CUDA 13.4 begrenzt GPU-Speicher pro Workload im Time-Sharing ohne MIG

CUDA 13.4 begrenzt GPU-Speicher pro Workload im Time-Sharing ohne MIG

Laut NVIDIA-Entwicklerblog soll CUDA 13.4 eine Speichergrenze durchsetzen, die die Anwendung nicht bemerkt. Grundlage ist ein neuer Time-Sharing-Modus: Jeder Workload sähe nur einen Teil des GPU-Speichers. So ließen sich GPUs in Kubernetes teilen, ohne dass Speicher ungeschützt zwischen Workloads liegt. Eine Hardwaretrennung wie bei MIG wäre dafür nicht nötig.

Ein Workload kann zwei Arten von Zusicherung anfordern. Die erste ist eine exakte Speichermenge. Eine Allokation oberhalb dieser Größe schlüge fehl, so wie auf einer kleineren GPU. Die zweite ist ein Bereich: ein garantiertes Minimum und ein Maximum, bis zu dem der Workload wachsen darf, solange Speicher frei ist. Der bereits vorhandene Compute-Modus (sm-sharing) in MPS bleibt wählbar. Jeder Workload kann ihn statt des standardmäßigen Time-Sharing nutzen.

Die Neuerung schließt eine Lücke im bisherigen Time-Slicing. Dort teilen sich die Replikas einer GPU den Speicher ohne Speicher- oder Fehlerisolation. Grenzen werden nicht durchgesetzt. Ein Pod kann so Speicher aufbrauchen, den andere Pods benötigen. MPS lässt Prozesse dagegen schon heute in getrennten Adressräumen gleichzeitig laufen.

Kubernetes braucht Software auf jedem GPU-Knoten

CUDA liefert die Durchsetzung. Ein Kubernetes-Cluster kann sie laut NVIDIA allein nicht nutzen. Auf jedem GPU-Knoten muss eine Komponente die nötigen Daemons betreiben und überwachen. Sie muss außerdem die Speicher- und Compute-Limits auf die Container der Pods anwenden. Kubernetes kennt die Grenze nicht von selbst. Sie muss pro Knoten in konkrete Einstellungen übersetzt werden.

Der Ausgangspunkt ist eng gefasst. Der NVIDIA Device Plugin meldet GPUs standardmäßig als ganzzahlige Ressource nvidia.com/gpu. Ein Pod fordert damit ganze Geräte an. Betreiber müssen die zusätzliche Komponente selbst bereitstellen. Offen bleibt, welche Komponenten die Grenze in Kubernetes tatsächlich durchsetzen.

Relevant ist das auch für GPUs ohne MIG-Unterstützung. Die Dokumentation zu Amazon EKS nennt g5, g6 und g6e als solche Instanzfamilien. Dort bleibt Time-Slicing eine Option, solange keine Speicherisolation nötig ist. Ob CUDA 13.4 auf diesen Instanzen unterstützt wird, ist nicht belegt.

NVIDIA betont außerdem den Nutzen. Gemeinsame Nutzung solle Plattformteams erlauben, mehr Workloads mit vorhandener Infrastruktur zu bedienen. Ganze GPUs ließen dagegen Kapazität brachliegen. Das ist eine Herstellerangabe ohne unabhängige Belege. Die in einer verwandten NVIDIA-Anleitung genannte Zuverlässigkeit von mehr als 99 Prozent bezieht sich auf MIG und Time-Slicing, nicht auf CUDA 13.4.

Version, Hardware, Reifegrad und Praxisdaten fehlen noch

Ungeklärt sind die genauen Versionen, die unterstützte Hardware und der Reifegrad: Alpha, Beta oder allgemein verfügbar. Die Primärquelle liegt nur als abgeschnittener Auszug vor. Unabhängige Messungen zu Leistung, Overhead und Fehlerverhalten gibt es nicht. Praxiserfahrungen auch nicht.

Zur Einordnung: MIG teilt eine GPU in hardwareisolierte Instanzen. Das funktioniert nur auf unterstützten GPUs und mit vorab geplanten statischen Profilen. Bei MPS kann der Fehler eines einzelnen Clients andere Clients auf derselben GPU beeinträchtigen. Speicheraufteilung bietet NVIDIA Run:ai mit GPU-Fractions bereits an. Zu Folgen für Deutschland oder die EU lässt sich aus der Faktenlage nichts ableiten.