Mixture of Experts: разреженная активация

Q: Почему у MoE отдельно считают total и active parameters?

Потому что total parameters описывают общий объём параметров и требования к памяти, а active parameters — сколько параметров реально участвует в обработке одного токена. Для MoE это принципиально разные величины.

Mixture of Experts (MoE) — это архитектурный приём, в котором модель хранит много параметров, но на каждом токене активирует только небольшую их часть. В современной волне LLM идея опирается на линию работ от Sparsely-Gated MoE и GShard до Switch Transformers, Mixtral и DeepSeekMoE. Для практиков это важно потому, что MoE меняет не только «размер модели на бумаге», но и экономику обучения, маршрутизацию токенов, профиль узких мест при инференсе и требования к распределённой системе.

Ниже — не каталог всех MoE-моделей, а разбор механики. Мы сосредоточимся на том, что делает роутер, почему эксперты обычно заменяют FFN-блоки, откуда берутся overflow, token dropping и коммуникационные издержки, и зачем в более поздних работах появляются shared experts и dropless-обучение.

Коротко

MoE отделяет общий объём параметров от вычислений на один токен: модель может быть «большой в памяти», но «не полностью активной в работе».
Базовый MoE-слой состоит из набора экспертов, роутера, механизма dispatch/combine и ограничений на загрузку экспертов.
Главная польза MoE приходит не сама по себе: нужны удачная маршрутизация, балансировка нагрузки и эффективная межустройственная коммуникация.
Главные инженерные проблемы — перекос маршрутизации, overflow, token dropping, all-to-all обмен между устройствами и более сложный serving.
Современные примеры вроде Mixtral и DeepSeekMoE показали, что MoE — это не только исследовательский трюк для гигантских кластеров, а полноценное пространство архитектурных компромиссов.

Контекст: зачем вообще понадобился Mixture of Experts

В плотной (dense) Transformer-модели каждый токен проходит через один и тот же набор параметров. Это просто для реализации и хорошо масштабируется по качеству, пока хватает данных и вычислений. Но у такого режима есть очевидная цена: каждый новый параметр обычно означает, что вы снова и снова платите вычислением за весь блок на каждом токене.

Идея MoE пытается разорвать эту связку. Ещё в работе Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer авторы формализовали conditional computation: не вся сеть обязана работать на каждом примере; можно иметь набор под-сетей и обучаемый gate, который выбирает, какие из них активировать. Позже обзор A Review of Sparse Expert Models in Deep Learning аккуратно обобщил эту мысль: разреженность позволяет развести в стороны общий размер модели и вычисления на один пример.

Для LLM это особенно важно в feed-forward части Transformer. В Switch Transformers и затем в Mixtral of Experts стандартный паттерн выглядит так: dense FFN внутри слоя заменяют набором FFN-экспертов, а роутер решает, какие из них обработают текущий токен. Поэтому MoE в популярных языковых моделях — это, как правило, не «несколько разных LLM рядом», а разрежённая замена части внутренней архитектуры одной модели.

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

Метод: как работает разреженная активация в MoE

Из чего состоит MoE-слой

На практике MoE-слой обычно содержит три обязательных компонента. Первый — это сами experts, чаще всего несколько независимых FFN-блоков с собственными параметрами. Второй — router или gating network, который по скрытому состоянию токена оценивает, какие эксперты подходят лучше. Третий — механизм dispatch/combine: токен нужно физически отправить к выбранным экспертам, получить их выходы и корректно собрать результат обратно в основной residual-поток.

Почему чаще всего заменяют именно FFN, а не attention? В Switch Transformers это прямо показано как стандартная конфигурация: dense FFN заменяется sparse Switch FFN. В Mixtral of Experts та же идея описана ещё проще: слой состоит из нескольких feedforward blocks, выступающих экспертами. Это практичный компромисс: attention остаётся общим для всех токенов, а разрежённость вводится там, где легко выиграть в ёмкости параметров.

Как токен проходит через слой

Механика у большинства MoE-вариантов похожа. Скрытое состояние токена поступает в роутер. Роутер вычисляет оценки по всем экспертам. Затем выбирается top-k экспертов, после чего токен отправляется только к ним. Их выходы масштабируются весами роутера и суммируются. Дальше результат возвращается в основной поток Transformer так же, как возвращался бы выход обычного FFN.

