La aviación aprendió algo que la industria de la IA está repitiendo ahora, pero con GPUs en vez de aviones. ¿Por qué importa que una GPU esté "en tierra"? Porque, igual que un avión, sigue costando mientras no genera salida útil. Y en una industria donde el recurso escasea, esa diferencia decide quién gana.
La analogía que abre el problema
Un avión acumula costos por hora del calendario: financiamiento, seguro, mantenimiento, tripulación. Solo gana dinero por hora de vuelo. Lo mismo pasa con una GPU: financiamiento, depreciación, energía y refrigeración se pagan por reloj, mientras que la producción se mide por horas de cómputo efectivas.
¿Resultado? La métrica que realmente importa deja de ser cuántas GPUs tienes y pasa a ser cuánto tiempo están haciendo trabajo que produce valor. Y esa métrica es profundamente dependiente de decisiones operativas: diseño de la red, planificación de mantenimiento, cómo programas los trabajos, y —lo más importante— la orquestación en tiempo real.
Una GPU ociosa no es solo desperdicio: es costo fijo convertido en pérdida económica.
¿Por qué no basta con comprar más GPUs?
Comprar más hardware es una respuesta natural. Pero hay dos problemas estructurales:
-
La demanda no es constante. Picos de entrenamiento, lotes nocturnos, generación de embeddings y tráfico en tiempo real no se alinean. La infraestructura se dimensiona para el pico y el resto del tiempo queda capacidad desaprovechada.
-
No todas las GPUs pueden absorber cualquier trabajo. A diferencia de un avión, una GPU tiene límites de memoria, requisitos de latencia, y dependencias de software (por ejemplo modelos cuantizados o instancias MIG). Eso crea lo que llamamos "formas" de GPU: perfiles de capacidad que no son intercambiables al 100%.
El resultado es que puedes tener un 90% de ocupación aparente y aun así tener colas de trabajo esperando porque ninguna GPU libre tiene la forma adecuada para ese trabajo.
Profundizando técnicamente: formas de trabajo y sus necesidades
Cada tipo de carga pide cosas diferentes de la GPU:
- Entrenamiento: demanda alta de memoria, largo tiempo continuo en la GPU, buena tolerancia a latencia, preferencia por throughput sostenido.
- Inferencia en tiempo real: exige baja latencia, a menudo tolera menos memoria, necesita contenedores optimizados y pipelining eficiente.
- Batch/embeddings: prefiere throughput y tolera esperas; se puede consolidar y empaquetar para mejorar eficiencia.
- Operaciones breves como quantización o evaluación: gran necesidad puntual de capacidad, pero por periodos cortos.
Técnicamente esto se traduce en restricciones: memoria disponible, capacidad de interconexión PCIe/NVLink, compatibilidad con MPS o MIG, tamaño de lotes (batch), y requisitos de latencia tail. Un scheduler que ignore estas dimensiones hará mal packing y generará desperdicio.
Métricas relevantes que debes medir
- Horas de GPU útiles (GPU-util hours) frente a horas encendidas.
- Latencia p99 para servicios en tiempo real.
- Throughput efectivo por tipo de trabajo.
- Fragmentación de memoria y porcentaje de colas por "shape mismatch".
- Coste por token o coste por consulta para workloads que vinieron de APIs.
Herramientas y patrones de GPU Management (técnico)
Lo que emerge es una capa de orquestación entre modelos y hardware: GPU Management. Sus responsabilidades técnicas incluyen asignación dinámica, prioridad, preemption con checkpointing, y colas diferenciadas por shape. Algunas prácticas y herramientas:
- Multiplexación y particionado:
NVIDIA MIGo particionamiento por hardware para tener "mini-GPUs" que atiendan inferencia ligera. - Specialization: distillation, quantization, y modelos específicos por tarea para reducir footprint y liberar capacidad.
- Scheduler avanzado: bin packing con awareness de memoria, backfilling, gang scheduling para entrenamiento distribuido, y preemption donde los trabajos largos ceden a tráfico en tiempo real.
- Pools calientes (warm pools): mantener instancias pre-cargadas para reducir cold start en inferencia en tiempo real.
- Checkpointing y migración: permitir que trabajos de entrenamiento se suspendan y reanuden para ceder capacidad crítica.
- Observabilidad: métricas por GPU, por proceso y por modelo; alertas en latencia tail y fragmentación.
- Autoscaling y compromisos híbridos: balancear coste variable (APIs) frente a coste fijo (hardware propio), calculando breakeven por token y por tasa de consultas.
En la práctica, herramientas como Kubernetes con device plugins, sistemas de colas especializados o motores propietarios pueden implementar estas políticas. Algunas empresas exploran asignadores basados en aprendizaje (auto-tuning) para poner la decisión en una capa automatizada que aprende trade-offs de prioridad y coste.
Especialización vs orquestación: por qué necesitas ambas
La especialización (modelos más pequeños y dedicados) reduce lo que cada trabajo necesita. La orquestación decide a dónde va la capacidad liberada. Si haces solo una de las dos cosas obtienes un beneficio parcial:
- Solo especialización: se libera capacidad, pero sin una capa que la reclame, el espacio queda ocioso.
- Solo orquestación: empaquetas mejor las cargas, pero si los modelos siguen siendo gigantes, el potencial de reclamación queda limitado.
Juntas, especialización y GPU Management cierran la brecha entre capacidad instalada y salida útil. El caso de DharmaOCR comparando con OCR4 y otros muestra cómo una especialización de dominio puede ganar incluso frente a arquitecturas más recientes, porque el recurso limitado se usa mejor.
¿Qué decisiones operativas cambian mañana?
- Mide adecuadamente: deja de mirar solo ocupación y añade métricas por shape y por prioridad.
- Segmenta clusters por clase de servicio: separar entrenamiento intenso de inferencia en tiempo real reduce conflictos.
- Invierte en modelos especializados donde el costo por token o por consulta lo justifique.
- Automatiza la asignación: no esperes que un ingeniero haga chequeos nocturnos. Implementa políticas automáticas de preemption y backfill.
- Evalúa el mix de nube y on-prem: considera compromisos multi-proveedor si necesitas resiliencia de capacidad.
Reflexión final
La lección es clara y práctica: poseer GPUs no es suficiente. La competencia ahora se decide por quién logra convertir cada hora de GPU en salida útil de la forma más continua posible. Eso exige tanto modelos que consuman menos como sistemas que decidan mejor y más seguido qué ejecutar y cuándo hacerlo.
Si te interesa la parte práctica, piensa en la orquestación como otro sistema inteligente: no sustituye al modelo, lo complementa. Dominar ambos frentes —arquitectura de modelos y GPU Management— será la ventaja competitiva para la próxima década.