Se hace ping al equipo porque la latencia de inferencia ha aumentado repentinamente en un 60%. Los paneles son confusos. La utilización de la GPU todavía parece saludable:
Nada parece catastróficamente malo. Se activa el escalado automático. Se agregan más nodos. El pico de las nubes sube. La latencia apenas mejora.
Una hora más tarde, el problema real resulta sorprendentemente mundano: tres nodos entraron silenciosamente en estados degradados de reconstrucción de RAID, lo que redujo el rendimiento del almacenamiento hasta el punto de privar a las cargas de trabajo de inferencia cercanas. El programador aún trataba esos nodos como "suficientemente saludables" porque las métricas de memoria y GPU parecían aceptables. En palabras simples, una de las unidades de almacenamiento de esas máquinas había fallado o se había vuelto poco confiable y el servidor estaba ocupado reconstruyendo los datos perdidos en las unidades restantes. Técnicamente, las máquinas todavía estaban en línea. No estaban lo suficientemente “muertos” como para ser retirados del servicio. Pero el rendimiento de su disco se había ralentizado considerablemente.
Este tipo de falla es cada vez más común en la infraestructura moderna de IA. Y expone una ilusión más profunda que se esconde debajo de muchos sistemas GenAI:
Las GPU pueden estar ocupadas sin ser productivas.
Esa distinción suena sutil. Financieramente, puede significar millones de dólares.
Los sistemas de IA modernos parecen fluidos desde el exterior. Un usuario envía un mensaje a ChatGPT de OpenAI, Claude de Anthropic o Gemini de Google y obtiene una respuesta pulida segundos después. Detrás de esa experiencia hay un enorme problema de coordinación.
Las GPU ejecutan operaciones tensoriales. Las CPU alimentan solicitudes y mueven datos. HBM almacena activaciones y caché KV. Los SSD transmiten incrustaciones y contexto de recuperación. Las redes mezclan gradientes y tráfico de inferencia entre nodos. Los sistemas de almacenamiento absorben reconstrucciones, reintentos y trabajo en segundo plano.
En algún momento en medio de todo esto, un programador decide dónde deben ejecutarse las cargas de trabajo. Ese programador determina silenciosamente si el clúster se comporta como un sistema informático coherente o como un costoso atasco de tráfico.
Este artículo se basa en el empaquetado geométrico con reconocimiento de residuos (RAGP), presentado en Kaarat et al., y explora por qué los programadores de IA modernos necesitan cada vez más razonar sobre el ancho de banda de almacenamiento, la presión de E/S y el comportamiento dinámico de los recursos, en lugar de tratar las GPU como dispositivos informáticos aislados.
La lección más profunda es más amplia que un algoritmo de programación. Es un problema de sistemas. Y cada vez más, también es un problema económico.
La ilusión de utilización
La utilización de GPU es una de las métricas más confiables en la infraestructura de IA. La alta utilización se siente eficiente. Si las GPU están mayoritariamente ocupadas, el clúster parece estar en buen estado.
Pero los promedios de utilización ocultan la estructura de lo que queda. Un clúster puede informar una alta ocupación de GPU, cargas de trabajo activas y un uso intensivo de memoria, sin dejar de tener una capacidad efectiva deficiente. El problema a menudo no es que los recursos se agoten, sino que los recursos sobrantes sobreviven sólo en combinaciones inutilizables.
Imagínese una gran ciudad en hora punta. Algunas carreteras están vacías. Otros están completamente atascados. Técnicamente, la ciudad todavía tiene capacidad vial. Pero si las intersecciones equivocadas están congestionadas, el tráfico en todo el sistema se ralentiza de todos modos.
Los sistemas de IA distribuidos se comportan de manera similar. Es posible que un clúster aún contenga GPU, HBM, almacenamiento y CPU de repuesto, pero no pueda acomodar de manera eficiente la siguiente carga de trabajo realista. No porque la capacidad haya desaparecido, sino porque la capacidad restante existe en formas equivocadas.
Fragmentación: el modo de falla invisible
Considere tres nodos después de una ráfaga de cargas de trabajo mixtas de GenAI:
Ahora supongamos que llega una nueva carga de trabajo de inferencia que requiere:
GPU moderada, HBM moderada, ancho de banda de almacenamiento saludable y capacidad de E/S saludable.
En todo el clúster, todavía existen suficientes recursos totales.
Pero ningún nodo individual tiene la combinación correcta de recursos restantes. La carga de trabajo no encaja claramente en ninguna parte.
Esto es fragmentación de recursos. El clúster no está vacío. Está fragmentado en restos que son difíciles de utilizar de forma productiva.
Esto se vuelve especialmente peligroso en los sistemas GenAI porque las cargas de trabajo modernas de IA dependen en gran medida de los canales de recuperación, el crecimiento de la caché KV, el rendimiento del almacenamiento y la eficiencia general de la ruta de datos. Un cúmulo puede parecer saludable a 10.000 pies de altura mientras se degrada silenciosamente bajo la superficie.
Un clúster puede tener GPU de repuesto y colas en aumento
Esta es la parte más contradictoria de todo el problema. Un cluster puede tener simultáneamente:
GPU de repuesto, aumento de los tiempos de cola, empeoramiento de la latencia y disminución del rendimiento.
A primera vista esto suena contradictorio. No lo es.
Si las únicas GPU “libres” se encuentran en nodos cuyo ancho de banda de almacenamiento ya está sobrecargado, la profundidad de la cola de SSD se está disparando o la CPU de E/S se consume en el trabajo en segundo plano, entonces esas GPU no están disponibles de manera significativa para la siguiente carga de trabajo útil.
Un planificador codicioso aún puede colocar trabajos allí. Esos trabajos entonces
correr más lento, aumentar la contención, alargar los tiempos de espera y dejar atrás una fragmentación aún peor.
Esto crea un bucle vicioso: más fragmentación → más parada → tiempos de ejecución más largos → más fragmentación. Desde el tablero, el clúster todavía parece ocupado. Operacionalmente, el sistema se está asfixiando lentamente.
Por qué GenAI cambió el panorama de los cuellos de botella
Los programadores tradicionales fueron diseñados para entornos donde la CPU, la memoria, la GPU y la red dominaban las decisiones de ubicación. Los sistemas GenAI modernos cambiaron la forma de la presión sobre la infraestructura:
Las canalizaciones con mucha recuperación pueden saturar el ancho de banda de SSD. Los trabajos de inferencia acumulan caché KV con el tiempo. La carga en los puntos de control puede perjudicar el almacenamiento de objetos. Las cargas de trabajo multimodales crean un movimiento de datos en ráfagas. Las tareas de mantenimiento en segundo plano roban silenciosamente ciclos de CPU que de otro modo alimentarían a las GPU. La degradación del almacenamiento a nivel de nodo puede reducir el rendimiento efectivo mucho antes de que un nodo falle técnicamente.
Esto crea una nueva categoría de patología de infraestructura: la GPU ya no es el único cuello de botella. La ruta que alimenta la GPU es igualmente importante. Eso cambia lo que realmente significa "utilización saludable".
Una GPU hambrienta sigue siendo una GPU cara
Aquí es donde la economía se vuelve seria. La infraestructura moderna de IA es cara. Los precios públicos para 2026 para el acceso a NVIDIA H100 generalmente varían desde dólares de un solo dígito por hora de GPU hasta muy por encima de $ 10 por hora, según el proveedor y el modelo de compromiso.
Ahora amplíelo a una gran flota.
Un clúster H100 de 1000 GPU que funciona a un costo combinado de aproximadamente $3/GPU-hora cuesta aproximadamente:
3.000 dólares/hora, 72.000 dólares/día y alrededor de 26 millones de dólares/año,
antes de los gastos generales de redes, almacenamiento, orquestación y ingeniería.
Ahora imagine que la fragmentación y el bloqueo de E/S desperdician silenciosamente solo el 10% del tiempo productivo de la GPU.
Eso se convierte aproximadamente en:
300 dólares por hora, 7.200 dólares por día y alrededor de 2,6 millones de dólares por año
de gasto ineficiente en infraestructura. No porque las GPU desaparecieran, sino porque el sistema no logró utilizarlas de manera eficiente.
Este es el cambio clave que muchos equipos de infraestructura están empezando a darse cuenta: la métrica real no es la asignación de GPU. Son horas de GPU productivas.
Programación consciente de residuos
La mayoría de los programadores hacen una pregunta engañosamente simple:
"¿Puede esta carga de trabajo caber en este nodo?"
La programación consciente de los residuos plantea una pregunta más importante:
"¿Qué tipo de grupo sobrante crea esta ubicación?"
Esa idea se encuentra en el centro del embalaje geométrico con conciencia de residuos (RAGP), propuesto en Kaarat et al. En lugar de reducir un nodo a unos pocos contadores escalares, RAGP trata la capacidad residual como una forma multidimensional.
A alto nivel:
Se eliminan los nodos inviables, el programador simula los recursos restantes después de la colocación. Prefiere ubicaciones cuyos vectores de recursos sobrantes sigan siendo útiles para cargas de trabajo futuras.
Ese último paso es muy importante.
Dos decisiones de ubicación pueden parecer correctas inmediatamente y al mismo tiempo crear estados futuros de clúster completamente diferentes. Se preserva una capacidad residual saludable. El otro divide los recursos en fragmentos inutilizables. Las métricas de utilización tradicionales a menudo no pueden distinguir entre esos resultados.
Un ejemplo concreto
Supongamos que una carga de trabajo entrante requiere:
GPU equilibrada, HBM equilibrada, ancho de banda de almacenamiento moderado y disponibilidad saludable de CPU.
Después de colocar tentativamente la carga de trabajo:
Un programador escalar puede considerar ambas ubicaciones como aceptables porque:
La GPU sigue disponible, la memoria sigue disponible y la carga de trabajo técnicamente se adapta.
La programación consciente de residuos prefiere el Nodo A.
¿Por qué?
Porque el Nodo B deja atrás una capacidad de almacenamiento casi inutilizable.
Eso se vuelve peligroso una vez que llega la siguiente carga de trabajo con mucha recuperación o aumento de caché. Este es el fallo sutil oculto dentro de muchos clusters GenAI modernos: una ubicación puede ser factible localmente pero dañina globalmente.
Ampliación de RAGP a RAGP-I/O
La formulación original de RAGP razonaba principalmente sobre:
CPU, RAM, computación GPU, HBM y redes.
Eso funcionó razonablemente bien en entornos dominados por la informática.
Las cargas de trabajo de GenAI cambiaron el panorama de los cuellos de botella.
En sistemas reales:
Contención de SSD, profundidad de la cola de almacenamiento, estados RAID degradados, presión de recuperación y saturación de CPU de E/S
puede influir en el rendimiento tanto como la propia utilización de la GPU.
Un nodo puede parecer saludable en términos de computación, memoria y redes, mientras silenciosamente agota las cargas de trabajo debido a cuellos de botella de almacenamiento.
RAGP-I/O amplía el espacio de programación incorporando explícitamente:
ancho de banda de almacenamiento y CPU de E/S
en la lógica de viabilidad y colocación. En lugar de razonar en cinco dimensiones, el programador razona en siete: CPU, RAM, GPU SM, HBM, red, ancho de banda de almacenamiento y CPU de E/S.
Conceptualmente, esto suena como una pequeña extensión. Operacionalmente, cambia significativamente el comportamiento del programador una vez que el almacenamiento se convierte en una restricción activa.
El Simulador Hecho Concreto
Los clústeres de IA de producción son entornos difíciles en los que probar de forma segura programadores experimentales. Para evaluar el comportamiento del planificador en condiciones controladas, el trabajo utiliza un simulador sintético de eventos discretos.
El simulador incluye:
Los escenarios más reveladores son los de estrés por almacenamiento.
Escenario C: aproximadamente entre el 10% y el 20% de los nodos permanecen en estados de reconstrucción RAID en un momento dado, lo que reduce el rendimiento efectivo del almacenamiento. Escenario D: agrega trabajos de inferencia de “respiración” cuyo uso de HBM y demanda de almacenamiento crecen gradualmente con el tiempo para imitar la expansión de la caché KV, por lo que una ubicación que parece segura en el momento de la admisión puede volverse problemática más adelante.
Esto refleja sorprendentemente bien los sistemas GenAI reales.
El resultado más importante
El resultado más importante no es simplemente "RAGP-I/O produjo una menor fragmentación". El resultado más profundo es este:
Una vez que el almacenamiento y la E/S se convierten en restricciones dominantes, los programadores sensatos se desvían sistemáticamente si se omiten esas dimensiones.
Ésa es una visión sistémica más amplia.
Debido a que las cargas de trabajo GenAI modernas requieren cada vez más recuperación, son más sensibles al almacenamiento y evolucionan dinámicamente, el programador ya no puede tratar la GPU como un dispositivo informático aislado. Toda la ruta de datos es importante.
Lo que muestran los experimentos
En escenarios equilibrados, en ráfagas y con estrés por almacenamiento, RAGP-I/O produjo consistentemente:
menor fragmentación, menor pérdida de GPU modelada, capacidad residual más saludable y comportamiento de rendimiento más estable
en comparación con el equilibrio escalar, el empaquetamiento estilo Tetris y la variante RAGP-5D con E/S ciega.
Las mayores ganancias se produjeron en condiciones de estrés por almacenamiento. En experimentos con estrés por almacenamiento, la fragmentación media para RAGP-I/O se mantuvo aproximadamente en el rango de 0,04 a 0,06, mientras que las líneas de base se mantuvieron más cerca de 0,09 a 0,12. La pérdida de GPU modelada se redujo drásticamente, en algunos casos acercándose a cero para RAGP‑I/O, aunque siguió siendo significativa para los otros programadores.
El escenario D muestra el mismo patrón en condiciones más duras: RAGP-I/O mantiene baja la fragmentación, reduce drásticamente el bloqueo total de la GPU y mantiene el rendimiento en el mismo rango general que los programadores más simples.
El resultado de advertencia es igualmente importante. RAGP-5D aún funciona mejor que las líneas base más simples, pero una vez que el almacenamiento se convierte en la restricción dominante, omitir el conocimiento de E/S deja al programador parcialmente ciego. La intuición geométrica es buena. La visibilidad es incompleta.
Stall: El caro impuesto invisible
La fragmentación por sí sola no es el problema operativo. El síntoma más doloroso es el estancamiento.
Los trabajos parecen "en ejecución", pero el progreso significativo se ralentiza porque el nodo no puede alimentar la GPU de manera eficiente. Una carga de trabajo de inferencia puede mostrar una alta ocupación de la GPU y una utilización saludable de la memoria, mientras que los kernels pasan un tiempo significativo esperando el movimiento del almacenamiento, la recuperación o las canalizaciones de datos del lado de la CPU sobrecargadas.
Una carga de trabajo de inferencia puede mostrar:
alta ocupación de GPU y utilización saludable de la memoria,
mientras que los kernels pasan mucho tiempo esperando:
movimiento de almacenamiento, recuperación o canalizaciones de datos del lado de la CPU sobrecargadas.
En la práctica, los equipos de infraestructura a menudo notan el problema conductualmente antes de identificarlo métricamente.
Ciertos nodos simplemente:
"sentirse maldecido", producir una latencia más ruidosa o degradar inesperadamente las cargas de trabajo vecinas.
A veces, los equipos comienzan a drenar manualmente esos nodos mucho antes de que los paneles expliquen claramente por qué.
Esto suele ser una señal de contención oculta en algún lugar de la ruta de datos.
Las compensaciones son reales
Un programador compatible con E/S no es gratuito. Agregar más dimensiones introduce:
requisitos de telemetría adicionales, más complejidad del programador, mayor sensibilidad a la información obsoleta del estado del nodo y posible inestabilidad de la ubicación si las mediciones de recursos fluctúan rápidamente.
Los propios programadores pueden convertirse en sistemas de control inestables bajo una telemetría ruidosa. Un programador que reacciona agresivamente a las fluctuaciones de las métricas de almacenamiento puede corregir en exceso: prefiriendo demasiado ciertos nodos, oscilando el comportamiento de ubicación o amplificando el desequilibrio en otros lugares.
La equidad y la aplicación de políticas multiinquilino también se vuelven más difíciles a medida que la lógica de ubicación se vuelve más sofisticada. Éstas son verdaderas compensaciones de ingeniería. La cuestión no es que la programación basada en E/S resuelva mágicamente la ineficiencia de la infraestructura. El punto es que ignorar por completo el almacenamiento y la E/S se está volviendo cada vez más costoso.
La lección más amplia sobre los sistemas
En última instancia, este artículo trata sobre algo más que programadores. Se trata del comportamiento de los sistemas. Los sistemas saludables no se definen únicamente por la utilización. Están definidos por el flujo coordinado. Ese patrón aparece en todas partes:
sistemas de tráfico, cadenas de suministro, bases de datos distribuidas, infraestructura en la nube y mercados financieros.
Los sistemas saludables no se definen únicamente por la utilización. Están definidos por el flujo coordinado. La optimización local no es lo mismo que la optimización global. Un programador optimizado sólo para su colocación inmediata puede dañar silenciosamente el rendimiento a largo plazo. Un clúster que parece ocupado aún puede ser económicamente ineficiente. Y una GPU que parece activa aún puede pasar mucho tiempo esperando al sistema que la rodea.
Qué deberían monitorear los equipos de infraestructura con más atención
La utilización de la GPU por sí sola ya no es suficiente. El monitoreo serio de la infraestructura GenAI requiere cada vez más visibilidad de:
Presión de HBM, consumo de ancho de banda de almacenamiento, profundidad de la cola de SSD, inflación del tiempo de ejecución frente a la duración esperada, utilización de CPU de E/S, estados de almacenamiento degradados y desaceleración a nivel de nodo en relación con el tiempo de finalización esperado.
Si las cargas de trabajo terminan consistentemente un 20 %, 30 % o 40 % más lento en nodos específicos a pesar de métricas de utilización aparentemente saludables, el programador debe tratar esos nodos de manera diferente. Ahí es donde a menudo vive la ineficiencia oculta.
El monitoreo serio de la infraestructura GenAI requiere cada vez más visibilidad de:
Presión de HBM, consumo de ancho de banda de almacenamiento, profundidad de la cola de SSD, inflación del tiempo de ejecución, utilización de CPU de E/S, estados de almacenamiento degradados y desaceleración a nivel de nodo en relación con el tiempo de finalización esperado.
Pensamiento final
La infraestructura moderna de IA esconde una enorme cadena de suministro de computación, almacenamiento, memoria, redes y coordinación debajo de una experiencia de usuario engañosamente fluida. Los usuarios ven indicaciones y respuestas. Los paneles muestran porcentajes de GPU. En algún punto intermedio, un programador decide silenciosamente si el clúster está realmente en buen estado o simplemente parece ocupado.
Esa distinción importa más que nunca. Porque en los sistemas GenAI modernos, la verdadera pregunta ya no es:
"¿Están ocupadas las GPU?"
Es:
“¿Están ocupados productivamente?”
Descargo de responsabilidad
Los puntos de vista y opiniones expresados en este artículo son los de los autores y no reflejan necesariamente la política o posición oficial de ningún empleador, institución o editor. Todos los experimentos y simulaciones tienen fines de investigación e ilustración únicamente y no deben considerarse como guía para la implementación de producción sin una validación independiente.
Referencias
Kaarat, A., Batthula, VJR y Segall, R. "Ajustar el vacío: embalaje geométrico con reconocimiento de residuos para cargas de trabajo GenAI". IEEE, 2025
Si está interesado en el concepto de empaquetamiento geométrico con reconocimiento de residuos, el modelo de simulación o el código utilizado en este artículo, no dude en comunicarse con [email protected].