VDI Windows sans licence sur Proxmox avec un Intel Arc Pro B50 — et la limite de micrologiciel qui l'a arrêté

Pourquoi cela a été cher jusqu’ici

Le VDI — Virtual Desktop Infrastructure — livre un bureau complet depuis un centre de données ou une instance cloud plutôt que depuis l’appareil devant vous. Un utilisateur se connecte depuis un portable, un client léger ou sa propre machine, et obtient un bureau Windows ou Linux familier dont les applications, les fichiers et le traitement se font tous de façon centralisée.

L’attrait pour une équipe informatique est que les correctifs, le contrôle d’accès et la protection des données se font tous au même endroit, et que les gens peuvent atteindre le même bureau de partout.

L’obstacle n’a jamais été l’hyperviseur. C’était le GPU.

Partager un GPU physique entre plusieurs bureaux a été le territoire de NVIDIA, et NVIDIA facture le logiciel vGPU qui fait le découpage. Cette licence est la raison pour laquelle le VDI avec graphismes accélérés par le matériel a surtout été l’apanage des structures aux budgets d’entreprise. Payer une redevance annuelle pour allumer quelque chose que le silicium sait déjà faire est une chose difficile à trouver enthousiasmante.

Intel a changé l’arithmétique avec la gamme Arc Pro. Ces cartes prennent en charge le découpage matériel par SR-IOV standard, qui est une fonction PCIe plutôt qu’un produit. À ce titre, il n’y a pas de serveur de licences, pas d’abonnement, et pas de logiciel vGPU séparé à acheter.

J’ai donc mis la main sur un Intel Arc Pro B50 pour voir avec quelle propreté il s’assemble avec Proxmox. La réponse courte : le mécanisme marche exactement comme annoncé, puis le micrologiciel s’est mis en travers. Les deux moitiés sont ci-dessous.

L’éléphant : il vous faut Windows d’abord

Avant que tout cela marche, la carte veut que son micrologiciel soit mis à jour. Intel livre cette mise à jour dans l’installeur du pilote Windows.

Ce qui est gênant, parce que la raison pour laquelle vous avez acheté la carte est de la faire tourner sous Proxmox.

Il y a un contournement qui n’a besoin que de Proxmox : montez une VM Windows, passez-lui la carte entière, laissez Windows mettre à jour le micrologiciel, puis rendez la carte à l’hôte. C’est une boucle d’amorçage, et il vaut de la connaître avant de planifier le montage plutôt qu’après.

Trouver la carte

Sur l’hôte Proxmox, lspci pour la localiser :

lspci

La voici à 03:00.0, rapportée comme Battlemage G21, le silicium derrière l’Arc Pro B50. Notez l’adresse. Vous en aurez besoin plusieurs fois, et il y a une fonction audio séparée à 04:00.0 qui l’accompagne.

Passer la carte entière à une VM Windows

Ajoutez la carte à une VM Windows comme périphérique PCI brut. Dans le matériel de la VM, c’est une entrée PCI Device : 0000:03:00 avec pcie=1 :

Il vaut de remarquer ce que cette VM est par ailleurs, parce que rien n’y est accidentel : type de machine Q35, micrologiciel OVMF, VirtIO SCSI single, et un TPM pour Windows 11. Q35 en particulier n’est pas optionnel ici. Un GPU passé sur i440fx apparaît comme un périphérique PCI hérité, qui est la mauvaise forme pour un pilote graphique moderne. C’est traité dans Toujours utiliser Q35, pas i440fx.

Démarrez la VM et vérifiez que Windows voit la carte :

Elle apparaît comme un Microsoft Basic Display Adapter parce qu’aucun pilote n’est encore installé. C’est l’état attendu, et cela suffit. Windows a trouvé le matériel.

Mettre à jour le micrologiciel

Prenez le pilote à jour depuis la page de téléchargement Arc Pro B50 d’Intel. Au moment d’écrire, c’était la version 32.0.101.8306 (Q4.25), pour Windows 11 et Windows 10 22H2 :

