Смесь экспертов (MoE): параметры, память и запуск моделей

Архитектура «смесь экспертов» позволяет нейросети выполнять меньше вычислений на каждый токен, хотя для её размещения по-прежнему нужны огромные ресурсы. У языковой модели Kimi K3.1 Pro от Moonshot AI 2.8T параметров всего, но на каждый токен активны только 104B, как указано в официальном сообщении о запуске. Меньшее число помогает понять объём вычислений, а большее остаётся важным, когда нужно разместить веса модели в памяти.

Числа параметров и утверждения источников проверены 24 октября 2026 года. Доли активных параметров ниже рассчитаны нами; это не результаты замеров ускорения, экономии памяти или качества.

Что такое смесь экспертов?

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

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

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

Как работает архитектура MoE?

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

Обработка идёт так:

1. Текущее представление токена поступает в слой MoE.
2. Обучаемый маршрутизатор, который также называют гейтом, присваивает экспертам оценки.
3. Он выбирает часть экспертов, обычно с наивысшими оценками. Это маршрутизация top-k, где k — число выбранных экспертов.
4. Выбранные эксперты обрабатывают представление токена. Их выходы взвешиваются и объединяются, затем обработка продолжается.

Этот процесс повторяется в слоях MoE, поэтому для разных токенов и на разных слоях могут выбираться разные эксперты. Разбор архитектуры от PyTorch описывает взвешенное объединение результатов, а статья Mistral о модели показывает, как выбор меняется от слоя к слою.

Что означает разреженность в MoE?

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

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

Смесь экспертов — по-прежнему одна модель

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

Разработчику важно помнить об этом при проектировании: выбор MoE-модели не даёт приложению управляемую команду специализированных агентов.

Общее число параметров и активные параметры: сравнивайте оба значения

Общее число параметров описывает размер хранимой модели, а число активных — заявленный объём параметров на пути обработки одного токена. Ни одно из этих значений не заменяет полных требований к оборудованию. B означает миллиарды, T — триллионы.

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

Kimi K3.1 Pro: малая доля очень большой модели

Kimi K3.1 Pro показывает, почему по числу активных параметров нельзя определять размер модели для размещения на своих серверах. Если привести общее число параметров Moonshot к тем же единицам, получится 2,800B. Тогда 104 ÷ 2,800 × 100 = 3.7%, с округлением.

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

В блоге о запуске Moonshot описывает Pro как версию K3 после дообучения и использует округлённое обозначение «класс 3T». В официальном сообщении о запуске приведена точная пара: 2.8T / 104B. Чтобы оценить размер модели, опирайтесь именно на эту явную спецификацию.

Для разработчика, использующего API, это модель, которую можно рассмотреть и протестировать. Для оператора собственных серверов сначала важна доступность весов: на дату проверки Moonshot обещала выпустить полные веса к 4 ноября 2026 года. Обещание релиза ещё не означает, что файлы для развёртывания доступны. Подробнее о решениях, связанных с этим выпуском, — в разборе Kimi K3.1 Pro.

Qwen3-235B-A22B: активные параметры не заменяют общее число

У Qwen3-235B-A22B это различие видно уже в названии. В исходной карточке модели Qwen указаны 235B параметров всего и 22B активных, а также 128 экспертов, из которых активируются 8.

Расчёт доли параметров: 22 ÷ 235 × 100 = 9.4%, с округлением. Для закрытого ассистента по работе с документами это подсказка о том, как модель ограничивает вычисления на токен. Но планировать память всё равно нужно под полный выбранный чекпойнт и состояние обслуживаемых запросов.

Не читайте «22B активных» как «занимает столько же памяти, сколько плотная модель на 22B». И всегда связывайте числа с конкретным чекпойнтом: одного названия семейства недостаточно для выбора файлов весов, числовой точности и конфигурации обслуживания.

Mixtral 8x7B: почему числа в названии нельзя просто перемножить

У Mixtral 8x7B есть общие компоненты, поэтому название модели — не инструкция по умножению. В блоге Mistral о запуске указаны 46.7B параметров всего и 12.9B используемых на токен. Если перемножить числа в названии, общие компоненты будут учтены так, словно они принадлежат отдельным полноценным моделям.

В статье Mistral описаны экспертные сети прямого распространения и общий механизм внимания. На каждом слое маршрутизатор выбирает 2 из 8 экспертов. Это не восемь независимых полноценных моделей.

По опубликованным числам параметров получаем 12.9 ÷ 46.7 × 100 = 27.6%, с округлением. Выбор 2 из 8 экспертов — это 25% экспертов, то есть здесь другой знаменатель. Общие компоненты — одна из причин, по которым доля выбранных экспертов отличается от доли активных параметров.

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

Почему меньше вычислений не всегда означает меньшую задержку?

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

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

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

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

Обработка промпта и генерация токенов тоже по-разному нагружают систему. Prefill обрабатывает входные данные, а decode генерирует последующие токены. В документации vLLM, ПО для обслуживания языковых моделей, описаны отдельные варианты обмена данными с экспертами для prefill с высокой пропускной способностью и decode с малой задержкой. В нашем руководстве по инференсу LLM разобраны эти этапы и метрики, которые нужно измерять отдельно.

