VDI de Windows sin licencia en Proxmox con una Intel Arc Pro B50 — y el límite de firmware que lo paró

Por qué esto ha sido caro hasta ahora

VDI — Infraestructura de Escritorio Virtual — entrega un escritorio completo desde un centro de datos o una instancia en la nube en vez de desde el dispositivo que tienes delante. Un usuario inicia sesión desde un portátil, un cliente ligero o su propia máquina, y obtiene un escritorio Windows o Linux familiar cuyas aplicaciones, ficheros y procesamiento ocurren todos de forma central.

El atractivo para un equipo de TI es que el parcheado, el control de acceso y la protección de datos ocurren todos en un solo sitio, y la gente puede llegar al mismo escritorio desde cualquier parte.

El obstáculo nunca ha sido el hipervisor. Ha sido la GPU.

Compartir una GPU física entre varios escritorios ha sido territorio de NVIDIA, y NVIDIA cobra por el software vGPU que hace el troceado. Esa licencia es por lo que el VDI con gráficos acelerados por hardware ha sido casi siempre coto de empresas con presupuestos corporativos. Pagar una cuota anual para encender algo que el silicio ya sabe hacer es difícil de tomarse con ganas.

Intel cambió la aritmética con la línea Arc Pro. Estas tarjetas soportan el troceado por hardware mediante SR-IOV estándar, que es una función de PCIe y no un producto. Como tal, no hay servidor de licencias, ni suscripción, ni software vGPU aparte que comprar.

Así que me hice con una Intel Arc Pro B50 para ver con qué limpieza se junta con Proxmox. La respuesta corta: el mecanismo funciona exactamente como se anuncia, y luego el firmware se puso en medio. Las dos mitades están más abajo.

El elefante: necesitas Windows primero

Antes de que nada de esto funcione, la tarjeta quiere que le actualicen el firmware. Intel entrega esa actualización dentro del instalador del driver de Windows.

Lo cual es incómodo, porque la razón por la que compraste la tarjeta es para usarla bajo Proxmox.

Hay una manera de sortearlo que no necesita más que Proxmox: monta una VM de Windows, pásale la tarjeta entera, deja que Windows actualice el firmware, y luego devuelve la tarjeta al host. Es un bucle de arranque, y vale la pena conocerlo antes de planear el montaje y no después.

Encontrar la tarjeta

En el host de Proxmox, lspci para localizarla:

lspci

Aquí está en 03:00.0, reportada como Battlemage G21, el silicio detrás de la Arc Pro B50. Apunta la dirección. La vas a necesitar varias veces, y hay una función de audio aparte en 04:00.0 que viene con ella.

Pasar la tarjeta entera a una VM de Windows

Añade la tarjeta a una VM de Windows como un dispositivo PCI en bruto. En el hardware de la VM, eso es una entrada PCI Device: 0000:03:00 con pcie=1:

Vale la pena fijarse en qué más es esa VM, porque nada de ello es accidental: tipo de máquina Q35, firmware OVMF, VirtIO SCSI single, y un TPM para Windows 11. Q35 en particular no es opcional para esto. Una GPU pasada por passthrough en i440fx aparece como un dispositivo PCI heredado, que es la forma equivocada para un driver de gráficos moderno. Eso se cubre en Usa siempre Q35, no i440fx.

Arranca la VM y comprueba que Windows ve la tarjeta:

Aparece como un Microsoft Basic Display Adapter porque todavía no hay driver instalado. Ese es el estado esperado, y basta. Windows ha encontrado el hardware.

Actualizar el firmware

Consigue el driver actual desde la página de descargas de la Arc Pro B50 de Intel. En el momento de escribir esto era la versión 32.0.101.8306 (Q4.25), para Windows 11 y Windows 10 22H2:

Instálalo, y deja que la actualización de firmware corra como parte del proceso en vez de cancelarla pronto. Ese paso del firmware es la razón entera de este desvío.

Cuando termine, devuelve la tarjeta al host y reinicia, para que se reinicialice del todo bajo Proxmox.

Confirmar que SR-IOV está ahí

Ahora pregúntale a la tarjeta qué sabe hacer:

lspci -v

La línea que importa:

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

Esa es la propuesta entera en una línea de salida de lspci, sin ninguna licencia atada.

Otras tres cosas en esa salida vale la pena leerlas ya que estás:

