Verfasst von Sarah Chieng, Head of DevX (@MilksAndMatcha
Eine der häufigsten Fragen, die wir erhalten, ist, wie wir große Modelle auf Cerebras-Wafer-Scale-Chips bereitstellen. Ein einzelner Cerebras WSE-3T-Wafer verfügt über 44 GB On-Chip-Speicher, und Frontier-Modelle mit Billionen von Parametern benötigen allein für ihre Gewichte Terabytes.
In diesem Beitrag erklären wir, wie wir ein großes Frontier-Modell auf mehrere WSE-3T-Wafer aufteilen, um Modelle mit mehreren Billionen Parametern bei 1000–2000+ Token pro Sekunde auszuführen.
Als anschauliches Beispiel verwenden wir das Open-Source-Modell Kimi K3 mit rund 3 Billionen Parametern.
Am Ende wirst du Folgendes verstehen:
- Wie wir das gesamte Modell in den On-Chip-Speicher einpassen
- Wie wir das Modell auf mehrere Chips verteilen
- Wie wir eine hohe Anzahl gleichzeitiger Anfragen bewältigen
Aufgeschlüsselt am Beispiel von Kimi K3
Kimi K3 ist ein Open-Source-Modell mit 3 Billionen Parametern, bestehend aus 69 Linear-Attention-Layern und 24 Dense-Layern.

Es erreicht beeindruckende 88,3 % im Terminal-Bench 2.1 (im Vergleich zu 88,8 % bei GPT-5.6 Sol) und 91,2 % bei BrowseComp (im Vergleich zu 90,4 % bei GPT-5.6 Sol). Diese Ergebnisse belegen Coding- und Agentenfähigkeiten auf Frontier-Niveau, die bei einigen Benchmarks sogar führende proprietäre Modelle übertreffen. Hier erfährst du mehr über Kimi K3.

Für dieses anschauliche Beispiel gehen wir von folgenden Werten aus:
- Eine angenommene durchschnittliche Anfragegröße von 256k
- 4-Bit-Gewichtsquantisierung (wie in der Hugging-Face-Implementierung
- Ein 8-Bit-KV-Cache
#1: Größe jedes Layers
Um die Gesamtzahl der benötigten Cerebras WSE-3T-Wafer für Kimi K3 zu berechnen, ermitteln wir zunächst die Größe jedes Modell-Layers.
Kimi K3 hat 3 Billionen Parameter. Wenn alle 3 Billionen Parameter mit jeweils 4 Bit gespeichert werden, ergibt sich folgende reine Parameterdatenmenge:

Teilt man diese Datenmenge durch 93 Layer, erhält man:

#2: Anzahl der Wafer
Da wir nun wissen, dass jeder Layer etwa 16 GB benötigt, können wir herausfinden, wie viele Layer auf einen 44-GB-Wafer passen. Die Antwort hängt vom Layertyp ab:
- Dense-Layer benötigen zusätzlichen Platz für einen KV-Cache, da jeder Dense-Layer (Full-Attention) die Schlüssel und Werte für jedes Token in jeder aktiven Anfrage speichert. Daher platzieren wir einen Dense-Layer pro Wafer und nutzen den verbleibenden SRAM für dessen KV-Cache.
- Linear-Attention-Layer benötigen keinen zusätzlichen Platz für einen KV-Cache. Anstatt Schlüssel und Werte für jedes Token zu speichern, hält ein Linear-Attention-Layer einen kleinen Zustand fester Größe pro Anfrage – unabhängig von der Kontextlänge. Dadurch ist Platz für zwei Linear-Layer pro Wafer (2 × 16 GB = 32 GB).

Mit den 69 Linear-Layern und 24 Dense-Layern von Kimi K3 ergibt sich also:

Das führt zu einer Gesamtzahl von 35 + 24 = 59 Wafern.
#3: Die Wafer miteinander verbinden
Cerebras führt Modelle in einer Pipeline aus. Nachdem der Cerebras-Compiler die Modell-Layer auf verschiedene Bereiche der Wafer verteilt hat, legt die Laufzeitumgebung den Pfad fest, über den die Token zwischen den Wafern fließen. Für ultraniedrige Latenzen müssen nur die Aktivierungen zwischen den Wafern weitergegeben werden, was über RDMA via Ethernet erfolgen kann. Das dauert pro Hop etwa 2 Mikrosekunden.

Wichtig hervorzuheben ist: Da jeder Cerebras-Wafer über 44 GB On-Chip-SRAM verfügt und jeder Layer nur 16 GB groß ist, können wir in der Regel ganze Modell-Layer direkt auf dem Chip unterbringen.
Das bedeutet, dass sich die Modellgewichte in den meisten Fällen gar nicht bewegen müssen und Layer nicht über mehrere Wafer aufgeteilt werden müssen. Nur die Aktivierungen wandern von einem Wafer zum nächsten.
#4: Wie wir 1 Anfrage bedienen
Nachdem unsere Wafer verbunden und das Modell angelegt ist, können wir uns jeden Wafer als eine Station an einem Fließband vorstellen: Die Modellgewichte jeder Station bleiben an ihrem Platz, während die Zwischenergebnisse der Anfrage die einzelnen Layer-Stationen durchlaufen.
Zum Beispiel verarbeitet Wafer 1 die Modell-Layer 1–2 und sendet seine Aktivierungen an Wafer 2. Wafer 2 verarbeitet die Layer 3–4 und gibt seine Ergebnisse an Wafer 3 weiter – und so weiter, bis der letzte Wafer das nächste Token erzeugt.

#5: Wie wir viele Anfragen bedienen
Hier entsteht oft ein Missverständnis: Wenn ein Token jeden Wafer der Reihe nach durchlaufen muss, liegt dann nicht jeder Wafer untätig herum, während er auf seinen Einsatz wartet? Würde das System dadurch nicht effektiv mit einer Batch-Größe von eins arbeiten?
Nein! Wenn wir immer nur eine Anfrage gleichzeitig durch die Pipeline schicken und warten würden, bis sie abgeschlossen ist, bevor die nächste startet, wäre das eine ineffiziente Nutzung der Pipeline. Stattdessen halten wir die gesamte Pipeline mit verschiedenen Anfragen gefüllt. Da das Modell bereits in Pipeline-Stufen aufgeteilt ist, kann jede Stufe gleichzeitig an einer anderen Anfrage arbeiten.
Während Stufe 3 ein Token für Anfrage A verarbeitet, bearbeitet Stufe 2 eines für Anfrage B und Stufe 1 eines für Anfrage C. In unserem Beispiel entspricht jede Stufe einem Layer. In der Produktivumgebung nutzt Cerebras deutlich feingranularere Stufen – und viel mehr davon.

Jede Stufe kann zudem einen Mikro-Batch verarbeiten, also eine kleine Gruppe von Anfragen statt nur einer einzigen. Die Anzahl der gleichzeitig laufenden Anfragen entspricht daher ungefähr der Anzahl der Stufen multipliziert mit der Mikro-Batch-Größe.

Der Kompromiss dabei: Kleinere Mikro-Batches machen jede einzelne Anfrage noch schneller, während größere Mikro-Batches den Gesamtdurchsatz erhöhen.
#6: Wie viele Anfragen können wir bedienen?
Die Menge des für den KV-Cache reservierten On-Chip-Speichers bestimmt die maximale Anzahl gleichzeitiger Anfragen. Jede laufende Anfrage benötigt auf jedem Dense-Layer-Wafer einen eigenen KV-Cache, weshalb die Größe des On-Chip-Speichers die Obergrenze für gleichzeitige Anfragen setzt. Wie oben erklärt, müssen wir den KV-Cache-Bedarf nur für Dense-Layer berechnen.
Für jeden 44-GB-Wafer, der bereits einen Dense-Layer enthält, lässt sich der verbleibende Speicherplatz für den KV-Cache folgendermaßen berechnen:
Gesamtspeicher des Wafers minus Größe eines Dense-Layers. In diesem Fall:

Berechnung der Anzahl gleichzeitiger Anfragen
Um die Anzahl der unterstützten gleichzeitigen Anfragen für eine bestimmte Modellverteilung zu ermitteln, berechnen wir zunächst, wie viel Cache eine einzelne 256k-Anfrage belegt:

Um anschließend die Gesamtzahl der gleichzeitigen Anfragen zu berechnen, die diese Konfiguration unterstützt, teilen wir:

Die Gesamtzahl der gleichzeitigen Anfragen gibt an, wie viele Anfragen zu einem beliebigen Zeitpunkt parallel durch die Pipeline laufen. Im Gegensatz zu einem GPU-Batch warten diese Anfragen nicht darauf, dass andere abgeschlossen sind – sie strömen kontinuierlich durch die Pipeline.
Natürlich sagen weder Parallelität noch Batch-Größe exakt aus, wie effizient ein Inferenzsystem arbeitet. Bei der Bewertung des Durchsatzes eines Inferenzsystems ist die aussagekräftigere Metrik der gesamte Token-Durchsatz pro Leistungseinheit (z. B. Token pro Sekunde pro Megawatt), gemessen bei gleicher Generierungsgeschwindigkeit.
Wie das über 3 Billionen Parameter hinaus skaliert
Derselbe Ansatz lässt sich auch auf größere Modelle übertragen: Berechne den benötigten Speicher für Gewichte und Anfragezustand, verteile das Modell auf die Wafer und verbinde sie zu einer Pipeline. Jeder zusätzliche Wafer bringt Rechenleistung und On-Chip-Speicher mit, sodass wir Modelle unterstützen können, die die Kapazität eines einzelnen Chips übersteigen.
Danke, dass du gemeinsam mit uns gelernt hast! Möchtest du ein Modell auf Cerebras bereitstellen oder mit unserer Inferenz-Cloud entwickeln?
- Starte mit unserer kostenlosen API: cloud.cerebras.ai
- Kontaktiere unser Vertriebsteam: sales@cerebras.ai
- Lies weitere Artikel auf cerebras.ai
- Den Originalartikel findest du hier.
Designs von @halleychangg. Vielen Dank an Atharva Talpade, Zhenwei Gao, Angela Yeung, Jessica Liu, Joyce Er, Emma Call und Rohan Gupta für ihr Review und Feedback.





