Jak samodzielnie hostować model Kimi K3

Wymagania dotyczące samodzielnego hostowania Kimi K3

Samodzielne hostowanie Kimi K3 wymaga zapewnienia miejsca dla 2,8 biliona parametrów. Moonshot opublikował otwarte wagi w formacie MXFP4, co odpowiada około pół bajta na wagę. Same wagi zajmują zatem około 1.4 TB, zanim jeszcze przydzieli się choćby jeden token pamięci podręcznej. Żaden dostępny obecnie w sprzedaży akcelerator nie jest w stanie pomieścić takiej ilości danych samodzielnie. K3 jest modelem wielowęzłowym i w przypadku pojedynczego serwera odpowiedź brzmi: nie.

Taki jest werdykt. Wszystko, co znajduje się poniżej, to obliczenia, które do niego doprowadziły, ponieważ to właśnie one stanowią wiedzę przydatną przy kolejnych wydaniach. Kilku dostawców infrastruktury opublikowało przewodniki wdrożeniowe K3 w tygodniach następujących po ogłoszeniu z 17 lipca 2026 r. i każdy z nich zakładał posiadanie gotowego klastra. Niniejsza strona podchodzi do zagadnienia od drugiej strony: jakie są koszty, co można uruchomić zamiast tego oraz jak rozpoznać, w której z tych dwóch sytuacji się znajdujesz.

Liczba parametrów całkowitych i aktywnych nie jest taka sama

K3 to model typu Mixture of Experts. MoE (mixture of experts) dzieli sieć na wiele podsieci i pozwala routerowi wybrać kilka z nich dla każdego tokena. Karta modelu wskazuje 2.8T parametrów całkowitych i 104B aktywnych na token, przy 896 wyznaczonych ekspertach, z których 16 uruchamia się dla danego tokena, w ramach 93 warstw.

Te dwie liczby parametrów odpowiadają na różne pytania, a ich mylenie jest najczęstszym błędem w każdym wątku typu "czy mogę to uruchomić".

Parametry aktywne określają koszt obliczeniowy. Token jest mnożony przez około 104B parametrów, więc oczekiwana przepustowość przypomina model gęsty 104B, a nie 2.8T. To jest główny powód tworzenia architektury MoE.

Parametry całkowite określają koszt pamięci. Router może wybrać dowolnego eksperta dla dowolnego tokena, więc każdy ekspert musi być załadowany do pamięci przed nadejściem pierwszego żądania. Nie można przechowywać 104B w VRAM i pobierać reszty na żądanie, ponieważ pobieranie musiałoby zakończyć się w mikrosekundach, a magistrala PCIe przesyła dziesiątki gigabajtów na sekundę. Użytkownicy próbują to robić. Strumieniowanie ekspertów z NVMe zmienia model, który powinien generować dziesiątki tokenów na sekundę, w taki, który generuje jeden token co kilka sekund.

Zatem obliczenia są tanie, ale przechowywanie kosztowne. Dobierz sprzęt pod kątem 2.8T. Oczekuj prędkości odpowiedniej dla 104B.

Bajty na wagę i skąd biorą się terabajty

Liczba parametrów pomnożona przez bajty na wagę. To cały wzór dla wag.

[
  {
    "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
  }
]

Model K3 został wytrenowany z uwzględnieniem kwantyzacji i udostępniony z wagami MXFP4 oraz aktywacjami MXFP8, więc wiersz 4-bitowy jest tym właściwym. Wiersze powyżej służą do porównania skali: w formacie bf16 ten sam model wymagałby 5.6 TB. MXFP4 przechowuje również jedną współdzieloną 8-bitową skalę dla każdego bloku 32 wag, co dodaje około 6 procent, więc opublikowane repozytorium zajmuje bliżej 1.5 TB niż równe 1.4 TB.

To zamyka typową drogę ucieczki. „Po prostu go skwantyzuj” tutaj nie pomoże, ponieważ udostępniony punkt kontrolny jest już 4-bitowy. Przejście na 2 bity zmniejszyłoby wagi do 0.7 TB i kosztowałoby utratę dokładności, której nikt dla tego punktu kontrolnego nie mierzył. Nadal byłbyś daleko poza możliwościami pojedynczej karty.

