Как развернуть Kimi K3 локально?

TL;DR

Kimi K3 — открытые веса, но не «уровень рабочей станции»: для сервинга нативной модели нужны дата-центровые GPU и распределённая память. Используйте vLLM для самого прямого пути в прод, либо SGLang, когда важны топология, параллелизм экспертов и управление кэшем. Сообщественные сборки GGUF снижают порог по «железу», но всё равно требуют порядка 500 GB до существенно более 1 TB адресуемой памяти и обменивают скорость или качество на возможность запуска. Для обычных ПК и Mac сперва тестируйте через хостed API и переходите на self-host только если приватность, устойчивая загрузка или контроль инфраструктуры оправдывают затраты.

What Is Kimi K3?

Kimi K3 — нативная, мультимодальная флагманская модель Moonshot AI с открытыми весами для долгосрочного кодинга, агентной интеллектуальной работы, рассуждений и визуального понимания.

Moonshot описывает её как «первую в мире открытую модель класса 3T». Архитектура сочетает Kimi Delta Attention and Attention Residuals со «разреженным» дизайном MoE, который для каждого токена выбирает лишь подмножество экспертов.

Масштаб необычен даже по меркам «фронтир-моделей». Вместо активации всех 2.8T параметров на каждый токен K3 выбирает 16 из 896 маршрутизируемых экспертов плюс общие эксперты. Это существенно снижает вычисления на токен, хотя все веса модели всё равно должны быть доступны где-то в системе инференса.

Кроме того, с этапа SFT применяется обучение с учётом квантизации, а не исключительно пост-тренировочная компрессия для сервинга в низкой точности.

Архитектура оптимизирована под очень крупномасштабный сервинг — но «разреженные вычисления» не стоит путать с «небольшим объёмом памяти». На каждый токен вычисляется лишь часть сети, однако весь пул экспертов должен быть доступен.

How Does Kimi K3 Perform?

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

Ниже — выборка по рассуждениям, кодингу, агентам и vision. Во всех метриках «выше — лучше».

Официальные результаты помещают Kimi K3 рядом с GPT-5.6 Sol, Claude Fable 5 и Claude Opus 4.8 по задачам рассуждений, кодинга, агентов и зрения. Относитесь к этим результатам как к контексту способностей провайдера, а не универсальному рейтингу; детальный анализ бенчмарков рассмотрен отдельно. Для данного руководства важен операционный вывод: self-hosting даёт возможности класса «фронтир» и контроль над инфраструктурой, но не является дешёвым «настольным» обходным путём.

Can You Actually Run Kimi K3 Locally?

Да, но есть два очень разных определения «локально».

Локальный сервер / частный дата-центр: реалистично.

Обычный десктоп или ноутбук: технически возможно с агрессивно квантованными сообщественными сборками, но в целом непрактично для интерактивной работы.

Текущий рецепт vLLM для Kimi K3 задаёт очень высокий базовый уровень:

• NVIDIA: минимум 8× GB300
• AMD ROCm: минимум 8× MI355X или MI350X
• Драйвер NVIDIA: R580+ для текущего CUDA 13 K3-образа
• Для реального прод-трафика рекомендована мультиузловая инфраструктура

Изначальный day-0 гайд vLLM также демонстрировал быстрый путь на 8-GPU B300 или 8-GPU MI355X. Для нового прод-развёртывания следуйте более свежему рецепту, поскольку он отражает стек сервинга после оптимизаций запуска.

Ключевой момент: K3 — открытые веса, но это не модель масштаба потребительского сегмента.

Official Weights vs Community GGUF Quantizations

Есть другой способ снизить порог аппаратных требований: сообщественная квантизация.

Текущий репозиторий Unsloth K3 предоставляет несколько вариантов GGUF, которые можно запускать через совместимое ПО с llama.cpp.

Сводное сравнение. Значения адресуемой памяти — ориентировочные оценки для планирования (размер загрузки плюс примерно 10–15% запаса на рантайм), не гарантии; контекст, кэш, vision и настройки оффлоуда могут потребовать больше.

Это различие также объясняет, почему некоторые ранние статьи о локальном развёртывании приводят 594 GB: 594 GB теперь соответствуют сообщественной сборке UD-IQ1_S GGUF, а не полезному описанию полного актуального нативного чекпойнта.

