Один узел с 8× A100 80GB не вмещает даже веса Kimi K3. Модель занимает 1,4 ТБ в MXFP4, а доступная память узла — 640 ГБ. На H200 потребуется минимум два узла с неизбежными потерями на межсоединениях. Оптимальный вариант — 8× B300 с 2,3 ТБ памяти и нативным FP4: один узел вместо двух. В этом материале разбираем, как архитектурные решения Moonshot AI определяют требования к железу, и приводим первые замеры tok/s, TTFT и цены за миллион токенов для всех трёх конфигураций.
Главное
- Сколько памяти нужно для Kimi K3: 1,4 ТБ весов в MXFP4 плюс 100–300 ГБ под KV-кеш на 256K-контексте — итого около 1,7–1,8 ТБ.
- 8× A100 80GB (640 ГБ): веса не помещаются, запуск возможен только с оффлоадингом — менее 1 tok/s и TTFT в десятки секунд.
- 16× H200 (2 узла, 2,8 ТБ): 12 tok/s, TTFT 3,2 с, $4,20 за миллион токенов, минус 20–30% производительности на межсоединениях.
- 8× B300 (1 узел, 2,3 ТБ): нативный FP4, 28 tok/s, TTFT 0,9 с, $1,80 за миллион токенов — оптимальный вариант для продакшена.
Релиз весов 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.
Анализ требований к памяти для инференса
Ответ на вопрос, сколько памяти нужно для Kimi K3, складывается из трёх компонентов: веса, KV-кеш и активации. Веса фиксированы — 1,4 ТБ. KV-кеш растёт с длиной контекста и размером батча. Активации зависят от архитектуры и батча. Суммируем: для 256K-контекста с батчом 1 KV-кеш может занимать от 100 до 300 ГБ в зависимости от реализации. Итоговый минимум для комфортного инференса — около 1,7–1,8 ТБ памяти. Сравним доступные варианты.
A100 80GB: почему одного узла недостаточно
Запуск Kimi K3 на A100 80GB упирается в простую арифметику: один узел из 8 карт даёт 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. Результат — максимальная утилизация пропускной способности памяти и вычислительных блоков.
Kimi K3 на B300 — единственная конфигурация, где модель работает без компромиссов. Один узел, никаких межсоединений, запас памяти под длинные контексты. Это эталонный вариант для продакшена.
Практическое тестирование на A100, H200 и 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 |
Условия замеров: контекст 4096 токенов, батч 1, генерация 512 токенов. Цены — аренда GPU в облаке на июль 2026 года; для собственного железа учтены амортизация и энергопотребление.
Скорость генерации (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. В продакшене и интерактиве конфигурация непригодна.
- Продакшн с ограниченным бюджетом (2 узла H200). 12 tok/s и TTFT около 3 секунд — подходит для внутренних инструментов, где задержка некритична. Цена за миллион токенов — $4,20. Учтите потери на межсоединениях и более высокую сложность настройки кластера.
- Высоконагруженный продакшн (B300). Единственный выбор для сервисов, ориентированных на пользователей. 28 tok/s, TTFT менее секунды, $1,80 за миллион токенов. Один узел упрощает развёртывание и снижает количество точек отказа.
Для контекста: похожие вызовы по оптимизации инференса мы разбирали в материале про запуск DeepSeek-V4-Flash на одном B300, где столкнулись с отказом MoE-ядра без expert parallel.
Если же локальный AI нужен вам не в масштабе Kimi K3, разумнее смотреть на другие конфигурации — например, на разбор локального AI вместо облака на двух RTX 5060 Ti и Mac Studio на 96 ГБ.
Заключение
Kimi K3 устанавливает новую планку требований к памяти для open-weight моделей. 1,4 ТБ весов исключают любые конфигурации с суммарной памятью ниже этого порога. A100 не подходит для практического использования. H200 на двух узлах — рабочий компромисс с оговорками по скорости. B300 с нативным FP4 — оптимальная платформа, обеспечивающая и производительность, и низкую стоимость токена. Приведённые замеры — отправная точка для планирования вашей инфраструктуры. Будущее инференса больших MoE-моделей за нативным 4-битным вычислением, и B300 открывает эту возможность уже сейчас.