Ilu jednostek GPU wymaga 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
  }
]

Poniższe wartości należy traktować jako minimum, a nie jako cel. Uwzględniają one wyłącznie wagi: bez pamięci podręcznej KV, buforów aktywacji, fragmentacji alokatora oraz miejsca na drugie jednoczesne żądanie. Zakładają również podział równoległy, który dzieli się równo, na co 93 warstwy i 896 ekspertów nie zawsze pozwala.

Opublikowane wytyczne znacznie przewyższają te wartości minimalne. Według stanu na sierpień 2026, Moonshot zaleca superwęzeł składający się z 64 lub więcej akceleratorów, a dokumentacja SGLang zawiera konfigurację H100 zbudowaną z czterech węzłów po 8 GPU, co daje łącznie 32 GPU i 2560 GB pamięci, w porównaniu do minimum wynoszącego 18 kart. Ta różnica nie jest marnotrawstwem. To przestrzeń na pamięć podręczną KV, pamięć aktywacji oraz zapas, który pozwala serwerowi przetwarzać wiele żądań jednocześnie. Nawet najbardziej przystępny wariant, karty klasy 5 GB300, opisuje maszynę, której większość dostawców nie oferuje jako pojedynczej jednostki SKU.

Pamięć podręczna KV jest elementem, który zaskakuje użytkowników

Wagi stanowią koszt stały. Pamięć podręczna KV (key value) nie jest stała: rośnie wraz z długością kontekstu oraz z każdym kolejnym użytkownikiem korzystającym z systemu jednocześnie. Dla standardowego mechanizmu attention wzór to bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element, który następnie mnoży się przez długość kontekstu oraz liczbę jednoczesnych połączeń.

Oto przykład obliczeniowy, który należy traktować wyłącznie poglądowo: 64 warstwy, 8 głowic KV, wymiar głowicy 128, fp8. Daje to 2 64 8 128 1 = 131 072 bajtów, czyli 128 KiB na token.

[
  {
    "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
  }
]

Jeden użytkownik przy kontekście 128k kosztuje 16 GiB. Jeden użytkownik przy pełnym milionie tokenów kosztuje 128 GiB, co dla pojedynczej konwersacji przekracza pojemność dowolnej pojedynczej karty graficznej.

K3 nie używa standardowego mechanizmu attention i to właśnie ta ostatnia liczba wyjaśnia dlaczego. Jego 93 warstwy składają się z 69 warstw KDA (Kimi Delta Attention) oraz 24 warstw Gated MLA (multi-head latent attention). KDA utrzymuje stan rekurencyjny o stałym rozmiarze zamiast pamięci podręcznej rosnącej z każdym tokenem, a MLA kompresuje klucze i wartości do jednego wektora utajonego niskiego rzędu, dzięki czemu rzeczywisty koszt na token jest znacznie niższy niż w powyższym przykładzie. Moonshot nie opublikował wymiarów przestrzeni utajonej, dlatego nie podam wartości na użytkownika dla samego modelu K3. Zamiast tego należy przeprowadzić własne pomiary: uruchomić serwer z małym parametrem --max-model-len, monitorować zużycie pamięci za pomocą nvidia-smi, a następnie zwiększać limit, aż do momentu, gdy alokacja zakończy się niepowodzeniem.

Kształt rozumowania przetrwa kolejne wydanie. Jeśli model deklaruje milion tokenów kontekstu i nie podaje żadnych informacji o architekturze mechanizmu attention, należy przyjąć, że pamięć podręczna jest głównym ograniczeniem, dopóki nie zostanie udowodnione inaczej.

Poziom 1: wynajem klastra na godziny

Jest to jedyny poziom, na którym uruchamiany jest sam K3. Nie kupujesz sprzętu. Wynajmujesz go na potrzebną liczbę godzin, a po zakończeniu pracy zwalniasz zasoby.

[
  {
    "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"
  }
]

