GPU-Vir­tua­li­sie­rung: vGPU, MIG und Pass­th­rough im tech­ni­schen Vergleich

GPU-Vir­tua­li­sie­rung umfasst drei grund­le­gen­de Ansätze: Bei GPU-Pass­th­rough wird eine voll­stän­di­ge physische GPU exklusiv einer einzelnen VM zu­ge­wie­sen. vGPU-Lösungen teilen GPU-Res­sour­cen dagegen meist zeitlich über Time-Slicing und Scheduler-Me­cha­nis­men zwischen mehreren VMs auf. Multi-Instance GPU, kurz MIG, par­ti­tio­niert un­ter­stütz­te NVIDIA-GPUs hingegen in feste, von­ein­an­der isolierte Hardware-Instanzen.

GPUs als zentrale Re­chen­res­sour­ce im Re­chen­zen­trum

Durch KI-Training, Inferenz und GPU-be­schleu­nig­tes High-Per­for­mance-Computing sind GPUs zu einer zentralen Re­chen­res­sour­ce moderner Re­chen­zen­tren geworden. Was früher vor allem für Grafik, Rendering oder Spe­zi­al­an­wen­dun­gen genutzt wurde, ist heute oft ent­schei­dend für die Leistung ganzer Platt­for­men.

GPU-Res­sour­cen effizient in vir­tu­el­len Um­ge­bun­gen be­reit­zu­stel­len, ist jedoch an­spruchs­vol­ler als bei klas­si­schen CPU-Workloads. GPUs arbeiten massiv parallel, verfügen über eigenen schnellen Speicher wie VRAM oder HBM und sind eng über PCIe sowie her­stel­ler­spe­zi­fi­sche Treiber- und Lauf­zeit­um­ge­bun­gen in das System ein­ge­bun­den. Dadurch lassen sie sich nicht ohne Weiteres so flexibel teilen wie CPU-Kerne oder Ar­beits­spei­cher.

In der Praxis haben sich drei wichtige Ansätze etabliert:

• Ex­klu­si­ves GPU-Pass­th­rough: Eine voll­stän­di­ge physische GPU wird einer einzelnen vir­tu­el­len Maschine zu­ge­wie­sen.
• vGPU-Lösungen: Mehrere virtuelle Maschinen teilen sich eine GPU über Treiber- und Hy­per­vi­sor-Me­cha­nis­men.
• Multi-Instance GPU (MIG): Un­ter­stütz­te NVIDIA-GPUs werden auf Hard­ware­ebe­ne in von­ein­an­der getrennte GPU-Instanzen auf­ge­teilt.

Diese Verfahren un­ter­schei­den sich vor allem darin, ob Res­sour­cen zeitlich geteilt oder fest par­ti­tio­niert werden und wie stark die einzelnen Workloads von­ein­an­der isoliert sind.

GPU-Pass­th­rough: direkte GPU-Zuweisung an eine VM

Beim GPU-Pass­th­rough wird eine voll­stän­di­ge physische GPU exklusiv einer einzelnen vir­tu­el­len Maschine zu­ge­wie­sen. Die VM erhält damit direkten Zugriff auf die GPU, als wäre sie in einem phy­si­schen Server eingebaut.

Je nach Plattform trägt dieses Verfahren un­ter­schied­li­che Namen:

• Microsoft Hyper-V: Discrete Device As­sign­ment (DDA)
• VMware vSphere/ESXi: VM­Di­rect­Path I/O bzw. PCI-Pass­th­rough
• Linux/KVM: PCI-Pass­th­rough über das VFIO-Framework

Technisch er­mög­licht wird dies durch die IOMMU (Input-Output Memory Ma­nage­ment Unit), die bei Intel meist als VT-d, bei AMD als AMD-Vi be­zeich­net wird. Sie sorgt dafür, dass Spei­cher­zu­grif­fe der GPU korrekt auf den Spei­cher­be­reich der VM ab­ge­bil­det und gegenüber anderen Sys­tem­be­rei­chen isoliert werden. Die VM kann dadurch den nativen Her­stel­ler-Treiber verwenden, also denselben Treiber, der auch auf einem phy­si­schen System zum Einsatz käme.

