Kimi-K3.1-Pro op 6 MI355X-GPU's met elk een limiet van 800 W

Kimi-K3.1-Pro heeft 2,8 biljoen parameters. Met Paiton, ons framework voor AI-optimalisatie, draait het op zes AMD Instinct MI355X GPUs met elk een vermogenslimiet van 800 W. Twee GPUs in de node met acht GPUs blijven buiten gebruik door het model.

Bij verzoeken met 8K invoer- en 1K uitvoertokens, samplingtemperatuur 0 en 800 W per GPU maten we in totaal 5.661 tokens/s, of 944 per GPU. AMD publiceert 936 per GPU voor ATOM op acht MI355X GPUs. De zes GPUs van Paiton verbruikten tijdens deze workload gemiddeld 4,18 kW. In een afzonderlijke test paste ook een prompt van een miljoen tokens op dezelfde zes GPUs bij dezelfde vermogenslimiet.

De vergelijking kent beperkingen. AMD vermeldt geen vermogenslimieten of samplingtemperaturen bij zijn doorvoertabellen. De nodes met acht GPUs halen een hogere totale doorvoer, en vLLM blijft per GPU sneller bij de workload met 128K invoertokens. In dit artikel betekent totale tokens steeds invoer plus uitvoer, niet alleen gegenereerde tokens.

Update, 12 november 2026: We hebben een fout hersteld in hoe Paiton één attention-parameter las. Daardoor vond het model na ongeveer 100K tokens minder informatie terug en konden lange agentsessies in herhaling vallen. Na de fix vond het model 72 van 72 geplaatste codes terug in tests bij 31K, 120K en 228K tokens; daarvoor waren dat 31 van 48 bij de tests op 120K en 228K. De snelheid bij 800 W is onveranderd. Onze exacte referentie en de gratis communityversie hadden dezelfde fout. De nauwkeurigheidssectie gebruikt nu de gecorrigeerde referentie. De communityfix staat in de pluginrepo; het containerimage wordt opnieuw gebouwd.

De header is een illustratie. De terminalbeelden en benchmarkopnamen hieronder komen uit de aangeleverde runs.

In dit artikel

• De opstelling en de opgenomen run
• Doorvoer en wachttijd
• GPU-vermogen en kostenscenario's
• Waarom zes GPUs en 800 W
• Sampling en nauwkeurigheid
• Draaien op vier GPUs
• Probeer de communityversie
• Meetdetails en een tweede benchmark

De opstelling en de opgenomen run

De oorspronkelijke Paiton-metingen van snelheid en vermogen hieronder zijn gemaakt op 10 en 11 november 2026. Het AMD-artikel van 4 november rapporteert resultaten voor ATOM en vLLM; het artikel van vLLM zelf bevat de vLLM-cijfers. Dit zijn afzonderlijke runs op verschillende nodes, geen gecontroleerde softwarevergelijking op één machine.

Originele opname tijdens de run, temperatuur 0. De momentopname rond 800 W verschilt van het gemiddelde over de run: circa 696 W per actieve GPU.

Benchmarkopname op 4× snelheid, niet in realtime. Zes MI355X GPUs, een limiet van 800 W per GPU, samplingtemperatuur 0.

Open de opname met zes GPUs of bekijk het originele resultaatscherm.

Doorvoer en wachttijd

We gebruikten de standaardclient vllm bench serve met willekeurige prompts, 64 verzoeken en maximaal 16 gelijktijdige verzoeken, volgens de workloadopzet die AMD publiceert. Prefixcaching stond uit en EOS werd genegeerd. De doorvoertests gebruikten een maximale sequentielengte van 140.000 tokens; de miljoen-tokentest gebruikte een aparte configuratie.

8K invoer en 1K uitvoer

TTFT: tijd tot het eerste token. TPOT: tijd per uitvoertoken na het eerste. Paiton T=0 bij 800 W per GPU is het gemiddelde van twee runs, 5.673 en 5.648 totale tok/s; T=1,0 is één run. Cijfers per GPU zijn afgerond. AMD gebruikt TP8/DCP8, 16 gelijktijdige verzoeken en 64 prompts.