Модель на 466–649 GB значительно меньше исходного объёма развёртывания, но всё ещё огромна по меркам рабочих станций. Также оставьте память под состояние рантайма, контекст, кэши, vision-проектор, системные процессы и прочие накладные расходы.

Ёмкость диска — не то же самое, что память инференса. Наличие SSD на 1 TB не означает, что модель 600 GB будет быстро работать на машине с 64 GB RAM. Оффлоуд на SSD может сделать экстремальные эксперименты технически возможными, но генерация токенов может стать мучительно медленной.

How to Deploy Kimi K3 with vLLM

Для серьёзного self-hosting vLLM — самый прямолинейный старт.

Moonshot сейчас указывает vLLM как один из рекомендованных движков инференса для K3, а vLLM предоставляет модель-специфичную поддержку для KDA, MXFP4 MoE, парсинга рассуждений, вызова инструментов, prefix caching и распределённого развёртывания.

Check the prerequisites

Для NVIDIA-продразвёртывания текущий проверенный рецепт использует контейнер vllm/vllm-openai:kimi-k3.

Проверьте GPU:

nvidia-smi

Подтвердите Docker:

docker --version

Убедитесь, что NVIDIA Container Toolkit видит акселераторы:

docker run --rm --gpus all nvidia/cuda:13.0.0-base-ubuntu24.04 nvidia-smi

Если последняя команда не видит все GPU, исправьте рантайм GPU на хосте/в контейнере до загрузки многотерабайтной модели.

Set your Hugging Face token

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

export HF_TOKEN="YOUR_HUGGING_FACE_TOKEN"

Pull the K3 vLLM container

docker pull vllm/vllm-openai:kimi-k3

Текущий рецепт указывает сборку CUDA 13 и драйвер NVIDIA R580 или новее.

Launch Kimi K3

Актуальный стартовый шаблон для Blackwell TP8 (рецепт vLLM обновлён 2026-09-10): используйте это как базу, затем сгенерируйте или измерьте профиль под ваше «железо» и трафик.

docker run --rm \
  --gpus all \
  --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HF_TOKEN="$HF_TOKEN" \
  -e VLLM_USE_V2_MODEL_RUNNER=1 \
  vllm/vllm-openai:kimi-k3 \
  --model moonshotai/Kimi-K3 \
  --tensor-parallel-size 8 \
  --gpu-memory-utilization 0.95 \
  --kv-cache-dtype fp8 \
  --attention-backend TOKENSPEED_MLA \
  --attention-config '{"use_prefill_query_quantization":true,"mla_prefill_backend":"TOKENSPEED_MLA"}' \
  --prefix-match-unit 128 \
  --enable-prefix-caching \
  --max-model-len 131072 \
  --enable-auto-tool-choice \
  --tool-call-parser kimi_k3 \
  --reasoning-parser kimi_k3

Текущий рецепт требует K3-образ с CUDA 13 и драйвер NVIDIA R580+. FP8 KV-кэш должен сочетаться с совместимым MLA prefill/decode-бэкендом; протестируйте альтернативы перед изменением конфигурации attention.

Источник: рецепт vLLM для Kimi K3. Он заменяет более раннюю команду day-0 и выступает как актуальный прод-рецепт.

Для первичной валидации имеет смысл ограничить максимальную длину модели, а не сразу выделять около полного окна в 1,048,576 токенов. Текущий рецепт vLLM явно рекомендует настраивать max-model-len под нагрузку.

Например:

--max-model-len 131072

Это не меняет архитектурный лимит контекста K3. Серверу просто задаётся более управляемая рабочая «оболочка» для первых тестов.

Test the local endpoint

vLLM поднимает OpenAI-совместимый API на порту 8000.

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moonshotai/Kimi-K3",
    "messages": [
      {
        "role": "user",
        "content": "Explain the difference between tensor parallelism and expert parallelism."
      }
    ],
    "max_tokens": 512
  }' 

Или используйте OpenAI Python SDK:

python

from openai import OpenAI

 client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="EMPTY",
    timeout=3600,
 )

response = client.chat.completions.create(
    model="moonshotai/Kimi-K3",
    messages=[
        {
            "role": "user",
            "content": "Write a Python function that validates a JSON schema.",
        }
    ],
    max_tokens=1024,
 )

print(response.choices[0].message.content)

