Jak uruchomić Kimi K3 lokalnie: sprzęt, pamięć i ograniczenia wdrożenia

Uruchomienie pełnego Kimi K3 lokalnie jest możliwe z udostępnionymi wagami, ale praktyczne wdrożenie nadal wymaga pamięci, akceleratorów i połączeń na skalę klastra.

Po otwartym wydaniu wag 27 lipca pytanie nie brzmi już, czy punkt kontrolny istnieje, lecz czy Twój system może go pobrać, załadować i obsłużyć z użyteczną prędkością. Publiczne repozytorium ma około 1,56 TB w 96 fragmentach safetensor, podczas gdy model zawiera 2,8 biliona parametrów łącznie i aktywuje 104 miliardy na token. Te liczby wykluczają zwykły PC, Mac, domowy NAS lub serwer z pojedynczym GPU z praktycznego zakresu pełnego modelu, dlatego poniższe sekcje rozdzielają kwestie przechowywania, pamięci, topologii akceleratorów, wsparcia runtime i realistycznych ścieżek awaryjnych.

Co jest dostępne teraz, gdy wagi Kimi K3 zostały udostępnione?

Wydanie otwartych wag Kimi K3 zawiera pełny punkt kontrolny modelu oraz raport techniczny. Publiczne repozytorium modelu obecnie pokazuje około 1,56 TB plików i 96 ponumerowanych fragmentów safetensor. Ta liczba jest przydatna do planowania pobrań i pojemności dysku, ale nie stanowi minimalnej specyfikacji VRAM.

Opublikowane podsumowanie modelu potwierdza 2,8 biliona parametrów łącznie, 104 miliardy aktywowanych parametrów, 93 warstwy, 69 warstw Kimi Delta Attention oraz 24 warstwy Gated MLA. Jego routing Stable LatentMoE wybiera 16 z 896 ekspertów przypisanych do tokena i korzysta także z dwóch współdzielonych ekspertów. Wagi są w formacie MXFP4, aktywacje w MXFP8, a deklarowany maksymalny kontekst to 1 048 576 tokenów.

Wsparcie wdrożeniowe jest również bardziej konkretne niż przed wydaniem. vLLM, SGLang i TokenSpeed są wymienione jako zalecane silniki inferencyjne, ale każdy wymaga jąder, kodu modelu, dzielenia i ustawień pamięci świadomych K3. Ogólne polecenie pokazane przez bibliotekę klienta nie zamienia punktu kontrolnego w lokalny model na skalę konsumencką.

Dlaczego rzadkie MoE nadal wymaga ogromnej pamięci?

Kimi K3 wykonuje obliczenia z 104 mld aktywowanych parametrów dla każdego tokena, ale wszyscy eksperci MoE nadal zużywają pamięć do przechowywania i obsługi. Router może wybrać różnych ekspertów dla następnego tokena, więc pełny zestaw wag 2,8T musi pozostać dostępny gdzieś w wdrożeniu.

Wybór 16 z 896 kierowanych ekspertów zmniejsza pracę ekspercką wykonywaną dla jednego tokena. Nie oznacza to, że maszyna może przechowywać tylko 16 ekspertów, odrzucić resztę i nadal uruchamiać wydany model bez zmian. Przycinanie ekspertów, destylacja lub strumieniowanie tworzyłyby inny kompromis operacyjny i nie powinny być mylone z normalną rzadką aktywacją.

Liczba 104 mld aktywowanych parametrów jest więc opisem skali obliczeniowej, a nie skrótem do szacowania rozmiaru punktu kontrolnego. Mnożenie 104 mld przez cztery bity i twierdzenie, że model potrzebuje tylko około 52 GB, ignorowałoby nieaktywne, ale nadal wymagane wagi ekspertów, komponenty gęste, współdzielonych ekspertów, warstwy uwagi, wagi wizji i stan działania.

Jaka jest minimalna dolna granica pamięci na wagi?