Bij T=0 ligt Paitons doorvoer per GPU dicht bij het gepubliceerde ATOM-resultaat. Bij T=1,0 ligt die dicht bij vLLM. Deze koppelingen zijn indicatief: door de ontbrekende samplingtemperaturen van AMD is dit geen vergelijking bij gelijke temperatuur. Bij die koppelingen is Paitons wachttijd per uitvoertoken hoger en de wachttijd tot het eerste token korter.

128K invoer en 100 uitvoer

Paiton: zes MI355X GPUs bij elk 800 W. Gepubliceerde AMD-resultaten: acht MI355X GPUs, vermogenslimieten en samplingtemperaturen niet vermeld. De tabellen hierboven bevatten de grafiekwaarden. Download de SVG.

Paiton bij T=0 en 800 W per GPU ligt op 128K/100 per GPU circa 22% boven ATOM en circa 4% onder vLLM. ATOM heeft een veel kortere wachttijd tot het eerste token. In de Paiton-run komen 16 lange verzoeken tegelijk binnen en worden hun prompts na elkaar verwerkt. Verzoeken wachten dus op eerdere prefills. Een hoog cijfer voor tokens per GPU neemt die wachttijd niet weg.

Eén verzoek en een prompt van een miljoen tokens

Acht verzoeken met willekeurige prompts per configuratie. De uitvoersnelheid is de omgekeerde waarde van de mediane TPOT.

Willekeurige prompts zijn gunstig voor speculative decoding bij T=0, omdat hun greedy vervolg vaak herhalend wordt. Op echte tekst bij 800 W per GPU haalde hetzelfde pad circa 100 uitvoertokens/s voor één verzoek. AMDs cijfers voor één verzoek gebruiken synthetische draftacceptatie; daarom staan ze niet in deze tabel.

In de aparte lange-contexttest op zes GPUs bij elk 800 W duurde één verzoek met 1.040.000 invoertokens en 64 uitvoertokens 90 seconden tot het eerste token, daarna 19,9 ms per uitvoertoken. De maximale sequentielengte en de KV-pool waren beide 1.052.672 tokens. Het GPU-geheugengebruik bereikte ongeveer 98%. Dat laat zien dat deze context op zes GPUs bij elk 800 W past; dit is niet de configuratie uit de doorvoertabellen.

GPU-vermogen en kostenscenario's

Onze zes GPUs verbruikten gemiddeld 4,18 kW op 8K/1K en 4,58 kW op 128K/100 bij T=0, onder hun gezamenlijke limiet van 4,8 kW. Deze metingen omvatten alleen de GPUs, niet de host of koeling.

AMD publiceert geen gemeten verbruik of ingestelde limieten voor zijn runs. Voor de berekeningen hieronder nemen we 1.400 W per GPU aan, of 11,2 kW voor acht GPUs, op basis van het opgegeven typische kaartvermogen van de MI355X. Die specificatie bewijst niet dat AMD bij deze limiet draaide of dat vermogen verbruikte.

Invoer- plus uitvoertokens. Paiton T=0, zes GPUs × 800 W; AMDs samplingtemperaturen en werkelijke limieten zijn onbekend. Delen door aangenomen limieten meet geen relatieve energie-efficiëntie. Download de SVG.

Elektriciteit voor de GPUs

Bij een aangenomen $0,10/kWh zijn dit de GPU-kosten per miljoen totale tokens. CPUs, netwerk en koeling zijn niet inbegrepen.

De berekening is kW × prijs per kWh × 1.000.000 ÷ (tokens/s × 3.600). Bij continu GPU-verbruik van 4,8 of 11,2 kW zouden de jaarlijkse elektriciteitskosten $4.205 of $9.811 zijn. Deze scenario's tonen geen gemeten elektriciteitsbesparing tegenover AMD aan.

GPU-huur

Voor een indicatieve toerekening van GPU-kosten gebruiken we gepubliceerde tarieven, gecontroleerd op 11 november 2026: TensorWave begint bij $2,95/GPU-uur, Daytona vermeldt $5,99/GPU-uur met CPU, RAM en opslag apart geprijsd, en Oracle vermeldt $8,60/GPU-uur voor bare-metal. Deze verschillende aanbiedingen zijn geen onderling uitwisselbare offertes voor een volledige node. Alle rijen gebruiken totale tokens, inclusief prompttokens.

