Unternehmen · 9. Juli 2026
Cerebras und die Latenz-Frontier
In der Ära der Inferenz ist die begrenzende Ressource nicht mehr die reine Rechenleistung, sondern Speicherbandbreite und Latenz. Cerebras antwortet mit einem Prozessor im Wafer-Maßstab, dessen SRAM-zentriertes Design Modellspeicher von Rechenleistung trennt — eine Wette auf latenzorientierte Inferenz, die den Kompromiss zwischen Durchsatz und Interaktivität neu ordnet und neue Anwendungsklassen erschließt.
Die Entwicklung der KI-Infrastruktur war lange vom Streben nach roher Rechenleistung geprägt. In der Ära der Inferenz stoßen anspruchsvolle Reasoning-, Long-Context-, agentische und multimodale Workloads jedoch vor allem an die Grenzen von Speicherbandbreite und Latenz bei der Token-Generierung. Herkömmliche GPU-Architekturen, die Daten über physische Gehäuse hinweg zu externem High-Bandwidth-Memory (HBM) schaufeln müssen, sind an eine physische Speicherwand gestoßen: Bei niedrigen Batch-Größen müssen für jedes neue Token große Mengen an Gewichten und KV-Cache über die HBM-Schnittstelle bewegt werden, während die Recheneinheiten stillstehen und auf Daten warten.
Cerebras hat dafür ein System gebaut, das sich grundlegend von den etablierten GPU- und TPU-Stacks unterscheidet. Statt vieler vergleichsweise kleiner Beschleuniger, die über Hochgeschwindigkeitsverbindungen gekoppelt sind, nutzt es einen einzigen Prozessor im Wafer-Maßstab als primäres Rechenbauteil und trennt Modellspeicher von Rechenleistung: Modellparameter und Optimizer-Zustand liegen in einem externen Speicherdienst und werden bei Bedarf Schicht für Schicht gestreamt, während Aktivierungen und Modellgewichte in sehr schnellem On-Chip-SRAM bleiben. Dieses SRAM-zentrierte Design im Wafer-Maßstab ist ausdrücklich auf latenzsensitive Inferenz ausgelegt — auf ein Regime also, in dem GPUs den Speicherverkehr nicht über Batching amortisieren können und die Tokens pro Sekunde pro Nutzer direkt mit der Speicherbandbreite skalieren.
Diese Architektur fügt dem klassischen Inferenz-Kompromiss zwischen Durchsatz und Interaktivität eine neue Achse hinzu. Bislang mussten Anbieter zwischen zwei Optionen wählen: viele Nutzer langsam bedienen (großes Batch, hoher Durchsatz, mittelmäßige Latenz pro Nutzer) oder wenige Nutzer schnell (kleines Batch, niedriger Durchsatz, gute Latenz). Der dominierende Hebel war dabei die Batch-Größe. Kleinere Batches bedeuten weniger Nutzer, höhere Geschwindigkeiten und damit höhere effektive Preise pro Token. Schnelle Coding-Tarife wie Codex Spark oder Claude Code Fast setzten genau auf dieses Regime und wurden entsprechend bepreist; sowohl unsere eigene Erfahrung als auch der breitere Entwicklerdiskurs deuten auf eine echte Zahlungsbereitschaft für spürbar höhere Geschwindigkeit und flüssigere Interaktion hin.
Cerebras bietet Hardware, die architektonisch auf gleichzeitig hohen Durchsatz und niedrige Latenz ausgelegt ist, statt sich allein auf Batching-Tricks zu verlassen. In den folgenden Abschnitten betrachten wir die technischen Details und Grenzen von Cerebras' Ansatz, die neuen Arten von Anwendungen und Mensch–Maschine-Interaktionen, die er eröffnet, und warum wir dieser latenzorientierten Inferenz-Hardware trotz realer ökonomischer und architektonischer Hürden grundsätzlich optimistisch gegenüberstehen.
Hardware-Architektur
Retikel-Grenze und Integration im Wafer-Maßstab
Über ein halbes Jahrhundert lang war die Halbleiterfertigung durch die Retikel-Grenze beschränkt: die maximale Fläche, die ein Lithografiesystem in einer einzigen Belichtung abbilden kann, rund 26 mm × 33 mm oder ~858 mm² auf modernen Anlagen. Ein 300-mm-Wafer wird deshalb als Raster identischer Dies strukturiert; nach der Belichtung zerteilt man ihn entlang der Ritzlinien in einzelne Chips, die dann verpackt und zu größeren Systemen verbunden werden.
Cerebras geht einen anderen Weg und zerschneidet den Wafer nicht. Der WSE-3 entsteht aus einem gewöhnlichen TSMC-N5-Wafer, auf dessen Oberfläche rund 84 Retikelbilder gedruckt sind. Statt entlang der Ritzlinien zu zerteilen, ergänzt Cerebras eigens entwickelte Metallisierungsschritte, um über eine Million mikroskopisch feiner Leiterbahnen über die Retikelgrenzen hinweg zu führen und die nominellen Dies so zu einer einzigen, zusammenhängenden Rechenfläche zu vernähen.
Die Wafer-Scale Engine 3 (WSE-3) misst 46.225 mm², beherbergt ~4 Billionen Transistoren und liefert 125 Petaflops KI-Spitzenleistung in Sparse-FP16. Möglich wird das durch eine Fail-in-place-Architektur: Cerebras stellt mehr Kerne und Interconnect bereit als nötig, kartiert Defekte nach der Fertigung und umgeht fehlerhafte Regionen — so bleiben selbst auf Wafern mit Dutzenden Defekten rund 900.000 funktionierende Kerne garantiert.
Kerne, Mesh und SRAM
Anders als GPUs, die auf gemeinsame Cache-Hierarchien mit externem HBM setzen, nutzt der WSE-3 ein verteiltes, SRAM-zentriertes Design:
- ~900.000 KI-optimierte Kerne, jeder mit eigenem lokalem SRAM und einem feingranularen Befehlssatz, der auf sparse Tensor-Operationen abgestimmt ist.
- 44 GB On-Chip-SRAM, über den Wafer verteilt — weit mehr On-Die-Speicher, als herkömmliche GPUs oder selbst Groqs LPUs bieten.
- ein 2D-Mesh-Interconnect, der die Kerne verbindet, mit einer aggregierten internen Bandbreite von rund 21 PB/s — weit über den 3,35–8 TB/s HBM-Bandbreite von High-End-GPUs.
Für Workloads, deren aktives Working Set in das 44-GB-SRAM-Budget passt, kann die WSE die Daten nahe an der Rechenleistung halten und einen Großteil der Latenz- und Bandbreitenstrafe des HBM vermeiden, die GPU-Inferenz dominiert.
Cerebras nennt 125 PFLOPS in Sparse-FP16 für den WSE-3, doch das setzt eine strukturierte 1:8-Sparsity voraus — also nur 12,5 % von null verschiedene Gewichte. Nvidia gibt Sparse-Durchsatz üblicherweise bei 2:4-Sparsity an, mithin 50 % von null verschiedene Gewichte. Auf dichter FP16-Basis liegt der WSE-3 näher bei 15–16 PFLOPS. Diese angegebenen Sparsity-Konfigurationen kommen in der Produktion nicht zum Einsatz und sind ziemlich nutzlos: Bei Nvidia wie bei Cerebras sind sie rein theoretisch.
Weight Streaming und disaggregierte Parameterspeicherung
Die 44 GB SRAM der WSE sind nach On-Chip-Maßstäben groß, aber klein gemessen an Frontier-Modellgewichten. Grob gerechnet fasst sie:
- ~22 Mrd. Parameter in FP16
- ~44 Mrd. Parameter in INT8
- ~88 Mrd. Parameter in INT4 / FP4
Für Modelle, die nicht vollständig ins On-Chip-SRAM passen, setzt Cerebras beim Training und in einigen Ausführungsmodi großer Modelle auf Weight Streaming: Die Modellparameter liegen in MemoryX, dem externen Modellspeicher-System, und werden Schicht für Schicht in die Wafer-Scale Engine gestreamt. Die WSE berechnet eine Schicht und geht dann zur nächsten über. So kann Cerebras Modelle trainieren und ausführen, die deutlich größer sind als der lokale Speicher der WSE, ohne den vollständigen Parametersatz auf jedem Wafer resident zu halten. Der kommerzielle Fokus hat sich inzwischen jedoch stark zur Inferenz verschoben, und für das Training auf Frontier-Ebene bleiben Nvidia-GPU-Cluster bei den meisten Labs die Standardwahl.
Solange GPUs die Messlatte für das Preis-Leistungs-Verhältnis im Training setzen und ein Cerebras-Deployment eine ganze Kette unterstützender Komponenten um den Wafer legt — MemoryX, SwarmX, externen DRAM, CPU-Infrastruktur und zusätzliches Networking —, lässt sich diese Stückliste für allgemeines Training schwer rechtfertigen, sofern Cerebras nicht bei bestimmten Workloads einen klaren Leistungs- oder Kostenvorteil liefert.
Bei latenzsensitiver Inferenz wäre es zu teuer, große Gewichte wiederholt über die Off-Wafer-Verbindung zu streamen. Naheliegender ist es, die Gewichte über einen oder mehrere Wafer resident zu halten und Pipeline-Parallelismus zu nutzen: Jede WSE hält einen Ausschnitt des Modells, und die Aktivierungen wandern zwischen den Stufen. Aktivierungen sind weit kleiner als Gewichte, weshalb dies besser zu den externen Bandbreitengrenzen der WSE passt, als jede Schicht über mehrere Geräte zu verteilen.
Weight Streaming hilft Cerebras, die Modellgröße zu skalieren, doch schnelle Inferenz lebt davon, den Hot Path so lokal wie möglich zu halten: Gewichte resident, Aktivierungen zwischen den Stufen in Bewegung und möglichst wenig Verkehr über die Systemgrenze hinweg.
KV-Cache, KVSS und Off-Wafer-Bandbreitengrenzen
KV-Cache ist schwieriger zu handhaben als Gewichte, weil er mit dem Workload wächst. Gewichte sind für ein gegebenes Modell fix; der KV-Cache wächst dagegen mit Kontextlänge, Nebenläufigkeit, Schichtzahl und Hidden-Dimension. Bei Coding-Assistenten und interaktiven Agenten mit langen Kontexten kann er zum dominierenden Speicherverbraucher werden.
Sobald der KV-Cache nicht mehr ins SRAM-Budget der WSE passt, muss er außerhalb des Wafers liegen. In Cerebras' Produktions-Inferenzarchitektur heißt das unter Umständen, den KV-Cache auf ein separates Dual-Socket-Chassis mit AMD-CPUs auszulagern — das KVSS oder KV-Cache Server System — mit bis zu 6 TB DDR5-DRAM. Lese- und Schreibzugriffe auf den KV-Cache laufen dann über denselben Off-Wafer-Pfad wie der übrige Systemverkehr.
Bei kurzen und mittleren Kontexten kann Cerebras vom lokalen SRAM des Wafers und der hohen internen Bandbreite profitieren. Bei langen Kontexten und hoher Nebenläufigkeit sitzt der aktive Attention-Zustand zunehmend außerhalb des Wafers, und die 21 PB/s interner Bandbreite verlieren an Bedeutung. Die Leistung hängt dann von Off-Wafer-I/O, DDR5-Bandbreite und der Cache-Management-Strategie ab.
Interconnect und Scale-Out gegenüber GPU-Clustern
Cerebras' SwarmX-Fabric verbindet mehrere CS-Systeme und trägt das MemoryX/WSE-Ausführungsmodell. Ziel ist ein möglichst einfaches Programmiermodell: MemoryX verwaltet die Parameter, SwarmX koordiniert Broadcast und Reduktion, und jede WSE verhält sich eher wie ein großer logischer Prozessor als wie ein kleiner Knoten in einem GPU-Cluster.
SwarmX ist vor allem für Cerebras' Trainings- und Weight-Streaming-Architektur relevant. Es verteilt die Gewichte von MemoryX per Broadcast an mehrere WSEs und führt die Gradienten während des Trainings wieder zusammen. Theoretisch lässt sich damit das Training großer Modelle vereinfachen, doch der Reiz schwindet, sobald ein Modell häufige, bandbreitenintensive Kommunikation über viele Beschleuniger hinweg braucht: verteilter KV-Cache, MoE-Expert-Routing, unregelmäßiger Pipeline-Verkehr oder feingranulare Collectives. Zum Nachteil von Cerebras setzen Frontier-Modelle zunehmend genau auf diese Muster. Einen klaren Trainingsvorteil für SwarmX, der über die Vereinfachung von Teilen des Weight-Streaming-Setups hinausginge, sehen wir kaum.
Hier behält Nvidia seinen Vorteil. NVLink und NVSwitch sind komplex und teuer, doch sie schaffen eine große GPU-Domäne mit hoher Bandbreite. Ein GB200-NVL72-Rack verbindet 72 Blackwell-GPUs mit 130 TB/s aggregierter NVLink-Bandbreite. Innerhalb des Wafers verfügt Cerebras über enorme Bandbreite, während der CS-3 nach außen nur rund 1,2 Tb/s — also ~150 GB/s — an System-I/O bereitstellt.
Wo Cerebras glänzt
Cerebras ist gezielt für decode-lastige Inferenz, niedrige bis mittlere Batch-Größen, kurze bis mittlere Kontexte und Workloads, bei denen die Latenz pro Nutzer zählt, ausgelegt. SRAM im Wafer-Maßstab, Weight Streaming und sparse oder distillierte Modelle können Token-Geschwindigkeiten erreichen, die GPU-Systeme sonst nur mit kleineren Modellen, stärkerem Batching oder aggressiverer Kompression schaffen.
Token-Geschwindigkeit, distillierte Modelle und MoE
Cerebras' klarster Vorteil sind die Tokens pro Sekunde pro Nutzer. Im Cloud-Angebot läuft gpt-oss-120B als Produktionsmodell mit rund 3.000 Tokens pro Sekunde, und für Coding-Workloads hat Cerebras GLM-4.7 mit etwa 1.000 Tokens pro Sekunde herausgestellt. Zudem macht Cerebras Kimi K2.6, ein offenes Modell mit einer Billion Parametern, für Unternehmenskunden verfügbar.
Am besten passt ein Modell, das groß genug ist, um nützlich zu sein, aber so zugeschnitten, dass die aktive Berechnung nahe am Wafer bleibt. Offene Reasoning-Modelle, distillierte Modelle, coding-spezialisierte Modelle und MoE-Modelle passen zu diesem Profil besser als dichte Frontier-Modelle mit sehr großem aktivem Footprint und starkem KV-Cache-Druck bei langen Kontexten.
GLM-4.5 etwa ist ein MoE-Modell mit 355 Mrd. Parametern und 32 Mrd. aktiven Parametern pro Token. Dieser aktive Footprint liegt viel näher an einem mittelgroßen dichten Modell als an einem vollen 355-Mrd.-Dense-Modell. Die Hardware gewinnt, wenn sich die aktiven Experten effizient streamen, cachen oder einplanen lassen. Wird das Expert-Routing jedoch zu feingranular oder zu verstreut, verliert das System an Auslastung und verwandelt Sparsity in ein Problem der Speicherbewegung.
Cerebras hat für dieses Problem einen eigenen MoE-Stack gebaut. REAP — Router-weighted Expert Activation Pruning — entfernt wenig einflussreiche Experten aus großen MoE-Modellen, statt sie zu verschmelzen, und senkt so den Speicheraufwand bei weitgehend erhaltener Modellqualität. Nach Angaben von Cerebras kann REAP bis zu 50 % der Experten aus MoE-Modellen mit bis zu 1 Bio. Parametern entfernen, bei begrenztem Qualitätsverlust auf generativen Benchmarks.
Batch Tiling on Attention (BTA) setzt an der Auslastung an. MoE-Schichten wollen für eine effiziente Expertenberechnung oft große Batches, während Attention stärker speichergebunden ist. Cerebras' BTA entkoppelt beides: Es verarbeitet Attention in kleineren Kacheln und speist dann ein größeres effektives Batch in die Expertenschichten. Anders gesagt: Die Software lässt sparse MoE für die Hardware weniger unregelmäßig erscheinen.
AWS und disaggregierte Inferenz
Neben der Vorzeige-Partnerschaft mit OpenAI bestätigt der AWS-Deal Cerebras als Decode-Beschleuniger. AWS betreibt Cerebras-CS-3-Systeme in eigenen Rechenzentren und stellt den daraus entstehenden Fast-Inference-Dienst über Amazon Bedrock bereit. Es ist ein geteilter Inferenz-Stack: AWS Trainium übernimmt das Prefill, Cerebras das Decode. Prefill verarbeitet den Prompt, baut den KV-Cache auf und ist vergleichsweise parallel und rechenintensiv. Decode erzeugt ein Token nach dem anderen, lässt sich ohne Latenzverlust schwerer batchen und reagiert empfindlicher auf die Speicherbandbreite. Im AWS-Design erledigt Trainium die dichte Prompt-Verarbeitung, dann übernimmt Cerebras die latenzsensitive Phase der Token-Generierung. AWS und Cerebras zufolge kann das kombinierte System bei gleichem Hardware-Footprint bis zu 5× mehr Hochgeschwindigkeits-Token-Kapazität liefern.
Die entscheidende Frage ist, ob das im großen Maßstab sauber funktioniert. Disaggregiertes Prefill/Decode schafft einen neuen Datenpfad: Trainium erzeugt den KV-Cache, der dann zum Decode-System von Cerebras wandern muss. Dieser Transfer bringt Switch-Latenz mit sich, verbraucht Netzwerkbandbreite und drückt zusätzlichen Verkehr über genau den Off-Wafer-Pfad, der die WSE bei langen Kontexten ohnehin schon einengt.
Hardware–Software-Co-Design
Cerebras braucht Hardware–Software-Co-Design stärker als ein universeller GPU-Stack. Die WSE hat enorme lokale Bandbreite, doch der Workload muss um den Wafer herum geformt werden: Die aktiven Parameter müssen handhabbar bleiben, das Routing vorhersehbar sein, und der Serving-Stack muss die Kerne ausgelastet halten.
REAP und Batch Tiling on Attention sind Beispiele dafür auf der Ebene der Modellausführung. Dasselbe Muster zeigt sich nun in den Partner-Deployments. Cognition zufolge wurde SWE-1.5 auf Cerebras mit bis zu 950 Tokens pro Sekunde bereitgestellt. OpenAI bezeichnet GPT-5.3-Codex-Spark als sein erstes Echtzeit-Coding-Modell; es läuft auf Cerebras und erreicht unter passender Konfiguration mehr als 1.000 Tokens pro Sekunde. Beide sind Coding-Systeme, die um niedrige Latenz herum gebaut sind — das Modell muss editieren, reagieren, verzweigen und Fehler auffangen, ohne den Entwickler aus dem Flow zu reißen.
Das OpenAI-Deployment weitet dies von einem einzelnen Modell auf die Infrastruktur aus. OpenAI hat sich zu 750 MW an Cerebras-Systemen für latenzarme Inferenzkapazität verpflichtet, mit Codex-Spark als erstem öffentlichen Modell der Partnerschaft. In dieser Größenordnung hat OpenAI einen starken Anreiz, Modellgröße, Distillation, Serving-Strategie und Workload-Routing auf die WSE abzustimmen. AWS bewegt sich von der Cloud-Seite in dieselbe Richtung: Bedrock nutzt Trainium fürs Prefill und Cerebras fürs Decode und macht damit die Serving-Architektur selbst hardwarespezifisch.
Herausforderungen
Die Cerebras-Architektur versteht man am besten über ihren Trade-off. Der Wafer verschafft dem System eine riesige lokale Rechen- und Speicherdomäne — deshalb kann es im richtigen Inferenz-Regime so schnell sein. Doch dasselbe Design bringt harte Beschränkungen mit sich. SRAM skaliert nicht wie Logik. Ein Wafer hat nur begrenzte Randfläche für I/O. Der Compiler muss Modelle auf ein festes zweidimensionales Gefüge abbilden. Und sobald Gewichte, KV-Cache oder Expert-Verkehr den Wafer verlassen, beginnt das System den Lokalitätsvorteil einzubüßen, der es auszeichnet.
SRAM-Dichte und das Skalierungsplateau
Die grundlegendste langfristige Beschränkung der Cerebras-Architektur ist, dass SRAM bei Wechseln des Prozessknotens schlecht skaliert. SRAM-Zellen brauchen sechs Transistoren pro Bit und sind auf Stabilität und Lese-/Schreibgeschwindigkeit ausgelegt, nicht auf Flächendichte. Rund die Hälfte der WSE-3-Die-Fläche entfällt auf SRAM. Auf TSMC N5 ergibt das 44 GB über 46.225 mm². Ein Wechsel zu N3E oder N2 verkleinert die SRAM-Zellfläche nicht nennenswert — ein WSE-4 auf N5 (gleicher Prozess, höherer Takt) erhielte also dieselben 44 GB, und ein hypothetisches künftiges Gerät auf N3 nur bescheidene Zuwächse.
Der WSE-1 (16 nm) lieferte 18 GB SRAM, der WSE-2 (7 nm) 40 GB, der WSE-3 (5 nm) 44 GB — ein Plus von 10 % über einen kompletten Knotenwechsel hinweg. Die Dichte der Compute-Transistoren stieg von Generation zu Generation deutlich, doch die SRAM-Kapazität bewegte sich kaum. SRAM ist zugleich Cerebras' wichtigster Wettbewerbsvorteil und die Komponente, die am meisten Fläche und Kosten verschlingt und sich am hartnäckigsten der Skalierung widersetzt. Pro Watt und pro Dollar bietet HBM weit mehr Speicherkapazität.
On-Chip-SRAM auf einem WSE-großen Wafer, nach Node
| Fertigungsknoten | On-Chip-SRAM | Logikdichte (vs. 7 nm) |
|---|---|---|
| 7 nm — WSE-2 | 40 GB | 1,0× |
| 5 nm — WSE-3 | 44 GB | 1,8× |
| 3 nm — projiziert | 44 GB | 2,9× |
| 2 nm — projiziert | ~53 GB | 3,4× |
Für die heutigen Workloads genügen 44 GB, um kleine und mittlere Modelle schnell zu bedienen, und sie können den aktiven Footprint mancher quantisierter MoE-Modelle abdecken. Viele aktuelle MoEs halten die aktiven Parameter pro Token im Bereich von 30–40 Mrd. und erhöhen zugleich Gesamtparameter und Expertenzahl. GLM-4.5 hat 355 Mrd. gesamt bei 32 Mrd. aktiv, DeepSeek-V3 671 Mrd. gesamt bei 37 Mrd. aktiv, und Kimi K2.6 1 Bio. gesamt bei 32 Mrd. aktiv über 384 Experten.
Für Cerebras bleibt das dennoch ein Skalierungsproblem. Mehr Experten und längere Kontexte erschweren Placement, Caching, Routing und KV-Cache, selbst wenn die aktiven FLOPs kontrolliert bleiben.
Off-Wafer-Input/Output
Weil die WSE im Verhältnis zu ihrem Umfang physisch groß ist, ist die Zahl der I/O-Signale, die den Chip verlassen können, strukturell durch den Chiprand begrenzt. Die externen Verbindungen müssen nahe am Waferrand sitzen, denn nur dort können die Signale den Chip verlassen. Retikel in der Wafermitte lassen sich kaum mit der Außenwelt verbinden; würde man das Innere mit SerDes-Blöcken füllen, verschwendete man Silizium an I/O, das keinen praktikablen Weg vom Wafer weg hat.
Das Ergebnis ist eine aktuelle Obergrenze der Off-Wafer-Bandbreite von rund 1,2 Tb/s (~150 GB/s) pro CS-3-System. Zum Vergleich: In einem GPU-Rack mit NVLink und NVSwitch bemisst sich die Cross-Chip-Bandbreite in zweistelligen Terabyte pro Sekunde — oder man denke an Groqs LP30 mit 9,6 Tb/s.
Die Bandbreiten-Klippe am Waferrand
| Pfad | Bandbreite (Bytes/s) | Reichweite |
|---|---|---|
| WSE-3 On-Wafer-Mesh | 21 PB/s | On-Chip, Kern zu Kern |
| GB200 NVL72 (NVLink) | 130 TB/s | Rack mit 72 GPUs |
| Groq LP30 | 1,2 TB/s | Off-Chip |
| Cerebras CS-3 | 150 GB/s | Off-Wafer-I/O |
Die Rechenleistung auf dem Wafer ist schnell und intern gut vernetzt, doch die Brücke nach außen ist schmal. Solange Workloads ihren kritischen Zustand auf dem Wafer halten, ist das beherrschbar. In dem Moment, in dem das Working Set On-Chip überläuft und der kritische Hot Path durchs I/O führt, entstehen Probleme.
Pipeline-Parallelismus und architekturspezifische Modellgrenzen
Cerebras' schnellstes Inferenz-Regime hängt davon ab, das Modell als räumliche Pipeline über den Wafer abzubilden. Jede Transformer-Schicht wird einer Region der WSE zugewiesen, und die Token-Aktivierungen fließen der Reihe nach durch diese Regionen — Schicht für Schicht, wie Daten, die einen Fluss hinunterfließen.
Deshalb glänzt Cerebras beim Durchsatz pro Nutzer bei kleinen Batches: Der Forward-Pass jedes Tokens fließt kontinuierlich mit wafer-lokaler Bandbreite durch die Pipeline, statt auf ein Multi-GPU-All-Reduce zu warten. Es gibt keinen Synchronisations-Overhead zwischen GPUs; das Mesh leitet alles intern weiter.
Der Haken ist, dass diese Pipeline-first-Architektur einschränkt, welche Modelltopologien sie effizient bedienen kann. Neuere Architekturen wie Moonshot/Kimi K2 — mit einem nicht standardmäßigen, verschränkten Design aus MoE und dichter Attention — sowie aufkommende „Mixture-of-Depths"- oder Cross-Layer-Attention-Modelle erzeugen unregelmäßige Aktivierungsgraphen, die sich schwerer effizient auf ein festes räumliches Layout abbilden lassen. Solche Architekturen verbreiten sich an der Frontier zunehmend und werden für einen Compiler, der Token-Aktivierungen statisch über ein festes 2D-Mesh routet, zu einer wachsenden Herausforderung.
CUDA gibt Entwicklern direktere Kontrolle über Kernels, Speicherbewegung und Synchronisation. Cerebras verlagert mehr des Performance-Problems in den Compiler: Kernels oder Schichten müssen auf WSE-Regionen platziert, mit Datenpfaden verbunden und über den Wafer hinweg eingeplant werden. Das gelingt am besten bei regelmäßigen, schichtweisen Graphen. Architekturen mit unregelmäßigem Routing, Cross-Layer-Abhängigkeiten, Mixture-of-Depths oder nicht standardmäßigen MoE-/Attention-Layouts lassen sich schwerer sauber abbilden und erfordern womöglich tiefergehende Compiler-Arbeit oder Modelländerungen, um eine gute Auslastung zu erreichen.
Mögliche Abhilfen: Packaging, Bonding und Optik
Cerebras' Führungsspitze kennt die Engpässe bei I/O und SRAM-Skalierung durchaus und hat öffentlich eine Roadmap skizziert, um sie anzugehen.
Hybrid-Bonding ist der technisch glaubwürdigste kurzfristige Weg, die effektive Bandbreite zwischen der WSE und benachbarten Speicher- oder Rechenschichten zu erhöhen. Bondet man einen Speicher-Wafer bei einem Pitch unter 12 µm direkt über oder unter den Compute-Wafer, lässt sich im Prinzip DRAM oder neuartiger Speicher näher an die Kerne bringen, als es heutiges Packaging erlaubt — und zwar über die gesamte Waferfläche statt nur am Rand. Jüngste Arbeiten zum Wafer-to-Wafer-Hybrid-Bonding haben Interconnect-Pitches von bis zu 200 nm gezeigt, auch wenn die Ausbeute bei diesem Pitch schwierig bleibt. Ein DRAM-Wafer, per Hybrid-Bonding auf die WSE gesetzt, könnte Cerebras' effektive On-Device-Speicherkapazität drastisch erhöhen — das würde zugleich die SRAM-Kapazitätsgrenze angehen und das KV-Cache-Problem teilweise entschärfen, ohne über die 150-GB/s-Off-Wafer-Verbindung zu laufen.
Optische Interconnects würden die I/O-Grenze am Perimeter unmittelbarer angehen. Cerebras hat die Vision eines programmierbaren optischen Interconnects im Wafer-Maßstab skizziert, der an die WSE gebondet ist und die gesamte Waferoberfläche statt nur den Rand nutzt, um I/O zu verteilen — mit potenziell 4.000× mehr Bandbreite als heutige kupferbasierte Off-Wafer-Verbindungen. Das ist wahrhaft heroische Ingenieurskunst: Sie verlangt eine standardisierte Bonding-Schnittstelle über verschiedene Foundry-Prozesse hinweg, neue Hybrid-Bonding-Verfahren auf Wafer-to-Wafer-Ebene und photonische Integration mit eingebetteten Lasern — jedes für sich ein mehrjähriges F&E-Vorhaben. Cerebras verfolgt genau das über eine DARPA-geförderte Co-Packaged-Optics-Partnerschaft mit Ranovus, doch es bleibt eher eine langfristige Vision als eine kurzfristige Abhilfe.
Mit Blick nach vorn wird Cerebras zudem Low-Precision-Formate wie FP8 und FP4 annehmen müssen, wenn Inferenz im Wafer-Maßstab ökonomisch attraktiv bleiben soll. Zwar hat das Unternehmen FP8-REAP-Checkpoints für Modelle wie GLM-4.7 veröffentlicht, doch Quantisierung auf Checkpoint-Ebene ist nicht dasselbe wie native FP8- oder FP4-Ausführung im Datenpfad der WSE. Nvidia behandelt geringere Präzision inzwischen als erstklassiges Hardware-Feature: Blackwell unterstützt FP8- und FP4-Formate, und die Software wird zunehmend um diese Modi herum gebaut. Ohne vergleichbare native Unterstützung verbraucht Cerebras pro effektivem Token mehr SRAM und Bandbreite als nötig. FP8 und schließlich FP4 würden Cerebras erlauben, mehr aktive Parameter in denselben Wafer-Footprint zu packen und die Ökonomie seiner Fast-Token-These zu verbessern.
Kurzfristig folgt Cerebras' praktische Antwort auf diese Beschränkungen dem Weg des Co-Designs: Modelle mit REAP prunen, Routing-Strategien mit BTA anpassen, wo möglich Low-Precision-Checkpoints nutzen und gemeinsam mit Partnern Workloads gestalten, die in jenem Regime bleiben, in dem das aktuelle I/O-Budget nicht der Engpass ist. Die Hardware-Roadmap ist vielversprechend, aber spekulativ. Die Co-Design-Roadmap ist bereits in Produktion und lässt sich weiter skalieren.
Neue Möglichkeiten
Die Frage für Cerebras lautet, wo Geschwindigkeit das Produkt so verändert, dass sich die Kosten rechtfertigen. Die stärksten Domänen teilen drei Merkmale: Latenz beeinflusst Nutzererlebnis oder Aufgabenerfolg; zusätzliche Rechenzeit zur Inferenz (Test-Time-Compute) verbessert die Qualität; und die Nutzer sind bereit, für flüssigere Interaktion zu zahlen.
Cerebras hat begonnen, dies als „Scaling Law" für Inferenz zu fassen: Schnellere Tokens erlauben es Modellen, innerhalb desselben Latenzbudgets mehr Tokens zur Inferenzzeit einzusetzen, was wiederum bessere Ergebnisse für ein fest vortrainiertes Modell bringt. OpenAIs Scaling Law zum Test-Time-Compute zeigt Ähnliches: Viele Benchmarks verbessern sich monoton mit der Zahl der bei der Inferenz genutzten Tokens. Doch Geschwindigkeit könnte auch ganz neue Verhaltensweisen ermöglichen — Modelle für kontinuierliche Interaktion etwa oder verkörperte Systeme, die übergeordnetes Reasoning mit schnellem Handeln verbinden.
Coding-Agenten und Harnesses
Coding ist bislang der klarste Anwendungsfall. OpenAI und Cognition setzen bereits schnelle Cerebras-gestützte Modelle als Premium-Coding-Modelle ein — Codex-Spark und SWE-1.6 laufen beide um die 1.000 Tokens pro Sekunde. Unabhängige Berichte heben durchweg den qualitativen Unterschied hervor: Treffen Antworten in unter einer Sekunde ein, bleiben Entwickler im Flow und behandeln das Modell als kontinuierlichen Mitarbeiter statt als Batch-Werkzeug, das man abfragt und dann ignoriert, während man an etwas anderem arbeitet.
Eine der größten Herausforderungen im agentischen Coding ist heute der Kontextwechsel. Ein typischer Ablauf: Man gibt dem Agenten eine nicht-triviale Aufgabe — ein Subsystem refaktorieren, eine Deployment-Pipeline aktualisieren, ein übergreifendes Feature einbauen — und sieht ihm dann über Dutzende Sekunden oder ganze Minuten beim Planen, Editieren, Testen und Zusammenfassen zu. Weil das Anstarren einer Ladeanzeige unerträglich ist, wechselt man zu einer anderen Aufgabe: E-Mail, Slack, ein anderes Ticket. Ist der Agent fertig, muss man das ursprüngliche Problem erst wieder laden, abgleichen, was er getan hat, und über die nächsten Schritte entscheiden. Spark ist so ausgelegt, dass „schnelle Antworten ebenso entscheidend sind wie Intelligenz", und ermöglicht „echtzeitfähiges, kontinuierliches Coding".
Schnellere Inferenz verändert auch das Verhältnis von Code und Harness. Heute laufen die meisten Coding-Agenten in einem weitgehend festen Harness: ein statischer Satz an Werkzeugen (Dateiänderungen, Shell, Tests), starre Prompt-Vorlagen und eine einzige Evaluations-Pipeline, die für sehr unterschiedliche Aufgaben taugen muss.
Blickt man nach vorn, sind mitwachsende Harnesses ein plausibler nächster Schritt — Harnesses, die sich an die jeweilige Aufgabe anpassen. Der Agent schriebe dann nicht nur Code in einer festen Umgebung; er gestaltete und verfeinerte laufend sein eigenes Harness, generierte projektspezifische Test-Runner, fügte Werkzeuge hinzu oder entfernte sie, während die Aufgabe fortschreitet, und strukturierte Evaluations-Pipelines auf Basis dessen um, was er über die Codebasis lernt. Tragfähig ist das nur, wenn die Harness-Operationen selbst schnell sind: Tests und Werkzeuge zu generieren, auszuführen und zu überarbeiten muss in ein Budget von wenigen Sekunden passen.
Interaktionsmodelle und neue Mensch–Maschine-Schnittstellen
Die zweite Anwendungsklasse ist Echtzeit-Interaktion. Chat-Modelle vertragen Pausen, weil die Schnittstelle rundenbasiert ist: Der Nutzer schickt eine Nachricht, wartet und bekommt eine Antwort. Live-Audio, -Video und kollaborative Oberflächen sind weniger nachsichtig. Das Modell muss entscheiden, wann es spricht, wann es schweigt, wann es unterbricht und wie es seine Antwort anpasst, sobald neues Audio, neues Video oder eine neue Nutzerabsicht eintrifft.
OpenAI hat gerade GPT Live vorgestellt. Es verarbeitet eingehendes Audio, während es selbst noch spricht, und trifft viele Male pro Sekunde Interaktionsentscheidungen: ob es spricht, weiter zuhört, pausiert, unterbricht oder ein Tool aufruft. Die native Audio-Verarbeitung erspart den Umweg über Text, und Antworten kommen in deutlich unter einer Sekunde — schnell genug, dass das Modell im Gespräch bleibt. Neben schnellen Coding-Modellen zeigt GPT Live, warum OpenAI mehr latenzarme Inferenzkapazität will: Das Modell muss in Echtzeit mit dem Nutzer Schritt halten. Thinking Machines lieferte als Erstes ein interaktions-orientiertes Modell dieser Art aus, doch das Paradigma erreicht nun Massenmarktprodukte.
Das gut zu bedienen verlangt anhaltend niedrige Latenz bei relativ großen aktiven Parameterzahlen und ein kontinuierliches Prefill/Decode-Regime mit Mikro-Batches. Offen bleibt das Kontextmanagement über lange Sitzungen: Der KV-Cache wächst mit Sitzungsdauer und Nebenläufigkeit und macht schließlich Speicherkapazität und Bandbreite zum Engpass.
Kompression, Eviction, Retrieval, Zusammenfassung und KV-Cache-Quantisierung sind allesamt aktive Forschungsfelder. Systeme wie RocketKV und KVzip weisen in dieselbe Richtung: weniger Zustand aktiv halten, das Verbleibende komprimieren und den Kontext bewahren, der für die nächste Runde zählt.
Kommerziell trägt das, wenn schnellere Interaktion die Dynamik der Interaktion verändert. Generische Sprachassistenten rechtfertigen nicht bei jeder Anfrage Premium-Inferenz. Ein Sales-Copilot, ein Echtzeit-Übersetzer, ein kollaboratives Design-Tool oder ein Support-Agent haben da die besseren Argumente, weil Verzögerungen die Qualität der Interaktion verändern. Ein Modell, das in rund 400 ms antwortet, kann im Gespräch bleiben.
Ambient State Interpretation
Die meisten KI-Anwendungen sind heute reaktiv: Sie warten, bis ein Nutzer um Hilfe bittet. Der Nutzer muss das Problem bemerken, den Kontext zusammentragen und ihn in einen Prompt gießen. Ambient State Interpretation verlagert diese Arbeit ins System. Das Modell liest den Arbeitsbereich fortlaufend, erschließt, was der Nutzer vorhat, und wird nützlich, bevor er überhaupt fragen muss.
Erste Vorläufer davon sind bereits zu sehen. Googles Gemini Intelligent Screen Context lässt das Modell erkennen, wann sich eine Anfrage auf das bezieht, was auf dem Bildschirm des Nutzers sichtbar ist — ohne dass er eigens auf „Ask about screen" tippen muss. Apple verfolgt mit On-Device-Foundation-Models in iOS 27 dieselbe Richtung und zielt über Siri-Extensions auf kontinuierliches Bewusstsein für den Bildschirminhalt.
Die architektonische Herausforderung ist die fortlaufende Verarbeitung eines Stroms aus Bildschirmzuständen, Ereignissen oder Sensoreingaben, um jederzeit ein aktuelles Modell dessen zu halten, was der Nutzer gerade tut. Effektive Ambient-Agenten müssen weit mehr Signal aufnehmen, als sie zeigen, und nach Beobachtungen handeln, die aktuell sind. Forschung zu proaktiven KI-Systemen benennt Latenz als den wichtigsten Faktor, der Vertrauen zerstört: Ein Agent, der mit einem Vorschlag auf Basis eines drei Sekunden alten Bildschirmzustands dazwischenfunkt, stört mehr, als gar kein Vorschlag es täte. Das experimentelle System ProAgent auf Jetson-Orin-Hardware meldet im Schnitt 4,5 Sekunden Latenz — ausdrücklich als Grenze des praktischen Nutzens genannt.
Aktuelle Systeme lösen das meist mit kleinen On-Device-Modellen, um die Latenz im Griff zu behalten — allerdings auf Kosten der Reasoning-Qualität: Kleine Modelle tun sich schwer, dichte Inhalte präzise zu deuten, und können nicht verlässlich abschätzen, was der Nutzer als Nächstes braucht. Schnelle Cloud-Inferenz könnte diese Lücke schließen: Ein Reasoning-Modell mit 70–120 Mrd. Parametern bei Cerebras-Geschwindigkeit könnte eine vollständige Interpretation des Bildschirms samt Vorhersage der nächsten Aktion in deutlich unter 200 ms erledigen — es erreichte die Latenz eines kleinen On-Device-Modells und brächte zugleich das Reasoning-Niveau eines Frontier-Modells auf komplexe Zustände zur Geltung.
Abschließende Gedanken
Cerebras ist eine Wette darauf, dass Inferenz spezialisierter und allgegenwärtiger wird. Die WSE ist gebaut für Low-Batch-Decode, schnelle Coding-Schleifen, Echtzeit-Interaktion und Agenten, die beobachten, schließen und handeln müssen, ohne den Flow des Nutzers zu brechen.
Die Architektur ist mächtig, weil sie Speicher und Rechenleistung auf einem Wafer eng zusammenführt. Die Grenzen stammen aus demselben Design: SRAM-Kapazität ist schwer zu skalieren, das Off-Wafer-I/O ist schmal, der KV-Cache wird bei langem Kontext schmerzhaft, und unregelmäßige Modellarchitekturen können den Compiler belasten. Cerebras funktioniert am besten, wenn Modelle und Serving-Stacks um den Wafer herum geformt werden.
Die bestehenden Partnerschaften mit OpenAI und AWS prüfen, ob schnelles Decode zu einer echten Schicht der Hyperscale-Inferenz werden kann: OpenAI über latenzsensitive Coding- und Interaktionsmodelle, AWS über disaggregiertes Prefill auf Trainium und Decode auf dem CS-3.
Cerebras rahmt dies als Scaling Law der Inferenz: Schnellere Tokens lassen ein Modell mehr Rechenaufwand zur Inferenzzeit betreiben, ohne den Nutzer warten zu lassen. Dasselbe Modell kann mehr Kandidaten erzeugen, über mehr Schritte hinweg schließen, die eigene Arbeit prüfen oder mehr Tool-Calls im selben Latenzbudget ausführen. Geschwindigkeit kann sich so — bei fest vortrainiertem Modell — in bessere Ausgabequalität übersetzen.
Über die Beschleunigung bestehender Anwendungsfälle hinaus legt schnellere Inferenz auch Anwendungskategorien frei, in denen Echtzeit-Modellarbeit bislang zu langsam, zu teuer oder zu umständlich war, um darauf zu bauen.
Wir glauben, dass sich KI-Produkte stärker in Richtung Live-Interaktion, Computer Use und kontinuierliche Agenten bewegen — Aufgaben, bei denen Token-Geschwindigkeit zählt und für die Nutzer zu zahlen bereit sind. Cerebras gibt diesen Produkten mehr Raum, im Latenzbudget des Nutzers zu denken, zu prüfen, zu handeln und sich zu korrigieren.