Kimi K3.1 Pro lokalnie: ile pamięci potrzebuje?

👁 121 przeczytań

Uruchomienie modelu Kimi K3.1 Pro na własnym sprzęcie nie jest obecnie możliwe z prostego powodu: na dzień 2026-10-23 pliki wag nie zostały jeszcze udostępnione do pobrania. Producent zapowiedział ich publikację do 2026-11-04 (blog Kimi). Nawet po ich wydaniu, przy założeniu skali znanej z poprzednika K3 (2,8 biliona parametrów ogółem, 104 miliardy aktywnych), same surowe wagi bez narzutów zajmą teoretycznie 2,8 TB w formacie FP8 lub 1,4 TB po kwantyzacji Q4. Poniżej przedstawiam pełne wyliczenie zapotrzebowania na pamięć, które każdy może odtworzyć w Pythonie bez pobierania modelu, oraz sprawdzam, jak sam model radzi sobie z tym zadaniem przez API.

• Status wag (stan na 2026-10-23): brak plików K3.1 w repozytorium Moonshot AI na Hugging Face (widoczny jest tam poprzedni model K3); publikacja wag K3.1 jest obiecana do 2026-11-04.
• Teoretyczny rozmiar samych wag (dla założonych 2,8e12 parametrów): 2,8 TB dla 8 bitów (FP8), 1,4 TB dla 4 bitów (Q4) oraz 0,7 TB dla 2 bitów (Q2) w jednostkach dziesiętnych.
• Czego nie obejmuje ten rachunek: wyliczenie pomija skale kwantyzacji, metadane plików, bufor kontekstu (KV cache dla deklarowanego okna 1 048 576 tokenów) oraz narzut silnika uruchomieniowego.
• Weryfikacja w API: w moim pojedynczym teście przez OpenRouter model moonshotai/kimi-k3.1-pro bezbłędnie wyliczył te wartości i zwrócił poprawny JSON w 3,291 s za 0,00196 USD.
• Realia sprzętowe: teoretyczne 1,4 TB dla wag Q4 niemal całkowicie wypełnia 1440 GB surowej pamięci VRAM z 8 akceleratorów po 180 GB każdy, co przed doliczeniem KV cache i buforów roboczych nie daje gwarancji uruchomienia inferencji na pojedynczym węźle tej klasy.

Dostępność wag Kimi K3.1 Pro i skąd bierze się założenie 2,8 biliona parametrów

Zanim przejdę do wzorów i gigabajtów, muszę wyraźnie oddzielić fakty od założeń. Kiedy 2026-10-23 sprawdzałem oficjalny profil Moonshot AI w serwisie Hugging Face, znajdowały się tam wyłącznie repozytoria starszej generacji K3. Pliki wag dla Kimi K3.1 Pro nie były jeszcze dostępne do pobrania ani niezależnej weryfikacji. Zgodnie z oficjalnym komunikatem na blogu Kimi, model działa już w aplikacjach Kimi, Work, Code oraz przez API, natomiast udostępnienie otwartych wag zostało obiecane w terminie do 2026-11-04.

Wartości 2,8 biliona (2,8e12) parametrów całkowitych oraz 104 miliardów parametrów aktywnych odnoszą się bezpośrednio do architektury poprzednika, czyli modelu K3. Dopóki w repozytorium nie pojawi się faktyczny artefakt wagowy K3.1 Pro (np. pliki safetensors z plikiem model.safetensors.index.json), traktuję liczbę 2,8e12 jako robocze założenie inżynieryjne oparte na poprzedniej wersji z rodziny Kimi. Cała poniższa analiza to teoretyczny rachunek rozmiaru pamięci masowej i VRAM dla takiej skali modelu, a nie relacja z lokalnego uruchomienia, którego przed publikacją plików nie da się przeprowadzić.

Powtarzalne obliczenie rozmiaru samych wag: FP8, Q4 i Q2