• Kernel driver in use: xe — la tarjeta va sobre el driver xe más nuevo de Intel en vez de i915, que es lo que va a crear las funciones virtuales.
• [420] Physical Resizable BAR y [220] Virtual Resizable BAR — la tarjeta soporta BAR redimensionables, y también sus funciones virtuales. Vale la pena saber qué te cuesta eso en espacio de direcciones si vas a pasar varias por passthrough: mira PCIe Resizable BAR y las GPU modernas.
• IOMMU group 13 — la tarjeta está en un grupo para ella sola, que es lo que quieres para un passthrough limpio. Por qué importa eso está en el artículo del impuesto del IOMMU.

Crear las funciones virtuales en el arranque

Las funciones virtuales no son persistentes. Pedirlas es una escritura a sysfs, así que tiene que pasar en cada arranque.

tmpfiles.d es una manera pulcra de hacer eso de forma declarativa, en vez de atornillar un script a un fichero de unidad:

El fichero hace tres trabajos en orden.

Crear las funciones virtuales, escribiendo el número al sriov_numvfs de la función física:

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

Desligar cada función nueva de xe, porque el driver del host las reclama según aparecen y un invitado no puede tener un dispositivo que el host está reteniendo:

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

Ligarlas a vfio-pci, que es lo que las hace disponibles para pasar por 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

Fíjate en las direcciones: la función física es 03:00.0 y las funciones virtuales salen como .1 hasta .4.

Un detalle sobre w que explica el orden, y que te morderá si te equivocas. systemd lo documenta así: «Write the argument parameter to a file, if the file exists.» sriov_numvfs solo existe una vez que un driver se ha ligado a la función física, y las rutas de las funciones virtuales solo existen una vez que esa escritura ha pasado. Así que la secuencia en el fichero no es estilística. Cada línea depende de que la anterior haya surtido efecto.

Por qué dos, y no cuatro

El driver 32.0.101.8306 — el instalado arriba — lleva el firmware de gráficos BMG__21,1162, y esa es la versión donde Intel habilitó por primera vez SR-IOV oficialmente en Arc Pro. El valor por defecto que Intel indica para la B50 en esa versión es dos funciones virtuales, cada una con un BAR de memoria local de VF de 8 GB.

Lo que hace del número aritmética y no política. La B50 tiene 16 GB. A 8 GB por función virtual, dos es todo lo que cabe.

Hay un matiz que vale la pena saber si te pones a buscar un apaño. Antes de que existiera el soporte oficial, algunos corrían firmware más viejo que exponía 12 funciones virtuales en una B50, y volver al driver 32.0.101.6979 restaura ese número. Esas 12 compartían los mismos 16 GB, así que cada una obtenía una fracción de la memoria que obtienen las mías. La postura de Intel es que dos se eligió a propósito para dar a cada función suficiente cómputo, capacidad y ancho de banda para comportarse de forma predecible.

Así que el tope se puede mover, pero no por ti. El número máximo de VF y el tamaño del BAR de memoria local de VF viven en el IFWI, no hay herramienta pública para cambiar ninguno, y la respuesta soportada en una pila actual es dos.

Cuántos escritorios te da cada tarjeta

La B50 es la tarjeta pequeña de la familia, y sus dos funciones son el punto más bajo de la familia. Si lo que te importa es el número de puestos, compra más arriba en la gama.

Toda la línea Battlemage Arc Pro hace SR-IOV. Lo que cambia es cuántas funciones tallará el firmware, y eso sigue a la memoria:

Solo la fila de la B50 está documentada por Intel. Los números de la B60 y la B70 son lo que la gente reporta de lspci, y se han movido más de una vez. La B60 en particular pasó de 24 a 7 en una actualización de firmware, que es el mismo tipo de estrechamiento que vio la B50. Nadie parece haber publicado un número de VF para la B65 en absoluto, así que trata esa fila como desconocida y no como cero.

Dos cosas se siguen de esa tabla, y las dos importan más que cualquier número suelto en ella.

El número de VF es una división de memoria, no una función del chip. La regla de Intel es que un BAR de memoria local de VF más grande significa menos funciones. Por eso la tarjeta de 16 GB da dos y las de 32 GB dan siete: nada de los shaders de la GPU lo decide.

Comprueba la tarjeta que estás a punto de comprar, no la familia. La presencia de SR-IOV ha variado entre fabricantes de placa sobre el mismo chip — la B60 Blower de Sparkle salió al principio sin la capacidad visible en absoluto y solo la ganó tras una actualización de firmware igsc. Pide la salida de lspci -v del modelo exacto, o cuenta con una actualización de firmware antes de fiarte de nada de esto.

La B60 Dual son dos tarjetas con un solo soporte