Podana stawka jest założeniem, a nie ofertą cenową. Ceny katalogowe akceleratorów w centrach danych w 2026 roku oscylowały w granicach od 2 do 5 USD za godzinę pracy GPU, przy czym rezerwacja pojemności jest tańsza. Należy przyjąć rzeczywistą stawkę dostawcy i ponownie wykonać mnożenie: liczba GPU razy liczba godzin razy stawka. Celem wykresu jest pokazanie proporcji. Uruchomienie węzła z 8 GPU na cztery godziny dziennie kosztuje 2,400 USD miesięcznie, podczas gdy utrzymywanie konfiguracji 32 GPU dla SGLang kosztuje 57,600 USD.

Oba główne serwery publikują polecenie uruchomienia na karcie modelu.

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

Żadne z tych podstawowych poleceń nie jest tym, które uruchamia się na rzeczywistym klastrze. Należy dodać flagi równoległości odpowiadające posiadanemu sprzętowi: SGLang przyjmuje --tp-size dla równoległości tensorowej (tensor parallel) oraz --ep-size dla równoległości eksperckiej (expert parallel), a iloczyn tych wartości musi być równy liczbie faktycznie dostępnych jednostek GPU.

Przed wysłaniem rzeczywistego ruchu należy sprawdzić, czy serwer został poprawnie uruchomiony:

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

Poprawnie działający serwer odpowiada obiektem JSON zawierającym identyfikator modelu. Błąd Connection refused oznacza, że proces nadal ładuje wagi lub już zakończył działanie, dlatego przed ponowną próbą należy sprawdzić dziennik serwera.

Najczęstszą awarią pierwszego dnia jest środowisko uruchomieniowe starsze niż model. K3 został wydany z KDA oraz nową warstwą MoE, których stabilne wersje vLLM i SGLang nie posiadały w momencie premiery. Objawem jest wyjście serwera podczas uruchamiania z komunikatem w formacie Model architectures [...] are not supported for now. Żadna zmiana konfiguracji tego nie naprawi, ponieważ kod obsługujący te warstwy nie znajduje się w używanej kompilacji. Należy zainstalować wersję nightly wskazaną na karcie modelu lub poczekać na wydanie, które zawiera wymagane zmiany.

Uwaga dotycząca kosztów, która często zaskakuje użytkowników: naliczanie opłat rozpoczyna się w momencie uruchomienia instancji, a nie w momencie gotowości modelu. Pobranie 1,5 TB danych z prędkością 1 GB/s zajmuje około 25 minut czasu pracy klastra przed wygenerowaniem pierwszego tokena. Wagi należy przechowywać na wolumenie, który istnieje niezależnie od instancji, dzięki czemu kolejne uruchomienie zajmie tylko kilka minut.

Poziom 2: uruchomienie mniejszego modelu na jednym akceleratorze

Na tym poziomie nie uruchamiasz K3. Powiedz to na głos przed rozpoczęciem, ponieważ większość wątków dotyczących lokalnego uruchamiania K3 kończy się w tym miejscu bez przyznania się do tego faktu.

Zasada dopasowania opiera się na tej samej formule w miniaturze: liczba parametrów pomnożona przez liczbę bajtów na wagę, plus pamięć podręczna KV, plus około 2 GB narzutu środowiska uruchomieniowego, musi mieścić się w dostępnej pamięci VRAM. Przy kwantyzacji 4-bitowej jest to w przybliżeniu pół bajta na parametr, co daje wygodne zestawienia:

• Karta 16 GB: model 7B w 4-bitach z zapasem na długi kontekst
• Karta 24 GB: model 14B w 4-bitach
• Karta 48 GB: model 32B w 4-bitach
• Karta 80 GB: model 70B w 4-bitach lub model klasy 30B typu MoE w 8-bitach

Ollama to najkrótsza droga do działającego serwera na serwerze VPS z podłączonym GPU:

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

ollama run pobiera model przy pierwszym użyciu, a następnie udostępnia wiersz poleceń. Nieistniejący tag zwraca błąd Error: model "..." not found, dlatego należy kopiować tagi ze strony biblioteki, zamiast wpisywać je z pamięci. Pełna instrukcja, obejmująca jednostkę systemd i zdalny dostęp, znajduje się w uruchamianiu Ollama na VPS.

