GPU virtual y vi­r­tua­li­za­ción de GPU: vGPU, MIG y Pa­s­s­th­rou­gh

La vi­r­tua­li­za­ción de GPU comprende tres enfoques pri­n­ci­pa­les: con GPU Pa­s­s­th­rou­gh, una GPU física completa se asigna en exclusiva a una única máquina virtual (VM). Las so­lu­cio­nes de GPU virtual (vGPU), en cambio, permiten compartir los recursos de una GPU entre varias VM mediante me­ca­ni­s­mos de vi­r­tua­li­za­ción y pla­ni­fi­ca­ción. En las co­n­fi­gu­ra­cio­nes basadas en time slicing, el tiempo de pro­ce­sa­mie­n­to de la GPU se di­s­tri­bu­ye entre las distintas VM. Multi-Instance GPU, o MIG, divide las GPU de NVIDIA co­m­pa­ti­bles en in­s­ta­n­cias de hardware in­de­pe­n­die­n­tes y aisladas entre sí.

Resumen ⓘ

Los puntos clave de la vi­r­tua­li­za­ción de GPU de un vistazo:

• GPU Pa­s­s­th­rou­gh: asigna una GPU física completa en exclusiva a una única VM — máximo re­n­di­mie­n­to, pero sin uso co­m­pa­r­ti­do.
• GPU virtual (vGPU): reparte una GPU entre varias VM mediante time slicing y pla­ni­fi­ca­do­res — mejor apro­ve­cha­mie­n­to, aunque con un ai­s­la­mie­n­to solo lógico.
• Multi-Instance GPU (MIG): divide las GPU de NVIDIA co­m­pa­ti­bles a nivel de hardware en hasta siete in­s­ta­n­cias aisladas con recursos fijos.
• Límites técnicos: Pa­s­s­th­rou­gh restringe la migración en vivo, vGPU requiere licencia y es sensible al efecto de vecino ruidoso, y MIG no permite apro­ve­char la capacidad libre de otro perfil.
• Cómo elegir: Pa­s­s­th­rou­gh para una única VM que necesita toda la GPU, vGPU para muchos usuarios con ne­ce­si­da­des moderadas, y MIG o vGPU re­s­pa­l­da­da por MIG para cargas de IA, in­fe­re­n­cia y HPC con re­n­di­mie­n­to pre­de­ci­ble.

La GPU como recurso de cálculo clave en el centro de datos

Gracias al en­tre­na­mie­n­to de IA, la in­fe­re­n­cia y la co­mpu­tación de alto re­n­di­mie­n­to (HPC) acelerada por GPU, las GPU se han co­n­ve­r­ti­do en un recurso de cálculo fu­n­da­me­n­tal en los centros de datos modernos. Lo que antes se utilizaba pri­n­ci­pa­l­me­n­te para gráficos, re­n­de­ri­za­do o apli­ca­cio­nes es­pe­cia­li­za­das, hoy suele ser de­te­r­mi­na­n­te para el re­n­di­mie­n­to de pla­ta­fo­r­mas completas.

Sin embargo, pro­po­r­cio­nar recursos de GPU de forma eficiente en entornos virtuales es más complejo que en las cargas de trabajo de CPU. Las GPU trabajan de forma ma­si­va­me­n­te paralela, disponen de memoria propia de alta velocidad, como VRAM o HBM, y están es­tre­cha­me­n­te in­te­gra­das en el sistema mediante PCIe, además de co­n­tro­la­do­res y entornos de ejecución es­pe­cí­fi­cos del fa­bri­ca­n­te. Por este motivo, sus recursos no pueden co­m­pa­r­ti­r­se con la misma fle­xi­bi­li­dad que los núcleos de CPU o la memoria RAM.

En la práctica, se han co­n­so­li­da­do tres enfoques pri­n­ci­pa­les:

• GPU Pa­s­s­th­rou­gh exclusivo: una GPU física completa se asigna a una única máquina virtual.
• So­lu­cio­nes de GPU virtual (vGPU): varias máquinas virtuales comparten los recursos de una GPU mediante me­ca­ni­s­mos de vi­r­tua­li­za­ción, co­n­tro­la­do­res y el hi­pe­r­vi­sor.
• Multi-Instance GPU (MIG): las GPU de NVIDIA co­m­pa­ti­bles se dividen a nivel de hardware en in­s­ta­n­cias de GPU in­de­pe­n­die­n­tes con recursos asignados.

