Технічний контекст
Я переглянув ці розрахунки щодо Kimi K3 і одразу вперся в головне питання: ми говоримо про лабораторний запуск чи повноцінну AI integration під продакшн? Це два дуже різні кошториси, і плутати їх не можна.
Якщо брати BF16 для моделі класу 2.5–2.8T, оцінка у 32 B300 GPU не виглядає божевільною. Там дійсно виходять терабайти HBM, величезний KV-cache, буфери, плюс живлення та охолодження вже на рівні окремого інженерного проекту, а не «просто купили залізо».
Але далі починається найцікавіше. Для Kimi K3 мова не лише про загальний розмір моделі, а про формат ваг і реальну схему сервінгу. Якщо нативний інференс іде в MXFP4 або MXFP8, картина різко змінюється: вже можна обговорювати 1–2 DGX B300 не як жарт, а як робочий компроміс для сценарію з низькою паралельністю.
Я б, правду кажучи, не продавав ідею «один DGX і все полетіло» надто сміливо. На папері 2.3 TB HBM у 1× DGX B300 начебто вистачає, але в житті пам'ять з'їдають не лише ваги. Потрібне місце під cache, службові буфери, маршрутизацію експертів і нормальний запас, інакше система житиме на межі.
Саме тому оцінки типу $600–700k за 1× DGX B300 для приватного використання звучать правдоподібно лише як дослідницький варіант. А от 2× DGX B300 за $1.25–1.45M вже більше схожі на нижню межу для нормального on-prem із батчингом, паралельними запитами та без постійної боротьби за кожен гігабайт.
Окрему суперечку про BF16 проти квантизації я чудово розумію. Якщо потрібен «топ без компромісів», BF16 логічний. Але тоді бюджет летить у зону, де багато хто раптом розуміє: API був не таким уже й дорогим.
Вплив на бізнес та автоматизацію
Для бізнесу тут три висновки. Перший: гігантська open model ще не означає дешеву AI automation. Залізо, interconnect та експлуатація легко стають дорожчими за саму ідею.
Другий: якщо у вас вузький приватний сценарій, R&D або внутрішня knowledge-система, 1–2 вузли можуть бути виправдані. Якщо потрібен стабільний SLA, довгий контекст і багато одночасних користувачів, економія на кластері потім повертається болем у latency.
Третій: багато команд переоцінюють цінність «обов’язково тримати все в себе» і недооцінюють гібридну AI architecture. Ми в Nahornyi AI Lab якраз вирішуємо такі розвилки для клієнтів: де вигідний API, де потрібен власний контур, а де варто build AI automation поверх меншої моделі без цього мільйонного кошторису.
Якщо у вас зараз схожа дилема між on-prem, API та кастомною архітектурою, давайте розкладемо її за цифрами, а не за форумними враженнями. У Nahornyi AI Lab я зазвичай швидко рахую, де artificial intelligence implementation реально окупиться, а де краще не купувати собі дорогу ілюзію контролю.