Wichtige Leistungskennzahlen für produktive serverlose LLM-Inferenz

Wenn Teams serverlose LLM-Inferenzmodelle und Plattformen miteinander vergleichen, konzentriert sich die Bewertung häufig auf einen einzigen Wert: die mediane Anzahl an Tokens pro Sekunde. Diese Kennzahl lässt sich leicht veröffentlichen, unkompliziert vergleichen und ist für bestimmte Workloads durchaus sinnvoll. Sie stellt jedoch nur eine von mehreren relevanten Messgrößen dar und zeigt lediglich einen begrenzten Ausschnitt dessen, was Leistung in einer produktiven Umgebung tatsächlich bedeutet.

Je nach Workload treten unterschiedliche Engpässe auf. Ein regelmäßig ausgeführter Batch-Prozess zur Zusammenfassung von Inhalten ist auf einen dauerhaft hohen Durchsatz angewiesen. Deshalb kann die mediane Tokenrate dafür eine geeignete Kennzahl sein. Bei einer benutzerorientierten Chat-Anwendung ist dagegen entscheidender, wie schnell das erste Token erscheint und wie konstant diese Reaktionszeit bleibt. Ein Produktivdienst mit realem Datenverkehr muss zusätzlich langsame Anfragen, Fehlerraten und die Kosten jeder vollständig erzeugten Antwort berücksichtigen. Diese Faktoren werden durch den medianen Durchsatz allein nicht ausreichend abgebildet. Wer die falsche Kennzahl optimiert, kann ein System entwickeln, das in Benchmarks hervorragend abschneidet, sich im praktischen Einsatz jedoch schlecht verhält.

Dieser Artikel erläutert die Kennzahlen, die für produktive serverlose Inferenz relevant sind, beschreibt ihre jeweilige Bedeutung und zeigt, für welche Workloads sie besonders wichtig sind. Ziel ist es, die Messgrößen auszuwählen, die zum konkreten Anwendungsfall passen.

Die wichtigsten Erkenntnisse

Nach Tests zahlreicher Modelle auf unterschiedlichen Plattformen wird deutlich, dass es keinen Anbieter gibt, der grundsätzlich am schnellsten ist. Die Rangfolge verändert sich abhängig vom getesteten Modell. Eine Plattform kann ein bestimmtes großes Sprachmodell dreimal schneller bereitstellen und bei einem anderen Modell gleichzeitig fünfmal langsamer sein. Die Aussage, ein bestimmter Anbieter sei der schnellste, bleibt daher unvollständig, solange weder das Modell noch der Workload genannt werden.

Die Verfügbarkeit ist eine entscheidende Kennzahl, die in vielen Benchmarks nicht berücksichtigt wird. Einige Plattformen stellen bestimmte Modelle nur über dedizierte Endpunkte bereit, während andere einzelne Modelle unregelmäßig ausführen oder lange Kaltstartzeiten verursachen. Ein Modell, das bei erfolgreicher Ausführung sehr schnell ist, besitzt nur geringen praktischen Nutzen, wenn es nicht zuverlässig aufgerufen werden kann.

Die Stabilität der Zeit bis zum ersten Token ist wichtiger als der schnellste einzelne Messwert. Für die meisten Produktivanwendungen ist eine gleichmäßige Time-to-First-Token über einen gesamten Modellkatalog hinweg wertvoller als Reaktionszeiten, die zwischen weniger als einer Sekunde und mehr als 20 Sekunden schwanken. Benutzer nehmen insbesondere die langsamsten Anfragen wahr und nicht nur den Median.

Die Kosten pro nutzbarer Antwort gehören zu den wichtigsten Messgrößen. Sie werden stärker durch die Wahl des Modells als durch den veröffentlichten Tokenpreis einer Plattform beeinflusst. Das passende Modell für eine Aufgabe auszuwählen, wirkt sich in der Regel stärker auf die Gesamtkosten aus als die Entscheidung zwischen verschiedenen Plattformen.

Durchsatz: Tokens pro Sekunde

Der Durchsatz beschreibt die konstante Geschwindigkeit, mit der ein Modell nach Beginn der Generierung Tokens ausgibt. Gleichzeitig ist dies die Kennzahl, die in öffentlichen Benchmarks am häufigsten hervorgehoben wird. Für bestimmte Workloads ist das sinnvoll. Ein Batch-Prozess, der über Nacht Produktinformationen überarbeitet, eine Pipeline, die große Mengen an Zusammenfassungen oder Embeddings erstellt, oder jede andere Offline-Aufgabe ohne wartende Benutzer hängt stark von einer dauerhaft hohen Tokenproduktion ab. In solchen Fällen kann ein Vergleich der Plattformen anhand des Durchsatzes zu einer sinnvollen Entscheidung führen.

