AMD byggede en AI-supercomputer med en billion parametre ud af mini-pc'er

For et år siden betød det at køre en sprogmodel med en billion parametre et serverrum. Racks, køling, en elregning der havde brug for sit eget møde. Så udgav AMD en udvikler-gennemgang, der viste fire mini-pc'er stående på et skrivebord (af den slags man kunne bære to ad gangen), som lavede det samme arbejde. Fire identiske små kasser, kablet sammen, der kørte en model med flere parametre, end der er stjerner, du kan se fra en bygade.

Overskriften skriver sig selv: "Ingen cloud. Intet datacenter." Og det passer. AMD kørte faktisk en model med 1,04 billioner parametre på fire Framework Desktop-systemer med forbrugersilicium indeni.

Men der er en del, overskriften sprang over, og det er den del, der afgør, om dette er en milepæl eller et tryllenummer. Der er en arkitekturdetalje, der gør "billion parametre" teknisk ærligt, en hage, der afgør, om du faktisk kunne bruge tingesten, og en grund til, at det betyder mere, end både hypen og modreaktionen giver det kredit for.

Den korte version

• Modellen er Kimi K2.5, og det er et Mixture-of-Experts-design: 1,04 billioner parametre i alt, men kun omkring 32 milliarder af dem aktiveres på et givet token. "Billion-parameter-model" er korrekt; beregningen per token er tættere på en arbejdsbyrde i 32B-klassen.
• Klyngen genererer omkring 8 til 9,5 tokens i sekundet, med en time-to-first-token på alt fra 39,7 til 239,1 sekunder afhængigt af, hvor lang din prompt er. Fint til batch-arbejde. Brutalt til en interaktiv kodningsløkke.
• Det, der ændrede sig, er ikke hastigheden. Det er, at samlet hukommelse satte inferens i frontier-skala på hardware, du kan købe og stille på en hylde, en kategori, der før startede ved "ejer et datacenter".

Hvad AMD faktisk gjorde

Opsætningen er næsten antiklimaktisk, når du først ser den lagt frem. Fire Framework Desktop maskiner, hver med en Ryzen AI Max+ 395 og 128 GB LPDDR5X samlet hukommelse. I BIOS kan hver node eksponere op til 96 GB som dedikeret VRAM, eller 384 GB på tværs af de fire noder; AMD's Linux-gennemgang bruger derefter TTM/kerne-indstillinger til at hæve det til 120 GB per node, eller 480 GB i alt. Det betyder noget, fordi den Kimi K2.5 UD_Q2_K_XL GGUF-build, AMD brugte, er angivet til 375 GB, ikke 240 GB.

Limen er llama.cpp, der kører i RPC-tilstand: én controller-node og tre RPC-servere, med modellen fordelt på alle fire maskiner. AMD angiver forbindelsen som 5 Gbps Ethernet, hvilket passer til Framework Desktops indbyggede 5Gbit Ethernet-port. Det er hele riggen. Ingen eksotisk forbindelse, ingen specialbyggede kort, intet du ikke kunne bestille i eftermiddag.

Det interessante ord i alt det er samlet. På en normal pc er din CPU's RAM og din GPU's VRAM separate puljer, og en model, der er for stor til VRAM'en, enten spildes til langsom systemhukommelse eller kører ikke. Samlet hukommelse fjerner den væg: GPU'en kan adressere hele banken, hvilket er hele grunden til, at en 4,5-liters desktop overhovedet kan rumme en bid af en model i denne størrelse.

AMD's egen tekniske gennemgang dækker konfigurationen i detaljer. Det, den ikke rigtig dækker, er hvorfor "billion parametre" udfører mere retorisk arbejde, end det ser ud til.

Tricket: Hvorfor "billion parametre" er sandt, men ikke hele sandheden

Her er det, specifikationsarket læner sig op ad uden at forklare: Kimi K2.5 er en Mixture-of-Experts-model, og det ændrer, hvad "billion parametre" betyder i praksis.

