AMD baute einen KI-Supercomputer mit einer Billion Parametern aus Mini-PCs

Vor einem Jahr bedeutete der Betrieb eines Sprachmodells mit einer Billion Parametern einen ganzen Serverraum. Racks, Kühlung, eine Stromrechnung, die ein eigenes Meeting brauchte. Dann veröffentlichte AMD einen Entwicklerbericht, der zeigte, wie vier Mini-PCs auf einem Schreibtisch (die Sorte, von der man zwei gleichzeitig tragen kann) dieselbe Aufgabe erledigten. Vier identische kleine Kisten, miteinander verkabelt, die ein Modell ausführten mit mehr Parametern, als es Sterne gibt, die man von einer Straße in der Stadt aus sehen kann.

Die Schlagzeile schreibt sich von selbst: „Keine Cloud. Kein Rechenzentrum." Und das stimmt. AMD hat tatsächlich ein Modell mit 1,04 Billionen Parametern auf vier Framework-Desktop-Systemen mit Consumer-Silizium darin laufen lassen.

Aber es gibt einen Teil, den die Schlagzeile übersprungen hat, und genau dieser Teil entscheidet, ob es sich um einen Meilenstein oder einen Zaubertrick handelt. Es gibt ein Architekturdetail, das „eine Billion Parameter" technisch ehrlich macht, einen Haken, der bestimmt, ob man dieses Ding tatsächlich nutzen könnte, und einen Grund, warum es wichtiger ist, als ihm der Hype oder die Gegenreaktion zugestehen.

Die Kurzfassung

• Das Modell ist Kimi K2.5, und es handelt sich um ein Mixture-of-Experts-Design: 1,04 Billionen Gesamtparameter, aber nur etwa 32 Milliarden davon werden bei einem beliebigen Token aktiviert. „Modell mit einer Billion Parametern" ist korrekt; die Rechenlast pro Token liegt eher bei einem Workload der 32B-Klasse.
• Der Cluster erzeugt rund 8 bis 9,5 Token pro Sekunde, mit einer Zeit bis zum ersten Token zwischen 39,7 und 239,1 Sekunden, je nachdem, wie lang Ihr Prompt ist. In Ordnung für Batch-Arbeit. Brutal für eine interaktive Coding-Schleife.
• Was sich verändert hat, ist nicht die Geschwindigkeit. Es ist die Tatsache, dass Unified Memory Inferenz im Frontier-Maßstab auf Hardware gebracht hat, die man kaufen und ins Regal stellen kann, eine Kategorie, die früher bei „besitze ein Rechenzentrum" anfing.

Was AMD tatsächlich getan hat

Der Aufbau ist fast schon antiklimaktisch, sobald man ihn vor sich ausgebreitet sieht. Vier Framework-Desktop Maschinen, jede mit einem Ryzen AI Max+ 395 und 128 GB LPDDR5X Unified Memory. Im BIOS kann jeder Knoten bis zu 96 GB als dediziertes VRAM bereitstellen, oder 384 GB über die vier Knoten hinweg; AMDs Linux-Anleitung nutzt dann TTM-/Kernel-Einstellungen, um das auf 120 GB pro Knoten anzuheben, oder 480 GB insgesamt. Das ist wichtig, weil der von AMD verwendete Kimi K2.5 UD_Q2_K_XL GGUF-Build mit 375 GB angegeben ist, nicht mit 240 GB.

Der Klebstoff ist llama.cpp, das im RPC-Modusläuft: ein Controller-Knoten und drei RPC-Server, wobei das Modell über alle vier Maschinen verteilt ist. AMD gibt die Verbindung als 5 Gbps Ethernet an, was zum integrierten 5-Gbit-Ethernet-Port des Framework Desktop passt. Das ist das ganze Rig. Keine exotische Verbindung, keine maßgefertigten Platinen, nichts, was Sie nicht heute Nachmittag bestellen könnten.

Das interessante Wort in all dem ist unified. Bei einem normalen PC sind der Arbeitsspeicher Ihrer CPU und das VRAM Ihrer GPU getrennte Pools, und ein Modell, das zu groß für das VRAM ist, läuft entweder in den langsamen Systemspeicher über oder gar nicht. Unified Memory reißt diese Wand ein: Die GPU kann die gesamte Bank adressieren, und genau das ist der Grund, warum ein 4,5-Liter-Desktop überhaupt einen Teil eines Modells dieser Größe halten kann.

AMDs eigener technischer Bericht behandelt die Konfiguration im Detail. Was er nicht wirklich behandelt, ist, warum „eine Billion Parameter" mehr rhetorische Arbeit leistet, als es aussieht.

Der Trick: Warum „eine Billion Parameter" stimmt, aber nicht die ganze Wahrheit ist

