Технический контекст
Я посмотрел на эти расчёты по Kimi K3 и сразу упёрся в главный вопрос: мы обсуждаем лабораторный запуск или нормальную AI integration под прод? Это две очень разные сметы, и путать их нельзя.
Если брать BF16 для модели класса 2.5–2.8T, оценка в 32 B300 GPU выглядит не безумной. Там действительно выходят терабайты HBM, огромный KV-cache, буферы, плюс питание и охлаждение уже на уровне отдельного инженерного проекта, а не “просто купили железо”.
Но дальше начинается самое интересное. Для Kimi K3 разговор не только про общий размер модели, а про формат весов и реальную схему сервинга. Если нативный инференс идёт в MXFP4 или MXFP8, картина резко меняется: уже можно обсуждать 1–2 DGX B300 не как шутку, а как рабочий компромисс для low-concurrency сценария.
Я бы, правда, не продавал идею “один DGX и всё полетело” слишком смело. На бумаге 2.3 TB HBM у 1× DGX B300 вроде бы хватает, но в жизни память съедают не только веса. Нужны место под cache, служебные буферы, маршрутизацию экспертов и нормальный запас, иначе система будет жить на грани.
Именно поэтому оценки вида $600–700k за 1× DGX B300 для private use звучат правдоподобно только как исследовательский вариант. А вот 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 реально окупится, а где лучше не покупать себе дорогую иллюзию контроля.