Podstawowy rachunek zapotrzebowania na pamięć dla samych wag sieci neuronowej zależy wyłącznie od liczby parametrów oraz liczby bitów przeznaczonych na zapis pojedynczego parametru. Aby przeliczyć bity na bajty, dzielę wynik przez 8, a następnie przez 10¹² (1e12), aby uzyskać wynik w dziesiętnych terabajtach (TB). Wzór ma postać:

rozmiar_TB = (liczba_parametrow * bity_na_parametr) / 8 / 1e12

Nie trzeba pobierać żadnych bibliotek uczenia maszynowego ani dysponować serwerem GPU, aby zweryfikować te liczby. Poniższy skrypt w czystym Pythonie pozwala każdemu odtworzyć moje wyliczenie na dowolnym komputerze:

import json

parametry = 2.8e12
bity = {"FP8": 8, "Q4": 4, "Q2": 2}

rozmiar_tb = {
    format_wag: round((parametry * b) / 8 / 1e12, 4)
    for format_wag, b in bity.items()
}

print(json.dumps(rozmiar_tb))

Po wykonaniu tego kodu otrzymuję dokładnie {"FP8": 2.8, "Q4": 1.4, "Q2": 0.7}. Co te liczby oznaczają w praktyce i dlaczego stanowią wyłącznie absolutne minimum?

Muszę tu zaznaczyć trzy istotne ograniczenia. Po pierwsze, wyliczone 2,8 TB, 1,4 TB i 0,7 TB to wyłącznie surowe wagi. W rzeczywistych plikach kwantyzowanych (np. blokowo w formatach typu AWQ, GPTQ czy GGUF) oprócz samych wag zapisywane są współczynniki skali (scales), punkty zerowe oraz metadane warstw, co zauważalnie powiększa finalny rozmiar na dysku i w pamięci VRAM.

Po drugie, wyliczenie dla Q2 (0,7 TB) ma charakter wyłącznie matematyczny. Nie ma żadnej gwarancji, że po wydaniu wag Kimi K3.1 Pro oficjalne silniki inferencyjne obsłużą dwubitową kwantyzację tej architektury ani że model po tak drastycznej kompresji zachowa użyteczną jakość odpowiedzi.

Po trzecie, do uruchomienia modelu niezbędna jest pamięć na stan kontekstu (KV cache) oraz tymczasowe bufory wykonawcze (runtime overhead). Oficjalna dokumentacja cennika (platform.kimi.ai/docs/pricing/chat) podaje, że Kimi K3.1 Pro obsługuje kontekst o długości 1 048 576 tokenów (1M). Utrzymanie bufora KV dla miliona tokenów w pamięci kart graficznych wymaga kolejnych setek gigabajtów, zależnie od dokładnej konfiguracji warstw uwagi w finalnym pliku konfiguracyjnym modelu.

Sprawdzian matematyczny przez API: jak Kimi K3.1 Pro i konkurencja liczą pamięć

Rachunek pamięci sprawdziłem pojedynczymi wywołaniami Kimi K3.1 Pro, Opus 5.5 i GPT-6 Astra przez OpenRouter. Parametry: temperature 0.2, żądane reasoning low, max_tokens 1800, bez strumieniowania. Wszystkie trzy podały poprawne 2,8/1,4/0,7 TB. To kontrola arytmetyki, nie próba uruchomienia modelu lokalnie.

W zadaniu pamiec przekazałem modelom następujące polecenie: Policz minimalny rozmiar samych wag dla hipotetycznego modelu o 2,8 biliona (2.8e12) parametrów przy 8, 4 i 2 bitach na parametr. Zwróć wyłącznie JSON: klucze FP8, Q4, Q2, wartości w dziesiętnych TB. Nie doliczaj żadnych narzutów.