Installez-le, et laissez la mise à jour du micrologiciel se dérouler dans le processus plutôt que d’annuler trop tôt. Cette étape de micrologiciel est toute la raison de ce détour.

Quand elle finit, rendez la carte à l’hôte et redémarrez, pour qu’elle se réinitialise pleinement sous Proxmox.

Confirmer que le SR-IOV est là

Demandez maintenant à la carte ce qu’elle sait faire :

lspci -v

La ligne qui compte :

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

C’est toute la proposition en une ligne de sortie de lspci, sans aucune licence attachée.

Trois autres choses dans cette sortie valent d’être lues pendant que vous y êtes :

• Kernel driver in use: xe — la carte est sur le pilote xe plus récent d’Intel plutôt que sur i915, et c’est lui qui créera les fonctions virtuelles.
• [420] Physical Resizable BAR et [220] Virtual Resizable BAR — la carte prend en charge les BAR redimensionnables, et ses fonctions virtuelles aussi. Il vaut de savoir ce que cela vous coûte en espace d’adressage si vous en passez plusieurs : voir PCIe Resizable BAR et les GPU modernes.
• IOMMU group 13 — la carte est dans un groupe à elle, ce qui est ce que vous voulez pour un passthrough propre. Pourquoi cela compte est dans l’article sur la taxe IOMMU.

Créer les fonctions virtuelles au démarrage

Les fonctions virtuelles ne sont pas persistantes. Les demander est une écriture dans sysfs, donc cela doit se faire à chaque démarrage.

tmpfiles.d est une façon propre de faire cela de façon déclarative, plutôt que de boulonner un script sur un fichier d’unité :

Le fichier fait trois tâches dans l’ordre.

Créer les fonctions virtuelles, en écrivant le nombre dans le sriov_numvfs de la fonction physique :

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

Détacher chaque nouvelle fonction de xe, parce que le pilote de l’hôte les réclame dès qu’elles apparaissent et qu’un invité ne peut pas avoir un périphérique que l’hôte tient :

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

Les lier à vfio-pci, qui est ce qui les rend disponibles pour le passthrough :

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

Notez les adresses : la fonction physique est 03:00.0 et les fonctions virtuelles apparaissent de .1 à .4.

Un détail sur w qui explique l’ordre, et qui vous mordra si vous vous trompez. systemd le documente ainsi : « Write the argument parameter to a file, if the file exists. » sriov_numvfs n’existe qu’une fois qu’un pilote s’est lié à la fonction physique, et les chemins des fonctions virtuelles n’existent qu’une fois cette écriture faite. La séquence dans le fichier n’est donc pas stylistique. Chaque ligne dépend de ce que la précédente ait pris effet.

Pourquoi deux, et pas quatre

Le pilote 32.0.101.8306 — celui installé plus haut — porte le micrologiciel graphique BMG__21,1162, et c’est la version où Intel a d’abord officiellement activé le SR-IOV sur Arc Pro. Le défaut annoncé par Intel pour le B50 dans cette version est deux fonctions virtuelles, chacune avec un BAR de mémoire locale VF de 8 Go.

Ce qui fait du nombre de l’arithmétique plutôt qu’une politique. Le B50 a 16 Go. À 8 Go par fonction virtuelle, deux est tout ce qui tient.

Il y a une subtilité à connaître si vous cherchez un contournement. Avant que le support officiel existe, certains ont fait tourner un micrologiciel plus ancien qui exposait 12 fonctions virtuelles sur un B50, et revenir au pilote 32.0.101.6979 restaure ce nombre. Ces 12 partageaient les mêmes 16 Go, donc chacune avait une fraction de la mémoire que les miennes ont. La position d’Intel est que deux a été choisi délibérément pour donner à chaque fonction assez de calcul, de capacité et de bande passante pour se comporter de façon prévisible.