Hier ist das, worauf sich das Datenblatt stützt, ohne es zu erklären: Kimi K2.5 ist ein Mixture-of-Experts-Modell, und das verändert, was „eine Billion Parameter" in der Praxis bedeutet.

Ein dichtes Modell, die Sorte, die sich die meisten Menschen vorstellen, nutzt jeden Parameter für jedes Token. Ein dichtes Modell mit 70 Milliarden Parametern rechnet bei jedem Wort, das es erzeugt, im Wert von 70 Milliarden Parametern. Ein Mixture-of-Experts-Modell ist anders aufgebaut. Kimi K2.5 hat 384 separate „Experten", von denen 8 pro Token aktiviert werden, plus einen gemeinsamen Experten, über 61 Schichten. Während das Modell also insgesamt 1,04 Billionen Parameter trägt, leuchten bei einem einzelnen Vorwärtsdurchlauf nur etwa 32 Milliarden davon auf. Ein Router wählt, welche Experten geweckt werden; der Rest sitzt da und tut für dieses Token nichts.

Ist „ein Modell mit einer Billion Parametern auf vier Mini-PCs laufen lassen" also ehrlich? Ja, man braucht den Speicher tatsächlich, um alle 1,04 Billionen Parameter zu halten, und dieser Speicher ist der schwierige Teil. Aber die Rechenarbeit, die Ihre Hardware pro Token leisten muss, ist eine Aufgabe der 32B-Klasse, keine der 1T-Klasse.

Was in beide Richtungen schneidet, und hier wird es interessant. Es macht die Demo beeindruckender , als sie klingt, denn ein vollständiges Modell mit einer Billion Parametern im Speicher von Consumer-Kisten zu halten, ist das wirklich Schwierige, das ihnen gelungen ist. Und es macht sie weniger beeindruckend, als die Schlagzeile suggeriert, denn der tatsächliche Workload pro Token ist etwas, das einzelne Kisten bei kleineren MoE-Modellen bereits schneller durchkauen. Ein 120B-MoE-Modell läuft mit 50-plus Token pro Sekunde auf einem dieser Knoten. Die Zahl von einer Billion Parametern ist real, aber es ist ein Speicher-Flex, kein Rechen-Flex.

Die Erkenntnis: Wenn Sie Hardware für ein Modell dimensionieren, ist die Anzahl der aktiven Parameter das, was Ihre Maschine pro Token verarbeiten muss, nicht die Gesamtzahl auf der Kiste.

Der Haken: Was 8 Token pro Sekunde und eine Wartezeit von 40 Sekunden bis 4 Minuten tatsächlich bedeuten

Acht Token pro Sekunde ist die Zahl, die alles entscheidet, also lassen Sie sie einen Moment auf sich wirken. AMDs Artikel berichtet, dass der Cluster bei einem 8.192-Token-Kontext etwa 8,30 t/s erzeugt und im stationären Zustand rund 9,45 t/s, mit einer Prompt-Verarbeitung von etwa 100,77 t/s. Das sind für das, was sie sind, ordentliche, faire Zahlen.

Die, die wehtut, ist die Zeit bis zum ersten Token. Bevor das Modell auch nur ein einziges Wort erzeugt, muss es Ihren Prompt lesen, und AMDs eigene Benchmark-Tabelle beziffert diese Wartezeit auf 39,7 Sekunden für einen 4.096-Token-Prompt, 90,5 Sekunden für einen 8.192-Token-Prompt und 239,1 Sekunden für einen 16.384-Token-Prompt mit aktiviertem Flash Attention. Sie tippen also eine Frage ein und warten dann. Möglicherweise fast vier Minuten lang, bevor irgendetwas zurückkommt.

Für eine interaktive Coding-Schleife ist das hart, und Entwickler in der Hacker-News-Diskussion sagten das ganz unverblümt: über eine Minute Funkstille vor dem ersten Token passt nicht zu der Art, wie irgendjemand mit einem Assistenten Code schreibt. Aber drehen Sie den Workload um. Wenn Sie Batch-Jobs über Nacht laufen lassen, Dokumente asynchron verarbeiten, Dinge erzeugen, die Sie später lesen, oder private Inferenz betreiben, bei der der ganze Sinn darin besteht, dass nichts das Gebäude verlässt, sind 8 Token pro Sekunde völlig erträglich. Sie haben sowieso nicht auf den Bildschirm geschaut.

Der Sternchen-Vermerk: Erwarten Sie nicht, dass sich diese Zahlen out of the box reproduzieren lassen. Der ROCm-Software-Stack auf dieser Hardware ist versionsabhängig auf eine Weise, die beißt: ein GitHub-Issue dokumentierte ein Strix-Halo-System, das bei Idle-GPU-Takten festhing und unter LLM-Inferenz auf ROCm 7.1.1 und Linux-Kernel 6.14 mit 0,5 t/s dahinkroch. Das heißt nicht „AMD ist kaputt", aber es bedeutet, dass die veröffentlichte Leistung von einem sehr spezifischen Software-Stack abhängt, und Sie könnten am Ende ROCm-, Kernel- und Firmware-Kombinationen durchprobieren, bevor Ihr Rig den Zahlen im Bericht entspricht.

