Skip to main content
qwenmoeai-infrastructure

Qwen, 2.7T і холодний душ для заліза

Обговорення Qwen змішало розмір моделі та обсяг навчальних даних: офіційно на сьогодні моделі на 2.7 трильйона параметрів немає. Але дискусія корисна, оскільки розкриває реальні витрати на AI інтеграцію та інфраструктуру для великих MoE, показуючи розрив між очікуваннями та реальними вимогами до обладнання й бюджету.

Технічний контекст

Я поліз у цифри, бо тема про «2.7T параметрів і лише 50B активних» звучить ефектно, але з фактами там каша. На сьогодні у Qwen немає офіційної моделі на 2.7 трильйона параметрів. Швидше за все, люди змішали розмір моделі з обсягом навчальних даних, а це зовсім різні розмови.

Якщо дивитися на реальні релізи, то найближче сюди Qwen3-235B-A22B: 235 мільярдів параметрів сумарно і близько 22 мільярдів активованих на токен. Це вже серйозний MoE-підхід, і саме він важливий для AI-автоматизації та продакшн-систем, бо вирішує не лише питання якості, а й вартості інференсу.

Ось де я реально зупинився: sparse MoE не скасовує фізику. Коли активується мала частина ваг, обчислень на токен менше, так. Але пам'ять, маршрутизація експертів, пропускна здатність interconnect і затримки нікуди не зникають.

Тому розрахунки з обговорення про сотні GPU, десятки терабайт HBM і шалений бюджет не виглядають маячнею як клас. Вони виглядають маячнею стосовно приписаного Qwen-числа, але не самої ідеї переднавчання гігантської sparse-моделі. Для повного тренування такого рівня розмова зазвичай іде вже не про «сервер», а про окрему інфраструктурну програму.

І так, fine-tuning тут окремий біль. LoRA ще можна протягнути відносно адекватно, а от повноцінне донавчання величезної MoE-архітектури швидко впирається в пам'ять, sharding, checkpointing та вартість експериментів. На серветці це рахується гарно, а потім приходить рахунок за кластер і охолодження.

Що це змінює для бізнесу та автоматизації

Для бізнесу висновок дуже приземлений: більшості компаній не потрібен свій монстр на сотні мільярдів параметрів. Їм потрібна нормальна AI-архітектура: обрати модель під задачу, зібрати пайплайн, додати retrieval, контроль якості та моніторинг.

Виграють ті, хто будує AI-рішення для бізнесу навколо ефективності, а не фетишу розміру моделі. Програють команди, які планують бюджет по хайпу з X, а не по реальних обмеженнях пам'яті, latency і вартості токена.

Я це бачу постійно: проблема зазвичай не в тому, що «модель замала», а в тому, що AI-впровадження зібране криво. У Nahornyi AI Lab ми якраз вирішуємо такі вузькі місця: де потрібен агент, де вистачить компактної MoE, а де дешевше й надійніше взагалі не чіпати важке навчання. Якщо ваш пайплайн уже впирається у вартість, затримку чи хаос в інтеграціях, можна спокійно розібрати архітектуру разом зі мною і зібрати AI-автоматизацію без зайвих мільйонів у залізі.

Раніше ми розповідали, як аналіз вартості контексту та конфігурацій архітектури для великих моделей, як-от Claude Opus 4.6, може оптимізувати автоматизацію бізнесу. Подібний розрахунок витрат застосовується при оцінці кластера інференсу для моделі з 2,7 трильйона параметрів.

Поділитися статтею