Estos métodos se di­fe­re­n­cian pri­n­ci­pa­l­me­n­te en la forma en que se asignan o comparten los recursos y en el grado de ai­s­la­mie­n­to que existe entre las distintas cargas de trabajo.

GPU Pa­s­s­th­rou­gh: asi­g­na­ción directa de GPU a una VM

Con GPU Pa­s­s­th­rou­gh, una GPU física completa se asigna de forma exclusiva a una única máquina virtual. De este modo, la VM obtiene acceso directo a la GPU y puede uti­li­zar­la prá­c­ti­ca­me­n­te como si estuviera conectada di­re­c­ta­me­n­te a un sistema físico.

Según la pla­ta­fo­r­ma, este pro­ce­di­mie­n­to recibe distintos nombres:

• Microsoft Hyper-V: Discrete Device As­si­g­n­me­nt (DDA)
• VMware vSphere/ESXi: VM­Di­re­c­t­Pa­th I/O o PCI Pa­s­s­th­rou­gh
• Linux/KVM: PCI Pa­s­s­th­rou­gh mediante VFIO

Té­c­ni­ca­me­n­te, este acceso directo se basa en la IOMMU (Input-Output Memory Ma­na­ge­me­nt Unit), que en las pla­ta­fo­r­mas Intel suele de­no­mi­nar­se VT-d y en las de AMD, AMD-Vi. La IOMMU controla y aísla los accesos directos a memoria (DMA) de los di­s­po­si­ti­vos, de modo que la GPU solo pueda acceder a las áreas de memoria que le co­rre­s­po­n­den. Así, la VM puede utilizar el co­n­tro­la­dor nativo del fa­bri­ca­n­te, es decir, el mismo tipo de co­n­tro­la­dor que emplearía en un sistema físico.

Ventajas e in­co­n­ve­nie­n­tes de GPU Pa­s­s­th­rou­gh

La principal ventaja de este enfoque es su re­n­di­mie­n­to muy elevado. Como la GPU se asigna di­re­c­ta­me­n­te a la VM y no tiene que co­m­pa­r­ti­r­se mediante una capa adicional de vi­r­tua­li­za­ción, el re­n­di­mie­n­to puede situarse, según la carga de trabajo, muy cerca del obtenido di­re­c­ta­me­n­te sobre hardware físico.

La principal de­s­ve­n­ta­ja es la falta de fle­xi­bi­li­dad: una GPU asignada mediante Pa­s­s­th­rou­gh queda reservada para una única VM. Ninguna otra VM puede uti­li­zar­la si­mu­l­tá­nea­me­n­te, aunque la máquina virtual a la que está asignada solo necesite una pequeña parte de su capacidad de cálculo o memoria.

Li­mi­ta­cio­nes técnicas de GPU Pa­s­s­th­rou­gh

El alto re­n­di­mie­n­to de GPU Pa­s­s­th­rou­gh conlleva algunas li­mi­ta­cio­nes prácticas, derivadas pri­n­ci­pa­l­me­n­te de la asi­g­na­ción exclusiva de la GPU a una única VM:

