Как самостоятельно разместить Kimi K3: требования к VRAM

Что требуется для самостоятельного размещения Kimi K3

Самостоятельное размещение Kimi K3 означает, что нужно найти место для 2.8 триллиона параметров. Moonshot опубликовала открытые веса в формате MXFP4. Это примерно половина байта на один вес, поэтому только веса занимают около 1.4 TB ещё до выделения памяти под единственный токен кэша. Ни один доступный сегодня ускоритель не вмещает такой объём самостоятельно. K3 — многоузловая модель. Поэтому на одном сервере это невозможно.

Таков вывод. Ниже приведены вычисления, лежащие в его основе. Именно эти вычисления можно использовать повторно после следующего выпуска. Через несколько недель после объявления 17 July 2026 несколько поставщиков инфраструктуры опубликовали руководства по развёртыванию K3. В каждом предполагалось, что кластер уже есть. На этой странице рассмотрен обратный вопрос: сколько это стоит, что можно запустить вместо K3 и как определить, какой из этих двух вариантов вам подходит.

Общее число параметров и число активных параметров — не одно и то же

K3 — модель со смесью экспертов. MoE (mixture of experts) разделяет сеть на множество подсетей и позволяет маршрутизатору выбирать несколько из них для каждого токена. В карточке модели указаны 2.8T общих параметров и 104B активированных параметров на токен. В состав модели входят 896 маршрутизируемых экспертов, из которых для каждого токена активируются 16, в 93 слоях.

Эти два значения отвечают на разные вопросы. Подмена одного значения другим — самая распространённая ошибка в обсуждениях о возможности запуска модели.

Активные параметры определяют вычислительную нагрузку. Для одного токена выполняется умножение примерно через 104B параметров. Поэтому ожидаемая пропускная способность будет ближе к показателям плотной модели на 104B параметров, а не модели на 2.8T. В этом и состоит основная причина использования MoE.

Общее число параметров определяет требования к памяти. Маршрутизатор может выбрать любого эксперта для любого токена. Поэтому все эксперты должны находиться в памяти до поступления первого запроса. Нельзя хранить в VRAM только 104B параметров, а остальные загружать по требованию: такая загрузка должна завершаться за микросекунды, тогда как канал PCIe передаёт десятки гигабайт в секунду. Попытки использовать такой подход есть. Потоковая загрузка экспертов с NVMe превращает модель, которая должна выдавать десятки токенов в секунду, в модель, выдающую один токен за несколько секунд.

Таким образом, вычисления выполняются относительно дёшево, а хранение требует значительных ресурсов. Подбирайте аппаратное обеспечение исходя из 2.8T параметров. Ожидаемую скорость оценивайте исходя из 104B параметров.

Байт на один вес и откуда берутся терабайты

Количество параметров умножается на число байт на один вес. Для весов формула полностью сводится к этому.

[
  {
    "label": "bf16",
    "bytes_per_weight": 2,
    "weights_tb": 5.6
  },
  {
    "label": "fp8",
    "bytes_per_weight": 1,
    "weights_tb": 2.8
  },
  {
    "label": "4-bit (MXFP4, as shipped)",
    "bytes_per_weight": 0.5,
    "weights_tb": 1.4
  },
  {
    "label": "2-bit",
    "bytes_per_weight": 0.25,
    "weights_tb": 0.7
  }
]

K3 обучалась с учётом последующей квантизации и выпущена с весами MXFP4 и активациями MXFP8, поэтому строка для 4 бит отражает реальную конфигурацию. Строки выше приведены для масштаба: при использовании bf16 той же модели потребовалось бы 5.6 TB. MXFP4 также хранит один общий 8-битный scale для каждого блока из 32 весов. Это добавляет около 6 процентов, поэтому опубликованный repository занимает скорее 1.5 TB, чем ровно 1.4 TB.

