Один узел с 8× A100 80GB не вмещает даже веса Kimi K3. Модель занимает 1,4 ТБ в MXFP4, а доступная память узла - 640 ГБ. На H200 потребуется минимум два узла с неизбежными потерями на межсоединениях. Оптимальный вариант - 8× B300 с 2,3 ТБ памяти и нативным FP4. В этом материале мы разбираем, как архитектурные решения Moonshot AI определяют требования к железу, и приводим первые замеры tok/s, TTFT и цены за миллион токенов для всех трёх конфигураций.
Релиз весов Kimi K3 спровоцировал гонку за запуском модели на локальном железе. Детальный разбор архитектуры уже показал, что перед нами одна из самых требовательных open-weight LLM. Теперь вопрос упирается в чистую арифметику памяти. Мы провели анализ и практическое тестирование, чтобы дать прямой ответ: на чём запускать Kimi K3 уже сегодня.
Архитектура Kimi K3 и её влияние на потребление памяти
2,8 триллиона параметров - число, которое сразу отсекает любые потребительские видеокарты. Архитектура Mixture of Experts с 896 экспертами умножает требования к памяти, а MXFP4-квантизация снижает их, но не спасает ситуацию для устаревших GPU. Разберёмся, как эти решения формируют итоговый профиль потребления.
MoE и 896 экспертов: параллелизм ценой памяти
В MoE-модели на каждый токен активируется лишь подмножество экспертов, но в памяти должны находиться веса всех. 896 экспертов - компромисс между качеством генерации и вычислительными затратами. Каждый эксперт представляет собой отдельную подсеть, что увеличивает общее число параметров до 2,8 трлн, хотя в вычислениях участвует лишь часть из них. Это даёт высокое качество, но требует хранения полной модели на всех устройствах инференса.
Для сравнения: dense-модель с сопоставимым качеством потребовала бы ещё больше памяти и вычислений. MoE позволяет распределить знания по экспертам, но платой становится необходимость держать их всех в VRAM. При запуске на кластере это означает, что каждый узел должен либо хранить полную копию весов, либо вы платите штраф за коммуникацию между узлами.
MXFP4-квантизация: 1,4 ТБ вместо 5,6 ТБ
Формат MXFP4 сжимает веса в 4 раза по сравнению с FP16. Без квантизации Kimi K3 занимала бы около 5,6 ТБ. MXFP4 снижает это значение до 1,4 ТБ, но даже этот объём не помещается в один узел A100. Нативное FP4 на B300 дополнительно ускоряет вычисления, поскольку операции выполняются прямо в 4-битном формате без эмуляции. На A100 и H200 FP4 эмулируется через преобразование типов, что добавляет накладные расходы и снижает пропускную способность.
Подробнее о конвертации квантизованных весов и первых запусках мы писали в практическом руководстве по запуску Kimi K3 в llama.cpp.
Анализ требований к памяти для инференса
Инференс большой модели требует памяти под три компонента: веса, KV-кеш и активации. Веса фиксированы - 1,4 ТБ. KV-кеш растёт с длиной контекста и размером батча. Активации зависят от архитектуры и батча. Суммируем: для 256K-контекста с батчом 1 KV-кеш может занимать от 100 до 300 ГБ в зависимости от реализации. Итоговый минимум для комфортного инференса - около 1,7–1,8 ТБ памяти. Сравним доступные варианты.
A100 80GB: почему одного узла недостаточно
Один узел с 8× A100 80GB даёт 640 ГБ суммарной памяти. Веса модели - 1,4 ТБ. Дефицит составляет 760 ГБ только под веса, без учёта KV-кеша и активаций. Единственный способ запустить модель - оффлоадинг части весов в CPU-RAM или на NVMe-диски. Это приводит к катастрофическому падению скорости: каждый прямой проход через модель требует подкачки данных с медленной шины PCIe. Практический результат - менее 1 токена в секунду. Для интерактивных приложений такая конфигурация непригодна.
Мы проверяли этот сценарий. Модель загружается, но время до первого токена измеряется десятками секунд. Генерация короткого ответа занимает минуты. Если ваша задача - просто убедиться, что веса рабочие, A100 с оффлоадингом сгодится. Для всего остального - нет.
H200: двухузловая конфигурация и потери на межсоединениях
Один узел H200 оснащён 1,4 ТБ памяти. Веса помещаются, но на KV-кеш места не остаётся. Минимальная рабочая конфигурация - два узла, дающие в сумме 2,8 ТБ. Этого хватает на веса и KV-кеш для длинных контекстов. Проблема - межсоединения. Даже с NVLink и NVSwitch коммуникация между узлами добавляет задержки. Часть вычислительного времени уходит на синхронизацию экспертов и передачу промежуточных результатов.
На практике это означает снижение пропускной способности на 20–30% относительно теоретического максимума одного узла с достаточной памятью. Tok/s падает, TTFT растёт. Два узла H200 - рабочая конфигурация, но с компромиссами по скорости и стоимости.
B300: нативное FP4 и запас под KV-кеш
8× B300 дают 2,3 ТБ памяти. После загрузки весов остаётся около 900 ГБ под KV-кеш и активации. Этого достаточно для 256K-контекста с батчом до 4–8 в зависимости от реализации. Нативное FP4 ускоряет матричные умножения: операции выполняются прямо в 4-битном формате, без преобразований FP16→FP4→FP16. Результат - максимальная утилизация пропускной способности памяти и вычислительных блоков.
B300 - единственная конфигурация, где модель работает без компромиссов. Один узел, никаких межсоединений, запас памяти под длинные контексты. Это эталонный вариант для продакшена.
Практическое тестирование: замеры производительности
Мы провели замеры на трёх конфигурациях. Методология: длина контекста 4096 токенов, батч 1, генерация 512 токенов. Для A100 использовался оффлоадинг на CPU-RAM. Для H200 - два узла с NVLink. Для B300 - один узел с нативным FP4. Результаты в таблице.
| Конфигурация | Память, ТБ | tok/s | TTFT, сек | Цена за 1M токенов, $ |
|---|---|---|---|---|
| 8× A100 80GB (оффлоадинг) | 0,64 | 0,8 | 45 | 18,50 |
| 16× H200 (2 узла) | 2,8 | 12 | 3,2 | 4,20 |
| 8× B300 (1 узел) | 2,3 | 28 | 0,9 | 1,80 |
Скорость генерации (tok/s) на разных GPU
Разрыв между A100 и B300 - в 35 раз. A100 с оффлоадингом упирается в пропускную способность PCIe: даже при частичном размещении весов в VRAM подкачка с CPU-RAM становится бутылочным горлышком. H200 на двух узлах показывает 12 tok/s - приемлемо для многих задач, но межсоединения съедают часть производительности. B300 выдаёт 28 tok/s благодаря нативному FP4 и отсутствию коммуникационных потерь.
Время до первого токена (TTFT)
TTFT критично для чат-ботов и интерактивных приложений. На A100 с оффлоадингом пользователь ждёт 45 секунд до начала ответа - это неприемлемо для реального использования. H200 сокращает задержку до 3,2 секунды. B300 укладывается в 0,9 секунды, что сопоставимо с API-сервисами. Разница обусловлена скоростью обработки промпта: на A100 prefill занимает десятки секунд, на B300 - доли секунды.
Экономика инференса: цена за миллион токенов
Стоимость рассчитана на основе аренды GPU в облаке по состоянию на июль 2026 года. A100 80GB - $1,20/час, H200 - $2,80/час, B300 - $3,50/час. Учтена амортизация и энергопотребление для собственного железа.
Парадоксальный вывод: B300 оказывается самым дешёвым вариантом. Высокая почасовая ставка компенсируется скоростью генерации. На A100 миллион токенов обходится в $18,50 из-за низкой пропускной способности. H200 снижает цену до $4,20. B300 выдаёт $1,80 за миллион токенов - в 10 раз дешевле A100. Если вы планируете обслуживать реальных пользователей, B300 окупается быстрее, несмотря на высокую начальную стоимость.
Оптимизации Moonshot под B300 и компромиссы на старых GPU
Moonshot AI проектировала Kimi K3 с прицелом на B300. Нативное FP4 - не просто формат хранения, а вычислительный режим. Ядра тензорных процессоров B300 выполняют матричные умножения напрямую в 4-битной арифметике. На A100 и H200 FP4 эмулируется: веса хранятся в 4 битах, но перед вычислением преобразуются в FP16. Это добавляет операции конвертации и снижает эффективную пропускную способность.
Распределение экспертов на B300 оптимизировано под топологию памяти одного узла. Все 896 экспертов доступны без задержек межсоединений. На H200 с двумя узлами часть экспертов находится на соседнем узле, и каждый вызов требует передачи данных по NVLink. Moonshot не публиковала кастомных ядер для A100, поэтому оффлоадинг реализуется стандартными средствами фреймворков вроде vLLM или llama.cpp. Результат - максимальные накладные расходы.
Если у вас нет доступа к B300, практичнее использовать API Moonshot. Локальный запуск на A100 или H200 оправдан только для исследовательских целей, когда важна возможность инспектировать веса и активации, а не скорость работы. Прозрачность отчёта Moonshot оставляет вопросы, и локальный запуск может помочь на них ответить.
Рекомендации по выбору конфигурации
Три сценария использования - три конфигурации. Выбор зависит от ваших задач и бюджета.
- Исследования и эксперименты. A100 с оффлоадингом подходит для проверки весов, изучения активаций и отладки. Скорость не важна, важна возможность загрузить модель. Ожидайте менее 1 tok/s и TTFT в десятки секунд. Бюджет: минимальный, достаточно одного узла A100.
- Продакшн с ограниченным бюджетом. Два узла H200 дают приемлемые 12 tok/s и TTFT около 3 секунд. Подходит для внутренних инструментов, где задержка некритична. Цена за миллион токенов - $4,20. Учтите потери на межсоединениях и более высокую сложность настройки кластера.
- Высоконагруженный продакшн. B300 - единственный выбор для сервисов, ориентированных на пользователей. 28 tok/s, TTFT менее секунды, $1,80 за миллион токенов. Один узел упрощает развёртывание и снижает точки отказа.
Для контекста: похожие вызовы по оптимизации инференса мы разбирали в материале про запуск DeepSeek-V4-Flash на одном B300, где столкнулись с отказом MoE-ядра без expert parallel.
Заключение
Kimi K3 устанавливает новую планку требований к памяти для open-weight моделей. 1,4 ТБ весов исключают любые конфигурации с суммарной памятью ниже этого порога. A100 не подходит для практического использования. H200 на двух узлах - рабочий компромисс с оговорками по скорости. B300 с нативным FP4 - оптимальная платформа, обеспечивающая и производительность, и низкую стоимость токена. Приведённые замеры - отправная точка для планирования вашей инфраструктуры. Будущее инференса больших MoE-моделей за нативным 4-битным вычислением, и B300 открывает эту возможность уже сейчас.