Latenz-Architektur für LLM-Apps: Streaming, Vorberechnung und UX-Muster

Zwei Anwendungen nutzen dasselbe Modell mit derselben Antwortzeit. Die eine fühlt sich flüssig an, die andere zäh. Der Unterschied liegt nicht im Modell, sondern in allem, was darum herum gebaut wurde: wann die Anwendung erste Inhalte zeigt, was sie vorberechnet hat und wie sie mit Wartezeit umgeht, die sich nicht vermeiden lässt.

Denn an der Grundgeschwindigkeit der Modelle lässt sich anwendungsseitig wenig drehen. Eine lange Antwort braucht ihre Zeit, ein großer Kontext ebenso. Was sich sehr wohl gestalten lässt, ist die gefühlte Latenz: die Zeit, bis der Nutzer etwas Verwertbares sieht und weiß, dass das System arbeitet. Die entscheidende Messgröße ist deshalb selten die Gesamtdauer, sondern die Zeit bis zum ersten sichtbaren Inhalt.

Dieser Artikel geht die wichtigsten Bausteine einer Latenz-Architektur durch: Streaming, Vorberechnung, asynchrone Jobs, Modell-Kaskaden und Latenz-Budgets als Planungsinstrument.

Token-Streaming und progressive Anzeige

Der wirksamste Einzelhebel ist Streaming: Statt auf die vollständige Antwort zu warten, liefert die API Token, sobald sie entstehen, und die Oberfläche zeigt sie fortlaufend an. Die Gesamtdauer ändert sich dadurch nicht, aber die Wartezeit bis zum ersten Inhalt schrumpft von vielen Sekunden auf einen Bruchteil davon. Der Nutzer liest bereits, während der Rest noch generiert wird.

Damit das gut wirkt, muss die Oberfläche mitspielen. Fortlaufend eintreffender Text braucht eine Darstellung, die nicht springt: Markdown wird progressiv gerendert, Listen und Überschriften erscheinen, sobald sie vollständig sind, und die Scroll-Position bleibt stabil. Grenzen hat Streaming bei strukturierten Ausgaben. Eine halbe JSON-Antwort kann man weder anzeigen noch verarbeiten. In solchen Fällen streamt man statt des Ergebnisses den Fortschritt: welche Schritte gerade laufen, welche Quellen gelesen werden, was schon abgeschlossen ist. Auch das ist progressives Anzeigen, nur auf einer anderen Ebene.

Vorberechnung und Caching auf Anwendungsebene

Die schnellste Antwort ist die, die schon fertig ist. Drei Muster tragen hier die Hauptlast. Erstens der klassische Antwort-Cache: Wiederkehrende, deterministische Anfragen, etwa die Zusammenfassung desselben Dokuments, werden einmal berechnet und danach ausgeliefert. Als Schlüssel dient die normalisierte Eingabe samt Prompt-Version, damit eine Prompt-Änderung den Cache sauber entwertet.

Zweitens die Vorberechnung am Ereignis: Statt zu warten, bis ein Nutzer die Zusammenfassung eines Dokuments anfordert, wird sie erzeugt, sobald das Dokument eintrifft. Der Nutzer erlebt später eine sofortige Antwort, obwohl dahinter ein voller Modellaufruf stand. Drittens das Prompt-Caching der Anbieter: Lange, stabile Kontextteile wie Systemanweisungen und Referenzdokumente werden beim Anbieter zwischengespeichert, was Zeit bis zum ersten Token und Kosten zugleich senkt. Voraussetzung ist eine Prompt-Struktur, die stabile Teile vorn und variable Teile hinten anordnet.

Asynchrone Jobs statt endlosem Spinner

Ab einer gewissen Dauer kippt jede synchrone Interaktion. Wer eine Minute auf einen Spinner schaut, geht davon aus, dass etwas hängt, und lädt die Seite neu, was im schlimmsten Fall den Auftrag doppelt startet. Die Grenze liegt erfahrungsgemäß bei wenigen zehn Sekunden. Alles darüber gehört in einen anderen Modus: Die Anwendung nimmt den Auftrag an, bestätigt sofort und meldet sich, wenn das Ergebnis da ist, per Benachrichtigung in der Anwendung oder per E-Mail.

Der Gewinn ist doppelt. Der Nutzer kann weiterarbeiten, statt eine Wartezeit auszusitzen, und das System kann den Auftrag robust im Hintergrund verarbeiten, mit Wiederholungen und Statusverfolgung statt einer offenen HTTP-Verbindung als einzigem Faden. Wo möglich, zeigt die Statusansicht Zwischenstände: welche Dokumente verarbeitet sind, was noch offen ist. Ein ehrlicher Fortschrittsbalken schlägt jede Animation.

Modell-Kaskaden: klein zuerst

Nicht jede Anfrage braucht das größte Modell. Eine Modell-Kaskade nutzt das aus: Ein kleines, schnelles Modell bearbeitet den Normalfall, und nur erkannt schwierige Fälle gehen an das große Modell weiter. Die Weiche stellt entweder ein vorgeschalteter Klassifikator, der die Komplexität der Anfrage einschätzt, oder das kleine Modell selbst, indem es bei Unsicherheit eskaliert.

Eine Variante ist die Kaskade in der Zeit: Das kleine Modell liefert sofort einen brauchbaren Entwurf, während das große im Hintergrund die ausführliche Fassung erstellt, die dann nachgeladen wird. Beide Varianten haben denselben Preis: Die Qualität streut über zwei Modelle, und die Eskalationslogik ist eine eigene Fehlerquelle. Ohne Evals, die beide Pfade getrennt messen, sollte man Kaskaden nicht betreiben. Mit ihnen sind sie einer der besten Hebel, um Latenz und Kosten gleichzeitig zu senken.

Latenz-Budgets pro Interaktionstyp

Damit diese Bausteine nicht ad hoc eingesetzt werden, lohnt ein einfaches Planungsinstrument: ein Latenz-Budget je Interaktionstyp, festgelegt bevor gebaut wird.

Interaktionstyp	Erwartung des Nutzers	Passendes Muster
Eingabehilfe, Vorschläge	unter einer Sekunde	kleines Modell, aggressives Caching
Chat-Antwort	erster Inhalt nach wenigen Sekunden	Streaming, Prompt-Caching
Dokumentanalyse	Sekunden bis unter einer Minute	Fortschrittsanzeige, Kaskade
Massenverarbeitung	Stunden, aber verlässlich	asynchroner Job, Benachrichtigung

Das Budget entscheidet über die Architektur, nicht umgekehrt. Eine Eingabehilfe mit zwei Sekunden Verzögerung ist wertlos, egal wie gut die Vorschläge sind. Gemessen wird gegen das Budget im Betrieb, sinnvollerweise mit Perzentilen statt Durchschnitt und mit der Zeit bis zum ersten Token als eigener Metrik. Ein Durchschnitt versteckt genau die langsamen Ausreißer, über die sich Nutzer beschweren.

Fazit

Schnelle KI-Anwendungen entstehen nicht durch schnellere Modelle, sondern durch Architektur: Streaming macht Wartezeit sichtbar produktiv, Vorberechnung und Caching lassen sie ganz verschwinden, asynchrone Jobs nehmen langen Aufgaben den Druck, und Kaskaden geben dem Normalfall den schnellen Pfad. Das Latenz-Budget pro Interaktionstyp hält alles zusammen: Es zwingt dazu, die Erwartung des Nutzers vor der Implementierung festzulegen und dagegen zu messen. Wer so plant, baut Anwendungen, die sich schnell anfühlen, obwohl die Modelle dahinter dieselben sind wie überall.