Antwortzeit
Wer eine Frage an ein digitales System stellt, wartet auf eine Reaktion. Die Zeitspanne zwischen Absenden der Anfrage und dem Moment, in dem die erste sichtbare Antwort erscheint, heißt Antwortzeit. Sie entscheidet darüber, ob die Interaktion flüssig wirkt oder als zäh empfunden wird.
Was Antwortzeit misst
Antwortzeit (englisch: response time) erfasst die gesamte Dauer vom Absenden einer Anfrage bis zum Eintreffen der Antwort beim Absender. Sie umfasst mehrere Teilstrecken: die Übertragung der Anfrage über das Netzwerk, die Verarbeitung im Zielsystem und die Rückübertragung des Ergebnisses. Jede dieser Teilstrecken trägt zur Gesamtdauer bei.
Beispiel: Ein Nutzer gibt eine Suchanfrage in ein Webformular ein. Der Browser sendet die Anfrage an den Server (Netzwerk: 20 ms), der Server berechnet die Ergebnisse (Verarbeitung: 80 ms), und die Ergebnisseite wird zurückübertragen (Netzwerk: 20 ms). Die Antwortzeit beträgt 120 ms.
Beispiel: Eine Datenbankabfrage auf einem lokalen Server hat nahezu keine Netzwerkzeit. Die Antwortzeit besteht fast ausschließlich aus der Verarbeitungszeit der Datenbank-Engine: Indexzugriff, Filterung, Sortierung.
Die Messung erfolgt üblicherweise in Millisekunden (ms). Für KI-Systeme, die längere Texte generieren, wird zusätzlich die Zeit bis zum ersten sichtbaren Token erfasst (Time to First Token, TTFT). Diese Metrik ist besonders relevant, wenn Antworten per Streaming schrittweise angezeigt werden.
Fachliche Einordnung: Antwortzeit ist ein Oberbegriff. In der Netzwerktechnik wird zwischen Round-Trip Time (RTT), Processing Time und Queuing Time unterschieden. Bei KI-Systemen kommen Prefill-Zeit (Verarbeitung der Eingabe) und Decode-Zeit (Token-Generierung) als eigene Messabschnitte hinzu.
Aus welchen Teilen sich die Antwortzeit zusammensetzt
Die Gesamtdauer einer Anfrage lässt sich in klar abgrenzbare Abschnitte zerlegen. Jeder Abschnitt hat eigene Ursachen für Verzögerungen und eigene Optimierungsansätze.
Netzwerkübertragung: Die Dauer, bis Datenpakete zwischen Client und Server hin- und zurückreisen. Physische Distanz, Routeranzahl und Bandbreite beeinflussen diese Zeit. Ein Server in Frankfurt erreicht einen Nutzer in München schneller als einer in Singapur.
Beispiel: Ein API-Aufruf von Europa zu einem Rechenzentrum in Nordamerika fügt typischerweise 80 bis 120 ms allein durch Netzwerklaufzeit hinzu. Derselbe Aufruf innerhalb einer Region liegt bei 5 bis 15 ms.
Warteschlange (Queuing): Wenn mehrere Anfragen gleichzeitig eintreffen, müssen sie in eine Warteschlange. Die Wartezeit hängt von der Anzahl gleichzeitiger Anfragen und der Kapazität des Systems ab. Unter hoher Last steigt die Queuing-Zeit überproportional an.
Beispiel: Ein KI-System mit 8 GPU-Slots für gleichzeitige Inferenzanfragen empfängt 200 Anfragen pro Sekunde. Die Warteschlange wächst, und die Antwortzeit steigt von 150 ms auf über 2 Sekunden, obwohl die reine Verarbeitungszeit pro Anfrage unverändert bleibt.
Verarbeitung (Processing): Die eigentliche Rechenarbeit. Bei einer Datenbankabfrage ist das der Indexzugriff. Bei einem KI-Modell die Token-für-Token-Generierung. Die Verarbeitungszeit hängt von der Komplexität der Aufgabe und der verfügbaren Rechenleistung ab.
Antwortzeit bei KI-Systemen
KI-Systeme unterscheiden sich in ihrem Antwortverhalten grundlegend von klassischen Webanwendungen. Eine Webseite liefert eine fertige HTML-Datei aus. Ein Transformer-basiertes Sprachmodell erzeugt seine Antwort schrittweise. Jedes Token wird einzeln berechnet, wobei die bereits erzeugten Tokens als Kontext dienen.
Daraus ergeben sich zwei messbare Größen:
Time to First Token (TTFT): Die Dauer vom Absenden der Anfrage bis zum Erscheinen des ersten Tokens. Diese Metrik bestimmt, wann der Nutzer eine erste sichtbare Reaktion erhält. Bei Streaming-Schnittstellen beginnt der Text zu erscheinen, während das Modell noch rechnet.
Beispiel: Ein Chatbot zeigt nach 400 ms das erste Wort an. Die vollständige Antwort mit 200 Tokens ist nach 4 Sekunden fertig. Ohne Streaming müsste der Nutzer die gesamten 4 Sekunden warten, bevor überhaupt Text sichtbar wird.
Tokens pro Sekunde: Die Rate, mit der das Modell nach dem ersten Token weitere Tokens erzeugt. Ein Modell mit 50 Tokens pro Sekunde produziert flüssig lesbaren Text. Bei 10 Tokens pro Sekunde stockt die Ausgabe sichtbar.
Beispiel: Ein Zusammenfassungsdienst verarbeitet einen 5.000-Wörter-Artikel. Die Tokenisierung des Eingabetextes (Prefill) dauert 800 ms. Danach generiert das Modell die Zusammenfassung mit 40 Tokens pro Sekunde. Die TTFT beträgt 800 ms, die Gesamtantwortzeit für 150 Tokens Ausgabe liegt bei 4,55 Sekunden.
Die Länge der Eingabe beeinflusst die Prefill-Zeit direkt. Je mehr Tokens das Modell als Kontext verarbeiten muss, desto länger dauert dieser erste Schritt. Bei sehr langen Kontexten (100.000 Tokens und mehr) kann allein die Prefill-Phase mehrere Sekunden beanspruchen.
Wie Antwortzeit gemessen wird
Antwortzeiten schwanken. Jede einzelne Messung liefert einen anderen Wert, beeinflusst von Netzwerklast, Systemauslastung und gleichzeitigen Anfragen anderer Nutzer. Deshalb werden Antwortzeiten nicht als Einzelwerte, sondern als Verteilungen betrachtet.
Die gängige Methode nutzt Perzentile: p50 (Median) zeigt den typischen Wert. p95 beschreibt die Schwelle, unter der 95 % aller Anfragen liegen. p99 erfasst die langsamsten 1 % der Anfragen.
Beispiel: Ein API-Dienst meldet folgende Antwortzeiten: p50 = 120 ms, p95 = 340 ms, p99 = 1.200 ms. Der Median sieht gut aus. Doch jede hundertste Anfrage dauert über eine Sekunde. Bei 10.000 Anfragen pro Stunde erleben 100 Nutzer diese Verzögerung.
Arithmetische Mittelwerte sind für Antwortzeiten ungeeignet. Ein einzelner Ausreißer mit 30 Sekunden Antwortzeit verschiebt den Durchschnitt erheblich, ohne dass sich am typischen Nutzererlebnis etwas geändert hat. Perzentile sind gegen solche Verzerrungen robust.
Beispiel: 99 Anfragen werden in 100 ms beantwortet, eine Anfrage dauert 60 Sekunden (Timeout). Der Durchschnitt liegt bei 697 ms. Der Median (p50) bleibt bei 100 ms. Der Median beschreibt das tatsächliche Nutzererlebnis präziser.
Professionelle Monitoringsysteme erfassen Antwortzeiten kontinuierlich und bilden sie als Zeitreihen ab. Dadurch werden Muster sichtbar: Lastspitzen zur Geschäftszeit, Degradation nach Deployments, saisonale Schwankungen. Ohne diese Langzeitbetrachtung bleiben schleichende Verschlechterungen unentdeckt.
Menschliche Wahrnehmung von Antwortzeiten
Die Forschung zur menschlichen Zeitwahrnehmung bei Computersystemen geht auf die Arbeiten von Robert B. Miller (1968) und Jakob Nielsen zurück. Drei Schwellenwerte haben sich empirisch bestätigt:
Unter 100 ms: Die Reaktion wird als unmittelbar empfunden. Der Nutzer erlebt keine Wartezeit. Tastatureingaben, Klicks auf Schaltflächen und einfache Filteroperationen sollten diese Schwelle einhalten.
100 bis 1.000 ms: Die Verzögerung ist spürbar, unterbricht aber den Gedankengang nicht. Der Nutzer nimmt wahr, dass das System arbeitet, bleibt jedoch im Arbeitskontext. Seitennavigation und einfache Suchanfragen fallen in diesen Bereich.
Über 1.000 ms: Die Aufmerksamkeit wandert ab. Der Nutzer beginnt, über die Wartezeit nachzudenken, wechselt möglicherweise den Kontext (anderer Tab, andere Aufgabe). Ab 10 Sekunden wird eine Interaktion häufig abgebrochen.
Beispiel: Eine Autovervollständigung in einem Suchfeld muss unter 100 ms reagieren, um als sofortig wahrgenommen zu werden. Dauert sie 500 ms, tippt der Nutzer weiter, bevor Vorschläge erscheinen. Die Funktion wird nutzlos.
Beispiel: Ein KI-Assistent mit Streaming-Ausgabe zeigt nach 300 ms die ersten Wörter an. Die Gesamtantwort dauert 8 Sekunden. Durch das frühe visuelle Feedback bleibt der Nutzer engagiert, obwohl die Gesamtdauer über der 1-Sekunden-Schwelle liegt. Streaming verschiebt die wahrgenommene Antwortzeit nach vorn.
Die Wahrnehmung hängt auch vom Kontext ab. Wer eine komplexe Datenanalyse anfordert, toleriert längere Wartezeiten als jemand, der eine einfache Faktenabfrage stellt. Die Erwartungshaltung bestimmt, welche Dauer als akzeptabel gilt.
Technische Ansätze zur Optimierung
Antwortzeiten lassen sich an verschiedenen Stellen der Verarbeitungskette reduzieren. Die wirksamsten Hebel hängen davon ab, welcher Abschnitt den größten Anteil an der Gesamtdauer hat.
Caching
Wenn dieselbe Anfrage wiederholt auftritt, kann das Ergebnis zwischengespeichert werden. Statt erneuter Berechnung liefert ein Cache die gespeicherte Antwort in Mikrosekunden. Bei KI-Systemen wird häufig ein KV-Cache (Key-Value-Cache) genutzt, der die Zwischenergebnisse des Attention-Mechanismus speichert. So müssen bei Folgeanfragen im selben Gespräch nicht alle vorherigen Tokens erneut verarbeitet werden.
Beispiel: Ein KI-Chatbot führt ein Gespräch mit 2.000 Tokens Kontext. Ohne KV-Cache müsste bei jeder neuen Nachricht der gesamte Kontext erneut verarbeitet werden. Mit KV-Cache wird nur die neue Nachricht durch die Prefill-Phase geschickt. Die TTFT sinkt von 1.200 ms auf 200 ms.
Quantisierung
Modellgewichte werden von 32-Bit-Gleitkommazahlen auf 8-Bit- oder 4-Bit-Ganzzahlen reduziert. Das verringert den Speicherbedarf und beschleunigt die Matrixmultiplikationen, die den Kern der Transformer-Architektur bilden. Die Antwortzeit sinkt, weil mehr Berechnungen in den schnellen GPU-Speicher passen und Speicherzugriffe reduziert werden.
Beispiel: Ein 70-Milliarden-Parameter-Modell benötigt in voller Präzision (FP16) rund 140 GB GPU-Speicher. Quantisiert auf 4 Bit passt es in 35 GB. Das ermöglicht den Betrieb auf einer einzelnen GPU statt auf vier, was Kommunikationsoverhead eliminiert und die Antwortzeit messbar senkt.
Batching
Mehrere Anfragen werden zu einem Stapel zusammengefasst und gemeinsam verarbeitet. Moderne Verfahren wie Continuous Batching fügen neue Anfragen dynamisch hinzu, sobald eine laufende Anfrage fertig ist. Das erhöht den Durchsatz (Anfragen pro Sekunde), kann aber die Antwortzeit einzelner Anfragen geringfügig erhöhen.
Beispiel: Ohne Batching verarbeitet ein System 10 Anfragen pro Sekunde bei 100 ms Antwortzeit pro Anfrage. Mit Batching (Batch-Größe 8) steigt der Durchsatz auf 60 Anfragen pro Sekunde, aber die Antwortzeit pro Anfrage erhöht sich auf 130 ms. Der Durchsatzgewinn überwiegt in den meisten Szenarien den leichten Anstieg der Einzelantwortzeit.
Geografische Verteilung
Rechenzentren in der Nähe der Nutzer reduzieren die Netzwerklatenz. Für KI-Modelle, die große GPU-Cluster erfordern, ist diese Option allerdings begrenzt: Nicht jedes Rechenzentrum verfügt über die nötige Hardware. Leichtgewichtige Modelle können hingegen am Netzwerkrand (Edge) betrieben werden.
Zielkonflikte: Antwortzeit gegen andere Größen
Schnellere Antwortzeiten stehen oft im Widerspruch zu anderen Systemzielen. Die Optimierung einer Größe verschlechtert eine andere. Diesen Zusammenhang zu verstehen, ist für fundierte technische Entscheidungen notwendig.
Antwortzeit gegen Antwortqualität: Größere Sprachmodelle liefern präzisere Antworten, rechnen aber länger. Ein Modell mit 7 Milliarden Parametern antwortet schneller als eines mit 70 Milliarden, erreicht aber bei komplexen Aufgaben geringere Trefferquoten. Die Wahl des Modells ergibt sich aus der konkreten Anwendung.
Beispiel: Eine Rechtschreibprüfung benötigt kein 70-Milliarden-Parameter-Modell. Ein kleines, spezialisiertes Modell prüft schneller und genauer. Eine juristische Analyse profitiert dagegen von der größeren Kapazität, auch wenn die Antwortzeit steigt.
Antwortzeit gegen Durchsatz: Batching erhöht die Anzahl verarbeiteter Anfragen pro Zeiteinheit, verzögert aber die einzelne Antwort. Systeme müssen zwischen niedriger Latenz (wenig Batching, teure Hardware) und hohem Durchsatz (viel Batching, effizientere Auslastung) abwägen.
Antwortzeit gegen Kosten: Schnellere Hardware (neuere GPU-Generationen, mehr Speicher, höhere Taktung) senkt die Antwortzeit, erhöht aber die Betriebskosten. Quantisierung bietet einen Kompromiss: geringerer Ressourcenverbrauch bei akzeptablem Qualitätsverlust.
Beispiel: Ein Unternehmen betreibt einen internen Wissensassistenten. Variante A nutzt ein kleines Modell auf einer GPU (p95-Antwortzeit: 500 ms, Kosten: 3.000 €/Monat). Variante B nutzt ein großes Modell auf vier GPUs (p95-Antwortzeit: 2.000 ms, Kosten: 18.000 €/Monat). Die Qualitätssteigerung von B rechtfertigt sich nur, wenn die Aufgaben hinreichend komplex sind.
Fachliche Einordnung: In der Systemarchitektur wird dieser Zielkonflikt als Latency-Throughput-Tradeoff beschrieben. Die theoretische Grenze bildet das Universal Scalability Law (USL) von Neil Gunther: Jenseits eines Optimums führt mehr Parallelität zu längerer Antwortzeit durch Koordinationsaufwand (Contention und Coherency). Dieses Modell gilt für KI-Inferenzsysteme ebenso wie für klassische Datenbanken.
Grenzen und Einordnung
Antwortzeit ist eine notwendige, aber keine hinreichende Metrik für Systemqualität. Ein System kann schnell antworten und trotzdem unbrauchbar sein, wenn die Antwort falsch, unvollständig oder irreführend ist. Umgekehrt kann eine längere Antwortzeit akzeptabel sein, wenn das Ergebnis präzise und vollständig ist.
Beispiel: Ein Sprachmodell antwortet in 200 ms mit einer faktisch falschen Zusammenfassung. Ein sorgfältiger arbeitendes Modell benötigt 3 Sekunden, liefert aber ein korrektes Ergebnis. Die Antwortzeit allein sagt nichts über den Nutzen aus.
Benchmarks für Antwortzeiten sind kontextabhängig. Die Anforderungen einer Echtzeit-Übersetzung (unter 200 ms) unterscheiden sich fundamental von denen einer Dokumentenanalyse (mehrere Sekunden akzeptabel). Pauschale Schwellenwerte wie "unter 1 Sekunde" sind daher nur als grobe Orientierung tauglich.
Die Messung selbst beeinflusst das Ergebnis. Monitoring-Systeme verbrauchen Rechenressourcen und erhöhen die Antwortzeit geringfügig. Bei hochfrequenten Systemen (Hunderttausende Anfragen pro Sekunde) kann dieser Overhead relevant werden. Sampling, also die Messung nur jeder n-ten Anfrage, reduziert den Aufwand auf Kosten der Präzision.
Beispiel: Ein Monitoring-System misst jede Anfrage und speichert die Ergebnisse in einer Zeitreihendatenbank. Bei 500.000 Anfragen pro Sekunde erzeugt das Monitoring selbst eine messbare Last. Ein Sampling von 1 % reduziert den Overhead, übersieht aber möglicherweise kurzzeitige Ausreißer.
Antwortzeit erfasst ausschließlich die Dauer. Sie sagt nichts über Verfügbarkeit (antwortet das System überhaupt?), Korrektheit (stimmt die Antwort?) oder Konsistenz (liefert das System bei gleicher Eingabe gleiche Ergebnisse?). Ein vollständiges Bild der Systemqualität erfordert die Kombination mehrerer Metriken.