Gestión de GPUs: Por qué las GPUs ociosas son el nuevo problema
La utilización, no la inteligencia, es la próxima restricción real en IA.
La aviación aprendió esta lección de la manera difícil. Durante gran parte de la historia de la industria, el indicador que mejor predecía si una aerolínea sobreviviría era la cantidad de tiempo que cada aeronave pasaba en tierra. La razón es estructural. Los costos de una aeronave se acumulan por hora calendario: financiamiento, depreciación, seguros, mantenimiento programado y contratos de tripulación. Sus ingresos, en cambio, solo se acumulan por hora de vuelo. Cada hora en tierra reduce la capacidad de generación de ingresos mientras los costos permanecen constantes. La utilización depende de casi todo lo demás: disciplina en los tiempos de respuesta, diseño de redes, planificación de mantenimiento y disponibilidad de repuestos. Si algo falla, el avión permanece en tierra.
Contar con una flota más grande ayuda, pero dos aerolíneas con flotas y rutas comparables pueden tener resultados económicos drásticamente distintos, y la brecha se reduce a una sola métrica. La IA empresarial está enfrentando la misma estructura en hardware diferente. Una GPU acumula costos por hora calendario —financiamiento, depreciación, energía y refrigeración— sin importar si está realizando una tarea útil. Su valor solo se genera por hora de cómputo. Al igual que en una aerolínea, poseer más GPUs es una ventaja, pero no garantiza el éxito. Dos empresas con presupuestos similares divergen según cuánta de esa infraestructura está realmente trabajando en un momento dado. La inteligencia ha llevado a la industria hasta aquí, pero la utilización es donde se forma la próxima restricción.
El cuello de botella se movió de los modelos al cómputo
La escasez no desapareció con el escalamiento de la IA; simplemente se movió hacia arriba en la cadena. La primera ola de la IA empresarial se ganó con la calidad del modelo. Parámetros, benchmarks y posiciones en leaderboards dominaron la conversación. Sin embargo, esa capacidad conlleva una dependencia: el hardware especializado, principalmente GPUs. Estas son costosas, tienen suministro limitado y una demanda que supera la oferta. En 2020, Microsoft construyó para OpenAI un supercomputador con más de 10,000 GPUs y 285,000 núcleos de CPU, posicionándolo como uno de los cinco sistemas más grandes del mundo para entrenar GPT-3. Seis años después, esas cifras parecen un punto de partida. Para 2026, laboratorios con capital masivo tratan el acceso al cómputo como una restricción estratégica. Anthropic, por ejemplo, gestiona compromisos de múltiples gigavatios en cuatro plataformas: Amazon, Google, Microsoft y AMD. Meta ha firmado acuerdos de escala comparable, demostrando que incluso con capital ilimitado, la escasez de cómputo es una realidad constante.
El mismo patrón aparece fuera de los laboratorios. Las empresas que consumen modelos vía API enfrentan un problema de precios: el costo escala linealmente con los tokens. Un PoC (Prueba de Concepto) con pocos miles de solicitudes es asequible, pero el volumen de producción puede disparar los costos de manera insostenible. La alternativa es adquirir GPUs propias y ejecutar modelos localmente, cambiando un costo variable por uno de capital fijo.
El gráfico anterior ilustra cómo el costo de API aumenta con el uso, mientras que la infraestructura propia se mantiene fija. Superado el punto de equilibrio, la lógica económica se invierte a favor del hardware propio. Este cambio convierte a la GPU en infraestructura, dimensionada para picos de demanda, lo que significa que la compra no resuelve el problema, sino que abre uno nuevo: mantenerlas ocupadas. Firmar por el hardware tiene fecha límite, pero la eficiencia operativa es lo que decide si la inversión fue rentable. Estos acuerdos representan compromisos de capacidad, no de eficiencia, y esa capacidad suele medirse con mucho menos rigor.
¿Por qué los clústeres ocupados siguen desperdiciando capacidad?
Un clúster lleno de GPUs puede seguir desperdiciando potencial debido a la disparidad entre la oferta y la demanda. La infraestructura debe dimensionarse para el pico máximo de entrenamiento, trabajos por lotes (batch jobs) y tráfico en tiempo real, lo que deja una porción significativa sin uso fuera de esos picos. Si cada GPU pudiera manejar cualquier tipo de carga, una mejor previsión resolvería el problema, pero la realidad es más compleja. La disparidad comienza en una capa más profunda. En la primera generación, el trabajo de una GPU era principalmente ejecutar inferencia. Hoy, el mismo hardware soporta entrenamiento, fine-tuning, cuantización, inferencia en tiempo real, inferencia por lotes y generación de embeddings. Cada carga de trabajo exige algo distinto: la inferencia en tiempo real prioriza la baja latencia, el trabajo por lotes tolera demoras, y el entrenamiento requiere ocupación continua durante días. Un planificador (scheduler) ajustado para una tarea desaprovechará las otras. El fallo no siempre aparece en un panel de control, ya que el clúster puede reportar alta ocupación mientras trabajos importantes esperan por un tipo de GPU que está ocupada en otra tarea. La mezcla de carga varía, pero la naturaleza del problema es constante. Aquí es donde la analogía de la aviación encuentra su límite: una aeronave ociosa puede ser reasignada a cualquier ruta, pero una GPU no siempre es intercambiable.
Vía Hugging Face.
