La IA compró las GPU; nadie se hace cargo de mantenerlas ocupadas

Comprar GPU tiene un plazo, un presupuesto y un equipo de adquisición. Mantenerlas ocupadas no tiene ninguna de las tres. Un nuevo ensayo de Dharma AI, el proveedor de modelos especializados de código abierto, llama a esa brecha el problema estructural de la IA empresarial: una GPU acumula costos por hora de calendario, a través de financiamiento, depreciación, energía y refrigeración, ya sea que compute algo o no, mientras que su producción se acumula solo por hora de cómputo.

La lección de las aerolíneas: los ingresos solo se acumulan en el aire

El ensayo se apoya en la historia de la aviación. Los costos de una aeronave se acumulan por hora de calendario: financiamiento, depreciación, seguro de casco, mantenimiento programado, contratos de tripulación. Los ingresos se acumulan solo por hora de vuelo. La utilización está aguas abajo de casi todo lo que hace una aerolínea, desde la disciplina de los tiempos de escala hasta el diseño de red. Dos aerolíneas con flotas comparables pueden terminar con economías muy diferentes; la brecha se remonta a una sola medición, no al tamaño de la flota. Una flota más grande sigue ayudando. Nunca ha sido la variable decisiva.

El cuello de botella pasó de los modelos al cómputo y al hardware inactivo

La primera ola de la IA empresarial se ganó por la calidad de los modelos. Esa capacidad vino acompañada de una dependencia, porque la IA de producción se ejecuta en GPU que son caras, con oferta limitada y con una demanda que supera con creces lo disponible. En 2020, Microsoft construyó para OpenAI un supercomputador dedicado: más de 10 000 GPU y 285 000 núcleos de CPU, creado para entrenar lo que se convirtió en GPT-3. Seis años después, esa cifra parece un punto de partida. Para 2026, Anthropic mantenía compromisos simultáneos de múltiples gigavatios en cuatro plataformas de hardware, Amazon, Google, Microsoft y AMD, , mientras Meta firmaba un acuerdo comparable por su cuenta. Comprometerse con cuatro proveedores a la vez es lo que parece la escasez cuando ni siquiera el capital ilimitado puede obtener lo suficiente de una sola fuente.

El mismo patrón aparece aguas abajo en otra forma. Los precios de las API escalan linealmente con los tokens, separando casi por completo la economía de una prueba de concepto de la de producción. Unos pocos miles de solicitudes al mes parecen asequibles; el volumen de producción se convierte en una línea de costo que nunca termina de cerrar. La ruta que gana terreno es poseer el hardware, intercambiando un costo variable por uno fijo de capital. AMD ya está vendiendo en esa dirección: su escritorio para desarrolladores de 128 GB cuesta unas seis veces menos que el uso equivalente de API en la nube a lo largo de tres años, según los propios cálculos de la empresa, y ejecuta localmente modelos de hasta 200 000 millones de parámetros. El día en que un clúster así entra en funcionamiento, la pregunta pasa de «¿podemos conseguir aceleradores?» a «¿podemos mantenerlos ocupados?».

Firmar por el hardware es la parte que tiene plazo y dueño. Mantenerlo en el aire es la parte que decide silenciosamente si el acuerdo valió la pena firmarlo.

Los clústeres ocupados pueden, aun así, desperdiciar gran parte de su capacidad

Las GPU funcionan de forma continua mientras que la demanda no, por lo que una parte de la capacidad permanece aprovisionada pero sin usarse fuera del pico. Una mejor previsión resolvería eso si cada GPU pudiera absorber igual de bien todos los tipos de trabajo. Pocas pueden. El mismo hardware ahora soporta entrenamiento, ajuste fino, cuantización, inferencia en tiempo real, inferencia por lotes, generación de embeddings y evaluación de modelos, a menudo en el mismo clúster, y cada carga de trabajo exige algo diferente del silicio:

Carga de trabajo	Lo que exige de la GPU
Inferencia en tiempo real	Baja latencia por encima de casi todo lo demás; una respuesta lenta cuenta como fallida
Inferencia por lotes	Rendimiento; tolera demoras que pueden extenderse por horas
Entrenamiento	Ocupación continua, durante tramos medidos en horas o días
Cuantización	Gran capacidad, pero solo brevemente

Un planificador ajustado para una de estas asigna mal las otras tres casi por defecto, y el fallo no siempre aparece en un panel de utilización: un clúster puede reportar una ocupación alta mientras los trabajos en cola esperan por un tipo de GPU que está ocupado ejecutando otra cosa. Aquí la analogía de las aerolíneas se queda corta. Un 737 inactivo puede reasignarse a casi cualquier ruta. Una GPU inactiva solo puede absorber una carga de trabajo cuyo perfil de memoria, latencia y duración pueda servir de verdad, lo que hace que la orquestación sea más difícil que la programación de flotas y convierte la pregunta en qué carga de trabajo se ejecuta en qué GPU, cuándo y con qué prioridad.

La pregunta de las 3 a. m. y el interés del proveedor en la respuesta

El aprovisionamiento es una decisión que se toma una sola vez, en el momento de la compra. La asignación se toma de forma constante: cada vez que termina un trabajo, cada nueva solicitud, cada cambio de prioridad entre un servicio orientado al cliente y un proceso de entrenamiento interno. Ningún ingeniero está mirando un panel a las tres de la mañana para decidir si una ejecución de entrenamiento terminada debería ceder su GPU a un trabajo por lotes en cola o reservarla para una ráfaga entrante de tráfico. Por eso la decisión se está moviendo hacia una capa de orquestación, una disciplina que el ensayo llama gestión de GPU.

El argumento final del ensayo combina esa orquestación con la especialización. Los modelos específicos para una tarea pueden hacer trabajos concretos a una fracción del costo de recursos de un gran modelo generalista, liberando capacidad. Pero la capacidad liberada solo se convierte en retorno si algo decide activamente adónde va. La especialización sin orquestación libera capacidad que nadie recupera; la orquestación sin especialización tiene menos capacidad que valga la pena recuperar. Cada una eleva el techo de la otra.

La lógica se sostiene por sí sola, con un asterisco que vale la pena mencionar. El ensayo proviene de Dharma AI, que vende modelos especializados de código abierto, y cierra remitiendo a los lectores a sus lanzamientos en Hugging Face. La comparación con las aerolíneas es la mitad fuerte del argumento. La conclusión de que la respuesta son modelos especializados más pequeños es también la tesis de producto de la empresa que lo plantea.

Tampoco se debería esperar que la eficiencia reduzca la demanda total de cómputo: la inferencia más barata se usa más, no menos, como mostró nuestra cobertura de la hipótesis de los 314 000 millones de dólares. El hardware ya está instalado, ya se está depreciando, ya está comprometido, y pierde dinero por hora de calendario. Las aerolíneas aprendieron que el ganador rara vez es la flota más grande, sino la que hace volar lo que tiene de la forma más completa. La IA empresarial está llegando a la misma disciplina desde una dirección diferente. La pregunta es a quién se le asigna esa responsabilidad antes de que las horas inactivas se acumulen.