Официальный рецепт vLLM использует тот же OpenAI-совместимый шаблон localhost, что упрощает переключение приложения между локальным и хостed инференсом.

How to Deploy Kimi K3 with SGLang

SGLang — другой основной путь развёртывания, официально рекомендованный Moonshot.

Он особенно актуален, когда нужен более глубокий контроль над распределённым сервингом, параллелизмом экспертов, аппаратно-специфичными ядрами или сложной прод-топологией.

Используйте специализированный Cookbook SGLang для Kimi K3 и выберите топологию под конкретное «железо». Ниже — проверенный однопроцессный профиль 8×B300 Unified/Balanced из cookbook; измерения проведены на SGLang v0.5.18, коммит 71de97b2.

Установите сборку с поддержкой K3:

pip install --upgrade pip
pip install uv
uv pip install --prerelease=allow sglang

Запустите проверенный профиль B300 TP8/DCP8:

sglang serve \
  --trust-remote-code \
  --model-path moonshotai/Kimi-K3 \
  --tp-size 8 \
  --dcp-size 8 \
  --mem-fraction-static 0.85 \
  --mamba-full-memory-ratio <value-from-official-calculator> \
  --reasoning-parser kimi_k3 \
  --tool-call-parser kimi_k3 \
  --host 0.0.0.0 \
  --port 30000

--mamba-full-memory-ratio зависит от нагрузки: рассчитайте его из средней суммы длины входа и выхода в официальном cookbook. Не переносите эту B300-топологию на H100/H200, GB200/GB300, AMD или мультиузлы; для них используются другие схемы TP/PP/DCP/EP.

Проверьте сервер:

curl http://localhost:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moonshotai/Kimi-K3",
    "messages": [{"role": "user", "content": "Give me a five-step debugging plan for a distributed Python application."}]
  }'

Для реального прод-развёртывания подтвердите ёмкость, качество вывода и восстановление после сбоев именно на той версии SGLang, топологии, длине контекста и смеси трафика, которые вы намерены использовать.

vLLM vs SGLang vs llama.cpp

Выбор движка инференса зависит прежде всего от вашего «железа» и цели развёртывания.

Если у вас есть сервер с 8 GPU класса Blackwell/MI35x, начните с vLLM.

Если вы проектируете специализированный кластер распределённого инференса и хотите более низкоуровневые средства управления сервингом, оцените SGLang также.assistant_message

Если ваша цель — лишь «хочу доказать, что K3 выполняется на моём железе», GGUF плюс llama.cpp гораздо более доступны — при условии, что у машины действительно исключительный объём памяти.

How to Run a Quantized Kimi K3 with llama.cpp or Ollama

Сообщественный репозиторий Kimi K3 GGUF теперь предоставляет варианты, совместимые с llama.cpp.

Этот путь существенно снижает входной барьер по сравнению с нативным развёртыванием с открытыми весами в дата-центре, но «существенно» — понятие относительное: даже меньшие сборки — это сотни гигабайт.

Install llama.cpp on macOS or Linux

Текущая карточка модели GGUF предлагает:

curl -LsSf https://llama.app/install.sh | sh

На Windows:

winget install llama.cpp

Start an OpenAI-compatible server

В репозитории сейчас документирован UD-Q4_K_XL как пример:

llama serve \
  -hf unsloth/Kimi-K3-GGUF:UD-Q4_K_XL

Можно запустить и CLI напрямую:

llama cli \
  -hf unsloth/Kimi-K3-GGUF:UD-Q4_K_XL

Эти команды взяты непосредственно из актуальной карточки модели Kimi K3 GGUF.

Однако UD-Q4_K_XL — это примерно 1.51 TB, так что это не тот вариант, с которого начнут большинство пользователей рабочих станций. Если приоритет — снижение требований к памяти, а не максимальная сохранность качества, изучите сначала меньшие 1-bit и 2-bit варианты.

Например:

llama serve \
  -hf unsloth/Kimi-K3-GGUF:UD-IQ1_M

Текущий каталог UD-IQ1_M составляет примерно 649 GB.

Модель на 649 GB — всё ещё не «ноутбучный» масштаб. В идеале часто используемое состояние модели должно находиться в быстрой памяти. Тяжёлый оффлоуд на SSD может сделать экстремальный эксперимент технически возможным, но не обязательно полезным для интерактивной работы.

Run the Same GGUF Build with Ollama

