Serverless-LLM-Inference in der Produktion: Leistungskennzahlen, die wirklich zählen

Wenn Teams serverlose LLM-Inference-Modelle und Plattformen vergleichen, wird die Diskussion häufig auf eine einzige Kennzahl reduziert: die mediane Anzahl generierter Tokens pro Sekunde. Dieser Wert lässt sich leicht veröffentlichen, einfach gegenüberstellen und ist für bestimmte Workloads tatsächlich die passende Größe zur Optimierung. Dennoch bleibt er nur ein einzelner Messpunkt. Für sich allein betrachtet beschreibt er nur einen kleinen Ausschnitt dessen, was „Performance“ bedeutet, sobald ein Inference-Workload produktiv betrieben wird.

Der Grund dafür liegt darin, dass unterschiedliche Workloads auch unterschiedliche Engpässe spüren. Ein nächtlicher Batch-Prozess zur Zusammenfassung von Inhalten ist auf dauerhaft hohen Durchsatz angewiesen, weshalb mediane Tokens pro Sekunde in diesem Fall ein sinnvoller Benchmark sein können. Eine Chat-Anwendung mit direkter Benutzerinteraktion hängt dagegen viel stärker davon ab, wie schnell das erste Token erscheint und wie konstant dieses Verhalten ist, nicht nur von der stabilen Ausgaberate. Ein produktiver Dienst mit echtem Traffic wird außerdem von den langsamsten Anfragen, der Fehlerrate und den Kosten pro vollständig erzeugter Antwort geprägt. All das bildet eine mediane Durchsatzkennzahl nicht ab. Wer die falsche Metrik optimiert, kann ein System bereitstellen, das im Benchmark hervorragend aussieht, sich in der Praxis aber schlecht anfühlt.

Dieser Beitrag erläutert die Kennzahlen, die für serverlose Inference im Produktivbetrieb wirklich relevant sind, was sie jeweils messen und welche Workloads besonders auf sie achten sollten. Ziel ist es, die Auswahl der passenden Messwerte für den jeweiligen Anwendungsfall zu erleichtern.

Wichtige Erkenntnisse

Benchmark-Ergebnisse zeigen, dass es keinen universell schnellsten Anbieter gibt. Die Leistung hängt stark vom jeweiligen Modell und der konkreten Arbeitslast ab. Ein Anbieter kann bei einem Modell – etwa Llama 3.3 70B – sehr schnell sein, bei einem anderen wie Gemma 4 jedoch deutlich langsamer. Aussagen über die Geschwindigkeit sind daher nur sinnvoll, wenn das getestete Modell und der Anwendungsfall klar angegeben werden.

Neben der Geschwindigkeit ist auch die Zuverlässigkeit entscheidend, wird in Benchmarks jedoch häufig vernachlässigt. Manche Anbieter stellen bestimmte Modelle nur über dedizierte Endpunkte bereit, während andere inkonsistentes Verhalten oder lange Cold Starts zeigen. Eine schnelle Antwortzeit bringt wenig, wenn das Modell nicht zuverlässig verfügbar ist.

Für Produktivsysteme ist eine konsistente Time-to-First-Token meist wertvoller als eine gelegentlich extrem niedrige Latenz bis zum ersten Token. Vorhersagbare Antwortzeiten über den gesamten Modellkatalog hinweg sind einer Umgebung vorzuziehen, in der dieselbe Anfrage mal in weniger als einer Sekunde und ein anderes Mal erst nach 24 Sekunden beantwortet wird. Nutzer nehmen vor allem diese langsamen Ausreißer wahr – nicht den Durchschnitt.

Der wichtigste Kostenfaktor ist häufig der tatsächliche Nutzen der Antwort im Verhältnis zur jeweiligen Aufgabe. Dieser wird in der Regel stärker durch die Wahl des passenden Modells beeinflusst als durch einen reinen Vergleich der Preislisten verschiedener Anbieter.

Durchsatz: Tokens pro Sekunde

