Buduj z CometAPIPotrzebujesz jednego API dla wielu modeli?Przetestuj proces w Playground, a potem utwórz klucz API, gdy model i koszt pasują do Twojego zastosowania.
Jak wdrożyć Kimi K3.1 Pro lokalnie: wymagania sprzętowe, konfiguracja vLLM
Dowiedz się, jak samodzielnie hostować Kimi K3.1 Pro przy użyciu vLLM, sprawdź wymagania dotyczące GPU, pobierz wagi modelu, przetestuj wnioskowanie i porównaj wdrożenie lokalne z dostępem do API.
Wdróż Kimi K3.1 Pro na serwerze Linux z GPU, a następnie podłącz lokalną aplikację do jego endpointu inferencyjnego. Ten przewodnik używa jednego węzła NVIDIA B300 z ośmioma GPU i vLLM. Potrzebujesz dostępu do powłoki serwera, kompatybilnych sterowników oraz przestrzeni na pełny checkpoint. Zacznij od zrealizowania jednego krótkiego żądania tekstowego, zanim przetestujesz dłuższe wejścia lub przepływy pracy agentów.
Bez odpowiednich GPU możesz uruchomić aplikację lokalnie i podłączyć ją do oficjalnego API Kimi lub dostawcy zewnętrznego, takiego jak CometAPI.
Key Takeaways
104 mld aktywnych parametrów modelu nie odzwierciedla pełnych wymagań pamięciowych.
Zgodność sprzętowa obejmuje pamięć GPU, interconnecty, wsparcie kwantyzacji i kerneli inferencyjnych.
Sprawdzone pod kątem przejrzystości, atrybucji źródeł i aktualnej terminologii API.
Mocne wyniki w benchmarkach uzasadniają testy, ale nie gwarantują równoważnej wydajności w Twojej aplikacji.
Działający endpoint inferencyjny nie oznacza automatycznie przeglądarki, piaskownicy kodu ani kompletnego środowiska agenta.
Porównuj samohostowanie i dostęp przez API według kosztu na udane zadanie, uwzględniając ponowienia i utrzymanie.
Czym jest Kimi K3.1 Pro?
Kimi K3.1 Pro to otwarto-wagowy model multimodalny Moonshot AI do programowania, analizy dokumentów i użycia narzędzi. Poniżej wymieniono jego główne specyfikacje na podstawie oficjalnej karty modelu .
Specyfikacja
Opublikowana konfiguracja
Architektura
MoE; 2,8T łącznych parametrów, 104B aktywnych
Mechanizm uwagi
93 warstwy: 69 KDA + 24 Gated DSA
Eksperci
896 routowanych; 16 wybieranych na token; 2 współdzielonych
Model aktywuje 104 mld parametrów na token, ale wdrożenie nadal wymaga pełnego checkpointu z 2,8T parametrów. Silnik inferencji musi także wspierać warstwy KDA i Gated DSA oraz kwantyzację MXFP4.
Jakiego sprzętu potrzebujesz, aby uruchomić Kimi K3.1 Pro lokalnie?
Poniższa tabela podsumowuje konfiguracje vLLM istotne dla tego przewodnika. Przykład używa jednego węzła B300 z ośmioma GPU; wdrożenia na GB300 i AMD wymagają odpowiednich konfiguracji.
Sprzęt
Udokumentowana ścieżka
Uwagi planistyczne
NVIDIA B300
Jeden węzeł z ośmioma GPU, TP8
Punkt odniesienia dla poniższego przewodnika
NVIDIA GB300
Osiem GPU w dwóch tacach, TP8
Wymaga konfiguracji wielowęzłowej i ustawienia interconnectów
AMD MI355X
Węzeł z ośmioma GPU, konfiguracja specyficzna dla AMD
Użyj ścieżki ROCm/AITER; nie używaj ustawień środowiska NVIDIA
Pojedynczy konsumencki GPU 24–32 GB
Niewystarczający do bezpośredniego ładowania pełnego checkpointu
Nie jest praktycznym celem dla tego tutorialu
Dla skali: 2,8T parametrów zajęłoby około 5,6 TB w BF16, 2,8 TB przy ośmiu bitach lub 1,4 TB przy idealizowanych czterech bitach. To obliczenia surowego magazynu parametrów, a nie rzeczywiste rozmiary checkpointów czy minimalne VRAM w czasie działania. Mieszana precyzja i metadane zmieniają rozmiar plików; cache i przydziały czasu wykonania zwiększają wymagania serwowania.
Zarezerwuj pojemność NVMe na pełne pobranie, pliki tymczasowe i kopię na rollback. W systemach wielowęzłowych zweryfikuj komunikację przed załadowaniem modelu.
Jak wdrożyć Kimi K3.1 Pro
Użyj samohostowania, jeśli masz odpowiedni sprzęt; w przeciwnym razie zacznij od hostowanego API. Poniższe kroki używają vLLM, a na końcu sekcji podano alternatywę SGLang. Porównaj koszty hostingu po uzyskaniu działającego żądania.
Uruchom polecenia konfiguracji, pobierania, startu i wstępnej weryfikacji w powłoce Bash na serwerze GPU. Jeśli pracujesz z laptopa, najpierw połącz się z tym serwerem przez SSH. Klient Pythona może później działać na obu maszynach, używając instrukcji połączenia poniżej.
Ten przewodnik podąża za oficjalną recepturą wdrożenia; nie został niezależnie przetestowany na potrzeby tego artykułu.
1. Sprawdź widoczność GPU, magazyn i łączność
Zacznij od podstawowych testów infrastruktury:
nvidia-smi
nvidia-smi topo -m
df -h
Potwierdź, że wszystkie docelowe GPU są widoczne i że katalog modelu ma wystarczającą przestrzeń. Uwzględnij dodatkowe miejsce na cache pobierania, logi i przyszłe wersje checkpointów.
Dla wdrożeń wielowęzłowych zweryfikuj komunikację między węzłami przed uruchomieniem modelu.
Utrzymaj wąski pierwszy kamień milowy: załaduj checkpoint i zrealizuj jedno krótkie żądanie tekstowe. Ułatwia to diagnozowanie błędów.
2. Przygotuj środowisko serwowania
Użyj hosta Linux z ośmioma GPU B300 dla tego przykładu jedno-węzłowego. W środowisku CUDA zgodnym z opublikowaną recepturą utwórz izolowane środowisko i zainstaluj narzędzia serwujące:
Minimalna wersja nie gwarantuje zgodności z każdym sterownikiem czy kołem. Jeśli receptura sprzętowa wymaga dedykowanego kontenera lub buildu, użyj właśnie tego środowiska. Przypnij wersję, która przeszła testy, przed produkcją.
3. Pobierz pełny checkpoint
Zainstaluj CLI Hugging Face i pobierz repozytorium modelu:
Przechowuj pliki konfiguracyjne, tokenizer, processor i indeks wag obok shardów wag. Kopiowanie tylko wybranych plików tensorów może pozostawić wdrożenie niekompletne.
Dla powtarzalnych wdrożeń produkcyjnych zanotuj i przypnij rewizję repozytorium, którą zweryfikowałeś. Przed użyciem komercyjnym przejrzyj licencję niestandardową repozytorium.
Po przygotowaniu środowiska użyj poniższego polecenia bazowego. Uruchamia ono ośmiokierunkowy paralelizm tensorowy i ogranicza początkowe okno kontekstu do 32 768 tokenów:
Nazwa kimi-local to alias widoczny dla aplikacji. Używaj tej samej nazwy w kolejnych żądaniach.
Ustawienie 32 768 tokenów to zachowawczy punkt wyjścia dla tego przewodnika, a nie maksymalny wspierany kontekst modelu.
Opcja --trust-remote-code pozwala na załadowanie niestandardowego kodu repozytorium. Połącz ją z przejrzanym, przypiętym rewizją checkpointem.
Tutaj 127.0.0.1 odnosi się do maszyny uruchamiającej klienta. Poniższe polecenia curl działają na serwerze GPU, gdzie docierają do procesu inferencji. Aby użyć klienta Pythona z laptopa, otwórz tunel SSH w osobnym terminalu laptopa i utrzymuj go:
ssh -N -L 8000:127.0.0.1:8000 user@gpu-server
Zastąp user@gpu-server swoim loginem i adresem serwera. Z tym tunelem otwartym klient na laptopie może używać http://127.0.0.1:8000/v1. Jeśli port 8000 jest już zajęty na laptopie, wybierz inny lokalny port i zaktualizuj URL klienta.
finish_reason wskazującego, czy generowanie zakończyło się, czy osiągnęło limit.
Błędów pamięci GPU lub nieobsługiwanych operacji.
Rozumowanie może zużywać część budżetu generowania. Jeśli żądanie osiągnie limit, zanim powstanie końcowa odpowiedź, zwiększ budżet i spróbuj ponownie, zanim uznasz, że serwer nie działa.
6. Połącz lokalną aplikację Python
python -m pip install openai
from openai import OpenAI
client = OpenAI(
base_url="http://127.0.0.1:8000/v1",
api_key="EMPTY",
timeout=300.0,
max_retries=1,
)
response = client.chat.completions.create(
model="kimi-local",
messages=[{"role": "user", "content": "Write a Python function that removes duplicate filenames while preserving order."}],
reasoning_effort="low",
max_tokens=2048,
)
print(response.choices[0].message.content)
print(response.choices[0].finish_reason)
EMPTY to placeholder dla tego serwera w pętli zwrotnej bez uwierzytelniania kluczem API. Użyj skonfigurowanego poświadczenia dla uwierzytelnionego endpointu. Zweryfikuj osobno wejście obrazu i wykonanie narzędzi przed podłączeniem agenta.
Alternatywa SGLang
Dla SGLang użyj oficjalnego sprzętowo-specyficznego cookbooka. Wybierz B300, Unified i Low-Latency (TP8) jako najbliższe dopasowanie do tego przewodnika jedno-węzłowego. Sprawdź wyświetlany status weryfikacji; wygenerowana konfiguracja nie jest koniecznie przetestowaną konfiguracją.
Na serwerze GPU zainstaluj Docker i skonfiguruj NVIDIA Container Toolkit, następnie utwórz kontener z zamontowanym checkpointem pod /models/Kimi-K3.1-Pro. Najpierw zatrzymaj vLLM, aby oba silniki nie konkurowały o te same GPU.
Wewnątrz kontenera wklej pełne polecenie uruchomienia wygenerowane przez cookbook dla wybranej konfiguracji. Zastąp jego ścieżkę modelu na /models/Kimi-K3.1-Pro, ustaw host usługi na 0.0.0.0 i port na 30000 oraz zachowaj flagi specyficzne dla sprzętu. Kontener musi nasłuchiwać na swoim interfejsie sieciowym, aby działało przekierowanie portów Dockera; port po stronie hosta pozostaje związany z loopbackiem. Poczekaj na komunikat o gotowości usługi przed testowaniem.
W drugiej powłoce na serwerze GPU wylistuj serwowany model, a następnie wyślij żądanie, używając dokładnego ID modelu zwróconego wcześniej:
curl http://127.0.0.1:30000/v1/models
MODEL_ID="replace-with-id-from-models-response"
curl http://127.0.0.1:30000/v1/chat/completions \
-H "Content-Type: application/json" \
-d "{\"model\":\"$MODEL_ID\",\"messages\":[{\"role\":\"user\",\"content\":\"Explain database indexes in three sentences.\"}],\"reasoning_effort\":\"low\",\"max_tokens\":2048}"
Udana odpowiedź powinna zawierać końcową odpowiedź. Jeśli start się nie powiedzie, sprawdź logi kontenera i potwierdź, że wybrana receptura sprzętowa i obraz pasują. Dla dostępu z laptopa użyj tego samego wzorca tunelu SSH z portem 30000. Zobacz przewodnik instalacji Dockera dla SGLang w celu poznania wymagań wstępnych kontenera.
Jak Kimi K3.1 Pro wypada w benchmarkach?
Użyj oficjalnych wyników ewaluacji poniżej, aby wybrać zadania do testów wdrożeniowych. Te wyniki opisują opublikowaną konfigurację ewaluacyjną; nie mierzą lokalnego serwera skonfigurowanego w tym przewodniku.
Poniższa tabela pokazuje wybrane wyniki i ich pozycje w zestawie porównawczym opublikowanym w karcie modelu.
Benchmark i oficjalne wyniki
Wynik modelu
Pozycja w tym porównaniu
Terminal-Bench 4.0
65,7
Drugie miejsce
SWE Marathon v1.1
51,7
Pierwsze miejsce
Program Bench
31,5
Czwarte miejsce
OfficeQA Pro v2
64,4
Pierwsze wśród zgłoszonych wyników
Frontier Finance
58,6
Drugie miejsce
Wyniki wspierają testowanie modelu pod kątem rozszerzonych zadań inżynierskich i przepływów dokumentowych. Kimi K3.1 Pro prowadzi w tym porównaniu na SWE Marathon, ale zajmuje czwarte miejsce w ProgramBench, co czyni oba użytecznymi kandydatami do testów specyficznych dla aplikacji.
Te pozycje są obliczone w ramach oficjalnej tabeli porównawczej, a nie na żywym globalnym leaderboardzie. Harnessy ewaluacyjne, narzędzia, budżety rozumowania i dobór próbek różnią się między benchmarkami.
Dla decyzji wdrożeniowej zbuduj niewielki zestaw ewaluacyjny z rzeczywistej pracy: poprawki repozytoriów, pytania przekrojowe o dokumenty i wieloetapowe zadania narzędziowe. Mierz jakość ukończenia, korekty ludzkie i czas. Opublikowane wyniki są przydatne do shortlistingu; o opłacalności wdrożenia decydują testy aplikacyjne.
Jak optymalizować lokalną inferencję Kimi K3.1 Pro?
Kontroluj kontekst i współbieżność
Gdy krótkie żądania działają, przetestuj osobno dłuższe dokumenty, obrazy, rozmowy wielotur i wywołania narzędzi.
Śledź opóźnienie pierwszego tokena, liczbę tokenów na sekundę oraz szczytowe zużycie pamięci GPU przy docelowej długości kontekstu i współbieżności. Notuj też powodzenie zadań i koszt na udane zadanie, aby szybsze wyjście nie maskowało większej liczby ponowień lub korekt ludzkich.
Zmieniaj jedną główną zmienną naraz. Jednoczesne zwiększanie długości kontekstu, współbieżności i ustawień optymalizacji utrudnia wyjaśnienie regresji wydajności.
Dobieraj poziom rozumowania i ustawienia cache rozważnie
Używaj niskiego, wysokiego lub maksymalnego poziomu rozumowania w zależności od zadania. Zacznij od niskiego dla testów interfejsu, następnie porównaj wysoki i maksymalny na trudnych zadaniach, mierząc zarówno jakość ukończenia, jak i czas. Dłuższy ślad rozumowania sam w sobie nie jest dowodem lepszego rezultatu.
Dla długich sesji oceń pojemność cache i ponowne użycie prefiksu, zanim dodasz dekodowanie spekulatywne lub większą współbieżność. Utrzymuj znany, dobry baseline i zmieniaj jedno ustawienie naraz.
Dlaczego wywoływanie narzędzi przez Kimi K3.1 Pro może się nie udać po wdrożeniu?
Twoja aplikacja wykonuje wywołania narzędzi, zwraca ich wyniki i kontynuuje rozmowę. Zachowaj pełną wiadomość asystenta — włącznie z reasoning_content i tool_calls — i zwracaj każdy wynik narzędzia z dopasowanym tool_call_id.
Ważna jest też obsługa wieloturu. Wytyczne użycia modelu wymagają zachowania pełnej wiadomości asystenta, w tym pól rozumowania i wywołań narzędzi, zamiast przechowywania jedynie końcowego tekstu.
Objaw
Pierwsze kontrole
Nierozpoznana architektura modelu
Wersja środowiska uruchomieniowego, kod niestandardowy, konfiguracja
Brak pamięci podczas ładowania
Pojemność GPU, paralelizm, konkurencyjne procesy
Krótkie żądania działają, długie zawodzą
Limit kontekstu, pojemność cache, współbieżność
Nie można sparsować wywołań narzędzi
Ustawienia parsera i schemat narzędzi
Agent zatrzymuje się po zażądaniu narzędzia
Wykonanie aplikacji i obsługa wyników narzędzi
Niespójne odpowiedzi w wieloturze
Brakujące pola wiadomości asystenta
Użyj minimalnego, reprodukowalnego żądania, aby wyizolować każdą awarię. Gdy zadziała, przywracaj dodatkowe ustawienia aplikacji po jednym.
Czy samodzielnie hostować czy użyć hostowanego API?
Wybierz samohostowanie, gdy potrzebujesz kontroli nad wagami, infrastrukturą lub lokalizacją danych i możesz utrzymać sensowne wykorzystanie GPU. Dla wstępnej ewaluacji lub zmiennego popytu porównaj oficjalne API Kimi i CometAPI używając tych samych promptów i kryteriów akceptacji. Potwierdź dostęp do modeli, wspierane parametry, limity i warunki przetwarzania danych każdej usługi.
Uwzględnij ich tokeny lub wywołania w opłatach API
Przegląd ludzki
Licz czas korekt przy tej samej stawce
Licz czas korekt przy tej samej stawce
Najlepsze dopasowanie
Stały popyt i kontrola infrastruktury
Ewaluacja i zmienny popyt
Przydatne porównanie to:
Koszt na udane zadanie = (obliczenia GPU lub opłaty API + magazyn i sieć + operacje + korekta ludzka) / udane zadania.
Używaj kosztów i liczby udanych zadań z tego samego okresu pomiarowego. Uwzględnij nieudane próby i ponowienia w łącznym koszcie obliczeń lub API raz; nie dodawaj drugiej opłaty za ponowienie. Dla przepływu hybrydowego uwzględnij zarówno obliczenia, jak i opłaty API. Licz unikalne ukończone zadania, nie próby żądań.
Niewykorzystany serwer może pozostać kosztowny nawet przy teoretycznie świetnej przepustowości. Z kolei zespół z istniejącą infrastrukturą, stałym popytem i ostrymi wymaganiami dot. danych może zyskać istotną wartość z samohostowania.
Używaj identycznych promptów i kryteriów akceptacji przy porównywaniu tras wdrożenia. Uwzględnij latencję end-to-end i jakość wyjścia w decyzji.
Wypróbuj hostowany endpoint bez ładowania wag
Oficjalny quickstart API Kimi używa poniższego endpointu. Ustaw MOONSHOT_API_KEY w środowisku i potwierdź dostęp do modelu na swoim koncie. To żądanie działa w infrastrukturze dostawcy.
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["MOONSHOT_API_KEY"],
base_url="https://api.moonshot.ai/v1",
)
response = client.chat.completions.create(
model="kimi-k3.1-pro",
messages=[{"role": "user", "content": "Explain database indexes in three sentences."}],
reasoning_effort="low",
max_completion_tokens=2048,
)
print(response.choices[0].message.content)
Dla Kimi K3.1 Pro w CometAPI ustaw COMETAPI_API_KEY w środowisku i potwierdź, że Twoje konto ma dostęp do żądanego modelu. Żądanie działa zdalnie:
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["COMETAPI_API_KEY"],
base_url="https://api.cometapi.com/v1",
)
response = client.chat.completions.create(
model="kimi-k3.1-pro",
messages=[{"role": "user", "content": "Explain database indexes in three sentences."}],
max_tokens=2048,
)
print(response.choices[0].message.content)
Porównaj wynik ze swoim lokalnym endpointem przy użyciu tych samych kryteriów akceptacji. Sprawdź bieżącą cenę trasy i wspierane parametry przed szacowaniem kosztów produkcyjnych.
Podsumowanie
Samohostowanie Kimi K3.1 Pro jest praktyczne przy wspieranej konfiguracji GPU i dopasowanym środowisku inferencji. Użyj powyższych kroków wdrożenia, aby ustanowić działający endpoint, a następnie zmierz jakość zadań, latencję i koszt na swoim własnym obciążeniu. Wybierz hostowane API, jeśli wciąż walidujesz aplikację lub nie masz odpowiedniego sprzętu.
FAQ
Czy zwykły laptop uruchomi pełny model?
Zwykły laptop nie jest praktycznym celem dla wymagań pojemnościowych oryginalnego checkpointu. Może działać jako klient podłączony do Twojego serwera inferencji lub hostowanego API.
Czy instalacja aplikacji desktopowej liczy się jako lokalne wdrożenie?
Lokalizacja instalacji aplikacji nie przesądza, gdzie odbywa się inferencja. Samohostowanie wymaga uruchomienia wag modelu i procesu inferencji w infrastrukturze, którą kontrolujesz.
Dlaczego model potrzebuje tyle pamięci, skoro aktywnych jest tylko 104 mld parametrów?
Różne tokeny mogą wybierać różnych ekspertów. Aktywne parametry opisują udział w obliczeniach; wdrożenie nadal musi przechowywać i uzyskiwać dostęp do pełnego zestawu wag.
Czy mogę od razu włączyć pełny milion-tokenowy kontekst?
Zwiększaj długość kontekstu stopniowo i mierz użycie pamięci GPU przy docelowej współbieżności. Model wspiera 1 048 576 tokenów, ale używalna pojemność serwowania zależy od cache i ustawień paralelizacji.
Czy lokalne wdrożenie odtworzy opublikowane wyniki benchmarków?
Nie automatycznie. Kwantyzacja, budżety rozumowania, narzędzia, prompty i frameworki ewaluacji mogą wpływać na wyniki. Zweryfikuj konfigurację na własnych zadaniach.
Czy powinienem testować przez API przed zakupem sprzętu?
Jeśli nie ustaliłeś, że model spełnia Twoje wymagania jakościowe, testy API dają wstępną bazę przy mniejszym nakładzie infrastrukturalnym. Zespoły z odpowiednim sprzętem i jasnymi wymaganiami dot. rezydencji danych mogą przejść bezpośrednio do kontrolowanej ewaluacji samohostowania.
