Смешение экспертов простыми словами: почему MoE быстрее

MAATRIX

Вы читаете описание новой модели: «120 миллиардов параметров», а рядом кто-то пишет, что она генерирует текст почти как модель на 15 миллиардов. Дальше — хуже: для развёртывания ей всё равно нужна память как для полных 120 миллиардов. Если это выглядит как противоречие — оно и есть противоречие для человека, который ждёт от больших моделей одинаково больших требований и по скорости, и по памяти. На деле здесь работает архитектура Mixture of Experts (MoE, «смешение экспертов»), и она удивляет свежих людей плюс-минус одинаково каждый раз. Разберём, что там происходит на самом деле и что из этого следует для железа.

Как работает обычная, «плотная» модель

Начнём с базы, чтобы контраст был понятен. Классическая языковая модель — GPT-2, LLaMA, Qwen в «плотных» (dense) версиях и большинство моделей, которые вы запускаете через Ollama по умолчанию, — устроена так: есть один большой набор весов, и для обработки КАЖДОГО токена активируется абсолютно ВСЯ сеть целиком. Токен проходит через все слои, через все нейроны, через все параметры без исключения — не важно, спрашиваете вы дату столицы Франции или просите написать регулярное выражение.

Это простая и предсказуемая схема. Она напрямую связывает три вещи: число параметров, объём вычислений на токен и объём памяти под веса. Модель на 7 миллиардов параметров в FP16 весит около 14 ГБ на диске и в VRAM (без учёта KV-кэша и служебных буферов — про это подробно в статье про KV-кэш), и на каждый токен генерации нужно пройти вычисление примерно через все эти 7 миллиардов весов. Хотите модель умнее — увеличиваете число параметров, и вычислений на токен становится пропорционально больше, а генерация — пропорционально медленнее. Это и есть главное ограничение плотной архитектуры: качество и скорость тянут в разные стороны, компромисса без потерь тут нет.

Что меняет смешение экспертов

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

Ключевая идея: для обработки конкретного токена активируется не вся модель, а маршрутизатор в реальном времени решает, какие именно несколько экспертов из общего набора нужны именно сейчас — и включает в работу только их. Обычно это 2 эксперта из 8, 2 из 16, изредка больше — конкретное число («top-k») задаётся архитектурой и обычно указано в конфигурации модели. Остальные эксперты в эту секунду просто не участвуют в вычислении — они есть, они загружены, но их веса не используются, поэтому и на вычисления не тратится время.

Важный нюанс, который часто упускают: маршрутизация происходит НЕ один раз на весь запрос, а отдельно для каждого токена, а часто даже отдельно для каждого слоя модели внутри одного токена. Один токен может пойти через экспертов №2 и №5 на одном слое и через №1 и №7 на следующем. Это не «выбор одного специалиста на весь диалог», а постоянное, очень мелкозернистое перераспределение нагрузки буквально на каждом шаге генерации.

Аналогия: компания с отделами и диспетчером

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

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

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

Это и есть суть компромисса MoE в одном абзаце: экономия на вычислениях (меньше сотрудников реально работает над каждым конкретным запросом) без экономии на содержании штата (все сотрудники должны быть наняты и присутствовать).

Почему это ускоряет вычисления, но не экономит память

Здесь стоит зафиксировать техническую суть предельно честно, потому что путаница именно в этом месте стоит дороже всего при планировании сервера.

На вычисления (и, следовательно, на скорость генерации) влияет число АКТИВНЫХ параметров — то есть сколько весов реально участвует в математике при обработке одного токена. Если из общего пула в 100 экспертов маршрутизатор на каждом слое включает только 2, то по вычислительной нагрузке модель ведёт себя похоже на плотную модель размером примерно с эти 2 активных эксперта (плюс общие для всех токенов части сети — attention-слои, эмбеддинги и так далее, которые в MoE обычно остаются общими и считаются всегда). Именно поэтому MoE-модель с большим суммарным числом параметров может генерировать текст со скоростью, сравнимой с гораздо более компактной плотной моделью — вычислительно она гораздо легче, чем кажется по заявленному общему размеру.

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

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