Durchsatz beschreibt die stabile Geschwindigkeit, mit der ein Modell Tokens erzeugt, nachdem die Antwort begonnen hat. Genau diese Kennzahl steht in vielen öffentlichen Benchmarks an erster Stelle. Für bestimmte Workloads ist das sinnvoll. Ein Batch-Prozess, der über Nacht Produktdaten umschreibt, eine Pipeline, die große Mengen an Zusammenfassungen oder Embeddings erzeugt, oder ein anderer Offline-Prozess, bei dem kein Mensch aktiv wartet, ist durch dauerhaft erzeugte Tokens pro Sekunde begrenzt. In solchen Fällen kann ein Vergleich nach Durchsatz zur richtigen Entscheidung führen.

Throughput-Benchmarks betrachten häufig nur eine einzelne aktive Anfrage, was typischen Produktionstraffic jedoch nicht realistisch abbildet. Reale Anwendungen verarbeiten viele Anfragen parallel. Daher ist es sinnvoller, den Gesamtdurchsatz unter gleichzeitiger Last zu messen und zu beobachten, wie gleichmäßig die Performance pro Anfrage mit steigender Nachfrage abnimmt.

Auch die Modellarchitektur spielt eine wichtige Rolle. Mixture-of-Experts-Modelle können Tokens deutlich schneller erzeugen als Dense Models mit ähnlicher oder sogar höherer Parameteranzahl. Der Throughput hängt daher nicht nur vom Anbieter, sondern auch stark vom gewählten Modell ab.

Time to First Token und Stabilität

Bei interaktiven Anwendungen ist die Time to First Token, kurz TTFT, die Kennzahl, die Nutzer am unmittelbarsten wahrnehmen. In einer Streaming-Chat-Oberfläche beschreibt TTFT die Verzögerung zwischen dem Absenden einer Eingabe und dem Moment, in dem die Antwort sichtbar zu erscheinen beginnt. Ein Modell mit nur mittelmäßigem Durchsatz kann sich trotzdem sehr schnell anfühlen, wenn das erste Token zügig und vorhersehbar ausgegeben wird, insbesondere wenn Nutzer nicht auf die vollständig fertige Antwort warten müssen, bevor erste generierte Inhalte angezeigt werden.

Die Vorhersehbarkeit ist dabei der schwierigere Teil. Ein erstes Token, das normalerweise nach 0,2 Sekunden erscheint, gelegentlich aber acht Sekunden benötigt, erzeugt ein fehlerhaft wirkendes Nutzungserlebnis, selbst wenn der Median hervorragend aussieht. TTFT sollte deshalb als Spannweite gemessen werden, indem der Median mit dem 95. Perzentil verglichen wird. Die Differenz zwischen beiden zeigt genau den Teil der Nutzererfahrung, den der Median verdeckt.

Wenn TTFT über einen interaktiven Chat-Workload mit festen Prompts, temperature=0 und mindestens 25 Testläufen pro Modell gemessen wird, wobei drei Warmup-Anfragen verworfen werden, ist die Spanne zwischen Median und schlechtestem Fall besonders aussagekräftig. In einem repräsentativen Benchmark von einem Cloud-Server in einer New-York-Region zeigte ein Anbieter sowohl bei gpt-oss-120b mit 0,29 bis 0,35 Sekunden als auch bei einem Kimi-Reasoning-Modell mit unter 0,7 Sekunden im schlechtesten Fall eine sehr enge Median-bis-Worst-Case-Spanne. Über eine breitere Auswahl gängiger Modelle hinweg zeigte sich dasselbe Muster: typische und ungünstige First-Token-Zeiten lagen nur wenige hundert Millisekunden auseinander und blieben unter 0,4 Sekunden.

Tail Latency: p95 und p99

Während TTFT misst, ob eine Antwort schnell beginnt, zeigt Tail Latency, ob die gesamte Anfrage innerhalb des vorgesehenen Zeitbudgets abgeschlossen wird. Sie beschreibt die Ende-zu-Ende-Dauer der langsamsten Anfragen, üblicherweise gemessen am 95. und 99. Perzentil. Diese Werte sind die Grundlage für Service-Level-Ziele, HTTP-Timeouts und Kapazitätsplanung. Bei produktiven Traffic-Mengen ist der „Tail“ kein seltener Sonderfall, sondern ein vorhersehbarer Anteil der Anfragen in jeder Minute. Ein Anbieter mit ausgezeichnetem Median, aber starkem Tail kann daher unbemerkt das Latenzbudget sprengen, sobald der Traffic steigt.

