Как разреженный ИИ на 17 млрд параметров обходит плотную модель на 70 млрд: анатомия Mixture-of-Experts (MoE)

Если вы случайно упустили момент, когда создатели языковых моделей соревновались в наращивании гигантских чисел в названиях, а открыв глаза, обнаружили всеобщий тренд на скромное количество активных параметров, эта публикация написана специально для вас. Сегодня мы разберем метаморфозу, превратившую все передовые open-source флагманы в MoE-системы, выясним, почему Qwen3.5 при своих 397 миллиардах параметров генерирует текст с невероятной скоростью, и убедимся, почему при этом никто не обанкротился на покупке ускорителей.

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

Фундамент трансформеров: почему MoE произвел революцию

Обратимся к истокам: классический трансформер состоит из последовательных слоев, внутри которых хранятся матрицы с числовыми коэффициентами. Сумма всех этих чисел и составляет общий объем параметров модели. Исторически действовало негласное правило: чем больше этот массив, тем мощнее система. Предположим, модель получает на вход фразу: «Привет! Ты инженер, закончи предложение, которое начинается словом «пиковая»». Этот запрос последовательно проходит сквозь все 96 слоев, трансформируясь в диалоговый контекст, который оседает в специальном хранилище — KV-кэше. Важная ремарка: кэшируются не сами лексемы, а промежуточные вычислительные представления модели.

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

1. Attention (Механизм внимания) — этакий гиперактивный секретарь. Занимая относительно скромную долю объема (около трети параметров), он постоянно сверяется с кэшем, удерживает исходный контекст, генерирует собственные корректировки и передает их дальше. И так на протяжении всех 96 слоев!

2. Feed-Forward Network (Полносвязная сеть, FFN) — массивное хранилище шаблонов и фактов, забирающее оставшиеся две трети параметров. Этот блок прекрасно осведомлен о том, что бывает пиковая нагрузка, пиковая мощность, предельная ставка или даже пиковая дама. Однако он совершенно лишен способности оценивать широкий контекст и умеет лишь перемножать числа, поступившие с предыдущего уровня.

Вернемся к нашему примеру: на ранних этапах генерации отсекаются лишние смысловые пласты («Раз речь не о художественной литературе или карточных играх, значит, нас интересует либо нагрузка, либо мощность, либо ставка — следующие уровни разберутся»). На последующих слоях происходит уточнение: «Минутку, какая может быть ставка? Никаких упоминаний финансов или биржи здесь нет».

Этот конвейер работает до тех пор, пока пользователь не увидит на экране готовый результат: «Привет! Вот твой ответ: пиковая нагрузка на систему превышает номинальную».

Теперь взглянем на экономическую изнанку этого процесса. Вывод банального слова «нагрузка» заставил нас задействовать полный проход по всем 96 блокам и всем 175 миллиардам параметров. Абсолютно все матрицы, включая узкоспециализированные знания по юриспруденции, медицине и поэзии серебряного века, участвовали в обработке технического термина. И подобная нагрузка создается для каждого сгенерированного токена, причем за приветственное слово пользователь платит ровно ту же вычислительную цену, что и за сложный экспертный ответ.

Разработчики концепции Mixture-of-Experts (смеси экспертов) задали логичный вопрос: зачем прогонять запросы через всё массивное хранилище FFN на каждом шаге, если эту громоздкую часть можно декомпозировать на множество компактных специализированных модулей-«экспертов», активируя для обработки конкретного токена лишь пару из них? Остальной массив никуда не исчезает, но вычислительные ресурсы расходуются исключительно на задействованные в данный момент блоки.

Именно поэтому для MoE-сетей принято указывать двойную цифру в характеристиках: общий объем параметров отражает эрудицию модели, а количество активных параметров определяет вычислительную сложность запроса. Так, у Qwen 3.5 заложено 397 миллиардов знаний при стоимости всего в 17 активных миллиардов, а Kimi K2.5 оперирует триллионом при эквиваленте 32 активных параметров.

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

Анатомия MoE: где скрывается медицинский гений

Итак, главное архитектурное нововведение MoE заключается в замене монолитного FFN-блока на N миниатюрных FFN-экспертов в сопровождении крошечного диспетчера (роутера). Модуль Attention остался практически без изменений ввиду своей изначальной компактности.

Теперь пайплайн функционирует по следующей схеме:

1. Лексема проходит слой Attention практически стандартным образом (с оговоркой на специфику архитектурных нюансов).

2. Роутер анализирует скрытое состояние (hidden state) — те самые промежуточные смысловые маркеры — и отбирает top-k наиболее подходящих экспертов из общего пула N.

3. Токен обрабатывается исключительно выбранной группой, в то время как остальные N−k модулей бездействуют.