Это исключает обычный способ уменьшить требования. Вариант «просто выполнить квантизацию» здесь не помогает, поскольку опубликованный checkpoint уже использует 4 бита. Переход к 2 битам уменьшил бы объём весов до 0.7 TB, но привёл бы к потере точности, которая для этого checkpoint не измерялась. Даже после этого требования всё равно намного превышали бы возможности любой одной карты.

Сколько GPU требуется Kimi K3

[
  {
    "config": "H100 80GB",
    "hbm_per_gpu_gb": 80,
    "gpus_for_weights": 18
  },
  {
    "config": "H200 141GB",
    "hbm_per_gpu_gb": 141,
    "gpus_for_weights": 10
  },
  {
    "config": "B200 192GB",
    "hbm_per_gpu_gb": 192,
    "gpus_for_weights": 8
  },
  {
    "config": "GB300 288GB",
    "hbm_per_gpu_gb": 288,
    "gpus_for_weights": 5
  }
]

Считайте эти значения минимальным порогом, а не целевой конфигурацией. Они учитывают только веса модели: без KV cache, буферов активаций, фрагментации памяти аллокатора и запаса для второго параллельного запроса. Кроме того, предполагается равномерное распределение модели между устройствами, что не всегда возможно для 93 слоёв и 896 экспертов.

Опубликованные рекомендации предусматривают значительно больше ресурсов. По состоянию на August 2026 Moonshot рекомендует supernode как минимум с 64 ускорителями, а SGLang cookbook содержит конфигурацию для H100 из четырёх узлов по 8 GPU: всего 32 GPU и 2,560 GB общей памяти. Для сравнения, минимальный порог составляет 18 карт. Эта разница не является избыточной. Она необходима для KV cache, памяти активаций и запаса, который позволяет серверу одновременно обрабатывать множество запросов. Даже наиболее выгодный вариант — 5 карт класса GB300 — описывает машину, которую большинство провайдеров не предлагает как единый SKU.

KV-кэш — это часть, которая часто становится неожиданностью

Веса требуют фиксированного объёма памяти. KV-кэш (key-value cache) таким не является: он растёт вместе с длиной контекста и увеличивается с каждым параллельным пользователем. Для обычного attention формула имеет вид bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element. Затем результат нужно умножить на длину контекста и количество параллельных пользователей.

Ниже приведён расчёт только для примера: 64 слоя, 8 KV-голов, размерность головы 128, fp8. Получается 2 64 8 128 1 = 131,072 байта, то есть 128 KiB на токен.

[
  {
    "label": "8k context",
    "kv_gib_per_user": 1
  },
  {
    "label": "32k context",
    "kv_gib_per_user": 4
  },
  {
    "label": "128k context",
    "kv_gib_per_user": 16
  },
  {
    "label": "1M context",
    "kv_gib_per_user": 128
  }
]

Один пользователь с контекстом 128k занимает 16 GiB. Один пользователь с максимальным контекстом в миллион токенов занимает 128 GiB. Это больше, чем вмещает любая отдельная карта, даже для одного диалога.

K3 не использует обычный attention. Именно поэтому последний показатель неприменим к нему напрямую. В его составе 93 слоя: 69 слоёв KDA (Kimi Delta Attention) и 24 слоя Gated MLA (multi-head latent attention). KDA использует рекуррентное состояние фиксированного размера вместо кэша, который растёт с каждым токеном. MLA сжимает key и value в один латентный вектор низкого ранга. Поэтому фактический расход на токен значительно ниже приведённого примера. Moonshot не опубликовала размеры латентных представлений, поэтому я не буду приводить значение на одного пользователя для самого K3. Измерьте его самостоятельно: запустите сервер с небольшим значением --max-model-len, отслеживайте память с помощью nvidia-smi, затем повышайте лимит, пока выделение памяти не завершится ошибкой.

Принцип расчёта сохраняется и для следующего релиза. Если модель заявляет контекст в миллион токенов, но ничего не сообщает об архитектуре attention, считайте KV-кэш ограничивающим ресурсом, пока не доказано обратное.

