713 Tokens i Sekundet: Arkitekturen bag Ultraspeed

Infercom leverer 713 tokens i sekundet på gpt-oss-120b og 428 tok/s på MiniMax M2.7 Ultraspeed fra vores EU-infrastruktur. Du kan genskabe disse tal med vores open source benchmark-værktøj.

Men hastighedspåstande er meningsløse uden at forstå hvorfor.

Vi er hardware-agnostiske. Vores opgave er at evaluere inferens-arkitekturer og implementere den bedste mulighed for hver workload. For hukommelsesbundet decode på store modeller kører vi i øjeblikket SambaNovas dataflow-arkitektur, fordi den adresserer hukommelsesflaskehalsen, der begrænser GPU-inferens. Denne artikel forklarer de tekniske årsager bag dette valg - se vores teknologioversigt for implementeringsdetaljer.

Decode-flaskehalsen

For at forstå hvorfor noget inferens er hurtigere end andet, skal du forstå hvad der sker, når du sender en prompt til en LLM. To forskellige faser opstår, og de belaster hardwaren på helt forskellige måder.

Prefill behandler hele din input-prompt. Modellen læser alle dine tokens på én gang og finder ud af, hvordan hvert ord relaterer til hvert andet ord - det der kaldes "attention". Alle input-tokens behandles parallelt, hvilket er præcis det GPU'er er designet til. Tusindvis af kerner holdes beskæftiget, udnyttelsen er høj, alt fungerer som tilsigtet. Prefill bygger også KV-cachen - en hukommelsesstruktur der gemmer mellemliggende attention-beregninger, så modellen ikke behøver at genberegne dem for hver ny token.

Decode genererer output-tokens én ad gangen. Hver ny token afhænger af alle tidligere tokens, så arbejdet er i sagens natur sekventielt. For hver token skal modellen læse de aktive vægte fra hukommelsen, læse hele KV-cachen, beregne forudsigelsen og derefter tilføje den nye tokens data til cachen. Beregningen er hurtig i forhold til hukommelsesadgangen - tiden går mest til at vente på at data ankommer.

KV-cachen er større end de fleste tror. For en tæt 70B-model som Llama ved BF16-præcision vokser den med cirka 0,3 MB pr. token. En 8K-kontekst samtale kræver 2,5 GB bare til cachen. Ved 32K kontekst er det 10 GB. Ved 128K rammer cachen alene 40 GB. Hver token du genererer kræver læsning af hele denne cache fra hukommelsen.

Under prefill kører GPU-udnyttelsen ved 80% eller højere. Under decode falder den til 20-40%. Beregningsenhederne sidder passive og venter på hukommelse. Dette er decode-flaskehalsen - ikke et softwareproblem du kan optimere væk, men et fundamentalt mismatch mellem GPU-arkitektur og workloaden. GPU'er blev designet til grafikrendering - massivt parallel matrixmatematik der tilfældigvis fungerer godt til træning af neurale netværk. Men inferens, især sekventiel token-generering, er et helt andet problem.

Hvorfor hukommelsesbåndbredde begrænser GPU-inferens

For hver output-token skal modellen læse de aktive vægte fra hukommelsen, læse hele KV-cachen, beregne forudsigelsen og opdatere cachen. For tætte modeller betyder dette at læse alle parametre. For Mixture of Experts (MoE) modeller - nu den dominerende arkitektur - aktiveres kun en brøkdel pr. token: DeepSeek V4-Pro har 1,6T samlede parametre men aktiverer kun 49B pr. token, hvilket reducerer vægtlæsninger dramatisk. Men KV-cachen vokser stadig med kontekstlængde uanset arkitektur.

Lad os lave matematikken på en tæt 70B-model for at se flaskehalsen tydeligt. Den faktiske beregning er triviel - 70B parametre betyder cirka 140 milliarder floating point-operationer pr. token, og en H100 GPU leverer 2.000 TFLOPS. Matematikken tager cirka 0,07 millisekunder.

Men at læse disse 70B parametre fra hukommelsen tager meget længere. H100 HBM3 båndbredde er 3,35 TB/s. Ved FP16 svarer 70B parametre til 140GB. At læse dem tager cirka 42 millisekunder.