Przy 2,8 biliona parametrach najprostsze obliczenie dolnej granicy to całkowita liczba parametrów pomnożona przez liczbę bitów przechowywanych na parametr. MXFP4 daje minimalną wartość 4-bitową: 2,8T × 4 bity to około 1,4 TB, czyli około 1,27 TiB, tylko dla surowej wagi.

Opublikowane repozytorium ma około 1,56 TB, co pokazuje, dlaczego pamięć obsługi wykracza poza prostą kalkulację wag. Pakowanie punktu kontrolnego, skale bloków, wyrównanie tensorów, pliki konfiguracyjne, zasoby tokenizera, komponenty wizji i inne dane modelu podnoszą rzeczywisty rozmiar pobrania ponad teoretyczną podstawę czterobitową.

Należy osobno zaplanować cztery różne budżety: trwałą pamięć do pobrania, tymczasową przestrzeń stagingową, pamięć RAM hosta oraz HBM lub VRAM akceleratora. Działająca usługa potrzebuje dodatkowo miejsca na stan KDA, pamięć podręczną MLA KV, aktywacje, bufory komunikacyjne, jądra, przechwytywanie grafu i zapas na awarie. Rozmiar repozytorium 1,56 TB nie jest więc ani pełnym wymaganiem RAM, ani pełnym wymaganiem pamięci GPU.

Jaki sprzęt faktycznie może uruchomić Kimi K3 lokalnie?

Nie istnieje uczciwa lista minimalnych konsumenckich GPU dla pełnego modelu. System, który technicznie może mapować lub strumieniować punkt kontrolny, nie jest automatycznie zdolny do stabilnej, interaktywnej obsługi. Praktyczne wymagania sprzętowe Kimi K3 zależą od rezydencji wag, obsługiwanych jąder MXFP4, przepustowości połączeń, pojemności pamięci podręcznej, długości kontekstu, współbieżności i silnika obsługi.

Opublikowane wsparcie day-zero Kimi K3 ustawia realistyczną klasę startową na węzeł korporacyjny z ośmioma akceleratorami. Obecne materiały vLLM opisują akceleratory klasy GB300 lub MI350X/MI355X jako punkty startowe, podczas gdy SGLang publikuje przykłady uwzględniające topologię, w tym B300 1×8, GB300 2×4, B200 2×8, H200 2×8, H100 4×8 oraz MI350X/MI355X 1×8.

To opublikowane przepisy wykonawcze i konfiguracje startowe, a nie pojedynczy certyfikowany minimum dla każdego obciążenia. Starsze lub mniejsze akceleratory mogą wymagać więcej węzłów, innych jąder kwantyzacji, zmniejszonego kontekstu lub dodatkowego eksperckiego równoległego przetwarzania. Ruch produkcyjny wymaga również pojemności na jednoczesne żądania, nieudane procesy i zapas wydajności, a nie tylko dopasowania punktu kontrolnego raz.

Dlaczego jeden stacja robocza lub NAS nadal jest niewłaściwą topologią?

Podział surowej pojemności nie oddaje skali problemu. Nawet jeśli złożona zostanie wystarczająca pamięć, równoległość ekspertowa zamienia trasowanie w ruch sieciowy. Tokeny muszą dotrzeć do akceleratorów trzymających wybranych ekspertów, a następnie wrócić do reszty potoku modelu.

Węzły akceleratorów korporacyjnych oferują więcej niż pamięć. Łączą szybkie łącza GPU, sieci RDMA, biblioteki komunikacji zbiorowej oraz jądra zaprojektowane do równoległości tensorowej, ekspertowej, danych lub potokowej. Zbiór konsumenckich GPU połączonych przez zwykłe PCIe lub sieć domową może wykazywać nominalną pojemność, ale pozostaje zbyt wolny lub zawodny do użytecznej obsługi.

NAS jest cenny do przechowywania fragmentów punktów kontrolnych, logów, zestawów danych, indeksów wyszukiwania i danych aplikacji, ale pamięć sieciowa nie zastępuje przepustowości pamięci akceleratora. Lepszą rolą serwera domowego jest zwykle przechowywanie prywatnych danych i wyszukiwanie blisko użytkownika, pozostawiając inferencję modeli najnowszej generacji odpowiedniemu klastrowi lub hostowanemu punktowi końcowemu. W takim projekcie serwer domowy oddziela lokalną warstwę danych od inferencji najnowszych modeli.

