Kimi K3 zelf hosten: hardwarevereisten en berekeningen

Wat er nodig is om Kimi K3 zelf te hosten

Het zelf hosten van Kimi K3 betekent dat u ruimte moet vinden voor 2,8 biljoen parameters. Moonshot heeft de open gewichten gepubliceerd in MXFP4, wat neerkomt op ongeveer een halve byte per gewicht. De gewichten alleen beslaan dus ruwweg 1.4 TB, nog voordat u ook maar één token aan cache toewijst. Geen enkele accelerator die momenteel te koop is, kan dit alleen aan. K3 is een model voor meerdere nodes; voor één server is het antwoord nee.

Dat is het oordeel. Alles hieronder is de rekenkunde die erachter zit, omdat u deze berekeningen bij de volgende release opnieuw kunt gebruiken. Verschillende infrastructuurleveranciers hebben in de weken na de aankondiging op 17 juli 2026 implementatiehandleidingen voor K3 gepubliceerd, en elk daarvan ging ervan uit dat u al over een cluster beschikte. Deze pagina begint bij de andere kant: wat het kost, wat u in plaats daarvan kunt draaien en hoe u bepaalt in welke van die twee situaties u zich bevindt.

Totaal aantal parameters en actieve parameters zijn niet gelijk

K3 is een Mixture of Experts-model. MoE (Mixture of Experts) splitst het netwerk in vele subnetwerken en laat een router per token een selectie hiervan kiezen. De modelkaart vermeldt 2,8T totale parameters en 104B geactiveerde parameters per token, verdeeld over 896 gerouteerde experts waarvan er 16 worden geactiveerd voor elk willekeurig token, verspreid over 93 lagen.

Deze twee parameteraantallen beantwoorden verschillende vragen, en het verwisselen ervan is de meest gemaakte fout in elke discussie over "kan ik dit draaien".

Actieve parameters bepalen de rekenkosten. Een token wordt vermenigvuldigd met ongeveer 104B parameters, dus de doorvoersnelheid die u mag verwachten lijkt op die van een 104B dense model in plaats van een 2,8T model. Dat is de hele reden om een MoE te bouwen.

Totale parameters bepalen de geheugenkosten. De router kan bij elk token een willekeurige expert selecteren, dus elke expert moet in het geheugen aanwezig zijn voordat het eerste verzoek binnenkomt. U kunt geen 104B in VRAM houden en de rest op aanvraag ophalen, omdat het ophalen binnen microseconden voltooid zou moeten zijn en een PCIe-verbinding verplaatst tientallen gigabytes per seconde. Mensen proberen het wel. Het streamen van experts vanaf NVMe verandert een model dat tientallen tokens per seconde zou moeten genereren in een model dat elke paar seconden één token genereert.

Het is dus goedkoop om te berekenen en duur om op te slaan. Baseer de hardware op 2,8T. Baseer uw verwachtingen voor de snelheid op 104B.

Bytes per gewicht, en waar de terabytes vandaan komen

Aantal parameters maal bytes per gewicht. Dat is de volledige formule voor de gewichten.

[
  {
    "label": "bf16",
    "bytes_per_weight": 2,
    "weights_tb": 5.6
  },
  {
    "label": "fp8",
    "bytes_per_weight": 1,
    "weights_tb": 2.8
  },
  {
    "label": "4-bit (MXFP4, as shipped)",
    "bytes_per_weight": 0.5,
    "weights_tb": 1.4
  },
  {
    "label": "2-bit",
    "bytes_per_weight": 0.25,
    "weights_tb": 0.7
  }
]

K3 is getraind met quantisation-aware training en uitgebracht met MXFP4-gewichten en MXFP8-activaties, dus de 4-bit rij is de werkelijke waarde. De rijen daarboven dienen als schaalvergelijking: bij bf16 zou hetzelfde model 5.6 TB vereisen. MXFP4 slaat bovendien één gedeelde 8-bit schaalwaarde op voor elk blok van 32 gewichten, wat ongeveer 6 procent toevoegt. Daarom zit de gepubliceerde repository dichter bij 1,5 TB dan bij een zuivere 1.4 TB.