• Sin uso co­m­pa­r­ti­do si­mu­l­tá­neo de recursos: una GPU física se asigna de forma exclusiva a una VM. La capacidad que no se utiliza no puede asignarse di­ná­mi­ca­me­n­te a otras VM.
• Baja efi­cie­n­cia con cargas de trabajo pequeñas: para es­cri­to­rios virtuales, in­fe­re­n­cia ligera u otras tareas poco exigentes, dedicar una GPU completa suele suponer un apro­ve­cha­mie­n­to in­e­fi­cie­n­te de los recursos.
• Movilidad limitada de la VM: al estar vinculada di­re­c­ta­me­n­te a una GPU física, algunas funciones de vi­r­tua­li­za­ción pueden dejar de estar di­s­po­ni­bles o verse co­n­si­de­ra­ble­me­n­te limitadas. De­pe­n­die­n­do de la pla­ta­fo­r­ma, esto puede afectar a la migración en vivo, los snapshots y las funciones de guardar y restaurar. En de­te­r­mi­na­dos entornos de clúster puede ser posible reiniciar au­to­má­ti­ca­me­n­te la VM en otro host tras un fallo, pero esto no equivale a una migración en vivo.
• De­pe­n­de­n­cia de la pla­ta­fo­r­ma y de la IOMMU: el host debe ser co­m­pa­ti­ble con PCIe Pa­s­s­th­rou­gh. Esto requiere, entre otras cosas, ex­te­n­sio­nes de vi­r­tua­li­za­ción de E/S como Intel VT-d o AMD-Vi y una co­n­fi­gu­ra­ción PCIe/IOMMU adecuada. En Linux/KVM también es im­po­r­ta­n­te que los di­s­po­si­ti­vos que se van a asignar estén co­rre­c­ta­me­n­te aislados a través de la IOMMU.
• De­pe­n­de­n­cia del hardware, el software y los co­n­tro­la­do­res: no todas las GPU, placas base ni versiones de hi­pe­r­vi­sor ofrecen el mismo nivel de co­m­pa­ti­bi­li­dad con Pa­s­s­th­rou­gh. En entornos de pro­du­c­ción conviene comprobar siempre las listas de co­m­pa­ti­bi­li­dad de hardware y los re­qui­si­tos de co­n­tro­la­do­res del fa­bri­ca­n­te.

GPU virtual (vGPU)

La GPU virtual resuelve una de las pri­n­ci­pa­les li­mi­ta­cio­nes de GPU Pa­s­s­th­rou­gh: una GPU física ya no tiene que asignarse en exclusiva a una única VM, sino que puede co­m­pa­r­ti­r­se entre varias máquinas virtuales.

Para ello, en el host se utiliza un co­m­po­ne­n­te es­pe­cí­fi­co de vi­r­tua­li­za­ción de GPU, como NVIDIA Virtual GPU Manager. Este se ejecuta en el hi­pe­r­vi­sor co­rre­s­po­n­die­n­te, por ejemplo, VMware vSphere/ESXi, Linux/KVM o XenServer, y pro­po­r­cio­na a las VM di­s­po­si­ti­vos de GPU virtual. En cada máquina virtual se instala además el co­n­tro­la­dor NVIDIA vGPU co­rre­s­po­n­die­n­te.

En las co­n­fi­gu­ra­cio­nes clásicas de vGPU, el uso co­m­pa­r­ti­do se basa pri­n­ci­pa­l­me­n­te en el reparto temporal o “time slicing”. Esto significa que la GPU no se divide de forma pe­r­ma­ne­n­te en pa­r­ti­cio­nes de hardware fijas, sino que sus recursos de cálculo y gráficos se comparten en el tiempo entre las distintas VM. Las cargas de trabajo se ejecutan por turnos y en in­te­r­va­los muy breves sobre la misma GPU física.

Cada VM recibe, mediante un perfil de vGPU, una cantidad de­te­r­mi­na­da de memoria de fra­me­bu­f­fer. Estos perfiles definen, entre otras cosas, cuánta memoria de GPU tiene di­s­po­ni­ble una VM y para qué tipo de carga de trabajo está pensado el perfil. Algunos ejemplos son:

• Perfiles Q para es­ta­cio­nes de trabajo virtuales
• Perfiles B para es­cri­to­rios virtuales
• Perfiles A para apli­ca­cio­nes virtuales y streaming de apli­ca­cio­nes
• Perfiles C para cargas de trabajo de cálculo

En las vGPU basadas en time slicing, la capacidad de cálculo no se divide fí­si­ca­me­n­te en partes fijas, sino que se di­s­tri­bu­ye mediante un pla­ni­fi­ca­dor. NVIDIA ofrece, entre otras, las políticas Best Effort, Equal Share y Fixed Share:

• Best Effort permite utilizar la GPU de la forma más flexible posible, pero puede provocar di­fe­re­n­cias de re­n­di­mie­n­to cuando las cargas de trabajo fluctúan mucho.
• Equal Share y Fixed Share pro­po­r­cio­nan, re­s­pe­c­ti­va­me­n­te, un reparto más uniforme o más fijo del tiempo de GPU.

Ventajas e in­co­n­ve­nie­n­tes de la GPU virtual (vGPU)

