Как запустить Kimi K3 локально: расчеты и требования

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

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

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

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

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

Эти два показателя отвечают на разные вопросы, и их подмена — самая частая ошибка в любых обсуждениях на тему «потянет ли мое оборудование эту модель».

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

Общие параметры определяют требования к памяти. Маршрутизатор может выбрать любого эксперта для любого токена, поэтому все эксперты должны быть загружены в память до поступления первого запроса. Нельзя держать 104B в VRAM и подгружать остальные по требованию, так как загрузка должна завершиться за микросекунды, а шина 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 ТБ. Формат MXFP4 также сохраняет один общий 8-битный масштаб для каждого блока из 32 весов, что добавляет около 6 процентов, поэтому опубликованный репозиторий занимает ближе к 1.5 ТБ, чем к чистым 1.4 ТБ.

Это закрывает стандартный путь для отступления. Фраза «просто квантуйте её» здесь не поможет, так как выпущенный чекпоинт уже является 4-битным. Переход к 2 битам уменьшил бы объем весов до 0.7 ТБ и привел бы к потере точности, которую никто не измерял для данного чекпоинта. Вы все равно значительно выйдете за пределы возможностей любой отдельной карты.

Сколько 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 экспертах.

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

KV-кэш — это то, что удивляет пользователей

Веса модели — это фиксированные затраты. KV-кэш (key-value cache) — нет: он растет вместе с длиной контекста и увеличивается с каждым одновременным пользователем. Для обычного механизма внимания (ordinary 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 не использует обычный механизм внимания, и именно поэтому последнее число так велико. Его 93 слоя состоят из 69 слоев KDA (Kimi Delta Attention) и 24 слоев Gated MLA (multi-head latent attention). KDA поддерживает рекуррентное состояние фиксированного размера вместо кэша, который растет с каждым токеном, а MLA сжимает ключи и значения в один латентный вектор низкого ранга. Благодаря этому реальные затраты на токен значительно ниже, чем в приведенном примере. Moonshot не публиковала латентные размерности, поэтому я не буду указывать конкретные цифры для K3. Вместо этого проведите измерения самостоятельно: запустите сервер с небольшим значением --max-model-len, отслеживайте память с помощью nvidia-smi, а затем повышайте лимит, пока выделение памяти не завершится ошибкой.

Структура рассуждений сохраняется в следующем релизе. Если модель заявляет контекст в миллион токенов и не содержит информации о реализации механизма внимания, исходите из того, что кэш является ограничивающим фактором, пока не доказано обратное.

Уровень 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 года варьировались примерно от 2 до 5 USD за час работы GPU, при этом зарезервированные мощности обходятся дешевле. Возьмите актуальные данные вашего провайдера и пересчитайте стоимость: количество GPU умножить на количество часов и на ставку. Цель этой таблицы — показать соотношение затрат. Запуск узла с 8 GPU на четыре часа в день обойдётся в 2,400 USD в месяц, тогда как постоянно работающая конфигурация SGLang на 32 GPU будет стоить 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 для тензорного параллелизма и --ep-size для параллелизма экспертов, при этом произведение этих значений должно быть равно количеству имеющихся у вас GPU.

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

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

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

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

Важное замечание по расходам: тарификация начинается с момента запуска инстанса, а не с момента готовности модели. Загрузка 1.5 ТБ данных на скорости 1 ГБ/с занимает около 25 минут работы кластера до генерации первого токена. Размещайте веса на томе, который сохраняется после остановки инстанса, чтобы второй запуск занимал считанные минуты.

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

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

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

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

Каждое из приведенных выше сочетаний предполагает обработку одного запроса за раз. Как только второй пользователь отправляет запрос, каждый параллельный слот требует собственный KV-кэш. Именно этот баланс между параллельными слотами, очередью запросов и оставшейся VRAM помогают настроить параметры NUM_PARALLEL и MAX_QUEUE в Ollama.

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

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

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

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

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. Изучите лог загрузки: в нем отображается количество выгруженных слоев. Слои, которые не поместились и были вытеснены в системную 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"
  }
]

Конечная точка совместима с 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 за миллион выходных токенов та же сумма позволяет получить около 960 миллионов выходных токенов через API. Чтобы выиграть в стоимости, необходимо генерировать около миллиарда выходных токенов в месяц (примерно 30 миллионов в день) и поддерживать постоянную загрузку кластера, так как простаивающие GPU оплачиваются по той же ставке, что и работающие. Агентские рабочие нагрузки с большим объемом промптов еще сильнее отдаляют эту границу: повторяющийся контекст оплачивается по ставке попадания в кэш 0.30 USD за миллион, а не по ставке промаха 3.00 USD.

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

К какому уровню относится стек обслуживания

Серверы класса vLLM и SGLang относятся к уровню 1. Они предназначены для одновременной обработки множества запросов с использованием непрерывной пакетной обработки (continuous batching), кэширования KV-блоков (paged KV cache), а также тензорного и экспертного параллелизма, распределенного между несколькими узлами. Они рассчитаны на использование ускорителей уровня дата-центров и высокоскоростных соединений между ними. При установке на одну потребительскую видеокарту они избыточны и не дают заметных преимуществ.

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

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

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

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

FAQ

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

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

Сколько VRAM нужно для Kimi K3?

Начните с 1.4 ТБ только для весов, что соответствует 18 картам H100 80GB или 5 картам класса GB300. К этому значению необходимо добавить память для KV-кэша и активаций. По состоянию на август 2026 года Moonshot рекомендует использовать 64 или более ускорителей. В руководстве SGLang приводится конфигурация на 32 GPU H100 с общим объемом 2560 ГБ, поэтому рассматривайте значение веса модели как нижний предел, а не как итоговое требование.

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

Нет, это нецелесообразно. Выпущенный чекпоинт уже представлен в 4-битном формате с использованием обучения с учетом квантования, поэтому наиболее простые способы оптимизации уже применены. Снижение до 2 бит уменьшит вес до 0.7 ТБ, что все еще более чем в два раза превышает объем памяти самой емкой карты, при этом влияние 2-битного квантования на точность модели не было изучено.

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

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

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

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