Derfor forudsiger rå TFLOPS ikke inferenshastighed. Når udbydere viser dig GPU-specifikationer, viser de dig beregningskraft. Men for decode er hukommelsesbåndbredde flaskehalsen. Virkelige tal bekræfter dette: produktions-GPU-inferens på 70B-modeller opnår typisk 50-150 tok/s. Teoretisk beregning ville tillade 14.000+ tok/s. Gabet er ventetid på hukommelsesbåndbredde.

Hvordan dataflow-arkitektur ændrer ligningen

Løsningen er ikke hurtigere GPU'er - det er en anden arkitektur. Flere leverandører har bygget chips specifikt til inferens: SambaNovas RDU (Reconfigurable Dataflow Unit), Groqs LPU (Language Processing Unit) og Cerebras WSE (Wafer-Scale Engine). Hver tager en forskellig tilgang til at løse hukommelsesflaskehalsen.

Vi valgte SambaNovas dataflow-arkitektur til vores EU-infrastruktur (8 racks, 128 chips i München) fordi den håndterer store modeller effektivt uden at kræve hundredvis eller tusindvis af chips. Det følgende forklarer specifikt hvordan dataflow fungerer og hvorfor det betyder noget for inferens.

Tre arkitektoniske forskelle forklarer hvorfor dataflow slår GPU'er til inferens:

1. Samlebånd vs. værkstedsfabrik

Forestil dig en GPU som en værkstedsfabrik. Hver arbejder (beregningskerne) tager en opgave, går til lageret (hukommelse) for at hente materialer, udfører arbejdet, går tilbage for at gemme resultatet og tager derefter den næste opgave. Tusindvis af arbejdere, men de bruger det meste af deres tid på at gå til og fra lageret.

Dataflow-arkitektur fungerer som et samlebånd. I stedet for at arbejdere bevæger sig til materialer, flyder materialer gennem stationære arbejdsstationer. Hver operation er fysisk lagt ud på chippen, og data strømmer fra én til den næste uden omveje til hukommelse. Chippen er designet så når én operation slutter, ankommer dens output allerede til den næste operation.

SambaNova kalder dette "rumlig eksekvering" - beregningen mappes til det fysiske chip-layout snarere end planlagt som en sekvens af instruktioner. Resultatet: data bliver ved med at bevæge sig i stedet for at vente.

2. Tre niveauer af lagring, strategisk placeret

Hukommelseshastighed varierer med afstand fra processoren. Den nærmeste hukommelse (SRAM, på selve chippen) er 100x hurtigere end det næste niveau (HBM), som stadig er meget hurtigere end systemhukommelse (DDR). Tricket er at holde de rigtige data det rigtige sted.

SambaNovas RDU bruger alle tre niveauer bevidst. SRAM på chippen håndterer de hotteste data - mellemberegninger der ellers ville hoppe til hukommelse og tilbage. HBM (1 terabyte pr. rack) gemmer modelvægte og samtalecachen. DDR (12 terabytes pr. rack) holder flere modeller og cachede prompts til øjeblikkelig skift.

Nøgleforskellen fra GPU'er: RDU'ens hukommelseshierarki er softwarestyret, ikke hardwareadministreret. Compileren beslutter hvad der går hvor, i stedet for at stole på cache-forudsigelse. For forudsigelige workloads som inferens - hvor du ved præcis hvilke vægte du skal bruge i hvilken rækkefølge - eliminerer dette cache-misses.

Dette betyder også intet behov for kvantisering. GPU-udbydere komprimerer ofte modeller til INT8 eller INT4 for at reducere hukommelsesbåndbreddekrav - bytter nøjagtighed for hastighed. Dataflow-hukommelseshierarkiet løser båndbreddeproblemet direkte, så modeller kører ved deres native præcision uden kompromis.

Dette design lader også et enkelt rack køre massive modeller. At køre en 671B-parameter model på GPU'er kræver 40 racks (320 GPU'er). SambaNova kører den på ét rack med 16 RDU'er fordi hukommelseshierarkiet skalerer effektivt.

