Если вдруг вы моргнули на моменте, когда разработчики нейросетей мерились у кого больше цифра рядом с названием модели, а выморгнув, обнаружили, что теперь модно флексить скромными размерами активных параметров, эта статья для вас. Сегодня объясняю, как же так произошло, что все флагманы опенсорса внезапно стали MoE, почему Qwen3.5 на 397 миллиардов параметров строчит токены, как будто ей 17 и почему никто не разорился на видеокартах.
Ну и для тех, кому «только спросить» откроем тайну: в каком же кабинете у MoE живет эксперт по медицине.
База про трансформеры и почему MoE стал прорывом
Давайте вспомним истоки: в обычной модели-трансформере есть слои. На каждом слое лежат матрицы с числами внутри них. Общее количество этих чисел во всей модели равняется числу параметров. Раньше было чем больше — тем круче. Модель, получает на вход некий контекст, допустим: «Привет! Ты инженер, закончи предложение, которое начинается словом «пиковая»». Запрос проделывает путь через все 96 слоев модели и становится контекстом беседы, попадая в «блокнот» модели — KV-кеш. Важная оговорка: ложатся в кеш, конечно, не сами слова, а пометки о том, что модель про них навычисляла.
А дальше начинается интересный процесс. Модель не выпаливает ответ сразу, а составляет его по словам (на самом деле токенам), постепенно передавая его через ВСЕ слои и уточняя ответ на каждом из них. Как происходит уточнение? Внутри каждого слоя живут два принципиально разных механизма:
Attention — это такой секретарь-СДВГшник. Маленький (по размеру 1/3 от количества параметров) все время сверяется с блокнотом, понимает какой контекст был на входе, подмешивает свои пометки о том, что считает правильным передает их дальше. 96 раз передает!
Feed-Forward Network (FFN) — это, грубо говоря, склад шаблонов. Он жирный (2/3 параметров), но полезный. Эта часть знает, что бывает пиковая нагрузка, пиковая мощность, пиковая ставка и даже пиковая дама, но она не умеет смотреть по сторонам, она умеет только перемножать числа, полученные от предыдущего слоя, не зная контекста беседы.
В случае с нашим предложением, на пути генерации ответа на ранних слоях происходит примерно следующий отсев: «Стопэ, у нас речь не про литературу и не про карты, значит либо нагрузка, либо мощность, либо ставка, на следующих слоях разберутся». Дальше происходит еще одно уточнение: «Позвольте-ка, ну какая ставка? Тут ни слова про игры или биржу».
…И так до конца, пока на экране у пользователя не появляется, например: «Привет! Вот твой ответ: пиковая нагрузка на систему превышает номинальную».
Но теперь посмотрим на экономику этого ответа. Слово «нагрузка» стоило нам полного прохода через все 96 блоков и все 175 миллиардов параметров. Все матрицы, включая знания о медицине, юриспруденции и поэзии Серебряного века, участвовали в вычислении технического термина. И так на каждое слово ответа: примерно две операции на каждый параметр модели, без скидок за простоту. Кстати, за слово «привет» вы заплатили столько же сколько за интересовавшее вас изначально.
Разработчики архитектуры Mixture-of-Experts подумали: а зачем нам задействовать весь склад FFN на каждом слое, если можно нарезать эту «жирную» часть модели на десятки маленьких «экспертов», чтобы каждый токен включал только пару из них. Остальные при этом никуда не деваются, но платим вычислениями мы только за те, что задействованы в ответе.
Вот так и повелось, что число параметров для сетей с архитектурой MoE у нас стало обозначаться двойной цифрой: общее число параметров отвечает за то, сколько модель знает, число активных — за то, сколько это стоит в вычислениях. У Qwen 3.5 это 397 миллиардов знаний по цене 17, у Kimi K2.5 — триллион по цене 32.
Для конечного пользователя это значит, что то же качество вычислений достигается примерно в семь раз быстрее — именно такое значение демонстрируется в работе ученых из Google. С момента выпуска этой работы стало понятно, что за MoE будущее архитектур.
Где в MoE живет эксперт по медицине
Итак, MoE изменил в архитектуре одну вещь: вместо одного FFN в блоке добавил N маленьких FFN-экспертов плюс крошечный роутер. Attention и так компактный, поэтому его почти не меняют.
Работает путь теперь примерно так:
Токен проходит attention почти как в обычной модели. (Говорю почти, потому что описание различий тянет на отдельную статью).
Роутер смотрит на hidden state (не само слово, а те самые пометки, которые модель себе навычисляла) и выбирает top-k экспертов из N.
Токен прогоняется только через выбранных — остальные N−k спят.
Их выходы складываются с весами роутера и превращаются в выход слоя.
Но давайте-ка пристальнее посмотрим на роутер: маленький слой с большой властью. Это ведь он решает, какому эксперту адресовать анализы на ферритин, которые вы решили скормить модели, да?
Тут вас ждет разочарование, даже два. Внимательно посмотрите на гифку выше. Видите на ней человека в белом халате? И я не вижу. Потому что не живут в MoE ни эксперт по коду, ни по медицине, ни по поэзии Серебряного века. Реальность одновременно скучнее и интереснее.
Когда исследователи (в том числе авторы Mixtral) посмотрели, кому роутер раздает токены, тематической специализации они не обнаружили. Оказалось, эксперты специализируются по токен-паттернам: этот любит пунктуацию, вон тот — числа, а этому подавай отступы в коде и питоновские кейворды. Вот так просто: синтаксис в этом представлении различим куда лучше, чем медицина или юриспруденция.
Теперь обратите внимание на подпись внизу гифки: невыбранные эксперты не считаются вообще. Это не «посчитали и умножили на ноль», их веса даже не читаются из памяти. Вся экономия MoE зиждется на этом факте — в нем их сила и одновременно самая большая боль.
Казалось бы, схема надежная как швейцарские часы? Если бы! Имеются в ней и дыры швейцарского сыра.
При прохождении пути токены уходят к разным экспертам, но всем им нужны одни и те же базовые знания, выходит, что они независимо друг от друга выучивают одно и то же на своих параметрах.
Ребята из DeepSeek усвоили это и докрутили схему: у них помимо роутизируемых экспертов появился один shared expert, который включен всегда, для каждого токена. Логика следующая: базовые вещи (грамматика, частые слова) нужны всем — незачем заставлять каждого эксперта дублировать их у себя. Общее храним в shared, частное — в роутизируемых экспертах, которых при этом можно еще и нашинковать помельче.
Однако дубли знаний — это не главная проблема, с которой столкнулись разработчики MoE на пути к тому, какими мы видим эти сети сегодня.
Load balancing: головная боль №1 в MoE
Вообще-то первая статья, которая описывает принципы MoE датируется аж 1991 годом, не верите, смотрите сами. Авторы тогда предложили набор экспертных сетей плюс отдельную сеть-распорядителя, которая решает, кого включить. Правда, боролись они вовсе не за экономию, а за то, чтобы разные подзадачи не мешали друг другу при обучении, и именно эту болячку долго не могли вылечить.
Первый рабочий подход к вопросу и сам роутер появились в более поздней работе. Вот ведь какая штука: эксперт, которого выбирают чаще, больше учится и становится лучше, из-за чего роутер… начинает выбирать его еще чаще! Соответственно, если в обучающей выборке было мало работы для какого-нибудь экзотического эксперта, новые задачи к нему и не попадут, потому что он доселе не подавал признаков жизни. Зато эксперт широкого профиля будет пыхтеть за троих.
«Мертвый» эксперт плох не только тем, что он не работает, он еще и занимает место на VRAM. Непорядок! Дабы задействовать весь состав было предложено добавить балансировочные лоссы. Это такой штраф во избежание коррупции и фаворитизма: если сеть видит, что какому-то эксперту направляется больше запросов, она прикрывает лавочку и заставляет роутер раздавать задачки ровнее (Auxiliary loss). Решение эффективное, но не без огрехов: все эксперты учатся, вся емкость модели работает, но ценой того, что роутер иногда шлет токен не самому лучшему эксперту. Чтобы этот факт не сильно влиял на качество ответов, используются еще два математических ухищрения: Z-loss и Aux-loss-free. Но это, пожалуй, уже слишком сложная тема. Оставил ссылки для прошаренных любопытствующих, а мы поедем дальше.
Так почему 17B бьют 70B и где подвох
Вернемся к тейку из заголовка. Если коротко, Dense-модели плотно связывают компьют с токенами: хочешь больше знаний — плати больше компьюта на каждый токен. MoE эту связь разрывает: знаний — на 397B, а платишь по 17B потому что задействуются только те эксперты, которые нужны для ответа на вопрос. В сообществах ходит такое эмпирическое правило: по качеству MoE ведет себя примерно как плотная модель на √(total × active) — для Qwen3.5 это ~82B, для DeepSeek-V3 ~157B. Числа грубые, но порядок верный: 17B активных честно бьют плотные 70B. С точностью народной эвристики можно поспорить в комментариях.
Но в чем же подвох? А в том, что на больших батчах халява тает.
При батче 1 (ваш локальный чатик) — все замечательно и выгодно. А вот на сервере с батчем 256 у каждого токена свой маршрут — суммарно за шаг активируются почти все эксперты, и читать из памяти приходится всё. Преимущество по FLOPs остается, по bandwidth — исчезает. Поэтому большие и серьезные провайдеры лечат это с помощью экспертного параллелизма, хитрого роутинга батчей, квантизации, про которую я уже писал, и выгрузки экспертов на CPU.
Счет у MoE выставляется в гигабайтах. Выбор экспертов происходит на каждом токене, и вам заранее не угадать, кто понадобится, поэтому в памяти обязаны сидеть все. Qwen3.5 в BF16 — это ~794 ГБ весов при работе «как 17B». Загрузить только активных нельзя, потому что спустя токен активными будут уже другие.
Ну а в остальном MoE — честная сделка: память в обмен на скорость и емкость. Теперь, когда вы увидите «1T параметров» из громких анонсов, то будете знать, что на каждом токене модель шевелит лишь скромные 32B. Зато как замороченно и элегантно она это делает!