Vor- und Nachteile von GPU-Pass­th­rough

Der große Vorteil dieses Ansatzes ist die sehr hohe Per­for­mance. Da die GPU nicht emuliert oder über eine zu­sätz­li­che Abs­trak­ti­ons­schicht geteilt wird, liegt die Leistung je nach Workload sehr nah an der Leistung eines direkt auf phy­si­scher Hardware be­trie­be­nen Systems.

Der Nachteil ist die fehlende Fle­xi­bi­li­tät: Eine per Pass­th­rough zu­ge­wie­se­ne GPU steht exklusiv einer VM zur Verfügung. Andere VMs können diese GPU wäh­rend­des­sen nicht nutzen, auch dann nicht, wenn die zu­ge­wie­se­ne VM nur einen kleinen Teil der Rechen- oder Spei­cher­ka­pa­zi­tät benötigt.

Tech­ni­sche Ein­schrän­kun­gen von GPU-Pass­th­rough

Die hohe Per­for­mance von GPU-Pass­th­rough geht mit einigen prak­ti­schen Ein­schrän­kun­gen einher, die vor allem aus der ex­klu­si­ven Bindung der GPU an eine einzelne VM entstehen:

• Keine gleich­zei­ti­ge Res­sour­cen­tei­lung: Eine physische GPU wird einer VM exklusiv zu­ge­ord­net. Freie GPU-Kapazität kann nicht dynamisch an andere VMs wei­ter­ge­ge­ben werden.
• Geringe Wirt­schaft­lich­keit bei kleinen Workloads: Für virtuelle Desktops, leichte Inferenz oder andere wenig an­spruchs­vol­le Aufgaben ist eine komplette GPU oft über­di­men­sio­niert.
• Ein­ge­schränk­te Mobilität der VM: Da die VM direkt an eine konkrete physische GPU gebunden ist, sind Live-Migration, Snapshots, Save/Restore und nahtloses Failover je nach Plattform nicht oder nur stark ein­ge­schränkt möglich. In einigen Cluster-Szenarien ist ein au­to­ma­ti­scher Neustart auf einem anderen Host möglich, aber keine echte Live-Migration.
• Ab­hän­gig­keit von Plattform und IOMMU: Der Host muss PCIe-Pass­th­rough sauber un­ter­stüt­zen. Dazu gehören ak­ti­vier­te Vir­tua­li­sie­rungs­er­wei­te­run­gen wie Intel VT-d oder AMD-Vi sowie eine geeignete PCIe-/IOMMU-Topologie. Unter Linux/KVM ist ins­be­son­de­re relevant, ob die GPU in einer aus­rei­chend iso­lier­ten IOMMU-Gruppe liegt.
• Support- und Trei­ber­ab­hän­gig­kei­ten: Nicht jede GPU, jedes Mainboard und jede Hy­per­vi­sor-Version un­ter­stützt Pass­th­rough zu­ver­läs­sig. In pro­duk­ti­ven Um­ge­bun­gen sollten daher immer die Hardware-Kom­pa­ti­bi­li­täts­lis­ten und Trei­ber­vor­ga­ben des je­wei­li­gen Her­stel­lers geprüft werden.

Virtual GPU (vGPU)

Virtual GPU, kurz vGPU, löst ein zentrales Problem des GPU-Pass­th­rough: Eine physische GPU muss nicht mehr exklusiv einer einzelnen VM zu­ge­wie­sen werden, sondern kann von mehreren vir­tu­el­len Maschinen gemeinsam genutzt werden.

Dafür kommt auf dem Host eine spezielle Vir­tua­li­sie­rungs­kom­po­nen­te zum Einsatz, zum Beispiel der NVIDIA Virtual GPU Manager. Dieser läuft auf dem je­wei­li­gen Hy­per­vi­sor, etwa VMware vSphere/ESXi, Linux/KVM oder XenServer, und stellt den VMs virtuelle GPU-Geräte bereit. In der Gast-VM wird an­schlie­ßend ein passender NVIDIA-vGPU-Treiber in­stal­liert.