Wszystkie trzy modele zwróciły bezbłędny wynik zgodny z moim skryptem w Pythonie i zmieściły się w rygorystycznym formacie JSON bez zbędnych znaczników markdown. W przypadku Kimi K3.1 Pro warto jednak spojrzeć na pełny obraz pozostałych pięciu zadań z mojego protokołu testowego, ponieważ ujawnia on specyficzne zachowanie mechanizmu wnioskowania przy limicie 1800 tokenów.

Szersze omówienie tych zachowań pojawi się w osobnych, planowanych materiałach powiązanych: o obsłudze struktur danych przeczytasz w analizie Kimi K3.1 w zadaniach API i JSON, kwestie językowe trafią do tekstu Kimi K3.1 po polsku, a bezpośrednie zestawienia z rywalami znajdą się w artykułach zaplanowany wspólny test po polsku oraz zaplanowany wspólny test po polsku.

Co oznacza 1,4 TB lub 2,8 TB dla sprzętu serwerowego

Wróćmy do wyliczonych wartości pamięci i przełóżmy je na fizyczną infrastrukturę. Nawet jeśli odrzucimy wariant FP8 (2,8 TB samych wag) i skupimy się na agresywniejszej kwantyzacji 4-bitowej (Q4, czyli 1,4 TB = 1400 GB dziesiętnych), mówimy o skali całkowicie niedostępnej dla stacji roboczych czy pojedynczych serwerów z kartami konsumenckimi.

Rozważmy teoretyczną konfigurację pojedynczego węzła wyposażonego w 8 akceleratorów posiadających po 180 GB pamięci każdy. Łączna pula surowej pamięci VRAM w takim systemie wynosi:

8 * 180 GB = 1440 GB VRAM

Zestawiając 1440 GB dostępnej pamięci z 1400 GB wymaganymi na same surowe wagi Q4, widzimy, że zapas wynosi zaledwie 40 GB (około 5 GB na jeden układ GPU). W praktyce inżynieryjnej taki margines nie daje żadnej gwarancji uruchomienia modelu. Po doliczeniu tabel skali kwantyzacji, narzutu jądra CUDA/silnika inferencyjnego (np. vLLM lub SGLang), buforów komunikacyjnych dla równoległości tensorowej (Tensor Parallelism) oraz pamięci na KV cache, model o rozmiarze 1,4 TB w samych wagach przekroczy limit 1440 GB. Realne wdrożenie tak dużego modelu wymagałoby więc rozproszenia wag na wiele połączonych węzłów (multi-node inference z użyciem szybkiego interconnectu pokroju InfiniBand) lub zejścia z precyzją poniżej 4 bitów, o ile dany format będzie w ogóle wspierany.

Przykład kalkulacji kosztu chmury GPU (Lambda) a opłacalność API

Osobną kwestią, niezależną od rekomendacji sprzętowych, jest koszt wynajmu maszyn o zbliżonej pojemności pamięci w chmurze. Zaznaczam, że nie wynajmowałem takich instancji, nie weryfikowałem kompatybilności oprogramowania ani nie mierzyłem przepustowości - poniższe wyliczenie to czysta arytmetyka oparta na publicznym cenniku.

Według karty cenowej serwisu Lambda (lambda.ai/pricing, odczyt z 2026-10-23), stawka za instancję z 8 układami B200 wynosi 6,69 USD za jeden układ GPU na godzinę (przed podatkiem). Prosty rachunek dla całego węzła wygląda następująco:

• Koszt godzinowy węzła 8x B200: 8 × 6,69 USD = 53,52 USD netto za godzinę.
• Koszt dobowy (24h): 24 × 53,52 USD = 1284,48 USD netto za dobę utrzymania instancji.

Nawet gdyby pojedynczy węzeł tej klasy wystarczył do załadowania mocno skompresowanego modelu (co, jak wykazałem wyżej dla Q4 bez narzutów, jest na granicy fizycznej pojemności), sam postój serwera przez jedną dobę kosztuje blisko 1300 dolarów przed opodatkowaniem.

Zestawmy to teraz z oficjalnym cennikiem API na platformie platform.kimi.ai (stawki przed doliczeniem podatków, odrębne od subskrypcji konsumenckich):

