Mixture of Experts — одна з найпоширеніших архітектур 2024–2025 років. Mistral, DeepSeek, Qwen, Grok — всі вони використовують MoE у тій чи іншій формі. Разом із популярністю прийшло й нерозуміння: білдери переносять інтуїцію з dense-моделей на MoE і отримують несподівані результати — від краху розгортання до деградації якості після fine-tuning.

Ця стаття — практичний довідник: розбираємо найпоширеніші помилки при роботі з MoE-моделями і пояснюємо, що насправді відбувається всередині архітектури.

MoE — це не «велика dense-модель»

Перша і найшкідливіша помилка — сприймати MoE як просто більшу версію звичайної моделі. У dense-моделі кожен параметр задіяний під час кожного форвард-пасу. У MoE на кожен токен активується лише підмножина так званих «експертів» — окремих FFN-блоків. Наприклад, у DeepSeek-V3 на кожен токен активується 8 із 256 експертів. Загальна кількість параметрів — 671B, але активних під час inference — близько 37B.

Звідси перший практичний висновок: MoE дешевший у обчисленнях на токен, але дорожчий по пам'яті. Щоб запустити модель, треба тримати в пам'яті всіх експертів — навіть тих, що зараз не задіяні. Це фундаментальна відмінність, яку важливо засвоїти ще до планування інфраструктури.

Помилка 1: недооцінка вимог до пам'яті

Це найчастіша пастка при плануванні розгортання. Білдер бачить «активних параметрів 37B» і думає: «запущу на 2×A100 80 GB». Але для завантаження моделі потрібна пам'ять під усі 671B параметрів — у fp16 це близько 1,34 TB VRAM тільки під ваги, ще до KV-cache та активацій.

Як правильно рахувати:

• Загальна VRAM = загальна кількість параметрів × байти на параметр + KV-cache + activation memory
• Для fp16: кожен мільярд параметрів ≈ 2 GB — рахуйте від повного числа, не активного
• KV-cache зростає лінійно з batch size і context length — при довгому контексті це сотні GB додатково

Якщо плануєте self-host MoE-моделі рівня DeepSeek або Qwen MoE — реалістично розглядайте multi-node setup або кількісне ущільнення (AWQ, GPTQ), яке суттєво знижує вимоги без критичної втрати якості.

Помилка 2: ігнорування routing collapse

Routing collapse — ситуація, коли маршрутизатор (router) у MoE-шарі навчається відправляти майже всі токени до одного-двох експертів, ігноруючи решту. Це може відбуватися як під час тренування власних MoE-моделей, так і проявлятися при fine-tuning чужих.

Симптоми routing collapse:

• Один або два експерти отримують понад 90% токенів
• Auxiliary load-balancing loss різко зростає
• Якість генерації деградує на специфічних доменах або завданнях

Як запобігти при тренуванні: використовуйте auxiliary loss — штраф за нерівномірне завантаження експертів. У більшості фреймворків (Megatron-LM, MegaBlocks) це вбудована опція. Встановлюйте capacity factor вище 1.0, щоб переповнення одного експерта не блокувало обробку токенів.

При fine-tuning чужих MoE-моделей: якщо тренуєте лише частину параметрів, не заморожуйте router-ваги повністю — це може призвести до дрейфу між розподілом токенів і можливостями збережених експертів.

Помилка 3: хибні очікування щодо latency і throughput

Поширена помилка — вважати, що менше активних параметрів автоматично означає меншу затримку. Насправді MoE може бути повільнішим за dense-модель порівнянного «активного» розміру через кілька причин:

• Expert routing overhead: маршрутизатор додає обчислення на кожен токен у кожному MoE-шарі
• Communication overhead: у розподілених системах «all-to-all» обмін між вузлами для відправки токенів до відповідних експертів стає вузьким місцем
• Load imbalance: якщо батч нерівномірно розподіляється між експертами, одні GPU простоюють, чекаючи на інші

Практичний наслідок: MoE виграє у throughput (токенів за секунду при великому batch), але не обов'язково у latency (час до першого токена). Для real-time застосунків із малими батчами — зважуйте це перед вибором архітектури.

Помилка 4: некоректний fine-tuning

Fine-tuning MoE-моделей має свої особливості, які часто ігноруються.

LoRA на MoE: якщо застосовуєте LoRA-адаптери, їх слід додавати і до expert FFN-шарів, і до shared-шарів (attention). Ігнорування expert-шарів дає помітно слабший результат, оскільки саме там зосереджена більшість специфічних знань моделі.

Learning rate: MoE-моделі чутливіші до learning rate, ніж dense-аналоги. Емпірично ефективніші значення у 2–3 рази нижчі за стандартні рецепти для dense-моделей — починайте з консервативних налаштувань.

Моніторинг балансування: завеликий batch size може маскувати routing collapse під час тренування, усереднюючи дисбаланс. Відстежуйте expert utilization явно — не покладайтеся лише на загальну функцію втрат.

Висновок AiiN

MoE — потужна архітектура, але з нетривіальними компромісами. Головне, що варто тримати в голові перед кожним проєктом:

• VRAM рахується від загальних параметрів, а не від активних
• Routing collapse — реальна загроза і при тренуванні, і при fine-tuning
• Переваги у throughput не завжди конвертуються у кращу latency для малих батчів
• Fine-tuning потребує окремих рецептів: LoRA на всі шари, нижчий LR, явний моніторинг балансування

Моделі на базі MoE — Mistral, DeepSeek, Qwen, Grok — стали практичним стандартом для high-capacity inference. Розуміти їхні особливості означає правильніше ставити завдання, точніше планувати інфраструктуру й отримувати передбачувані результати замість несподіваних провалів.