Durchsetzung von GPU-Speichergrenzen in Kubernetes mit CUDA 13.4 und KAI Scheduler

NVIDIA hat CUDA 13.4 veröffentlicht, das eine transparente Durchsetzung von Speicherbegrenzungen für GPU-Workloads einführt. Um dies in Kubernetes zu operationalisieren, arbeitet der Open-Source-GPU-Fractioning-Operator nun mit KAI Scheduler v0.18.0 zusammen, um fraktionierte GPU-Ressourcen zu verwalten. Diese Kombination ermöglicht es Plattformteams, GPUs effizienter zu teilen und gleichzeitig eine strikte Speicherisolation beizubehalten.

Was passiert ist

Viele Workloads für KI-Inferenz und Entwicklung benötigen nicht die gesamte GPU. Die Zuweisung vollständiger Geräte an kleine Jobs führt zu erheblichen ungenutzten Kapazitäten. Während NVIDIA-GPUs die gemeinsame Nutzung über Multi-instance GPU (MIG), Time-Slicing oder Multi-Process Service (MPS) seit Langem unterstützen, fehlten bei früheren Methoden robuste Mechanismen zur Speicherdurchsetzung im geteilten Modus. Time-Slicing erlaubte Prozessen, sich abwechselnd zu nutzen, verhinderte jedoch nicht, dass ein Prozess den gesamten verfügbaren Speicher verbraucht. MPS erlaubte parallele Ausführung, verließ sich aber auf die Disziplin der Anwendungsebene bei der Speichernutzung.

CUDA 13.4 schließt diese Lücke, indem es Speicherbegrenzungen transparent auf Treiberebene durchsetzt. Anwendungen sehen nur ihren zugewiesenen Anteil des Speichers, und Allokationen, die dieses Limit überschreiten, schlagen sofort fehl. Um die Kluft zwischen dieser Low-Level-Funktion und der Kubernetes-Orchestrierung zu überbrücken, hat NVIDIA den GPU Fractioning Operator eingeführt. Gehostet unter der KAI-Scheduler-Organisation auf GitHub, läuft dieser Operator parallel zum NVIDIA GPU Operator. Er verwaltet die Einrichtung von MPS auf jedem Knoten, wendet speicherbezogene Limits pro Workload an und meldet die Nutzung pro Fraktion statt pro gesamter GPU.

KAI Scheduler v0.18.0 integriert sich direkt mit diesem Operator über einen neuen GPU-Sharing-Modus namens NvFractions. Der Scheduler wählt geeignete GPUs basierend auf dem verfügbaren Speicher aus und schreibt spezifische Annotationen in die Pod-Spezifikationen. Der GPU Fractioning Operator liest diese Annotationen und konfiguriert den Knoten so, dass die angeforderten Speicherlimits und Compute-Modi vor dem Start des Containers durchgesetzt werden. Diese Trennung der Zuständigkeiten stellt sicher, dass Scheduling-Entscheidungen von der Durchsetzung auf Knotenebene getrennt bleiben.

Wie es funktioniert

Das System stützt sich auf zwei Compute-Modi für die gemeinsame Nutzung von GPU-Ressourcen: Time-Slicing und SM-Sharing. Beim Time-Slicing wechseln sich Workloads bei der Nutzung der gesamten GPU ab. Wenn ein Workload im Leerlauf ist, wird sein Zeitslot auf andere verteilt. Dieser Modus bietet vollständige Fehlerisolierung, was bedeutet, dass ein Absturz eines Workloads keine anderen beeinflusst. Beim SM-Sharing werden die Streaming-Multiprozessoren (SMs) der GPU unter gleichzeitigen Workloads aufgeteilt. Alle aktiven Workloads laufen gleichzeitig, und ungenutzte SMs werden dynamisch neu allokiert. Allerdings placing SM-Sharing Workloads in einer einzigen Fehlerdomäne, sodass ein Fehler in einem die anderen beeinträchtigen kann.

CUDA 13.4 setzt Speicherlimits unabhängig vom Compute-Modus durch. Ein Workload kann eine exakte Speichermenge oder einen Bereich anfordern, der aus einer garantierten Mindestmenge und einer burstfähigen Höchstmenge besteht. Versucht ein Workload, mehr Speicher als sein Limit zuzuweisen, schlägt die Allokation fehl, genau wie auf einer physisch kleineren GPU. Diese Durchsetzung ist für die Anwendung transparent und erfordert keine Codeänderungen. Der GPU Fractioning Operator stellt sicher, dass diese Limits angewendet werden, indem er die zugrunde liegenden MPS-Daemons konfiguriert und die Nutzung pro Fraktion überwacht.

