La conversación sobre IA en infraestructura propia siempre acaba en la misma pieza: la GPU. Puedes tener el mejor clúster Proxmox en producción, pero si quieres entrenar modelos, hacer fine-tuning o servir inferencia con rendimiento serio, necesitas que una tarjeta gráfica física trabaje dentro de una máquina virtual sin perder por el camino la potencia por la que has pagado. Eso es el GPU passthrough, y es la técnica que convierte un servidor con GPU en un nodo de IA de tu cloud privado.
Este artículo explica qué es el passthrough, cómo se hace en Proxmox VE 9.2, dónde están las trampas que hacen perder tardes enteras, y —la pregunta de fondo— cuándo tiene sentido montar esto en casa frente a alquilar GPU en un hiperescalar. Porque la respuesta no es siempre la misma, y conviene saber en qué lado caes antes de comprar hardware.
Virtualizar CPU, RAM o disco es un problema resuelto hace años: el hipervisor los reparte entre VMs sin que ninguna note demasiado. Una GPU es harina de otro costal. Es un dispositivo PCI Express complejo, con su propia memoria y sus propios drivers, diseñado para hablar directamente con un sistema operativo, no para ser troceado por un hipervisor.
El passthrough resuelve esto de la forma más directa posible: en vez de virtualizar la GPU, se la quita al host y se le entrega entera a una VM. Desde dentro de esa máquina virtual, la GPU se ve y se comporta como si estuviera instalada físicamente ahí. Los drivers de NVIDIA o AMD funcionan sin modificar, las bibliotecas de IA (CUDA, ROCm) la detectan como nativa, y el rendimiento es prácticamente el del metal desnudo. La contrapartida: esa GPU es de esa VM y de nadie más mientras dure la asignación.
Para que esto sea seguro —que la VM no pueda usar la GPU para leer memoria de otras máquinas o del host— hacen falta dos tecnologías del procesador.
IOMMU (Intel VT-d o AMD-Vi) es el guardián de la memoria. Aísla lo que un dispositivo PCI puede tocar, de modo que la GPU asignada a una VM solo accede a la memoria de esa VM. Sin IOMMU, el passthrough sería un agujero de seguridad; con él, es una asignación aislada y segura.
VFIO es el mecanismo del kernel Linux que desengancha la GPU del host —evitando que el driver del anfitrión la reclame— y la deja lista para entregársela a la VM. Es el «no toques esto, es para la máquina virtual» a nivel de sistema.
El proceso tiene una secuencia fija. Saltarse un paso es la causa del 90 % de los «no me funciona».
Primero, encender la virtualización de I/O en la BIOS/UEFI del servidor (VT-d en Intel, AMD-Vi/IOMMU en AMD). Luego decírselo al kernel en los parámetros de arranque:
# Intel — en la línea de comandos del kernel
intel_iommu=on iommu=pt
# AMD
amd_iommu=on iommu=ptTras reiniciar, se comprueba que el sistema ve los grupos IOMMU. Si el comando devuelve grupos, IOMMU está activo.
Hay que evitar que el host cargue el driver de la GPU (si el host reclama la NVIDIA, la VM se queda sin ella). Se le dice al kernel que use el driver vfio-pci para esa tarjeta, identificándola por sus IDs de PCI, y se ponen en lista negra los drivers del host (nouveau, nvidia, etc.).
En la interfaz de Proxmox: VM → Hardware → Add → PCI Device, se elige la GPU. Para tarjetas modernas suele bastar con marcar «All Functions» (para que vaya también el chip de audio HDMI de la tarjeta) y, según el caso, «PCI-Express». La VM debe usar máquina tipo q35 y BIOS OVMF (UEFI) para GPUs modernas.
Arrancada la VM, se instalan los drivers del fabricante (NVIDIA/AMD) y el stack de IA (CUDA o ROCm) dentro del sistema operativo huésped. A partir de ahí, la GPU es suya.
Nadie te avisa de esto en el tutorial feliz. Las tres que más duelen:
Los grupos IOMMU mal separados. El passthrough funciona a nivel de grupo IOMMU, no de dispositivo individual. Si tu placa base agrupa la GPU junto con otros dispositivos PCI (un controlador USB, una tarjeta de red) en el mismo grupo, tienes que pasarlos todos juntos o ninguno. En placas de consumo esto es un problema frecuente; en placas de servidor (con más líneas PCIe bien separadas) es raro. Antes de comprar hardware para passthrough, comprueba que la placa separa bien los grupos IOMMU. Es el factor que más decide si esto va a ser fácil o un calvario.
Querer pasar la GPU de arranque. Si el servidor solo tiene una GPU y es la que usa para su propia consola de arranque, entregarla a una VM deja al host sin salida de vídeo y puede fallar. Lo limpio es tener una GPU dedicada al passthrough (y que el host arranque con vídeo integrado o una tarjeta básica aparte). En servidores para IA, esto se planifica desde el diseño.
Confundir passthrough con vGPU. Son cosas distintas con implicaciones de licencia muy distintas. El passthrough entrega una GPU entera a una VM: una tarjeta, una máquina, sin licencia adicional del fabricante. La vGPU (o MIG en las NVIDIA de datacenter) parte una GPU física entre varias VMs, y eso sí requiere licencias del fabricante con coste recurrente. Para la mayoría de cargas de IA en cloud privado, passthrough completo es más simple y más barato. vGPU tiene sentido cuando necesitas repartir una GPU cara entre muchos usuarios ligeros.
Esta es la decisión que de verdad importa, y no tiene una respuesta universal. Depende del patrón de uso.
| GPU en cloud privado (passthrough) | GPU alquilada en hiperescalar | |
|---|---|---|
| Coste con uso sostenido | Bajo: pagas el hardware una vez y lo amortizas | Alto: la factura por hora no para nunca |
| Coste para picos puntuales | Malo: hardware parado la mayor parte del tiempo | Bueno: enciendes, usas, apagas |
| Soberanía del dato | Total: los datos no salen de tu infraestructura | Limitada: datos y modelos en casa ajena |
| Elasticidad instantánea | Limitada por el hardware que tengas | Alta: escalas con la tarjeta |
| Previsibilidad de coste | Alta: sabes lo que gastas | Baja: la factura variable sorprende |
La regla práctica: si tu uso de GPU es sostenido y previsible —inferencia continua, entrenamientos recurrentes, cargas que corren la mayor parte del tiempo—, el cloud privado gana por coste amortizado y soberanía. El alquiler brilla en lo contrario: picos esporádicos, experimentos de una tarde, necesidad de escalar a decenas de tarjetas por un rato. Muchos acaban en un modelo mixto: base propia para lo constante, nube para los picos. Es la misma lógica de cloud híbrido que aplica al resto de la infraestructura.
Y hay un factor que no aparece en la tabla de coste pero pesa cada vez más: dónde acaban tus datos y tus modelos. Servir inferencia sobre datos sensibles —historiales, documentos legales, información de clientes— en hardware propio mantiene ese dato bajo tu control. Es el argumento de la soberanía del dato llevado a la IA: no es solo cuánto cuesta, es quién puede llegar a lo que procesas.
q35 + UEFI y arranca.Con eso, tu servidor con GPU deja de ser una tarjeta suelta y pasa a ser un nodo de IA gobernado por tu cloud privado, con tus datos dentro y tu factura bajo control.
¿El passthrough pierde rendimiento frente a una GPU física? Muy poco. Con IOMMU y VFIO bien configurados, la VM accede a la GPU casi como si estuviera instalada nativamente: la pérdida típica es marginal. Si notas una caída grande de rendimiento, casi siempre es un problema de configuración, no una limitación del método.
¿Puedo compartir una GPU entre varias VMs? Con passthrough puro, no: una GPU va entera a una VM. Para repartir una GPU física entre varias máquinas existe vGPU (o MIG en NVIDIA de datacenter), pero requiere licencias del fabricante con coste recurrente. Para la mayoría de cargas de IA en cloud privado, una GPU por VM es más simple y económico.
¿Qué necesito comprobar antes de comprar hardware? Sobre todo, que la placa base separe bien los grupos IOMMU (las placas de servidor lo hacen mejor que las de consumo) y que puedas dedicar una GPU al passthrough dejando otra salida de vídeo para el host. Estos dos factores determinan si la instalación será sencilla o un calvario.
¿Sale más barato que alquilar GPU en la nube? Depende del uso. Con carga sostenida y previsible, el cloud privado amortiza el hardware y gana por coste y soberanía. Para picos esporádicos, alquilar es mejor porque no pagas hardware parado. Muchos combinan ambos: base propia para lo constante, nube para los picos.
¿Funciona con GPUs de gaming o solo con las de datacenter? El passthrough funciona con muchas GPUs de consumo, y es una vía habitual para montar nodos de IA asequibles. Las de datacenter añaden funciones (más memoria, ECC, MIG, mejor soporte de vGPU) que importan a cierta escala, pero para empezar una GPU de consumo bien elegida hace el trabajo.
¿Quieres montar nodos de IA en tu propio cloud privado y que tus datos no salgan a hardware ajeno? Diseñamos contigo servidores con GPU y passthrough sobre Proxmox, dimensionados para tu carga real. Empieza por nuestra comparativa de cloud o hablemos de tu proyecto.
Proxmox VE 9.2 estrena versión oficial para ARM64 (AArch64), la primera fuera de x86-64 en la historia del producto. Misma base de código, mismos repositorios y mismo soporte, con NVIDIA Grace y NVIDIA Vera como plataformas certificadas de salida. Repasamos qué hardware cumple los requisitos, qué funciones se quedan en x86 y qué cambia (poco, de momento) para quien ya tiene un clúster en producción.
Haces backup de la VM cada noche y duermes tranquilo. Hasta que restauras y la base de datos arranca corrupta o pierde las últimas transacciones. Un snapshot de disco no es lo mismo que un backup consistente de una base de datos. Explicamos la diferencia entre backup consistente por caída, por sistema de ficheros y por aplicación, y cómo conseguir el bueno en Proxmox con el agente invitado, hooks y volcados nativos.
Una red IP enrutada abajo, los servicios de cada cliente encapsulados arriba y BGP distribuyendo dónde está cada MAC. Qué resuelve EVPN-VXLAN, cómo encajan underlay y overlay, qué detalles rompen un fabric (la MTU, siempre la MTU) y cuándo no compensa montarlo.