En tæt model, den slags de fleste forestiller sig, kører hver parameter for hvert token. En tæt model med 70 milliarder parametre udfører matematik svarende til 70 milliarder parametre på hvert ord, den producerer. En Mixture-of-Experts-model er bygget anderledes. Kimi K2.5 har 384 separate "eksperter", hvoraf 8 aktiveres per token plus én delt ekspert, på tværs af 61 lag. Så selvom modellen bærer 1,04 billioner parametre i alt, lyser kun omkring 32 milliarder af dem op ved et enkelt forward pass. En router vælger, hvilke eksperter der skal vækkes; resten sidder der og laver intet for det token.

Så er det ærligt at sige "kører en model med en billion parametre på fire mini-pc'er"? Ja, du har virkelig brug for hukommelsen til at rumme alle 1,04 billioner parametre, og den hukommelse er den svære del. Men den beregning, din hardware skal udføre per token, er en opgave i 32B-klassen, ikke en i 1T-klassen.

Hvilket skærer begge veje, og det er her, det bliver interessant. Det gør demoen mere imponerende, end den lyder, fordi det at holde en fuld billion-parameter-model i hukommelsen på forbrugerkasser er den ægte svære ting, de fik gennemført. Og det gør den mindre imponerende, end overskriften antyder, fordi den faktiske arbejdsbyrde per token er noget, enkelte kasser allerede tygger sig hurtigere igennem på mindre MoE-modeller. En 120B MoE-model kører med 50-plus tokens i sekundet på én af disse noder. Tallet på en billion parametre er ægte, men det er en hukommelsesmuskel, ikke en beregningsmuskel.

Konklusionen: når du dimensionerer hardware til en model, er antallet af aktive parametre det, din maskine skal fodre per token, ikke totalen på kassen.

Hagen: Hvad 8 tokens i sekundet og en ventetid på 40 sekunder til 4 minutter faktisk betyder

Otte tokens i sekundet er tallet, der afgør alt, så lad det synke ind et øjeblik. AMD's artikel rapporterer, at klyngen genererer omkring 8,30 t/s ved en kontekst på 8.192 tokens og cirka 9,45 t/s i stabil tilstand, med promptbehandling omkring 100,77 t/s. Det er fine, fair tal for det, de er.

Den der gør ondt, er time-to-first-token. Før modellen producerer et eneste ord, skal den læse din prompt, og AMD's egen benchmark-tabel sætter den ventetid til 39,7 sekunder for en prompt på 4.096 tokens, 90,5 sekunder for en prompt på 8.192 tokens og 239,1 sekunder for en prompt på 16.384 tokens med Flash Attention aktiveret. Så du skriver et spørgsmål, og så venter du. Muligvis i næsten fire minutter, før der kommer noget tilbage.

Til en interaktiv kodningsløkke er det hårdt, og udviklere i Hacker News-diskussionen sagde det rent ud: et minut-plus af dødtid før det første token passer ikke til den måde, nogen skriver kode med en assistent på. Men vend arbejdsbyrden om. Hvis du kører batch-job natten over, behandler dokumenter asynkront, genererer ting, du læser senere, eller laver privat inferens, hvor hele pointen er, at intet forlader bygningen, er 8 tokens i sekundet helt til at leve med. Du holdt alligevel ikke øje med skærmen.

Stjernen: Forvent ikke, at disse tal reproduceres ud af boksen. ROCm-softwarestakken på denne hardware er versionsfølsom på måder, der bider: et GitHub-issue dokumenterede et Strix Halo-system, der sad fast på idle GPU-clocks og kravlede ved 0,5 t/s under LLM-inferens på ROCm 7.1.1 og Linux-kerne 6.14. Det er ikke "AMD er i stykker", men det betyder, at den offentliggjorte ydeevne afhænger af en meget specifik softwarestak, og du kan ende med at jage ROCm-, kerne- og firmware-kombinationer, før din rig matcher tallene i gennemgangen.