Уровень 1: аренда кластера с почасовой оплатой

Это единственный уровень, на котором запускается сам K3. Покупать оборудование не нужно. Вы арендуете его на необходимое количество часов, а затем останавливаете.

[
  {
    "label": "1 GPU, always on",
    "gpu_hours": 720,
    "usd_cost": "1,800"
  },
  {
    "label": "8 GPUs, 4 hours a day",
    "gpu_hours": 960,
    "usd_cost": "2,400"
  },
  {
    "label": "8 GPUs, always on",
    "gpu_hours": 5760,
    "usd_cost": "14,400"
  },
  {
    "label": "32 GPUs, always on",
    "gpu_hours": 23040,
    "usd_cost": "57,600"
  }
]

Указанная ставка является допущением, а не коммерческим предложением. В течение 2026 on-demand цены на accelerator в дата-центрах составляли примерно от 2 до 5 USD за GPU-час, а резервируемая ёмкость обходится дешевле. Возьмите фактическую ставку вашего провайдера и пересчитайте сумму: количество GPU × часы × ставка. На графике показано соотношение. Запуск узла с 8 GPU на четыре часа в день стоит 2,400 USD в месяц, а постоянная работа конфигурации на 32 GPU, рассчитанной для SGLang, стоит 57,600 USD.

Оба основных сервера публикуют команду запуска на странице модели.

pip install vllm
vllm serve "moonshotai/Kimi-K3"

pip install sglang
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K3" --host 0.0.0.0 --port 30000

В реальном кластере недостаточно выполнить эти команды без изменений. Добавьте флаги параллелизма в соответствии с вашим оборудованием: SGLang использует --tp-size для tensor parallel и --ep-size для expert parallel. Произведение этих значений должно быть равно фактическому количеству GPU.

Перед отправкой реального трафика убедитесь, что сервер запустился:

curl http://127.0.0.1:30000/v1/models

Работающий сервер возвращает JSON-объект со списком идентификаторов моделей. Connection refused означает, что процесс ещё загружает веса или уже завершился. Перед новой попыткой просмотрите log сервера.

В первый день чаще всего оказывается, что runtime старше модели. K3 поставлялся с KDA и новым MoE-слоем, которых не было в стабильных версиях vLLM и SGLang на момент запуска. Симптомом является завершение сервера во время запуска со строкой вида Model architectures [...] are not supported for now. Изменение конфигурации не устранит эту проблему, потому что в вашей сборке отсутствует код для выполнения этих слоёв. Установите nightly-версию, указанную на странице модели, или дождитесь выпуска версии с её поддержкой.

Есть ещё одна особенность тарификации. Отсчёт начинается при запуске инстанса, а не после готовности модели. Загрузка 1.5 TB со скоростью 1 GB/s занимает около 25 минут работы кластера до появления первого токена. Сохраните веса на volume, который продолжает существовать после остановки инстанса. Тогда при следующем запуске сервер начнёт работу через несколько минут.

Уровень 2: запустите меньшую модель на одном ускорителе

На этом уровне K3 не запускается. Сразу зафиксируйте это, прежде чем начинать: большинство обсуждений о локальном запуске K3 заканчиваются на этом этапе, но обычно этого не признают.

Правило совместимости здесь такое же, только в уменьшенном масштабе: количество параметров, умноженное на число байт на один вес, плюс KV cache и примерно 2 GB накладных расходов среды выполнения должны помещаться в доступный объём VRAM. В режиме 4-bit это примерно полбайта на параметр. Поэтому обычно подходят такие варианты:

• карта на 16 GB: модель 7B в режиме 4-bit с запасом для длинного контекста
• карта на 24 GB: модель 14B в режиме 4-bit
• карта на 48 GB: модель 32B в режиме 4-bit
• карта на 80 GB: модель 70B в режиме 4-bit или MoE класса 30B в режиме 8-bit

Ollama — самый короткий путь к рабочему серверу на VPS с подключённым GPU:

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14b