Eine große Lücke zwischen Median und Tail Latency kann ein klares Signal für einen überlasteten oder instabilen Serving-Pfad sein. Plane mit p95 oder p99 und behandle einen großen Abstand zwischen Median und Tail nicht als Rundungsfehler, sondern als Warnhinweis für die Zuverlässigkeit.

Zuverlässigkeit und Verfügbarkeit

Geschwindigkeit ist bedeutungslos, wenn eine Anfrage fehlschlägt, keine nutzbare Ausgabe liefert oder das gewünschte Modell gar nicht erst aufgerufen werden kann. Verfügbarkeit beschreibt, ob ein Modell über serverlose Inference nutzbar ist, ohne dafür dedizierte Infrastruktur bereitstellen zu müssen.

Zuverlässigkeit ist die zweite Dimension. Sie zeigt, ob Anfragen erfolgreich abgeschlossen werden, sobald das Modell grundsätzlich erreichbar ist. Benchmarke immer das konkrete Modell, das tatsächlich eingesetzt werden soll, denn etablierte Modelle können auf einer ausgereiften Plattform stabil laufen, während neue oder sehr spezialisierte Modelle weiterhin Verfügbarkeits- und Zuverlässigkeitsprobleme aufweisen können.

Kosten pro nützlichem Ergebnis

Beim Vergleich verschiedener Modelltypen ist die richtige Kostenkennzahl nicht einfach der Preis pro Million Tokens aus einer Preistabelle. Aussagekräftiger sind die Kosten für eine nützliche, vollständig erzeugte Antwort bei den Tokenmengen, die der jeweilige Workload tatsächlich produziert. Entscheidend sind vor allem Modellauswahl und Routing-Fähigkeiten, insbesondere der Unterschied zwischen Standardmodellen und Reasoning-Modellen. Reasoning-Modelle erzeugen häufig einen längeren internen Denkprozess, bevor die sichtbare Antwort entsteht. Diese Thinking Tokens werden als Output berechnet. Dadurch kann eine Antwort, die sichtbar nur einige hundert Tokens umfasst, tatsächlich wie mehrere tausend Tokens abgerechnet werden.

Bei der Messung der Kosten einer einzelnen abgeschlossenen Chat-Antwort zeigen sich zwei Muster. Innerhalb desselben Modells liegen Anbieter häufig nur wenige Prozent auseinander. Eine abgeschlossene gpt-oss-120b-Antwort kann etwa 0,00017 bis 0,00019 US-Dollar kosten, während eine Antwort eines Reasoning-Modells ungefähr 1,5 bis 1,7 Cent kosten kann. Zwischen verschiedenen Modellen kann der Unterschied jedoch ungefähr beim Faktor 230 liegen, von 0,00006 US-Dollar bei einem kleineren Modell bis zu etwa eineinhalb Cent bei einem Reasoning-Modell. Die Anbieterwahl verschiebt die Antwortkosten oft nur um wenige Prozent, während die Modellwahl sie um Größenordnungen verändern kann. Der stärkste Kostenhebel ist deshalb die Zuordnung des passenden Modells zur jeweiligen Aufgabe.

Daraus ergibt sich eine Architektur mit aufgabenbasiertem Routing. Standardanfragen sollten an ein schnelles und günstiges Mainstream-Modell gehen. Nur Aufgaben, die tatsächlich Reasoning benötigen, sollten an ein Reasoning-Modell weitergeleitet werden. Die Anbieterwahl sollte dabei als nachgelagerte Entscheidung betrachtet werden. Eine Routing-Schicht kann helfen, diesen Prozess automatisch zu steuern.

Cold Starts und Burst-Verhalten

Serverlose Inference bringt eine Kennzahl mit sich, die dedizierte Deployments meist nicht haben: den Cold Start. Wenn ein Endpunkt längere Zeit inaktiv war oder für einen Lastanstieg skaliert werden muss, zahlen die ersten Anfragen oft eine Bereitstellungsverzögerung. Bei sprunghaftem Traffic sind genau diese ersten Anfragen häufig die, die von den Nutzern kommen.