Ollama — удобная обёртка для того же пути развёртывания GGUF, а не четвёртый независимый метод self-hosting.

Репозиторий K3 GGUF также описывает маршрут через Ollama.

Например:

bash

ollama run hf.co/unsloth/Kimi-K3-GGUF:UD-Q4_K_XL

Ollama упрощает управление моделями и работу с API, но не устраняет требования K3 к памяти.

Смена лаунчера с llama.cpp на Ollama не превращает квантизацию на сотни гигабайт в модель на 24 GB VRAM. Подлежащие данные модели всё равно должны храниться и быть доступны.

По этой причине Ollama лучше рассматривать как удобный рантайм-слой, а не как обходной путь по «железу».

Which Kimi K3 Quantization Should You Choose?

Для экспериментов выбор — это в основном компромисс между размером модели и верностью.

Important Kimi K3 Serving Behavior

Есть один специфичный для K3 нюанс реализации, который легко упустить.

K3 использует preserved thinking history. Moonshot говорит, что в многотуровых диалогах и рабочих процессах с вызовом инструментов следует возвращать в модель полное предыдущее сообщение assistant, включая reasoning_content и tool_calls, а не сохранять только видимый контент.

Упрощённый паттерн в приложении выглядит так:

messages = [
    {
        "role": "user",
        "content": "Inspect this project and propose a migration plan.",
    }
 ]

first = client.chat.completions.create(
    model="moonshotai/Kimi-K3",
    messages=messages,
    max_tokens=2048,
 )

assistant_message = first.choices[0].message

 # Preserve the whole message object, not just assistant_message.content.
 messages.append(
    assistant_message.model_dump(exclude_none=True)
 )

messages.append(
    {
        "role": "user",
        "content": "Now identify the riskiest part of that plan.",
    }
 )

second = client.chat.completions.create(
    model="moonshotai/Kimi-K3",
    messages=messages,
    max_tokens=2048,
 )

Это становится особенно важно для кодинговых агентов, инструментальных циклов и длительных автономных сессий.

K3 также поддерживает включённый режим рассуждений и параметры низкой, высокой и максимальной интенсивности рассуждений. Когда ваш слой сервинга раскрывает эти параметры, считайте «усилие рассуждений» ещё одним контролем латентности/качества, а не всегда максимизируйте его для каждого запроса.

How to Optimize a Local Kimi K3 Deployment

Do not allocate the full 1M context immediately

K3 поддерживает 1,048,576 токенов, но максимальные возможности модели и разумная конфигурация сервера — разные вещи.

Для разработки начните с чего-то вроде:

--max-model-len 131072

Затем увеличивайте контекст только после измерения доступной памяти, времени до первого токена, пропускной способности и ожидаемой конкурентности.

Enable prefix caching

Кодинговые агенты часто переиспользуют инструкции репозитория, схемы инструментов, системные промпты и длинные префиксы.

С vLLM:

--enable-prefix-caching

Гибридная архитектура внимания K3 потребовала спецобработки для prefix caching, и vLLM реализовал модель-специфичную поддержку.

Use the K3 parsers

Для агентных нагрузок добавьте:

--tool-call-parser kimi_k3 \
--reasoning-parser kimi_k3

Это держит вызовы инструментов и вывод рассуждений в формате, согласованном с K3.

Keep storage fast

Модель такого масштаба создаёт необычную нагрузку на локальное хранилище при первичной загрузке, чтении чекпойнта, обновлениях и восстановлении.

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

Monitor more than GPU utilization

Отслеживайте:

• Использование HBM/VRAM
• RAM CPU
• коэффициент попадания в кэш
• время до первого токена
• скорость декодирования токенов (tokens/s)
• глубину очереди запросов
• меж-GPU коммуникацию
• межузловую пропускную способность
• сбои парсинга вызовов инструментов
• время загрузки модели

В масштабе K3 «здоровая» загрузка GPU не говорит, эффективна ли топология сервинга.

Local Kimi K3 vs Hosted Kimi K3

Self-hosting даёт командам максимальный контроль над путём данных, рантаймом и весами модели, а также возлагает ответственность за ёмкость GPU, масштабирование, обновления, мониторинг и восстановление. Hosted-доступ снимает большую часть инфраструктурной работы и обычно быстрее для оценки или переменного спроса.

