Equipos que gestionan cargas de trabajo de inteligencia artificial (IA) en Kubernetes suelen pensar que ampliar su pool de GPUs es la solución ante una cola creciente de trabajos en batch. Sin embargo, esta acumulación puede deberse a factores como la programación, la capacidad de servicio disponible, o incluso el modelo y hardware elegidos. Por ello, antes de aumentar la cantidad de GPUs, es fundamental establecer con claridad qué significa el éxito, cuándo deben terminarse las cargas y cuál es el coste real para lograrlo.
Es imprescindible entender que una GPU asignada, una GPU ocupada y un trabajo que produce resultados valiosos no son lo mismo. Esta distinción ayuda a aprovechar mejor la capacidad actual sin incurrir en costes innecesarios por sumar más hardware de forma prematura.
Empieza definiendo el resultado esperado y la fecha límite
Es esencial analizar las cargas de trabajo y su contexto específico. Por ejemplo, un chatbot de atención al cliente puede requerir capacidad de inferencia constante, mientras que un trabajo de evaluación de modelos solo necesita completarse antes de la próxima reunión de lanzamiento interno. Clasificar los trabajos en categorías generales como «inferencias» o «entrenamientos» no es suficiente para determinar la urgencia real. Algunos trabajos en batch pueden retrasarse, mientras que otros, incluso de entrenamiento, pueden tener una fecha límite estricta. 
Para cada tarea, se debe documentar la fecha límite, tiempo estimado de ejecución, requerimientos de recursos y si es posible interrumpirla o no. También es importante definir qué constituye un resultado útil: un servicio de inferencia debe establecer un umbral de calidad específico y un objetivo de latencia. Que un trabajo genere una respuesta válida o simplemente responda no garantiza que haya cumplido con sus objetivos.
Además, hay que diferenciar claramente la flexibilidad en la hora de inicio del trabajo frente a la tolerancia a interrupciones. Un trabajo que puede esperar para comenzar, puede no aceptar interrupciones una vez en marcha.
Aprovecha la flexibilidad en la programación antes de aumentar la capacidad
Imaginemos que hay cuatro GPUs compatibles para trabajos batch disponibles entre las 12:00 y las 17:00. Cuatro evaluaciones independientes están listas a las 12:00, cada una requiere dos GPUs durante una hora y todas deben finalizar a las 17:00.
Ejecutar las cuatro tareas simultáneamente requiere ocho GPUs. No obstante, si se agrupan dos trabajos al mediodía y otros dos a la 1 p.m., se completan las cuatro tareas a las 2 p.m. con solo las cuatro GPUs disponibles. A igualdad de tiempos y recursos asociados, ambas formas consumen el mismo número de GPU-horas, salvo el coste asociado al arranque.
Esta programación escalonada reduce la demanda máxima sin que se retrase la entrega. Por ello, antes de comprar más GPUs para vaciar una cola, conviene analizar cuánta flexibilidad existe para escalonar tareas.
Herramientas como Kueue ofrecen un punto de control para la admisión de trabajos basándose en cuotas y políticas definidas. Sin embargo, los equipos deben implementar de forma eficaz las reglas sobre tiempos límites y requisitos de cada tarea. Así, una gestión flexible de colas ayuda a planificar la capacidad y evita la ejecución prematura de trabajos que luego puedan ser interrumpidos.
Mide realmente cuánta carga útil puede soportar tu despliegue
La programación flexible ataja limitaciones, pero hay que evaluar si el modelo y su configuración coinciden con la carga esperada.
La mera alta ocupación de GPU no indica cuánto margen queda para más carga. Por ejemplo, según la documentación de Nvidia, una actividad elevada en los multiprocesadores de streaming puede incluir operaciones esperando respuesta de memoria. Métricas adicionales como el número de peticiones activas o en cola y la ocupación de cache ofrecen mejor perspectiva. Contabilizar preempciones también ayuda a entender comportamientos. Sistemas como vLLM miden aspectos como el uso del KV-cache, aunque esta métrica no refleja directamente la capacidad total de servicio.
Lo adecuado es medir la capacidad sostenible a través de pruebas de carga representativas, manteniendo fijos modelo, hardware y configuración. Aumentando gradualmente la tasa de llegada de solicitudes y monitorizando el throughput, calidad y latencia, el máximo ritmo que cumple con requisitos (incluyendo errores y percentiles de latencia) proporciona una estimación realista. Para generación interactiva, conviene medir no solo el tiempo hasta la finalización, sino también el tiempo hasta la entrega del primer y siguientes tokens. Estudios como DistServe subrayan la importancia de evaluar capacidad con objetivos concretos de la aplicación.
Después, es clave comparar el tráfico real con esa capacidad testada. Si la ocupación de cache es baja, conviene investigar posibles ineficiencias. Colas breves pueden indicar picos temporales, mientras colas persistentes deben ser diagnosticadas para identificar el recurso limitante real.
Relaciona costes (OpenCost) con resultados probados
Desde la perspectiva FinOps, la eficiencia en IA se entiende como la relación entre costes y resultados útiles. En cargas de IA, el coste cobra sentido si se vincula literalmente a los resultados que la infraestructura posibilita. Equipos de Kubernetes pueden hacerlo combinando datos de coste por tarea, comportamiento del servicio y resultados reales.
La API de asignación de costes de OpenCost permite obtener costes por tarea en intervalos definidos y cruzar estos datos con la telemetría del servicio y registros de resultados, utilizando identificadores y marcas temporales. OpenCost incluye opcionalmente seguimiento del coste en inferencias, como coste por millón de tokens. Al calcular el coste por resultado, se deben incluir GPUs, CPUs, memoria y otros gastos, asignando de forma documentada costes compartidos o tiempos de inactividad. Si hay costes externos a OpenCost, deben añadirse aparte para evitar duplicidad.
Una métrica válida es el «coste por resultado verificado»: coste total atribuible dividido por el número de resultados que cumplen criterios de calidad y tiempo establecidos. Se deben contabilizar reintentos, fallos, arranques y períodos ociosos que impactan en los costes totales, contando cada resultado una sola vez. Cuando la calidad se estima por muestreos, es necesario documentar el método y margen de error.
OpenCost provee la asignación financiera; la aplicación los criterios y evidencias de evaluación. La capacidad requiere mediciones específicas independientes. Existe actualmente una propuesta para incorporar telemetría del motor de servicio al modelo de costes, aunque aún en borrador.
Valora si la capacidad extra justifica su coste
Consideremos un servicio que procesa 1.000 tareas por hora y exige un 98% de resultados correctos. Un modelo pequeño que solo logra 90% es inadecuado aunque ocupe un GPU barato.
Un modelo más potente puede producir 990 resultados correctos a un coste de 2 dólares por hora, usando solo parte de su capacidad testada. Esto supone un coste de alrededor de 2,02 dólares por cada 1.000 resultados cualificados; la capacidad sobrante puede justificarse para garantizar calidad y absorber picos.
El siguiente paso es comprobar si una GPU más pequeña, menos réplicas o ajustes en el batching mantienen resultados y fiabilidad requeridos. Si, con estas modificaciones, se logran los mismos 990 resultados por 1,50 dólares, el coste baja a 1,52 dólares por cada 1.000 resultados validos. El ahorro proviene de usar menos recursos para idéntico resultado. Incrementar simplemente la utilización sin mejorar resultados no aporta valor comparable.
Cuando dos modelos cumplen mínimos, mejoras adicionales en calidad pueden justificar mayor coste si reducen errores graves o revisión manual. Siempre hay que poner este valor en contexto con la demanda real. El coste por resultado correcto es más útil cuando los resultados comparados tienen utilidad y consecuencias similares.
Hay que modificar una variable clave a la vez y comparar coste, resultados validados, latencia y cumplimiento de límites bajo demanda realista. Se debe reservar capacidad para picos y fallos y comprobar que baja actividad refleja realmente capacidad disponible. Un GPU dedicado exclusivamente a un Pod solo se libera cuando termina su tarea.
Con esta evidencia, el equipo puede optar por retrasar trabajos flexibles, mejorar el agrupamiento, redimensionar despliegues, seleccionar otro modelo o ampliar GPUs. El objetivo es un despliegue que entregue resultados con la calidad requerida a un coste razonable, con suficiente margen para cumplir sus metas.