Huurkosten zijn aantal GPUs × uurtarief × 1.000.000 ÷ (tokens/s × 3.600). Huurt u een ondeelbare node met acht GPUs, dan verlaagt het ongebruikt laten van twee GPUs de factuur niet. Die capaciteit kan naar een andere workload, afhankelijk van de resterende hostcapaciteit. Test gecombineerde workloads voordat u die capaciteit als omzet meetelt.

Waarom zes GPUs en 800 W

De circa 1,56 TB aan modelgewichten en een KV-pool voor een miljoen tokens passen op zes MI355X GPUs. Paitons eigen sharding ondersteunt dat aantal, ook al zijn de hoofddimensies van het model niet deelbaar door zes. Het framework draait eigen HIP-kernels op de GPUs.

Twee GPUs met samen 576 GB opgegeven HBM-capaciteit blijven buiten het Kimi-proces. Embeddings, reranking of een tweede model zouden die kunnen gebruiken, maar zulke combinaties zijn hier niet getest. Zes GPUs hebben ook minder rekenkracht en geheugenbandbreedte dan acht. De gepubliceerde resultaten op acht GPUs halen een hogere totale nodedoorvoer.

De limiet van 800 W kwam door onze eenfasige PDU. Tests bij 1.000 W per GPU brachten de voeding dicht bij haar grens; langdurig gebruik van acht GPUs bij 1.400 W lag buiten die capaciteit. Alle end-to-end Paiton-benchmarkresultaten in dit artikel gebruiken 800 W per GPU.

Wat 1.400 W mogelijk verandert

We konden het volledige model niet bij 1.400 W draaien. De bereiken hieronder zijn schattingen uit beperkte tests van onderdelen, met de aanname van snellere prefill en maximaal 10% snellere decode. Ze zijn niet gevalideerd bij die vermogenslimiet.

De waarden bij 1.400 W zijn extrapolaties uit een onderdelentest en aangenomen decodeschaling. Het zijn geen gemeten resultaten voor het volledige model en geen prestatiebelofte. Download de SVG.

Sampling en nauwkeurigheid

Paiton gebruikt de openbare Inferact DSpark-drafter. De samplingtemperatuur verandert hoeveel voorgestelde tokens het doelmodel accepteert. Bij T=0 zijn herhalende vervolgen op willekeurige prompts makkelijker te voorspellen; bij T=1,0 worden meer voorstellen afgewezen. Daarom rapporteren we beide temperaturen zonder er een toe te schrijven aan AMDs onbekende instellingen.

De volgende resultaten komen van de herstelde versie op zes GPUs bij 800 W per GPU, met een context van 1M tokens, greedy decoding en thinking uit. We gebruikten dezelfde testopzet en opgavensets als voorheen; MMLU-Pro is nieuw in dit artikel.

HumanEval is onveranderd binnen de meetruis. Deze controles tonen niet de nauwkeurigheid op elke taak aan.

Onze eerdere KL-cijfers gebruikten een foutieve referentie en zijn niet meer geldig. Tegenover het gecorrigeerde exacte model hebben de gebruikte instellingen op het prefill-pad een KL-divergentie van 0,0078 over 47 apart gehouden rijen en 85.152 posities, met 96,4% top-1-overeenkomst. Tegenover diezelfde gecorrigeerde referentie scoort de oude versie 0,109 en standaard-vLLM 0,0030. Een lagere KL betekent een verdeling die dichter bij de referentie ligt, niet automatisch betere antwoorden op elke taak.

We hebben de KL-divergentie op het decode-pad niet opnieuw gemeten.

Draaien op vier GPUs

De tijden in deze sectie zijn vóór de fix gemeten. De gecorrigeerde nauwkeurigheidsresultaten op zes GPUs hierboven valideren deze configuratie met vier GPUs niet.

Paiton draait Kimi-K3.1-Pro ook op vier MI355X GPUs bij elk 800 W. De gewichten passen niet volledig in hun HBM, dus de twee AMD EPYC 9575F CPUs van de node berekenen een deel van de expertworkload.

Dezelfde workload met 64 verzoeken en maximaal 16 tegelijk; T=0 is het gemiddelde van twee runs. De tijd bij één verzoek komt uit een aparte test. GPUs 2-5 zijn actief.