Полный анализ «железа» и точки окупаемости — в статье Kimi K3 Self-Hosting vs API. Для цен на токены, кэширование и сравнения с K2.7 используйте гид по ценам Kimi K3. Это руководство поэтому кратко касается сравнения и сосредоточено на командах, конфигурации и устранении неполадок.

Common Kimi K3 Local Deployment Problems

The model does not fit in GPU memory

Самая предсказуемая проблема.

Не вычисляйте память из 104B активируемых параметров. Эта цифра описывает вычисления на токен, а не объём экспертных весов, который система сервинга должна иметь доступным.

Используйте поддерживаемую распределённую топологию, меньший GGUF-квант или hosted-сервис.

CUDA or NVIDIA driver errors

Текущий образ vLLM для K3 основан на CUDA 13 и требует хост-драйвер R580+.

Если хост остаётся на стеке R575/CUDA 12.9, обновите его или следуйте пути сборки из исходников, описанному vLLM, вместо предположения, что контейнер исправит несовместимость драйвера.

The first request is extremely slow

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

С активами на многотерабайтном уровне «процесс сервера запущен» и «модель готова к прод-трафику» — не эквивалентные состояния.

Tool calls fail intermittently

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

Long conversations become less stable

Убедитесь, что вы возвращаете полное сообщение assistant — включая сведения о рассуждениях и инструментах — в последующие ходы K3.

Отбрасывание скрытых полей состояния рассуждений может нарушить паттерн preserved-thinking-history, к которому K3 обучалась.

So, What Is the Best Way to Deploy Kimi K3 Locally?

Для большинства организаций с подходящим «железом» vLLM — лучший первый путь развёртывания. Он имеет выделенную поддержку K3, OpenAI-совместимый API, модель-специфичные парсеры, prefix caching, поддержку speculative decoding и актуальные рецепты под «железо».

Выбирайте SGLang, когда инженерия распределённого инференса и тонкий контроль сервинга важнее самого короткого пути настройки.

Выбирайте llama.cpp плюс сообщественную квантизацию GGUF только когда ваша цель — эксперимент на рабочей станции/сервере, и вы понимаете, что даже 1-bit версии остаются сотнями гигабайт.

Для типичной рабочей станции разработчика практический вывод иной: не покупайте сотни гигабайт RAM лишь для того, чтобы «впихнуть» K3 на десктоп. Сначала протестируйте Kimi K3 через CometAPI, количественно оцените пользу на ваших задачах и переходите к self-hosting только когда приватность, устойчивая загрузка или контроль инфраструктуры делает экономику оправданной.

FAQ

Can Kimi K3 run on a single consumer GPU?

Не реалистично. Модель значительно превосходит VRAM потребительских GPU. Сообщественные низкобитные кванты GGUF уменьшают «футпринт», но самые маленькие актуальные варианты всё равно — сотни гигабайт.

Can I run Kimi K3 on a Mac?

Экспериментальное выполнение на CPU/Apple Silicon с GGUF и оффлоудом на хранилище в принципе возможно, но интерактивная производительность и объём памяти — ограничивающие факторы. Типичный MacBook не стоит считать практичной платформой для сервинга K3.

Does Kimi K3 support Ollama?

Сообщественные сборки GGUF можно запускать через Ollama. Рантайм упрощает настройку, но не меняет исходных требований к памяти.

Is vLLM or SGLang better for Kimi K3?

vLLM — более простой по умолчанию для нового прод-развёртывания. SGLang привлекателен для команд, строящих сложные топологии распределённого сервинга. Оба — среди рекомендованных Moonshot движков инференса для K3.

How much context does Kimi K3 support?

Официальная спецификация модели поддерживает 1,048,576 токенов. Локальный сервер не обязан раскрывать всё окно контекста; установка меньшего max-model-len может быть практичнее для раннего развёртывания и большей конкурентности.

Is Kimi K3 open source?

Точнее — «open-weight». Moonshot выпустила веса модели под лицензией Kimi K3. Ознакомьтесь с ней напрямую перед коммерческим редистрибьюшеном или другим использованием, где важны условия лицензии.

What is the easiest way to use Kimi K3 without local GPUs?

Hosted API — самый простой путь. Kimi K3 доступна через CometAPI с OpenAI-совместимым интерфейсом chat-completions, так что код приложения может оставаться близким к тому, который вы использовали бы против локального сервера vLLM или SGLang.