llama.cpp zapewnia większą kontrolę nad kwantyzacją i odciążaniem:

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 wymusza przeniesienie wszystkich warstw na GPU. Należy monitorować dziennik ładowania: wyświetla on informację o liczbie odciążonych warstw. Warstwy, które nie mieszczą się w pamięci GPU i trafiają do pamięci RAM systemu, działają z przepustowością RAM zamiast HBM, co powoduje spadek szybkości generowania o rząd wielkości w momencie, gdy model przestaje się mieścić w całości. Kompromisy między tymi dwoma narzędziami zostały omówione w porównaniu Ollama i llama.cpp.

Poziom 3: hostowane API, orkiestracja we własnym zakresie

[
  {
    "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"
  }
]

Punkt końcowy jest zgodny z OpenAI, więc istniejący klient zadziała po zmianie adresu base 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."}]}'

Poprawny klucz zwraca obiekt JSON z tablicą choices. Błąd 401 oznacza, że klucz jest nieprawidłowy lub brakuje prefiksu Bearer. Błąd typu model-not-found zazwyczaj oznacza zmianę identyfikatora, ponieważ dostawcy wycofują identyfikatory między punktami kontrolnymi.

Teraz próg rentowności, przy założeniu podanej wyżej stawki wynajmu. Działający w trybie ciągłym węzeł z 8 GPU kosztuje 14,400 USD miesięcznie, a przy cenie 15.00 USD za milion tokenów wyjściowych, ta sama kwota pozwala uzyskać około 960 milionów tokenów wyjściowych z API. Aby zyskać na kosztach, należy generować blisko miliard tokenów wyjściowych miesięcznie, czyli około 30 milionów dziennie, i utrzymywać klaster w ciągłym obciążeniu, ponieważ bezczynne jednostki GPU są rozliczane w tej samej stawce co obciążone. Obciążenia typu agentowego z dużą liczbą promptów jeszcze bardziej przesuwają tę granicę: powtarzający się kontekst jest rozliczany według stawki cache-hit wynoszącej 0.30 USD za milion, zamiast stawki cache-miss wynoszącej 3.00 USD.

W tym poziomie we własnym zakresie hostuje się wszystko wokół modelu: bramkę, która przechowuje klucz API, aby nigdy nie trafił on do klienta, logi żądań i odpowiedzi, mechanizmy ponawiania prób, limity szybkości oraz budżety dla poszczególnych użytkowników. Działa to na małym VPS bez żadnego GPU. Ten sam podział dotyczy modeli o zamkniętych wagach, gdzie self-hosting Claude nie jest możliwy na poziomie modelu, a orkiestracja jest jedynym elementem, którym zarządzasz.

Który stos serwowania należy do której warstwy

Serwery klasy vLLM oraz SGLang należą do warstwy 1. Ich zadaniem jest obsługa wielu żądań jednocześnie przy użyciu mechanizmów continuous batching i paged KV cache, a także równoległości tensorowej i eksperckiej rozproszonej na kilka węzłów. Wymagają one akceleratorów klasy centrum danych oraz szybkiego połączenia między nimi. Na pojedynczej karcie konsumenckiej ich instalacja jest bardziej złożona i nie przynosi zauważalnych korzyści.

llama.cpp oraz Ollama należą do warstwy 2. Są one zoptymalizowane pod kątem pojedynczej maszyny, kwantyzacji GGUF, odciążania obliczeń na CPU w przypadku braku miejsca w pamięci VRAM oraz niskiej współbieżności. Technicznie llama.cpp załaduje ogromny model MoE, utrzymując większość warstw w pamięci RAM systemu, jednak dla modelu 2.8T czas generowania jednego tokena liczony jest w sekundach. Potwierdza to jedynie poprawność parsowania pliku. Nie jest to usługa, którą można udostępnić użytkownikom. Pełne porównanie znajduje się w Ollama kontra vLLM i nie zmienia się ono wraz z modelem: kluczowe pytanie zawsze brzmi, czy obsługujesz wielu użytkowników na współdzielonym sprzęcie, czy jednego użytkownika na własnej maszynie.

Cztery liczby, które przetrwają ten punkt kontrolny

