NVIDIA führt mit CUDA 13.4 eine transparente Speicherbegrenzung für gemeinsam genutzte GPU-Workloads ein. Wie aus Berichten vom 27. Oktober 2026 hervorgeht, zielt die Neuerung darauf ab, den Grafikkartenspeicher in Multi-Tenant-Umgebungen und verteilten Rechenzentren effizienter und kontrollierter auf mehrere Prozesse aufzuteilen.
Drei Speichermodi und flexibles Limit-Management
Für die Zuteilung des Grafikspeichers stellt NVIDIA in CUDA 13.4 drei verschiedene Modi bereit. Nutzer können eine exakte Speichermenge festlegen, bei der jede Allokation über das definierte Limit hinaus fehlschlägt.
Alternativ steht ein flexibler Bereich zur Verfügung, der sich aus einer garantierten Mindestmenge und einem zusätzlichen Burst-Maximum zusammensetzt. Als dritte Option lässt sich konfigurieren, dass für eine Anwendung von vornherein nur ein Bruchteil des gesamten GPU-Speichers sichtbar ist.
Neue KI-Gesetze und technische Anforderungen stellen Unternehmen vor immer komplexere Herausforderungen beim rechtssicheren Einsatz moderner Technologien. Dieser kostenlose Report klärt auf, welche rechtlichen Pflichten und Bedrohungen Unternehmer jetzt kennen müssen. Cyber Security Bedrohungen abwenden und Unternehmen schützen
Ergänzend dazu bringt die Version MPS V3 (Multi-Process Service) eine Unterscheidung zwischen Soft- und Hard-Limits mit. Ein Soft-Limit fungiert als Zielwert: Dieser darf zwar überschritten werden, allerdings kann MPS den entsprechenden Workload bei auftretender Speicherkonkurrenz drosseln, verdrängen oder beenden.
Das Hard-Limit bildet hingegen eine strikte Obergrenze. Erreicht ein Prozess diese Marke, führt jeder weitere Zuteilungsversuch unmittelbar zu einem Out-of-Memory-Fehler.
Compute-Modi zur Steuerung von Fehlerdomänen
Neben dem Speicher lässt sich auch die Zuteilung der Rechenleistung anpassen. Workloads können wahlweise im standardmäßigen Modus Time-Slicing oder im Modus SM-Sharing ausgeführt werden. Während Time-Slicing getrennte Fehlerdomänen bietet, teilen sich Prozesse beim SM-Sharing eine gemeinsame Fehlerdomäne. Der Scheduler verhindert dabei technisch, dass beide Betriebsmodi gleichzeitig auf derselben GPU gemischt werden.
Orchestrierung und Vorgaben für Kubernetes-Umgebungen
Die Durchsetzung der Limits in Kubernetes-Clustern erfolgt über den quelloffenen GPU Fractioning Operator aus dem KAI-Scheduler-Projekt auf GitHub. Dieser arbeitet parallel zum regulären NVIDIA GPU Operator, richtet MPS auf jedem GPU-Knoten ein, weist Limits sowie Betriebsmodi pro Container zu und erfasst den tatsächlichen Ressourcenverbrauch pro GPU-Fraktion.
Wer KI-Systeme in Rechenzentren oder Kubernetes-Umgebungen entwickelt und betreibt, muss auch die regulatorischen Vorgaben des neuen EU AI Acts im Blick behalten. Dieser kostenlose Download verschafft Ihnen den Überblick über Fristen und Risikoklassen, den Ihre Rechts- und IT-Abteilung jetzt dringend braucht. EU AI Act in 5 Schritten verstehen
Der KAI Scheduler integriert dieses Verfahren seit der am 23. September veröffentlichten Version v0.18.0 über den sogenannten NvFractions-Modus, der sich über das Helm-Flag global.nvFractions.set=true aktivieren lässt.
Entwickler deklarieren die Speicher- und Rechenvorgaben über spezifische Pod-Annotationen. Möglich sind unter anderem Angaben wie gpu-memory.request (beispielsweise 40Gi), gpu-memory.limit (beispielsweise 60Gi), gpu-compute.mode sowie gpu-fraction-num-devices (beispielsweise 4).
Speicheranforderungen lassen sich sowohl als absoluter Wert als auch als relativer GPU-Anteil (gpu-fraction) definieren. Wird kein separates Limit angegeben, entspricht dieses automatisch dem angeforderten Wert. Bei relativen Anteilen muss ein definiertes Limit größer als die Basisanforderung und kleiner als der Gesamtwert 1 sein.
Für den Einsatz unter Kubernetes setzt NVIDIA mindestens den Treiberzweig R615 sowie Linux cgroup v2 voraus. Zudem unterstützt die Multi-Instance-GPU-Technologie (MIG) die neuen Mechanismen zur Speicherbegrenzung nicht.