En ting mere, modreaktionen tager fejl af, og det er prisen. Folk bliver ved med at kalde det en "klynge til 10.000 dollars", men ingen offentliggør det som en fast stykliste. Lav regnestykket selv: fire 128 GB Framework Desktops til lanceringsprisen på 1.999 dollars ville sætte maskinerne alene til omkring 8.000 dollars, mens et Liliputing-snapshot fra marts 2026 angav en 128GB/1TB Framework Desktop-konfiguration til 2.851 dollars, eller omkring 11.400 dollars for fire før netværk. Læg et par hundrede dollars til for switch og kabler, og det praktiske spænd er tættere på cirka 8,2K til 11,7K dollars afhængigt af konfiguration, købsdato, og hvad du allerede har. Ikke ingenting. Heller ikke et serverrum.

Her er, hvor jeg lander på det hele: klyngen virker. Om otte tokens i sekundet og en ventetid på et minut-plus er en triumf eller et legetøj, afhænger helt af, hvad du forsøger at bygge. Det er ikke en interaktiv kodnings-workstation. Det er heller ikke et legetøj. Det er en rigtig maskine til en bestemt slags tålmodigt arbejde, og at lade som om det er enten mere eller mindre end det, er måden, alle i denne diskussion ender med at tale forbi hinanden.

Hvor dette faktisk lander

Den ærlige ramme er ikke "AMD slog Nvidia". Det er, at dette er et andet produkt til en anden person. Læseren, der vil have dette, er den, der har brug for privatliv, vil have offline, eller ikke vil betale per token for evigt, ikke den, der jagter det hurtigst mulige svar.

Og det stærkeste argument mod hele øvelsen fortjener et ligefremt svar: du kan bare bruge Kimis API. Artificial Analysis angiver i øjeblikket Kimis eget K2.5-endpoint til omkring 56 til 60 tokens i sekundet med en blandet pris omkring 0,49 dollars per million tokens, mens Kimis officielle API-platform angiver K2.5-priser på 0,10 dollars/M cache-hit input-tokens, 0,60 dollars/M input-tokens og 3,00 dollars/M output-tokens. Tredjeparts K2.5-udbydere kan være hurtigere eller billigere afhængigt af routing, men grundpointen er den samme: API'et er hurtigere end klyngen, undgår hardware-pasning, og vil være det rigtige valg for de fleste på de fleste dage.

Så den lokale historie giver kun mening, når en af tre ting er sand: dataene må ikke forlade stedet (privatliv), forbindelsen kan ikke antages (offline), eller token-mængden er høj nok og vedvarende nok til, at det at eje metallet slår at leje det for evigt (omkostning ved skala). Uden for de tre vinder API'et. Inden for dem er klyngen det eneste, der overhovedet løser opgaven.

For en god ordens skyld er Nvidias DGX Spark det åbenlyse "men hvad med" her, og den vinder på nogle akser, AMD-klyngen ikke gør. Det er en helt separat kamp, og en jeg tager op et andet sted. Hvis du vil have lejesiden af beslutningen mellem hardware og cloud, er Cloudzys GPU VPS side det mere praktiske sammenligningspunkt.

Den del, der faktisk betyder noget

Skræl token-raten og prisargumenterne væk, og ét faktum bliver stående: hardwaren, der kører en model med en billion parametre, er nu en hylde, ikke en bygning.

Det er skiftet, og det er let at overse under hastighedsskænderiet. For et år siden var kategorien af folk, der kunne køre en model med 1,04 billioner parametre, "datacenteroperatører". Punktum. Nu omfatter den enhver med cirka ti tusind dollars og lidt tålmodighed. Linjen flyttede sig ikke en lille smule: en helt ny gruppe mennesker gik lige igennem en dør, der var låst.

