Kimi K3 zelf hosten: hardwarevereisten en berekeningen

Wat er nodig is voor het zelf hosten van Kimi K3

Het zelf hosten van Kimi K3 betekent ruimte 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 op zichzelf opslaan. K3 is een multi-node model; voor één server is het antwoord nee.

Dat is het oordeel. Alles hieronder is de rekenkunde die erachter schuilt, omdat u deze berekeningen kunt hergebruiken bij de volgende release. Verschillende infrastructuurleveranciers publiceerden in de weken na de aankondiging op 17 juli 2026 handleidingen voor het implementeren van K3, en elk daarvan ging ervan uit dat u al over een cluster beschikte. Deze pagina begint aan 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 op 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 specifiek 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 is vergelijkbaar met 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 laden en de rest op aanvraag ophalen, omdat het ophalen binnen microseconden voltooid moet zijn en een PCIe-verbinding slechts tientallen gigabytes per seconde verplaatst. Mensen proberen dit 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, maar duur om op te slaan. Baseer de hardwarevereisten op 2.8T. Baseer uw verwachtingen voor de snelheid op 104B.

Bytes per gewicht, en waar de terabytes vandaan komen

Aantal parameters vermenigvuldigd met 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 ter vergelijking: bij bf16 zou hetzelfde model 5.6 TB vereisen. MXFP4 slaat daarnaast een gedeelde 8-bit schaalfactor op voor elk blok van 32 gewichten, wat ongeveer 6 procent toevoegt. De gepubliceerde repository zit daardoor 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 kaarten van de GB300-klasse, beschrijft een machine die de meeste providers niet als één enkele SKU verhuren.

De KV-cache is het onderdeel dat mensen verrast

Gewichten zijn een vaste kostenpost. De KV-cache (key value) is dat niet: deze groeit mee met de contextlengte en opnieuw 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 het aantal gelijktijdige gebruikers.

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, dus 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 low-rank latent vector, waardoor de werkelijke kosten per token aanzienlijk lager uitvallen dan in 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 vervolgens 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 uitvoert. U koopt de hardware niet. U huurt deze voor de uren dat u het 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 2 en 5 USD per GPU-uur, en gereserveerde capaciteit is goedkoper. Gebruik het werkelijke tarief van uw provider en voer de berekening 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 gedurende 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 gangbare servers vermelden 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 standaardcommando's is wat u op een echt cluster uitvoert. Voeg de parallelism-flags toe die overeenkomen met uw hardware: SGLang gebruikt --tp-size voor tensor parallel en --ep-size voor expert parallel, 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 het model-id wordt vermeld. Connection refused betekent dat het proces nog bezig is met het laden van gewichten of al is afgesloten; lees daarom 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 ondersteuning bevat.

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

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

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

De pasvormregel is dezelfde formule in het klein: parameters vermenigvuldigd met bytes per gewicht, plus de 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

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 geeft Error: model "..." not found terug, 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, staat in Ollama draaien op een VPS.

llama.cpp geeft 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: hierin staat 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 behandeld in Ollama en llama.cpp vergeleken.

Tier 3: gehoste API, zelfgehoste orchestratie

[
  {
    "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 endpoint 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 key retourneert een JSON-object met een choices array. Een 401 betekent dat de key onjuist is of dat het Bearer voorvoegsel ontbreekt. Een model-not-found fout betekent meestal dat de id is gewijzigd, omdat providers id's buiten gebruik stellen tussen checkpoints door.

Kijk nu naar het omslagpunt, uitgaande van het hierboven aangenomen huurtarief. Een node met 8 GPU's die altijd aan staat kost 14,400 USD per maand, en voor 15.00 USD per miljoen output-tokens koopt u voor hetzelfde geld ongeveer 960 miljoen output-tokens via de API. Om qua kosten voordeliger uit te zijn, moet u bijna een miljard output-tokens per maand genereren, grofweg 30 miljoen per dag, en het cluster continu bezet houden, omdat inactieve GPU's hetzelfde tarief factureren als actieve. Agent-workloads met veel prompts verschuiven de 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 key vasthoudt zodat deze nooit een client bereikt, logs voor verzoeken en antwoorden, retries, rate limits en budgetten per gebruiker. Dit draait op een kleine VPS zonder GPU. Dezelfde splitsing geldt voor closed weights, waarbij het zelf hosten van Claude op modelniveau niet mogelijk is en orchestratie 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 verspreid 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 richten zich op één machine, GGUF-kwantisatie, CPU-offload 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 geen service die u aan gebruikers kunt aanbieden. De volledige vergelijking staat in Ollama versus vLLM, en dit verandert niet met het model: de vraag is altijd of u veel gebruikers bedient op gedeelde hardware of één gebruiker op uw eigen machine.

De vier getallen die deze checkpoint overleven

1. Het totaal aantal parameters vermenigvuldigd met het aantal bytes per gewicht bepaalt de minimale geheugenbehoefte. 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 de gewichten al heeft betaald.
4. Tokens per seconde per dollar is het enige getal dat de klasse 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 enkele accelerator die te koop is, bevat 288 GB. Een MoE-model kan zijn inactieve experts niet met een 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 kleinste 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 configuratie met 32 H100 GPU's met een totaal van 2.560 GB, dus beschouw het cijfer voor de gewichten 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 quantisation-aware 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 prijs van 2.50 USD per GPU-uur kost een altijd actieve node met 8 GPU's 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 gelijk is aan dat van een 104B-model, waardoor de doorvoer in die klasse valt in plaats van in de 2.8T-klasse. Dit 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.