Een jaar geleden betekende het draaien van een taalmodel met een biljoen parameters een serverruimte. Racks, koeling, een energierekening die een eigen vergadering nodig had. Toen publiceerde AMD een ontwikkelaarsverslag waarin vier mini-pc's op een bureau stonden (van het soort dat je met twee tegelijk kon dragen) en hetzelfde werk deden. Vier identieke kleine kastjes, aan elkaar gekabeld, die een model draaien met meer parameters dan er sterren zichtbaar zijn vanaf een straat in de stad.
De kop schrijft zichzelf: "Geen cloud. Geen datacenter." En het klopt. AMD draaide echt een model met 1,04 biljoen parameters op vier Framework Desktop-systemen met consumentensilicium erin.
Maar er is een deel dat de kop oversloeg, en het is het deel dat bepaalt of dit een mijlpaal is of een goocheltruc. Er is een architectuurdetail dat "biljoen parameters" technisch eerlijk maakt, een addertje dat bepaalt of je dit ding daadwerkelijk zou kunnen gebruiken, en een reden waarom het meer toedoet dan zowel de hype als de tegenreactie het toedicht.
De korte versie
- Het model is Kimi K2.5, en het is een Mixture-of-Experts-ontwerp: 1,04 biljoen totale parameters, maar slechts ongeveer 32 miljard daarvan vuren bij een gegeven token. "Model met een biljoen parameters" is correct; de rekenlast per token ligt dichter bij een werklast van de 32B-klasse.
- Het cluster genereert ongeveer 8 tot 9,5 tokens per seconde, met een time-to-first-token van ergens tussen 39,7 en 239,1 seconden, afhankelijk van hoe lang je prompt is. Prima voor batchwerk. Bruut voor een interactieve codeerlus.
- Wat er veranderde is niet de snelheid. Het is dat unified memory inferentie op frontierschaal op hardware bracht die je kunt kopen en op een plank kunt zetten, een categorie die vroeger begon bij "bezit een datacenter".
Wat AMD Werkelijk Deed
De opstelling is bijna een anticlimax zodra je ze uitgestald ziet. Vier Framework Desktop-machines , elk met een Ryzen AI Max+ 395 en 128 GB LPDDR5X unified memory. In de BIOS kan elke node tot 96 GB blootstellen als dedicated VRAM, of 384 GB over de vier nodes; AMD's Linux-walkthrough gebruikt vervolgens TTM/kernel-instellingen om dat te verhogen tot 120 GB per node, of 480 GB totaal. Dat is belangrijk omdat de Kimi K2.5 UD_Q2_K_XL GGUF-build die AMD gebruikte vermeld staat op 375 GB, niet 240 GB.
De lijm is llama.cpp die draait in RPC-modus: één controllernode en drie RPC-servers, met het model verdeeld over alle vier de machines. AMD vermeldt de interconnect als 5 Gbps Ethernet, wat past bij de ingebouwde 5Gbit-Ethernetpoort van de Framework Desktop. Dat is de hele opstelling. Geen exotische interconnect, geen aangepaste boards, niets dat je vanmiddag niet zou kunnen bestellen.
Het interessante woord in dat alles is unified. Op een normale pc zijn het RAM van je CPU en het VRAM van je GPU gescheiden pools, en een model dat te groot is voor het VRAM loopt ofwel over naar traag systeemgeheugen ofwel draait niet. Unified memory laat die muur instorten: de GPU kan de hele bank adresseren, wat de hele reden is waarom een desktop van 4,5 liter überhaupt een stuk van een model van deze omvang kan bevatten.
AMD's eigen technische verslag behandelt de configuratie in detail. Wat het niet echt behandelt is waarom "biljoen parameters" meer retorisch werk verricht dan het lijkt.
De Truc: Waarom "Biljoen Parameters" Waar Is maar Niet de Hele Waarheid
Hier is het ding waar het specblad op leunt zonder het uit te leggen: Kimi K2.5 is een Mixture-of-Experts-model, en dat verandert wat "biljoen parameters" in de praktijk betekent.
Een dicht model, het soort dat de meeste mensen voor zich zien, draait elke parameter voor elk token. Een dicht model met 70 miljard parameters doet 70 miljard parameters aan rekenwerk op elk woord dat het produceert. Een Mixture-of-Experts-model is anders opgebouwd. Kimi K2.5 heeft 384 afzonderlijke "experts", waarvan er 8 per token activeren plus één gedeelde expert, over 61 lagen. Dus terwijl het model in totaal 1,04 biljoen parameters draagt, lichten er slechts ongeveer 32 miljard op bij een enkele forward pass. Een router kiest welke experts gewekt worden; de rest zit daar niets te doen voor dat token.
Dus is "een model met een biljoen parameters draaien op vier mini-pc's" eerlijk? Ja, je hebt het geheugen echt nodig om alle 1,04 biljoen parameters vast te houden, en dat geheugen is het moeilijke deel. Maar het rekenwerk dat je hardware per token moet doen is een klus van de 32B-klasse, niet een van de 1T-klasse.
Wat beide kanten op snijdt, en hier wordt het interessant. Het maakt de demo meer indrukwekkend dan het klinkt, omdat het vasthouden van een volledig model met een biljoen parameters in het geheugen op consumentenkastjes het werkelijk moeilijke is dat ze voor elkaar kregen. En het maakt het minder indrukwekkend dan de kop suggereert, omdat de werkelijke werklast per token iets is dat losse kastjes al sneller doorkauwen op kleinere MoE-modellen. Een MoE-model van 120B draait met 50-plus tokens per seconde op een van deze nodes. Het getal van een biljoen parameters is echt, maar het is een geheugenflex, geen rekenflex.
De conclusie: wanneer je hardware dimensioneert voor een model, is het aantal actieve parameters wat je machine per token moet voeden, niet het totaal op het kastje.
Het Addertje: Wat 8 Tokens per Seconde en een Wachttijd van 40 Seconden tot 4 Minuten Werkelijk Betekenen
Acht tokens per seconde is het getal dat alles bepaalt, dus blijf er even bij stilstaan. AMD's artikel rapporteert dat het cluster ongeveer 8,30 t/s genereert bij een context van 8.192 tokens en ruwweg 9,45 t/s in steady state, met promptverwerking rond 100,77 t/s. Dat zijn prima, eerlijke getallen voor wat ze zijn.
Degene die pijn doet is de time-to-first-token. Voordat het model een enkel woord produceert, moet het je prompt lezen, en AMD's eigen benchmarktabel stelt die wachttijd op 39,7 seconden voor een prompt van 4.096 tokens, 90,5 seconden voor een prompt van 8.192 tokens, en 239,1 seconden voor een prompt van 16.384 tokens met Flash Attention ingeschakeld. Dus je typt een vraag, en dan wacht je. Mogelijk bijna vier minuten, voordat er iets terugkomt.
Voor een interactieve codeerlus is dat zwaar, en ontwikkelaars in de Hacker News-discussie zeiden dat onomwonden: meer dan een minuut dode lucht vóór het eerste token past niet bij de manier waarop iemand code schrijft met een assistent. Maar draai de werklast om. Als je 's nachts batchtaken draait, documenten async verwerkt, dingen genereert die je later leest, of privé-inferentie doet waarbij het hele punt is dat er niets het gebouw verlaat, is 8 tokens per seconde volledig leefbaar. Je keek toch al niet naar het scherm.
Het sterretje: Verwacht niet dat deze getallen zich kant-en-klaar reproduceren. De ROCm-softwarestack op deze hardware is versiegevoelig op manieren die bijten: een GitHub-issue documenteerde een Strix Halo-systeem dat vastzat op idle GPU-kloksnelheden en kroop met 0,5 t/s onder LLM-inferentie op ROCm 7.1.1 en Linux-kernel 6.14. Dat is geen "AMD is kapot", maar het betekent wel dat de gepubliceerde prestaties afhangen van een zeer specifieke softwarestack, en je kunt uiteindelijk ROCm-, kernel- en firmwarecombinaties najagen voordat je opstelling overeenkomt met de getallen in het verslag.
Nog iets dat de tegenreactie verkeerd heeft, namelijk de kosten. Mensen blijven het een "cluster van $10.000" noemen, maar niemand publiceert dat als een vaste materiaallijst. Doe het rekenwerk zelf: vier Framework Desktops van 128 GB tegen de lanceringsprijs van $1.999 zouden de machines alleen al op ongeveer $8.000 brengen, terwijl een Liliputing-momentopname van maart 2026 een 128GB/1TB Framework Desktop-configuratie vermeldde op $2.851, oftewel ongeveer $11.400 voor vier vóór netwerken. Voeg een paar honderd dollar toe voor switch en bekabeling, en het praktische bereik ligt dichter bij ruwweg $8,2K tot $11,7K, afhankelijk van configuratie, aankoopdatum en wat je al hebt. Niet niets. Ook geen serverruimte.
Hier kom ik op uit over het geheel: het cluster werkt. Of acht tokens per seconde en meer dan een minuut wachten een triomf of speelgoed is, hangt volledig af van wat je probeert te bouwen. Het is geen interactief codeerwerkstation. Het is ook geen speelgoed. Het is een echte machine voor een specifiek soort geduldig werk, en doen alsof het meer of minder is dan dat, is hoe iedereen in dit argument langs elkaar heen praat.
Waar Dit Werkelijk Op Uitkomt
De eerlijke framing is niet "AMD versloeg Nvidia". Het is dat dit een ander product is voor een ander persoon. De lezer die dit wil is degene die privacy nodig heeft, offline wil, of niet voor altijd per token wil betalen, niet degene die de snelst mogelijke reactie najaagt.
En het sterkste argument tegen de hele exercitie verdient een rechtstreeks antwoord: je kunt gewoon Kimi's API aanspreken. Artificial Analysis vermeldt momenteel Kimi's eigen K2.5-endpoint rond 56 tot 60 tokens per seconde met een gemengde prijs rond $0,49 per miljoen tokens, terwijl Kimi's officiële API-platform K2.5-prijzen vermeldt op $0,10/M cache-hit input-tokens, $0,60/M input-tokens, en $3,00/M output-tokens. Externe K2.5-aanbieders kunnen sneller of goedkoper zijn afhankelijk van routering, maar het basispunt is hetzelfde: de API is sneller dan het cluster, vermijdt hardware-babysitten, en zal voor de meeste mensen op de meeste dagen de juiste keuze zijn.
Dus het lokale verhaal is alleen zinvol wanneer een van drie dingen waar is: de data mag niet weg (privacy), de verbinding mag niet worden verondersteld (offline), of het tokenvolume is hoog genoeg en aanhoudend genoeg dat het bezitten van het metaal beter is dan het voor altijd huren (kosten op schaal). Buiten die drie wint de API. Erbinnen is het cluster het enige dat de klus überhaupt klaart.
| Dimensie | AMD 4-node-cluster | Kimi API / cloudroute |
|---|---|---|
| Generatiesnelheid | ~8 tot 9,5 t/s | ~56 tot 60 t/s op Kimi's eigen K2.5-endpoint |
| Time-to-first-token | 39,7 tot 239,1 s | afhankelijk van aanbieder, veel lager |
| Kostenmodel | ~$8,2K tot $11,7K hardware | API-prijzen per token |
| Privacy / offline | volledig lokaal | gehost door aanbieder |
| Best passende use case | privé, offline, batchwerk | interactief/API-gebruik |
Voor de duidelijkheid, Nvidia's DGX Spark is hier de voor de hand liggende "maar wat dan met", en het wint op sommige assen die het AMD-cluster niet wint. Dat is een heel apart gevecht, en een dat ik elders zal aangaan. Als je de huurkant van de hardware-versus-cloud-beslissing wilt, is Cloudzy's GPU VPS -pagina het praktischere vergelijkingspunt.
Het Deel Dat Werkelijk Toedoet
Strip het tokentempo en de prijsargumenten weg, en één feit blijft overeind staan: de hardware die een model met een biljoen parameters draait is nu een plank, geen gebouw.
Dat is de verschuiving, en het is makkelijk te missen onder het snelheidsgekibbel. Een jaar geleden was de categorie mensen die een model met 1,04 biljoen parameters konden draaien "datacenteroperators". Punt uit. Nu omvat het iedereen met ongeveer tienduizend dollar en wat geduld. De lijn bewoog niet een beetje: een hele nieuwe groep mensen liep zojuist door een deur die op slot zat.
Wat dat opent is het interessante deel. Privé-agents die volledig draaien op hardware die je bezit. Inferentie die werkt in een vliegtuig of achter een air gap. Modellen die fysiek niet naar huis kunnen bellen omdat er nergens is waar het gesprek heen kan. Een economie van AI waar de marginale kosten van een token elektriciteit zijn in plaats van een gemeten API-lijn. Niets daarvan was bereikbaar op consumentenhardware een jaar geleden, en unified memory is het ding dat het bereikte.
Ik heb dit patroon vaak genoeg gezien om wantrouwig te zijn tegenover "dit verandert alles". Meestal doet het dat niet; meestal is het het ding van vorig jaar met een nieuw logo. Deze is anders, en niet omdat het snel is. Het is anders omdat de vloer verschoof. De langzame, dure, geduldige versie van lokale inferentie op frontierschaal bestaat nu, en de snelle versie is slechts een kwestie van de volgende paar hardwaregeneraties die het afslijpen. Het moeilijke deel zou nooit snelheid zijn. Het moeilijke deel was toegang, en toegang gebeurde zojuist.
De mijlpaal hier is niet snelheid. Het is wie er in de kamer mag. De machine die modellen op frontierschaal draait was vroeger een gebouw. Nu zijn het vier kastjes op een plank.
Veelgestelde vragen
Kun Je Echt een Model met een Biljoen Parameters Draaien op een Mini-pc-cluster?
Ja, met één belangrijke kanttekening. AMD draaide Kimi K2.5, een model met 1,04 biljoen parameters, over vier Ryzen AI Max+ 395 mini-pc's. In de BIOS kunnen de vier systemen samen ongeveer 384 GB dedicated VRAM blootstellen; AMD's Linux-walkthrough verhoogt de toewijzing vervolgens tot 480 GB totaal via TTM/kernel-instellingen. Maar Kimi K2.5 is een Mixture-of-Experts-model: van die 1,04 biljoen parameters activeren er slechts ongeveer 32 miljard bij een gegeven token. Je hebt het geheugen nodig om ze allemaal vast te houden, maar het rekenwerk per token ligt dichter bij een werklast met 32 miljard parameters.
Wat Is Kimi K2.5 en Waarom Doet de MoE-Architectuur Hier Toe?
Kimi K2.5 is een open-weight taalmodel van Moonshot AI met 1,04 biljoen totale parameters en 32 miljard actief per forward pass, gebouwd op een Mixture-of-Experts-ontwerp (384 experts, 8 geactiveerd per token plus één gedeelde). De architectuur doet toe omdat het aantal actieve parameters, niet het totaal, is wat je hardware voor elk token moet berekenen. Daarom kan een model met op papier een biljoen parameters überhaupt op consumentenkastjes draaien.
Is 8 Tokens per Seconde Snel Genoeg voor Lokale AI?
Het hangt volledig af van de werklast. Voor batchverwerking, async-taken, offline gebruik, of privé-inferentie waarbij niets je hardware mag verlaten, is 8 tokens per seconde prima, je staart niet naar het scherm. Voor interactief coderen is het zwaar, vooral omdat de time-to-first-token op dit cluster loopt van ongeveer 40 seconden tot bijna 4 minuten, afhankelijk van de promptlengte, en die dode lucht vóór het eerste woord nekt een iteratieve lus.
Waarom Niet Gewoon Kimi's API Gebruiken?
Voor de meeste mensen zou je dat moeten doen. Kimi's eigen K2.5-endpoint is veel sneller dan het lokale cluster in de huidige Artificial Analysis-data, en externe K2.5-aanbieders kunnen nog sneller of goedkoper zijn. De lokale hardware is alleen zinvol wanneer je privacy nodig hebt (de data mag niet weg), offline-mogelijkheden (geen verbinding om te veronderstellen), of kosten-op-schaal (aanhoudend hoog volume waarbij bezitten beter is dan huren). Buiten die gevallen is de API de betere keuze.