Diese Kennzahl misst die First-Token-Zeit aus einem kalten Zustand und während Lastspitzen. Wenn dein Traffic unregelmäßig oder bursty ist, sollte geprüft werden, ob die Plattform Keep-Warm-Verhalten oder bereitgestellte Kapazitäten anbietet. Teste den Übergang ausdrücklich, statt davon auszugehen, dass Warm-Path-Benchmarkwerte auch in diesen Situationen gelten.

Ausgabequalität und Ergebnisvalidität

Eine Anfrage kann HTTP 200 zurückgeben und trotzdem unbrauchbar sein. Output Fidelity misst, ob die Antwort korrekt, vollständig und qualitativ wie erwartet ist. Diese Dimension ist in Latenz- und Durchsatzdiagrammen nicht sichtbar. Dazu kann auch stille Kürzung gehören. In manchen Fällen kann ein Reasoning-Modell mit einem üblichen Tokenbudget für Antworten das gesamte Budget für internes Denken verbrauchen und anschließend eine leere Antwort zurückgeben. Technisch gesehen war die Anfrage erfolgreich, das Ergebnis ist jedoch nicht nutzbar.

Ein weiteres mögliches Problem ist Quantisierung. Manche Anbieter stellen Modelle in reduzierter Präzision bereit, etwa FP8 oder FP4. Das kann die Ausgabequalität verändern, ohne dass sich die API ändert. Außerdem wird dies nicht immer klar offengelegt.

Diese Kennzahl prüft, ob die Ausgabe für die Aufgabe gültig ist, nicht nur, ob die API einen erfolgreichen Statuscode zurückliefert. Bei Reasoning-Modellen bedeutet das, genügend Tokens einzuplanen, damit das Modell die eigentliche Antwort erreichen kann. Bei jedem Modell bedeutet es, die bereitgestellte Präzision zu kennen und die Qualität regelmäßig stichprobenartig zu prüfen.

Operative Passung

Die letzte Kennzahl ist weniger numerisch, bestimmt aber häufig den Integrationsaufwand: Wie gut passt die Plattform zur eigenen Entwicklungs- und Betriebsweise? Die meisten Anbieter stellen eine OpenAI-kompatible API bereit, wodurch ein Wechsel mitunter nur das Ändern einer Base URL erfordert. Kompatibilität geht jedoch über die Form des Endpunkts hinaus. Entscheidend ist auch, ob übergebene Parameter tatsächlich beachtet werden. Eine Anfrage, die den Reasoning-Modus eines Modells deaktivieren soll, kann von einem Anbieter respektiert und von einem anderen stillschweigend ignoriert werden.

Ebenso wichtig sind korrekt vom Server gemeldete Token-Nutzungsdaten für Abrechnung und Monitoring, zuverlässiges Streaming-Verhalten, Optionen für Region und Datenresidenz sowie Nutzungsbedingungen, die den jeweiligen Anwendungsfall erlauben. Ein kompatibel wirkender Endpunkt ist nicht automatisch eine kompatibel arbeitende Plattform. Deshalb sollten die Verhaltensweisen geprüft werden, von denen die eigene Anwendung abhängt.

Die passenden Kennzahlen für den eigenen Workload auswählen

Die genannten Kennzahlen sind keine Rangliste, die gleichzeitig optimiert werden sollte. Sie bilden vielmehr eine Auswahl, aus der je nach Anwendung die relevanten Messwerte gewählt werden. Der Workload entscheidet, welche Zahlen ausschlaggebend sind und welche eher Hintergrundrauschen darstellen.

Der mediane Single-Stream-Durchsatz ist die Kennzahl, die in vielen Vergleichen zuerst hervorgehoben wird. Für genau einen dieser Workloads ist sie entscheidend, für die übrigen eher zweitrangig. Sie ist weiterhin eine nützliche Kennzahl, aber nicht die einzige. Für die meisten produktiven Deployments ist sie auch nicht die wichtigste.

FAQ

Welche Kennzahl ist für serverlose Inference am wichtigsten?

Es gibt keine einzelne Kennzahl, die in jedem Fall am wichtigsten ist. Die passende Metrik hängt vom jeweiligen Workload ab. Interaktive Chat-Anwendungen priorisieren eine stabile Time-to-First-Token und hohe Zuverlässigkeit. Batch-Pipelines konzentrieren sich auf dauerhaft hohen Durchsatz unter Parallelität sowie Kosten pro Ergebnis, während RAG-Systeme besonders stark von der Prefill-Latenz bei langen Prompts beeinflusst werden.