La principal ventaja de la GPU virtual es que permite apro­ve­char mucho mejor el hardware. Varias VM pueden compartir una GPU de alto coste en lugar de necesitar una tarjeta dedicada para cada una. Esto resulta es­pe­cia­l­me­n­te útil para es­cri­to­rios virtuales, es­ta­cio­nes de trabajo CAD, entornos de re­n­de­ri­za­do, in­fe­re­n­cia ligera de IA y otras cargas que no utilizan de forma continua toda la capacidad de una GPU.

En las vGPU basadas en time slicing, la principal de­s­ve­n­ta­ja frente a MIG es que los recursos de cálculo se comparten te­m­po­ra­l­me­n­te entre varias VM en lugar de estar divididos en pa­r­ti­cio­nes de hardware dedicadas. Aunque cada vGPU dispone de memoria asignada y existen me­ca­ni­s­mos de ai­s­la­mie­n­to, varias cargas in­te­n­si­vas que se ejecuten al mismo tiempo pueden competir por el tiempo de pro­ce­sa­mie­n­to de la GPU.

Li­mi­ta­cio­nes técnicas de la GPU virtual (vGPU)

La GPU virtual (vGPU) ofrece mucha más fle­xi­bi­li­dad para compartir una GPU, pero también implica una mayor co­m­ple­ji­dad operativa y, en las co­n­fi­gu­ra­cio­nes basadas en time slicing, un ai­s­la­mie­n­to del re­n­di­mie­n­to menor que el de una partición MIG dedicada:

• Licencia necesaria: NVIDIA vGPU es una solución sujeta a licencia. De­pe­n­die­n­do del tipo de vGPU y del caso de uso, pueden uti­li­zar­se productos como NVIDIA RTX Virtual Wo­r­k­s­ta­tion (vWS), NVIDIA Virtual PC (vPC), NVIDIA Virtual Ap­pli­ca­tio­ns (vApps) o NVIDIA AI En­te­r­pri­se para cargas de cálculo. Si una vGPU que requiere licencia no obtiene una licencia válida dentro del periodo de gracia co­rre­s­po­n­die­n­te, puede pasar a funcionar con capacidad reducida.
• Posible efecto de vecino ruidoso (noisy neighbor): en las vGPU basadas en time slicing, varias VM comparten los ciclos de pro­ce­sa­mie­n­to de la GPU. Por tanto, una carga es­pe­cia­l­me­n­te intensa puede afectar al re­n­di­mie­n­to de otras vGPU alojadas en la misma GPU. Las políticas Equal Share o Fixed Share permiten controlar mejor este reparto, pero no equivalen a una partición de hardware dedicada.
• Necesidad de co­n­tro­la­do­res co­m­pa­ti­bles: NVIDIA Virtual GPU Manager en el host y el co­n­tro­la­dor vGPU del sistema invitado deben en­co­n­trar­se dentro de las co­m­bi­na­cio­nes de versiones co­m­pa­ti­bles definidas por NVIDIA. No siempre tienen que ser exac­ta­me­n­te de la misma versión, pero una co­m­bi­na­ción no co­m­pa­ti­ble puede impedir que la vGPU funcione co­rre­c­ta­me­n­te.
• Mayor co­m­ple­ji­dad operativa: la GPU virtual requiere coordinar la GPU co­m­pa­ti­ble, el hi­pe­r­vi­sor, NVIDIA Virtual GPU Manager, el co­n­tro­la­dor del sistema invitado, el sistema de licencias y la co­n­fi­gu­ra­ción de los perfiles. Por ello, su ad­mi­ni­s­tra­ción y ac­tua­li­za­ción son más complejas que las de GPU Pa­s­s­th­rou­gh.
• So­bre­ca­r­ga derivada de la pla­ni­fi­ca­ción: en las vGPU basadas en time slicing, el tiempo de pro­ce­sa­mie­n­to de la GPU se di­s­tri­bu­ye entre varias máquinas virtuales y se producen cambios de contexto. En muchas cargas de trabajo este efecto es asumible, pero puede influir en es­ce­na­rios es­pe­cia­l­me­n­te sensibles a la latencia o que requieren un re­n­di­mie­n­to muy pre­de­ci­ble.
• Sin partición física de los recursos de cálculo como en MIG: las vGPU clásicas basadas en time slicing comparten te­m­po­ra­l­me­n­te los recursos de cálculo de la GPU. Si necesitas recursos dedicados y separados mediante pa­r­ti­cio­nes de hardware, puedes recurrir a MIG o, cuando la pla­ta­fo­r­ma y la GPU sean co­m­pa­ti­bles, a vGPU re­s­pa­l­da­das por MIG (MIG-backed vGPU).