Der Durchsatz wird häufig anhand eines einzelnen Anfragestroms gemessen. Produktivsysteme arbeiten jedoch nur selten auf diese Weise. Reale Anwendungen senden mehrere Anfragen gleichzeitig. Daher ist der aggregierte Durchsatz unter paralleler Last aussagekräftiger. Zusätzlich sollte gemessen werden, wie stark die Geschwindigkeit einzelner Anfragen sinkt, wenn das Verkehrsaufkommen zunimmt.

Auch die Modellarchitektur beeinflusst den Durchsatz. Mixture-of-Experts-Modelle können Tokens deutlich schneller erzeugen als dichte Modelle mit vergleichbarer oder sogar größerer Modellgröße. Der Durchsatz ist deshalb nicht nur bei der Auswahl einer Plattform relevant, sondern ebenso bei der Wahl des Modells.

Zeit bis zum ersten Token und Stabilität der Antwort

Bei interaktiven Anwendungen ist die Zeit bis zum ersten Token, häufig als TTFT bezeichnet, die Kennzahl, die Benutzer am unmittelbarsten wahrnehmen. In einer streamenden Chat-Oberfläche beschreibt TTFT die Verzögerung zwischen dem Absenden einer Eingabe und dem sichtbaren Beginn der Antwort. Selbst ein Modell mit durchschnittlichem dauerhaftem Durchsatz kann sehr reaktionsschnell wirken, wenn das erste Token schnell und zuverlässig erscheint. Das gilt besonders dann, wenn Benutzer den generierten Text bereits lesen können, bevor die vollständige Antwort abgeschlossen ist.

Die Konstanz ist der anspruchsvollere Teil dieser Messung. Wenn das erste Token üblicherweise nach 0,2 Sekunden erscheint, gelegentlich jedoch acht Sekunden benötigt, entsteht trotz eines hervorragenden Medianwerts ein unzuverlässiges Nutzungserlebnis. TTFT sollte deshalb als Verteilung und nicht als einzelner Wert betrachtet werden. Der Vergleich zwischen Median und 95. Perzentil macht Schwankungen sichtbar, die durch den Median verborgen bleiben.

Für die Messung der TTFT bei einem interaktiven Chat-Workload sollten feste Prompts verwendet, temperature=0 gesetzt und mindestens 25 Messdurchläufe pro Modell durchgeführt werden. Mehrere Aufwärmanfragen sollten dabei vor der eigentlichen Auswertung verworfen werden. Die Differenz zwischen dem Median und dem langsamsten beobachteten Ergebnis zählt häufig zu den aussagekräftigsten Werten.

Gut ausgestattete Plattformen können die mediane und die schlechteste Zeit bis zum ersten Token sowohl bei gängigen Modellen als auch bei Reasoning-Modellen innerhalb weniger hundert Millisekunden halten. Eine solche enge Spanne ist häufig wertvoller als ein außergewöhnlich schneller Median in Verbindung mit unvorhersehbaren Verzögerungen.

Tail-Latenz: p95 und p99

Die Zeit bis zum ersten Token zeigt, ob eine Antwort zügig beginnt. Die Tail-Latenz misst dagegen, ob die vollständige Anfrage innerhalb des vorgesehenen Zeitrahmens abgeschlossen wird. Sie beschreibt die gesamte Verarbeitungsdauer der langsamsten Anfragen und wird üblicherweise als 95. oder 99. Perzentil angegeben.

Service-Level-Ziele, HTTP-Zeitüberschreitungen und Kapazitätsplanungen werden in der Regel an der Tail-Latenz ausgerichtet. Bei produktivem Datenverkehr sind langsame Anfragen keine seltenen Ausnahmen. Sie stellen einen vorhersehbaren Anteil aller Anfragen innerhalb eines bestimmten Zeitraums dar. Eine Plattform mit einem hervorragenden Median, aber einer ungünstigen Latenzverteilung, kann das vorgesehene Zeitbudget einer Anwendung bereits bei steigendem Verkehrsaufkommen überschreiten.

Ein großer Unterschied zwischen Median- und Tail-Latenz kann auf einen überlasteten oder unzureichend ausgestatteten Verarbeitungspfad hinweisen. Die Kapazitätsplanung sollte deshalb auf p95- oder p99-Werten basieren. Eine breite Spanne zwischen Median und Tail sollte als Zuverlässigkeitsproblem und nicht als unbedeutende Abweichung behandelt werden.

Zuverlässigkeit und Verfügbarkeit