ollama run загружает модель при первом использовании, после чего открывает приглашение командной строки. Если указанного тега не существует, возвращается Error: model "..." not found. Поэтому копируйте теги со страницы библиотеки, а не вводите их по памяти. Полное руководство, включая systemd unit и удалённый доступ, приведено в разделе запуск Ollama на VPS.

llama.cpp предоставляет больше возможностей для управления quantisation и offload:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

./build/bin/llama-server -m model.gguf -c 8192 -ngl 99 --host 0.0.0.0 --port 8080

-ngl 99 запрашивает размещение всех слоёв на GPU. Проверьте load log: в нём указано, сколько слоёв было выгружено. Слои, которые не помещаются и переносятся в system RAM, работают со скоростью RAM, а не HBM. Поэтому скорость генерации падает на порядок, как только модель перестаёт полностью помещаться. Компромиссы между этими двумя инструментами рассмотрены в разделе Ollama и llama.cpp: сравнение бок о бок.

Уровень 3: размещаемый API, самостоятельная оркестрация

[
  {
    "label": "Input, cache hit",
    "usd_per_million_tokens": "0.30"
  },
  {
    "label": "Input, cache miss",
    "usd_per_million_tokens": "3.00"
  },
  {
    "label": "Output",
    "usd_per_million_tokens": "15.00"
  }
]

Endpoint совместим с OpenAI, поэтому существующий клиент заработает после изменения базового URL.

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "Say hello."}]}'

Рабочий ключ возвращает JSON-объект с массивом choices. Ошибка 401 означает, что ключ указан неправильно или отсутствует префикс Bearer. Ошибка отсутствия модели обычно означает, что идентификатор изменился: провайдеры выводят идентификаторы из использования между контрольными точками.

Теперь рассчитаем точку безубыточности, используя указанную выше арендную ставку. Узел с 8 GPU, работающий постоянно, стоит 14,400 USD в месяц. При цене 15.00 USD за миллион выходных токенов за те же деньги через API можно получить около 960 миллионов выходных токенов. Чтобы снизить затраты, нужно генерировать почти миллиард выходных токенов в месяц, то есть примерно 30 миллионов в день, и постоянно загружать кластер. Неиспользуемые GPU тарифицируются по той же ставке, что и загруженные. В агентских сценариях с большим объёмом промптов разрыв ещё больше: повторно передаваемый контекст тарифицируется по ставке 0.30 USD за миллион при попадании в кэш, а не по ставке 3.00 USD при промахе кэша.

На этом уровне самостоятельно размещаются все компоненты вокруг модели: gateway, который хранит API-ключ и не передаёт его клиенту, журналы запросов и ответов, повторные попытки, ограничения скорости и бюджеты для отдельных пользователей. Всё это работает на небольшом VPS без GPU. То же разделение действует для закрытых весов: самостоятельное размещение Claude на уровне модели невозможно, поэтому вы управляете только оркестрацией.

Какой стек инференса относится к какому уровню

Серверы класса vLLM и SGLang относятся к уровню 1. Они предназначены для одновременной обработки большого числа запросов с непрерывной пакетной обработкой и страничным KV-кэшем, а также для распределения tensor parallelism и expert parallelism между несколькими узлами. Они рассчитаны на ускорители в дата-центрах и высокоскоростное соединение между ними. На одной потребительской видеокарте их сложнее устанавливать, а заметных преимуществ вы почти не получите.

llama.cpp и Ollama относятся к уровню 2. Они рассчитаны на одну машину, квантование GGUF, выгрузку вычислений на CPU, если модель не помещается, и низкий уровень параллелизма. llama.cpp технически загрузит огромную MoE-модель, оставив большую часть слоёв в системной RAM, но для модели размером 2.8T такой режим даёт скорость в несколько секунд на токен. Это подтверждает, что файл разбирается. Но такой процесс нельзя использовать как сервис для пользователей. Полное сравнение приведено в разделе Ollama против vLLM, и размер модели ничего не меняет: вопрос всегда сводится к тому, обслуживаете ли вы многих пользователей на общей аппаратной платформе или одного пользователя на собственной машине.

