NVIDIA bringt Green Contexts mit CUDA 13.1 in die CUDA Runtime API

Warum das Teilen einer GPU innerhalb eines Prozesses schwierig ist

Der Entwickler-Blog von NVIDIA, verfasst von Kyrylo Perelygin, Shelton Dsouza und Myrto Papadopoulou, geht von einem verbreiteten Muster aus: GPU-Anwendungen führen zunehmend mehrere unabhängige Komponenten gleichzeitig in einem einzigen Prozess aus. Beispiele sind ein latenzempfindlicher Operator neben einem durchsatzorientierten Hintergrund-Kernel, eine Datenvorverarbeitung neben der Modellinferenz oder mehrere Stufen eines Verarbeitungs-Workflows, die sich eine GPU teilen.

Laut NVIDIA können sich diese Komponenten unvorhersehbar gegenseitig stören, und die vorhandenen Werkzeuge bieten nur begrenzte Möglichkeiten, Ressourcen aufzuteilen. Klassische CUDA Contexts seien dafür nicht ausgelegt. NVIDIA beschreibt sie als schwergewichtig, mit Overhead durch Hardware-Kontextwechsel, und als Ausdruck von Annahmen aus einer früheren Zeit, in der GPUs kleiner waren und Anwendungen typischerweise eine dominante Workload ausführten.

Green Contexts sind in der Driver API seit CUDA 12.4 verfügbar. Ab CUDA 13.1 stehen sie zusätzlich über die Runtime API bereit, sodass eine Anwendung innerhalb ihres eigenen Prozesses festlegen kann, wo Arbeit ausgeführt wird und wie die Ausführungsressourcen aufgeteilt werden.

So teilen Green Contexts Ressourcen auf

Der Hauptanwendungsfall ist die SM-Partitionierung. Eine Anwendung weist einem Green Context eine Teilmenge der SMs zu, und über diesen Context eingereichte Arbeit läuft ausschließlich auf diesen SMs. So können mehrere Workloads gleichzeitig laufen, ohne um dieselben Recheneinheiten zu konkurrieren.

Green Contexts können außerdem Workqueue-Ressourcen bereitstellen. Im klassischen Modell können unabhängige, stream-geordnete Workloads auf dieselben zugrunde liegenden Workqueues abgebildet werden, was selbst bei ausreichend freien Ausführungsressourcen zu unbeabsichtigter Serialisierung führen kann. Wenn Anwendungen Workqueues explizit bereitstellen, können sie die erwartete Parallelität ausdrücken und falsche Abhängigkeiten verringern.

NVIDIA zufolge lassen sich Green Contexts leichtgewichtig erstellen und zerstören, ohne dass dabei unbeteiligte GPU-Arbeit implizit synchronisiert wird.

Auch das Programmiermodell ändert sich. Bisher rief eine Runtime-Anwendung cudaSetDevice() auf, erstellte Streams und reichte Arbeit ein, wobei das Ziel des Streams aus dem aktuellen Device oder Context des aufrufenden Threads abgeleitet wurde. Mit Green Contexts erstellt die Anwendung einen Green Context für eine gewählte Ressourcenmenge und legt anschließend daraus Streams an. In der Runtime API wird der Context durch den Typ cudaExecutionContext_t repräsentiert. Der Aufruf cudaGreenCtxCreate() liefert ein Handle, das direkt an Aufrufe wie cudaExecutionCtxStreamCreate() übergeben werden kann. In den Worten von NVIDIA: „Die Codeänderungen sind minimal, aber das mentale Modell ist klarer.“ Anwendungen, die das gesamte Gerät nutzen wollen, können beim klassischen Modell bleiben und den geräteweiten Context mit cudaDeviceGetExecutionCtx() abrufen, wenn eine API ein explizites Handle verlangt.

Ein latenzkritischer Kernel neben einer Bulk-Workload

Das Praxisbeispiel von NVIDIA behandelt einen bekannten Fall: Ein kleiner, latenzempfindlicher Kernel teilt sich ein Gerät mit einem größeren, durchsatzorientierten Worker. Als typische Szenarien nennt der Blog die Überlappung von Kommunikation und GEMM bei verteiltem Training und Inferenz sowie latenzempfindliche Operatoren in KI-Sensorverarbeitungsplattformen wie NVIDIA Holoscan.

CUDA-Stream-Prioritäten sind dafür ein Standardwerkzeug, reichen laut NVIDIA aber nicht aus, wenn Bulk-Kernels sämtliche SMs der GPU vollständig belegen. Stream-Prioritäten können einen bereits auf einem SM laufenden Block nicht unterbrechen, sodass der kritische Kernel warten muss, bis einige Blöcke abgearbeitet sind, ehe er SMs erhält.

Der Beispielcode fragt alle SMs ab, schneidet eine kritische Gruppe heraus, deren Größe sich an der Coscheduled-Ausrichtung der Architektur orientiert, und koppelt jede Partition mit einer eigenen Workqueue-Config-Ressource, sodass auch der Warteschlangendruck isoliert ist. Anschließend erstellt er für jede Partition einen Green Context und einen Stream, mit einem hochpriorisierten Stream für den kritischen Kernel und einem niedrigpriorisierten Stream für die Bulk-Arbeit. NVIDIA nach wurden drei Modi mit derselben kritischen und Bulk-Workload getestet. Modus A nutzt die Green-Context-Partition mit einem hochpriorisierten kritischen Stream, Modus B den Standard-Context mit einem hochpriorisierten kritischen Stream und ohne Partitionierung. Der vorliegende Text bricht vor dem dritten Modus und den vollständigen Ergebnissen ab.

Die Zusammenfassung des Blogs nennt das zentrale Ergebnis: Auf einer Blackwell-GPU mit 148 SMs sank die Latenz des kritischen Kernels von 0,140 ms auf 0,007 ms, wenn der Kernel dedizierte SMs hatte und nicht auf das Abarbeiten der Bulk-Arbeit warten musste.

Was das für CUDA-Entwickler bedeutet

NVIDIA betont, dass Green Contexts optional und additiv sind. Bestehende Anwendungen funktionieren unverändert weiter, und der übrige Code kann den streambasierten CUDA-Workflow weiter nutzen, sodass Teams Green Contexts schrittweise dort einführen können, wo sie feinere Kontrolle über parallele Workloads brauchen. Für Entwickler, die latenzempfindliche und Bulk-Arbeit auf einer GPU mischen, bietet der Runtime-API-Zugang in CUDA 13.1 eine explizitere Möglichkeit, beides voneinander zu isolieren. Das Unternehmen verweist Leser auf den Abschnitt zu Green Contexts im CUDA Programming Guide und auf die CUDA Driver API Reference für die Ressourcenpartitionierung auf niedriger Ebene.