LLM-Streaming

Was ist LLM-Streaming?

LLM-Streaming ist die schrittweise Auslieferung der Antwort eines Sprachmodells, Token für Token, während sie erzeugt wird, statt auf die vollständige Fertigstellung zu warten. Es macht aus einer Antwort, die viele Sekunden zum Fertigstellen braucht, eine, die fast sofort zu erscheinen beginnt – weshalb nahezu jede Chat- und Agenten-Oberfläche darauf setzt.

Die wichtigsten Punkte

• Streaming macht die Generierung nicht schneller; es macht das Warten zu sichtbarem Fortschritt. Die Gesamtzeit bis zur Fertigstellung bleibt gleich, aber die wahrgenommene Latenz sinkt drastisch.
• Die entscheidenden Metriken teilen sich in zwei auf: Time to First Token, dominiert von der Prompt-Verarbeitung, und Token pro Sekunde danach.
• Streaming verkompliziert alles nachgelagerte: JSON-Parsing, die Handhabung von Tool-Calls, Guardrail-Prüfungen und Fehlerbehandlung müssen alle mit unvollständiger Ausgabe zurechtkommen.
• Die meisten APIs liefern Streams über Server-Sent Events aus, und lang laufende Agenten-Aufrufe erfordern Streaming oft schon allein, um Verbindungen offen zu halten und Timeouts zu vermeiden.

So funktioniert es

Ein Transformer erzeugt Text ein Token nach dem anderen, unabhängig davon, wie er konsumiert wird. Ein nicht-streamender API-Aufruf puffert diese Token einfach und gibt sie gesammelt zurück; ein Streaming-Aufruf schickt jeden Chunk an den Client, sobald er erzeugt wurde, typischerweise über Server-Sent Events (SSE), wobei das SDK die Deltas zu Text, Tool-Call-Argumenten und – bei Reasoning-Modellen – Denkzusammenfassungen zusammensetzt. Der Nutzer beginnt nach dem ersten Token zu lesen statt nach dem letzten. Bei einer 2.000-Token-Antwort mit 60 Token pro Sekunde ist das der Unterschied zwischen Text, der innerhalb einer Sekunde zu fließen beginnt, und einem Ladesymbol, das eine halbe Minute lang angestarrt wird.

Die technischen Kosten landen beim Konsumenten. Eine unvollständige Antwort ist kein valides JSON, weshalb strukturierte Ausgaben inkrementelle Parser brauchen oder gepuffert werden müssen, bis der relevante Block abgeschlossen ist. Tool-Calls kommen als Argument-Fragmente an, die erst nach Vollständigkeit ausführbar werden. Ausgabe-Guardrails, etwa Moderation oder das Scannen nach Geheimnissen, stehen vor der Wahl, Chunks im Vorbeigehen zu prüfen – und dabei möglicherweise bereits angezeigten Text zurückzuziehen – oder sensible Abschnitte zu puffern und dafür etwas Latenz in Kauf zu nehmen. Fehler mitten im Stream hinterlassen eine halbe Antwort und eine Entscheidung über einen Wiederholungsversuch. Streaming spielt auch zwischen Maschinen eine Rolle: In Multi-Agenten-Pipelines und Agent-Harnessen kann ein Orchestrator schon auf frühe Ausgaben reagieren, und bei Anfragen mit sehr langen Ausgaben empfehlen oder verlangen Anbieter Streaming, weil untätige Verbindungen an Gateway-Timeouts scheitern. Wie Token getaktet werden, ist selbst ein Serving-Thema: Andes, ein System der University of Michigan, das die Auslieferung von Token in gestreamten Antworten plant, verbesserte die durchschnittliche wahrgenommene Nutzererfahrung bei gleichen GPU-Ressourcen um bis zum 4,7-Fachen – oder sparte bei gleichem Erfahrungsniveau bis zu 61 % der GPU-Ressourcen [1].

Beispiel