router_scores = softmax(x · W_router)
selected = top_k(router_scores, k)
y = Σ_i∈selected router_scores[i] * expert_i(x)

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

Почему нужен load balancing

Если просто дать роутеру свободу, он часто начинает отправлять слишком много токенов в небольшое число удобных экспертов. Тогда часть экспертов перегружается, а часть почти не учится. Поэтому уже ранние sparse-gated MoE и затем Switch Transformers вводят отдельные механизмы балансировки загрузки. Идея простая: модель должна не только хорошо выбирать эксперта для качества, но и использовать пул экспертов достаточно равномерно, чтобы не получить «коллапс маршрутизации».

В Switch Transformers это оформлено как вспомогательная функция потерь для выравнивания роутинга. На интуитивном уровне она подталкивает распределение токенов по экспертам к более равномерному виду. Это не делает маршрутизацию «честной» автоматически, но сильно помогает обучению не схлопнуться в несколько постоянно активных экспертов.

Capacity, overflow и token dropping

Следующая проблема появляется сразу после выбора экспертов: каждый эксперт может обработать лишь ограниченное число токенов за шаг. Если слишком много токенов направлены к одному и тому же эксперту, возникает overflow. Тогда системе нужно выбрать неприятный компромисс: либо отбросить часть токенов, либо заранее паддить вычисления под худший случай и тратить память и FLOPs неэффективно.

Switch Transformers делает это ограничение явным через expert capacity и показывает, как overflow возникает прямо в роутинге. Работа MegaBlocks: Efficient Sparse Training with Mixture-of-Experts строится именно вокруг этого узкого места и формулирует проблему жёстко: существующие реализации часто заставляют выбирать между dropping tokens и wasteful padding. Отсюда и интерес к dropless MoE: если система умеет не терять токены и при этом оставаться аппаратно эффективной, архитектурная идея MoE становится заметно практичнее.

Что меняют поздние варианты

Дальнейшее развитие MoE шло не по одной линии. Switch Transformers радикально упростила маршрутизацию: в этой работе токен отправляется только к одному эксперту. Это снижает вычислительную и коммуникационную сложность, но делает балансировку особенно важной. Mixtral of Experts, наоборот, показывает популярный современный вариант, где роутер выбирает двух экспертов и суммирует их выходы. Такой режим увеличивает гибкость комбинаций, хотя и усложняет исполнение.

Отдельная ветка — попытка улучшить не только масштаб, но и специализацию. В DeepSeekMoE авторы утверждают, что проблема стандартных top-k схем не сводится к эффективности: важно ещё и то, насколько эксперты реально разделяют знания, а не дублируют друг друга. Отсюда две характерные идеи этой работы: делать экспертов более мелкими и выделять shared experts, которые всегда отвечают за общие паттерны, оставляя routed experts для более узкой специализации.

Результаты: что показала литература по MoE

Если смотреть на линию работ целиком, MoE развивался не как одна «магическая архитектура», а как последовательность решений разных классов проблем: сначала — как вообще сделать sparse gating обучаемым, потом — как встроить его в крупные Transformer, затем — как упростить роутинг и наконец как убрать системные потери на уровне реализации.

Линия работ	Что было новым	Практический смысл
Sparsely-Gated MoE	Ввела обучаемый sparse gate и совместное обучение роутера с экспертами.	MoE — это часть одной сети, а не ансамбль независимых моделей после обучения.
GShard	Показала, что conditional computation можно встроить в крупные Transformer и распределённое обучение.	Для MoE важен не только алгоритм, но и способ шардирования и компоновки вычислений.
Switch Transformers	Упростила роутинг до одного эксперта на токен и закрепила замену dense FFN на sparse expert FFN как рабочий шаблон.	Чем проще маршрутизация, тем легче обучение и реализация, но тем выше чувствительность к дисбалансу.
Mixtral	Показал современный open-weight SMoE: роутер выбирает двух FFN-экспертов; в paper и официальном посте Mistral это описано как 46.7B total и 12.9B active параметров на токен.	Сравнивать MoE только по общему числу параметров некорректно: active-параметры не менее важны, чем total.
DeepSeekMoE	Предложил fine-grained expert segmentation и shared experts как способ уменьшить дублирование знаний.	Проблема MoE — не только масштабирование, но и качество специализации.
MegaBlocks	Сфокусировался на эффективной sparse-реализации без привычного компромисса между dropping и padding.	В MoE системный слой почти так же важен, как архитектурный.

