Infercom liefert 713 Tokens pro Sekunde auf gpt-oss-120b und 428 tok/s auf MiniMax M2.7 Ultraspeed aus unserer EU-Infrastruktur. Sie können diese Zahlen mit unserem Open-Source-Benchmark-Tool.
Aber Geschwindigkeitsbehauptungen sind bedeutungslos, ohne zu verstehen, warum.
Wir sind Hardware-agnostisch. Unsere Aufgabe ist es, Inferenz-Architekturen zu evaluieren und die beste Option für jeden Workload bereitzustellen. Für speichergebundenes Decoding bei großen Modellen setzen wir derzeit auf SambaNovas Dataflow-Architektur, weil sie den Speicherengpass adressiert, der GPU-Inferenz limitiert. Dieser Artikel erklärt die technischen Gründe hinter dieser Wahl - siehe unsere Technologie-Übersicht für Details zur Bereitstellung.
Der Decode-Engpass
Um zu verstehen, warum manche Inferenz schneller ist als andere, müssen Sie verstehen, was passiert, wenn Sie einen Prompt an ein LLM senden. Zwei unterschiedliche Phasen treten auf, und sie belasten die Hardware auf völlig unterschiedliche Weise.
Prefill verarbeitet Ihren gesamten Eingabe-Prompt. Das Modell liest alle Ihre Tokens auf einmal und ermittelt, wie jedes Wort zu jedem anderen Wort in Beziehung steht - das nennt man "Attention". Alle Eingabe-Tokens werden parallel verarbeitet, was genau das ist, wofür GPUs entwickelt wurden. Tausende Kerne bleiben beschäftigt, die Auslastung ist hoch, alles funktioniert wie vorgesehen. Prefill baut auch den KV-Cache auf - eine Speicherstruktur, die Zwischenberechnungen der Attention speichert, damit das Modell sie nicht für jeden neuen Token neu berechnen muss.
Decode generiert Output-Tokens einzeln nacheinander. Jeder neue Token hängt von allen vorherigen Tokens ab, daher ist die Arbeit von Natur aus sequenziell. Für jeden Token muss das Modell die aktiven Gewichte aus dem Speicher lesen, den gesamten KV-Cache lesen, die Vorhersage berechnen und dann die Daten des neuen Tokens zum Cache hinzufügen. Die Berechnung ist schnell im Vergleich zum Speicherzugriff - die Zeit geht hauptsächlich für das Warten auf ankommende Daten drauf.
Der KV-Cache ist größer als die meisten Menschen denken. Für ein dichtes 70B-Modell wie Llama bei BF16-Präzision wächst er um etwa 0,3 MB pro Token. Eine 8K-Kontext-Konversation benötigt 2,5 GB allein für den Cache. Bei 32K Kontext sind das 10 GB. Bei 128K erreicht der Cache allein 40 GB. Jeder Token, den Sie generieren, erfordert das Lesen dieses gesamten Caches aus dem Speicher.
Während des Prefills läuft die GPU-Auslastung bei 80% oder höher. Während des Decodes fällt sie auf 20-40%. Die Recheneinheiten sitzen untätig da und warten auf den Speicher. Das ist der Decode-Engpass - kein Softwareproblem, das man wegoptimieren kann, sondern ein fundamentales Missverhältnis zwischen GPU-Architektur und dem Workload. GPUs wurden für Grafikrendering entwickelt - massiv parallele Matrixmathematik, die zufällig gut für das Training neuronaler Netze funktioniert. Aber Inferenz, insbesondere sequenzielle Token-Generierung, ist ein völlig anderes Problem.
Vertiefung in unserem Glossar
Warum Speicherbandbreite GPU-Inferenz limitiert
Für jeden Output-Token muss das Modell die aktiven Gewichte aus dem Speicher lesen, den gesamten KV-Cache lesen, die Vorhersage berechnen und den Cache aktualisieren. Bei dichten Modellen bedeutet das, alle Parameter zu lesen. Bei Mixture-of-Experts (MoE) Modellen - jetzt die dominante Architektur - aktiviert sich nur ein Bruchteil pro Token: DeepSeek V4-Pro hat 1,6T Gesamtparameter, aktiviert aber nur 49B pro Token, was die Gewichtslesevorgänge dramatisch reduziert. Aber der KV-Cache wächst mit der Kontextlänge unabhängig von der Architektur.
Machen wir die Rechnung für ein dichtes 70B-Modell, um den Engpass deutlich zu sehen. Die eigentliche Berechnung ist trivial - 70B Parameter bedeuten etwa 140 Milliarden Gleitkommaoperationen pro Token, und eine H100 GPU liefert 2.000 TFLOPS. Die Mathematik dauert etwa 0,07 Millisekunden.
Aber das Lesen dieser 70B Parameter aus dem Speicher dauert viel länger. H100 HBM3 Bandbreite beträgt 3,35 TB/s. Bei FP16 entsprechen 70B Parameter 140GB. Das Lesen dauert etwa 42 Millisekunden.
Die GPU ist 0,07ms rechengebunden und 42ms speichergebunden pro Token. Ein 600-facher Unterschied.
Deshalb sagen rohe TFLOPS die Inferenzgeschwindigkeit nicht voraus. Wenn Anbieter Ihnen GPU-Spezifikationen zeigen, zeigen sie Ihnen Rechenleistung. Aber für Decode ist Speicherbandbreite der Engpass. Reale Zahlen bestätigen dies: Produktions-GPU-Inferenz auf 70B-Modellen erreicht typischerweise 50-150 tok/s. Theoretische Rechenleistung würde 14.000+ tok/s erlauben. Die Lücke ist Warten auf Speicherbandbreite.
Wie Dataflow-Architektur die Gleichung verändert
Die Lösung sind nicht schnellere GPUs - es ist eine andere Architektur. Mehrere Anbieter haben Chips speziell für Inferenz gebaut: SambaNovas RDU (Reconfigurable Dataflow Unit), Groqs LPU (Language Processing Unit) und Cerebras WSE (Wafer-Scale Engine). Jeder verfolgt einen anderen Ansatz zur Lösung des Speicherengpasses.
Wir haben SambaNovas Dataflow-Architektur für unsere EU-Infrastruktur (8 Racks, 128 Chips in München) gewählt, weil sie große Modelle effizient verarbeitet, ohne Hunderte oder Tausende von Chips zu benötigen. Im Folgenden wird erklärt, wie Dataflow funktioniert und warum es für Inferenz wichtig ist.
Drei architektonische Unterschiede erklären, warum Dataflow GPUs bei der Inferenz schlägt:
1. Fließband vs. Werkstattfertigung
Stellen Sie sich eine GPU wie eine Werkstattfertigung vor. Jeder Arbeiter (Rechenkern) nimmt eine Aufgabe auf, geht zum Lager (Speicher), um Materialien zu holen, erledigt die Arbeit, geht zurück, um das Ergebnis zu speichern, und nimmt dann die nächste Aufgabe auf. Tausende Arbeiter, aber sie verbringen die meiste Zeit damit, zum Lager hin und zurück zu gehen.
Dataflow-Architektur funktioniert wie ein Fließband. Statt dass Arbeiter zu Materialien gehen, fließen Materialien durch stationäre Arbeitsstationen. Jede Operation ist physisch auf dem Chip angeordnet, und Daten strömen von einer zur nächsten ohne Umwege zum Speicher. Der Chip ist so konzipiert, dass bis eine Operation endet, ihr Output bereits bei der nächsten Operation ankommt.
SambaNova nennt dies "räumliche Ausführung" - die Berechnung wird auf das physische Chip-Layout abgebildet, anstatt als Sequenz von Anweisungen geplant zu werden. Das Ergebnis: Daten bleiben in Bewegung, anstatt zu warten.
2. Drei Speicherebenen, strategisch platziert
Speichergeschwindigkeit variiert mit der Entfernung vom Prozessor. Der nächste Speicher (SRAM, auf dem Chip selbst) ist 100x schneller als die nächste Ebene (HBM), die immer noch viel schneller als Systemspeicher (DDR) ist. Der Trick besteht darin, die richtigen Daten am richtigen Ort zu halten.
SambaNovas RDU nutzt alle drei Ebenen gezielt. SRAM auf dem Chip verarbeitet die heißesten Daten - Zwischenberechnungen, die sonst zum Speicher und zurück springen würden. HBM (1 Terabyte pro Rack) speichert Modellgewichte und den Konversations-Cache. DDR (12 Terabyte pro Rack) hält mehrere Modelle und gecachte Prompts für sofortiges Umschalten.
Der Schlüsselunterschied zu GPUs: Die Speicherhierarchie des RDU ist softwaregesteuert, nicht hardwareverwaltet. Der Compiler entscheidet, was wohin geht, anstatt sich auf Cache-Vorhersage zu verlassen. Für vorhersagbare Workloads wie Inferenz - wo Sie genau wissen, welche Gewichte Sie in welcher Reihenfolge benötigen - eliminiert dies Cache-Misses.
Das bedeutet auch, dass keine Quantisierung nötig ist. GPU-Anbieter komprimieren Modelle oft auf INT8 oder INT4, um Speicherbandbreitenanforderungen zu reduzieren - Genauigkeit gegen Geschwindigkeit tauschend. Die Dataflow-Speicherhierarchie löst das Bandbreitenproblem direkt, sodass Modelle mit ihrer nativen Präzision ohne Kompromisse laufen.
Dieses Design ermöglicht es auch einem einzelnen Rack, massive Modelle zu betreiben. Ein 671B-Parameter-Modell auf GPUs zu betreiben erfordert 40 Racks (320 GPUs). SambaNova betreibt es auf einem Rack mit 16 RDUs, weil die Speicherhierarchie effizient skaliert.
Die DDR-Ebene ermöglicht einen weiteren Vorteil: schnelles Modellwechseln. Da DDR direkt mit den Chips verbunden ist (nicht über Systemspeicher wie bei GPUs), dauert das Laden eines anderen Modells Millisekunden statt der Sekunden oder Minuten, die GPU-Infrastruktur benötigt. Ein einzelnes Rack kann mehrere Modelle hosten und bei Bedarf zwischen ihnen wechseln.
3. Geplante Route vs. GPS-Neuberechnung
GPUs treffen Scheduling-Entscheidungen zur Laufzeit. Die Hardware jongliert ständig, welche Threads wo laufen, verwaltet Konflikte, wenn mehrere Kerne dieselben Daten benötigen, und koordiniert Synchronisationspunkte. Diese Flexibilität ist wertvoll für unvorhersehbare Workloads - aber Inferenz ist nicht unvorhersehbar. Sie kennen die Modellarchitektur. Sie kennen die Sequenz der Operationen. Die einzige Variable sind die Eingabedaten.
Der RDU-Compiler nutzt diese Vorhersagbarkeit aus. Er plant die gesamte Ausführung im Voraus - welcher Chip welche Schicht verarbeitet, wann Daten zwischen Chips bewegt werden, sogar den exakten Taktzyklus, in dem jede Operation startet. Keine Laufzeitentscheidungen, kein Koordinationsoverhead, kein Warten auf Nachzügler. Stellen Sie es sich als den Unterschied zwischen einem Lieferfahrer vor, der Turn-by-Turn-GPS folgt (ständig neu berechnend) versus einem Amazon-Lagerroboter, der einer voroptimieren Route durch die Anlage folgt. Wenn Sie wissen, dass sich das Layout nicht ändert, schlägt Planung Improvisation.
4. Kontinuierliche Pipeline vs. Stop-and-Go
Traditionelle GPU-Inferenz läuft als Serie diskreter Operationen. Starte die Attention-Berechnung. Warte auf ihre Fertigstellung. Schreibe Ergebnisse in den Speicher. Starte die nächste Operation. Lese Ergebnisse aus dem Speicher. Wiederhole. Jede Übergabe zwischen Operationen kostet Zeit - nicht für Berechnung, sondern für Speicherschreibvorgänge, Kernel-Starts und Synchronisation. Bei einer langen Inferenz, die Hunderte von Tokens generiert, summieren sich diese Übergaben.
Dataflow-Ausführung verschmilzt Operationen zu kontinuierlichen Pipelines. Daten fließen von Attention zu Feedforward zur nächsten Schicht ohne Unterbrechung. Zwischenergebnisse bleiben on-chip, anstatt Rundreisen zum Speicher zu machen. Die Ausführung sieht weniger wie ein Staffellauf aus (Staffelstab übergeben, warten, laufen) und mehr wie ein Fluss (kontinuierlicher Fluss durch eine Reihe von Verarbeitungsstationen).
Reale Performance-Zahlen
Diese architektonischen Unterschiede übersetzen sich in messbare Geschwindigkeitsvorteile. Artificial Analysis, die Anbieter unabhängig benchmarkt, misst SambaNova konstant unter den schnellsten Inferenz-Anbietern - mit gpt-oss-120b bei 685 tok/s und MiniMax M2.7 bei 426 tok/s in ihren Live-Benchmarks.
Auf Infercoms EU-Infrastruktur, die dieselbe RDU-Architektur nutzt, sehen wir 713 tok/s auf gpt-oss-120b (bis zu 772 bei kürzeren Prompts) und 428 tok/s auf MiniMax M2.7 Ultraspeed. Time to First Token bei 10K Input beträgt 388ms für gpt-oss-120b und 690ms für MiniMax M2.7 Ultraspeed. Diese Zahlen kommen aus unseren EU-Rechenzentren in München - keine US-Routing-Latenz für EU-Nutzer.
Wie vergleicht sich das? GPU-basierte Anbieter erreichen typischerweise 50-150 tok/s bei großen Modellen. Der 3-10x Geschwindigkeitsunterschied spiegelt den architektonischen Vorteil direkt wider - und die Lücke wächst mit zunehmender Modellgröße, weil Speicherbandbreite mehr zum Engpass wird. Mehr dazu, was diese Metriken bedeuten und wann welche wichtig ist, siehe LLM Inference-Geschwindigkeit erklärt.
Die Decode-Ära: Warum das jetzt wichtig ist
Jahrelang drehten sich KI-Infrastruktur-Gespräche um Rechenleistung. Mehr TFLOPS, größere Cluster, schnellere Trainingsläufe. Das war sinnvoll, als die dominante Herausforderung das Training größerer Modelle war. Aber Inferenz - insbesondere agentische Inferenz - verändert das Problem grundlegend.
Agenten beantworten nicht nur einen Prompt und stoppen. Sie denken über lange Kontexte nach, generieren viele Tokens, rufen Tools auf, iterieren. Jede Token-Generierung tritt wieder in denselben Decode-Zyklus ein. Ineffiziente Datenbewegung akkumuliert Latenz Token für Token. Schnellere Tokens übersetzen sich in mehr Intelligenz, weil das System mehr Denkschritte innerhalb desselben Zeitbudgets erkunden kann. Deshalb ist Geschwindigkeit so wichtig für agentisches Coding.
Energieeffizienz: Ein Nebeneffekt besserer Architektur
Schnellere Inferenz pro Watt ist nicht nur ein Nachhaltigkeits-Argument. Es beeinflusst die Betriebswirtschaft direkt. Infercoms SambaNova-Racks verbrauchen etwa 10 kW pro Stück. Äquivalente GPU-Infrastruktur läuft mit 40-50 kW oder mehr pro Rack - vier- bis fünfmal so viel Strom für vergleichbare Inferenzkapazität. Die RDUs nutzen auch Standard-Luftkühlung, während hochdichte GPU-Deployments oft Flüssigkühlungsinfrastruktur benötigen, die Kosten und Komplexität hinzufügt.
Stanfords Hazy Research Lab entwickelte eine Methodik zur Messung von "Intelligenz pro Watt" - nützlicher Output pro Energieeinheit. Nach dieser Metrik liefert Dataflow-Architektur bis zu 5x mehr Intelligenz pro Joule als GPU-basierte Inferenz.
Diese Effizienz kommt von denselben architektonischen Entscheidungen, die Geschwindigkeit ermöglichen. Daten on-chip zu halten reduziert Speicherverkehr. Reduzierter Speicherverkehr bedeutet weniger Energie für Datenbewegung. Statisches Scheduling eliminiert verschwendete Zyklen. Alles akkumuliert sich.
Was kommt als Nächstes: Disaggregierte Inferenz
Die Branche reagiert. Die nächste Evolution ist bereits im Gange: disaggregierte Inferenz, bei der Prefill und Decode auf völlig separater Hardware laufen.
Die Logik ist einfach. Prefill ist rechengebunden - es profitiert von rohen TFLOPS und hoher Parallelität. Decode ist speichergebunden - es braucht Bandbreite und Speicherzugriff mit niedriger Latenz. Beides auf demselben Chip laufen zu lassen bedeutet, dass eine Phase immer suboptimal ist. Warum Kompromisse eingehen, wenn man spezialisieren kann?
Auf der GTC 2026 kündigte Jensen Huang an, dass NVIDIA sich in Richtung disaggregierter Inferenz bewegt. SambaNova und Intel kündigten eine ähnliche Architektur an: GPUs übernehmen Prefill (Aufbau des KV-Cache), RDUs übernehmen Decode (schnelle Token-Generierung), und Xeon CPUs verwalten Orchestrierung und Tool-Ausführung.
Das ist noch wichtiger für agentische Workloads. Wenn ein Agent eine komplexe Aufgabe durchdenkt, iteriert er möglicherweise dutzende Male - denken, Tools aufrufen, Ergebnisse validieren, wiederholen. Jede Iteration trifft die Decode-Phase. Latenz akkumuliert sich über Iterationen. Eine 3x-Verbesserung der Decode-Geschwindigkeit macht nicht nur einzelne Antworten schneller; sie ermöglicht mehr Denkschritte innerhalb desselben Zeitbudgets.
Das ist nicht theoretisch - die Effizienzgewinne sind zu signifikant, um sie zu ignorieren. Erwarten Sie, dass disaggregierte Inferenz in den nächsten Jahren zum Standard für Hochleistungs-Deployments wird.
Das Fazit
GPU-Inferenz stößt bei großen Modellen an eine Wand, weil Decode speichergebunden ist, nicht rechengebunden. Der Chip sitzt untätig da und wartet auf Daten. Dataflow-Architektur löst dies mit räumlicher Ausführung, gestuftem Speicher, statischem Scheduling und kontinuierlichen Pipelines. Das Ergebnis: 3-10x schnellere Inferenz bei speichergebundenen Workloads.
Das ist kein Marketing. Das ist Physik.
Der Decode-Engpass verschwindet nicht - er wird sogar schlimmer, da Modelle wachsen und agentische Workloads mehr Tokens pro Aufgabe verlangen. Die Branche reagiert mit spezialisierter Hardware und disaggregierten Architekturen. Infercom betreibt SambaNova, weil es heute die beste Kombination aus Geschwindigkeit, Effizienz und Großmodell-Support für EU-Deployment bietet. Wir werden uns anpassen, wenn sich die Hardware-Landschaft weiterentwickelt.
Sie müssen uns das nicht glauben. benchmark.infercom.ai lässt Sie Ihre tatsächlichen Prompts gegen unsere Infrastruktur testen. Artificial Analysis veröffentlicht unabhängige Benchmarks über Anbieter hinweg. Testen Sie mit Ihren typischen Input- und Output-Längen. Testen Sie während Stoßzeiten. Die Architekturvorteile zeigen sich in den Zahlen.
Machen Sie die Rechnung. So wissen Sie es.
Weiterführende Lektüre
SambaNova technische Ressourcen:
- 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
Unabhängige Analysen:
Infercom Ressourcen:
- Performance-Benchmarks - Unsere tatsächlichen Zahlen
- Technologie-Übersicht - Wie wir Dataflow-Architektur einsetzen
- LLM Inference-Geschwindigkeit erklärt - Was die Metriken bedeuten
- Agentisches Coding - Warum Geschwindigkeit für KI-unterstützte Entwicklung wichtig ist
Geschrieben von Thomas Vits, mit Unterstützung von KI.