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

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

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

Це висновок. Нижче наведено арифметику, яка до нього приводить. Саме цю арифметику можна повторно використовувати для наступного релізу. Через кілька тижнів після анонсу 17 July 2026 кілька infrastructure vendors опублікували посібники з розгортання K3. Усі вони передбачали, що у вас уже є cluster. Ця сторінка починається з іншого боку: скільки це коштує, що можна запустити натомість і як визначити, до якого з цих двох варіантів ви належите.

Загальна кількість параметрів і кількість активних параметрів — не одне й те саме

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-бітну шкалу для кожного блоку з 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, буферів активацій, фрагментації пам’яті алокатора та запасу для другого паралельного запиту. Крім того, вони передбачають рівномірний розподіл між пристроями, який не завжди можливий для 93 шарів і 896 експертів.

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

Кеш KV — це частина, яка зазвичай дивує

Ваги — це фіксована вартість. Кеш KV (key value) — ні: він зростає разом із довжиною контексту та збільшується з кожним одночасним користувачем. Для звичайної уваги формула має вигляд 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 стискає key і value в один латентний вектор низького рангу. Тому фактична вартість на токен значно нижча, ніж у наведеному розрахунку. 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 погодинні ціни на accelerator для дата-центрів за моделлю on-demand становили приблизно від 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 означає, що процес ще завантажує ваги або вже завершив роботу, тому перед повторною спробою перегляньте журнал сервера.

Поширена проблема в перший день — runtime, старіший за модель. K3 постачався з KDA та новим шаром MoE, яких на момент запуску не було у стабільних релізах vLLM і SGLang. Ознака проблеми — завершення роботи сервера під час запуску з рядком формату Model architectures [...] are not supported for now. Зміна конфігурації не допоможе, оскільки у вашій збірці немає коду для виконання цих шарів. Встановіть nightly-версію, зазначену на сторінці моделі, або дочекайтеся релізу, який її підтримує.

Є ще одна важлива особливість розрахунку вартості. Облік починається під час запуску інстансу, а не після готовності моделі. Завантаження 1.5 TB зі швидкістю 1 GB/s займає приблизно 25 хвилин кластерного часу до появи першого токена. Збережіть ваги на томі, який не видаляється після зупинки інстансу. Тоді під час наступного запуску сервер буде готовий за кілька хвилин.

Рівень 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

Кожне наведене вище поєднання передбачає один запит за раз. Щойно друга людина надсилає prompt, для кожного паралельного слоту потрібен власний KV cache. Саме це є компромісом, який параметри NUM_PARALLEL і MAX_QUEUE в Ollama дають змогу налаштувати між паралельними слотами, запитами в черзі та доступним VRAM.

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 вимагає розмістити кожен layer на GPU. Перевірте load log: у ньому зазначено, скільки layer було offload. Layer, які не помістилися і перейшли до системної 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. Помилка про відсутню модель зазвичай означає, що id змінився, оскільки провайдери виводять id з експлуатації між checkpoint.

Тепер визначимо точку беззбитковості, використовуючи припущену вище вартість оренди. Вузол із 8 GPU, який працює постійно, коштує 14,400 USD на місяць, а за ціною 15.00 USD за мільйон вихідних токенів за ті самі кошти через API можна отримати приблизно 960 мільйонів вихідних токенів. Щоб self-hosting був вигіднішим за вартістю, потрібно генерувати майже мільярд вихідних токенів на місяць, тобто приблизно 30 мільйонів на день, і весь цей час повністю завантажувати кластер, оскільки за простою GPU стягується така сама плата, як і за роботу. Для агентних навантажень із великим обсягом prompt ця межа віддаляється ще більше: повторне надсилання контексту оплачується за ставкою 0.30 USD за мільйон за cache hit, а не за ставкою 3.00 USD за cache miss.

На цьому рівні ви self-hosted усе, що оточує модель: gateway, який зберігає API key і не передає його клієнту, журнали запитів і відповідей, повторні спроби, обмеження швидкості та бюджети для окремих користувачів. Це працює на невеликому VPS без GPU. Такий самий розподіл застосовується до закритих ваг, де self-hosting Claude на рівні моделі неможливий, а orchestration — єдина частина, яку ви контролюєте.

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

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

llama.cpp і Ollama належать до рівня 2. Вони розраховані на одну машину, квантування GGUF, вивантаження обчислень на CPU, якщо модель не вміщується, і низьку concurrency. 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, а найбільший доступний у продажу окремий accelerator має 288 GB. MoE-модель не може передавати неактивні experts із диска з придатною для роботи швидкістю, оскільки router може вибрати будь-який expert для будь-якого token, а отримання даних через PCIe триває набагато довше, ніж дозволяє бюджет часу на token. Найменша практична конфігурація K3 — вузол із кількома GPU. Опубліковані рецепти використовують 32 accelerators або більше.

Скільки VRAM потрібно Kimi K3?

Почніть із 1.4 TB лише для weights. Це відповідає 18 картам H100 80GB або 5 картам класу GB300. Додатково потрібна пам’ять для KV cache та activations. Станом на August 2026 Moonshot рекомендує 64 accelerators або більше, а cookbook для SGLang містить конфігурацію на 32 GPU H100 із загальним обсягом 2,560 GB. Тому сприймайте обсяг weights як мінімальну оцінку, а не як готову вимогу до конфігурації.

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

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

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

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

Що означають 104B active parameters з погляду швидкодії?

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