Lizenzfreies Windows-VDI auf Proxmox mit einer Intel Arc Pro B50 — und die Firmware-Grenze, die es gestoppt hat

Warum das bis jetzt teuer war

VDI — Virtual Desktop Infrastructure — liefert einen vollständigen Desktop aus einem Rechenzentrum oder aus der Cloud statt von dem Gerät vor dir. Ein Nutzer meldet sich von einem Laptop, einem Thin Client oder der eigenen Maschine an und bekommt einen bekannten Windows- oder Linux-Desktop, dessen Anwendungen, Dateien und Rechenarbeit alle zentral passieren.

Für ein IT-Team ist daran reizvoll, dass Aktualisierung, Zugriffssteuerung und Datenschutz alle an einer Stelle passieren und Leute denselben Desktop von überall erreichen können.

Das Hindernis war nie der Hypervisor. Es war die GPU.

Eine physische GPU zwischen mehreren Desktops zu teilen war NVIDIAs Gebiet, und NVIDIA verlangt Geld für die vGPU-Software, die das Teilen macht. Diese Lizenz ist der Grund, warum VDI mit hardwarebeschleunigter Grafik meist Sache von Häusern mit Konzernbudget war. Eine Jahresgebühr dafür zu zahlen, etwas anzuschalten, was das Silizium schon kann, ist schwer zu mögen.

Intel hat die Rechnung mit der Arc-Pro-Reihe verändert. Diese Karten unterstützen das Teilen in Hardware über normales SR-IOV, und das ist eine PCIe-Funktion und kein Produkt. Damit gibt es keinen Lizenzserver, kein Abo und keine getrennte vGPU-Software zu kaufen.

Also habe ich mir eine Intel Arc Pro B50 besorgt, um zu sehen, wie sauber das mit Proxmox zusammengeht. Die kurze Antwort: der Mechanismus arbeitet genau wie versprochen, und dann kam Firmware in den Weg. Beide Hälften stehen unten.

Der Elefant: du brauchst zuerst Windows

Bevor irgendetwas davon geht, will die Karte eine Firmware-Aktualisierung. Intel liefert die im Windows-Treiberpaket aus.

Was unangenehm ist, denn der Grund, warum du die Karte gekauft hast, ist, sie unter Proxmox zu betreiben.

Es gibt einen Weg darum herum, der nichts als Proxmox braucht: bau eine Windows-VM, reich die ganze Karte an sie durch, lass Windows die Firmware aktualisieren, und gib die Karte dann an den Host zurück. Es ist eine Bootstrap-Schleife, und es lohnt sich, davon zu wissen, bevor du den Aufbau planst, und nicht danach.

Die Karte finden

Auf dem Proxmox-Host mit lspci suchen:

lspci

Hier ist sie auf 03:00.0, gemeldet als Battlemage G21, das Silizium hinter der Arc Pro B50. Schreib die Adresse auf. Du brauchst sie mehrmals, und dazu gehört eine getrennte Audiofunktion auf 04:00.0.

Die ganze Karte an eine Windows-VM durchreichen

Füge die Karte einer Windows-VM als rohes PCI-Gerät hinzu. In der Hardware der VM ist das ein Eintrag PCI Device: 0000:03:00 mit pcie=1:

Es lohnt sich zu bemerken, was diese VM sonst ist, denn nichts davon ist Zufall: Maschinentyp Q35, Firmware OVMF, VirtIO SCSI single und ein TPM für Windows 11. Q35 ist dafür besonders nicht optional. Eine durchgereichte GPU erscheint auf i440fx als altes PCI-Gerät, und das ist die falsche Form für einen modernen Grafiktreiber. Das steht in Immer Q35, nicht i440fx.

Starte die VM und prüf, ob Windows die Karte sieht:

Sie erscheint als Microsoft Basic Display Adapter, weil noch kein Treiber installiert ist. Das ist der erwartete Zustand, und es genügt. Windows hat die Hardware gefunden.

Die Firmware aktualisieren

Hol den aktuellen Treiber von Intels Downloadseite für die Arc Pro B50. Zum Zeitpunkt des Schreibens war das Version 32.0.101.8306 (Q4.25), für Windows 11 und Windows 10 22H2:

Installier ihn, und lass die Firmware-Aktualisierung als Teil des Vorgangs laufen, statt vorher abzubrechen. Dieser Firmware-Schritt ist der ganze Grund für diesen Umweg.

Wenn er fertig ist, gib die Karte an den Host zurück und starte neu, damit sie sich unter Proxmox vollständig neu initialisiert.