Le plafond peut donc être déplacé, mais pas par vous. Le nombre maximum de VF et la taille du BAR de mémoire locale VF vivent dans l’IFWI, il n’y a pas d’outil public pour changer l’un ou l’autre, et la réponse prise en charge sur une pile à jour est deux.

Combien de bureaux chaque carte vous donne

Le B50 est la petite carte de la famille, et ses deux fonctions sont le plancher de la famille. Si le nombre de sièges est ce qui vous importe, achetez plus haut dans la gamme.

Toute la gamme Battlemage Arc Pro fait du SR-IOV. Ce qui diffère, c’est combien de fonctions le micrologiciel taillera, et cela suit la mémoire :

Seule la ligne du B50 est documentée par Intel. Les nombres du B60 et du B70 sont ceux que les gens rapportent de lspci, et ils ont bougé plus d’une fois. Le B60 en particulier est passé de 24 à 7 dans une mise à jour de micrologiciel, ce qui est le même genre de resserrement que le B50 a connu. Personne ne semble avoir publié de nombre de VF pour le B65 du tout, donc traitez cette ligne comme inconnue plutôt que comme zéro.

Deux choses découlent de ce tableau, et les deux comptent plus qu’aucun nombre isolé dedans.

Le nombre de VF est une division de mémoire, pas une fonction du die. La règle d’Intel est qu’un BAR de mémoire locale VF plus grand veut dire moins de fonctions. C’est pourquoi la carte de 16 Go en donne deux et les cartes de 32 Go en donnent sept : rien dans les shaders du GPU ne le décide.

Vérifiez la carte que vous êtes sur le point d’acheter, pas la famille. La présence du SR-IOV a varié entre fabricants de cartes sur la même puce — le B60 Blower de Sparkle est d’abord sorti sans la capacité visible du tout et ne l’a gagnée qu’après une mise à jour de micrologiciel igsc. Demandez la sortie de lspci -v du modèle exact, ou budgétez une mise à jour de micrologiciel avant de compter sur tout cela.

Le B60 Dual, ce sont deux cartes portant un seul support

Le B60 Dual 48G Turbo de Maxsun est l’intéressant pour le nombre de sièges, et la chose à comprendre est que les 48 Go ne sont pas un pool.

Ce sont deux GPU B60 — deux dies BMG-G21 — sur une carte, avec 24 Go de GDDR6 câblés à chacun, et aucune puce de pont PCIe entre eux. Les deux dies pendent droit aux doigts dorés x16 à PCIe 5.0 x8 chacun.

Ce qui veut dire que l’hôte doit découper l’emplacement pour vous. La carte a besoin que l’emplacement x16 primaire soit bifurqué en x8/x8, et la plupart des cartes grand public ne l’activent pas par défaut. C’est un réglage de micrologiciel que vous allez chercher, dans la même catégorie que les réglages IOMMU et ACS dont tout ceci a besoin.

Faites-le bien et le système d’exploitation voit deux GPU séparés, chacun avec sa propre fonction physique et sa propre capacité SR-IOV. Vous obtenez donc deux lots de fonctions virtuelles depuis un emplacement — 14 sièges si chaque die se comporte comme un seul B60 — et le fichier tmpfiles.d ci-dessus double, une écriture sriov_numvfs par die.

Faites-le mal et vous voyez un GPU et la moitié de la carte est invisible.

Il vaut d’être clair sur ce que les 48 Go ne sont pas : un invité attaché à une fonction virtuelle sur le premier die ne peut pas atteindre la mémoire du second die. Ce sont deux cartes de 24 Go dans un seul espace physique, ce qui est exactement ce que vous voulez pour des sièges VDI et exactement ce que vous ne voulez pas pour un seul gros modèle.

Donc : si deux sièges suffisent, le B50 est une carte de 70 W qui le fera. Si vous en voulez sept, planifiez autour d’un B70. Si vous en voulez quatorze et avez une carte qui bifurque, le B60 Dual vous y mène en un seul emplacement.