Dit sluit de gebruikelijke uitweg af. "Gewoon kwantiseren" helpt hier niet, omdat het uitgebrachte checkpoint al 4-bit is. Teruggaan naar 2-bit zou de gewichten op 0.7 TB brengen en ten koste gaan van een nauwkeurigheid die voor dit checkpoint door niemand is gemeten. U zou dan nog steeds ver buiten het bereik van een enkele kaart vallen.

Hoeveel GPU's heeft Kimi K3 nodig

[
  {
    "config": "H100 80GB",
    "hbm_per_gpu_gb": 80,
    "gpus_for_weights": 18
  },
  {
    "config": "H200 141GB",
    "hbm_per_gpu_gb": 141,
    "gpus_for_weights": 10
  },
  {
    "config": "B200 192GB",
    "hbm_per_gpu_gb": 192,
    "gpus_for_weights": 8
  },
  {
    "config": "GB300 288GB",
    "hbm_per_gpu_gb": 288,
    "gpus_for_weights": 5
  }
]

Beschouw deze aantallen als een ondergrens, niet als een streefwaarde. Ze tellen enkel de gewichten: geen KV-cache, geen activatiebuffers, geen fragmentatie door de allocator en geen ruimte voor een tweede gelijktijdige aanvraag. Ze gaan bovendien uit van een parallelle splitsing die gelijkmatig verdeelt, wat bij 93 lagen en 896 experts niet altijd mogelijk is.

De gepubliceerde richtlijnen liggen aanzienlijk hoger dan deze ondergrens. Sinds augustus 2026 adviseert Moonshot een supernode van 64 of meer accelerators, en het SGLang-kookboek levert een H100-configuratie opgebouwd uit vier 8-GPU-nodes, 32 GPU's en 2.560 GB aan totaal geheugen, tegenover een ondergrens van 18 kaarten. Dat verschil is geen verspilling. Het is de ruimte voor KV-cache, activatiegeheugen en de marge die de server in staat stelt om vele aanvragen tegelijk te verwerken. Zelfs de meest toegankelijke rij, 5 GB300-klasse kaarten, beschrijft een machine die de meeste providers niet als een enkele SKU verhuren.

De KV-cache is het onderdeel dat mensen vaak verrast

Gewichten zijn een vaste kostenpost. De KV-cache (key value) is dat niet: deze groeit mee met de contextlengte en nogmaals met elke gelijktijdige gebruiker. Voor standaard attention is de formule bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element, en vervolgens vermenigvuldigt u dit met de contextlengte en de gelijktijdigheid.

Hier is een uitgewerkt voorbeeld, en het is slechts een voorbeeld: 64 lagen, 8 KV-heads, head-dimensie 128, fp8. Dat geeft 2 64 8 128 1 = 131.072 bytes, oftewel 128 KiB per token.

[
  {
    "label": "8k context",
    "kv_gib_per_user": 1
  },
  {
    "label": "32k context",
    "kv_gib_per_user": 4
  },
  {
    "label": "128k context",
    "kv_gib_per_user": 16
  },
  {
    "label": "1M context",
    "kv_gib_per_user": 128
  }
]

Eén gebruiker met een context van 128k kost 16 GiB. Eén gebruiker met de volledige miljoen kost 128 GiB, wat voor één gesprek meer is dan wat een enkele kaart kan bevatten.

K3 gebruikt geen standaard attention, en dat laatste getal is de reden waarom. De 93 lagen bestaan uit 69 KDA-lagen (Kimi Delta Attention) en 24 Gated MLA-lagen (multi-head latent attention). KDA behoudt een recurrente status van vaste grootte in plaats van een cache die met elk token groeit, en MLA comprimeert key en value tot één latent vector van lage rang. Hierdoor liggen de werkelijke kosten per token ver onder het uitgewerkte voorbeeld. Moonshot heeft de latente dimensies niet gepubliceerd, dus ik zal geen cijfer per gebruiker aan K3 zelf toekennen. Meet het in plaats daarvan zelf: start de server met een kleine --max-model-len, monitor het geheugengebruik met nvidia-smi en verhoog de limiet totdat de toewijzing mislukt.

De vorm van de redenering blijft behouden in de volgende release. Als een model een context van een miljoen tokens adverteert en niets vermeldt over het attention-ontwerp, ga er dan vanuit dat de cache de beperkende factor is totdat iemand het tegendeel bewijst.

Tier 1: het cluster per uur huren