4. Полученные результаты агрегируются с учетом весов роутера, формируя итоговый выходной вектор слоя.

Однако давайте приглядимся к этому роутеру — крошечному компоненту с огромными полномочиями. Ведь именно он решает, какому конкретно эксперту направить результаты анализов на ферритин, которые вы решили загрузить в чат-бот?

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

Когда исследователи (включая создателей модели Mixtral) проанализировали распределение токенов от роутера, никакой строгой тематической специализации обнаружено не было. Выяснилось, что модули специализируются на синтаксических паттернах: один отлично справляется с пунктуацией, другой ориентируется в числах, а третий специализируется на отступах и ключевых словах языка Python. Структурные особенности текста распознаются моделью намного успешнее, чем высокие материи вроде юриспруденции или медицины.

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

Казалось бы, схема выглядит безупречной? На практике она имеет свои изъяны.

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

Инженеры компании DeepSeek учли этот нюанс и усовершенствовали концепцию: помимо динамических экспертов, они внедрили единый shared-модуль (общий эксперт), который активен постоянно для каждого токена. Логика проста: универсальные элементы (грамматика, частая лексика) необходимы всегда, поэтому нет смысла заставлять каждого эксперта хранить дублирующуюся информацию. Базовый функционал закреплен за общим блоком, а вариативный — за распределенными экспертами, размер которых можно дополнительно уменьшить.

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

Балансировка нагрузки (Load balancing): ключевая головная боль MoE

Концепция Mixture-of-Experts берет свое начало в далеком 1991 году — с ней можно ознакомиться в <детальной научной работе>. Пионеры направления предложили ансамбль экспертных сетей в сочетании с управляющим модулем-диспетчером. Правда, преследовалась тогда совсем другая цель: предотвратить интерференцию разнородных подзадач при обучении. Эту фундаментальную проблему долго не удавалось решить.

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

«Мертвые» эксперты не просто простаивают без дела — они впустую расходуют дефицитную видеопамять. Для эффективного задействования всего пула было предложено внедрить балансировочные штрафы (Auxiliary loss). Механизм работает как регулятор честности: фиксируя диспропорцию в распределении запросов, система принудительно заставляет роутер равномернее распределять задачи. Решение оказалось действенным, хотя и не идеальным: полная емкость модели задействуется ценой того, что роутер порой направляет токен не самому оптимальному эксперту. Нивелировать этот побочный эффект помогают дополнительные математические инструменты — Z-loss и Aux-loss-free. Оставим ссылки для глубокого погружения энтузиастов и двинемся дальше.

Почему 17-миллиардные модели превосходят 70-миллиардные аналогов и где скрывается подвох

Вернемся к основному тезису. Плотные (Dense) модели жестко привязывают объем вычислительных затрат к числу параметров: желая получить богатую эрудицию, вы обязаны увеличивать вычислительные мощности для каждого токена. MoE разрушает эту жесткую зависимость: объем знаний соответствует 397 миллиардам параметров, а оплата взимается как за 17 миллиардов, поскольку в обработке участвуют лишь релевантные эксперты. В профессиональном сообществе действует эмпирическое правило: по эффективности MoE сопоставима с плотной моделью уровня √(total × active). Для Qwen3.5 это эквивалентно примерно 82B, а для DeepSeek-V3 — около 157B. Оценка условная, но порядок цифр отражает реальность: скромные 17 активных миллиардов уверенно превосходят плотные 70-миллиардные аналоги.

Однако в чем же кроется подводный камень?

При работе с небольшими батчами (например, ваш персональный чат-бот) архитектура демонстрирует невероятную экономичность. Но в условиях корпоративного сервера с размером батча 256 ситуация меняется: у каждого токена формируется уникальный маршрут, в результате чего за один шаг активируется практически весь пул экспертов, и системе приходится вычитывать из памяти весь массив весов. Преимущество по числу операций с плавающей запятой (FLOPs) сохраняется, но выигрыш по пропускной способности памяти (bandwidth) нивелируется. Крупные провайдеры решают эту проблему с помощью экспертного параллелизма, сложного планирования батчей, продвинутой квантизации (о которой мы уже рассказывали) и частичной выгрузки экспертов на CPU.

Главная валюта в мире MoE — это объем оперативной памяти. Поскольку маршрутизация токенов меняется динамически на каждом шаге и предсказать потребность заранее невозможно, вся совокупность экспертов должна постоянно удерживаться в памяти. Модель Qwen3.5 в формате BF16 требует около 794 ГБ для функционирования в режиме «17B активных». Загрузить исключительно востребованные модули физически невозможно, так как на следующем шаге активными станут совершенно другие компоненты.

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

 

Источник