Гонка за токенами: почему MoE-моделям нужен новый диспетчер
Пару лет назад Mixture of Experts (MoE) стал мейнстримом — DeepSeek V3, Qwen3, MiniMax и армия китайских стартапов затащили архитектуру с тысячами мелких экспертов. Но чем больше экспертов, тем жестче проблема: на этапе декодирования каждый токен обращается к 2-4 экспертам, раскиданным по десяткам GPU. Результат — дикий all-to-all трафик, просадки latency и недогруженные ускорители.
В июне 2026 года группа исследователей (похоже, из Microsoft Research) выкатила препринт с хитрой идеей — Expert Locality-aware Decoding Routing (ELDR). Суть: если в prefilling фазу маршрутизация уже определила, какие эксперты чаще всего активируются вместе, то на декодинге можно заранее разместить эту связку на одном узле или вычислительном ядре. Никаких глобальных пересылок — только локальные.
💡 ELDR — не про обучение, а про сервинг. Он не трогает веса, только перекраивает логистику.
Как это работает (без кода, но с метафорой)
Представьте склад запчастей. В обычной MoE каждый токен (заказ) бежит к разным стеллажам (экспертам), расталкивая встречные заказы. ELDR запоминает, какие стеллажи часто нужны одним и тем же заказам, и ставит их рядом. В следующий раз токен не бегает по всему складу — повернулся, взял, ушел.
Конкретнее: алгоритм строит граф совместной активации экспертов на префильной фазе, кластеризует их и на лету перераспределяет так, чтобы каждый кластер оказался на минимальном физическом расстоянии. EMO-подобные техники показывают, что эксперты внутри одного слоя имеют сильную корреляцию — ELDR этим и пользуется.
⚠️ Важный нюанс: ELDR добавляет небольшой overhead на профайлинг (первые несколько запросов), но авторы утверждают, что он окупается уже на 5-10 токенах.
Цифры и бенчмарки (сдерживаем скепсис)
В статье приводят тесты на синтетической нагрузке: 16 экспертов на слой, 8 GPU, модель ~200B параметров. Результаты:
- Снижение времени генерации токена на 23-37% в зависимости от batch size.
- Уменьшение межнодового трафика (all-to-all) почти в 4 раза.
- Без потери качества — routing приоритетов не меняется, только физическое размещение.
Звучит красиво, но на реальных workload'ах (например, квантованные Qwen3-Coder или fine-tune с NeMo) результаты могут плавать. Хотя бы потому, что реальный паттерн запросов редко бывает однородным.
Кому это нужно (и когда ждать в продакшене)
Если вы крутите большие MoE-модели на кластере (8+ GPU) для чат-ботов или код-ассистентов — ELDR ваш кандидат. Для маленьких инференсов на одной карте выигрыш будет мизерным: там локальность экспертов и так не проблема.
Пока код не выложен (авторы обещают opensource к осени 2026), но уже можно экспериментировать с routing-логикой вручную через кастомные маршрутизаторы. Главное — не забыть про профайлер.
Подводные камни: не верь, пока не попробуешь
- Динамика нагрузки. Если паттерн активации экспертов резко меняется (например, смена темы в чате), кластеризация может устареть. Нужна адаптивная перебалансировка.
- Гранулярность. Для моделей с сотнями экспертов на слой кластеризация сама становится узким местом.
- Гармония с другими оптимизациями. ELDR может конфликтовать с speculative decoding или LoRA-адаптерами из MoOLE-T — всё это добавляет свои сдвиги в расположении экспертов.
И еще: ELDR вряд ли станет серебряной пулей. На кластерах с быстрым NVLink и топологией «звезда» выигрыш может быть меньше, чем на дешевых ethernet-сетях. Зато именно для последних техника — реальный спаситель.
Резюме: революция или бустик?
ELDR — это не новый алгоритм обучения, не новый слой, не новая функция активации. Это инженерное решение проблемы физического размещения экспертов во время инференса. Если оно взлетит, мы увидим менее дорогой хостинг больших MoE и меньше жалоб на «первый токен слишком долго». Если нет — останемся с теми же all-to-all и дорогими InfiniBand. Пока я ставлю на «да», но с оговоркой: opensource-реализация всё решит. Следим за репозиториями.