Jak stan KDA, pamięć podręczna MLA KV i długość kontekstu zwiększają budżet?

Kimi K3 nie używa jednolitej pamięci podręcznej pełnej uwagi dla wszystkich 93 warstw. Jego 69 warstw KDA i 24 warstwy Gated MLA tworzą dwa różne zapotrzebowania na pamięć serwisową: pulę stanów KDA o stałej geometrii modelu dla przyjmowanych żądań oraz stronicowaną pulę MLA KV, która rośnie wraz z przechowywanymi tokenami.

To rozdzielenie oznacza, że KDA może zmniejszyć wzrost długiego kontekstu występujący w konwencjonalnej uwadze, ale nie sprawia, że żądanie na milion tokenów jest darmowe. Ponieważ stan KDA i pamięć MLA KV konkurują o pojemność akceleratora, strona KDA może ograniczać przyjmowane żądania, podczas gdy strona MLA ogranicza całkowitą liczbę przechowywanych tokenów.

Rozmiar partii, współbieżność, średnia długość promptu, długość generowanego rozumowania, multimodalne dane wejściowe, precyzja pamięci podręcznej oraz strategia wstępnego wypełniania/dekodowania zmieniają użyteczną pojemność. Liczba 1M tokenów to maksymalna zdolność modelu, a nie zalecana domyślna wartość. Pierwsze wdrożenie powinno zacząć od krótszego maksymalnego kontekstu, rozmiaru partii jeden i niskiej współbieżności, zanim zmierzy się błędy braku pamięci, czas wstępnego wypełniania, szybkość dekodowania i ruch między węzłami.

Jak można uruchomić Kimi K3 lokalnie po wydaniu otwartych wag?

Uruchomienie Kimi K3 lokalnie teraz oznacza budowę rozproszonej usługi inferencyjnej wokół udostępnionego punktu kontrolnego, a nie instalację zwykłej aplikacji desktopowej. Najbezpieczniejszą sekwencją jest weryfikacja magazynu, wsparcia środowiska uruchomieniowego, topologii i małego punktu operacyjnego przed zwiększeniem kontekstu lub ruchu.

1. Przygotuj magazyn. Zarezerwuj co najmniej około 1,56 TB na repozytorium plus dodatkowe miejsce na częściowe pobrania, pamięci podręczne, obrazy kontenerów, logi i pliki tymczasowe.
2. Wybierz obsługiwany silnik. Użyj ścieżki wdrożeniowej specyficznej dla Kimi K3 vLLM, SGLang lub TokenSpeed z wymaganym kodem modelu, jądrami oraz wersją kontenera lub gałęzi.
3. Dopasuj topologię. Wybierz układ wielo-GPU lub wielo-węzłowy klasy korporacyjnej z wystarczającą ilością HBM oraz ścieżką NVLink, MNNVL lub RDMA oczekiwaną przez ustawienia równoległości tensorów i ekspertów.
4. Zacznij poniżej limitów nagłówka. Zmniejsz maksymalną długość modelu, rozmiar partii i współbieżność, a następnie zweryfikuj ładowanie, zachowanie przy braku pamięci, poprawność wyjścia, szybkość wstępnego wypełniania, szybkość dekodowania i ruch all-to-all.
5. Skaluj tylko po pomiarze. Dodawaj kontekst, równoczesne żądania, funkcje pamięci podręcznej, multimodalne dane wejściowe lub spekulatywne dekodowanie po jednej zmiennej na raz.

Polecenie takie jak vllm serve lub sglang serve opisuje, jak rozpocząć kompatybilne środowisko rozproszone; nie usuwa to wymogu sprzętowego. Gdy wymagana klasa akceleratora jest niedostępna, realistyczne opcje to hostowane API, hybrydowa architektura utrzymująca pliki i pobieranie lokalnie lub mniejszy lokalny model mieszczący się w rzeczywistej pamięci i budżecie niezawodności serwera domowego.