Dit is de enige tier die K3 zelf draait. U koopt de hardware niet. U huurt deze voor de uren die u nodig heeft en stopt het gebruik daarna.

[
  {
    "label": "1 GPU, always on",
    "gpu_hours": 720,
    "usd_cost": "1,800"
  },
  {
    "label": "8 GPUs, 4 hours a day",
    "gpu_hours": 960,
    "usd_cost": "2,400"
  },
  {
    "label": "8 GPUs, always on",
    "gpu_hours": 5760,
    "usd_cost": "14,400"
  },
  {
    "label": "32 GPUs, always on",
    "gpu_hours": 23040,
    "usd_cost": "57,600"
  }
]

Het tarief is een aanname, geen offerte. De on-demand catalogusprijzen voor datacenter-accelerators lagen in 2026 ruwweg tussen de 2 en 5 USD per GPU-uur, en gereserveerde capaciteit is goedkoper. Gebruik het werkelijke tarief van uw provider en voer de vermenigvuldiging opnieuw uit: GPU's maal uren maal tarief. Het doel van de tabel is de verhouding. Het opschalen van een node met 8 GPU's voor vier uur per dag kost 2,400 USD per maand, terwijl het continu laten draaien van de SGLang-configuratie met 32 GPU's 57,600 USD kost.

Beide mainstream-servers publiceren een opstartcommando op de modelkaart.

pip install vllm
vllm serve "moonshotai/Kimi-K3"

pip install sglang
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K3" --host 0.0.0.0 --port 30000

Geen van beide kale commando's is wat u op een echt cluster uitvoert. Voeg de parallellisatie-vlaggen toe die overeenkomen met uw hardware: SGLang gebruikt --tp-size voor tensor-parallelisme en --ep-size voor expert-parallelisme, en het product daarvan moet gelijk zijn aan het aantal GPU's waarover u daadwerkelijk beschikt.

Controleer of de server is opgestart voordat u daadwerkelijk verkeer verstuurt:

curl http://127.0.0.1:30000/v1/models

Een gezonde server antwoordt met een JSON-object waarin de model-id wordt vermeld. Connection refused betekent dat het proces nog bezig is met het laden van gewichten of al is afgesloten; lees dus het serverlogboek voordat u het opnieuw probeert.

De meest voorkomende fout op de eerste dag is een runtime die ouder is dan het model. K3 werd uitgebracht met KDA en een nieuwe MoE-laag die de stabiele vLLM- en SGLang-releases bij de lancering nog niet bevatten. Het symptoom hiervan is dat de server tijdens het opstarten afsluit met een regel in de vorm van Model architectures [...] are not supported for now. Geen enkele configuratiewijziging lost dit op, omdat de code om die lagen uit te voeren niet in uw build aanwezig is. Installeer de nightly-versie die op de modelkaart wordt genoemd, of wacht op de release die deze ondersteunt.

Eén kostenpost waar mensen vaak tegenaan lopen: de meter begint te lopen zodra de instantie start, niet wanneer het model gereed is. Een download van 1,5 TB met 1 GB/s duurt ongeveer 25 minuten aan clustertijd voordat het eerste token wordt gegenereerd. Sla de gewichten op een volume op dat langer meegaat dan de instantie, zodat de tweede run binnen enkele minuten start.

Niveau 2: een kleiner model draaien op één accelerator

U draait in dit niveau geen K3. Zeg dit hardop voordat u begint, aangezien de meeste discussies over "K3 lokaal draaien" hier eindigen zonder dat toe te geven.

De pasvormregel is dezelfde formule in het klein: parameters vermenigvuldigd met bytes per gewicht, plus KV-cache, plus ongeveer 2 GB aan runtime-overhead, moet onder uw VRAM blijven. Bij 4-bit is dat ongeveer een halve byte per parameter, wat comfortabele combinaties oplevert:

• 16 GB kaart: een 7B-model op 4-bit met ruimte voor een lange context
• 24 GB kaart: een 14B-model op 4-bit
• 48 GB kaart: een 32B-model op 4-bit
• 80 GB kaart: een 70B-model op 4-bit, of een 30B-klasse MoE op 8-bit

