Cerebras rapporterer 5X økning i inferensgjennomstrømning fra desaggregasjon

Cerebras Systems sa 1. oktober 2026 at de økte inferensgjennomstrømningen med 5‑ganger i tidlige resultater ved hjelp av en teknikk kalt desaggregasjon, med samme antall Cerebras‑systemer og uten tap i token‑genereringshastigheter. Avsløringen kom i Desaggregert inferens fra grunnen av, et bedriftsblogginnlegg av Isaac Tai og Zhenwei Gao som starter en planlagt serie om emnet.

Innlegget rammer inn serien for lesere som har hørt begrepet desaggregasjon, eller påstanden om at prefill er beregningsavhengig og decode er minneavhengig, og som har lurt på hva hver av dem faktisk betyr. Det bygger forklaringen fra grunnen av, og starter med hvordan akseleratorer balanserer aritmetikk mot databevegelse.

Prefill og Decode stiller forskjellige krav på maskinvaren

Innlegget definerer aritmetisk intensitet som antall flyttallsoperasjoner delt på antall byte som overføres mellom minne og en akselerators beregningselementer. I ett av eksemplene deres gir addisjon av to matriser 1 FLOP for hver 6 byte som flyttes, en aritmetisk intensitet på 0,167 FLOP per byte, og dette forholdet forblir konstant etter hvert som matrisene vokser. Matrismultiplikasjon oppfører seg annerledes: hver utgangsverdi bygges fra en hel rad i én input og en hel kolonne i den andre, slik at lastede verdier bidrar til flere utganger og den aritmetiske intensiteten øker med input‑størrelsen.

Innferens, forklarer innlegget, er en kjede av slike matrismultiplikasjoner mellom en modells faste vekter og dens input‑token, og den kjører i to faser med ulike intensitetsprofiler. Under prefill behandles hele prompten parallelt som en stor matriseoperasjon, og reelle prompt kan inneholde tusenvis eller til og med hundretusener av token. Under decode genereres token én om gangen, og modellen benytter KV‑cachen, som lagrer nøkler og verdier beregnet for tidligere token slik at de kan gjenbrukes i stedet for å beregnes på nytt.

Begge fasene må fortsatt flytte alle modellens vekter, potensielt hundrevis av gigabyte eller terabyte, til beregningselementene for hver token som genereres. Innlegget viser at minnebevegelsen forblir nesten konstant mens den aritmetiske intensiteten faller etter prefill, og peker på dette gapet som grunnen til at økt rå beregningskapasitet ikke nødvendigvis gjør at token ankommer raskere under decode.

Desaggregasjon deler inferens inn i separate puljer

I produksjon håndterer en inferensserver vanligvis mange forespørsler samtidig, og når prefill og decode kjører på samme maskinvare, kan den beregningsintensive prefill forsinke aktive decode‑forespørsler. Planleggere må da velge mellom å få nye forespørsler til deres første token raskt, holde aktive svar strømmende jevnt, og maksimere total gjennomstrømning. Batch‑behandling gjør at samtidige forespørsler kan dele arbeidet med å lese modellvekter, men større batcher kan gjøre hvert decode‑steg lengre, slik at total gjennomstrømning kan øke mens hver bruker får token saktere.

Innlegget beskriver desaggregasjon som et systemdesignmønster som kjører de to fasene i separate maskinvare‑puljer. Når fasene er adskilt, kan operatører tildele maskinvare, sette batch‑politikker, og prioritere latens eller gjennomstrømning for hver fase uavhengig: et system med strenge mål for tid‑til‑første‑token kan reservere mer kapasitet til prefill, mens et system bygget for jevn strømming kan gi decode en større eller tettere planlagt pulje. Puljene kan også skaleres individuelt.

Separasjon introduserer et nytt krav. Etter at prefill bygger KV‑cachen, må denne forespørsels‑spesifikke tilstanden overføres til decode‑puljen, hvor den lastes inn i minnet før genereringen kan fortsette, mens modellvektene allerede er lastet i begge puljene. Innlegget påpeker at overleveringen legger til nettverks‑ og koordineringskostnader, at en av puljene kan stå tom dersom kapasitetene ikke matcher etterspørselen, og at den ekstra latensen avhenger av om cachen flyttes mellom same‑lokaliserte maskiner eller mellom regioner. Det argumenteres for at desaggregasjon er mest overbevisende i stor skala, hvor gevinster fra uavhengig dimensjonering og planlegging av puljene kan oppveie overførings‑ og driftskostnadene, og at det endrer kontroll‑grensesnittet til tjenestesystemet i stedet for kun å jevne ut strømmingen.

Heterogen maskinvare, tidlige resultater og partnerskap

Cerebras sa at de leder utviklingen av heterogen desaggregasjon, ved å kombinere flere typer brikker i ett inferenssystem og tildele forskjellig maskinvare til segmentene som er minneavhengige eller beregningsavhengige. Innlegget sammenligner selskapets wafer‑scale‑design, som distribuerer SRAM sammen med beregning over hele waferen, med GPU‑er, som mellomlagrer modelldata fra høy‑båndbredde‑minne gjennom mindre on‑chip‑minner og cacher.

Et publisert diagram for topp‑minnebåndbredde i innlegget, datert 10. september 2026, viser Cerebras WSE‑3 on‑chip SRAM på 21 000 TB/s per wafer, sammen med en unavngitt on‑chip SRAM‑akselerator på 150 TB/s og HBM4‑GPU‑er på 23,3 og 22 TB/s. Diagrammet advarer om at SRAM‑tallene summerer lokal minnebåndbredde på tvers av en prosessor, mens HBM‑tallene måler trafikk fra minne utenfor chippen, så tallene beskriver ulike minnetiers i stedet for målte token‑hastigheter.

Innlegget gjengir også Artificial Analysis-data fra 10. september 2026 for GPT-oss-120B som kjører høy resonnering med 10 000 inntokener. Det viser Cerebras med 1 669 utgående token per sekund, SambaNova med 708, Groq med 475, Microsoft Azure med 319, Nebius med 294 og Baseten med 293.

Cerebras sa at i et tradisjonelt aggregert system betydde økt kapasitet å sette inn mer maskinvare, og at ved å utnytte partnerakseleratorer til å håndtere promptbehandling økte kapasiteten femfold i tidlige tester med samme WSE-fotavtrykk. Selskapet opplyste at det har kunngjort partnerskap med flere maskinvarepartnere for å bringe flere ultrarask token til markedet, og et diagram i innlegget viser AWS Trainium og AMD Helios Instinct GPU-systemer blant pre‑fill maskinvarealternativene som forsyner en Cerebras‑dekodingspool.

Innlegget identifiserer agentbaserte applikasjoner som en overbevisende match for heterogen disaggregasjon, siden de ofte involverer lange, flertrinns arbeidsflyter hvor konteksten vokser over modellkall og forsinkelser på hvert trinn forsterkes. Cerebras sa at de neste delene vil dekke maskinvare‑ og programvarestablene som er involvert, samt de økonomiske avveiningene ved å implementere disaggregert inferens i stor skala.