DDR-niveauet muliggør en anden fordel: hurtig modelskift. Fordi DDR er direkte forbundet til chipsene (ikke tilgået gennem systemhukommelse som på GPU'er), tager indlæsning af en anden model millisekunder snarere end de sekunder eller minutter GPU-infrastruktur kræver. Et enkelt rack kan hoste flere modeller og skifte mellem dem efter behov.

3. Planlagt rute vs. GPS-genberegning

GPU'er træffer planlægningsbeslutninger ved runtime. Hardwaren jonglerer konstant med hvilke tråde der kører hvor, håndterer konflikter når flere kerner har brug for de samme data og koordinerer synkroniseringspunkter. Denne fleksibilitet er værdifuld for uforudsigelige workloads - men inferens er ikke uforudsigelig. Du kender modelarkitekturen. Du kender sekvensen af operationer. Den eneste variabel er inputdataene.

RDU-compileren udnytter denne forudsigelighed. Den forplanlægger hele eksekveringen - hvilken chip håndterer hvilket lag, hvornår data bevæger sig mellem chips, selv den præcise clock-cyklus hver operation starter. Ingen runtime-beslutninger, ingen koordineringsoverhead, ingen ventetid på efternølere. Tænk på det som forskellen mellem en leveringschauffør der følger turn-by-turn GPS (genberegner konstant) versus en Amazon-lagerrobot der følger en foroptimeret rute gennem faciliteten. Når du ved layoutet ikke ændrer sig, slår planlægning improvisation.

4. Kontinuerlig pipeline vs. stop-and-go

Traditionel GPU-inferens kører som en serie af diskrete operationer. Start attention-beregningen. Vent på den bliver færdig. Skriv resultater til hukommelse. Start den næste operation. Læs resultater fra hukommelse. Gentag. Hver overdragelse mellem operationer koster tid - ikke for beregning, men for hukommelsesskrivninger, kernel-lanceringer og synkronisering. Ved en lang inferens der genererer hundredvis af tokens, lægger disse overdragelser sig sammen.

Dataflow-eksekvering fusionerer operationer til kontinuerlige pipelines. Data flyder fra attention til feedforward til det næste lag uden at stoppe. Mellemresultater forbliver on-chip i stedet for at lave rundture til hukommelse. Eksekveringen ligner mindre et stafetløb (aflever stafetten, vent, løb) og mere en flod (kontinuerligt flow gennem en række behandlingsstationer).

Virkelige ydeevnetal

Disse arkitektoniske forskelle oversættes til målbare hastighedsfordele. Artificial Analysis, som benchmarker udbydere uafhængigt, måler konsekvent SambaNova blandt de hurtigste inferensudbydere - med gpt-oss-120b der rammer 685 tok/s og MiniMax M2.7 ved 426 tok/s i deres live benchmarks.

Hvordan sammenligner dette? GPU-baserede udbydere opnår typisk 50-150 tok/s på store modeller. Den 3-10x hastighedsforskel afspejler den arkitektoniske fordel direkte - og gabet vokser når modeller bliver større, fordi hukommelsesbåndbredde bliver mere af en flaskehals. For mere om hvad disse metrikker betyder og hvornår hver betyder noget, se LLM Inferenshastighed forklaret.

Decode-æraen: Hvorfor dette betyder noget nu

I årevis centrerede AI-infrastruktursamtaler sig om beregningskraft. Flere TFLOPS, større clusters, hurtigere træningskørsler. Det gav mening da den dominerende udfordring var at træne større modeller. Men inferens - især agentisk inferens - ændrer problemet fuldstændigt.

Agenter svarer ikke bare på en prompt og stopper. De ræsonnerer over lange kontekster, genererer mange tokens, kalder værktøjer, itererer. Hver token-generering genindtræder i samme decode-cyklus. Ineffektiv databevægelse akkumulerer latens token for token. Hurtigere tokens oversættes til mere intelligens fordi systemet kan udforske flere ræsonneringstrin inden for samme tidsbudget. Derfor er hastighed så vigtig for agentisk kodning.

Energieffektivitet: En bieffekt af bedre arkitektur

Hurtigere inferens pr. watt er ikke bare et bæredygtighedsargument. Det påvirker driftsøkonomien direkte. Infercoms SambaNova-racks trækker cirka 10 kW hver. Tilsvarende GPU-infrastruktur kører 40-50 kW eller mere pr. rack - fire til fem gange strømmen for sammenlignelig inferenskapacitet. RDU'erne bruger også standard luftkøling, mens højdensitets GPU-implementeringer ofte kræver væskekølingsinfrastruktur der tilføjer omkostninger og kompleksitet.

Stanfords Hazy Research-lab udviklede en metode til at måle "intelligens pr. watt" - nyttigt output pr. energienhed forbrugt. Efter denne metrik leverer dataflow-arkitektur op til 5x mere intelligens pr. joule end GPU-baseret inferens.

Denne effektivitet kommer fra de samme arkitektoniske beslutninger der muliggør hastighed. At holde data on-chip reducerer hukommelsestrafik. Reduceret hukommelsestrafik betyder mindre energi brugt på at flytte data. Statisk planlægning eliminerer spildte cyklusser. Det akkumulerer alt sammen.

Hvad er det næste: Disaggregeret inferens

Branchen reagerer. Den næste evolution er allerede i gang: disaggregeret inferens, hvor prefill og decode kører på helt separat hardware.

Logikken er ligetil. Prefill er beregningsbundet - det drager fordel af rå TFLOPS og høj parallelisme. Decode er hukommelsesbundet - det har brug for båndbredde og lav-latens hukommelsesadgang. At køre begge på samme chip betyder at én fase altid er suboptimal. Hvorfor gå på kompromis når du kan specialisere?

Ved GTC 2026 annoncerede Jensen Huang at NVIDIA bevæger sig mod disaggregeret inferens. SambaNova og Intel annoncerede en lignende arkitektur: GPU'er håndterer prefill (bygger KV-cachen), RDU'er håndterer decode (hurtig token-generering), og Xeon CPU'er administrerer orkestrering og værktøjseksekvering.

Dette betyder endnu mere for agentiske workloads. Når en agent ræsonnerer igennem en kompleks opgave, itererer den måske snesevis af gange - ræsonnerer, kalder værktøjer, validerer resultater, gentager. Hver iteration rammer decode-fasen. Latens akkumulerer over iterationer. En 3x forbedring i decode-hastighed gør ikke bare individuelle svar hurtigere; det muliggør flere ræsonneringstrin inden for samme tidsbudget.

Dette er ikke teoretisk - effektivitetsgevinsterne er for betydelige til at ignorere. Forvent at disaggregeret inferens bliver standard for højtydende implementeringer over de næste år.

Bundlinjen

GPU-inferens rammer en mur på store modeller fordi decode er hukommelsesbundet, ikke beregningsbundet. Chippen sidder passivt og venter på data. Dataflow-arkitektur løser dette med rumlig eksekvering, lagdelt hukommelse, statisk planlægning og kontinuerlige pipelines. Resultatet: 3-10x hurtigere inferens på hukommelsesbundne workloads.

Decode-flaskehalsen forsvinder ikke - faktisk bliver den værre når modeller vokser og agentiske workloads kræver flere tokens pr. opgave. Branchen reagerer med specialiseret hardware og disaggregerede arkitekturer. Infercom kører SambaNova fordi det leverer den bedste kombination af hastighed, effektivitet og stormodel-support til EU-implementering i dag. Vi tilpasser os når hardwarelandskabet udvikler sig.

Du behøver ikke tage vores ord for noget af dette. benchmark.infercom.ai lader dig køre dine faktiske prompts mod vores infrastruktur. Artificial Analysis publicerer uafhængige benchmarks på tværs af udbydere. Test ved dine typiske input- og outputlængder. Test i spidsbelastningstimer. Arkitekturfordelene viser sig i tallene.

Kør tallene. Sådan ved du det.

Videre læsning

SambaNova tekniske ressourcer:

• Inference Speed or Throughput? With RDUs, You Don't Have to Choose
• The Decode Era of AI: Why Dataflow Matters More Than Ever
• Solving the Decode Bottleneck: Why Agentic Inference Needs Hybrid Hardware

Uafhængig analyse:

• SambaNova Provider Analysis - Artificial Analysis
• DeepSeek R1 671B with 95% Fewer Chips - TechRadar

Infercom ressourcer:

• Ydeevne-benchmarks - Vores faktiske tal
• Teknologioversigt - Hvordan vi implementerer dataflow-arkitektur
• LLM Inferenshastighed forklaret - Hvad metrikkerne betyder
• Agentisk kodning - Hvorfor hastighed betyder noget for AI-assisteret udvikling