Четыре числа, которые остаются актуальными после этой проверки

1. Общее число параметров, умноженное на количество байт на один вес, задаёт минимальный объём памяти. Ниже этого значения модель не запустится. При переходе на 4-bit квантование этот предел уже почти не меняется.
2. Активные параметры определяют класс производительности. MoE-модель с 2.8T параметров и 104B активных параметров выполняет вычисления как модель с 104B параметров.
3. Объём KV cache на один токен, умноженный на длину контекста и число параллельных запросов, определяет затраты, которые продолжают расти после загрузки весов в память.
4. Число токенов в секунду на доллар — единственный показатель, по которому выбирают тарифный уровень. Все остальные показатели являются входными данными для него.

Примените эти четыре показателя к любому релизу, и получите правильный ответ ещё до того, как откроете руководство поставщика. Затем указывайте дату для каждой записанной цифры. Цены и списки поддерживаемых архитектур изменились в течение двух недель после выпуска K3. Все числа на этой странице опубликованы в July 2026.

FAQ

Можно ли запустить Kimi K3 на одном GPU?

Нет. Объём весов составляет примерно 1.4 TB при точности MXFP4, с которой Moonshot выпускает модель, а крупнейший доступный в продаже ускоритель вмещает 288 GB. MoE-модель не может передавать неактивных экспертов с диска с приемлемой скоростью: маршрутизатор может выбрать любого эксперта для любого токена, а чтение по PCIe занимает гораздо больше времени, чем допускает бюджет обработки токена. Минимальная практически оправданная конфигурация K3 — узел с несколькими GPU. В опубликованных конфигурациях используется 32 ускорителя или больше.

Сколько VRAM требуется Kimi K3?

Только на веса потребуется 1.4 TB. Это соответствует 18 картам H100 80GB или 5 картам класса GB300. Дополнительно потребуется память для KV cache и активаций. По состоянию на August 2026 Moonshot рекомендует использовать 64 ускорителя или больше. В cookbook для SGLang опубликована конфигурация на 32 GPU H100 с совокупным объёмом 2,560 GB. Поэтому считайте объём весов минимальной оценкой, а не достаточным требованием.

Позволяет ли квантование разместить Kimi K3 на одном узле?

Практически нет. Выпущенный checkpoint уже использует 4-битное представление и quantisation-aware training, поэтому основной простой способ сэкономить память уже применён. При дополнительном снижении до 2 бит объём весов составит 0.7 TB. Это всё ещё более чем вдвое превышает объём памяти крупнейшей карты. Влияние 2-битного представления на точность этой модели не измерялось.

Дешевле ли арендовать GPU, чем использовать API Kimi K3?

Только при большом и стабильном объёме запросов. Если принять стоимость 2.50 USD за час работы одного GPU, постоянно включённый узел с 8 GPU обойдётся в 14,400 USD в месяц. За те же деньги можно получить примерно 960 миллионов выходных токенов по опубликованной цене 15.00 USD за миллион токенов. Кроме того, придётся оплачивать простой, загрузку весов и работу специалиста, который поддерживает кластер в рабочем состоянии. Для кратковременных пиков арендуйте GPU почасово. Сравнивайте затраты с фактически измеренным объёмом токенов, а не с предположительной оценкой.

Что означает 104B активных параметров с точки зрения скорости?

Это означает, что вычислительная нагрузка на токен соответствует модели с 104B параметров. Поэтому пропускная способность будет соответствовать этому классу, а не классу 2.8T. На объём памяти это не влияет: все 2.8T параметров остаются в памяти, поскольку маршрутизатор может вызвать любого эксперта для любого токена. Используйте число активных параметров для оценки количества токенов в секунду, а общее число параметров — для расчёта требуемого объёма VRAM.