Mixture of Experts (MoE): смесь экспертов в нейросетях

Mixture of Experts (MoE) — это архитектура нейросети, в которой для каждого токена или примера активируется не вся модель, а только небольшой набор специализированных подмоделей, называемых экспертами. Практический смысл прост: модель можно сделать очень большой по числу параметров, не увеличивая вычисления на каждый шаг пропорционально этому размеру. Такой подход особенно полезен в крупных трансформерах, многоязычных системах и моделях с широким набором доменов. Но MoE плохо подходит для маленьких моделей, развёртывания на одном слабом устройстве, задач с жёстко фиксированной задержкой и инфраструктуры, где обмен данными между устройствами становится узким местом.

Простыми словами

Представьте команду специалистов: один хорошо работает с кодом, другой — с юридическими формулировками, третий — с разговорным языком. Вместо того чтобы заставлять одного универсального сотрудника одинаково глубоко разбираться во всём, система направляет каждый фрагмент работы к тому, кто вероятнее справится лучше. В MoE роль диспетчера выполняет модуль router, а роль специалистов — эксперты.

Важно не путать MoE с обычным ансамблем моделей. В ансамбле несколько отдельных моделей делают предсказания целиком, а затем их ответы объединяются. В MoE эксперты встроены внутрь одной модели, и для каждого токена активируется только часть из них. То есть это не несколько независимых систем, а один общий вычислительный граф с разреженной активацией.

Подход	Что активируется при обработке токена	Главная идея
Плотная модель	Все слои и все параметры слоя	Максимально простой и предсказуемый путь вычислений
MoE	Общий каркас модели и только часть экспертов	Большая общая ёмкость при разреженном вычислении
Ансамбль	Несколько отдельных моделей	Повысить устойчивость или качество за счёт объединения ответов

Как это работает

Чаще всего MoE встраивают в трансформер, заменяя обычный плотный feed-forward блок набором экспертов. Каждый эксперт — это отдельная небольшая сеть, обычно такого же типа, как стандартный FFN-блок, но со своими параметрами.

1. Токен проходит через общую часть модели. Например, через attention-слои трансформера.
2. Router получает скрытое представление токена. Он вычисляет оценки для всех экспертов.
3. Выбирается top-k экспертов. На практике это часто один или два эксперта на токен.
4. Токен отправляется выбранным экспертам. Их выходы масштабируются по весам роутера и объединяются.
5. Модель продолжает вычисление. Для следующего слоя процесс повторяется.

Из этого следуют две важные особенности. Во-первых, общая модель может содержать очень много параметров, потому что одновременно используется лишь малая их часть. Во-вторых, появляется новая инженерная задача: токены нужно распределять по экспертам так, чтобы одни не были постоянно перегружены, а другие не простаивали.

Поэтому в обучении MoE почти всегда есть дополнительные механизмы:

• балансировка нагрузки — вспомогательный loss, который не даёт роутеру отправлять почти все токены к одному эксперту;
• capacity factor — ограничение, сколько токенов эксперт может принять за шаг;
• overflow handling — стратегия для токенов, которые не поместились в выбранного эксперта;
• expert parallelism — распределение экспертов по нескольким устройствам.

На бумаге идея выглядит простой, но на практике основная сложность не в самих экспертах, а в коммуникации между устройствами. Если эксперты распределены по разным GPU, то модель тратит время не только на математику, но и на пересылку токенов. Поэтому MoE особенно чувствителен к качеству межузловой связи и реализации операций типа all-to-all.

Зачем нужно

MoE применяют там, где плотная модель становится слишком дорогой, но хочется нарастить общую ёмкость и специализацию.

• Масштабирование параметров. Можно увеличить число параметров модели без пропорционального роста FLOPs на каждый токен.
• Специализация. Разные эксперты могут лучше обслуживать разные языки, жанры текста, типы запросов или паттерны данных.
• Более эффективное использование вычислений. Если токену не нужен весь объём знаний модели сразу, нет смысла активировать все параметры.
• Поддержка многообразных задач в одной модели. Вместо нескольких крупных систем можно собрать один общий каркас с внутренней специализацией.

Но выгода не бесплатна. MoE имеет смысл, когда модель действительно большая и разнообразие входов достаточно велико, чтобы специализация окупилась. Для компактных моделей или узких задач плотная архитектура часто проще, стабильнее и дешевле в эксплуатации.

Пример

Практический сценарий: корпоративный ассистент, который отвечает по документации продукта, API, биллингу и юридическим условиям использования. Обычная плотная модель должна одинаково хорошо держать в рабочих параметрах и синтаксис кода, и тарифные правила, и договорные формулировки. В версии с MoE в нескольких FFN-слоях можно разместить экспертов, условно специализирующихся на технических описаниях, биллинге, юридическом тексте и общем языке.