Peut-on faire de l’IA sur une fonction virtuelle ?

Réponse courte : traitez-le comme non pris en charge. Réponse plus longue, parce que la raison compte et n’est pas celle que vous devineriez.

Ce sont des cartes vendues comme cartes d’IA et elles ne font pas semblant. Les 128 moteurs XMX du B50 sont notés à 170 TOPS de pointe, le B70 à 367, et l’histoire logicielle d’Intel est réelle — vLLM sert des modèles de 8B jusqu’à 120B sur les Arc Pro série B, et IPEX-LLM et le backend SYCL de llama.cpp tournent tous deux dessus.

Mais regardez comment chacun de ces résultats est produit. Les propres chiffres Arc Pro de vLLM viennent d’un conteneur Docker sur métal nu, sur des systèmes avec quatre et huit cartes B60 entières faisant du parallélisme de tenseurs. Le billet d’Intel ne mentionne le SR-IOV ni les fonctions virtuelles pas une seule fois.

Ce schéma tient partout où j’ai regardé. Intel cantonne les cas d’usage du SR-IOV au bureau distant virtualisé, à l’accélération graphique du système invité, et à l’encodage et au décodage média. Le calcul n’est pas sur cette liste, et je n’ai pas pu trouver un seul cas publié de quiconque faisant tourner de l’inférence LLM dans une VM attachée à une fonction virtuelle.

Ce que les gens font réellement est parlant : ils font tourner le modèle dans Docker sur l’hôte, et remettent des fonctions virtuelles aux VM pour les bureaux. Une personne faisant les deux à la fois rapporte simplement que « VRAM gets pretty tight » — la VRAM devient assez juste.

Ce qui est le vrai problème, et c’est de l’arithmétique plutôt qu’un support de pilote.

Une fonction virtuelle obtient une tranche fixe de mémoire locale — 8 Go sur le B50, fixé dans le micrologiciel. Cette tranche est le plafond dur pour les poids plus le cache KV dans cet invité, et elle ne grandit pas parce que la carte en a plus. Un modèle 8B en FP16 fait environ 16 Go de poids avant que vous n’ajoutiez le moindre contexte, donc il ne tient pas dans une fonction virtuelle de B50 sur aucun pilote. Quantifiez en Q4 et un 8B tient dans environ 4 Go, laissant quelques Go pour le contexte — ce qui marche, mais est loin de ce que la carte sait faire non divisée.

Les deux charges se disputent donc la même mémoire, et le partage est décidé dans le micrologiciel avant qu’aucune des deux ne démarre.

Si l’IA est le travail, ne divisez pas la carte. Passez le tout à une seule VM — le même passthrough hostpci0 utilisé pour la mise à jour du micrologiciel plus tôt dans ce billet — ou faites tourner le conteneur sur l’hôte et sautez la virtualisation pour cette charge. Les deux donnent au modèle les 16 Go entiers et tout le réseau XMX.

Si le VDI est le travail, les fonctions virtuelles sont justes, et attendez des graphismes de bureau plutôt qu’un serveur d’inférence derrière chacune. Les bureaux accélérés par le matériel, la lecture vidéo et l’encodage marchent. C’est pour cela que le mécanisme est documenté.

Il vaut de dire clairement : l’absence de preuve publiée n’est pas la preuve que cela échoue. Le pilote xe expose le calcul par Level Zero et OpenCL, et il est tout à fait possible qu’un invité adossé à une VF les amène sans souci. Mais rien d’Intel ne dit que c’est validé, personne ne semble l’avoir montré marchant, et le plafond de mémoire limite le gain même si c’est le cas. Ce n’est pas quelque chose sur quoi bâtir un plan.

Ce que cela vaut quand même

Deux fonctions virtuelles, ce sont deux bureaux Windows accélérés par le matériel depuis une carte, sans licence vGPU, sans abonnement et sans serveur de licences. Sur un hyperviseur dont l’exploitation ne coûte rien. C’est assez pour prouver que l’approche marche, ce qui est le travail honnête d’un B50. C’est le bas de la gamme.