Det, der åbner sig, er den interessante del. Private agenter, der kører helt på hardware, du ejer. Inferens, der virker i et fly eller bag en air gap. Modeller, der fysisk ikke kan ringe hjem, fordi der ikke er noget sted, opkaldet kan gå hen. En økonomi for AI, hvor marginalomkostningen for et token er elektricitet i stedet for en målt API-linje. Intet af det var inden for rækkevidde på forbrugerhardware for et år siden, og samlet hukommelse er det, der nåede det.

Jeg har set dette mønster nok gange til at være på vagt over for "dette ændrer alt". Som regel gør det ikke; som regel er det sidste års ting med et nyt logo. Denne her er anderledes, og ikke fordi den er hurtig. Den er anderledes, fordi gulvet flyttede sig. Den langsomme, dyre, tålmodige version af lokal inferens i frontier-skala eksisterer nu, og den hurtige version er bare et spørgsmål om, at de næste få hardware-generationer maler den ned. Den svære del skulle aldrig handle om hastighed. Den svære del var adgang, og adgang skete lige nu.

Milepælen her er ikke hastighed. Det er, hvem der får lov at komme ind i rummet. Maskinen, der kører modeller i frontier-skala, plejede at være en bygning. Nu er den fire kasser på en hylde.

Ofte stillede spørgsmål

Kan du virkelig køre en model med en billion parametre på en klynge af mini-pc'er?

Ja, med ét vigtigt forbehold. AMD kørte Kimi K2.5, en model med 1,04 billioner parametre, på tværs af fire Ryzen AI Max+ 395 mini-pc'er. I BIOS kan de fire systemer eksponere omkring 384 GB dedikeret VRAM i alt; AMD's Linux-gennemgang hæver derefter allokeringen til 480 GB i alt gennem TTM/kerne-indstillinger. Men Kimi K2.5 er en Mixture-of-Experts-model: af de 1,04 billioner parametre aktiveres kun omkring 32 milliarder på et givet token. Du har brug for hukommelsen til at rumme dem alle, men beregningen per token er tættere på en arbejdsbyrde med 32 milliarder parametre.

Hvad er Kimi K2.5, og hvorfor betyder MoE-arkitekturen noget her?

Kimi K2.5 er en open-weight-sprogmodel fra Moonshot AI med 1,04 billioner parametre i alt og 32 milliarder aktive per forward pass, bygget på et Mixture-of-Experts-design (384 eksperter, 8 aktiveret per token plus én delt). Arkitekturen betyder noget, fordi antallet af aktive parametre, ikke totalen, er det, din hardware skal beregne for hvert token. Det er derfor, en model med en billion parametre på papiret overhovedet kan køre på forbrugerkasser.

Er 8 tokens i sekundet hurtigt nok til lokal AI?

Det afhænger helt af arbejdsbyrden. Til batch-behandling, asynkrone job, offline-brug eller privat inferens, hvor intet kan forlade din hardware, er 8 tokens i sekundet fint, du stirrer ikke på skærmen. Til interaktiv kodning er det hårdt, mest fordi time-to-first-token på denne klynge går fra omkring 40 sekunder til næsten 4 minutter afhængigt af promptens længde, og den dødtid før det første ord dræber en iterativ løkke.

Hvorfor ikke bare bruge Kimis API i stedet?

For de fleste bør du. Kimis eget K2.5-endpoint er meget hurtigere end den lokale klynge i de aktuelle Artificial Analysis-data, og tredjeparts K2.5-udbydere kan være hurtigere eller billigere endnu. Den lokale hardware giver kun mening, når du har brug for privatliv (dataene må ikke forlade stedet), offline-evne (ingen forbindelse at antage) eller omkostning ved skala (vedvarende høj mængde, hvor det at eje slår at leje). Uden for de tilfælde er API'et det bedre valg.