Eine GenAI-Anwendung kann fachlich überzeugen und trotzdem im Alltag scheitern: wenn Antworten zu langsam kommen, Lastspitzen die Systeme überfordern oder die Kosten pro Anfrage unkontrolliert wachsen. In der Praxis liegt das Problem selten „im Modell“, sondern in der Art, wie KI-Inferenz in Backend, Datenzugriff und Produktlogik eingebettet ist. Wer Inferenz wie ein Produktionssystem behandelt – mit klaren Zielen für Latenz, Durchsatz und Budget – erhält zuverlässige Nutzererlebnisse und planbare Betriebskennzahlen.
Der Fokus dieses Beitrags liegt auf Inferenz für LLM-basierte Anwendungen (Chat, Assistenz, Zusammenfassung, Klassifikation, Extraktion). Im Mittelpunkt stehen kontrollierbare Stellhebel: Request-Design, Modellwahl, Caching, Parallelisierung, Streaming sowie Mess- und Betriebskonzepte.
Latenz bei LLM-Anfragen: welche Bestandteile wirklich zählen
End-to-End-Latenz zerlegen statt pauschal „zu langsam“
Für Optimierung ist eine klare Zerlegung der Antwortzeit entscheidend. End-to-End-Latenz setzt sich typischerweise aus mehreren Phasen zusammen: Netzwerk und Authentifizierung, Queueing/Wartezeit, Modellstart oder Warmup, Prompt-Vorbereitung, eigentliche Token-Generierung sowie Nachbearbeitung (Parsing, Safety-Checks, Rendering). Besonders die Token-Generierung dominiert bei langen Antworten, während bei kurzen Antworten oft Warteschlangen, TLS/Proxy oder Initialisierung auffallen.
Ein bewährter Ansatz ist eine einfache Zeitbudgetierung: Für eine gewünschte Nutzererfahrung wird ein Zielwert festgelegt (z. B. „spürbar interaktiv“), dann wird der Wert auf Teilkomponenten verteilt. So entsteht unmittelbar Klarheit, ob eher Infrastruktur (Queueing), Prompt-Design (Prompt-Länge) oder Modellverhalten (Tokenrate) der Hebel ist.
Streaming verbessert Wahrnehmung, nicht zwingend Gesamtdauer
Token-Streaming verkürzt die Zeit bis zum ersten sichtbaren Output und verbessert die gefühlte Geschwindigkeit erheblich. Für die Gesamtdauer kann Streaming neutral sein, weil weiterhin die gleiche Anzahl Tokens erzeugt werden muss. Der praktische Nutzen entsteht vor allem in UI-nahen Flows (Chat, Copilot), weniger in Batch-Jobs. Wichtig ist, Streaming als Produkt- und UX-Entscheidung zu behandeln: Abbruchmöglichkeiten, Zwischenstände und klare Ladeindikatoren reduzieren Frust und senken gleichzeitig unnötige Tokenkosten durch frühzeitiges Stoppen.
Prompt-Länge und Kontext sind direkte Latenztreiber
Jedes zusätzliche Token im Input erhöht Verarbeitung und häufig auch die Generationsdauer (weil Antworten länger werden). Kontext wird oft „auf Verdacht“ vollständig mitgeschickt, obwohl nur ein Teil relevant ist. Stattdessen sollten Kontextblöcke streng kuratiert werden: kurze Auszüge, klare Rangfolge, und nur die Informationen, die für die konkrete Frage nötig sind. In RAG-Setups ist es häufig effizienter, weniger Dokumente mit höherer Relevanz zu liefern als viele mittelmäßige Treffer. Passend dazu lohnt sich ein Blick auf Kontextfenster und Grenzen in der Praxis.
Durchsatz und Parallelität: von Einzelanfragen zu Produktionslast
Warum „mehr Nutzer“ nicht linear skaliert
LLM-Inferenz skaliert nicht wie klassische Web-APIs, weil die Rechenlast pro Request stark variiert: Eingabelänge, gewünschte Ausgabelänge, Stop-Sequenzen, Tool-Calls und Retries verändern den Verbrauch. Deshalb führt mehr Parallelität ab einem Punkt zu Warteschlangen und damit zu explodierender Latenz. Der Engpass ist häufig GPU-Speicher, seltener reine CPU-Zeit.
Ein brauchbares Betriebsmodell betrachtet Anfragen als „Kostenpakete“: Input-Tokens + Output-Tokens + Overhead (Tooling, Retrieval, Postprocessing). Daraus lassen sich Kapazitätsziele ableiten, etwa wie viele typische Requests pro Minute bei akzeptabler Latenz möglich sind.
Batching, Micro-Batching und Priorisierung
Bei vielen gleichartigen Requests (z. B. Klassifikation, Extraktion, Zusammenfassung) kann Batching die Hardwareauslastung verbessern, indem mehrere Inputs in einem Inferenzlauf verarbeitet werden. In interaktiven Systemen sind Micro-Batches üblich: sehr kurze Sammelfenster, um nicht spürbar zu verzögern. Wichtig ist eine klare Priorisierung: interaktive Nutzeranfragen sollten andere Warteschlangen-Regeln haben als Backoffice-Batch-Jobs.
Praktisch bewährt sind getrennte Queues für „Live“ und „Batch“ mit unterschiedlichen Timeouts und Retry-Regeln. So wird verhindert, dass ein großer nächtlicher Job den Chat am Morgen ausbremst.
Concurrency-Limits als Sicherheitsgurt
Concurrency-Limits sind ein zentraler Schutz gegen Kaskadeneffekte: Zu viele parallele Requests erhöhen Queueing, verursachen Timeouts, lösen Retries aus und verschärfen die Last nochmals. Saubere Limits pro Tenant, pro API-Key oder pro Funktionsbereich stabilisieren den Betrieb. Das Prinzip ähnelt Feature-Freigaben; wer Funktionsrollouts granular steuern will, findet ergänzend Ansätze bei Feature-Flags für GenAI.
Kosten pro Anfrage: die wichtigsten Hebel ohne Mythos
Tokenbudgetierung als Produktentscheidung
In vielen Teams wird zuerst am Preis pro Token diskutiert. Oft ist jedoch das Nutzungsprofil der stärkere Hebel: Wie viele Requests pro Nutzer und Tag? Wie lang sind Prompts im Mittel? Wie hoch ist das maximale Antwortlimit? Eine Tokenbudgetierung pro Use Case schafft Transparenz: Für jede Funktion wird festgelegt, welche maximale Input- und Output-Länge akzeptabel ist und wie Abbrüche aussehen. Diese Regeln sind produktnah, nicht rein technisch.
Caching: nicht nur für Retrieval, auch für Modellantworten
Response-Caching lohnt sich, wenn Anfragen sich häufig wiederholen oder stark ähneln: Standardfragen, Hilfetexte, Richtlinien, wiederkehrende Reports. Zusätzlich gibt es „Partial Caches“: wiederverwendbare Systemteile, Vorlagen, statische Kontextbausteine oder normalisierte Nutzereingaben. Wichtig ist die Risikoabwägung: Caches brauchen klare Invalidierungslogik, Tenant-Trennung und Datenschutzregeln. Besonders bei personenbezogenen oder vertraulichen Inhalten sollten Caches kurzlebig sein oder vollständig vermieden werden.
Tool-Calls und Retrieval sind oft versteckte Kostentreiber
Viele moderne Anwendungen rufen neben dem Modell weitere Systeme auf: Vektorsuche, SQL, interne APIs, Dokumentenparser. Diese Schritte verursachen Latenz und Kosten unabhängig vom LLM-Preis. Typische Optimierungen sind: Retrieval nur bei Bedarf (z. B. wenn das Modell signalisiert, dass Wissen fehlt), harte Limits für Trefferanzahl, und klare Timeout-Strategien. Wer RAG betreibt, kann ergänzend den Betrieb von Vektordatenbanken vertiefen.
Architektur-Entscheidungen: Hosting, Routing und Modellmix
Gehostete API vs. eigenes Serving: Kriterien statt Ideologie
Für viele Organisationen ist eine gehostete LLM-API der schnellste Weg zu stabiler Inferenz, weil Skalierung, Patching und Hardware-Management ausgelagert sind. Eigenes Serving kann sinnvoll sein, wenn spezielle Latenzanforderungen, strenge Datenlokation, sehr hohe Last oder ein kontrollierter Modellmix nötig sind. Entscheidend sind Betriebskompetenz, Monitoring-Reife und die Fähigkeit, Lastprofile realistisch zu prognostizieren.
Mehrere Modelle statt „one size fits all“
Ein Modellmix reduziert Kosten und verbessert Qualität: kleine Modelle für Klassifikation oder Extraktion, größere für komplexe Synthese. Routing kann regelbasiert (Use Case), dynamisch (Confidence/Heuristiken) oder anhand von Evaluationsdaten erfolgen. Das Zusammenspiel aus Qualität, Kosten und Latenz wird deutlich besser, wenn nicht jede Aufgabe das teuerste Modell erhält. Vertiefend passt hierzu Model-Routing in der Praxis.
Warmup, Pooling und Skalierung
Bei eigenem Serving sind Warmup und Pooling entscheidend: Kaltstarts erhöhen die Latenz spürbar. Ein Grundbestand „warmer“ Worker reduziert Ausreißer, während horizontale Skalierung Spitzen abfängt. Gleichzeitig braucht es Grenzen, weil Skalierung nicht unbegrenzt ist (Kosten, GPU-Verfügbarkeit). Besonders wichtig: Skalierung muss am realen Request-Mix getestet werden, nicht an synthetischen Einzelfällen.
Messung und Betriebssteuerung: was dauerhaft stabil hält
Welche Kennzahlen für Inferenz wirklich helfen
Für kontinuierliche Steuerung reichen wenige, aber präzise Metriken: Latenzverteilung (nicht nur Mittelwert), Zeit bis zum ersten Token (bei Streaming), Erfolgsquote/Fehlertypen, Retries, Tokenverbrauch pro Use Case sowie Queueing-Zeiten. Ergänzend sind Qualitätsindikatoren nötig, damit „billiger und schneller“ nicht unbemerkt zu schlechteren Antworten führt. Für die technische Betriebsseite ist Observability für GenAI ein passender Anknüpfungspunkt.
Fehlerbilder: Timeouts, Retries, Rate Limits
Timeouts sollten differenziert sein: kurze Timeouts für Tool-Calls, längere für reine Generierung, und klare Abbruchpfade im UI. Retries dürfen nicht „blind“ sein, sondern brauchen Backoff und Obergrenzen. Rate Limits sind kein Ärgernis, sondern ein Designinstrument: Sie schützen Systeme und ermöglichen faire Nutzung über Teams und Mandanten hinweg.
Kompakter Vergleich zentraler Stellhebel
| Stellhebel | Wirkt primär auf | Typische Nebenwirkung | Geeignet wenn |
|---|---|---|---|
| Prompt kürzen / Kontext straffen | Latenz, Kosten | Risiko: fehlende Details | Kontext oft „zu viel“ oder unscharf |
| Streaming aktivieren | Wahrgenommene Latenz | Komplexeres Frontend | Interaktive Chat-/Copilot-Flows |
| Caching (Antworten/Teile) | Kosten, Durchsatz | Invalidierung, Datenschutz | Viele wiederkehrende Anfragen |
| Batching / Micro-Batching | Durchsatz | Mehr Latenz bei falscher Konfiguration | Viele ähnliche Requests, Batch-Workloads |
| Modellmix + Routing | Kosten, Qualität | Mehr Komplexität im Betrieb | Heterogene Use Cases, klare Qualitätsziele |
| Concurrency-Limits | Stabilität | Abweisungen bei Spitzen | Lastspitzen, viele Teams/Tenants |
Praxisnahe Umsetzung: ein belastbarer Ablauf für Teams
So lässt sich Inferenz planbar machen
- Pro Use Case ein Ziel definieren: maximale Antwortzeit, gewünschte Zeit bis zum ersten Output, akzeptable Fehlerrate.
- Tokenbudgets festlegen: Obergrenzen für Input/Output, klare Stop-Regeln und Abbruchmöglichkeiten im UI.
- Lastprofil beschreiben: typische Anfragegrößen, Peak-Zeiten, Anteil interaktiv vs. Batch.
- Messpunkte einbauen: Zeitstempel pro Pipeline-Schritt (Retrieval, Tool-Calls, Generierung, Postprocessing).
- Stabilisatoren aktivieren: Concurrency-Limits, getrennte Queues, Timeouts pro Schritt, Retry-Backoff.
- Optimierungen priorisieren: erst Kontext/Prompt und Tooling, dann Caching/Batching, zuletzt Infrastruktur/Serving.
- Regelmäßige Review-Schleife: Kosten- und Qualitätsdrift pro Funktion beobachten und Grenzwerte nachschärfen.
Typische Stolpersteine aus Pilotprojekten
In Piloten werden Lastspitzen unterschätzt, weil wenige Nutzer testen und Workflows noch nicht in Kernprozesse integriert sind. Außerdem werden Tool-Calls (z. B. Retrieval, interne APIs) als „kostenlos“ betrachtet, obwohl sie Latenz dominieren können. Ein weiterer Klassiker ist die fehlende Trennung von Live- und Batch-Verkehr: Eine nächtliche Verarbeitung kann am nächsten Morgen noch Kapazität blockieren, wenn Queues nicht sauber segmentiert sind.
Häufige Fragen aus Produkt- und Plattformteams
Was bringt mehr: kleineres Modell oder kürzerer Prompt?
Beides kann stark wirken, aber die Reihenfolge ist oft klar: Ein überlanger Prompt treibt Latenz und Kosten unabhängig vom Modell. Wenn der Kontext bereits straff ist, kann ein Modellmix die größte Wirkung entfalten, weil einfache Aufgaben nicht das größte Modell benötigen.
Wann lohnt sich Caching wirklich?
Wenn Wiederholungen auftreten oder Teile des Inputs stabil sind. Bei hochindividuellen Nutzeranfragen ist Response-Caching selten wirksam. Häufig lohnt eher das Caching statischer Kontextbausteine oder normalisierter Zwischenprodukte (z. B. extrahierte Fakten), sofern Datenschutz und Tenant-Trennung sauber umgesetzt sind.
Wie entstehen extreme Latenzausreißer?
Ausreißer entstehen typischerweise durch Queueing unter Last, Kaltstarts, Timeouts in Tool-Calls oder unerwartet lange Generation (keine Stop-Regeln, zu hohes Output-Limit). Ohne Zerlegung der Pipeline werden diese Ursachen leicht verwechselt, was zu falschen Optimierungen führt.