Geschwindigkeit besitzt nur geringen Wert, wenn eine Anfrage fehlschlägt, keine brauchbare Ausgabe liefert oder ein nicht verfügbares Modell aufruft. Die Verfügbarkeit beschreibt, ob das benötigte Modell über einen serverlosen Dienst verwendet werden kann, ohne dafür eine dedizierte Infrastruktur bereitstellen zu müssen.

Die Zuverlässigkeit gibt an, ob Anfragen nach der Verfügbarkeit des Modells erfolgreich abgeschlossen werden. Jedes Modell, das später eingesetzt werden soll, sollte separat getestet werden. Etablierte Modelle können auf einer ausgereiften Plattform zuverlässig funktionieren, während neuere oder seltener verwendete Modelle durch schwankende Verfügbarkeit, längere Startzeiten oder höhere Fehlerraten auffallen können.

Kosten pro nutzbarem Ergebnis

Beim Vergleich unterschiedlicher Modellarten ist der veröffentlichte Preis pro Million Tokens nicht die aussagekräftigste Kostenkennzahl. Relevanter sind die Gesamtkosten einer vollständigen und nutzbaren Antwort bei den Prompt- und Ausgabelängen, die im realen Workload tatsächlich entstehen.

Die Wahl des Modells und die Möglichkeiten zur Weiterleitung von Anfragen bestimmen die Kosten besonders stark. Das gilt vor allem beim Vergleich von Standardmodellen mit Reasoning-Modellen. Reasoning-Modelle können vor der sichtbaren Antwort eine umfangreiche interne Verarbeitung erzeugen. Diese Reasoning-Tokens werden üblicherweise als Ausgabetokens berechnet. Dadurch kann eine sichtbare Antwort mit nur wenigen hundert Tokens Kosten für mehrere tausend generierte Tokens verursachen.

Bei Kostenmessungen vollständiger Chat-Antworten zeigen sich im Allgemeinen zwei Muster. Für dasselbe Modell bleiben die Preisunterschiede zwischen verschiedenen Plattformen häufig in einem relativ kleinen Bereich. Zwischen unterschiedlichen Modellen können die Gesamtkosten einer vollständigen Antwort dagegen um mehr als zwei Größenordnungen variieren.

Die Wahl der Plattform kann die Kosten einer Antwort um einige Prozentpunkte verändern. Die Modellwahl kann sie dagegen um ein Vielfaches erhöhen oder reduzieren. Die wirksamste Kostenstrategie besteht daher darin, das Modell gezielt an die jeweilige Aufgabe anzupassen.

Eine praktische Architektur leitet Anfragen entsprechend ihrer Komplexität weiter. Gewöhnliche Aufgaben werden an ein schnelles und kostengünstiges Universalmodell gesendet. Nur Probleme, die tatsächlich eine erweiterte Schlussfolgerung erfordern, werden an ein Reasoning-Modell übergeben. Die Auswahl der Plattform wird dadurch zu einer nachgeordneten Entscheidung. Ein System zur automatischen Inferenzweiterleitung kann diesen Prozess übernehmen.

Kaltstarts und Verhalten bei Lastspitzen

Serverlose Inferenz führt eine Kennzahl ein, die bei dauerhaft bereitgestellten Installationen üblicherweise keine vergleichbare Rolle spielt: den Kaltstart. War ein Endpunkt längere Zeit inaktiv oder muss er aufgrund eines plötzlichen Anstiegs des Datenverkehrs skaliert werden, können die ersten Anfragen durch die Bereitstellung zusätzlicher Infrastruktur verzögert werden. Bei Anwendungen mit unregelmäßigem Verkehrsaufkommen betreffen diese Verzögerungen häufig genau die Anfragen aktiver Benutzer.

Diese Kennzahl misst die Zeit bis zum ersten Token bei einem kalten Dienst sowie während unerwarteter Lastspitzen. Anwendungen mit stark schwankendem Datenverkehr sollten prüfen, ob eine Plattform Funktionen zum Warmhalten oder reservierte Kapazitäten anbietet. Der Übergang vom inaktiven Zustand zum aktiven Betrieb sollte ausdrücklich getestet werden. Es sollte nicht davon ausgegangen werden, dass die Benchmark-Ergebnisse eines bereits aufgewärmten Dienstes unverändert gelten.

Qualität und Verwendbarkeit der Ausgabe

Eine Anfrage kann den HTTP-Status 200 zurückgeben und dennoch keinen praktischen Nutzen bieten. Die Ausgabequalität bewertet, ob eine Antwort korrekt, vollständig und für die vorgesehene Aufgabe geeignet ist. Diese Informationen sind in Diagrammen zu Latenz oder Durchsatz nicht erkennbar.

