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ę, więc same wagi zajmują w przybliżeniu 1.4 TB, zanim jeszcze przydzielisz choćby jeden token pamięci podręcznej. Żaden akcelerator dostępny obecnie w sprzedaży nie 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 poniżej to obliczenia, które za nim stoją, ponieważ to właśnie obliczenia są elementem, który wykorzystasz ponownie przy kolejnym wydaniu. Kilku dostawców infrastruktury opublikowało przewodniki wdrażania K3 w tygodniach po ogłoszeniu z 17 lipca 2026 roku i każdy z nich zakładał, że posiadasz już klaster. Ta strona zaczyna od drugiej strony: ile to kosztuje, co można uruchomić w zamian 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 oraz 104B parametrów aktywnych na token, przy 896 ekspertach routowanych, z których 16 jest uruchamianych dla danego tokena w ramach 93 warstw.

Te dwie wartości parametrów odpowiadają na różne pytania, a ich mylenie jest najczęstszym błędem w każdym wątku dotyczącym wymagań sprzętowych.

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ęciowy. Router może wybrać dowolnego eksperta dla dowolnego tokena, więc każdy ekspert musi znajdować się w 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 jest kosztowne. Dobieraj sprzęt pod kątem 2.8T. Oczekuj prędkości działania 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: w formacie bf16 ten sam model wymagałby 5.6 TB. MXFP4 przechowuje również jeden współdzielony 8-bitowy skaler 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 skwantuj” tutaj nie pomoże, ponieważ udostępniony punkt kontrolny jest już 4-bitowy. Przejście na 2 bity zmniejszyłoby wagę do 0.7 TB i kosztowałoby utratę dokładności, której nikt dla tego punktu kontrolnego nie mierzył. Nadal znajdowałbyś się daleko poza możliwościami pojedynczej karty.

Ilu procesorów 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
  }
]

Wartości te należy traktować jako minimum, a nie jako cel. Uwzględniają one wyłącznie wagi: nie obejmują pamięci podręcznej KV, buforów aktywacji, fragmentacji alokatora ani 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 pozwalają.

Opublikowane wytyczne znacznie przewyższają te wartości minimalne. Według stanu na sierpień 2026 r. 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 8-GPU, łącznie 32 procesorów GPU i 2560 GB pamięci zbiorczej, w porównaniu do minimum wynoszącego 18 kart. Ta różnica nie jest marnotrawstwem. To pamięć podręczna KV, pamięć aktywacji oraz zapas, który pozwala serwerowi przetwarzać wiele żądań jednocześnie. Nawet najbardziej przystępny wariant, 5 kart klasy GB300, opisuje maszynę, której większość dostawców nie oferuje jako pojedynczej jednostki SKU.

Pamięć podręczna KV jest elementem zaskakującym

Wagi stanowią koszt stały. Pamięć podręczna KV (key value) nie: rośnie ona 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 należy pomnożyć przez długość kontekstu oraz liczbę jednoczesnych połączeń.

Oto przykład obliczeniowy, który ma charakter wyłącznie poglądowy: 64 warstwy, 8 głowic KV, wymiar głowicy 128, format 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 w przypadku pojedynczej konwersacji przekracza pojemność każdej dostępnej karty graficznej.

Model K3 nie korzysta ze 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 stały rozmiar stanu rekurencyjnego zamiast pamięci podręcznej rosnącej z każdym tokenem, a MLA kompresuje klucze i wartości do jednego wektora ukrytego niskiego rzędu. Dzięki temu rzeczywisty koszt na token jest znacznie niższy niż w przedstawionym przykładzie. Moonshot nie opublikował wymiarów przestrzeni ukrytej, dlatego nie podam wartości na użytkownika dla samego modelu K3. Należy przeprowadzić własne pomiary: uruchomić serwer z małym parametrem --max-model-len, monitorować pamięć za pomocą nvidia-smi, a następnie zwiększać limit, aż do momentu niepowodzenia alokacji.

Charakterystyka rozumowania pozostanie aktualna w kolejnym wydaniu. Jeśli model deklaruje milion tokenów kontekstu i nie podaje 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"
  }
]

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 o rozmiarze 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 oraz --ep-size dla równoległości eksperckiej, a iloczyn tych wartości musi być równy liczbie faktycznie posiadanych jednostek GPU.

Przed wysłaniem rzeczywistego ruchu sprawdź, czy serwer został uruchomiony:

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

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

Najczęstszym błędem pierwszego dnia jest środowisko uruchomieniowe starsze niż model. K3 został wydany z KDA i nową warstwą MoE, których stabilne wersje vLLM i SGLang nie zawierał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. Zainstaluj wersję nightly wskazaną na karcie modelu lub poczekaj na wydanie, które ją zawiera.

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. Przechowuj wagi na wolumenie, który istnieje niezależnie od instancji, aby drugie uruchomienie trwało tylko kilka minut.

Poziom 2: uruchomienie mniejszego modelu na jednym akceleratorze

Na tym poziomie nie uruchamia się K3. Należy to wyraźnie zaznaczyć 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 mniejszej skali: 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 pozwala na następujące wygodne konfiguracje:

• 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 MoE 30B w 8-bitach

Każde z powyższych zestawień zakłada obsługę jednego żądania w danym czasie. W momencie, gdy druga osoba wysyła zapytanie, każdy równoległy slot wymaga własnej pamięci podręcznej KV. Jest to kompromis, który ustawienia NUM_PARALLEL oraz MAX_QUEUE w Ollama realizują w zakresie równoległych slotów, kolejkowania żądań oraz pozostałej dostępnej pamięci VRAM.