Noch etwas, das die Gegenreaktion falsch versteht, nämlich die Kosten. Die Leute nennen es ständig einen „10.000-Dollar-Cluster", aber niemand veröffentlicht das als feste Stückliste. Rechnen Sie selbst nach: vier 128-GB-Framework-Desktops zum Einführungspreis von 1.999 Dollar würden die Maschinen allein auf etwa 8.000 Dollar bringen, während ein Liliputing-Schnappschuss vom März 2026 eine 128GB/1TB-Framework-Desktop-Konfiguration mit 2.851 Dollar auflistete, oder etwa 11.400 Dollar für vier vor dem Netzwerk. Rechnen Sie ein paar hundert Dollar für Switch und Verkabelung hinzu, und die praktische Spanne liegt eher bei rund 8,2K bis 11,7K Dollar, je nach Konfiguration, Kaufdatum und dem, was Sie bereits haben. Nicht nichts. Aber auch kein Serverraum.

Hier lande ich bei der ganzen Sache: Der Cluster funktioniert. Ob acht Token pro Sekunde und über eine Minute Wartezeit ein Triumph oder ein Spielzeug sind, hängt ganz davon ab, was Sie zu bauen versuchen. Es ist keine interaktive Coding-Workstation. Es ist auch kein Spielzeug. Es ist eine echte Maschine für eine bestimmte Art geduldiger Arbeit, und so zu tun, als wäre es mehr oder weniger als das, ist der Grund, warum in dieser Debatte alle aneinander vorbeireden.

Wo das Ganze tatsächlich landet

Die ehrliche Einordnung lautet nicht „AMD hat Nvidia geschlagen". Es ist, dass dies ein anderes Produkt für eine andere Person ist. Der Leser, der das will, ist derjenige, der Privatsphäre braucht, offline sein will oder nicht für immer pro Token zahlen möchte, nicht derjenige, der der schnellstmöglichen Antwort hinterherjagt.

Und das stärkste Argument gegen die ganze Übung verdient eine klare Antwort: Sie können einfach Kimis API ansteuern. Artificial Analysis listet derzeit Kimis eigenen K2.5-Endpunkt bei rund 56 bis 60 Token pro Sekunde mit einem Mischpreis von etwa 0,49 Dollar pro Million Token auf, während Kimis offizielle API-Plattform die K2.5-Preise mit 0,10 $/M Cache-Hit-Input-Token, 0,60 $/M Input-Token und 3,00 $/M Output-Token angibt. Drittanbieter von K2.5 können je nach Routing schneller oder günstiger sein, aber der grundlegende Punkt bleibt derselbe: Die API ist schneller als der Cluster, erspart das Hardware-Babysitting und wird für die meisten Menschen an den meisten Tagen die richtige Wahl sein.

Die lokale Variante ergibt also nur dann Sinn, wenn eine von drei Bedingungen zutrifft: die Daten dürfen das Gebäude nicht verlassen (Privatsphäre), die Verbindung kann nicht vorausgesetzt werden (offline), oder das Token-Volumen ist hoch genug und nachhaltig genug, dass der Besitz der Hardware das ewige Mieten schlägt (Kosten bei Skalierung). Außerhalb dieser drei gewinnt die API. Innerhalb davon ist der Cluster das Einzige, das die Aufgabe überhaupt erledigt.

Fürs Protokoll: Nvidias DGX Spark ist hier das offensichtliche „aber was ist mit", und er gewinnt auf einigen Achsen, auf denen der AMD-Cluster es nicht tut. Das ist ein ganz eigener Kampf, und einen, den ich an anderer Stelle aufgreifen werde. Wenn Sie die Mietseite der Hardware-vs-Cloud-Entscheidung wollen, ist die GPU-VPS-Seite von Cloudzy der praktischere Vergleichspunkt.

Der Teil, der tatsächlich zählt

Streicht man die Token-Rate und die Preisargumente weg, bleibt eine Tatsache stehen: Die Hardware, die ein Modell mit einer Billion Parametern ausführt, ist jetzt ein Regal, kein Gebäude.

Das ist die Verschiebung, und sie ist im Geschwindigkeitsgezänk leicht zu übersehen. Vor einem Jahr war die Kategorie von Menschen, die ein Modell mit 1,04 Billionen Parametern ausführen konnten, „Rechenzentrumsbetreiber". Punkt. Jetzt gehört dazu jeder mit ungefähr zehn Riesen und etwas Geduld. Die Linie hat sich nicht ein bisschen verschoben: eine ganz neue Gruppe von Menschen ist gerade durch eine Tür gegangen, die verschlossen war.