Ein mögliches Problem ist die unbemerkte Kürzung einer Antwort. Erhält ein Reasoning-Modell ein Tokenlimit, das lediglich für eine normale Antwort ausgelegt ist, kann es das gesamte Kontingent während seiner internen Verarbeitung verbrauchen und anschließend keine sichtbare Antwort mehr liefern. Technisch kann die Anfrage dennoch als erfolgreich gelten, obwohl kein verwertbares Ergebnis vorhanden ist.

Eine weitere mögliche Einschränkung ist die Quantisierung. Manche Plattformen stellen Modelle mit reduzierter numerischer Genauigkeit bereit, beispielsweise als FP8- oder FP4-Variante. Solche Versionen können die Qualität der Ausgabe verändern, ohne dass sich die API-Schnittstelle unterscheidet. Der verwendete Präzisionsgrad wird dabei nicht immer eindeutig offengelegt.

Die Ausgabequalität zeigt, ob ein Ergebnis für den jeweiligen Workload geeignet ist, anstatt lediglich zu bestätigen, dass der API-Aufruf technisch erfolgreich war. Reasoning-Modelle benötigen ausreichende Tokenlimits, um sowohl die interne Verarbeitung als auch die sichtbare Antwort abzuschließen. Bei jedem Modell sollten Teams den bereitgestellten Präzisionsgrad kennen und regelmäßig Beispielausgaben auf ihre Qualität überprüfen.

Operative Eignung

Die letzte Kennzahl ist weniger numerisch, kann jedoch den größten Einfluss auf den Integrationsaufwand haben: die Frage, wie gut eine Plattform zu den Entwicklungs- und Betriebsanforderungen einer Anwendung passt.

Viele Plattformen stellen eine API bereit, die mit einer verbreiteten Schnittstelle für Sprachmodelle kompatibel ist. Dadurch kann ein Wechsel des Dienstes häufig durch die Änderung einer Basis-URL erfolgen. Die Kompatibilität geht jedoch über die reine Struktur des Endpunkts hinaus. Es muss geprüft werden, ob übermittelte Anfrageparameter tatsächlich berücksichtigt werden. Ein Parameter, der den Reasoning-Modus eines Modells deaktivieren soll, kann auf einer Plattform korrekt funktionieren und auf einer anderen unbemerkt ignoriert werden.

Weitere betriebliche Aspekte sind eine genaue, serverseitig gemeldete Tokennutzung für Abrechnung und Überwachung, ein zuverlässiges Streaming-Verhalten, regionale Bereitstellungs- und Datenresidenzoptionen sowie Nutzungsbedingungen, die den geplanten Anwendungsfall erlauben.

Ein auf Endpunktebene kompatibler Dienst ist nicht automatisch eine betrieblich kompatible Plattform. Sämtliche Verhaltensweisen, von denen eine Anwendung abhängt, sollten daher direkt geprüft werden.

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

Die beschriebenen Kennzahlen sollten nicht alle gleichermaßen optimiert werden. Sie bilden eine Auswahl an Messgrößen, aus der Teams abhängig vom Verhalten ihrer Anwendung wählen sollten. Der konkrete Workload bestimmt, welche Werte entscheidend sind und welche nur eine begrenzte praktische Aussagekraft besitzen.

Der mediane Durchsatz eines einzelnen Anfragestroms ist die Kennzahl, die in Plattformvergleichen am häufigsten hervorgehoben wird. Sie ist jedoch nur für eine dieser Workload-Kategorien die wichtigste Messgröße und für die übrigen lediglich von nachrangiger Bedeutung. Der Wert bleibt nützlich, ist aber nicht die einzige relevante Kennzahl und bei produktiven Bereitstellungen nur selten die entscheidende.

Häufig gestellte Fragen

Welche Kennzahl ist für serverlose Inferenz am wichtigsten?

Es gibt keine einzelne Kennzahl, die für jeden Workload gleichermaßen wichtig ist. Interaktive Chat-Anwendungen benötigen eine stabile Zeit bis zum ersten Token und eine hohe Zuverlässigkeit der Anfragen. Batch-Pipelines legen den Schwerpunkt auf einen dauerhaft hohen Durchsatz unter paralleler Last sowie auf die Kosten pro vollständigem Ergebnis. Systeme für Retrieval-Augmented Generation reagieren bei langen Prompts besonders empfindlich auf die Prefill-Latenz. Die mediane Anzahl an Tokens pro Sekunde ist ein sinnvoller Ausgangswert, stellt für die meisten Produktivsysteme jedoch nicht den entscheidenden Faktor dar.

