Синхронное декодирование MoE заставляет GPU ждать самую загруженную группу

Добавить GPU в кластер для LLM-сервиса и получить прирост пропускной способности меньше ожидаемого — типичная картина для крупных онлайн-развёртываний. Jiqizhixin пишет, что в схемах для MoE-моделей вроде DeepSeek дело в ожидании. Несколько групп карт параллельно обрабатывают свои запросы, но каждый шаг декодирования они завершают вместе, через межгрупповую связь. Шаг идёт «в ногу»: пока самая загруженная группа не досчитала, остальные стоят. Ниже разобрана механика проблемы по тому, что в нём сказано.

Почему шаг стоит ровно столько, сколько самая медленная группа

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

Такой обмен работает как барьер. Группа, которая справилась быстро, не может уйти вперёд и ждёт. Время шага определяется максимумом по группам, а не средним. Если разброс нагрузки растёт вместе с числом групп, то вероятность попасть на один сильно перегруженный узел тоже растёт. Карт больше, а доля времени, которую они проводят в простое, увеличивается.

Где теряется прирост

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

Из описания следуют такие свойства ситуации:

• Режим: онлайн-обслуживание с большим числом одновременных запросов.
• Архитектура: MoE-модель, развёрнутая на нескольких группах карт параллельно.
• Узкое место: синхронный шаг декодирования с межгрупповой коммуникацией.
• Симптом: пропускная способность растёт медленнее, чем число карт.
• Главный фактор потерь: дисбаланс нагрузки между группами, из-за которого быстрые ждут медленных.

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

Что известно о решении

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

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

Практический вывод

Команде, которая сама поднимает MoE-инференс, полезно проверить, что именно мешает масштабированию. Сначала стоит замерить разброс времени шага между группами карт, а не только суммарную пропускную способность. Если медленнейшая группа заметно отстаёт от средней, докупать GPU рано: часть из них будет простаивать. Затем нужно посмотреть, как запросы распределяются по группам, потому что длина контекста и число активных запросов сильно влияют на время шага. И только после этого имеет смысл считать стоимость токена при разном числе карт.

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