Bestätigen, dass SR-IOV da ist

Jetzt frag die Karte, was sie kann:

lspci -v

Die Zeile, auf die es ankommt:

Capabilities: [320] Single Root I/O Virtualization (SR-IOV)

Das ist das ganze Angebot in einer Zeile lspci-Ausgabe, ohne Lizenz daran.

Drei andere Dinge in dieser Ausgabe sind es wert, gleich mitgelesen zu werden:

• Kernel driver in use: xe — die Karte läuft auf Intels neuerem xe-Treiber statt auf i915, und der wird die virtuellen Funktionen anlegen.
• [420] Physical Resizable BAR und [220] Virtual Resizable BAR — die Karte kann veränderbare BARs, und ihre virtuellen Funktionen auch. Es lohnt sich zu wissen, was dich das an Adressraum kostet, wenn du mehrere davon durchreichst: siehe PCIe Resizable BAR und moderne GPUs.
• IOMMU group 13 — die Karte sitzt in einer eigenen Gruppe, und das willst du für sauberes Passthrough. Warum das zählt, steht in dem Beitrag über die IOMMU-Steuer.

Die virtuellen Funktionen beim Start anlegen

Virtuelle Funktionen bleiben nicht über Neustarts erhalten. Sie zu verlangen ist ein Schreibvorgang in sysfs, das muss also bei jedem Start passieren.

tmpfiles.d ist ein ordentlicher Weg, das erklärend zu tun, statt ein Skript an eine Unit-Datei zu schrauben:

Die Datei erledigt drei Aufgaben in dieser Reihenfolge.

Die virtuellen Funktionen anlegen, indem die Anzahl in sriov_numvfs der physischen Funktion geschrieben wird:

w /sys/devices/pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:01.0/0000:03:00.0/sriov_numvfs  - - - -  4

Jede neue Funktion von xe lösen, denn der Host-Treiber beansprucht sie, sobald sie erscheinen, und ein Gast kann kein Gerät haben, das der Host hält:

w /sys/bus/pci/drivers/xe/unbind - - - - 0000:03:00.1
w /sys/bus/pci/drivers/xe/unbind - - - - 0000:03:00.2
w /sys/bus/pci/drivers/xe/unbind - - - - 0000:03:00.3
w /sys/bus/pci/drivers/xe/unbind - - - - 0000:03:00.4

Sie an vfio-pci binden, und das macht sie zum Durchreichen verfügbar:

w /sys/bus/pci/drivers/vfio-pci/bind - - - - 0000:03:00.1
w /sys/bus/pci/drivers/vfio-pci/bind - - - - 0000:03:00.2
w /sys/bus/pci/drivers/vfio-pci/bind - - - - 0000:03:00.3
w /sys/bus/pci/drivers/vfio-pci/bind - - - - 0000:03:00.4

Achte auf die Adressen: die physische Funktion ist 03:00.0, und die virtuellen kommen als .1 bis .4 hoch.

Eine Einzelheit zu w, die die Reihenfolge erklärt und dich beißt, wenn du sie falsch machst. systemd dokumentiert es so: „Write the argument parameter to a file, if the file exists“ — schreib den Argumentparameter in eine Datei, wenn die Datei existiert. sriov_numvfs existiert erst, wenn ein Treiber an die physische Funktion gebunden ist, und die Pfade der virtuellen Funktionen erst, wenn dieser Schreibvorgang passiert ist. Die Reihenfolge in der Datei ist also nicht Stil. Jede Zeile hängt davon ab, dass die vorige gewirkt hat.

Warum zwei und nicht vier

Der Treiber 32.0.101.8306 — der oben installierte — trägt die Grafik-Firmware BMG__21,1162, und das ist die Ausgabe, in der Intel SR-IOV auf Arc Pro erstmals offiziell freigegeben hat. Intels angegebene Voreinstellung für die B50 in dieser Ausgabe sind zwei virtuelle Funktionen, jede mit einem VF-Local-Memory-BAR von 8 GB.

Damit ist die Zahl Rechnerei und keine Politik. Die B50 hat 16 GB. Bei 8 GB pro virtueller Funktion sind zwei alles, was hineingeht.

Es gibt einen Haken, den man kennen sollte, wenn man nach einem Umweg sucht. Bevor es offizielle Unterstützung gab, haben manche Leute ältere Firmware betrieben, die auf einer B50 12 virtuelle Funktionen zeigte, und der Rückschritt auf Treiber 32.0.101.6979 stellt diese Zahl wieder her. Diese 12 teilten sich dieselben 16 GB, jede bekam also einen Bruchteil des Speichers, den meine bekommen. Intels Haltung ist, dass zwei bewusst gewählt wurde, damit jede Funktion genug Rechenleistung, Kapazität und Bandbreite für vorhersehbares Verhalten hat.

