Kimi K3 selvhosting vs API i 2026: maskinvare & kostnader

TL;DR

I 2026 kan Kimi K3 selvhostes, men det offentlige vekt-repositoriet er på omtrent 1.56 TB og den offisielle vLLM-oppskriften starter på 8 NVIDIA GB300 GPU-er eller 8 AMD MI355X/MI350X GPU-er. Moonshot anbefaler 64 eller flere akseleratorer i en supernode-konfigurasjon for effektiv produksjonsinferens. For de fleste team er et hostet API fortsatt det lavest-risiko utgangspunktet.

Kimi K3 selvhosting vs. API i korte trekk

Kimi K3 selvhosting betyr å laste ned Moonshots åpne modellvekter og kjøre dem på infrastruktur som driftes av ditt eget team eller din sky-konto. Organisasjonen din er ansvarlig for GPU-kapasitet, modell-serving, skalering, sikkerhet, oppgraderinger, overvåking og pålitelighet.

Kimi K3 API-tilgang betyr å sende forespørsler til et leverandør-drevet endepunkt uten å operere den underliggende GPU-klyngen. Leverandøren håndterer modell-serving og kapasitet, mens teamet ditt betaler basert på bruk og hovedsakelig fokuserer på applikasjonsintegrasjon.

Moonshot introduserte Kimi K3 i sin offisielle tekniske blogg (https://www.kimi.com/blog/kimi-k3) 16. juli 2026 og slapp de fullstendige vektene innen 27. juli. Modellen er nå tilgjengelig som et open-weight-sjekkpunkt, men “åpne vekter” må ikke forveksles med “enkelt å kjøre lokalt”. For en bredere oversikt over kapabiliteter og benchmarker, se CometAPIs Kimi K3 access guide (https://www.cometapi.com/what-is-kimi-k3-benchmarks-capabilities-access-guide-in-2026/).

Den praktiske forskjellen handler ikke bare om modelltilgang. Det handler om hvem som eier infrastrukturen, kapasitetsplanleggingen, oppgraderingene og den operasjonelle risikoen.

Det sentrale spørsmålet er ikke om selvhosting er teknisk mulig. Det er om teamet ditt kan holde den nødvendige infrastrukturen tilstrekkelig opptatt — og drifte den tilstrekkelig pålitelig — til å slå hostet tilgang på total kostnad per akseptert oppgave.

Kan du selvhoste Kimi K3?

Ja. Moonshot har publisert de fullstendige vektene i det offisielle Kimi K3-repositoriet (https://github.com/MoonshotAI/Kimi-K3) under den egendefinerte Kimi K3-lisensen (https://github.com/MoonshotAI/Kimi-K3/blob/main/LICENSE). Offentlige utrullingsveier inkluderer vLLM (https://recipes.vllm.ai/moonshotai/Kimi-K3), SGLang (https://docs.sglang.io/cookbook/autoregressive/Moonshotai/Kimi-K3) og TokenSpeed (https://lightseek.org/tokenspeed/recipes/models#kimi-k3).

Men Kimi K3 er ikke en modell i arbeidsstasjonsklassen. Det er en Mixture-of-Experts-modell med 2,8 billioner parametere, 104 milliarder aktiverte parametere per token, 896 rutede eksperter, innebygde multimodale kapabiliteter, MXFP4-vekter, MXFP8-aktiveringer og et kontekstvindu på opptil 1,048,576 token.

Tallet 104B for aktiverte parametere beskriver mengden modellkapasitet som brukes ved hvert tokensteg. Det betyr ikke at bare 104B parametere må lagres. Ruteren kan velge ulike eksperter under generering, så hele ekspertssettet forblir en del av den deployerte modellen.

Kimi K3 selvhosting vs. API: infrastrukturkrav

Selvhosting av Kimi K3 krever et stort distribuert GPU-miljø, mens hostet API-tilgang fjerner behovet for å operere den underliggende modell-serving-klyngen. I 2026 starter den offisielle selvhostingsbaselinen på åtte NVIDIA GB300- eller AMD MI355X/MI350X GPU-er, mens API-brukere bare trenger standard applikasjonsinfrastruktur.

Forskjellen er ikke bare hvem som eier GPU-ene. Selvhosting gjør også teamet ditt ansvarlig for modell-lagring, flernode-nettverk, kapasitetsplanlegging, utrulling, skalering, overvåking, oppgraderinger og feilgjenoppretting. Med hostet API-tilgang flyttes mesteparten av dette ansvaret til leverandøren.

Maskinvarekrav for selvhosting

Den gjeldende offisielle vLLM-oppskriften (https://recipes.vllm.ai/moonshotai/Kimi-K3) lister følgende forutsetninger for å kjøre hele Kimi K3-sjekkpunktet:

• NVIDIA: minst 8x GB300 GPU-er
• AMD ROCm: minst 8x MI355X eller MI350X GPU-er
• Produksjonstrafikk: flernode-utrulling anbefales
• vLLM: versjon 0.27.0 eller nyere, med Kimi K3-image og dokumenterte utrullingsprofiler

Disse kravene representerer et dokumentert serving-gulv, ikke en garanti for at et system med åtte GPU-er vil tilfredsstille enhver produksjonsarbeidslast.

Moonshots lanseringsdokumentasjon (https://www.kimi.com/blog/kimi-k3#architecture-and-infrastructure) går lenger. For høyere inferenseffektivitet anbefaler den å deployere Kimi K3 på supernode-konfigurasjoner med 64 eller flere akseleratorer. Denne anbefalingen er spesielt relevant for team som sikter mot høy samtidighet, lange kontekster eller forutsigbar latens under last.

Flaskehalsen er ikke bare samlet GPU-minne. Kimi K3 aktiverer 16 av 896 rutede eksperter per token, så ekspert-parallelliserte utrullinger genererer betydelig all-til-alle-kommunikasjon mellom akseleratorer.

Den offisielle vLLM-oppskriften anbefaler kommunikasjons-backends som deepep_v2 for RDMA-miljøer og flashinfer_nvlink_one_sided for NVLink-basert kommunikasjon mellom noder. Som en konsekvens er ikke åtte GPU-er koblet gjennom et tregere nettverk operasjonelt likeverdige med åtte GPU-er inne i et høybåndbredde, tett sammenkoblet system.

Hvor mye lagring og kjøretidsminne trengs ved selvhosting?

Det offentlige Kimi K3-sjekkpunktet er cirka 1.56 TB, ifølge det offisielle Hugging Face-repositoriet (https://huggingface.co/moonshotai/Kimi-K3/tree/main).

En teoretisk nedre grense-beregning for 2,8 billioner parametere lagret med fire bit per parameter er:

2.8 trillion parameters × 4 bits ÷ 8
= 1.4 trillion bytes
= about 1.4 TB, or 1.27 TiB

Hvorfor er Kimi K3 vanskeligere å serve enn en standardmodell?

Kimi K3 er vanskeligere å serve fordi dens distribuerte MoE-arkitektur kombinerer all-til-alle-eksperttrafikk, planlegging av lang-kontekst-cache, modellspesifikk resonnementshistorikk og validering av verktøykall. Team må benchmarke interconnect-ytelse, parallellisering, prefill- og dekodeatferd, samtidighet og retry-håndtering, i stedet for å behandle den som et konvensjonelt endepunkt på én node.

Den offisielle vLLM-oppskriften (https://recipes.vllm.ai/moonshotai/Kimi-K3) fremhever flere produksjonsbetraktninger:

• Trafikk mellom noder trenger en passende all-til-alle-backend og et høybåndbredde kommunikasjonsstoff.
• MoE-backend endres med parallelliseringsstrategien og maskinvaretopologien.
• Tensor-parallellisering, ekspert-parallellisering og de dokumenterte disaggregerte prefill/decode-profilene må benchmarkes opp mot den reelle arbeidslasten.
• max-model-len, samtidighet og minneutnyttelse trenger eksplisitt tuning i stedet for standardverdier.
• K3 kan av og til emitere et verktøykall-format som dens egen parser ikke forventer; oppskriften anbefaler skjemavalidering og retry-håndtering.

Er 1M-token-konteksten “gratis” å bruke?

Nei. Moonshot anvender ikke et høyere per-token-trinn kun fordi en forespørsel bruker en lenger kontekst, men lange prompt øker fortsatt inntaks-token, prefill-arbeid, KV-cache-behov, latens og samtidighetspress. Konfigurer max-model-len rundt arbeidslasten du faktisk har tenkt å serve, i stedet for å aktivere maksimum som standard.

Applikasjonskompatibilitet betyr også noe. Ifølge Moonshots Kimi K3 API quickstart (https://platform.kimi.ai/docs/guide/kimi-k3-quickstart) resonerer K3 alltid og støtter reasoning_effort-verdiene low, high og max, med max som standard. Dette kan øke volumet av genererte token, men overheaden varierer etter oppgave og innsatsnivå. Mål resonnement og utgangstoken på ditt eget evalueringssett i stedet for å anta en fast multiplikator. For samtaler over flere meldinger og verktøykall, send tilbake hele assistant-meldingen, inkludert reasoning_content og tool_calls, i stedet for kun det synlige svaret.

Et hostet endepunkt fjerner det meste av arbeidet på klyngenivå, men det fjerner ikke applikasjonsnivåets validering, retry-logikk, latenstmåling eller håndtering av flerturn-state.

Hvor mye koster Kimi K3 API-et?

Per juli 2026 tar Moonshot $0.30 per 1M cache-hit inntaks-token, $3.00 per 1M cache-miss inntaks-token og $15.00 per 1M utgangstoken. Den effektive kostnaden avhenger sterkt av gjenbruk av prefiks-cache og utgangslengde, så team bør måle belastet bruk med produksjonsnære forespørsler i stedet for kun å sammenligne overskriftraten for input.

Moonshots offisielle Kimi K3 prisside (https://platform.kimi.ai/docs/pricing/chat-k3) lister:

Den direkte forespørsel-kostnadsformelen er:

API-kostnad =

(cache-hit input tokens ÷ 1M × $0.30)

• (cache-miss input tokens ÷ 1M × $3.00)
• (output tokens ÷ 1M × $15.00)

For eksempel koster en forespørsel med 300,000 inntaks-token og 30,000 utgangstoken:

• $1.35 hvis all input belastes som cache-miss input
• $0.54 hvis all input får cache-hit-prisen

Reelle arbeidslaster ligger vanligvis mellom disse to tilfellene. Cache-ytelse avhenger av hvor konsekvent applikasjonen gjenbruker et uendret prefiks og hvordan leverandøren implementerer caching.

Hostet prising varierer også etter leverandør. Per juli 2026 lister CometAPI Kimi K3 (https://www.cometapi.com/models/moonshotai/kimi-k3/) til $2.40 per 1M input-token og $12.00 per 1M utgangstoken — 20 % under Moonshots standard cache-miss-rater på $3.00 for input og $15.00 for output. Dette er imidlertid ikke en universell 20 % besparelse. Moonshot tar kun $0.30 per 1M cache-hit inntaks-token, så arbeidslaster med høy cache-hit-rate kan koste mindre via det offisielle API-et.

Bruk den live CometAPI-modellsiden som gjeldende priskilde, og se Kimi K3 API pricing guide (https://www.cometapi.com/kimi-k3-api-pricing/) for kostnadseksempler. Sammenlign begge ruter ved å bruke faktisk belastet bruk fra det samme evalueringssettet, inkludert cache-treff, resonnement-output, retries og akseptert-oppgave-rate.

Hvor mye koster selvhosting av Kimi K3?

Kimi K3 har ingen universell pris for selvhosting. Den totale kostnaden avhenger av klyngestørrelse, kontraktsvilkår, produktiv utnyttelse, nettverk, lagring, engineering og pålitelighetsmål. Et planleggingsscenario med åtte GPU-er kan allerede overstige $58,000 per måned kun i infrastruktur, mens Moonshots anbefalte produksjonstopologi med 64+ akseleratorer vil kreve en separat, langt større kostnadsmodell.

Bruk en fullstendig månedlig modell:

Månedlig selvhostet kostnad =

akselerator- eller klyngekostnad

• plattformengineering
• inferensdrift
• nettverk og lagring
• observabilitet og sikkerhet
• redundans og idle-headroom

Illustrerende åtte-GPU-infrastrukturscenarier

Tabellen under bruker 730 timer per måned og tre hypotetiske satser for en alltid-tilgjengelig klynge i minimumsstørrelse. Disse tallene er planleggingsinput, ikke pristilbud. De representerer heller ikke Moonshots anbefaling om 64+ akseleratorer for produksjon.

Å legge til engineering, overvåking, redundans, nettverk og inaktiv kapasitet øker terskelen for selvhosting. En større produksjonstopologi øker den ytterligere.

Utnyttelse betyr noe, men det finnes ingen universell terskel

Det finnes ingen universell GPU-utnyttelsesprosent der selvhosting blir billigere. Nivået avhenger av målt throughput, maskinvarekostnad, latenstmål, redundans og om maskinvaren er en ny utgift eller allerede eies.

Spor produktiv utnyttelse i stedet:

Produktiv utnyttelse =

klyngetimer brukt på akseptert arbeidslast

÷ totale provisjonerte klyngetimer

Et høyt utnyttelsestall er ikke nok hvis forespørsler bommer på latenst- eller kvalitetsmål. Tilsvarende kan et lavere tall fortsatt være akseptabelt når maskinvaren allerede er bundet til andre arbeidslaster. Bruk utnyttelse som input i TCO-modellen, ikke som en selvstendig beslutningsregel.

Den mest nyttige nevneren er ikke rå forespørsler. Det er akseptert ekvivalent arbeid:

Break-even aksepterte oppgaver =

total månedlig selvhostet kostnad

÷ hostet API-kostnad per akseptert ekvivalent oppgave

Inkluder feil, retries, latenstbrudd, menneskelig gjennomgang og degraderte utdata på begge sider. To endepunkter som bruker de samme vektene, er ikke økonomisk likeverdige hvis ett bommer på applikasjonens pålitelighets- eller kvalitetsmål.

Hva tillater Kimi K3-lisensen?

Den egendefinerte Kimi K3-lisensen gir brede rettigheter til å bruke, kopiere, modifisere, finjustere, deployere, distribuere, viderelisensiere og selge programvaren og modellvektene. Den inkluderer også vilkår som er viktige for store Model-as-a-Service-virksomheter og høyskala kommersielle produkter.

For de fleste interne utrullinger og ordinære kommersielle applikasjoner forbyr ikke lisensen bruk som utgangspunkt. Team som selger direkte modelltilgang, driver et modell-API, eller nærmer seg de angitte tersklene, bør få juridisk gjennomgang av den eksakte produktutformingen og selskapsstrukturen.

“Open-weight” er en mer presis beskrivelse enn “fullt åpen kildekode”, fordi bruken styres av denne egendefinerte lisensen snarere enn kun en standard permisiv programvarelisens.

API vs selvhostet Kimi K3: Hva bør du velge?

For de fleste team i 2026 er hostet API-tilgang det beste første steget fordi etterspørsel, cache-atferd og kostnad per akseptert oppgave fortsatt er usikre. Velg selvhosting først når vedvarende utnyttelse, datakontrollkrav eller runtime-tilpasning er målt opp mot den komplette kostnaden for en like pålitelig produksjonsutrulling.

Velg et hostet API når:

• Trafikken er ny, variabel eller vanskelig å prognostisere.
• Du trenger produksjonstilgang uten en GPU-anskaffelsessyklus.
• Teamet ditt ikke allerede drifter distribuert MoE-inferens.
• Bruken ligger godt under beregnet break-even-terskel.
• Administrert skalering, oppdateringer og kapasitet er mer verdifullt enn runtime-kontroll.
• Leverandørens datahåndtering og tjenestevilkår tilfredsstiller kravene dine.

Velg selvhosting når:

• Etterspørselen er vedvarende og forutsigbar nok til å holde klyngen høyt utnyttet.
• Organisasjonen din allerede har distribuert GPU-infrastruktur og inferensingeniører.
• En kontrollert datapath, dedikert miljø eller tilpasset retainment-policy er et hardt krav.
• Du trenger direkte kontroll over modellversjoner, planlegging, runtime-innstillinger eller finjusterte vekter.
• Målt hostet forbruk nærmer seg den komplette interne kostnaden for en like pålitelig utrulling.
• Juridisk gjennomgang bekrefter at tiltenkt bruk passer Kimi K3-lisensen.

Vurder en hybrid utrulling når:

• Grunnlasten er forutsigbar, men trafikken har store topper.
• Selvhostet kapasitet kan serve jevne arbeidslaster mens et API håndterer overskudd.
• Du trenger et administrert fallback for vedlikehold eller regionale feil.
• Prompter, verktøyskjema, akseptansetester og modellatferd forblir portabel på tvers av begge ruter.

En hybrid strategi øker kompleksiteten i ruting og observabilitet, så den bør løse et målt kapasitets- eller robusthetsproblem fremfor å eksistere kun som et arkitektonisk preferansevalg.

Hvordan bør du teste break-even-punktet mellom API og selvhosting?

Kjør det samme produksjonsnære evalueringssettet gjennom hostede og selvstyrte ruter, og sammenlign deretter kostnad per akseptert oppgave — ikke rå tokenpris eller GPU-leie alene. En troverdig test bør måle cache-treff, utgangstoken, latens, retries, kvalitet, samtidighet, engineeringtid, inaktiv kapasitet og feilgjenoppretting over minst én representativ driftsperiode.

1. Lag et representativt evalueringssett. Inkluder 30 til 50 oppgaver som dekker faktisk miks av koding, lang kontekst, visjon og verktøykall.
2. Mål hostet bruk i minst én uke. Registrer input-token, cache-hit-token, output-token, latens, retries, feil og akseptert-oppgave-rate.
3. Test den foreslåtte selvhostede topologien. Bruk tiltenkte kontekstgrenser, samtidighet, parallellisering og pålitelighetsinnstillinger — ikke en demonstrasjon for én bruker.
4. Beregn den komplette månedlige kostnaden. Inkluder klyngetid, engineering, observabilitet, redundans, lagring, nettverk, sikkerhet og idle-headroom.
5. Sammenlign økonomien per akseptert oppgave. Bekreft at kvalitet, latens og pålitelighet er likeverdige før du sammenligner kostnader.
6. Kjør feilsceanrier. Test node-tap, utrullings-rollback, køvekst, lange kontekster i burst og malformede verktøykall.
7. Godkjenn selvhosting først når den operasjonelle saken er målbar. Strategisk kontroll kan rettferdiggjøre høyere kostnad, men trade-offen bør være eksplisitt.

For en hostet baseline tilbyr CometAPI (https://www.cometapi.com/quickstart/) en OpenAI-kompatibel rute. Hold prompter, verktøy og akseptansekriterier uendret når du tester en annen leverandør eller et selvhostet endepunkt.

FAQ

Kan Kimi K3 kjøre på én enkelt GPU?

Ikke under den offisielle veiledningen for full-modell-serving. vLLM-oppskriften starter på åtte NVIDIA GB300 GPU-er eller åtte AMD MI355X/MI350X GPU-er og anbefaler flernode-infrastruktur for reell produksjonstrafikk. Den endelige topologien avhenger av kontekstlengde, samtidighet, latens og redundansmål.

Hvor mye lagring krever Kimi K3 selvhosting?

Det offentlige Hugging Face-repositoriet er cirka 1.56 TB. Kravene til kjøretidsminne er høyere fordi serving også trenger kvantiseringsmetadata, aktiveringer, KV-cache, kommunikasjonsbuffere og samtidighetshode-rom.

Er Kimi K3 åpen kildekode?

Kimi K3 beskrives best som open-weight under den egendefinerte Kimi K3-lisensen. Vektene er offentlig tilgjengelige og kan modifiseres og deployeres, men store MaaS-operatører og svært store kommersielle produkter møter ytterligere vilkår.

Er selvhosting av Kimi K3 billigere enn API-tilgang?

Det kan være billigere ved høy, vedvarende utnyttelse, men det finnes ikke et universelt break-even-punkt. Sammenlign den komplette månedlige kostnaden for en like pålitelig utrulling med hostet kostnad per akseptert oppgave, inkludert cache-atferd, retries, latens og inaktiv kapasitet.

Hvilke inferensemotorer støtter Kimi K3?

Moonshot anbefaler for tiden vLLM, SGLang og TokenSpeed. vLLM-oppskriften gir den tydeligste offentlige maskinvarebaselinen, mens hver motor fortsatt trenger arbeidslastspesifikk validering.

Test den hostede ruten før du kjøper infrastruktur

Kimi K3s åpne vekter skaper en reell selvhostingsmulighet, men sjekkpunktstørrelsen og kravene til distribuert serving gjør det til et infrastrukturprosjekt snarere enn en rutinemessig modelldistribusjon.

Start med et fast evalueringssett. Mål token-bruk, cache-atferd, latens, retries og akseptert-oppgavekvalitet via et hostet endepunkt. Sammenlign deretter disse resultatene med en lasttestet selvhostet topologi ved å bruke den komplette månedlige kostnaden — ikke bare GPU-regningen.

CometAPI tilbyr en OpenAI-kompatibel rute for å etablere den baselinen. Bruk How to Use Kimi K3 API guide (https://www.cometapi.com/how-to-use-kimi-k3-api/) for implementasjonsdetaljer, CometAPI quickstart (https://www.cometapi.com/quickstart/) for migrasjonstrinn, og den live Kimi K3-modellsiden (https://www.cometapi.com/models/moonshotai/kimi-k3/) og prissiden (https://www.cometapi.com/pricing/) for gjeldende tilgjengelighet og priser.