GPU-Job-Scheduling mit einem ungenutzten Inference-GPU-Pool

GPU-Job-Scheduling mit einem ungenutzten Inference-GPU-Pool: Ein Fallbeispiel zur Infrastruktur-Effizienz des LG AI Research Institute

Dieser vom Platform&Infra Team des LG AI Research Institute veröffentlichte Beitrag behandelt, wie ungenutzte GPU-Ressourcen, die beim Betrieb von Large Language Model (LLM)-Services anfallen, für Forschungs- und Experimentierarbeiten wiederverwendet wurden. Unternehmen, die AI-Services betreiben, reservieren GPUs in der Regel vorab auf Basis des Traffic-Spitzenwerts. In Zeiten mit geringerem Traffic bleiben dadurch teure GPUs oft ungenutzt und belegen lediglich Speicher. Das Institut hat eine Pipeline aufgebaut, die GPUs in diesen Leerlaufzeiten automatisch Trainings- und Evaluierungsjobs zuweist und so ohne zusätzliche Hardwarekäufe Rechenressourcen erschließen konnte.

Kernproblemdefinition

• Grenzen des Auto-Scalings bei LLM-Services: Anders als bei gewöhnlichen Web-Services schwankt der GPU-Verbrauch pro Anfrage bei LLMs je nach Länge der Eingabe- und Ausgabetokens sowie je nach Modellarchitektur stark. Daher ist es schwierig, die tatsächliche Last mit traditionellen Metriken wie CPU-Auslastung oder Speicherauslastung präzise zu messen.
• Umfang ungenutzter Ressourcen: In einer Umgebung, in der ein Replica (duplizierte Service-Instanz) vier GPUs verwendet, lagen in den nächtlichen Nebenzeiten (20 Uhr bis 8 Uhr des Folgetags) durchschnittlich 52 GPUs pro Tag für etwa 12 Stunden brach.

Lösungsansatz

• Nutzung interner vLLM-Metriken: Statt allgemeiner Systemmetriken wurden Echtzeitmetriken des LLM-Inference-Engines vLLM, etwa Durchsatz und Warteschlangenzustand, als Grundlage für das Auto-Scaling verwendet, um eine präzise, auf die Eigenschaften von LLMs abgestimmte Ressourcensteuerung umzusetzen.
• Job-Ausführung im Best-effort-Modell: Forschungsjobs werden auf nächtlichen ungenutzten GPUs gestartet. Steigt der Traffic wieder an, können diese Jobs jederzeit unterbrochen und die GPUs an den Service zurückgegeben werden, sodass die Service-Stabilität nicht beeinträchtigt wird.
• Pipeline auf Basis von Argo Workflows: Jobs werden auf Docker-Image-Ebene definiert, und Datenvorverarbeitung, Pretraining, Supervised Fine-Tuning, Reinforcement Learning und Evaluierung können als Schritte sequenziell oder parallel ausgeführt werden.

Besondere Vorteile der Designprinzipien

• Universalität: Sowohl Training als auch Inference sowie beliebige Frameworks lassen sich unverändert ausführen, solange sie in ein Docker-Image verpackt werden.
• Skalierbarkeit und Flexibilität: Auch wenn neue Job-Typen hinzukommen, können sie aufgenommen werden, ohne den Pipeline-Code anpassen zu müssen.
• Reproduzierbarkeit: Sämtliche Konfigurationen werden nicht im Code, sondern über externe Parameter injiziert, und Ein- sowie Ausgabe werden im Cloud Storage verwaltet, sodass unter identischen Bedingungen identische Ergebnisse gewährleistet sind. Auch die zustandslose (Stateless) Architektur der Pipeline, die keinen Zustand speichert, trägt zur Betriebsstabilität bei.

Betriebsergebnisse

• Kumulative Nutzung: Von November 2025 bis Januar 2026, also über rund drei Monate, wurden 85 Jobs ausgeführt, und die kumulierte GPU-Nutzung erreichte 95.000 GPU-Stunden.
• Wachstumstrend: Die GPU-Nutzung im Januar lag rund 70 % über dem Wert vom November und entsprach, auf 24 Stunden umgerechnet, dem Effekt einer zusätzlichen Verfügbarkeit von etwa 55 GPUs.
• Kosteneinsparungen: Rechnet man dieselbe Rechenmenge auf Basis einer dreijährigen Verpflichtung in der Public Cloud um, ergab sich allein für den Januar eine Einsparung von rund 75 Millionen Won und kumuliert über drei Monate von rund 185 Millionen Won.

Ausblick

• Weiterentwicklung der Skalierungsmetriken: Die Nutzungsmuster je Service sollen weiter ausdifferenziert werden, um die Logik der Ressourcenzuweisung zu verfeinern.
• Ausweitung auf kontinuierliches Scheduling: Mithilfe von Kubernetes und dem hauseigenen Modell EXAONE soll das System von einem nur nächtlichen Betrieb auf eine kontinuierliche Ausführung erweitert werden, bei der Jobs sofort gestartet werden, sobald Ressourcen frei werden.
• UX-Verbesserungen: Geplant ist eine Oberfläche, über die Forschende ihre Jobs von der Anfrage bis zum Monitoring intuitiv durchführen können.

Dieses Fallbeispiel ist insofern bemerkenswert, als es eine branchenweit verbreitete Herausforderung, nämlich den Mangel an GPUs, nicht durch Hardware-Ausbau, sondern durch eine Verbesserung der Betriebsstruktur angeht. Besonders auffällig ist der Ansatz, die für LLM-Services typische Schwierigkeit der Lastmessung über interne vLLM-Metriken zu umgehen und Forschungsjobs im Best-effort-Modell zu betreiben, um die zwei gegensätzlichen Ziele Service-Stabilität und Ressourcenauslastung gleichzeitig zu erreichen. Der quantifizierbare Erfolg, ohne zusätzliche Investitionen Kosten in Höhe von rund 180 Millionen Won eingespart zu haben, liefert auch anderen Organisationen mit GPU-Infrastruktur ein durchaus nachahmenswertes Betriebsmodell.