Elke bovenstaande combinatie gaat uit van één verzoek tegelijk. Zodra een tweede persoon een prompt verstuurt, vereist elke gelijktijdige slot een eigen KV-cache. Dit is de afweging die Ollama's NUM_PARALLEL en MAX_QUEUE instellingen voor u maakt tussen parallelle slots, wachtrijen voor verzoeken en het resterende VRAM.

Ollama is de kortste weg naar een werkende server op een VPS met een gekoppelde GPU:

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14b

ollama run downloadt het model bij het eerste gebruik en opent vervolgens een prompt. Een tag die niet bestaat resulteert in Error: model "..." not found, dus kopieer tags van de bibliotheekpagina in plaats van ze uit het hoofd te typen. De volledige handleiding, inclusief de systemd-unit en externe toegang, vindt u in Ollama draaien op een VPS.

llama.cpp biedt u meer controle over kwantisatie en offloading:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

./build/bin/llama-server -m model.gguf -c 8192 -ngl 99 --host 0.0.0.0 --port 8080

-ngl 99 vraagt om elke laag op de GPU te plaatsen. Lees het laadlogboek: dit toont hoeveel lagen er zijn ge-offload. Lagen die uitlopen naar het systeem-RAM draaien op RAM-bandbreedte in plaats van HBM-bandbreedte, waardoor de generatiesnelheid met een factor tien afneemt zodra het model niet meer volledig in het geheugen past. De afwegingen tussen beide tools worden besproken in Ollama en llama.cpp vergeleken.

Tier 3: gehoste API, zelfgehoste orkestratie

[
  {
    "label": "Input, cache hit",
    "usd_per_million_tokens": "0.30"
  },
  {
    "label": "Input, cache miss",
    "usd_per_million_tokens": "3.00"
  },
  {
    "label": "Output",
    "usd_per_million_tokens": "15.00"
  }
]

Het eindpunt is compatibel met OpenAI, waardoor een bestaande client werkt nadat u de base URL heeft aangepast.

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "Say hello."}]}'

Een werkende sleutel retourneert een JSON-object met een choices-array. Een 401 betekent dat de sleutel onjuist is of dat het Bearer-voorvoegsel ontbreekt. Een model-not-found-fout betekent meestal dat de id is gewijzigd, omdat aanbieders id's tussen checkpoints door buiten gebruik stellen.

Kijk nu naar het omslagpunt, uitgaande van het bovenstaande huurtarief. Een node met 8 GPU's die altijd aan staat, kost 14,400 USD per maand. Bij 15.00 USD per miljoen output-tokens koopt u voor hetzelfde bedrag ongeveer 960 miljoen output-tokens via de API. Om kosten te besparen moet u bijna een miljard output-tokens per maand genereren, oftewel ongeveer 30 miljoen per dag, en het cluster constant bezet houden, aangezien inactieve GPU's hetzelfde tarief factureren als actieve GPU's. Agent-workloads met veel prompts verschuiven deze grens nog verder: herhaalde context wordt gefactureerd tegen het cache-hit-tarief van 0.30 USD per miljoen in plaats van het cache-miss-tarief van 3.00 USD.

Wat u in deze tier zelf host, is alles rondom het model: een gateway die de API-sleutel vasthoudt zodat deze nooit een client bereikt, logs van verzoeken en antwoorden, retries, rate limits en budgetten per gebruiker. Dit draait op een kleine VPS zonder GPU. Dezelfde verdeling is van toepassing op closed weights, waarbij het zelf hosten van Claude niet mogelijk is op modelniveau en orkestratie het enige onderdeel is dat u in eigen beheer heeft.

Welke serving stack hoort bij welke tier

vLLM- en SGLang-klasse servers behoren tot tier 1. Deze zijn ontworpen om veel verzoeken tegelijkertijd te verwerken, met behulp van continuous batching en een paged KV cache, aangevuld met tensor- en expert-parallelisme over meerdere nodes. Ze gaan uit van datacenter-accelerators en een snelle interconnect tussen deze nodes. Op een enkele consumentenkaart zijn ze zwaarder om te installeren en bieden ze nauwelijks merkbare voordelen.