Scheduler kommunizieren Anforderungen an den Operator über standardmäßige Kubernetes-Pod-Annotationen. Diese Annotationen spezifizieren die garantierte Speicheranforderung, das optionale Burst-Limit, den gewünschten Compute-Modus und die spezifischen zugewiesenen GPU-Geräte. Der Operator analysiert diese Felder und übersetzt sie in Konfigurationen auf Knotenebene. Dieser Mechanismus ermöglicht es jedem Kubernetes-Scheduler, der in der Lage ist, diese Annotationen zu schreiben, die Speicherdurchsetzung von CUDA zu nutzen, obwohl KAI Scheduler die erste native Integration bietet.

Wichtige Details

• CUDA 13.4 führt transparente Speicherbegrenzungs-Durchsetzung ein, die exakte Speichermengen oder burstfähige Bereiche für geteilte GPU-Workloads erlaubt.
• Der GPU Fractioning Operator ist ein Open-Source-Tool, das MPS einrichtet, Speicherlimits anwendet und die Nutzung pro GPU-Fraktion misst.
• KAI Scheduler v0.18.0 enthält einen NvFractions-Modus, der die erforderlichen Pod-Annotationen für die Durchsetzung durch den Operator schreibt.
• Workloads können zwischen Time-Slicing (serielle Ausführung mit Fehlerisolierung) und SM-Sharing (parallele Ausführung mit dynamischer SM-Allokation) wählen.
• Speicheranforderungen können als absolute Größen (z. B. "40Gi") oder als Anteile einer GPU (z. B. "0.5") definiert werden.
• Administratoren aktivieren die Integration während der Installation von KAI Scheduler über ein Helm-Flag, das den GPU Fractioning Operator als Abhängigkeit installiert.

Warum das wichtig ist

Für Engineering-Teams, die ML-Infrastrukturen aufbauen, verbessert dieses Update die Ressourcennutzung erheblich, ohne die Stabilität zu gefährden. Zuvor bedeutete die gemeinsame Nutzung von GPUs oft die Wahl zwischen schlechter Isolation (MPS) oder starrer Partitionierung (MIG). Mit CUDA 13.4 und dem GPU Fractioning Operator können Teams mehr Workloads auf vorhandener Hardware bündeln und dabei sicherstellen, dass kein einzelner Job andere des Speichers entbehren lässt. Dies ist besonders wertvoll für Inferenzdienste und Entwicklungsumgebungen, in denen Workloads in Größe und Intensität variieren.

Die Möglichkeit, burstfähige Speicherlimits zu definieren, erhöht die Flexibilität für Batch-Jobs oder Trainingsaufgaben, die gelegentlich mehr Ressourcen benötigen. Wenn Speicher frei ist, kann ein Workload diesen nutzen; wenn nicht, bleibt es innerhalb seiner garantierten Mindestmenge. Diese dynamische Allokation reduziert die Notwendigkeit einer Überbereitstellung. Darüber hinaus ermöglicht die klare Unterscheidung zwischen Time-Slicing und SM-Sharing Architekten, den Sharing-Modus an die Fehlertoleranzanforderungen des Workloads anzupassen. Kritische Produktionsdienste können Time-Slicing für Isolation nutzen, während resiliente Batch-Jobs SM-Sharing für höheren Durchsatz verwenden können.

Was Sie tun können

• Installieren Sie KAI Scheduler v0.18.0 oder neuer mit dem Helm-Flag global.nvFractions.set=true, um die Unterstützung für GPU-Frakturierung zu aktivieren.
• Prüfen Sie das Repository des GPU Fractioning Operators auf GitHub für Installationsanleitungen und Konfigurationsdetails.
• Aktualisieren Sie Pod-Spezifikationen, um Annotationen für Speicheranforderungen, Limits und Compute-Modi einzuschließen, wenn Sie fraktionierte Workloads bereitstellen.
• Wählen Sie Time-Slicing für Workloads, die Fehlerisolierung erfordern, und SM-Sharing für solche, die parallele Ausführung und dynamische SM-Nutzung benötigen.
• Überwachen Sie die GPU-Nutzung pro Fraktion anhand der Metriken des GPU Fractioning Operators, um die Ressourcenzuweisung zu optimieren.
• Treten Sie dem KAI-Scheduler-Slack-Kanal bei oder nehmen Sie an den zweiwöchentlichen Community-Meetings teil, um Fragen zu stellen und zum Projekt beizutragen.