Що потрібно для self-hosting Kimi K3

Що потрібно для self-hosting Kimi K3

Self-hosting Kimi K3 означає, що потрібно розмістити 2.8 трильйона параметрів. Moonshot опублікувала open weights у форматі MXFP4. Це приблизно половина байта на вагу, тому самі ваги займають близько 1.4 TB ще до виділення пам’яті для кешу хоча б одного токена. Жоден доступний сьогодні accelerator не вміщує такий обсяг самостійно. K3 — це multi-node модель, тому на одному сервері запустити її не можна.

Це висновок. Нижче наведено арифметику, оскільки саме її можна повторно використати для наступного релізу. Протягом кількох тижнів після анонсу 17 July 2026 кілька інфраструктурних постачальників опублікували посібники з розгортання 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 відсотків. Тому опублікований репозиторій займає ближче до 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, буферів активацій, фрагментації allocator і запасу для другого одночасного запиту. Вони також передбачають паралельний поділ на однакові частини, що не завжди можливо для 93 шарів і 896 експертів.

Опубліковані рекомендації передбачають значно більше ресурсів. Станом на August 2026 Moonshot рекомендує supernode із 64 або більше accelerator, а cookbook для SGLang містить конфігурацію на H100 із чотирьох вузлів по 8 GPU: 32 GPU та 2,560 GB сумарної пам’яті, тоді як мінімум становить 18 карт. Ця різниця не є зайвою. Вона потрібна для KV cache, пам’яті активацій і запасу ресурсів, який дає змогу серверу одночасно обробляти багато запитів у batch. Навіть найсприятливіший рядок, 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, вважайте кеш обмежувальним ресурсом, доки не буде доведено протилежне.

Рівень 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 року ціни на GPU-годину для accelerator-ів у дата-центрах за моделлю on-demand становили приблизно від 2 до 5 USD, а зарезервована потужність коштує дешевше. Візьміть фактичну ціну вашого провайдера й повторіть розрахунок: кількість 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 означає, що процес ще завантажує ваги або вже завершився, тому перед повторною спробою перегляньте журнал сервера.

Найпоширеніша проблема в перший день — 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 накладних витрат runtime, має бути меншою за обсяг 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 завантажує модель під час першого використання, після чого відкриває prompt. Якщо вказати неіснуючий tag, буде повернуто Error: model "..." not found. Тому копіюйте tag зі сторінки бібліотеки, а не вводьте його з пам’яті. Повний посібник, зокрема unit systemd і віддалений доступ, наведено в матеріалі запуск 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. Перевірте журнал завантаження: у ньому вказано, скільки шарів було перенесено. Шари, які не помістилися та опинилися в системній RAM, працюють зі швидкістю RAM, а не HBM. Тому швидкість генерації падає на порядок, щойно модель перестає повністю вміщатися. Відмінності між цими двома інструментами розглянуто в матеріалі Ollama і llama.cpp: порівняння.

Рівень 3: hosted API, self-hosted orchestration

[
  {
    "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 key і не передає його клієнту, журнали запитів і відповідей, повторні спроби, обмеження швидкості та бюджети для окремих користувачів. Це працює на невеликому VPS без GPU. Такий самий поділ застосовується до закритих ваг, де self-hosting Claude на рівні моделі неможливий, а orchestration є єдиною частиною, якою ви керуєте.

Який стек обслуговування належить до якого рівня

Сервери класу vLLM і SGLang належать до рівня 1. Вони призначені для одночасного обслуговування багатьох запитів із continuous batching і paged KV cache, а також із tensor parallelism і expert parallelism, розподіленими між кількома вузлами. Вони розраховані на accelerator-и в дата-центрі та швидке з’єднання між ними. На одній споживчій відеокарті їх складніше встановлювати, а переваги майже непомітні.

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. Тому сприймайте обсяг ваг як мінімальну оцінку, а не як достатню вимогу.

Чи дає quantisation змогу розмістити Kimi K3 на одному вузлі?

Практично ні. Опублікований checkpoint уже має 4-бітне представлення та пройшов quantisation-aware training, тому простий резерв економії вже використано. Повторне зменшення до 2 біт скорочує обсяг ваг до 0.7 TB. Це все одно більш ніж удвічі перевищує обсяг найбільшої карти. Вплив 2-бітного представлення на точність цієї моделі ще не вимірювали.

Чи дешевше орендувати GPU, ніж користуватися API Kimi K3?

Лише за великого та стабільного навантаження. Якщо припустити ціну 2.50 USD за GPU hour, постійно увімкнений вузол із 8 GPU коштує 14,400 USD на місяць. За ті самі кошти можна отримати приблизно 960 мільйонів вихідних токенів за опублікованою ціною 15.00 USD за мільйон. Додатково потрібно оплачувати простоювання, завантаження ваг і роботу спеціаліста, який підтримує кластер у працездатному стані. Для короткочасних пікових навантажень орендуйте GPU погодинно. Порівнюйте витрати з фактичним обсягом токенів, а не з приблизною оцінкою.

Що означає 104B активних параметрів для швидкості?

Це означає, що обсяг обчислень для кожного токена відповідає моделі на 104B параметрів. Тому пропускна здатність буде на рівні цього класу, а не класу 2.8T. На обсяг пам’яті це не впливає: усі 2.8T параметрів залишаються в пам’яті, оскільки маршрутизатор може викликати будь-якого експерта для будь-якого токена. Для оцінювання кількості токенів за секунду використовуйте число активних параметрів. Для визначення обсягу VRAM — загальну кількість параметрів.