Как это выглядит на конкретном примере

Возьмём для иллюстрации известную открытую MoE-архитектуру — Mixtral 8x7B от Mistral AI, чьи параметры маршрутизации публично описаны в конфигурации модели (config.json на Hugging Face содержит поля num_local_experts и num_experts_per_tok). У неё 8 экспертов и маршрутизатор активирует 2 эксперта на каждый токен на каждом слое.

Суммарный размер модели — это НЕ 8 умножить на размер одного эксперта, потому что часть слоёв (attention, эмбеддинги) общая для всех экспертов и не дублируется — по паспорту архитектуры суммарно это около 46,7 млрд параметров, из которых активны для каждого конкретного токена около 12,9 млрд. Прошу заметить: это архитектурные характеристики из документации модели, а не измеренные лично мной цифры скорости — точную скорость генерации на конкретном железе я не берусь называть, она будет зависеть от вашей видеокарты, квантования, длины контекста и загрузки сервера.

Практический смысл для человека, который сравнивает модели: вычислительно Mixtral 8x7B ощущается скорее как модель в районе 13 млрд активных параметров (то есть быстрее многих плотных моделей похожего суммарного размера), а по требованиям к памяти — вести себя нужно так, будто это полноценная модель на 46-47 млрд параметров, потому что именно столько весов нужно одновременно держать загруженными. При хранении в стандартном FP16 это около 90+ ГБ только под веса, без учёта KV-кэша и системных накладных расходов; при квантовании до Q4 объём будет заметно меньше — подробнее в статье про квантование Q4/Q5/Q8, но сама логика «считать по сумме, не по активной части» не меняется ни при каком уровне квантования.

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

Что учитывать при выборе сервера под MoE-модель

Практический вывод из всего разобранного один: при оценке требований к железу под MoE-модель ориентируйтесь на СУММАРНЫЙ размер модели, а не на число «активных» параметров, о котором обычно говорят в контексте скорости. Это самая частая ошибка тех, кто впервые встречается с этой архитектурой — увидев «активных параметров как у модели на 13B», человек мысленно прикидывает под неё бюджет памяти для 13B-модели и потом упирается в нехватку VRAM или RAM при попытке реально загрузить модель.

Порядок действий на практике:

1. Найдите в карточке модели (обычно README.md или config.json на Hugging Face) суммарное число параметров — часто оно прямо в названии («8x7B», «MoE-235B-A22B» — где после «A» число активных, а перед ним суммарное) или указано отдельным полем.
2. Считайте память под веса от суммарного числа, а не от активного — так же, как для плотной модели того же суммарного размера: параметры × размер одного параметра (2 байта для FP16, ~0,5-0,6 байта для Q4 в зависимости от схемы квантования).
3. Добавьте запас под KV-кэш, контекст и служебные процессы — методика та же, что и для плотных моделей, разобрана в статье про расчёт контекстного окна и памяти.
4. Ориентируйтесь на пропускную способность памяти (memory bandwidth), а не только на её объём — для MoE она даже более критична, чем для плотных моделей, потому что на каждом шаге приходится «доставать» из памяти веса разных экспертов; подробнее в статье про пропускную способность памяти как потолок локальной LLM.
5. Проверьте, что движок инференса вообще поддерживает MoE-маршрутизацию для конкретной архитектуры — не все версии vLLM, llama.cpp и Ollama одинаково быстро добавляют поддержку новых схем маршрутизации, это стоит явно сверить в документации выбранного движка перед покупкой железа под конкретную модель.

Если сомневаетесь, с какого объёма памяти начинать разговор о сервере — практичнее взять с запасом сверх расчётного суммарного размера модели процентов на 20-30 под контекст и служебные нужды, чем упереться в нехватку в проде.

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