Multi-Instance GPU (MIG)

La te­c­no­lo­gía Multi-Instance GPU, abreviada como MIG, sigue un enfoque diferente al de los modelos clásicos de GPU virtual basados en time slicing. NVIDIA introdujo Multi-Instance GPU con la ar­qui­te­c­tu­ra Ampere, entre otras, con la A100. Desde entonces, MIG se ha extendido a de­te­r­mi­na­das GPU para centros de datos y GPU pro­fe­sio­na­les. Por ello, esta te­c­no­lo­gía resulta es­pe­cia­l­me­n­te relevante en centros de datos donde varias cargas de trabajo de IA, in­fe­re­n­cia o HPC deben eje­cu­tar­se si­mu­l­tá­nea­me­n­te en una única GPU. En lugar de compartir te­m­po­ra­l­me­n­te los recursos de la GPU entre varias cargas de trabajo, el hardware se divide en pa­r­ti­cio­nes con recursos dedicados. Cada instancia recibe así una parte definida de la capacidad de cálculo, la memoria y el ancho de banda de memoria.

Según el modelo, una GPU física puede dividirse en varias in­s­ta­n­cias de GPU in­de­pe­n­die­n­tes. En numerosas GPU para centros de datos son posibles hasta siete in­s­ta­n­cias, aunque otros modelos admiten menos. Cada instancia recibe recursos de hardware asignados:

• Streaming Mu­l­ti­pro­ce­s­so­rs
• Segmentos de memoria
• Ancho de banda de memoria
• Porciones de caché L2
• Rutas de datos a través del sistema de memoria

El tamaño de una instancia se define mediante perfiles pre­de­fi­ni­dos. En una NVIDIA A100 con 40 GB de memoria, por ejemplo, existen perfiles como 1g.5gb, 2g.10gb o 7g.40gb. El primer valor indica la pro­po­r­ción de recursos de cálculo asignados y el segundo, la cantidad de memoria. Así, un perfil como 1g.5gb re­pre­se­n­ta una instancia pequeña, mientras que 7g.40gb utiliza toda la A100 de 40 GB como una única instancia.

Ventajas e in­co­n­ve­nie­n­tes de Multi-Instance GPU

La principal ventaja de MIG es su elevado ai­s­la­mie­n­to a nivel de hardware. Como los recursos de cálculo y memoria se asignan de forma es­pe­cí­fi­ca a cada instancia, las distintas cargas de trabajo pueden aislarse mucho mejor entre sí que con una GPU co­m­pa­r­ti­da úni­ca­me­n­te mediante time slicing. Esto resulta es­pe­cia­l­me­n­te útil en entornos bare metal o basados en co­n­te­ne­do­res en los que varias cargas de trabajo deben eje­cu­tar­se si­mu­l­tá­nea­me­n­te con recursos definidos y un re­n­di­mie­n­to pre­de­ci­ble.

MIG también puede uti­li­zar­se en entornos vi­r­tua­li­za­dos. Sin embargo, con GPU Pa­s­s­th­rou­gh las distintas in­s­ta­n­cias MIG de una GPU no pueden asignarse por separado a varias VM: una única VM recibe la GPU con MIG ha­bi­li­ta­do y puede acceder a sus in­s­ta­n­cias. Para pro­po­r­cio­nar in­s­ta­n­cias MIG aisladas a distintas máquinas virtuales se utiliza una vGPU re­s­pa­l­da­da por MIG (MIG-backed vGPU).

Li­mi­ta­cio­nes técnicas de Multi-Instance GPU

MIG mejora co­n­si­de­ra­ble­me­n­te el ai­s­la­mie­n­to y la pre­vi­si­bi­li­dad del re­n­di­mie­n­to frente a una GPU virtual clásica basada en time slicing, pero está limitado a de­te­r­mi­na­dos modelos de hardware, perfiles pre­de­fi­ni­dos y ciertas re­s­tri­c­cio­nes ar­qui­te­c­tó­ni­cas:

• Solo di­s­po­ni­ble en de­te­r­mi­na­das GPU: MIG no es co­m­pa­ti­ble con todas las GPU de NVIDIA. Las GPU de consumo y muchas tarjetas pro­fe­sio­na­les más antiguas no ofrecen esta función. MIG está di­s­po­ni­ble en de­te­r­mi­na­das GPU para centros de datos y en algunas GPU pro­fe­sio­na­les más recientes.
• Tamaños de perfil pre­de­fi­ni­dos: la división de los recursos no puede co­n­fi­gu­rar­se con una gra­nu­la­ri­dad ar­bi­tra­ria. Los ad­mi­ni­s­tra­do­res deben elegir entre los perfiles definidos por NVIDIA, por ejemplo, 1g.5gb, 2g.10gb o 7g.40gb en la A100 con 40 GB de memoria.
• Número limitado de in­s­ta­n­cias: de­pe­n­die­n­do de la GPU, pueden crearse hasta siete in­s­ta­n­cias si­mu­l­tá­neas. Otros modelos co­m­pa­ti­bles con MIG admiten un número menor.
• Re­co­n­fi­gu­ra­ción dinámica limitada: las in­s­ta­n­cias MIG pueden eli­mi­nar­se y volver a crearse, pero para modificar una partición las in­s­ta­n­cias afectadas no deben estar siendo uti­li­za­das. Además, de­pe­n­die­n­do de la ge­ne­ra­ción de la GPU y de la pla­ta­fo­r­ma, activar o des­ac­ti­var el modo MIG puede requerir reiniciar la GPU.
• Sin uso de capacidad adicional fuera del perfil: una instancia MIG solo puede utilizar los recursos asignados a su perfil. Los recursos que queden libres en otra instancia no se tra­n­s­fie­ren au­to­má­ti­ca­me­n­te a ella.
• Li­mi­ta­cio­nes en la co­mu­ni­ca­ción entre in­s­ta­n­cias y en co­n­fi­gu­ra­cio­nes multi-GPU: CUDA IPC no está di­s­po­ni­ble entre distintas GPU Instances, aunque sí puede uti­li­zar­se entre de­te­r­mi­na­das Compute Instances. El soporte P2P también está limitado; con co­n­tro­la­do­res recientes se admite entre in­s­ta­n­cias MIG de una misma GPU, pero no entre in­s­ta­n­cias MIG de distintas GPU. Además, el soporte de NCCL con MIG sigue teniendo re­s­tri­c­cio­nes: desde NCCL 2.31 existe co­m­pa­ti­bi­li­dad ex­pe­ri­me­n­tal con varias in­s­ta­n­cias MIG uti­li­za­n­do CUDA Driver 13.0 o posterior, pero algunas funciones como NVLink SHARP no están di­s­po­ni­bles. Por ello, MIG puede no ser la opción adecuada para de­te­r­mi­na­das cargas de trabajo di­s­tri­bui­das o co­n­fi­gu­ra­cio­nes multi-GPU que dependan de estas funciones.

Casos de uso y ayuda para la toma de de­ci­sio­nes

La te­c­no­lo­gía más adecuada depende pri­n­ci­pa­l­me­n­te de tres preguntas:

• ¿Se necesita el máximo re­n­di­mie­n­to de una GPU completa?
• ¿Es necesario aislar de forma fiable distintas cargas de trabajo o entornos de di­fe­re­n­tes usuarios o clientes?
• ¿Se debe compartir una GPU de la forma más eficiente posible entre varias máquinas virtuales (VM) o varios usuarios?

Como regla general:

• Máximo re­n­di­mie­n­to para una única VM: GPU Pa­s­s­th­rou­gh
• Muchos usuarios en paralelo con unas ne­ce­si­da­des moderadas de GPU: vGPU
• Varias cargas de trabajo de IA, in­fe­re­n­cia o HPC con recursos aislados y re­n­di­mie­n­to pre­de­ci­ble: MIG en bare metal o entornos con co­n­te­ne­do­res; vGPU re­s­pa­l­da­da por MIG cuando las cargas deben eje­cu­tar­se en máquinas virtuales in­de­pe­n­die­n­tes.

¿Cuándo es adecuado GPU Pa­s­s­th­rou­gh?

GPU Pa­s­s­th­rou­gh es es­pe­cia­l­me­n­te adecuado cuando una única VM necesita toda la potencia de una GPU física. Algunos ejemplos típicos son:

• Es­ta­cio­nes de trabajo de gama alta
• Re­n­de­ri­za­do intensivo con GPU
• Apli­ca­cio­nes CAD y CAE
• Trabajos de en­tre­na­mie­n­to in­di­vi­dua­les que apro­ve­chan al máximo una GPU completa

En estos casos, el re­n­di­mie­n­to es prio­ri­ta­rio, mientras que el uso co­m­pa­r­ti­do de la GPU tiene poca im­po­r­ta­n­cia o no es necesario.

La de­s­ve­n­ta­ja es que la GPU queda asignada en exclusiva a una VM. Como co­n­se­cue­n­cia, la capacidad que esta no utiliza queda des­apro­ve­cha­da y, de­pe­n­die­n­do de la pla­ta­fo­r­ma, funciones como la migración en vivo o la co­n­mu­ta­ción por error tra­n­s­pa­re­n­te (failover) pueden estar muy limitadas.

¿Cuándo es adecuada una GPU virtual?

Una GPU virtual resulta adecuada cuando muchos usuarios o VM solo necesitan una parte de la capacidad de la GPU. Es habitual, por ejemplo, en los si­guie­n­tes casos:

• Es­cri­to­rios virtuales
• Entornos de trabajo para usuarios con apli­ca­cio­nes de pro­du­c­ti­vi­dad
• Es­ta­cio­nes de trabajo técnicas con ne­ce­si­da­des gráficas moderadas o in­fe­re­n­cia ligera de IA

La GPU virtual permite aumentar el número de usuarios o VM que pueden utilizar una misma GPU y mejora el apro­ve­cha­mie­n­to del hardware. Su principal ventaja es la fle­xi­bi­li­dad: varias VM pueden compartir la misma GPU física. La de­s­ve­n­ta­ja es que, en las co­n­fi­gu­ra­cio­nes clásicas de vi­r­tua­li­za­ción de GPU basadas en time slicing, los recursos de cálculo se comparten en el tiempo. Si varias VM generan una carga elevada si­mu­l­tá­nea­me­n­te, pueden competir por el tiempo de pro­ce­sa­mie­n­to de la GPU. Políticas de pla­ni­fi­ca­ción como Equal Share o Fixed Share pueden reducir este efecto, pero no pro­po­r­cio­nan una partición física de los recursos como MIG.

¿Cuándo es adecuada Multi-Instance GPU?

Multi-Instance GPU (MIG) resulta es­pe­cia­l­me­n­te in­te­re­sa­n­te cuando varias cargas de trabajo deben eje­cu­tar­se en una misma GPU, pero necesitan recursos definidos y un re­n­di­mie­n­to pre­de­ci­ble. Algunos ámbitos de uso típicos son:

• In­fe­re­n­cia de IA para varias cargas de trabajo o equipos
• Entornos de de­sa­rro­llo y pruebas co­m­pa­r­ti­dos por varios equipos
• Entornos aislados para tareas de en­tre­na­mie­n­to de menor tamaño
• Entornos en la nube basados en co­n­te­ne­do­res o, mediante MIG-backed vGPU, en máquinas virtuales in­de­pe­n­die­n­tes

MIG divide las GPU de NVIDIA co­m­pa­ti­bles a nivel de hardware. Cada instancia recibe recursos de cálculo y memoria asignados es­pe­cí­fi­ca­me­n­te. De este modo, las cargas de trabajo pueden aislarse mejor que con el time slicing clásico y obtener un re­n­di­mie­n­to más pre­de­ci­ble. Por ello, MIG resulta es­pe­cia­l­me­n­te adecuado para entornos en los que son im­po­r­ta­n­tes tanto un buen apro­ve­cha­mie­n­to de la GPU como un alto grado de ai­s­la­mie­n­to.

En entornos vi­r­tua­li­za­dos, MIG también puede co­m­bi­nar­se con una GPU virtual. Con una vGPU re­s­pa­l­da­da por MIG (MIG-backed vGPU), las pa­r­ti­cio­nes de hardware de MIG se integran en las VM. De este modo, es posible combinar recursos de GPU definidos y ai­s­la­mie­n­to a nivel de hardware con un modelo de fu­n­cio­na­mie­n­to basado en máquinas virtuales.