Есть и более общий вывод. Почти все сильные результаты в этой области измеряются не одной метрикой, а набором разных осей: total parameters, active parameters, FLOPs, wall-clock speed, sample efficiency, downstream quality и стоимость распределённого исполнения. Эти величины нельзя бездумно смешивать. MoE-модель может выглядеть «огромной» по total parameters и при этом вести себя ближе к куда более компактной dense-модели по активным вычислениям на токен.

Интерпретация: что это значит и почему важно

Главное последствие MoE для практики — появляется новая ось масштабирования. В dense-модели рост параметров и рост вычислений обычно привязаны друг к другу. В MoE вы можете увеличить доступную ёмкость модели сильнее, чем растут вычисления на один токен, потому что активируется только часть экспертных параметров. Именно поэтому MoE так часто всплывает в разговорах о «больших, но всё ещё исполнимых» LLM.

Но эта выгода не бесплатна. Разреженность переносит сложность из математики в систему: роутинг, балансировка, capacity planning, all-to-all обмен, размещение экспертов по устройствам и отдельные компромиссы serving-слоя. Если dense Transformer — это относительно прямолинейный «большой GEMM-конвейер», то MoE — это уже комбинация вычислений и логистики данных.

Наш комментарий

На наш взгляд, MoE полезно воспринимать не как «способ сделать модель больше», а как способ по-новому распределить бюджет. Вы покупаете дополнительную ёмкость параметров, но расплачиваетесь более капризным обучением и гораздо более сложной эксплуатацией. Именно поэтому сравнение вида «MoE на X параметров против dense на Y параметров» почти всегда неполно без уточнения, сколько параметров активно на токен, как устроен роутинг и что происходит на реальном кластере.

Из этого следует и практическое правило чтения papers. Если авторы показывают выигрыш MoE, нужно отдельно смотреть минимум на четыре вещи: где именно вставлены эксперты, как считается active compute, есть ли token dropping или rerouting, и насколько результат зависит от конкретного системного стека. Без этого легко перепутать архитектурный выигрыш с выигрышем от инфраструктуры или, наоборот, недооценить архитектуру из-за неудачной реализации.

Ограничения и критика

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

Во-вторых, выигрыш по upstream-метрикам не всегда аккуратно переносится на downstream. Это важно потому, что sparse-модели часто показывают очень хорошие свойства в pretraining, но Switch Transformers прямо отмечает: рост качества на предварительном обучении не гарантирует такого же чистого выигрыша в fine-tuning на всех задачах. Для практики это означает, что MoE нельзя оценивать только по loss или perplexity.

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

В-четвёртых, многие paper-результаты сильно завязаны на конкретный стек. Для MoE особенно важны layout батча, реализация all-to-all, шардирование экспертов и low-level kernels. Из-за этого одна и та же архитектурная идея может выглядеть блестяще в одной инфраструктуре и посредственно в другой.

Наконец, MoE не всегда лучший ответ на задачу. Если у вас маленький или средний inference-budget, жёсткие latency-SLA, простая однородная предметная область или команда без зрелой distributed-инфраструктуры, dense-модель может оказаться лучше по суммарной цене владения, даже если она хуже выглядит по «параметрам на слайде».

Вывод

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

Если запомнить одну вещь, то вот она: в MoE надо смотреть не только на сколько параметров всего, но и на сколько параметров реально работает на токен, как устроен роутинг и какой системной ценой это достигается.

Источники

FAQ

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

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

Почему эксперты чаще ставят в FFN, а не в attention?

Потому что так проще получить выигрыш в параметрической ёмкости без полного взрыва сложности. Литература по Switch и Mixtral использует именно expert FFN как базовый рабочий шаблон; attention-эксперименты существуют, но они обычно более капризны по стабильности и реализации.

MoE всегда быстрее dense-модели?

Нет. На уровне активных вычислений на токен MoE может быть выгоднее, но итоговая wall-clock скорость зависит от роутинга, overflow, обмена между устройствами, kernel-реализации и serving-инфраструктуры. Поэтому claim о «быстрее» нужно проверять в конкретном стеке.

Почему у MoE отдельно считают total и active parameters?

Потому что это разные вещи. Total parameters говорят, сколько знаний и памяти хранит модель целиком, а active parameters — сколько из этого реально задействуется на одном токене. Для MoE это принципиально важное различие.

Mixture of Experts: как работает разреженная активация