Bei klas­si­schen vGPU-Kon­fi­gu­ra­tio­nen basiert die ge­mein­sa­me Nutzung vor allem auf Time-Slicing. Die GPU wird also nicht dauerhaft in feste Hard­ware­be­rei­che auf­ge­teilt, sondern ihre Rechen- und Grafik-Engines werden zeitlich zwischen den VMs geteilt. Die einzelnen Workloads laufen dabei in schneller Abfolge nach­ein­an­der auf derselben phy­si­schen GPU.

Jede VM erhält über ein vGPU-Profil einen de­fi­nier­ten Anteil am GPU-Speicher. Solche Profile legen unter anderem fest, wie viel Frame­buf­fer einer VM zur Verfügung steht und für welchen Ein­satz­zweck das Profil gedacht ist. Beispiele sind:

• Q-Profile für virtuelle Work­sta­tions
• B-Profile für virtuelle Desktops
• A-Profile für App-Streaming
• C-Profile für Compute-Workloads

Die Re­chen­leis­tung wird bei klas­si­schen vGPU-Profilen dagegen nicht physisch fest ab­ge­trennt, sondern über Scheduler verteilt. NVIDIA un­ter­stützt dafür unter anderem Best Effort, Equal Share und Fixed Share:

• Best Effort erlaubt eine möglichst flexible Aus­las­tung der GPU, kann aber bei stark schwan­ken­den Workloads zu Per­for­mance-Un­ter­schie­den führen.
• Equal Share und Fixed Share sorgen für eine gleich­mä­ßi­ge­re be­zie­hungs­wei­se festere Ver­tei­lung der GPU-Zeit.

Vor- und Nachteile von vGPU

Der Vorteil von vGPU liegt in der deutlich besseren Aus­las­tung der Hardware. Mehrere VMs können sich eine teure GPU teilen, statt dass jede VM eine eigene Karte benötigt. Das ist besonders sinnvoll für virtuelle Desktops, CAD-Ar­beits­plät­ze, Rendering-Um­ge­bun­gen, leichte KI-Inferenz oder andere Workloads, die nicht dauerhaft eine komplette GPU auslasten.

Der Nachteil liegt in der ge­rin­ge­ren Hardware-Iso­lie­rung gegenüber MIG oder Pass­th­rough. Zwar ist der zu­ge­wie­se­ne Frame­buf­fer der einzelnen vGPUs von­ein­an­der ab­ge­grenzt, die ei­gent­li­chen Re­chen­res­sour­cen werden aber geteilt. Wenn mehrere VMs gleich­zei­tig hohe GPU-Last erzeugen, kann es deshalb zu Kon­kur­renz um Re­chen­zeit kommen.

Tech­ni­sche Ein­schrän­kun­gen von vGPU

vGPU bietet deutlich mehr Fle­xi­bi­li­tät bei der ge­mein­sa­men Nutzung einer GPU, bringt dafür aber zu­sätz­li­chen Be­triebs­auf­wand und Ein­schrän­kun­gen bei der Per­for­mance-Iso­lie­rung mit sich:

• Li­zen­zie­rung er­for­der­lich: NVIDIA vGPU ist ein li­zenz­pflich­ti­ges Produkt. Je nach Profil und Ein­satz­zweck kommen un­ter­schied­li­che Li­zenz­mo­del­le zum Einsatz, zum Beispiel vWS, vPC, vApps oder NVIDIA AI En­ter­pri­se für Compute-Szenarien. Ohne gültige Lizenz wird die Leistung be­zie­hungs­wei­se Funk­tio­na­li­tät nach Ablauf einer Frist ein­ge­schränkt.
• Noisy-Neighbor-Effekt möglich: Da die GPU-Re­chen­res­sour­cen zeitlich geteilt werden, kann eine stark aus­ge­las­te­te VM die Per­for­mance anderer VMs auf derselben GPU be­ein­flus­sen. Scheduler wie Equal Share oder Fixed Share können diesen Effekt begrenzen, ersetzen aber keine voll­stän­di­ge Hardware-Par­ti­tio­nie­rung.
• Kom­pa­ti­ble Treiber er­for­der­lich: Der host­sei­ti­ge vGPU-Manager und der Gast­trei­ber müssen innerhalb der von NVIDIA de­fi­nier­ten Kom­pa­ti­bi­li­täts­be­rei­che liegen. Eine exakte Ver­si­ons­gleich­heit ist nicht immer er­for­der­lich. Werden sie jedoch un­ab­hän­gig von­ein­an­der ak­tua­li­siert, kann es passieren, dass vGPU in den be­trof­fe­nen VMs nicht mehr korrekt startet.
• Mehr Be­triebs­auf­wand: vGPU erfordert eine ab­ge­stimm­te Kom­bi­na­ti­on aus un­ter­stütz­ter GPU, Hy­per­vi­sor-Version, vGPU-Manager, Gast-Treiber, Li­zenz­ser­ver und Pro­fil­kon­fi­gu­ra­ti­on. Das macht Betrieb und Updates komplexer als bei einfachem GPU-Pass­th­rough.
• Moderater Sche­du­ling-Overhead: Da GPU-Zeit zwischen mehreren vGPUs geplant und um­ge­schal­tet wird, entsteht zu­sätz­li­cher Ver­wal­tungs­auf­wand. Dieser ist in vielen Szenarien gut ver­tret­bar, kann aber bei besonders latenz- oder per­for­mance­kri­ti­schen Workloads eine Rolle spielen.
• Keine harte physische Isolation wie bei MIG: Klas­si­sche vGPU teilt Re­chen­res­sour­cen logisch über Software und Sche­du­ling. Wer feste, hard­ware­sei­tig getrennte GPU-Anteile benötigt, sollte MIG oder MIG-backed vGPU prüfen.

Multi-Instance GPU (MIG)

Multi-Instance GPU, kurz MIG, verfolgt einen anderen Ansatz als klas­si­sche vGPU-Modelle mit Time-Slicing. NVIDIA führte Multi-Instance GPU mit der Ampere-Ar­chi­tek­tur ein, unter anderem mit der A100. Seitdem wurde MIG auf aus­ge­wähl­te Dat­a­cen­ter- und Pro­fes­sio­nal-GPUs aus­ge­wei­tet. Die Tech­no­lo­gie ist deshalb vor allem in Re­chen­zen­trums­um­ge­bun­gen relevant, in denen mehrere KI-, Inferenz- oder HPC-Workloads gleich­zei­tig auf einer GPU laufen sollen. Statt eine GPU zeitlich zwischen mehreren Workloads auf­zu­tei­len, wird die Hardware in feste Teil­be­rei­che par­ti­tio­niert. Jede Instanz erhält dadurch einen klar de­fi­nier­ten Anteil an Re­chen­leis­tung, Speicher und Spei­cher­band­brei­te.

Je nach GPU-Modell kann eine physische GPU in mehrere von­ein­an­der getrennte GPU-Instanzen auf­ge­teilt werden. Bei vielen Dat­a­cen­ter-Modellen sind bis zu sieben Instanzen möglich. Jede Instanz erhält fest zu­ge­wie­se­ne Hardware-Res­sour­cen:

• Streaming Mul­tipro­ces­sors
• Spei­cher­be­rei­che
• Spei­cher­band­brei­te
• L2-Cache-Anteile
• Da­ten­pfa­de durch das Spei­cher­sys­tem

Die Größe einer Instanz wird über vor­de­fi­nier­te Profile fest­ge­legt. Bei einer NVIDIA A100 mit 40 GB Speicher sind zum Beispiel Profile wie 1g.5gb, 2g.10gb oder 7g.40gb möglich. Die erste Angabe be­schreibt grob den Anteil an GPU-Re­chen­res­sour­cen, die zweite den zu­ge­wie­se­nen Speicher. Ein Profil wie 1g.5gb steht also für eine kleine Instanz, während 7g.40gb die gesamte A100 mit 40 GB als eine Instanz nutzt.

Vor- und Nachteile von Multi-Instance GPU