Was das eröffnet, ist der interessante Teil. Private Agenten, die vollständig auf Hardware laufen, die Sie besitzen. Inferenz, die in einem Flugzeug oder hinter einem Air-Gap funktioniert. Modelle, die physisch nicht nach Hause telefonieren können, weil es kein Ziel für den Anruf gibt. Eine KI-Ökonomie, in der die Grenzkosten eines Tokens Strom statt einer getakteten API-Leitung sind. Nichts davon war vor einem Jahr auf Consumer-Hardware erreichbar, und Unified Memory ist das, was es erreicht hat.

Ich habe dieses Muster oft genug beobachtet, um bei „das verändert alles" vorsichtig zu sein. Meistens tut es das nicht; meistens ist es die Sache vom letzten Jahr mit einem neuen Logo. Diese hier ist anders, und nicht, weil sie schnell ist. Sie ist anders, weil sich der Boden verschoben hat. Die langsame, teure, geduldige Variante lokaler Inferenz im Frontier-Maßstab existiert jetzt, und die schnelle Variante ist nur eine Frage der nächsten paar Hardware-Generationen, die sie abschleifen. Der schwierige Teil sollte nie die Geschwindigkeit sein. Der schwierige Teil war der Zugang, und der Zugang ist gerade passiert.

Der Meilenstein hier ist nicht die Geschwindigkeit. Es ist, wer in den Raum gelassen wird. Die Maschine, die Modelle im Frontier-Maßstab ausführt, war früher ein Gebäude. Jetzt sind es vier Kisten in einem Regal.

Häufig gestellte Fragen

Kann man wirklich ein Modell mit einer Billion Parametern auf einem Mini-PC-Cluster laufen lassen?

Ja, mit einer wichtigen Einschränkung. AMD ließ Kimi K2.5, ein Modell mit 1,04 Billionen Parametern, über vier Ryzen AI Max+ 395 Mini-PCs laufen. Im BIOS können die vier Systeme insgesamt etwa 384 GB dediziertes VRAM bereitstellen; AMDs Linux-Anleitung hebt die Zuweisung dann über TTM-/Kernel-Einstellungen auf insgesamt 480 GB an. Aber Kimi K2.5 ist ein Mixture-of-Experts-Modell: von diesen 1,04 Billionen Parametern werden bei einem beliebigen Token nur etwa 32 Milliarden aktiviert. Sie brauchen den Speicher, um sie alle zu halten, aber die Rechenlast pro Token liegt näher an einem Workload mit 32 Milliarden Parametern.

Was ist Kimi K2.5 und warum ist die MoE-Architektur hier wichtig?

Kimi K2.5 ist ein Open-Weight-Sprachmodell von Moonshot AI mit 1,04 Billionen Gesamtparametern und 32 Milliarden aktiven pro Vorwärtsdurchlauf, aufgebaut auf einem Mixture-of-Experts-Design (384 Experten, 8 aktiviert pro Token plus einer gemeinsam). Die Architektur ist wichtig, weil die Anzahl der aktiven Parameter, nicht die Gesamtzahl, das ist, was Ihre Hardware für jedes Token berechnen muss. Genau deshalb kann ein Modell mit einer Billion Parametern auf dem Papier überhaupt auf Consumer-Kisten laufen.

Sind 8 Token pro Sekunde schnell genug für lokale KI?

Das hängt ganz vom Workload ab. Für Batch-Verarbeitung, asynchrone Jobs, Offline-Nutzung oder private Inferenz, bei der nichts Ihre Hardware verlassen darf, sind 8 Token pro Sekunde in Ordnung, Sie starren nicht auf den Bildschirm. Für interaktives Coding ist es hart, vor allem weil die Zeit bis zum ersten Token auf diesem Cluster je nach Prompt-Länge von etwa 40 Sekunden bis fast 4 Minuten reicht, und diese Funkstille vor dem ersten Wort tötet eine iterative Schleife.

Warum nicht einfach Kimis API stattdessen nutzen?

Für die meisten Menschen sollten Sie genau das tun. Kimis eigener K2.5-Endpunkt ist in den aktuellen Daten von Artificial Analysis deutlich schneller als der lokale Cluster, und Drittanbieter von K2.5 können noch schneller oder günstiger sein. Die lokale Hardware ergibt nur dann Sinn, wenn Sie Privatsphäre brauchen (die Daten dürfen nicht weg), Offline-Fähigkeit (keine Verbindung vorausgesetzt) oder Kosten bei Skalierung (nachhaltig hohes Volumen, bei dem Besitz das Mieten schlägt). Außerhalb dieser Fälle ist die API die bessere Wahl.