MIG es útil cuando una NVIDIA A100, H100 o H200 es demasiado potente para una sola tarea, pero hay que dividirla de forma segura y predecible entre varios usuarios, servicios o equipos. Con MIG, la GPU física se divide en varias instancias aisladas: cada una recibe su propia parte de recursos de cómputo y de memoria de vídeo. Es una buena opción para inferencia, entornos de prueba, notebooks, varias modelos pequeños y plataformas de ML, pero no siempre es adecuada para el entrenamiento distribuido a gran escala, donde suele ser mejor usar GPU físicas completas.
Los aceleradores modernos para IA rara vez se compran «con margen» para un único experimento. Se instalan en servidores donde una misma tarjeta gráfica puede ser necesaria para desarrolladores, analistas, el equipo de MLOps, una plataforma interna de machine learning o varios clientes. En esa situación aparece rápidamente un problema: un usuario lanza un modelo pequeño y ocupa toda la tarjeta, aunque en realidad solo utiliza una parte de la memoria de vídeo y de los bloques de cómputo.
MIG resuelve precisamente esta tarea. La tecnología permite dividir una GPU compatible en varias partes independientes. En el sistema se ven como dispositivos separados de menor tamaño. Por ejemplo, una A100 de 80 GB se puede dividir en varias instancias de 10, 20 o 40 GB, mientras que una H200 de 141 GB ofrece perfiles con más memoria para modelos más pesados.
Para las empresas que eligen GPU NVIDIA para IA y redes neuronales, MIG es tan importante como la capacidad total de memoria de vídeo o la generación de la GPU. Ayuda a entender cómo se utilizará realmente la tarjeta: completa para una sola tarea o en paralelo para varias cargas de trabajo.
Qué es MIG en palabras sencillas
MIG es una tecnología de particionamiento por hardware para tarjetas gráficas NVIDIA compatibles. Una GPU física se divide en varias instancias de GPU. Cada instancia recibe una parte fija de los recursos:
- bloques de cómputo;
- memoria de vídeo;
- parte de la caché L2;
- parte del ancho de banda de memoria;
- rutas independientes de acceso a la memoria;
- un conjunto de motores de hardware que depende del perfil.
Para la aplicación, una instancia MIG se ve como una tarjeta gráfica independiente de menor tamaño. El usuario no recibe toda la A100, H100 o H200, sino que trabaja solo con la parte asignada. La descripción oficial de la arquitectura MIG se puede consultar en la NVIDIA MIG User Guide.
Un ejemplo sencillo:
- sin MIG, un usuario lanza un notebook y ocupa toda la H100;
- con MIG, el administrador divide la H100 en varios perfiles;
- un perfil se asigna al notebook, otro a un servicio de inferencia y otro a un modelo de prueba;
- las tareas no compiten por toda la tarjeta a la vez, porque cada una tiene su propia zona asignada de la GPU.
No es lo mismo que «dar acceso a todos a una misma tarjeta gráfica y esperar que no se molesten entre sí». MIG divide los recursos a nivel de la propia GPU, por eso el comportamiento de las tareas se vuelve más predecible.
Dónde MIG aporta más valor
MIG es especialmente útil cuando una tarjeta gráfica cara no debe trabajar para una sola tarea grande, sino para varios entornos o servicios con requisitos distintos.
Varios equipos en una misma GPU
Dentro de una empresa, una misma H100 puede ser necesaria para varios grupos al mismo tiempo:
- los desarrolladores prueban un modelo nuevo;
- los analistas trabajan en un entorno de notebooks;
- el equipo de MLOps prueba inferencia;
- el equipo de ingeniería depura el pipeline de preparación de datos.
Sin MIG, esa tarjeta suele convertirse en un recurso disputado: quien ocupa primero la GPU trabaja, y los demás esperan o ejecutan sus tareas por la noche. Con MIG se puede asignar de antemano un perfil a cada equipo, en lugar de entregar la tarjeta completa.
Esto resulta cómodo para:
- plataformas internas de ML;
- equipos de investigación;
- laboratorios;
- proveedores de servicios;
- empresas donde las GPU se compran de forma centralizada y se distribuyen entre proyectos.
Entornos de desarrollo y prueba
Para desarrollo casi nunca se necesita una H100 o H200 completa. En la etapa de depuración, la disponibilidad del entorno suele ser más importante que el máximo rendimiento. MIG permite asignar perfiles pequeños para:
- comprobar el entorno;
- hacer una ejecución de prueba del modelo;
- depurar dependencias;
- comprobar la compatibilidad de CUDA, controladores y bibliotecas;
- preparar el pipeline antes de ejecutarlo en una GPU completa.
Por ejemplo, un desarrollador no tiene por qué ocupar toda una A100 de 80 GB si solo está comprobando la carga del modelo y la corrección del procesamiento de los datos de entrada. Puede bastarle un perfil pequeño, mientras que el resto de la tarjeta queda disponible para otras tareas.
Inferencia de varios modelos
La inferencia es uno de los escenarios más naturales para MIG. En una sola GPU física se pueden mantener varios servicios:
- diferentes versiones de un mismo modelo;
- varios modelos para distintos productos;
- modelos separados para diferentes clientes;
- una versión de prueba y una versión de producción del servicio;
- inferencia por lotes con carga moderada.
Si cada modelo utiliza solo una parte de la memoria de vídeo, no siempre es racional ejecutarlos en GPU físicas separadas. MIG permite aumentar la densidad de colocación y reducir el tiempo de inactividad del hardware.
Pero es importante no elegir el perfil solo por la cantidad de memoria. Un modelo puede tener suficiente memoria de vídeo, pero no suficiente parte de cómputo del perfil o ancho de banda de memoria. Por eso, para inferencia siempre hay que comprobar la latencia de respuesta, el tamaño del batch y la estabilidad con carga paralela.
Aislamiento de clientes y proyectos
MIG ayuda a dividir la GPU entre clientes o proyectos para que una tarea no pueda ocupar toda la memoria de vídeo de la tarjeta física. Esto es especialmente importante en plataformas donde los usuarios lanzan sus propios contenedores, notebooks o modelos.
MIG aporta aislamiento a nivel de recursos de GPU, pero no sustituye los demás niveles de protección. Para un entorno multiusuario real siguen siendo necesarios:
- separación de usuarios en el sistema operativo;
- permisos de acceso a los datos;
- aislamiento mediante contenedores;
- políticas de red;
- límites en Kubernetes;
- monitorización de procesos;
- reglas para limpiar tareas colgadas.
De lo contrario, MIG solo resolverá una parte del problema: dividirá la tarjeta gráfica, pero no protegerá la plataforma de errores en permisos, secretos, imágenes de contenedores o configuración de red.
Qué se divide exactamente en MIG
Al crear una instancia MIG, el administrador elige un perfil. El perfil determina qué parte de la tarjeta gráfica recibirá la tarea. Dentro del perfil se fijan los recursos de cómputo y la memoria de vídeo.
De forma simplificada, se puede imaginar así: una GPU grande se corta en varias secciones predefinidas. Una sección pequeña sirve para tareas ligeras, y una sección grande para modelos que necesitan más memoria y más capacidad de cómputo.
MIG divide:
- parte de los bloques de cómputo de la GPU;
- parte de la memoria de vídeo;
- parte de la caché L2;
- parte del ancho de banda de memoria;
- algunos motores de hardware;
- la visibilidad del dispositivo para las aplicaciones.
Qué significa esto para el usuario:
- la tarea no puede superar el volumen de memoria de vídeo asignado;
- una instancia vecina no debería quitar recursos a otra instancia;
- el administrador puede planificar de antemano qué volumen de GPU está disponible para cada usuario;
- el comportamiento de la carga es más fácil de predecir que con el uso compartido normal de una misma tarjeta.
Pero este enfoque tiene una desventaja: los recursos libres de una instancia vecina no se transfieren automáticamente. Si a una tarea se le asignan 10 GB y al lado hay una instancia de 40 GB inactiva, la primera tarea no podrá usar esos 40 GB. Para cambiar la distribución, hay que modificar la configuración MIG.
Qué no hace MIG
MIG no convierte una GPU física en varias tarjetas gráficas totalmente independientes y sin limitaciones. Este punto es importante, porque las expectativas incorrectas suelen llevar a errores de diseño.
MIG no significa que:
- cualquier tarea vaya a funcionar más rápido;
- un perfil pequeño vaya a ofrecer exactamente 1/7 del rendimiento de la GPU completa;
- se pueda redistribuir la memoria entre tareas con flexibilidad infinita;
- varias instancias MIG sustituyan a varias GPU físicas para entrenamiento grande;
- la migración en vivo empiece a funcionar por sí sola;
- la monitorización pueda seguir igual que para una GPU normal.
NVIDIA describe por separado las limitaciones de MIG en la sección Deployment Considerations. Para una implantación práctica son especialmente importantes las restricciones relacionadas con el intercambio de datos entre instancias, el perfilado y las bibliotecas distribuidas.
Limitaciones para tareas distribuidas
MIG encaja bien con tareas independientes en una misma GPU física. Pero si la carga requiere un intercambio activo de datos entre varias GPU o entre instancias, conviene tener más cuidado.
Pueden ser problemáticos los escenarios donde se utilizan:
- entrenamiento distribuido a gran escala;
- modelos que requieren varias GPU al mismo tiempo;
- intercambio intensivo entre aceleradores;
- bibliotecas de comunicaciones colectivas;
- tareas sensibles a la latencia entre dispositivos.
En estos casos a menudo es mejor utilizar GPU físicas completas sin MIG. Por ejemplo, si un modelo ocupa de forma estable toda la H100 e intercambia datos activamente con GPU vecinas, dividir la tarjeta en perfiles MIG puede complicar la arquitectura.
Limitaciones de monitorización
La visión habitual de una GPU física ya no es suficiente. El administrador debe ver no solo la carga total de la tarjeta, sino también el estado de cada instancia MIG.
De lo contrario aparece una situación típica:
- la GPU física parece tener una carga irregular;
- una instancia MIG está sobrecargada;
- otra está inactiva;
- una tercera tarea se ha caído por falta de memoria;
- en la métrica general todo parece «uso normal de GPU».
Para producción conviene recopilar métricas por cada instancia. NVIDIA DCGM puede entregar indicadores tanto a nivel de GPU física como a nivel de dispositivos MIG; esto se describe en la DCGM documentation.
Conviene monitorizar:
- la utilización de los recursos de cómputo;
- la memoria de vídeo ocupada;
- errores de memoria;
- temperatura;
- consumo de energía;
- throttling;
- caídas de procesos;
- distribución de tareas por perfiles;
- inactividad prolongada de instancias individuales.
Perfiles MIG en A100, H100 y H200
El perfil MIG determina el tamaño de la instancia. En el nombre del perfil suele haber dos partes: la fracción de la parte de cómputo y el volumen de memoria de vídeo. Por ejemplo, el perfil 1g.10gb significa una instancia pequeña con 10 GB de memoria de vídeo, mientras que 7g.80gb corresponde a casi toda una H100 de 80 GB en un único perfil.
La lista completa de perfiles debe comprobarse en la tabla oficial Supported MIG Profiles, porque las opciones disponibles dependen del modelo concreto de GPU, la capacidad de memoria, el factor de forma y la versión del controlador.
| GPU | Ejemplos de perfiles MIG | Máximo de instancias | Para qué tareas es adecuado |
|---|---|---|---|
| A100 40 GB | 1g.5gb, 2g.10gb, 3g.20gb, 4g.20gb, 7g.40gb | hasta 7 | modelos pequeños, pruebas, notebooks, inferencia ligera |
| A100 80 GB | 1g.10gb, 1g.20gb, 2g.20gb, 3g.40gb, 4g.40gb, 7g.80gb | hasta 7 | varios equipos, inferencia, tareas por lotes, experimentos medianos |
| H100 80 GB | 1g.10gb, 1g.20gb, 2g.20gb, 3g.40gb, 4g.40gb, 7g.80gb | hasta 7 | inferencia en producción, pruebas de LLM, varios servicios en una GPU |
| H100 94/96 GB | 1g.12gb, 1g.24gb, 2g.24gb, 3g.47/48gb, 4g.47/48gb, perfil completo | hasta 7 | tareas a las que 80 GB les quedan cortos, pero que no siempre necesitan toda la tarjeta |
| H200 141 GB | 1g.18gb, 1g.35gb, 2g.35gb, 3g.71gb, 4g.71gb, 7g.141gb | hasta 7 | inferencia grande, tareas con alta demanda de memoria, varios modelos pesados |
Las cifras del nombre del perfil no deben interpretarse como una predicción exacta del rendimiento. El perfil muestra el tamaño de la parte de GPU asignada, pero la velocidad real depende del modelo, el tamaño del batch, el tipo de cálculos, la memoria, las bibliotecas y lo bien que escale la tarea.
Cómo elegir un perfil para una tarea
La elección del perfil no empieza con la pregunta «cuántas instancias se pueden crear», sino con «qué se ejecutará exactamente en cada instancia». Para una misma GPU se pueden construir esquemas diferentes: muchos perfiles pequeños, varios medianos o uno grande.
Modelo pequeño o servicio de prueba
Para un modelo pequeño normalmente conviene empezar con un perfil 1g. Esta opción sirve si la tarea:
- utiliza poca memoria de vídeo;
- no requiere un alto ancho de banda;
- atiende un número moderado de solicitudes;
- se necesita para pruebas o desarrollo;
- se ejecuta como servicio independiente.
En una A100 de 80 GB puede ser el perfil 1g.10gb. En una H200 de 141 GB, 1g.18gb. La diferencia importa: en H200 incluso el perfil mínimo ofrece bastante más memoria, por lo que es más cómodo dividirla entre tareas más pesadas.
Notebook para un desarrollador o analista
Los entornos de notebooks suelen ocupar GPU de forma ineficiente. El usuario puede abrir una sesión, cargar un modelo, ejecutar unas cuantas celdas y dejar el proceso activo durante horas. Si se le entrega una H100 completa, la tarjeta queda formalmente ocupada, aunque en realidad solo se utilice parcialmente.
Para notebooks suelen encajar:
- perfiles 1g para experimentos ligeros;
- perfiles 2g para tareas con batch más grande;
- límite de duración de la sesión;
- limpieza automática de procesos inactivos;
- límites separados para distintos grupos de usuarios.
Aquí MIG no ayuda tanto a acelerar los cálculos como a hacer más justo el acceso a la GPU.
Inferencia por lotes
Para la inferencia por lotes hay que mirar no solo la memoria, sino también la latencia de procesamiento. Un perfil pequeño puede alojar el modelo, pero no mantener la velocidad necesaria.
Antes de elegir el perfil conviene comprobar:
- el tamaño máximo del batch;
- la latencia media y pico;
- la carga de la parte de cómputo;
- la carga de memoria;
- el comportamiento con solicitudes paralelas;
- el margen para crecimiento de carga.
Si el servicio atiende un modelo pequeño, se puede empezar con 1g o 2g. Si el batch es grande o el modelo es más pesado, es mejor probar 3g o 4g. Para tareas donde importa una gran cantidad de memoria de vídeo, merece más la pena mirar hacia H200.
Fine-tuning
Para fine-tuning, los perfiles pequeños no siempre son adecuados. Aunque el modelo arranque, puede fallar en la siguiente etapa por picos de consumo de memoria. Esto se nota especialmente al aumentar el batch size, la longitud de contexto o al utilizar configuraciones de entrenamiento menos económicas.
Para fine-tuning suelen hacer falta:
- perfiles 3g o 4g;
- un perfil completo si el modelo es grande;
- una GPU física separada si la tarea utiliza de forma estable toda la tarjeta;
- una prueba previa del consumo máximo de memoria.
Si la tarea implica un ajuste serio de un LLM, no conviene empezar por el perfil mínimo. Es mejor medir primero el consumo en una ejecución de prueba y después decidir si se puede dividir la tarjeta.
Ejemplos de distribución de una GPU entre tareas
MIG se entiende mejor con esquemas concretos. Los ejemplos siguientes no son recetas universales, sino variantes típicas que pueden servir como punto de partida para el diseño.
A100 de 80 GB para un equipo de desarrollo
La NVIDIA A100 80Gb PCIE HBM2 OEM se puede usar como tarjeta compartida para varias tareas internas.
Ejemplo de distribución:
- 2 × 1g.10gb para notebooks de desarrolladores;
- 1 × 2g.20gb para inferencia de prueba;
- 1 × 3g.40gb para un experimento con un modelo más grande.
Este esquema encaja cuando el equipo no necesita la máxima aceleración de una sola tarea, sino acceso constante a varios entornos aislados. Si en algún momento hace falta un experimento más grande, la configuración se puede reconstruir y asignar temporalmente más recursos a una tarea.
H100 de 80 GB para varios servicios de inferencia
La NVIDIA H100 80Gb HBM3 OEM se elige con más frecuencia para cargas de IA más productivas. En escenarios MIG resulta adecuada para varios servicios de inferencia.
Un esquema posible:
- varios perfiles 1g o 2g para modelos pequeños;
- un perfil 3g o 4g para un servicio más pesado;
- un perfil pequeño separado para probar una nueva versión del modelo.
Aquí es importante no sobrecargar la tarjeta con perfiles aleatorios. Es mejor definir de antemano clases de servicios: pequeño, mediano y pesado. Así, a los equipos les resulta más fácil solicitar recursos y a los administradores, seguir la carga.
H200 de 141 GB para tareas donde la memoria de vídeo importa
La NVIDIA H200 ORIGINAL resulta interesante cuando la limitación no es solo la potencia de cómputo, sino también la capacidad de memoria de vídeo. Los perfiles MIG de H200 son más grandes: incluso un perfil pequeño ofrece 18 GB, y los perfiles medianos pueden aportar 35 o 71 GB.
Esta tarjeta se puede dividir entre:
- varios servicios de inferencia con un consumo notable de memoria;
- tareas por lotes;
- pruebas de modelos a los que 10–20 GB les quedan cortos;
- varios equipos que trabajan con pipelines más pesados.
Si el modelo necesita casi todo el volumen de H200, MIG ya no es necesario: es mejor usar un perfil completo o toda la GPU física.
Qué comprobar antes de implementar MIG
Antes de implementar MIG es importante comprobar no solo la tarjeta gráfica, sino todo el stack: controlador, contenedores, Kubernetes, monitorización, reglas de acceso y escenarios de recreación de perfiles.
| Qué comprobar | Por qué es importante |
|---|---|
| Compatibilidad de la GPU | No todas las tarjetas gráficas NVIDIA admiten MIG. A100, H100 y H200 son compatibles, pero el modelo concreto y el factor de forma deben comprobarse por separado |
| Versión del controlador | Las versiones antiguas pueden no admitir los perfiles necesarios o no funcionar correctamente con un stack moderno |
| CUDA y bibliotecas | La aplicación debe ver la instancia MIG como una GPU disponible y arrancar correctamente en un perfil limitado |
| nvidia-smi | Hay que asegurarse de que MIG se activa, los perfiles se crean y se muestran en el sistema |
| Kubernetes device plugin | Es necesario si las instancias MIG se entregarán a contenedores en Kubernetes |
| GPU Operator y MIG Manager | Simplifican la gestión del stack de GPU y de las configuraciones MIG en los nodos |
| Monitorización | Se necesitan métricas por cada instancia, no solo por la GPU física |
| Reglas de asignación | Los usuarios deben entender qué perfil necesitan y por qué |
| Política de cambio de perfiles | Reconstruir el esquema MIG puede requerir detener tareas |
| Plan de tolerancia a fallos | MIG divide la GPU, pero no sustituye la redundancia del servicio |
Hay que prestar especial atención a las reglas de asignación. Si no existen, MIG se convierte rápidamente en un conjunto de perfiles creados al azar: un usuario pide una instancia demasiado grande, otro ocupa un perfil pequeño para un modelo pesado y un tercero deja una sesión colgada durante el fin de semana.
Una buena práctica es describir de antemano varias clases estándar:
- perfil pequeño para notebooks y pruebas;
- perfil mediano para inferencia;
- perfil grande para experimentos pesados;
- perfil completo para tareas que realmente necesitan toda la tarjeta.
MIG en Kubernetes
Ejemplo de arquitectura para escalar Triton Inference Server con MIG y Kubernetes. Fuente: NVIDIA Developer Blog
En Kubernetes, MIG es especialmente útil porque permite entregar a un pod no toda la GPU física, sino un perfil concreto. Para ello se necesita el stack adicional de NVIDIA: controladores, container toolkit, device plugin y, en instalaciones más gestionadas, GPU Operator.
NVIDIA describe los escenarios MIG para Kubernetes en una documentación separada: MIG Support in Kubernetes. En la práctica se ve así:
- el administrador activa MIG en el nodo con GPU;
- crea los perfiles necesarios;
- Kubernetes recibe la lista de recursos MIG disponibles;
- el pod solicita un tipo concreto de recurso;
- el scheduler coloca la carga en un nodo donde ese perfil existe.
En Kubernetes es especialmente importante no crear caos con demasiados perfiles distintos. Cuantas más variantes haya, más difícil será para el planificador colocar tareas y para los equipos elegir el recurso correcto.
Para plataformas de ML suelen ser útiles estas reglas:
- etiquetar los nodos GPU según el tipo de perfiles disponibles;
- crear colas separadas para tareas pequeñas, medianas y grandes;
- limitar el acceso a GPU completas;
- cerrar automáticamente sesiones de notebook inactivas;
- recopilar estadísticas de uso por perfiles;
- revisar periódicamente qué perfiles se necesitan de verdad.
MIG funciona bien con Kubernetes cuando las tareas están clasificadas de antemano. Si cada equipo pide manualmente «algo más grande», las ventajas se pierden rápido.
Cuándo es mejor no usar MIG
MIG no es necesario en todos los servidores GPU. A veces dividir la tarjeta solo complica la operación.
Es mejor usar una GPU física completa o varias GPU sin MIG si:
- una tarea utiliza de forma estable toda la tarjeta gráfica;
- el modelo requiere casi toda la memoria de vídeo;
- se necesita el máximo rendimiento de una sola tarea;
- el entrenamiento se distribuye entre varias GPU;
- la carga intercambia datos activamente entre aceleradores;
- la aplicación funciona mal en un perfil limitado;
- se requiere una redistribución flexible de memoria entre tareas;
- la infraestructura no está preparada para monitorizar instancias MIG;
- no hay un administrador que gestione perfiles y reglas de acceso.
MIG funciona especialmente bien donde las cargas son parecidas y predecibles. Por ejemplo, si hay varios servicios de inferencia típicos, varios entornos de notebooks y límites claros para los equipos. Si cada ejecución es única y el consumo de memoria es difícil de predecir, habrá que cambiar perfiles y detener tareas con más frecuencia.
A100, H100 o H200: qué elegir para MIG
Fuente: ServerMall
La elección depende de qué tareas haya que ejecutar y de lo importante que sea la memoria de vídeo.
A100
A100 es una plataforma madura y extendida. Encaja bien para:
- entornos internos de ML;
- desarrollo y pruebas;
- varios notebooks;
- inferencia de modelos pequeños y medianos;
- equipos que necesitan acceso a GPU sin presupuesto para las H100/H200 de gama más alta.
Si se prevé una división activa entre usuarios, la A100 de 80 GB es más cómoda que la versión de 40 GB: ofrece más variantes de memoria y reduce el riesgo de que cada tarea llegue rápidamente al límite.
H100
H100 debe considerarse cuando se necesita mayor rendimiento para cargas modernas de IA. En escenarios MIG es adecuada para:
- inferencia en producción;
- varios servicios en una misma GPU;
- pruebas de LLM;
- plataformas de ML con distintas clases de tareas;
- equipos que necesitan margen de velocidad.
H100 puede ser excesiva para tareas pequeñas. Precisamente por eso MIG es especialmente útil aquí: ayuda a no entregar toda la potencia de la tarjeta a un proceso pequeño.
H200
H200 resulta interesante cuando el principal problema es la memoria de vídeo y el ancho de banda de memoria. Los perfiles H200 son más grandes, por lo que la tarjeta encaja bien con escenarios de inferencia más pesados y con tareas a las que los 10–20 GB típicos les quedan cortos.
Conviene considerar H200 si:
- los modelos chocan a menudo con el límite de memoria;
- hay que mantener varios servicios pesados;
- la inferencia por lotes requiere una gran reserva;
- una sola tarea no siempre utiliza todo el volumen de 141 GB;
- se quiere dividir la tarjeta sin caer en perfiles demasiado pequeños.
Si la tarea es única y necesita constantemente toda la H200, dividirla no aportará ventajas. Pero si hay varias tareas y cada una requiere solo una parte de la tarjeta, MIG ayuda a usar el recurso con más densidad.
Errores frecuentes al trabajar con MIG
Los errores suelen estar relacionados no con la propia tecnología, sino con las expectativas y la operación.
Los problemas más habituales son:
- elegir el perfil solo por la cantidad de memoria de vídeo;
- no comprobar el consumo máximo del modelo;
- no medir la latencia de inferencia bajo carga;
- asignar perfiles demasiado grandes «por si acaso»;
- ejecutar fine-tuning en una instancia demasiado pequeña;
- no recopilar métricas por cada instancia MIG;
- olvidar que la memoria libre del perfil vecino no se transfiere automáticamente;
- no documentar a quién y para qué se asignó un perfil;
- mezclar demasiadas configuraciones en un mismo nodo;
- considerar MIG como sustituto de varias GPU físicas;
- no planificar la parada de tareas antes de cambiar el esquema.
Para evitar estos errores, MIG debe implementarse no como una configuración puntual, sino como una política gestionada de uso de GPU.
Conjunto mínimo de reglas:
- Describir perfiles y escenarios típicos.
- Comprobar las cargas reales en un entorno de prueba.
- Configurar monitorización por instancias.
- Limitar el acceso a GPU completas.
- Introducir reglas para limpiar procesos inactivos.
- Revisar las configuraciones según las estadísticas de uso.
Cómo entender si MIG se amortiza
MIG tiene sentido si una GPU cara permanece inactiva con frecuencia o está ocupada por tareas que no necesitan toda la tarjeta. Esto se nota especialmente en equipos donde hay muchas pruebas, notebooks, modelos pequeños y servicios de inferencia.
MIG será útil si:
- varios usuarios compiten regularmente por una misma GPU;
- las tareas son predecibles en consumo de memoria;
- hay muchos servicios de inferencia pequeños;
- hay que aislar clientes o equipos;
- la GPU suele estar ocupada, pero en realidad no está completamente cargada;
- la infraestructura ya usa Kubernetes o planea migrar a él;
- hay un administrador que gestionará los perfiles.
MIG puede ser innecesario si:
- toda la GPU está casi siempre ocupada por una sola tarea grande;
- los modelos requieren constantemente todo el volumen de memoria;
- no hay monitorización;
- no existen reglas claras de distribución;
- el equipo no está preparado para cambiar sus procesos de trabajo con GPU.
En resumen, MIG no debe verse como una forma de acelerar A100, H100 o H200, sino como una forma de hacer que su uso sea más gestionable. Ayuda a dividir una tarjeta gráfica cara entre varias tareas, reduce los conflictos por recursos y aumenta la utilización del hardware. Pero para obtener un buen resultado hacen falta perfiles correctos, monitorización y comprensión de las limitaciones. Sin eso, MIG puede convertirse fácilmente en otra capa compleja de infraestructura que nadie controla.