Versnelde benchmarkopname, niet in realtime. Vier MI355X GPUs met elk een limiet van 800 W, met CPU-experts, samplingtemperatuur 0.

Open de opname met vier GPUs of bekijk het originele resultaatscherm.

Dit gebruikt minder GPUs, maar verliest veel doorvoer door het wachten op CPU-werk. De vier ongebruikte GPUs delen die drukbezette host. Twee gelijktijdige Kimi-instances zijn niet gevalideerd.

Probeer de communityversie

De gratis communityversie met launcher draait het model op vier ondersteunde AMD Instinct CDNA4 GPUs. Het is gewone Python/PyTorch, zonder Paiton-kernels, batching of speculative decoding. U kunt er het model mee bekijken en eigen prompts proberen; het reproduceert Paitons prestaties niet.

Historische metingen vóór de fix, bij 800 W per GPU. Communityprefill: 1.175 tokens in 239 seconden; Paiton-prefill: circa 8K tokens in 2,6 seconden. De duur van het 8K/1K-communityverzoek is geschat uit gemeten fasesnelheden, niet uit een voltooide benchmark van twee uur. Deze fasetests gebruiken verschillende promptlengtes.

Op 12 november 2026 staat de communityfix in de pluginrepo en wordt het containerimage opnieuw gebouwd. De tag hieronder verwijst naar de oorspronkelijke release; dit bevestigt niet dat een pull de fix bevat.

ghcr.io/eliovp/paiton-vllm-plugin:kimi31pro-rocm10.1.0-pytorch2.13.0-cdna4-v1

Lees de handleiding voordat u downloadt. Nodig zijn ondersteunde gfx950 GPUs, minstens 768 GB host-RAM en opslag voor circa 1,6 TB gewichten plus het image van ongeveer 37 GB. Er wordt één verzoek tegelijk verwerkt, standaard met maximaal 32.768 tokens; dit is geen gevalideerde communityopstelling voor een miljoen tokens. De Apache-2.0-licentie van de code staat los van Kimi's modelvoorwaarden. Controleer de commerciële modelvoorwaarden voor uw toepassing.

Meetdetails en een tweede benchmark

Onze node heeft acht MI355X GPUs, twee EPYC 9575F CPUs met elk 64 cores en 2,2 TB RAM. Tests met zes GPUs gebruikten GPUs 2-7; tests met vier GPUs gebruikten GPUs 2-5. Het GPU-vermogen werd elke twee tot drie seconden gemeten met amd-smi metric -p; de ingestelde limieten zijn bij de resultaten opgeslagen.

De servingclient kwam uit vllm/vllm-openai-rocm:kimi-k31. Voor 8K/1K gebruikte die --dataset-name random --random-input-len 8192 --random-output-len 1024 --num-prompts 64 --max-concurrency 16 --ignore-eos. T=0-verzoeken stelden expliciet --temperature 0 in; de andere run gebruikte Paitons serverstandaard van 1,0. Prefixcaching stond uit en prefillchunks waren 8.192 tokens.

We draaiden ook LocalMaxxings open CLI, lmx 0.1.60, tegen Paiton op zes MI355X GPUs met elk een limiet van 800 W en de miljoen-tokenconfiguratie. De prompts en tijdmeting verschillen van de benchmark met willekeurige tokens.

De totale uitvoer wordt geteld over elke decodecel van 30 seconden. De snelheid per verzoek is de mediaan van de omgekeerde inter-tokenwachttijd, niet de totale doorvoer gedeeld door het aantal gelijktijdige verzoeken.

Dit zijn onze lokale CLI-resultaten, geen gepubliceerde vermelding in het klassement. Indiening werd geweigerd omdat de lijst met toegelaten AMD Instinct GPUs stopte bij MI300X en MI325X en de MI355X niet bevatte. De opgeslagen resultatenpagina en originele screenshot staan hier.

Dank aan Moonshot AI voor de uitgebrachte gewichten, Inferact voor de drafter en de AMD ATOM- en vLLM-teams voor het publiceren van hun metingen. Onze eerdere MI350P-resultaten en ons R9700-werk behandelen andere modellen en hardwarebudgetten.

Bouwt u een tokenfabriek?

Of hebt u er plannen voor? Bespreek uw model, gewenste wachttijd en hardwarebudget met ons. Dan testen we samen welke afwegingen werken.