La Arc Pro B60 Dual 48G Turbo de Maxsun es la interesante para el número de puestos, y lo que hay que entender es que los 48 GB no son un pool.

Son dos GPU B60 — dos dies BMG-G21 — en una placa, con 24 GB de GDDR6 cableados a cada uno, y ningún chip de puente PCIe entre ellos. Los dos dies cuelgan directos de los dedos dorados x16 a PCIe 5.0 x8 cada uno.

Lo que significa que el host tiene que partirte la ranura. La tarjeta necesita la ranura x16 primaria bifurcada a x8/x8, y la mayoría de las placas de consumo no lo habilitan por defecto. Es un ajuste de firmware que hay que ir a buscar, en la misma categoría que los ajustes de IOMMU y ACS que necesita todo esto.

Hazlo bien y el sistema operativo ve dos GPU separadas, cada una con su propia función física y su propia capacidad SR-IOV. Así que obtienes dos lotes de funciones virtuales desde una ranura — 14 puestos si cada die se comporta como una B60 sola — y el fichero tmpfiles.d de arriba se duplica, una escritura a sriov_numvfs por die.

Hazlo mal y ves una GPU y la mitad de la tarjeta es invisible.

Vale la pena ser claro sobre lo que los 48 GB no son: un invitado adjuntado a una función virtual del primer die no puede alcanzar la memoria del segundo die. Esto son dos tarjetas de 24 GB en un solo espacio físico, que es exactamente lo que quieres para puestos de VDI y exactamente lo que no quieres para un modelo grande.

Así que: si dos puestos bastan, la B50 es una tarjeta de 70 W que lo hará. Si quieres siete, planea alrededor de una B70. Si quieres catorce y tienes una placa que bifurque, la B60 Dual te lleva ahí en una sola ranura.

¿Puedes correr IA en una función virtual?

Respuesta corta: trátalo como no soportado. Respuesta más larga, porque la razón importa y no es la que adivinarías.

Estas se venden como tarjetas de IA y no están fingiendo. Los 128 motores XMX de la B50 están valorados en 170 TOPS pico, la B70 en 367, y la historia de software de Intel es real — vLLM sirve modelos desde 8B hasta 120B en las Arc Pro serie B, e IPEX-LLM y el backend SYCL de llama.cpp corren los dos en ellas.

Pero mira cómo se produce cada uno de esos resultados. Los propios números de Arc Pro de vLLM vienen de un contenedor Docker sobre metal desnudo, en sistemas con cuatro y ocho tarjetas B60 enteras haciendo paralelismo de tensores. La entrada de Intel no menciona SR-IOV ni funciones virtuales ni una sola vez.

Ese patrón se mantiene por todas partes donde miré. Intel acota los casos de uso de SR-IOV a escritorio remoto virtualizado, aceleración de gráficos del SO invitado, y codificación y decodificación de medios. El cómputo no está en esa lista, y no pude encontrar un solo caso publicado de alguien corriendo inferencia de LLM dentro de una VM adjuntada a una función virtual.

Lo que la gente hace de verdad es revelador: corren el modelo en Docker en el host, y entregan funciones virtuales a las VM para escritorios. Una persona haciendo las dos cosas a la vez reporta simplemente que «VRAM gets pretty tight» — la VRAM se pone bastante justa.

Que es el problema real, y es aritmética y no soporte del driver.

Una función virtual obtiene una porción fija de memoria local — 8 GB en la B50, fijada en firmware. Esa porción es el techo duro para pesos más caché KV en ese invitado, y no crece porque la tarjeta tenga más. Un modelo de 8B a FP16 son alrededor de 16 GB de pesos antes de añadir nada de contexto, así que no cabe en una función virtual de la B50 con ningún driver. Cuantiza a Q4 y un 8B cabe en unos 4 GB, dejando unos pocos GB para contexto — lo que funciona, pero está muy lejos de lo que la tarjeta puede hacer sin dividir.

Así que las dos cargas de trabajo compiten por la misma memoria, y el reparto se decide en firmware antes de que ninguna de las dos empiece.

Si el trabajo es la IA, no dividas la tarjeta. Pásala entera por passthrough a una VM — el mismo passthrough hostpci0 usado para la actualización de firmware antes en este artículo — o corre el contenedor en el host y sáltate la virtualización para esa carga. Ambos le dan al modelo los 16 GB enteros y el array XMX completo.

Si el trabajo es el VDI, las funciones virtuales son lo correcto, y espera gráficos de escritorio y no un servidor de inferencia detrás de cada una. Escritorios acelerados por hardware, reproducción de vídeo y codificación funcionan. Eso es para lo que está documentado el mecanismo.