Пользователь пишет: Как обновить webhook и повлияет ли это на лимиты моего тарифа? После attention-слоёв router видит, что часть токенов относится к API и конфигурации, а часть — к ограничениям подписки. Токены, связанные с webhook, уходят к техническому эксперту; токены про тариф и лимиты — к биллинговому; служебные слова остаются на общих экспертах. На выходе модель собирает единый ответ, но внутри него разные фрагменты были обработаны разными подмодулями.

Что здесь важно для практики:

• нужно смотреть не только на качество ответа, но и на распределение нагрузки по экспертам;
• если один эксперт забирает слишком много токенов, router может деградировать в почти плотную схему;
• при дообучении на узком домене есть риск, что несколько экспертов перестанут использоваться;
• при инференсе на нескольких GPU задержка может определяться не вычислением, а пересылкой токенов.

Иными словами, MoE в таком продукте полезен, если у вас действительно разнотипный поток запросов и инфраструктура умеет быстро обслуживать разрежённый роутинг. Если запросы однообразны, а система должна работать на одном устройстве с предсказуемой задержкой, плотная модель обычно практичнее.

Заблуждения и ограничения

• «MoE всегда быстрее». Не всегда. Вычислений на токен может быть меньше, чем у плотной модели той же общей ёмкости, но коммуникация между устройствами и логика роутинга способны съесть этот выигрыш.
• «Эксперты автоматически становятся понятными человеку». Тоже нет. Иногда один эксперт действительно чаще получает код или определённый язык, но жёсткой семантической интерпретации может не быть.
• «Чем больше экспертов, тем лучше». Избыточное число экспертов усложняет обучение, ухудшает балансировку и повышает накладные расходы на память и обмен данными.
• «MoE заменяет ансамблирование». Это разные инструменты. MoE решает задачу условного вычисления внутри одной модели, а ансамбль — задачу комбинирования нескольких моделей.
• «MoE легко дообучать как обычный трансформер». Базовая логика похожа, но стабильность обучения сильнее зависит от баланса нагрузки, качества роутера и стратегии распределения экспертов по устройствам.
• «MoE подходит для любого развёртывания». Нет. Для edge-сценариев, on-device инференса, маленьких батчей и систем без быстрой межсоединительной шины преимущества часто не проявляются.

Есть и методические ограничения. MoE не решает проблему внешних знаний сам по себе: если модели нужен доступ к актуальной базе данных или документам, архитектуры вроде RAG остаются отдельным классом решений. Кроме того, MoE не отменяет необходимости хороших данных: плохо размеченный или узкий датасет не станет лучше только потому, что вы добавили экспертов.

Частые вопросы

Чем MoE отличается от ансамбля моделей?

В MoE есть один общий каркас модели и внутренний роутинг токенов по экспертам. В ансамбле несколько отдельных моделей независимо получают вход и затем объединяют результаты. Цель MoE — разрежённое вычисление и масштабирование ёмкости, цель ансамбля — повысить устойчивость или качество за счёт комбинирования.

Что такое router в MoE?

Router — это модуль, который по скрытому представлению токена решает, какие эксперты должны его обработать. Обычно он выбирает одного или двух экспертов по схеме top-k и назначает им веса.

Ускоряет ли MoE инференс?

Иногда да, но не автоматически. Если сравнивать с плотной моделью той же общей ёмкости, на токен может приходиться меньше активных вычислений. Однако при распределённом запуске выигрыш зависит от стоимости пересылки токенов между устройствами и от того, насколько равномерно нагружены эксперты.

Можно ли дообучать MoE под свой домен?

Да, но это сложнее, чем обычный instruction-tuning плотной модели. Нужно следить, чтобы роутер не схлопывал распределение в один-два эксперта, а редкие эксперты не «умирали» без трафика. Для узких доменных задач иногда разумнее сначала проверить плотную базовую модель.

Связанные понятия

Понятие	Связь с MoE	Ключевое отличие
Conditional computation	Общий принцип: активировать только часть сети в зависимости от входа	MoE — частный и наиболее известный способ такой организации
Sparse activation	Техническая основа MoE	Разрежённость относится к вычислению, а не обязательно к весам
Dense transformer	Базовая альтернатива	В плотной модели для каждого токена активны все параметры слоя
Expert parallelism	Способ разнести экспертов по устройствам	Нужен для практического обучения и инференса крупных MoE
Switch Transformer	Известный вариант MoE с выбором одного эксперта	Упрощает роутинг по сравнению с маршрутами на несколько экспертов

Если нужен краткий вывод для практики, он такой: MoE — это способ купить больше модельной ёмкости ценой более сложной инженерии. Подход оправдан в больших системах с разнородными данными и хорошей распределённой инфраструктурой. Если же приоритет — простота, стабильность и предсказуемая задержка, плотная модель часто остаётся лучшим выбором.