Aby pokazać proporcje kosztów w codziennej pracy, przygotowałem własną, hipotetyczną kalkulację budżetową (to symulacja matematyczna, a nie przebieg 1000 fizycznych wywołań). Załóżmy pakiet 1000 zapytań, z których każde przesyła 1000 tokenów wejściowych i generuje 500 tokenów odpowiedzi (łącznie 1 mln tokenów wejścia i 0,5 mln tokenów wyjścia):

Za równowartość jednej doby utrzymania węzła 8x B200 w chmurze (1284,48 USD) można w oficjalnym API Kimi K3.1 Pro przetworzyć ponad 183 tysiące takich zapytań bez martwienia się o alokację 1,4 TB pamięci VRAM. Szczegółowe rozbicie taryf opiszę w planowanym artykule o cenach API Kimi K3.1.

Najczęściej zadawane pytania (FAQ)

Czy mogę już pobrać wagi Kimi K3.1 Pro i uruchomić je lokalnie?

Nie. Na dzień 2026-10-23 w oficjalnym repozytorium Moonshot AI na Hugging Face dostępne są wagi poprzedniego modelu K3, natomiast pliki dla Kimi K3.1 Pro nie zostały jeszcze opublikowane. Producent zapowiedział na swoim blogu, że wagi zostaną udostępnione do 2026-11-04.

Ile pamięci zajmą same wagi modelu o 2,8 biliona parametrów?

Przyjmując liczbę 2,8e12 parametrów (znaną z poprzednika K3), minimalny teoretyczny rozmiar samych wag wynosi 2,8 TB dla precyzji 8-bitowej (FP8), 1,4 TB dla 4-bitowej (Q4) oraz 0,7 TB dla 2-bitowej (Q2) w jednostkach dziesiętnych. Wyliczenie to nie uwzględnia skal kwantyzacji, metadanych, bufora KV cache ani narzutu środowiska uruchomieniowego.

Czy serwer z 8 kartami po 180 GB VRAM wystarczy do uruchomienia wersji Q4?

Osiem układów po 180 GB daje łącznie 1440 GB surowej pamięci VRAM. Ponieważ same wagi w formacie Q4 dla 2,8e12 parametrów zajmują teoretycznie 1400 GB przed doliczeniem jakichkolwiek narzutów, pozostałe 40 GB to zbyt mało na pomieszczenie skal kwantyzacji, buforów silnika i pamięci kontekstu (KV cache). Taka konfiguracja nie gwarantuje możliwości uruchomienia inferencji.

Jak Kimi K3.1 Pro wypadł w teście obliczania pamięci przez API?

W moim pojedynczym teście przez OpenRouter model moonshotai/kimi-k3.1-pro poprawnie wyliczył rozmiar wag i zwrócił oczekiwany obiekt JSON {"FP8":2.8,"Q4":1.4,"Q2":0.7} w czasie 3,291 s przy koszcie 0,00196 USD.

Źródła

• Oficjalny blog Kimi - zapowiedź Kimi K3.1 Pro i deklaracja publikacji wag do 2026-11-04 (odczyt: 2026-10-23)
• Profil Moonshot AI w serwisie Hugging Face - weryfikacja dostępności repozytoriów wag (odczyt: 2026-10-23)
• Platforma API Kimi - oficjalne stawki za milion tokenów dla wariantów Pro i Highspeed (odczyt: 2026-10-23)
• Dokumentacja cennika czatu Kimi API - specyfikacja okna kontekstowego 1 048 576 tokenów i warunków rozliczeń (odczyt: 2026-10-23)
• Cennik chmury GPU Lambda - stawka godzinowa dla instancji 8x B200 (odczyt: 2026-10-23)

Link do Kimi jest partnerski: jeśli kupisz przez niego, serwis dostaje prowizję, a Ty płacisz tyle samo. Nie wpływa to na treść, także tam, gdzie piszę krytycznie.