Red Hat AI 3.5: Chat und Batch teilen sich eine GPU ohne Latenzeinbußen
Red Hat AI 3.5 macht prioritätsbasiertes Serving allgemein verfügbar. Chat-, Batch- und agentische Last teilen sich damit einen GPU-Pool, interaktive Anfragen kommen zuerst dran. Laut Red Hat sanken die Batch-Abweisungen bei einer Lastflut in den Tests von 48.224 auf 0, Anwendungen müssen dafür nicht angepasst werden.
- Prioritätsbasiertes Serving auf Basis von llm-d Flow Control ist in Red Hat AI 3.5 allgemein verfügbar.
- Auf einer NVIDIA H100 sanken die Batch-Abweisungen laut Red Hat bei einer Batch-Flut von 48.224 auf 0.
- Der neue Concurrency-Detektor hielt die Echtzeit-Stufen bei einer Time to First Token von 364 ms (Platinum) und 430 ms (Gold).
- Die Priorität ist strikt, und lange Ausgaben mit Tausenden Token können den Schutz von Premium schwächen.
- Als nächsten Schritt für llm-d nennt Red Hat SLO-bewusstes Serving mit Latenzzielen pro Stufe.
Warum getrennte GPU-Pools so teuer sind
Red Hat beschreibt das Problem als Frage, die sich jede gemeinsam genutzte Inferenzplattform irgendwann stellt: Wessen Anfrage kommt zuerst dran? Ein einzelnes Foundation Model auf einem Cluster kann einen Kunden-Chatbot, eine Batch-Pipeline zur Zusammenfassung, einen agentischen Workflow mit Retrieval-Augmented Generation (RAG) und einen internen Copiloten bedienen. Sie teilen sich ein Modell, aber nicht die Leistungsanforderungen.
Ein Chatbot braucht sein erstes Token in unter einer Sekunde. Eine Batch-Pipeline achtet auf den Durchsatz pro Dollar. Ein Pool ohne Prioritätskonzept nutzt eine Warteschlange und eine Abfolge bei der Zuteilung. Eine Batch-Flut bei einer Lastspitze lässt Chatbot-Anfragen daher dahinter warten.
Die übliche Antwort ist ein eigener GPU-Pool je Workload-Typ, jeweils auf die eigene Spitzenlast ausgelegt. Laut Red Hat bedeutet das, dass jeder Pool seine eigene Reserve vorhält und kein Pool freie Kapazität eines anderen nutzen kann.
So funktioniert prioritätsbasiertes Serving
Die Funktion basiert auf llm-d Flow Control, einer Schicht vor den Modellservern. Anwendungen rufen weiterhin denselben Endpunkt auf. Der Betreiber weist jedem Workload in einer Kubernetes-Ressource namens InferenceObjective eine Priorität zu, legt einen Sättigungsschwellenwert fest (den Punkt, ab dem der Pool als voll gilt) und wählt eine Fairness-Richtlinie. Das Gateway liest die Zugangsdaten des Aufrufers und versieht jede Anfrage mit einer Priorität und einem Mandanten.
Sobald der Pool gesättigt ist, entscheiden drei Regeln, wer als Nächstes drankommt:
- Priorität: Das höchste Band mit wartenden Anfragen kommt zuerst.
- Fairness: Innerhalb eines Bands wechselt die Zuteilung reihum zwischen den Mandanten, damit der Ansturm eines Mandanten die anderen nicht verdrängt.
- Reihenfolge: In der Warteschlange eines Mandanten werden Anfragen nach dem Prinzip „first come, first served“ bearbeitet.
Unterhalb des Schwellenwerts wird freie Kapazität nie zurückgehalten.
Testergebnisse von Red Hat
Unter Red Hat AI 3.5 teilten sich vier Stufen eine NVIDIA H100, die gpt-oss-20b bei identischem Datenverkehr bediente. Geändert wurde nur der Detektor, also der Teil von Flow Control, der entscheidet, wann der Pool als voll gilt. Die Time to First Token (TTFT) lag mit dem neuen Concurrency-Detektor bei 364 ms für Platinum (Echtzeit), 430 ms für Gold (Echtzeit), 699 ms für Silver (Standard) und 3,0 s für Bronze (Batch). Der ältere Auslastungsdetektor kam auf 1,3 s, 1,5 s, 2,0 s und 2,7 s.
Ohne Flow Control verursachte eine Batch-Flut auf derselben GPU über 3 Läufe hinweg 48.224 Abweisungen, jeweils ein Fehler 429 („Too Many Requests“). Mit Flow Control gab es keine, und die Anfragen warteten bei jeder getesteten Ausgabelänge, bis sie an der Reihe waren.
Innerhalb einer Stufe teilten sich drei Premium-Mandanten ein Band, während einer auf 82 Anfragen pro Sekunde anstieg und die beiden anderen bei 6 blieben. Die Wartezeit der ruhigen Mandanten blieb mit rund 17 Millisekunden konstant, der Mandant mit der Lastspitze wartete 45 Millisekunden und wurde dennoch bedient.
In internen Tests mit Premium, Standard und Batch auf vier NVIDIA A100 lag das erste Token bei Premium in jedem Szenario zwischen 2,1 und 2,8 Sekunden. Laut Red Hat sind es mit dem früheren Detektor 6,7 bis 8,3 Sekunden.
Grenzen und Feinjustierung
Laut Red Hat gibt es nur eine Stellschraube. Ist der Schwellenwert zu hoch, stauen sich Anfragen in den Modellservern. Ist er zu niedrig, beginnt das Queueing, obwohl die GPUs noch Reserven haben. Empfohlen wird, die Last so lange zu erhöhen, bis Premium sein Latenzziel verfehlt, und den Schwellenwert dann auf einen Bruchteil dieses Werts zu setzen.
Das Unternehmen nennt zwei Einschränkungen. Die Priorität ist strikt, daher hält dauerhafte Premium-Last Batch-Aufgaben so lange zurück, wie sie anhält. Und wenn Antworten Tausende Token umfassen, bestimmen Anfragen, die das Gate bereits passiert haben, die Latenz, sodass Flow Control den Schutz von Premium nicht mehr garantieren kann. Red Hat rät, agentische oder Reasoning-Workloads mit langen Ausgaben zuerst zu testen. Teams, deren Datenverkehr nur aus einer Art besteht oder deren Pool nie voll wird, brauchen die Funktion nicht.
Was das für Plattformteams bedeutet
Red Hat nennt ein Beispiel: Drei Pools mit je 8 GPUs bei durchschnittlich 30 % Auslastung bedeuten 24 GPUs, die etwa die Arbeit von 7 GPUs leisten. Wird Batch mit niedriger Priorität in einen gemeinsamen Pool gelegt, kann es nutzen, was die interaktiven Stufen frei lassen. Wie viel Kapazität dadurch frei wird, hängt davon ab, wie sich die Spitzen überlagern. Red Hat empfiehlt, das anhand der eigenen Auslastungsdaten zu prüfen.
Als nächsten Schritt nennt das Unternehmen SLO-bewusstes Serving, bei dem ein Betreiber pro Stufe ein Latenzziel angibt, statt es manuell in einen Sättigungsschwellenwert umzurechnen. Laut Red Hat geht llm-d in diese Richtung.
