Bygg med CometAPITrenger du ett API for flere modeller?Test arbeidsflyten i Playground, og opprett deretter en API-nøkkel når modellen og kostnaden passer bruksområdet ditt.
Distribuer Kimi K3.1 Pro på en Linux-GPU-server, og koble deretter en lokal applikasjon til dens inferens-endepunkt. Denne gjennomgangen bruker én NVIDIA B300-node med åtte GPU-er og vLLM. Du trenger skalltilgang til serveren, kompatible drivere og lagring for hele sjekkpunktet. Start med å fullføre én kort tekstforespørsel før du tester lengre input eller agent-arbeidsflyter.
Uten egnede GPU-er kan du kjøre applikasjonen lokalt og koble den til den offisielle Kimi API-en eller en tredjepartsleverandør som CometAPI.
Viktige punkter
Modellens 104B aktive parametere representerer ikke hele lagringsbehovet.
Maskinvarekompatibilitet omfatter GPU-minne, interconnects, kvantisering og inferens-kjerner.
Gjennomgått for klarhet, kildeangivelse og gjeldende API-terminologi.
Sterke benchmark-resultater gjør modellen verdt å teste, men de garanterer ikke tilsvarende ytelse i din applikasjon.
Et fungerende inferens-endepunkt inkluderer ikke automatisk en nettleser, kode-sandkasse eller komplett agent-runtime.
Sammenlign selvhosting og API-tilgang etter kostnad per vellykket oppgave, inkludert nye forsøk og vedlikehold.
Hva er Kimi K3.1 Pro?
Kimi K3.1 Pro er Moonshot AI sin multimodale modell med åpne vekter for koding, dokumentanalyse og verktøybruk. Hovedspesifikasjoner er listet nedenfor, basert på den offisielle modellkortet .
Modellen aktiverer 104B parametere per token, men distribusjon krever fortsatt hele sjekkpunktet med 2.8T parametere. Inferensmotoren må også støtte KDA- og Gated DSA-lagene og MXFP4-kvantisering.
Hvilken maskinvare trenger du for å kjøre Kimi K3.1 Pro lokalt?
Tabellen nedenfor oppsummerer de vLLM-konfigurasjonene som er relevante for denne veiledningen. Gjennomgangen bruker én B300-node med åtte GPU-er; distribusjoner på GB300 og AMD krever tilsvarende konfigurasjoner.
Maskinvare
Dokumentert rute
Planleggingsnotater
NVIDIA B300
Én node med åtte GPU-er, TP8
Grunnlag for gjennomgangen nedenfor
NVIDIA GB300
Åtte GPU-er fordelt på to brett, TP8
Krever flernode-konfigurasjon og interconnect-oppsett
AMD MI355X
Node med åtte GPU-er og AMD-spesifikk konfig
Bruk ROCm/AITER-løpet; ikke gjenbruk NVIDIA-miljøinnstillinger
Én 24–32 GB konsument-GPU
Utilstrekkelig for direkte lasting av fullstendig sjekkpunkt
Ikke et praktisk mål for denne tutorialen
Kun for skala: 2.8T parametere ville oppta omtrent 5.6 TB ved BF16, 2.8 TB ved åtte biter, eller 1.4 TB ved idealiserte fire biter. Dette er rå beregninger av parameterlagring, ikke faktiske sjekkpunktstørrelser eller minimum VRAM for kjøring. Blandet presisjon og metadata endrer filstørrelsen; cache og allokeringer under kjøring øker kravet for serving.
Reserver NVMe-kapasitet for full nedlasting, midlertidige filer og en rollback-kopi. På flernodesystemer, valider kommunikasjonen før du laster modellen.
Hvordan distribuere Kimi K3.1 Pro
Bruk selvhosting hvis du har egnet maskinvare; ellers, start med en hostet API. Stegene nedenfor bruker vLLM, med SGLang som et alternativ mot slutten av denne seksjonen. Sammenlign hostingkostnader etter at du har en fungerende forespørsel.
Kjør oppsett-, nedlastings-, oppstarts- og verifiseringskommandoene i et Bash-skall på GPU-serveren. Hvis du jobber fra en laptop, koble til den serveren med SSH først. Python-klienten kan senere kjøre på begge maskiner ved å bruke tilkoblingsinstruksjonene nedenfor.
Denne gjennomgangen følger den offisielle distribusjonsoppskriften; den er ikke uavhengig testet for denne artikkelen.
1. Sjekk GPU-synlighet, lagring og tilkobling
Start med grunnleggende infrastrukturkontroller:
nvidia-smi
nvidia-smi topo -m
df -h
Bekreft at alle målgpuene er synlige og at modelldirektivet har tilstrekkelig plass. Sett av ekstra lagring til nedlastingscache, logger og fremtidige sjekkpunktversjoner.
For flernodedistribusjoner, verifiser kommunikasjon mellom noder før du forsøker modelloppstart.
Hold den første milepælen smal: last sjekkpunktet og fullfør én kort tekstforespørsel. Dette gjør feil enklere å diagnostisere.
2. Klargjør serving-miljøet
Bruk en Linux-vert med åtte B300-GPU-er for dette enkeltnode-eksemplet. I et CUDA-miljø som er kompatibelt med den publiserte oppskriften, opprett et isolert miljø og installer serving-verktøyene:
Versjonsgulvet garanterer ikke kompatibilitet med alle drivere eller hjul. Hvis maskinvareoppskriften krever en dedikert container eller build, bruk det miljøet i stedet. Lås den versjonen som er testet og fungerer før produksjon.
3. Last ned hele sjekkpunktet
Installer Hugging Face-CLI og last ned modellrepoet:
Behold konfigurasjons-, tokenizer-, prosessorfiler og vektindeks sammen med vektshardene. Å kopiere bare utvalgte tensorfiler kan gjøre distribusjonen ufullstendig.
For reproducerbare produksjonsdistribusjoner, registrer og lås repo-revisjonen du har validert. Gjennomgå repoets tilpassede lisens før kommersiell bruk.
4. Start vLLM-serveren
Den offisielle oppskriften spesifiserer vLLM 0.34.0 eller nyere. Start med maskinvare-spesifikk miljøkonfigurasjon, og lås deretter versjonen og avhengighetene som består testene dine.
Etter forberedelse av miljøet, bruk følgende grunnkommando. Den starter åtteveis tensor-parallellisme og begrenser den innledende kontekstvinduet til 32,768 tokens:
Navnet kimi-local er et applikasjonsvendt alias. Bruk samme navn i påfølgende forespørsler.
Innstillingen 32,768 tokens er et konservativt utgangspunkt for denne gjennomgangen, ikke modellens maksimale støttede kontekst.
Alternativet --trust-remote-code tillater at tilpasset repo-kode lastes. Kombiner det med en gjennomgått og låst sjekkpunktrevisjon.
Her refererer 127.0.0.1 til maskinen som kjører klienten. curl-sjekkene nedenfor kjøres på GPU-serveren, hvor de når dens inferensprosess. For å bruke Python-klienten fra laptopen din, åpne en SSH-tunnel i et separat laptop-terminalvindu og hold den kjørende:
ssh -N -L 8000:127.0.0.1:8000 user@gpu-server
Bytt ut user@gpu-server med din SSH-pålogging og serveradresse. Med denne tunnelen åpen kan laptop-klienten bruke http://127.0.0.1:8000/v1. Hvis port 8000 allerede er i bruk på laptopen, velg en annen lokal port og oppdater klient-URL-en.
En finish_reason som indikerer om genereringen ble fullført eller nådde sin grense.
GPU-minnefeil eller ikke-støttede operasjoner.
Resonnering kan bruke deler av generasjonsbudsjettet. Hvis forespørselen når sin grense før et endelig svar produseres, øk budsjettet og prøv på nytt før du konkluderer med at serveren er ødelagt.
6. Koble til en lokal Python-applikasjon
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 er en plassholder for denne loopback-only serveren uten API-nøkkel-autentisering. Bruk din konfigurerte legitimasjon for et autentisert endepunkt. Valider bildeinndata og verktøyutførelse separat før du kobler til en agent.
SGLang-alternativ
For SGLang, bruk den offisielle maskinvare-spesifikke kokeboken. Velg B300, Unified, og Low-Latency (TP8) for nærmeste match til denne enkeltnode-gjennomgangen. Sjekk den viste verifiseringsstatusen; en generert konfigurasjon er ikke nødvendigvis en testet konfigurasjon.
På GPU-serveren, installer Docker og konfigurer NVIDIA Container Toolkit, opprett deretter en container med det nedlastede sjekkpunktet montert på /models/Kimi-K3.1-Pro. Stopp vLLM først slik at begge motorer ikke konkurrerer om de samme GPU-ene.
Inne i containeren, lim inn den komplette oppstartskommandoen produsert av kokeboken for din valgte konfigurasjon. Bytt modellstien til /models/Kimi-K3.1-Pro, sett tjenestehost til 0.0.0.0 og port til 30000, og bevar maskinvare-spesifikke flagg. Containeren må lytte på sitt nettverksgrensesnitt for at Docker-portviderekobling skal fungere; vertsiden-porten ovenfor forblir bundet til loopback. Vent på meldingen om at tjenesten er klar før testing.
I et andre skall på GPU-serveren, list den tjente modellen, og send deretter en forespørsel ved å bruke den eksakte modell-ID-en som returneres:
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}"
En vellykket respons bør inneholde et endelig svar. Hvis oppstart feiler, inspiser containerloggene og bekreft at valgt maskinvareoppskrift og image stemmer. For laptop-tilgang, bruk samme SSH-tunnelmønster med port 30000. Se SGLang Docker-installasjonsveiledningen for containerens forutsetninger.
Hvordan yter Kimi K3.1 Pro på tvers av benchmarks?
Bruk de offisielle evalueringsresultatene nedenfor for å velge oppgaver til din distribusjonstest. Disse poengene beskriver det publiserte evalueringsoppsettet; de måler ikke den lokale serveren som er konfigurert i denne veiledningen.
Følgende tabell viser utvalgte resultater og deres posisjoner innenfor sammenligningssettet som er publisert i modellkortet.
Benchmark og offisielle resultater
Modellscore
Plassering innen den sammenligningen
Terminal-Bench 4.0
65.7
Andre
SWE Marathon v1.1
51.7
Første
Program Bench
31.5
Fjerde
OfficeQA Pro v2
64.4
Første blant rapporterte resultater
Frontier Finance
58.6
Andre
Resultatene støtter testing av modellen for utvidede ingeniøroppgaver og dokumentarbeidsflyter. Kimi K3.1 Pro leder denne sammenligningen på SWE Marathon, men rangerer som nummer fire på ProgramBench, noe som gjør begge til nyttige kandidater for applikasjonsspesifikk testing.
Disse plasseringene er beregnet innen den offisielle sammenligningstabellen, ikke en live global toppliste. Evalueringsrammeverk, verktøy, resonneringsbudsjetter og utvalgsvalg varierer mellom benchmarks.
For en distribusjonsbeslutning, bygg et lite evalueringssett fra faktisk arbeid: repository-fikser, tverrdokument-spørsmål og flertrinns verktøyoppgaver. Mål fullføringskvalitet, menneskelige rettelser og medgått tid. Publiserte poeng er nyttige for shortlisting; applikasjonstester avgjør om distribusjonen er verdt det.
Hvordan kan du optimalisere lokal inferens for Kimi K3.1 Pro?
Kontroller kontekst og samtidighet
Når korte forespørsler fungerer, test lengre dokumenter, bilder, flersamtaler og verktøykall separat.
Spor latens for første token, utgangstokens per sekund og topp GPU-minne ved din tiltenkte kontekstkunnskap og samtidighet. Registrer også oppgavesuksess og kostnad per vellykket oppgave, slik at raskere utdata ikke skjuler flere nye forsøk eller menneskelige rettelser.
Endre én stor variabel om gangen. Å øke kontekstlengde, samtidighet og optimaliseringsinnstillinger samtidig gjør ytelsesregresjoner vanskelige å forklare.
Velg resonneringsinnsats og cache-innstillinger med omhu
Bruk lav, høy eller maks resonneringsinnsats i henhold til oppgaven. Start med lav for grensesnittkontroller, og sammenlign deretter høy og maks på vanskelige oppgaver ved å bruke både fullføringskvalitet og medgått tid. En lengre resonneringsspor er i seg selv ikke bevis på et bedre resultat.
For lange økter, evaluer cachekapasitet og prefiks-gjenbruk før du legger til spekulativ dekoding eller mer samtidighet. Behold en kjent god grunnlinje og endre én innstilling om gangen.
Hvorfor kan verktøykall feile etter distribusjon av Kimi K3.1 Pro?
Applikasjonen din utfører verktøykall, returnerer resultatene og fortsetter samtalen. Bevar hele assistentmeldingen — inkludert reasoning_content og tool_calls — og returner hvert verktøyresultat med sin matchende tool_call_id.
Håndtering over flere turer er også viktig. Modellens bruksveiledning krever bevaring av hele assistentmeldingen, inkludert resonnerings- og verktøykall-felter, snarere enn å beholde bare den endelige teksten.
Symptom
Første kontroller
Ukjent modellarkitektur
Runtime-versjon, tilpasset kode og konfigurasjon
Tom for minne under lasting
GPU-kapasitet, parallellisme og konkurrerende prosesser
Korte forespørsler fungerer, lange feiler
Kontekstgrense, cachekapasitet og samtidighet
Verktøykall kan ikke tolkes
Parserinnstillinger og verktøyskjema
Agenten stopper etter å ha bedt om et verktøy
Applikasjonsutførelse og håndtering av verktøyresultat
Flersamtale-svar blir inkonsistente
Manglende assistentmeldingsfelt
Bruk en minimal reproduksjonsforespørsel for å isolere hver feil. Når den fungerer, reintroduser applikasjonens tilleggsinnstillinger én om gangen.
Bør du selvhoste eller bruke en hostet API?
Velg selvhosting når du trenger kontroll over vekter, infrastruktur eller datalokasjon og kan holde GPU-ene nyttig opptatt. For innledende evaluering eller variabel etterspørsel, sammenlign den offisielle Kimi API-en og CometAPI med samme prompt og akseptkriterier. Bekreft hver tjenestes modelltilgang, støttede parametere, kvoter og vilkår for datahåndtering.
Kostnad eller driftsfaktor
Selvhostet
Offisiell Kimi API / CometAPI
Kapasitetskostnad
GPU-kjøp eller leie, inkludert tomgangstid
Fakturert API-bruk; sjekk hver leverandørs gjeldende priser
Lagring og nettverk
Sjekkpunktslagring, cache og nettverkskostnader
Eventuelle applikasjonsside-lagrings- og nettverkskostnader
Drift
Distribusjon, overvåking, oppgraderinger og gjenoppretting
Integrasjon, kvotehåndtering og forespørselsmonitorering
Nye forsøk
Inkluder deres GPU-tid i beregnede kostnader
Inkluder deres tokens eller kall i API-kostnader
Menneskelig gjennomgang
Regn rettingstid med samme sats
Regn rettingstid med samme sats
Best egnet
Jevn etterspørsel og infrastrukturkontroll
Evaluering og variabel etterspørsel
En nyttig sammenligning er:
Kostnad per vellykket oppgave = (GPU-beregning eller API-kostnader + lagring og nettverk + drift + menneskelig retting) / vellykket fullførte oppgaver.
Bruk kostnader og antall vellykkede oppgaver fra samme måleperiode. Inkluder mislykkede forsøk og nye forsøk i beregnings- eller API-totalen én gang; ikke legg til en andre kostnad for nytt forsøk. For en hybrid arbeidsflyt, inkluder både beregnings- og API-kostnader. Tell unike fullførte oppgaver, ikke forespørselsforsøk.
En underutnyttet server kan forbli kostbar selv når dens teoretiske gjennomstrømning er utmerket. Omvendt kan et team med eksisterende infrastruktur, jevn etterspørsel og strenge krav til data gi betydelig verdi fra selvhosting.
Bruk identiske prompts og akseptkriterier når du sammenligner distribusjonsruter. Inkluder ende-til-ende-latens og utgangskvalitet i beslutningen.
Prøv det hostede endepunktet uten å laste vekter
Den offisielle Kimi API-quickstarten bruker endepunktet nedenfor. Sett MOONSHOT_API_KEY i miljøet ditt og bekreft modelltilgang i kontoen din. Denne forespørselen kjører på leverandørens infrastruktur.
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)
For Kimi K3.1 Pro API i CometAPI, sett COMETAPI_API_KEY i miljøet ditt og bekreft at kontoen din har tilgang til den forespurte modellen. Forespørselen kjører eksternt:
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)
Sammenlign resultatet med ditt lokale endepunkt ved å bruke samme akseptkriterier. Sjekk gjeldende rutepris og støttede parametere før du estimerer produksjonskostnader.
Konklusjon
Selvhosting av Kimi K3.1 Pro er praktisk med en støttet GPU-konfigurasjon og et samsvarende inferensmiljø. Bruk distribusjonstrinnene ovenfor for å etablere et fungerende endepunkt, mål deretter oppgavekvalitet, latens og kostnad på din egen arbeidsmengde. Velg en hostet API hvis du fortsatt validerer applikasjonen eller ikke har egnet maskinvare.
FAQ
Kan en vanlig laptop kjøre hele modellen?
En vanlig laptop er ikke et praktisk mål for kapasitetskravene til det originale sjekkpunktet. Den kan fungere som en klient koblet til din egen inferensserver eller en hostet API.
Teller installasjon av skrivebordsapplikasjonen som lokal distribusjon?
Applikasjonens installasjonslokasjon fastslår ikke hvor inferens foregår. Selvhosting krever at modellvektene og inferensprosessen kjører i infrastruktur du kontrollerer.
Hvorfor trenger modellen så mye minne hvis bare 104B parametere er aktive?
Ulike tokens kan velge forskjellige eksperter. Aktive parametere beskriver deltakelse i beregning; distribusjon må fortsatt lagre og få tilgang til hele settet med vekter.
Kan jeg umiddelbart aktivere full million-token kontekst?
Øk kontekstlengden gradvis og mål GPU-minnebruk ved din mål-samtidighet. Modellen støtter 1,048,576 tokens, men den brukbare serving-kapasiteten avhenger av cache- og parallellismeinnstillinger.
Vil lokal distribusjon reprodusere publiserte benchmark-poeng?
Ikke automatisk. Kvantisering, resonneringsbudsjetter, verktøy, prompts og evalueringsrammeverk kan alle påvirke resultatene. Valider konfigurasjonen mot dine egne oppgaver.
Bør jeg teste via en API før jeg kjøper maskinvare?
Hvis du ikke har fastslått at modellen oppfyller kvalitetskravene dine, gir API-testing et innledende grunnlag med mindre infrastrukturarbeid. Team med egnet maskinvare og tydelige krav til dataresidens kan gå direkte til en kontrollert selvhostingsevaluering.
