Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Модели со смесью экспертов (MoE) научились ускорять на этапе генерации, не урезая их при чтении запроса. В нерецензированном препринте a2sys и KAIST, где числа получили сами авторы, SlimWise повысил пропускную способность декодирования до 1,81 раза после удаления половины экспертов. Подход позволяет оптимизировать самый узкий этап отдельно, не меняя формат кэша и архитектуру внимания.
Почему эксперты мешают именно при генерации
MoE-модель хранит много специализированных блоков-экспертов, но для каждого токена включает лишь несколько. Это сокращает вычисления, однако не гарантирует такой же экономии при чтении весов из памяти GPU.
Во время пакетной генерации каждый запрос выбирает собственный набор экспертов. Их объединение быстро охватывает почти весь пул: Qwen3.6-35B-A3B выбирает восемь экспертов из 256 для каждого токена, но крупный пакет обращается почти ко всем. Даже при умеренном размере пакета модель читала около 75% весов экспертов за один шаг.
Обработка исходного запроса устроена иначе. Модель одновременно прогоняет много входных токенов и повторно использует уже загруженные веса, поэтому скорость ограничивают вычисления. Удаление экспертов почти не ускоряет этот этап, если число активных блоков на токен остаётся прежним.
При генерации модель выпускает по одному токену для каждой последовательности. На одного загруженного эксперта приходится мало работы, и время начинает определять передача весов из памяти. Обычное сокращение модели применяется к обеим фазам сразу: оно ухудшает представление запроса, хотя заметный выигрыш даёт только после начала ответа.
Полный KV-кэш достаётся сокращённому декодеру
SlimWise выполняет обработку запроса полной моделью, а затем передаёт сокращённому декодеру кэш ключей и значений (KV-кэш). Удаление экспертов не меняет архитектуру внимания и формат кэша, поэтому преобразовывать сохранённые состояния не нужно.
В раздельной конфигурации обработка запроса и генерация работают на разных экземплярах. Декодер загружает только оставшихся экспертов, а освободившуюся память использует для дополнительных последовательностей и их кэша. Если обе фазы работают вместе, движок хранит полный пул, но при генерации маскирует удалённых экспертов в маршрутизаторе.
Одной передачи кэша оказалось недостаточно. Сокращённый декодер иногда сохранял результат на тесте, но резко менял длину рассуждения: на MATH-500 медиана выросла с 2,4 до 6,6 тысячи токенов. На других задачах ответы, наоборот, обрывались раньше.
Поэтому разработчики добавили перенос знаний со полной модели на сокращённую. Декодер обучали на 100 миллионах токенов, давали ему состояния полной модели и обновляли лишь часть параметров. При самом жёстком сокращении длинный хвост ответов на MATH-500 уменьшился с 32,8 до 14 тысяч токенов, хотя до поведения исходной модели не вернулся.
Это важная деталь для оценки таких оптимизаций. Итоговая точность может почти не измениться, а стоимость ответа и задержка вырастут из-за лишних токенов. Поэтому вместе с качеством нужно измерять медианную длину, длинный хвост и долю ответов, которые упираются в лимит генерации.
Когда SlimWise меняет архитектурный план
Работу проверяли на двух основах — Qwen3.6-35B-A3B и Gemma 4 — с тремя способами ранжировать экспертов. Качество измеряли на задачах по математике, программированию и вызову функций. Замеры скорости для Qwen выполняли в vLLM на паре A100-80GB, с запросами на тысячу входных и восемь тысяч выходных токенов.
SlimWise меняет план, если сервис уже использует MoE-модель и значительная часть времени уходит на длинную генерацию. В раздельной архитектуре сокращённый декодер не только меньше читает из памяти, но и освобождает место под KV-кэш. Это позволяет увеличить пакет, сохранив требуемую скорость генерации для одного пользователя.
При совместном размещении эффект уже: полный набор весов остаётся в памяти ради обработки запроса. Маскирование всё ещё сокращает передачу весов во время генерации, но не увеличивает доступную ёмкость KV-кэша.
Для сервисов с короткими ответами выигрыш на всём запросе будет меньше, потому что SlimWise не ускоряет начальную обработку. Метод также не сводится к безусловному удалению половины экспертов: после выбора набора придётся отдельно проверить качество, длину ответов и соблюдение лимитов на рабочих сценариях.
Практический архитектурный вывод касается границы между фазами. Если система уже разделяет обработку запроса и генерацию, эти части необязательно должны загружать одинаковую MoE-модель. Общий формат KV-кэша позволяет сохранить полную модель там, где важнее качество представления запроса, и сократить её там, где пропускную способность ограничивает память.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