Ein Team baut einen internen Analytics-Agenten: Der Nutzer stellt eine Frage, das Modell schreibt SQL, führt es über ein Tool aus und erklärt die Ergebnisse. Die erste Version verwendete blockierende Aufrufe, und Nutzer berichteten, das Tool „hänge" bei allem Nicht-Trivialen, da eine reasoning-intensive Abfrage fünfzehn stille Sekunden bedeutete. Die neu gebaute Version streamt alles: Denkzusammenfassungen werden als Statuszeile dargestellt, die SQL-Abfrage erscheint Zeichen für Zeichen in einem Codeblock, während sie geschrieben wird, und die Erklärung fließt anschließend nach. Eine Feinheit kostet einen ganzen Nachmittag: Die Oberfläche versuchte, das SQL bei jedem Delta syntaktisch hervorzuheben, und das erneute Parsen einer halbfertigen Abfrage warf Fehler – also wurde das Hervorheben verzögert, bis der Code-Block geschlossen war. Gleiches Modell, gleiche Latenz, und die wahrgenommene Erfahrung wandelte sich von kaputt zu reaktionsschnell.

Häufige Missverständnisse

Das wiederkehrende Missverständnis ist, Streaming sei ein UI-Extra, das man am Ende noch anflanschen kann. In der Praxis verändert es den Vertrag des Systems mit dem Modell überall dort, wo die Ausgabe konsumiert wird. Code, der von einer vollständigen Antwort ausging – JSON validieren, Ausgaben gegen KI-Guardrails prüfen, vollständige Completions loggen –, bricht oder degradiert unbemerkt, wenn er Fragmente erhält. Teams, die Streaming aufschieben, enden oft damit, ihre Antwortverarbeitungsschicht spät im Projekt neu schreiben zu müssen. Früh entscheiden, von Anfang an streamen und „unvollständige Ausgabe behandeln" als Designanforderung behandeln, nicht als Sonderfall.

FAQ

Reduziert Streaming die Latenz eines LLM? Es reduziert die vom Nutzer wahrgenommene Time to First Token, die für die gefühlte Reaktionsschnelligkeit ausschlaggebend ist, aber die Gesamtgenerierungszeit bleibt identisch. Um die Generierung wirklich zu beschleunigen, braucht es ein kleineres oder quantisiertes Modell, einen kürzeren Prompt, weniger Ausgabe-Token oder Verbesserungen auf Anbieterseite. Die Wahrnehmung hat ihre eigenen Eigenheiten: Eine CHI-2026-Studie, die die Time-to-First-Token zwischen 2, 9 und 20 Sekunden variierte, fand, dass Teilnehmer Ausgaben nach 2-Sekunden-Wartezeiten als weniger durchdacht und nützlich bewerteten als nach 9 oder 20 Sekunden – sie lasen die längere Verzögerung als Nachdenken der KI [2].

Wie funktioniert Streaming mit strukturierten Ausgaben und Tool-Calls? Der Stream liefert typisierte Ereignisse: Text-Deltas, Tool-Call-Argument-Fragmente und Abschlusssignale. Ein Tool-Call wird entweder gepuffert, bis seine Argumente vollständig sind – die sichere Standardoption –, oder es kommt ein inkrementeller JSON-Parser zum Einsatz, der auf Felder reagiert, sobald sie abgeschlossen sind. Ein Tool sollte nie mit unvollständigen Argumenten ausgeführt werden.

Sollten Agenten-Backends auch streamen, wenn kein Mensch zuschaut? Meist ja. Streaming hält lange Anfragen innerhalb der Proxy- und Gateway-Timeouts, ermöglicht frühzeitigen Abbruch, wenn die Ausgabe entgleist, und erlaubt es Orchestratoren, nachgelagerte Arbeit im Pipeline-Verfahren zu starten. Gepufferte Aufrufe sind für kurze, begrenzte Completions in Batch-Jobs unproblematisch.

Quellen

1. University of Michigan (arXiv). Das QoE-bewusste Serving-System Andes verbessert die Qualität gestreamter Antworten um bis zum 4,7-Fachen oder spart bis zu 61 % der GPU-Ressourcen bei gleicher QoE. https://arxiv.org/abs/2404.16283. Abgerufen im August 2026.
2. ACM CHI 2026 (arXiv). Teilnehmer bewerteten LLM-Ausgaben nach einer Time-to-First-Token von 2 Sekunden als weniger durchdacht und nützlich als nach Wartezeiten von 9 oder 20 Sekunden. https://arxiv.org/abs/2604.06183. Abgerufen im August 2026.