Der Median der Tokens pro Sekunde ist ein nützlicher Ausgangswert, in den meisten Produktionsumgebungen jedoch nicht der entscheidende Hauptfaktor.

Warum sollte p95-Latenz statt nur der Median betrachtet werden?

Der Median beschreibt eine typische Anfrage, während p95 zeigt, wie sich langsamere Nutzererfahrungen darstellen. Bei relevantem Traffic können fünf Prozent der Anfragen Tausende Interaktionen ausmachen. Ein Anbieter kann bei p50 hervorragend aussehen und bei p95 dennoch für den Produktivbetrieb ungeeignet sein.

Kosten Reasoning-Modelle bei serverloser Inference mehr?

Ja, häufig deutlich mehr, als die Listenpreise vermuten lassen. Reasoning-Modelle erzeugen Thinking Tokens, bevor die sichtbare Antwort entsteht, und diese Tokens werden als Output berechnet. In diesem Benchmark kostete ein Reasoning-Modell pro Chat-Anfrage ungefähr 230-mal mehr als ein kleines Instruct-Modell, obwohl die Preise pro Token deutlich weniger stark auseinanderlagen. Vergleiche deshalb immer die Kosten pro abgeschlossener Antwort und nicht nur die Kosten pro Million Tokens.

Warum unterscheiden sich Benchmark-Ergebnisse zwischen Anbietern beim gleichen Modell so stark?

Anbieter verwenden unterschiedliche Hardware, Batching-Strategien und Quantisierungsstufen. Die konkrete Präzision wird nicht immer offengelegt. Auch die Bereitstellung der Serving-Pools spielt eine große Rolle. Ein Anbieter kann bei seinen bekanntesten Modellen sehr schnell sein, während ein Nischenmodell auf derselben Plattform deutlich langsamer läuft. Rangfolgen können sich je nach getestetem Modell vollständig drehen. Deshalb sollte immer das konkrete Modell benchmarked werden, das später bereitgestellt werden soll.

Wie viele Testläufe sind für einen belastbaren Benchmark notwendig?

Führe für jede Kombination aus Modell und Szenario mindestens 25 gemessene Durchläufe aus. Entferne zuvor einige Warm-up-Anfragen, setze die Temperatur auf 0 und verwende feste Prompts, damit die Ergebnisse vergleichbar bleiben. Diese Anzahl an Durchläufen reicht in der Regel aus, um einen stabilen p50-Wert und einen brauchbaren, richtungsweisenden p95-Wert zu berichten. Zusätzlich ist es hilfreich, Messungen über mehrere Zeitfenster hinweg zu sammeln.

Fazit

Die Leistung serverloser Inferenz lässt sich nicht mit einer einzigen Kennzahl erfassen. Zwar wird häufig der Median der Tokens pro Sekunde angegeben, dieser spiegelt jedoch in erster Linie den Batch-Durchsatz wider und weniger die Performance in realen Produktionsumgebungen. In der Praxis sind Metriken wie die Modellverfügbarkeit, die Konsistenz der **Time-to-First-Token (TTFT)** unter Last, die **Tail-Latenz** im 95. Perzentil sowie die tatsächlichen Kosten pro Antwort – unter Berücksichtigung realistischer Promptgrößen und Reasoning-Tokens – deutlich aussagekräftiger.

In unseren Benchmarks lieferten diese produktionsorientierten Kennzahlen die zuverlässigsten Erkenntnisse. Eine katalogweite First-Token-Latenz, die nur um wenige Hundert Millisekunden schwankt, lässt sich in der Regel nur mit gut dimensionierter und dauerhaft vorgewärmter Serving-Infrastruktur erreichen. Umgekehrt weisen hohe Tail-Latenzen und eingeschränkt verfügbar gemachte Modelle häufig auf begrenztere Ressourcenbereitstellung hin. Bevor du dich für einen Anbieter entscheidest, solltest du ihn daher mit deinem eigenen Workload testen, mehrere Hundert Anfragen senden und die Latenz-Perzentile auswerten. Solche Messungen liefern deutlich aussagekräftigere Einblicke in die tatsächliche Leistungsfähigkeit der Infrastruktur als Preislisten oder einzelne Benchmark-Zahlen.