CNCF: Goodput-Metrik zeigt fast 10× schlechtere p95-Latenz bei durchsatzoptimiertem LLM-Serving

Was ist Goodput und warum unterscheidet es sich vom Durchsatz?

Goodput misst die Anzahl abgeschlossener Anfragen pro Sekunde, die eine vordefinierte Ziel-Latenz einhalten, während Durchsatz alle verarbeiteten Anfragen zählt, unabhängig davon, ob sie schnell genug sind. Akamas-Ingenieur Graziano Casto zeigt im CNCF-Blog, dass höherer Durchsatz nicht zwangsläufig besseren Service bedeutet — eine Konfiguration kann insgesamt mehr Anfragen verarbeiten, aber einen Teil davon mit inakzeptabel langer Latenz für den Endnutzer.

Benchmark: 50 % höherer Durchsatz bei fast 10× schlechterer Latenz

Ein Test am Modell Qwen2.5-7B, auf einer einzelnen NVIDIA-A10G-GPU innerhalb eines EKS-Clusters (Amazon Elastic Kubernetes Service), mit der vLLM-Serving-Engine und dem Lastsimulationstool GuideLLM, zeigte, dass eine Konfiguration mit 50 % höherem kombiniertem Durchsatz eine fast 10× höhere p95-Time-per-Output-Token — die Latenz, unter der 95 % der Anfragen bleiben — haben kann, von rund 50 Millisekunden auf rund 494 Millisekunden. Getestet wurden drei Workload-Typen: Chatbot mit strenger TTFT-Anforderung (Time-to-First-Token, Zeit bis zum ersten Token), Reasoning mit einer Ausgabe von etwa 4.000 Token sowie agentische Abläufe mit kurzen verketteten Aufrufen.

Empfehlung: automatisierte Parametersuche

Casto empfiehlt eine automatisierte Suche über Parameter wie gpu_memory_utilization, max_num_batched_tokens und max_num_seqs, um die Serving-Konfiguration direkt für Goodput statt für reinen Durchsatz zu optimieren. Der Ansatz erfordert getrenntes Testen je Workload-Typ, da Chatbot-, Reasoning- und agentische Szenarien unterschiedliche Ziel-Latenzen und Toleranzen haben, sodass keine einzelne universelle Konfiguration alle Fälle gleich gut abdeckt.

Manuelles Durchsuchen von Parameterkombinationen für jede Modell-GPU-Kombination ist angesichts der großen Zahl möglicher Einstellungen unpraktikabel, weshalb Casto einen automatisierten Prozess befürwortet, der Konfigurationen systematisch testet und diejenige mit dem besten Goodput für den jeweiligen Workload-Typ auswählt. Teams, die LLMs in Produktion betreiben, erhalten damit eine konkrete Methode, um die Falle zu vermeiden, ausschließlich auf Durchsatz zu optimieren — was im Benchmark zu einer fast zehnfach schlechteren p95-Latenz für den Endnutzer führt.