Pour un déploiement VDI réel, je spécifierais le B60 Dual.

Quatorze fonctions depuis un emplacement — si chaque die se comporte comme un seul B60 — le met dans le même territoire de nombre de sièges que les cartes NVIDIA vendues pour cette charge, à un prix bien plus bas, et sans rien à licencier par utilisateur. Cette dernière partie est celle qui compose. Les vApps, vPC et RTX vWS de NVIDIA sont tous licenciés par utilisateur simultané, soit comme abonnement annuel, soit comme licence perpétuelle qui doit être achetée à côté d’un abonnement de support et de maintenance de cinq ans. Chaque siège est une ligne de facture, et elle revient. Côté Intel, il n’y a pas de ligne équivalente. Vous achetez la carte.

Et le mécanisme est la partie qui compte à long terme. Le SR-IOV sur le GPU est une capacité PCIe, pas un palier de produit, donc le fichier tmpfiles.d grandit simplement pour correspondre à ce que la carte permet.

La forme est une écriture sriov_numvfs, puis un unbind et un bind pour chaque fonction — donc deux fonctions font cinq lignes, et les neuf ci-dessus sont quatre fonctions demandées sur une carte qui en livre deux. Sept fonctions font quinze lignes. Un B60 Dual en fait trente, parce que chaque die est sa propre fonction physique et obtient sa propre écriture sriov_numvfs.

Rien d’autre ne change à mesure que vous l’échelonnez. Aucun serveur de licences n’apparaît à aucun moment dans ce fichier.

Références

• Intel support — why the latest Arc Pro B50 firmware shows 2 SR-IOV VFs — l’affirmation qui fait autorité : SR-IOV officiellement activé à partir du micrologiciel graphique BMG__21,1162 dans le pilote 32.0.101.8306, deux VF à un BAR de mémoire locale VF de 8 Go chacune sur le B50, et le nombre maximum de VF et la taille de BAR fixés au niveau IFWI sans outil public pour les changer
• Intel Community — “Why did the latest Intel Arc Pro B50 firmware nerf SR-IOV VFs from 12 to 2?” — le micrologiciel pré-officiel à 12 VF, le retour à 32.0.101.6979 qui le restaure, et le raisonnement d’Intel pour le défaut plus bas
• Level1Techs — B60 SR-IOV support in the Arc Pro drivers — les rapports lspci de terrain pour le B60, la mise à jour de micrologiciel igsc qui a exposé la capacité, et d’où viennent les chiffres 24-puis-7
• Level1Techs — B50, B60 or B70 for SR-IOV — les nombres de VF rapportés par carte et par micrologiciel, source des lignes du B70
• ASRock — Intel Arc Pro B65 Creator 32GB — les spécifications du B65 : 32 Go GDDR6, 20 unités de calcul, 160 moteurs XMX, 256 bits, PCIe 5.0
• MAXSUN — Arc Pro B60 Dual 48G Turbo — l’affirmation du fabricant lui-même que la carte « 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 — l’histoire d’IA sur ces cartes, et le fait que c’est une histoire de Docker-sur-métal-nu sur quatre et huit B60 entiers, sans mention du SR-IOV ni des fonctions virtuelles
• Linux kernel — Intel Xe driver — le pilote en usage sur la carte, d’après lspci -v
• tmpfiles.d(5) — le type de ligne w, et sa condition « if the file exists » qui dicte l’ordre ci-dessus
• NVIDIA Virtual GPU Software Packaging, Pricing and Licensing Guide — l’alternative licenciée que cette conception évite : vApps, vPC et RTX vWS tous vendus par utilisateur simultané, comme abonnement annuel ou comme licence perpétuelle groupée avec cinq ans de support et de maintenance
• Proxmox VE — PCI(e) Passthrough — les exigences de passthrough côté hôte