1. Iloczyn całkowitej liczby parametrów i liczby bajtów na wagę wyznacza minimalne zapotrzebowanie na pamięć. Żaden proces nie uruchomi się poniżej tej wartości, a techniki kwantyzacji nie zmieniają jej znacząco, gdy wersja jest już 4-bitowa.
2. Aktywne parametry określają klasę przepustowości. Model MoE 2.8T z 104B aktywnych parametrów oblicza się jak model 104B.
3. Pamięć podręczna KV na token, pomnożona przez długość kontekstu i współbieżność, to koszt, który rośnie po opłaceniu wag modelu.
4. Liczba tokenów na sekundę w przeliczeniu na dolara to jedyny wskaźnik określający poziom wydajności. Wszystkie powyższe punkty są danymi wejściowymi dla tego obliczenia.

Zastosuj te cztery zasady do dowolnego wydania, aby uzyskać poprawną odpowiedź przed otwarciem dokumentacji dostawcy. Następnie opatrz datą każdą zapisaną liczbę. Ceny oraz listy wspieranych architektur zmieniły się w ciągu dwóch tygodni od premiery K3, a każda liczba na tej stronie została opublikowana w lipcu 2026.

FAQ

Czy można uruchomić Kimi K3 na pojedynczym GPU?

Nie. Wagi modelu zajmują 1.4 TB przy precyzji MXFP4 dostarczanej przez Moonshot, a największy dostępny w sprzedaży akcelerator posiada 288 GB pamięci. Model typu MoE nie może pobierać nieaktywnych ekspertów z dysku w czasie rzeczywistym, ponieważ router może wybrać dowolnego eksperta dla każdego tokena, a czas dostępu przez PCIe znacznie przekracza budżet czasowy na wygenerowanie tokena. Najmniejsza sensowna konfiguracja K3 to węzeł wieloprocesorowy, a opublikowane instrukcje zakładają użycie co najmniej 32 akceleratorów.

Ile pamięci VRAM wymaga Kimi K3?

Należy przyjąć 1.4 TB wyłącznie na wagi, co odpowiada 18 kartom H100 80GB lub 5 kartom klasy GB300. Do tego należy doliczyć pamięć na KV cache oraz aktywacje. Według stanu na sierpień 2026, Moonshot zaleca użycie 64 lub więcej akceleratorów. Dokumentacja SGLang opisuje konfigurację z 32 GPU H100 i łączną pamięcią 2560 GB, dlatego wartość dla wag należy traktować jako absolutne minimum, a nie docelowe wymaganie.

Czy kwantyzacja pozwala na uruchomienie Kimi K3 na jednym węźle?

Nie w sposób użyteczny. Udostępniony punkt kontrolny jest już skwantyzowany do 4 bitów z wykorzystaniem treningu uwzględniającego kwantyzację, więc łatwe oszczędności zostały już wykorzystane. Dalsza redukcja do 2 bitów zmniejsza rozmiar wag do 0.7 TB, co nadal dwukrotnie przekracza pojemność największej karty, a wpływ 2-bitowej kwantyzacji na dokładność modelu nie został jeszcze zbadany.

Czy wynajmowanie GPU jest tańsze niż korzystanie z API Kimi K3?

Tylko przy dużym i stałym obciążeniu. Przy założeniu kosztu 2.50 USD za godzinę pracy GPU, działający w trybie ciągłym węzeł z 8 GPU kosztuje 14,400 USD miesięcznie. Za tę samą kwotę można uzyskać około 960 milionów tokenów wyjściowych przy opublikowanej stawce 15.00 USD za milion. Należy również uwzględnić koszty przestojów, pobierania wag oraz obsługi technicznej klastra. W przypadku pracy okresowej zaleca się wynajem godzinowy i porównanie kosztów z faktycznym, zmierzonym wolumenem tokenów, zamiast szacunków.

Co oznacza 104B aktywnych parametrów dla szybkości działania?

Oznacza to, że operacje arytmetyczne na token odpowiadają modelowi o rozmiarze 104B, więc przepustowość mieści się w tej klasie, a nie w klasie 2.8T. Nie dotyczy to jednak pamięci: wszystkie 2.8T parametrów muszą być stale załadowane w pamięci, ponieważ router może wywołać dowolnego eksperta dla każdego tokena. Liczbę aktywnych parametrów należy stosować do szacowania liczby tokenów na sekundę, a całkowitą liczbę parametrów do określenia zapotrzebowania na VRAM.