Der zentrale Vorteil von MIG ist die starke Hardware-Iso­lie­rung. Da Rechen- und Spei­cher­res­sour­cen fest zugeteilt werden, lassen sich Workloads deutlich besser von­ein­an­der trennen als bei rein zeit­li­cher GPU-Teilung. Eine stark aus­ge­las­te­te Instanz kann die ihr zu­ge­wie­se­nen Res­sour­cen voll­stän­dig nutzen, soll aber die Spei­cher­band­brei­te, den L2-Cache-Anteil und die Re­chen­res­sour­cen anderer Instanzen nicht ver­drän­gen. Dadurch eignet sich MIG besonders für planbare, man­dan­ten­fä­hi­ge Um­ge­bun­gen mit mehreren par­al­le­len KI-, Inferenz- oder HPC-Workloads.

MIG kann außerdem mit NVIDIA vGPU kom­bi­niert werden. Bei einer so­ge­nann­ten MIG-backed vGPU werden die Hardware-Par­ti­tio­nen von MIG in eine vir­tua­li­sier­te Umgebung ein­ge­bun­den. Dadurch lassen sich die Vorteile fester GPU-Par­ti­tio­nen mit VM-basierten Be­triebs­mo­del­len kom­bi­nie­ren.

Tech­ni­sche Ein­schrän­kun­gen von Multi-Instance GPU

MIG ver­bes­sert die Isolation und Plan­bar­keit gegenüber klas­si­scher vGPU deutlich, ist jedoch an bestimmte Hardware, feste Profile und einige ar­chi­tek­to­ni­sche Grenzen gebunden:

• Nur auf be­stimm­ten GPUs verfügbar: MIG wird nicht von jeder NVIDIA-GPU un­ter­stützt. Vor allem Consumer-GPUs und viele ältere Work­sta­tion-Karten bieten diese Funktion nicht. Verfügbar ist MIG auf aus­ge­wähl­ten Dat­a­cen­ter- und neueren Pro­fes­sio­nal-GPUs.
• Feste Pro­fil­grö­ßen: Die Auf­tei­lung ist nicht beliebig fein wählbar. Ad­mi­nis­tra­to­ren müssen aus den von NVIDIA vor­ge­se­he­nen Profilen wählen, zum Beispiel 1g.5gb, 2g.10gb oder 7g.40gb bei der A100 mit 40 GB Speicher.
• Begrenzte Anzahl an Instanzen: Je nach GPU sind bis zu sieben Instanzen möglich. Einige MIG-fähige Modelle un­ter­stüt­zen weniger parallele Instanzen.
• Re­kon­fi­gu­ra­ti­on nur ein­ge­schränkt dynamisch: MIG-Instanzen lassen sich verwalten und neu anlegen, aber Än­de­run­gen an der Auf­tei­lung setzen voraus, dass die be­trof­fe­nen Instanzen nicht aktiv genutzt werden. Das Ak­ti­vie­ren des MIG-Modus kann je nach GPU-Ge­ne­ra­ti­on und Plattform zu­sätz­lich einen GPU-Reset erfordern.
• Kein Bursting über Pro­fil­gren­zen hinweg: Eine MIG-Instanz kann nur die Res­sour­cen nutzen, die ihrem Profil zu­ge­wie­sen wurden. Freie Kapazität einer anderen Instanz steht ihr nicht au­to­ma­tisch zur Verfügung.
• Ein­ge­schränk­te P2P- und Multi-GPU-Kom­mu­ni­ka­ti­on: MIG ist auf isolierte GPU-Par­ti­tio­nen ausgelegt. CUDA-IPC über ver­schie­de­ne GPU-Instanzen hinweg und NCCL werden laut NVIDIA nicht un­ter­stützt. P2P ist nur in engen Grenzen möglich, z. B. mit neueren Treibern zwischen MIG-Instanzen auf derselben GPU. Für Workloads, die NVLink, NVSwitch oder NCCL-basiertes Multi-GPU-Training benötigen, ist MIG daher meist nicht geeignet.

Ein­satz­sze­na­ri­en und Ent­schei­dungs­hil­fe

Welche Tech­no­lo­gie am besten passt, hängt vor allem von drei Fragen ab:

• Wird die maximale Leistung einer ganzen GPU benötigt?
• Müssen Workloads oder Mandanten zu­ver­läs­sig von­ein­an­der isoliert werden?
• Soll eine GPU möglichst effizient von mehreren VMs oder Nutzern geteilt werden?

Als Faust­re­gel gilt:

• Maximale Leistung für eine einzelne VM: GPU-Pass­th­rough
• Viele parallele Nutzer mit moderatem GPU-Bedarf: vGPU
• Mehrere KI-, Inferenz- oder HPC-Workloads mit planbarer Leistung: MIG oder MIG-backed vGPU

Wann sich GPU-Pass­th­rough eignet

GPU-Pass­th­rough eignet sich besonders dann, wenn eine einzelne VM die volle Leistung einer phy­si­schen GPU benötigt. Typische Beispiele sind:

• High-End-Work­sta­tions
• GPU-in­ten­si­ves Rendering
• CAD- und CAE-An­wen­dun­gen
• Einzelne Trai­nings­jobs, die eine komplette Karte auslasten

In solchen Fällen steht Per­for­mance im Vor­der­grund, während Sharing keine oder nur eine un­ter­ge­ord­ne­te Rolle spielt.

Der Nachteil: Die GPU ist exklusiv an eine VM gebunden. Dadurch bleibt un­ge­nutz­te Kapazität auf dieser GPU ungenutzt, und Funk­tio­nen wie Live-Migration oder nahtloses Failover sind je nach Plattform stark ein­ge­schränkt.

Wann sich Virtual GPU eignet

Virtual GPU (vGPU) ist sinnvoll, wenn viele User oder VMs jeweils nur einen Teil der GPU-Leistung benötigen. Das ist häufig der Fall bei:

• Vir­tu­el­len Desktops
• Knowledge-Worker-Um­ge­bun­gen
• Tech­ni­schen Ar­beits­plät­zen mit moderatem Gra­fik­be­darf oder leichter KI-Inferenz

vGPU erhöht die Man­dan­ten­dich­te und ver­bes­sert die Aus­las­tung teurer GPU-Hardware. Der Vorteil liegt in der Fle­xi­bi­li­tät: Mehrere VMs können dieselbe physische GPU nutzen. Der Nachteil ist, dass die Re­chen­res­sour­cen bei klas­si­schen vGPU-Kon­fi­gu­ra­tio­nen zeitlich geteilt werden. Bei hoher gleich­zei­ti­ger Last kann es daher zu Kon­kur­renz um GPU-Zeit kommen. Scheduler wie Equal Share oder Fixed Share können das abmildern, bieten aber keine voll­stän­di­ge Hardware-Isolation.

Wann sich Multi-Instance GPU eignet

Multi-Instance GPU (MIG) ist vor allem dann in­ter­es­sant, wenn mehrere Workloads auf einer GPU laufen sollen, aber trotzdem feste und planbare Res­sour­cen benötigen. Typische Ein­satz­be­rei­che sind:

• Man­dan­ten­fä­hi­ge KI-Inferenz
• Ent­wick­lungs- und Test­um­ge­bun­gen für mehrere Teams
• Kleinere Trainings-Sandboxes
• Cloud-Angebote mit ga­ran­tier­ten GPU-Profilen

MIG par­ti­tio­niert un­ter­stütz­te NVIDIA-GPUs auf Hard­ware­ebe­ne. Jede Instanz erhält fest zu­ge­wie­se­ne Rechen- und Spei­cher­res­sour­cen. Dadurch lassen sich Workloads besser von­ein­an­der trennen als bei klas­si­schem Time-Slicing. Das macht MIG besonders geeignet für Um­ge­bun­gen, in denen hohe Aus­las­tung und starke Isolation gleich­zei­tig wichtig sind.

In vir­tua­li­sier­ten Um­ge­bun­gen kann MIG außerdem mit vGPU kom­bi­niert werden. Bei MIG-backed vGPU werden die Hardware-Par­ti­tio­nen von MIG in VMs ein­ge­bun­den. So lassen sich feste GPU-Profile mit einem vir­tua­li­sier­ten Be­triebs­mo­dell verbinden.