llama.cpp en Ollama behoren tot tier 2. Deze zijn gericht op één machine, GGUF-kwantisatie, CPU-offloading wanneer het model niet in het geheugen past, en lage gelijktijdigheid. llama.cpp kan technisch gezien een enorm MoE-model laden door de meeste lagen in het systeem-RAM te houden; voor een 2.8T-model resulteert dit in een snelheid van seconden per token. Dit bewijst dat het bestand correct wordt geparseerd. Het is echter geen service die u aan gebruikers kunt aanbieden. De volledige vergelijking staat in Ollama versus vLLM, en dit verandert niet per model: de vraag is altijd of u veel gebruikers bedient op gedeelde hardware of één gebruiker op uw eigen systeem.

De vier getallen die dit checkpoint overleven

1. Het totaal aantal parameters vermenigvuldigd met het aantal bytes per gewicht bepaalt het minimale geheugengebruik. Niets draait onder deze grens, en geen enkele kwantisatietruc verandert dit significant zodra de release al 4-bit is.
2. Het aantal actieve parameters bepaalt de doorvoerklasse. Een 2.8T MoE met 104B actieve parameters rekent als een 104B model.
3. De KV cache per token, vermenigvuldigd met de contextlengte en de gelijktijdigheid, is de kostenpost die blijft groeien nadat u voor de gewichten heeft betaald.
4. Tokens per seconde per dollar is het enige getal dat een categorie bepaalt. Alles hierboven is input voor deze berekening.

Pas deze vier punten toe op elke release en u heeft het juiste antwoord voordat u een handleiding van de leverancier opent. Voorzie elk getal dat u noteert van een datum. Prijzen en lijsten met ondersteunde architecturen veranderden beide in de twee weken na de lancering van K3, en elk getal op deze pagina is gepubliceerd in juli 2026.

FAQ

Kan ik Kimi K3 op één GPU draaien?

Nee. De gewichten zijn ongeveer 1.4 TB bij de MXFP4-precisie die Moonshot levert, en de grootste losse accelerator die te koop is, heeft 288 GB. Een MoE-model kan zijn inactieve experts niet met bruikbare snelheid vanaf de schijf streamen, omdat de router bij elke token een willekeurige expert kan kiezen en een PCIe-fetch veel langer duurt dan het tokenbudget toelaat. De kleinst zinvolle K3-implementatie is een multi-GPU-node, en gepubliceerde recepten gebruiken 32 accelerators of meer.

Hoeveel VRAM heeft Kimi K3 nodig?

Begin bij 1.4 TB alleen al voor de gewichten, wat neerkomt op 18 H100 80GB-kaarten of 5 GB300-klasse kaarten. Voeg daar vervolgens KV-cache en activatiegeheugen aan toe. Sinds augustus 2026 adviseert Moonshot 64 of meer accelerators, en het SGLang-kookboek publiceert een 32 GPU H100-configuratie met 2.560 GB totaal, dus beschouw het gewichtencijfer als een ondergrens in plaats van als een vereiste.

Zorgt kwantisatie ervoor dat Kimi K3 op één node past?

Niet op een bruikbare manier. Het uitgebrachte checkpoint is al 4-bit met kwantisatie-bewuste training, dus de makkelijke besparing is al behaald. Nogmaals halveren naar 2-bit brengt de gewichten op 0.7 TB, wat nog steeds meer dan het dubbele is van de grootste kaart, en de nauwkeurigheidskosten van 2-bit zijn bij dit model niet gemeten.

Is het huren van GPU's goedkoper dan de Kimi K3 API?

Alleen bij een hoog en constant volume. Bij een aangenomen 2,50 USD per GPU-uur kost een altijd actieve 8 GPU-node 14,400 USD per maand, en voor hetzelfde geld koopt u ongeveer 960 miljoen output-tokens tegen het gepubliceerde tarief van 15.00 USD per miljoen. U betaalt ook voor inactieve uren, het downloaden van gewichten en de persoon die het cluster draaiende houdt. Huur per uur voor pieken en vergelijk dit met uw eigen gemeten tokenvolume in plaats van met een schatting.

Wat betekent 104B actieve parameters voor de snelheid?

Het betekent dat het rekenwerk per token dat van een 104B-model is, waardoor de doorvoer in die klasse valt in plaats van in de 2.8T-klasse. Het zegt niets over het geheugen: alle 2.8T parameters blijven resident, omdat de router bij elke token elke expert kan aanroepen. Gebruik het actieve aantal om tokens per seconde te voorspellen en het totaal aantal om de VRAM-grootte te bepalen.