Після того як Mixtral 8x7B, DeepSeek-V3 і Grok-1 показали, що Mixture of Experts (MoE) дозволяє масштабувати продуктивність без лінійного зростання вартості inference, здається, ніби відповідь на питання «яку архітектуру обирати» стала очевидною. Але AI-білдери, які переходять на MoE без глибокого аналізу власного сценарію, часто натрапляють на несподівані труднощі: завеликий footprint у пам'яті, нестабільну латентність і складніший процес fine-tuning.
MoE — це не безкоштовний обід. Так, активується лише частина параметрів (у Mixtral 8x7B — два з восьми «експертів» на кожен токен), але загальний розмір моделі залишається величезним. Знати, коли не використовувати MoE — так само важливо для практика, як розуміти переваги цієї архітектури.
Що таке MoE і де ховається пастка
У класичній щільній мережі кожен токен проходить через усі параметри. У MoE є «маршрутизатор» (router), який вирішує, які кілька «експертів» (підмереж у FFN-блоці) обробляють цей токен. Теоретично — нижчі FLOPs на токен, вища ємність моделі при рівному бюджеті inference.
Але саме тут починається пастка для будівників систем. Модель із 47 млрд загальних параметрів (як Mixtral 8x7B) потребує завантаження усіх ваг у VRAM або RAM — навіть якщо активні лише 13 млрд. Тобто для хостингу такої моделі потрібно значно більше ресурсів, ніж для щільної моделі з 13 млрд параметрів, яка дасть порівнянну швидкість inference.
П'ять сценаріїв, де MoE програє
- Edge і on-device деплой. Якщо модель має запускатися на ноутбуці, мобільному або embedded-пристрої — MoE тут майже завжди поступається. Загальний розмір ваг критичний: увесь чекпоінт має поміститися у пам'ять. Llama 3.1 8B у 4-bit квантуванні займає близько 4,5 ГБ — проти ~25 ГБ для MoE-моделі з подібною «активною» потужністю.
- Latency-sensitive застосунки. Router у MoE додає додатковий крок на кожному шарі. При high-concurrency навантаженні чи потребі в P99 латентності нижче 200 мс — щільна модель зазвичай передбачуваніша. MoE-маршрутизація також ускладнює ефективне кешування KV-стану при великій кількості одночасних запитів.
- Вузькодоменне fine-tuning. Якщо ви адаптуєте модель під специфічний корпус — юридичні документи, медичні звіти, код однієї мови — щільна модель навчається прямолінійніше. У MoE є ризик expert collapse: ситуації, коли більшість токенів маршрутизується до одного-двох експертів, а решта деградує. Load balancing loss частково вирішує цю проблему, але ускладнює навчання.
- Маленький або непередбачуваний трафік. Паралелізм експертів реально корисний при high-throughput батчевій обробці. Якщо сервіс обробляє кілька десятків запитів на годину, переваги MoE не реалізуються, а складність інфраструктури зростає.
- Обмежений бюджет на VRAM. Якщо у вас один або два GPU з 24 ГБ пам'яті — щільна модель дає кращий ROI. MoE вимагає або дорогого GPU-кластера, або повільної CPU-offload стратегії, що нівелює перевагу в ефективності.
Практичні антипатерни при виборі MoE
Є кілька поширених помилок, які роблять AI-білдери при роботі з MoE:
- Порівнювати «активні параметри» замість загального footprint. Маркетинг часто акцентує на активних параметрах, але для деплою важливий повний розмір чекпоінту. Mixtral 8x7B — це 47 млрд, а не 13 млрд.
- Ігнорувати складність serving-стека. Ефективний inference для MoE потребує спеціалізованих фреймворків (vLLM з підтримкою expert parallelism, Megablocks тощо). Стандартний Transformers зі спрощеним сервером часто не дає очікуваної ефективності.
- Застосовувати MoE для завдань з коротким контекстом і малим batch. Якщо середня довжина запиту — 100 токенів і batch size = 1, різниця між MoE і щільною моделлю в реальному throughput мінімальна, а ресурси витрачаються непропорційно.
- Переносити fine-tuning пайплайн без адаптації. LoRA на MoE-моделях вимагає обережного вибору таргет-модулів: чи адаптувати лише router, лише FFN окремих експертів або все разом — це суттєво впливає на результат і вартість навчання.
Висновок AiiN
MoE — правильний вибір, коли є масштаб: high-throughput serving, кластер GPU, різноманітні завдання, де різні «знання» справді потрібні одночасно. Але для більшості команд, які будують перші production-системи або обмежені ресурсами, щільна модель залишається надійнішим і прогнозованішим вибором.
Перш ніж братися за MoE, дайте відповідь на три питання: чи поміщається повний чекпоінт у ваш hardware-бюджет? Чи достатній ваш throughput, щоб паралелізм мав сенс? Чи справді ваш use case виграє від diverse expertise, а не від глибокої спеціалізації? Якщо на будь-яке з них відповідь «ні» — скоріш за все, MoE зараз не для вас.