Die Grenze lässt sich also verschieben, aber nicht von dir. Die maximale VF-Zahl und die Größe des VF-Local-Memory-BAR wohnen in der IFWI, es gibt kein öffentliches Werkzeug, eines von beiden zu ändern, und die unterstützte Antwort auf einem aktuellen Stand ist zwei.

Wie viele Desktops jede Karte hergibt

Die B50 ist die kleine Karte der Familie, und ihre zwei Funktionen sind der Tiefpunkt der Familie. Ist die Zahl der Plätze das, worauf es dir ankommt, kauf weiter oben in der Reihe.

Die ganze Battlemage-Arc-Pro-Reihe macht SR-IOV. Verschieden ist, wie viele Funktionen die Firmware herausschneidet, und das folgt dem Speicher:

Nur die Zeile zur B50 ist von Intel dokumentiert. Die Zahlen zu B60 und B70 sind, was Leute aus lspci melden, und sie haben sich mehr als einmal bewegt. Besonders die B60 ging in einer Firmware-Aktualisierung von 24 auf 7 herunter, dieselbe Art Verengung, die die B50 gesehen hat. Zur B65 scheint überhaupt niemand eine VF-Zahl veröffentlicht zu haben, behandle diese Zeile also als unbekannt und nicht als null.

Zwei Dinge folgen aus dieser Tabelle, und beide zählen mehr als jede einzelne Zahl darin.

Die VF-Zahl ist eine Teilung des Speichers, keine Eigenschaft des Chips. Intels Regel ist, dass ein größeres VF-Local-Memory-BAR weniger Funktionen heißt. Deshalb gibt die Karte mit 16 GB zwei und die Karten mit 32 GB sieben: nichts an den Shadern der GPU entscheidet das.

Prüf die Karte, die du kaufen willst, nicht die Familie. Die Anwesenheit von SR-IOV hat zwischen Platinenherstellern auf demselben Chip geschwankt — Sparkles B60 Blower kam zuerst ganz ohne sichtbare Fähigkeit und bekam sie erst nach einer Firmware-Aktualisierung per igsc. Frag nach der Ausgabe von lspci -v vom genauen Modell, oder plane eine Firmware-Aktualisierung ein, bevor du auf irgendetwas davon setzt.

Die Dual B60 sind zwei Karten in einem Blech

Maxsuns Arc Pro B60 Dual 48G Turbo ist die interessante für die Platzzahl, und was man verstehen muss, ist, dass die 48 GB kein gemeinsamer Pool sind.

Es sind zwei B60-GPUs — zwei BMG-G21-Dies — auf einer Platine, mit je 24 GB GDDR6 daran verdrahtet, und ohne PCIe-Bridge-Chip dazwischen. Beide Dies hängen direkt an den x16-Goldfingern, mit je PCIe 5.0 x8.

Das heißt, der Host muss den Slot für dich teilen. Die Karte braucht den primären x16-Slot als x8/x8 aufgeteilt, und die meisten Consumer-Platinen haben das nicht standardmäßig an. Es ist eine Firmware-Einstellung, nach der du suchen musst, in derselben Kategorie wie die IOMMU- und ACS-Einstellungen, die all das braucht.

Mach das richtig, und das Betriebssystem sieht zwei getrennte GPUs, jede mit ihrer eigenen physischen Funktion und ihrer eigenen SR-IOV-Fähigkeit. Du bekommst also zwei Sätze virtueller Funktionen aus einem Slot — 14 Plätze, wenn jedes Die sich wie eine einzelne B60 verhält — und die tmpfiles.d-Datei von oben verdoppelt sich, ein sriov_numvfs-Schreibvorgang pro Die.

Mach es falsch, und du siehst eine GPU, und die halbe Karte ist unsichtbar.

Es lohnt sich, klar zu sagen, was die 48 GB nicht sind: ein Gast an einer virtuellen Funktion des ersten Die kommt nicht an den Speicher des zweiten. Das sind zwei Karten mit 24 GB in einem physischen Raum, und das ist genau, was du für VDI-Plätze willst, und genau, was du für ein großes Modell nicht willst.

Also: sind zwei Plätze genug, ist die B50 eine 70-W-Karte, die das kann. Willst du sieben, plane um eine B70. Willst du vierzehn und hast eine Platine, die aufteilt, bringt dich die Dual B60 in einem Slot dorthin.