Выбирая API, сравнивайте фактическое поведение на своих запросах. Пара чисел параметров не расскажет, насколько активно провайдер объединяет запросы в батчи, как долго они стоят в очереди и насколько его оборудование подходит модели.

Какие компромиссы MoE важны для бизнеса?

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

Память: каждому эксперту нужно место

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

Отправная точка для расчёта: объём хранения весов ≈ общее число параметров × число байтов на хранимый параметр. Это лишь начальная оценка: точность может различаться между тензорами, а метаданные файлов, выравнивание, копии и выделяемая во время работы память увеличивают общий объём.

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

Квантование — хранение весов с пониженной числовой точностью — может уменьшить занимаемый ими объём. Оно не превращает общее число параметров в число активных и не отменяет проверку качества ответов. В руководстве по квантованию LLM рассмотрен выбор формата и точности; сам механизм описан в обзоре квантования Hugging Face.

Пропускная способность: загрузить модель — только начало

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

Из-за этих пересылок межсоединения — каналы связи между устройствами — становятся частью архитектуры обслуживания. Ресурсы, распределённые по машинам с медленной связью, не эквивалентны тем же ресурсам в системе с быстрым обменом данными. Это прямо следует из схемы коммуникаций, описанной в реализации параллелизма по экспертам в PyTorch.

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

Маршрутизация: популярные эксперты могут стать узким местом

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

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

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

Как выбирать MoE-модели для API и собственных серверов?

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

Для разработчиков, использующих API, архитектура — полезный контекст, а не повод менять модель. Проверяйте типичные задачи, следование инструкциям, использование инструментов, если оно нужно, время до первого токена и время полного ответа при ожидаемом числе одновременных запросов. Фиксируйте неудачные попытки и повторы. Эффективность инфраструктуры провайдера не определяет ни ваш счёт, ни объём работы, необходимый для получения приемлемого результата.

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

Для заказчиков, отвечающих за обязательства по качеству сервиса, главный вопрос — укладывается ли модель в целевое время ответа при выполнении работы, которая проходит приёмку, на запланированной инфраструктуре. «Триллионы параметров всего, миллиарды активных» — описание архитектуры, а не гарантия уровня сервиса.

1. 1

   Определите нагрузку до сравнения моделей

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

2. 2

   Проверяйте тот способ доступа, который будете использовать

   Для API тестируйте выбранного провайдера и эндпоинт. Для собственных серверов зафиксируйте точный чекпойнт, числовую точность, среду выполнения и оборудование. Другой способ обслуживания даёт другой результат в эксплуатации.

3. 3

   Проверяйте производительность и качество вместе

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

4. 4

   Переходите, только если выигрывает ваша нагрузка

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

Если текущий API уже устраивает разработчика по качеству и времени ответа, название архитектуры ничего не меняет. А оператору, который рассчитал ресурсы по числу активных параметров, стоит пересмотреть план уже сейчас.

Какие возможности MoE переоценивают?

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

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

Большее общее число параметров не доказывает, что ответы лучше. Меньшая доля активных параметров тоже не делает модель лучше сама по себе. Важны обучение, архитектура и задача. Таблица выше объясняет заявленные размеры моделей и намеренно не ранжирует их по качеству.

Меньшая доля активных параметров не означает пропорционального снижения цены или ускорения. Сама по себе она ничего не говорит о тарифах провайдера, очередях, сетевых пересылках или количестве токенов, которое нужно сгенерировать для вашей задачи.

Какая научная работа лежит в основе MoE?

В статье 2017 года Shazeer и соавторы формализовали влиятельный вариант слоя MoE с разреженным гейтингом, который увеличивал ёмкость модели без пропорционального роста вычислений. Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer — первоисточник этого механизма. Обсуждение балансировки нагрузки и производительности распределённых систем в той же статье напоминает: эксплуатационные компромиссы были частью идеи с самого начала.

Частые вопросы разработчиков о MoE

Что такое смесь экспертов в LLM?

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

GPT-4 использует смесь экспертов?

В техническом отчёте GPT-4 дополнительные сведения об архитектуре, включая размер модели, не раскрываются. Отчёт не содержит подтверждённой разработчиком разбивки параметров MoE, поэтому использовать числа из слухов как факты для планирования развёртывания нельзя.

Что учитывать при дообучении MoE?

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

Что сделать перед следующим развёртыванием?

В понедельник добавьте к каждой модели в шорт-листе заметку об условиях обслуживания. Запишите заявленные разработчиком общее и активное число параметров, источник и точный чекпойнт или эндпоинт API. При доступе через провайдера добавьте результаты своих задач и замеры задержки. Для собственных серверов — полный объём весов, резерв под кэш и производительность при ожидаемом трафике. Такая заметка полезнее, чем рейтинг по самому крупному числу в рекламе.

Чтобы получать практические разборы инфраструктуры ИИ-продуктов, подпишитесь на рассылку.