FAQ

Czy mogę uruchomić Kimi K3 lokalnie na zwykłym PC, Macu lub domowym NAS?

Nie przy praktycznej pełnej prędkości modelu. Repozytorium zajmuje około 1,56 TB przed narzutem serwowania, podczas gdy normalny lokalny system również nie posiada pamięci akceleratora ani topologii o wysokiej przepustowości oczekiwanej przez obecne środowiska uruchomieniowe. Eksperymentalne strumieniowanie ekspertów lub intensywne odciążanie mogą wykazać, że uruchomienie jest technicznie możliwe, ale nie jest to równoznaczne z responsywnym lub gotowym do produkcji serwowaniem.

Ile miejsca na dysku i pamięci wymaga Kimi K3?

Przezroczysta podstawa wag MXFP4 to około 1,4 TB, podczas gdy publiczne repozytorium ma około 1,56 TB. Potrzebujesz też dodatkowej przestrzeni dyskowej, pamięci RAM hosta, HBM lub VRAM akceleratora, stanu KDA, pamięci podręcznej MLA KV, aktywacji, przestrzeni roboczej komunikacji i zapasu operacyjnego. Nie ma jednej liczby, która reprezentowałaby wszystkie te warstwy.

Jaka jest minimalna opublikowana konfiguracja GPU dla Kimi K3?

Najmniejsze opublikowane konfiguracje na dzień zero to węzły korporacyjne z ośmioma kartami akceleratorów, a obecne ścieżki vLLM i SGLang skupiają się na sprzęcie klasy B300, GB300 lub MI350X/MI355X. Traktuj je jako punkty startowe środowiska uruchomieniowego, a nie uniwersalny gwarantowany minimum; kontekst, współbieżność, wersja silnika i cele produkcyjne mogą wymagać więcej zasobów.

Czy Kimi K3 może działać z dysku SSD lub z odciążeniem NAS?

Dyski SSD lub pamięć NAS mogą przechowywać fragmenty punktu kontrolnego, a eksperymentalne środowiska uruchomieniowe mogą przesyłać wagi przez pamięć hosta. Ograniczającym czynnikiem jest wielokrotne przesyłanie wag ekspertów i stanu przez pamięć masową, sieć, RAM i łącza PCIe. Te ścieżki są znacznie wolniejsze niż HBM akceleratora i szybkie sieci GPU, więc eksperymentalne uruchomienie może skutkować nieakceptowalną latencją.

Czy Ollama uruchamia pełny model Kimi K3 lokalnie?

Obecny wpis Ollama Kimi K3 używa tagu kimi-k3:cloud. Uruchomienie lokalnego klienta Ollama nie oznacza, że punkt kontrolny o rozmiarze 1,56 TB jest załadowany na lokalnej maszynie; wymieniona ścieżka jest wspierana przez chmurę.

Ostateczne wnioski

Kimi K3 jest teraz naprawdę dostępny jako model z otwartymi wagami, więc operatorzy klastrów mogą pobrać i wdrożyć pełny punkt kontrolny zamiast polegać na szacunkach przedpremierowych. Wydanie zmienia dostępność weryfikacji i narzędzi, ale nie zmienia fizycznej skali modelu o 2,8 biliona parametrów.

Najbardziej przydatne liczby pamięci Kimi K3 odpowiadają na różne pytania: około 1,4 TB to przezroczysta podstawa wag czterobitowych, około 1,56 TB to obecny rozmiar repozytorium, a 104B to aktywna skala obliczeń na token. Żadna z tych liczb osobno nie opisuje całkowitej pamięci potrzebnej do działania usługi.

Dla większości osób i użytkowników serwerów domowych granica zatrzymania jest jasna: bez węzła korporacyjnego z ośmioma akceleratorami lub rozproszonego klastra, należy korzystać z hostowanego wnioskowania, przechowywać prywatne dane i warstwę wyszukiwania lokalnie lub wybrać mniejszy model. To praktyczny sposób na korzystanie z Kimi K3 bez traktowania NAS, stacji roboczej czy pojedynczego GPU jako superwęzła modelu granicznego.