Kann man KI auf einer virtuellen Funktion betreiben?

Kurze Antwort: behandle es als nicht unterstützt. Längere Antwort, denn der Grund zählt, und er ist nicht der, den du erwarten würdest.

Diese Karten werden als KI-Karten vermarktet, und das ist keine Verstellung. Die 128 XMX-Einheiten der B50 sind mit 170 TOPS Spitze angegeben, die B70 mit 367, und Intels Software-Geschichte ist echt — vLLM liefert auf Arc Pro der B-Reihe Modelle von 8B bis 120B aus, und IPEX-LLM und das SYCL-Backend von llama.cpp laufen beide darauf.

Aber sieh nach, wie jedes dieser Ergebnisse zustande kommt. vLLMs eigene Arc-Pro-Zahlen kommen aus einem Docker-Container auf Blech, auf Systemen mit vier und acht ganzen B60-Karten, die Tensor-Parallelität machen. Intels Beitrag erwähnt SR-IOV oder virtuelle Funktionen kein einziges Mal.

Dieses Muster hält überall, wo ich nachgesehen habe. Intel begrenzt die Anwendungsfälle für SR-IOV auf virtualisierte Fernarbeitsplätze, Grafikbeschleunigung im Gast-Betriebssystem und Medien-Encoding und -Decoding. Rechnen steht nicht auf dieser Liste, und ich konnte keinen einzigen veröffentlichten Fall finden, in dem jemand LLM-Inferenz in einer VM an einer virtuellen Funktion betreibt.

Was Leute tatsächlich tun, ist vielsagend: sie betreiben das Modell in Docker auf dem Host und geben virtuelle Funktionen an VMs für Desktops. Eine Person, die beides gleichzeitig macht, berichtet bloß, dass „VRAM gets pretty tight“ — der VRAM wird ziemlich knapp.

Und das ist das eigentliche Problem, und es ist Rechnerei und keine Frage der Treiberunterstützung.

Eine virtuelle Funktion bekommt eine feste Scheibe lokalen Speichers — 8 GB auf der B50, in der Firmware festgelegt. Diese Scheibe ist die harte Decke für Gewichte plus KV-Cache in diesem Gast, und sie wächst nicht, weil die Karte mehr hat. Ein 8B-Modell in FP16 sind rund 16 GB Gewichte, bevor du irgendeinen Kontext dazunimmst, es passt also auf keinem Treiber in eine virtuelle Funktion einer B50. Quantisiere auf Q4, und ein 8B passt in etwa 4 GB und lässt ein paar GB für Kontext — was geht, aber weit von dem entfernt ist, was die Karte ungeteilt kann.

Die zwei Lasten konkurrieren also um denselben Speicher, und die Teilung wird in der Firmware entschieden, bevor eine von beiden anfängt.

Ist KI die Aufgabe, teile die Karte nicht. Reich das Ganze an eine VM durch — dasselbe hostpci0-Passthrough, das oben in diesem Beitrag für die Firmware-Aktualisierung genutzt wurde — oder betreibe den Container auf dem Host und lass die Virtualisierung für diese Last weg. Beides gibt dem Modell alle 16 GB und das ganze XMX-Feld.

Ist VDI die Aufgabe, sind virtuelle Funktionen richtig, und erwarte hinter jeder Desktop-Grafik statt eines Inferenzservers. Hardwarebeschleunigte Desktops, Videowiedergabe und Encoding gehen. Dafür ist der Mechanismus dokumentiert.

Klar gesagt: fehlende veröffentlichte Belege sind kein Beweis, dass es scheitert. Der xe-Treiber legt Rechenleistung über Level Zero und OpenCL offen, und es ist gut möglich, dass ein Gast an einer VF die sauber hochbringt. Aber nichts von Intel sagt, dass es geprüft ist, niemand scheint es gezeigt zu haben, und die Speicherdecke begrenzt den Gewinn, selbst wenn es geht. Darauf baut man keinen Plan.

Was es trotzdem wert ist

Zwei virtuelle Funktionen sind zwei hardwarebeschleunigte Windows-Desktops aus einer Karte, ohne vGPU-Lizenz, ohne Abo und ohne Lizenzserver. Auf einem Hypervisor, dessen Betrieb nichts kostet. Das genügt, um zu zeigen, dass der Weg funktioniert, und das ist die ehrliche Aufgabe einer B50. Sie ist das untere Ende der Reihe.