Warum sollte die p95-Latenz statt ausschließlich des Medians gemessen werden?

Der Median beschreibt eine typische Anfrage. p95 zeigt dagegen die Erfahrung der langsamsten fünf Prozent aller Anfragen. Bei einem hohen Verkehrsaufkommen können fünf Prozent mehreren tausend Benutzerinteraktionen entsprechen. Eine Plattform kann bei p50 sehr gute Ergebnisse erzielen und bei p95 dennoch für den produktiven Einsatz ungeeignet sein.

Verursachen Reasoning-Modelle bei serverloser Inferenz höhere Kosten?

Ja. Die tatsächlichen Betriebskosten können deutlich höher sein, als der veröffentlichte Tokenpreis zunächst vermuten lässt. Reasoning-Modelle erzeugen vor der sichtbaren Antwort interne Reasoning-Tokens, die als Ausgabe berechnet werden. In Benchmark-Szenarien kann ein Reasoning-Modell pro Chat-Anfrage mehr als 200-mal so viel kosten wie ein kleines, anweisungsorientiertes Modell, obwohl sich die veröffentlichten Tokenpreise deutlich weniger unterscheiden. Deshalb sollten die Kosten pro vollständiger Antwort und nicht nur pro Million Tokens verglichen werden.

Warum können sich Benchmark-Ergebnisse für dasselbe Modell zwischen Plattformen stark unterscheiden?

Plattformen verwenden unterschiedliche Hardwarekonfigurationen, Batching-Verfahren, Bereitstellungsstrategien und Quantisierungsstufen. Der Präzisionsgrad wird nicht immer offengelegt. Auch die Zuweisung von Ressourcen beeinflusst die Leistung. Eine Plattform kann bei ihren beliebtesten Modellen sehr gute Ergebnisse liefern und bei einem seltener verwendeten Modell auf demselben Dienst deutlich langsamer sein. Die Rangfolge der Plattformen kann sich abhängig vom getesteten Modell vollständig verändern. Teams sollten deshalb genau das Modell testen, das sie später einsetzen möchten.

Wie viele Testdurchläufe sind für einen zuverlässigen Benchmark erforderlich?

Für jede Kombination aus Modell und Szenario sollten mindestens 25 gemessene Durchläufe durchgeführt werden. Vor der Erfassung der Ergebnisse sollten mehrere Aufwärmanfragen verworfen, die Temperatur auf 0 gesetzt und feste Prompts verwendet werden, damit die einzelnen Durchläufe vergleichbar bleiben. Diese Stichprobengröße reicht im Allgemeinen aus, um einen stabilen p50-Wert und einen aussagekräftigen p95-Richtwert zu erhalten. Zusätzlich sollten die Tests zu mehreren unterschiedlichen Zeitpunkten wiederholt werden.

Fazit

Die Leistung serverloser Inferenz lässt sich nicht durch eine einzige Zahl darstellen. Die am häufigsten genannte Kennzahl, die mediane Anzahl an Tokens pro Sekunde, beantwortet in erster Linie die Frage nach dem Durchsatz bei Batch-Prozessen. Entscheidungen über produktive Bereitstellungen werden üblicherweise durch andere Messgrößen bestimmt.

Zu den wichtigen Kennzahlen für den Produktivbetrieb gehören die zuverlässige Verfügbarkeit des benötigten Modells, eine stabile Latenz bis zum ersten Token unter realistischem Datenverkehr, das Verhalten der langsamsten fünf Prozent aller Anfragen sowie die tatsächlichen Kosten einer vollständigen Antwort unter Berücksichtigung von Reasoning-Tokens und realen Promptgrößen.

Leistungsfähige Plattformen für serverlose Inferenz halten die Schwankungen der Zeit bis zum ersten Token über ihren gesamten Modellkatalog hinweg gering. Dieses Verhalten deutet auf ausreichend bereitgestellte Infrastruktur und aktiv verfügbare Verarbeitungskapazitäten hin. Breite Latenzverteilungen, nicht erreichbare Modelle und unvorhersehbare Startverzögerungen können dagegen auf eine unzureichende Ausstattung hindeuten.

Vor der Auswahl einer Plattform sollten mehrere hundert Streaming-Anfragen mit dem tatsächlichen Workload der Anwendung ausgeführt und die daraus resultierenden Perzentile ausgewertet werden. Diese Messungen geben einen aussagekräftigeren Einblick in die Infrastruktur hinter einem Endpunkt als eine veröffentlichte Preisliste oder ein einzelner hervorgehobener Benchmark-Wert.