Auf dem vorhandenen Proxmox-Host ist noch Platz für einen KI-Dienst. Reicht es, eine Grafikkarte einzubauen und eine virtuelle Maschine anzulegen? Das kann eine sinnvolle Lösung sein, wenn GPU-Zuordnung, Host-Ressourcen und Wartung zusammen geplant werden.
Eine physische GPU gehört beim Passthrough einer VM
PCIe-Passthrough gibt einer virtuellen Maschine die Kontrolle über ein physisches Gerät. Die KI-VM verwendet die GPU über ihren eigenen Gasttreiber. Der Host und andere VMs können dieselbe Karte während dieser Zuordnung nicht zugleich für eigene Berechnungen nutzen.
Innerhalb der KI-VM kann ein gemeinsam genutzter Modelldienst mehrere Anfragen bearbeiten. Das ist etwas anderes als die Aufteilung der Karte auf mehrere VMs. Ob eine separate vGPU-Lösung geeignet ist, hängt zusätzlich von GPU, Hypervisor, Treibern, Freigaben und Lizenzierung ab.
Der Vorteil einer VM liegt in einer klar zugeordneten Systemumgebung: Betriebssystem, Modellserver und benötigte Daten können gemeinsam verwaltet werden. Die GPU bleibt dabei ein reales Gerät mit eigenen Voraussetzungen.
Vor dem Einbau die gesamte Hardwarekette prüfen
Die Proxmox-Dokumentation nennt IOMMU-Unterstützung einschließlich Interrupt-Remapping als Voraussetzung. CPU, Mainboard, Firmware und Linux-Unterstützung müssen zusammenpassen. Die Bezeichnung VT-d beziehungsweise AMD-Vi allein ersetzt diesen Abgleich nicht.
Auch die IOMMU-Gruppe des gewählten Steckplatzes ist relevant. Die GPU und ihre zugehörigen Funktionen sollen passend von anderen benötigten Geräten getrennt sein. Die Linux-VFIO-Dokumentation erklärt, warum eine Gruppe die Zuordnungs- und Isolationsgrenze bildet. Ein anderer Steckplatz kann eine andere Gruppierung ergeben.
Zusätzlich werden Platz, elektrische PCIe-Anbindung, Stromversorgung und Kühlung geprüft. Im Gast folgen ein passender GPU-Treiber und die Unterstützung durch den Modelldienst. Für GPU-Passthrough empfiehlt Proxmox üblicherweise q35 mit OVMF/UEFI und PCIe; dafür muss auch die Kartenfirmware geeignet sein. Die konkrete Einstellung richtet sich nach der eingesetzten Hardware.
Vorhandene Kapazität ist ein gemeinsames Budget
Als Planungsbeispiel dient ein vorhandener Virtualisierungshost mit Unternehmensanwendungen und einer zusätzlichen KI-VM. CPU-Zeit, Arbeitsspeicher, Datenträger und Netzwerk bleiben gemeinsame Ressourcen. Ein ungebremster Dokumentenimport oder ein Modellstart soll die übrigen Anwendungen nicht überraschend ausbremsen.
Die VM bekommt deshalb eine nachvollziehbare Ausstattung und Lastgrenzen. Grafikspeicher, Kontextlänge und gleichzeitige Modellanfragen werden gemeinsam getestet. Mehr zugewiesener VM-Arbeitsspeicher vergrößert den physischen VRAM der Karte nicht. CPU-Auslagerung kann das Verhalten ändern und braucht eine eigene Messung.
Für einen fairen Vergleich werden Modellfassung, Eingaben, Kontext und Parallelität festgehalten. Bewertet werden Qualität, erste Antwort, weitere Ausgabe, Wartezeit und die Wirkung auf andere VMs. Eine pauschale Prozentzahl für den Virtualisierungsaufwand wäre ohne diesen konkreten Test wenig hilfreich.
VM oder dedizierte Maschine: Was ändert sich im Betrieb?
| Frage | KI-VM mit GPU-Passthrough | Dedizierter KI-Server |
|---|---|---|
| Ressourcen | GPU fest zugeordnet, andere Host-Ressourcen mit bestehenden VMs abstimmen. | Rechen- und Speicherressourcen stehen dem eigenen System zur Verfügung. |
| Wartung | Gasttreiber, Modellbetrieb und Proxmox-/Host-Updates gemeinsam planen. | Betriebssystem und Modellbetrieb in einem eigenen Wartungsbereich. |
| Hostwechsel | Direkt durchgereichte PCI-Geräte verhindern die reguläre Live-Migration. Für einen gestoppten Umzug passende Zielhardware und Zuordnung prüfen. | Umzug oder Ersatz über einen vorbereiteten Wiederanlauf auf anderer Hardware. |
| Sicherung | VM-Datenträger, Anwendungskonsistenz, Konfiguration und Gerätezuordnung gemeinsam betrachten. | System-/Anwendungsdaten und Wiederherstellung gesondert organisieren. |
| Aufwand | Vorhandene Infrastruktur kann genutzt werden; Integration und zusätzliche Host-Abhängigkeiten mitrechnen. | Eigene Hardware und Standortressourcen einplanen; dafür klarer abgegrenzte Wartung. |
Ein vorhandener Cluster macht eine fest an reale Hardware gebundene KI-VM nicht automatisch unterbrechungsfrei verschiebbar. Für einen Neustart auf einem anderen Knoten werden kompatible GPU-Ressourcen, eine gültige Zuordnung und ein tatsächlich getesteter Ablauf benötigt. Der Serviceanspruch bestimmt, ob diese Vorbereitung ausreicht oder ein weiterer Dienstknoten sinnvoll ist.
Ein Restore soll mehr zeigen als eine startende VM
Eine kopierte virtuelle Festplatte enthält nicht den laufenden Zustand der physischen Grafikkarte. Bei der Wiederherstellung werden deshalb auch Modellstände, Konfiguration, Datenrechte und die erneute Gerätezuordnung geprüft. Ein Snapshot auf demselben Host ersetzt keine getrennte Sicherung.
Zur Abnahme gehören ein normaler VM-Neustart, ein Host-Neustart, ein Treiber-/Kernelwechsel im vorgesehenen Wartungsfenster und ein geplanter Restore. Danach werden eine echte Modellanfrage und die übrigen Anwendungen geprüft. So wird sichtbar, ob das Gerät nach einem Neustart sauber wieder verfügbar ist.
Für einen reinen Rechenbeschleuniger ist kein an der GPU angeschlossener Bildschirm nötig. Die Proxmox-Konsole zeigt nicht einfach den Bildinhalt einer durchgereichten GPU. Der KI-Dienst wird über seine vorgesehene Oberfläche oder API genutzt.
Mit einem begrenzten Pilot die Entscheidung absichern
DAXS klärt zunächst Aufgabe, vorhandenen Host, Nutzungsumfang und akzeptable Unterbrechung. Ein begrenzter Pilot prüft anschließend Gerätezuordnung, fachliche Qualität und Auswirkungen auf den Betrieb. Eine VM, eine eigene Maschine oder ein externer Dienst können je nach Ergebnis passend sein.
Die Proxmox-Einordnung für Unternehmen erklärt die allgemeine Plattformwahl. Die Fachseite zur lokalen LLM-Infrastruktur und der Lasttest-Pilot vertiefen die Dimensionierung. Für den gemeinsamen Dienst ergänzt Ollama und Open WebUI die Architektur.
KI-Betriebsmodell und vorhandene Infrastruktur besprechen.
Quellen: Proxmox: PCIe-Passthrough (externer Link) · Proxmox: Migration virtueller Maschinen (externer Link) · Linux: VFIO und IOMMU-Gruppen (externer Link) · NVIDIA: vGPU-Unterstützungsmatrix (externer Link) · Ollama: Hardware-Unterstützung (externer Link).