Für eine echte VDI-Installation würde ich die Dual B60 vorsehen.

Vierzehn Funktionen aus einem Slot — wenn jedes Die sich wie eine einzelne B60 verhält — setzt sie bei der Platzzahl in dieselbe Gegend wie die NVIDIA-Karten, die für diese Arbeit verkauft werden, bei weit niedrigerem Preis und ohne etwas, das pro Nutzer zu lizenzieren wäre. Der letzte Teil ist der, der sich aufsummiert. NVIDIAs vApps, vPC und RTX vWS werden alle pro gleichzeitigem Nutzer lizenziert, entweder als Jahresabo oder als dauerhafte Lizenz, die zusammen mit einem fünfjährigen Abo für Unterstützung und Pflege gekauft werden muss. Jeder Platz ist eine Position, und sie kommt wieder. Auf der Intel-Seite gibt es keine entsprechende Position. Du kaufst die Karte.

Und der Mechanismus ist der Teil, der langfristig zählt. SR-IOV auf der GPU ist eine PCIe-Fähigkeit und keine Produktstufe, die tmpfiles.d-Datei wächst also einfach mit, was die Karte zulässt.

Die Form ist ein sriov_numvfs-Schreibvorgang, dann ein Lösen und ein Binden pro Funktion — zwei Funktionen sind also fünf Zeilen, und die neun oben sind vier Funktionen, verlangt auf einer Karte, die zwei liefert. Sieben Funktionen sind fünfzehn Zeilen. Eine Dual B60 sind dreißig, denn jedes Die ist seine eigene physische Funktion und bekommt seinen eigenen sriov_numvfs-Schreibvorgang.

Nichts sonst ändert sich, wenn du es hochskalierst. An keiner Stelle dieser Datei erscheint ein Lizenzserver.

Quellen

• Intel Support — warum die neueste Arc-Pro-B50-Firmware 2 SR-IOV-VFs zeigt — die maßgebliche Aussage: SR-IOV offiziell freigegeben ab Grafik-Firmware BMG__21,1162 im Treiber 32.0.101.8306, zwei VFs mit je 8 GB VF-Local-Memory-BAR auf der B50, und maximale VF-Zahl und BAR-Größe auf IFWI-Ebene festgelegt, ohne öffentliches Werkzeug, sie zu ändern
• Intel Community — „Why did the latest Intel Arc Pro B50 firmware nerf SR-IOV VFs from 12 to 2?“ — die Firmware mit 12 VFs vor der offiziellen, der Rückschritt auf 32.0.101.6979, der sie wiederherstellt, und Intels Begründung für die niedrigere Voreinstellung
• Level1Techs — B60-SR-IOV-Unterstützung in den Arc-Pro-Treibern — lspci-Meldungen aus dem Feld zur B60, die igsc-Firmware-Aktualisierung, die die Fähigkeit offenlegte, und woher die Zahlen 24 und dann 7 kommen
• Level1Techs — B50, B60 oder B70 für SR-IOV — die gemeldeten VF-Zahlen pro Karte und pro Firmware, Quelle für die B70-Zeilen
• ASRock — Intel Arc Pro B65 Creator 32GB — die Daten der B65: 32 GB GDDR6, 20 Compute Units, 160 XMX-Einheiten, 256 Bit, PCIe 5.0
• MAXSUN — Arc Pro B60 Dual 48G Turbo — die eigene Aussage des Herstellers, dass die Karte „uses PCIe 5.0 x8 + x8 interfaces and runs efficiently on consumer platforms that support PCIe x16 lane bifurcation“
• vLLM — Fast and affordable LLM serving on Intel Arc Pro B-Series — die KI-Geschichte dieser Karten, und die Tatsache, dass es eine Geschichte von Docker auf Blech über vier und acht ganze B60 ist, ohne jede Erwähnung von SR-IOV oder virtuellen Funktionen
• Linux-Kernel — Intel-Xe-Treiber — der Treiber, der laut lspci -v auf der Karte läuft
• tmpfiles.d(5) — der Zeilentyp w und seine Bedingung „if the file exists“, die die Reihenfolge oben vorgibt
• NVIDIA Virtual GPU Software Packaging, Pricing and Licensing Guide — die lizenzierte Alternative, die dieser Entwurf vermeidet: vApps, vPC und RTX vWS alle pro gleichzeitigem Nutzer verkauft, als Jahresabo oder als dauerhafte Lizenz samt fünf Jahren Unterstützung und Pflege
• Proxmox VE — PCI(e) Passthrough — die Anforderungen an Passthrough auf der Host-Seite