Ollama to najkrótsza droga do uruchomienia 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 oraz zdalny dostęp, znajduje się w sekcji uruchamianie Ollama na VPS.

llama.cpp zapewnia większą kontrolę nad kwantyzacją i odciążaniem (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 wymusza przeniesienie wszystkich warstw na GPU. Należy monitorować dziennik ładowania: wyświetla on liczbę warstw, które zostały przeniesione do pamięci karty. Warstwy, które nie mieszczą się w VRAM i trafiają do pamięci systemowej RAM, korzystają z przepustowości RAM zamiast HBM, co powoduje spadek prędkości generowania o rząd wielkości w momencie, gdy model przestaje się mieścić w pamięci karty. Porównanie kompromisów między tymi dwoma narzędziami znajduje się w artykule Ollama i llama.cpp – porównanie.

Poziom 3: hostowane API, własna orkiestracja

[
  {
    "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 bazowego adresu 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 pomiędzy punktami kontrolnymi.

Teraz próg rentowności, przy założeniu powyższej stawki wynajmu. Węzeł z 8 GPU działający w trybie ciągłym 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 GPU są rozliczane w tej samej stawce co pracujące. Obciążenia agentowe z dużą ilością promptów jeszcze bardziej przesuwają tę granicę: powtarzający się kontekst jest rozliczany według stawki trafień w pamięć podręczną wynoszącej 0.30 USD za milion, zamiast stawki za brak trafienia wynoszącej 3.00 USD.

W tym poziomie samodzielnie hostuje się wszystko wokół modelu: bramkę, która przechowuje klucz API tak, aby nigdy nie dotarł do klienta, logi żądań i odpowiedzi, ponawianie 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 wag zamkniętych, gdzie samodzielne hostowanie Claude nie jest możliwe na poziomie modelu i orkiestracja jest jedynym elementem, który pozostaje pod kontrolą użytkownika.

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 zrównoleglenia tensorowego i eksperckiego rozproszonego na wiele 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, a zysk wydajnościowy – znikomy.

llama.cpp oraz Ollama należą do warstwy 2. Są one przeznaczone dla pojedynczej maszyny, wykorzystują kwantyzację GGUF, odciążanie obliczeń do CPU w przypadku braku miejsca w pamięci VRAM oraz charakteryzują się niską 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 będzie liczony w sekundach. Potwierdza to jedynie poprawność parsowania pliku. Nie jest to rozwiązanie gotowe do udostępnienia użytkownikom. Pełne porównanie znajduje się w Ollama kontra vLLM i nie zmienia się ono wraz z modelem: kluczowe pytanie zawsze dotyczy tego, czy serwujesz 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 bajtów na wagę wyznacza minimalne zapotrzebowanie na pamięć. Żaden proces nie uruchomi się poniżej tego progu, a techniki kwantyzacji nie zmieniają tego znacząco, gdy wydanie jest już w formacie 4-bit.
2. Liczba aktywnych parametrów określa klasę przepustowości. Model MoE 2.8T ze 104B aktywnych parametrów obliczeniowo odpowiada modelowi 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 pozwalający wybrać poziom wydajności. Wszystkie powyższe parametry są danymi wejściowymi dla tego wyliczenia.

Zastosowanie tych czterech zasad do dowolnego wydania pozwala uzyskać właściwą odpowiedź przed otwarciem dokumentacji dostawcy. Każdej zapisanej wartości należy przypisać datę. Ceny oraz listy wspieranych architektur zmieniły się w ciągu dwóch tygodni od premiery K3, a wszystkie liczby na tej stronie zostały opublikowane w lipcu 2026.

FAQ

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

Nie. Wagi zajmują około 1.4 TB przy precyzji MXFP4, w której Moonshot udostępnia model, a największy dostępny w sprzedaży akcelerator mieści 288 GB. 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 operacja fetch przez PCIe trwa znacznie dłużej, niż pozwala na to budżet czasowy tokena. Najmniejsza sensowna konfiguracja K3 to węzeł wieloprocesorowy, a opublikowane przepisy wymagają użycia co najmniej 32 akceleratorów.

Ile pamięci VRAM wymaga Kimi K3?

Należy przyjąć bazowo 1.4 TB tylko na same 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 64 lub więcej akceleratorów, a dokumentacja SGLang opisuje konfigurację z 32 GPU H100 o łącznej pojemności 2560 GB, dlatego wartość dla wag należy traktować jako minimum, a nie jako pełne wymaganie.

Czy kwantyzacja pozwala zmieścić Kimi K3 w jednym węźle?

Nie w sposób użyteczny. Udostępniony punkt kontrolny jest już w formacie 4-bitowym z treningiem uwzględniającym kwantyzację, więc łatwe oszczędności zostały już wykorzystane. Kolejne zmniejszenie do 2 bitów redukuje wagi do 0.7 TB, co nadal dwukrotnie przekracza pojemność największej karty, a spadek dokładności przy 2 bitach nie został dla tego modelu zmierzony.

Czy wynajem GPU jest tańszy niż 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ć godziny przestoju, pobieranie wag oraz koszt personelu utrzymującego klaster. W przypadku pracy okresowej należy wynajmować zasoby godzinowo i porównywać koszty z własnym zmierzonym wolumenem tokenów, zamiast opierać się na szacunkach.

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

Oznacza to, że operacje arytmetyczne na token odpowiadają modelowi 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, 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.