Vale la pena decirlo claro: la ausencia de evidencia publicada no es prueba de que falle. El driver xe expone cómputo a través de Level Zero y OpenCL, y es del todo posible que un invitado respaldado por una VF los levante bien. Pero nada de Intel dice que esté validado, nadie parece haberlo enseñado funcionando, y el techo de memoria limita la recompensa aunque lo haga. Eso no es algo sobre lo que construir un plan.

Lo que sigue valiendo

Dos funciones virtuales son dos escritorios de Windows acelerados por hardware desde una tarjeta, sin licencia de vGPU, sin suscripción y sin servidor de licencias. Sobre un hipervisor que no cuesta nada correr. Eso basta para probar que el enfoque funciona, que es el trabajo honesto de una B50. Es el fondo de la gama.

Para un despliegue de VDI de verdad yo estaría especificando la B60 Dual.

Catorce funciones desde una ranura — si cada die se comporta como una B60 sola — la pone en el mismo territorio de número de puestos que las tarjetas de NVIDIA vendidas para esta carga, a un precio mucho más bajo, y sin nada que licenciar por usuario. Esa última parte es la que se acumula. Los vApps, vPC y RTX vWS de NVIDIA se licencian todos por usuario concurrente, ya sea como suscripción anual o como licencia perpetua que hay que comprar junto a una suscripción de soporte y mantenimiento de cinco años. Cada puesto es una partida, y vuelve a caer. En el lado de Intel no hay partida equivalente. Compras la tarjeta.

Y el mecanismo es la parte que importa a largo plazo. SR-IOV en la GPU es una capacidad de PCIe, no un escalón de producto, así que el fichero tmpfiles.d simplemente crece para igualar lo que la tarjeta permita.

La forma es una escritura a sriov_numvfs, luego un unbind y un bind por cada función — así que dos funciones son cinco líneas, y las nueve de arriba son cuatro funciones pedidas en una tarjeta que entrega dos. Siete funciones son quince líneas. Una B60 Dual son treinta, porque cada die es su propia función física y obtiene su propia escritura a sriov_numvfs.

Nada más cambia según lo escalas. No aparece ningún servidor de licencias en ningún punto de ese fichero.

Referencias

• Intel support — why the latest Arc Pro B50 firmware shows 2 SR-IOV VFs — la afirmación que hace autoridad: SR-IOV habilitado oficialmente desde el firmware de gráficos BMG__21,1162 en el driver 32.0.101.8306, dos VF a un BAR de memoria local de VF de 8 GB cada una en la B50, y el número máximo de VF y el tamaño de BAR fijados a nivel de IFWI sin herramienta pública para cambiarlos
• Intel Community — “Why did the latest Intel Arc Pro B50 firmware nerf SR-IOV VFs from 12 to 2?” — el firmware pre-oficial a 12 VF, el retorno a 32.0.101.6979 que lo restaura, y el razonamiento de Intel para el valor por defecto más bajo
• Level1Techs — B60 SR-IOV support in the Arc Pro drivers — los reportes de campo de lspci para la B60, la actualización de firmware igsc que expuso la capacidad, y de dónde vienen las cifras de 24-luego-7
• Level1Techs — B50, B60 or B70 for SR-IOV — los números de VF reportados por tarjeta y por firmware, fuente de las filas de la B70
• ASRock — Intel Arc Pro B65 Creator 32GB — las especificaciones de la B65: 32 GB GDDR6, 20 unidades de cómputo, 160 motores XMX, 256 bits, PCIe 5.0
• MAXSUN — Arc Pro B60 Dual 48G Turbo — la afirmación del propio fabricante de que la tarjeta «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 — la historia de IA en estas tarjetas, y el hecho de que es una historia de Docker-sobre-metal-desnudo a través de cuatro y ocho B60 enteras, sin mención de SR-IOV ni funciones virtuales
• Linux kernel — Intel Xe driver — el driver en uso en la tarjeta, según lspci -v
• tmpfiles.d(5) — el tipo de línea w, y su condición «if the file exists» que dicta el orden de arriba
• NVIDIA Virtual GPU Software Packaging, Pricing and Licensing Guide — la alternativa licenciada que este diseño evita: vApps, vPC y RTX vWS vendidos todos por usuario concurrente, como suscripción anual o como licencia perpetua empaquetada con cinco años de soporte y mantenimiento
• Proxmox VE — PCI(e) Passthrough — los requisitos de passthrough del lado del host