Antes de ampliar tu pool de GPU, mide el resultado real

Cuando un equipo ejecuta cargas de IA sobre Kubernetes, ver el pool de GPU al completo y una cola de trabajos por lotes que no deja de crecer suele llevar a una conclusión rápida: hay que ampliar. Pero esa cola puede estar señalando problemas de planificación, de capacidad de servicio o de elección de modelo y hardware, no necesariamente falta de tarjetas. Antes de provisionar más capacidad conviene tener claro qué significa el éxito, cuándo debe estar terminado y cuánto cuesta entregarlo.

La idea central es sencilla pero se olvida con frecuencia: una GPU asignada, una GPU ocupada y una carga de trabajo que produce resultados valiosos no son lo mismo. Entender cómo se relacionan estos tres conceptos permite aprovechar mejor la capacidad existente antes de comprar la que de verdad se necesita.

Empieza por el resultado y la fecha límite

El primer paso es mirar las cargas de trabajo y los casos de uso que sostienen. Un chatbot de atención al cliente puede necesitar capacidad de inferencia las 24 horas, mientras que los resultados de un trabajo de evaluación de modelos quizá solo hagan falta antes de la próxima sincronización interna de release. Clasificar por categorías amplias como «inferencia» o «entrenamiento» no determina la urgencia: hay inferencia por lotes que puede esperar y entrenamientos con fecha límite firme.

Para cada carga conviene documentar la fecha límite, el tiempo de ejecución esperado, los requisitos de recursos y si se tolera la interrupción. También hay que definir qué cuenta como salida valiosa. Un servicio de inferencia debería tener un umbral de calidad específico para su tarea y un objetivo de latencia; que una petición termine o devuelva un JSON válido no demuestra que haya cumplido su objetivo.

Un matiz importante: la flexibilidad para empezar no es lo mismo que la tolerancia a la interrupción. Un trabajo que puede esperar a arrancar puede necesitar, una vez lanzado, ejecutarse sin cortes.

Usa la flexibilidad de planificación antes de ampliar

Pongamos un ejemplo concreto. Hay cuatro GPU compatibles disponibles para trabajo por lotes de mediodía a cinco de la tarde. A mediodía están listos cuatro trabajos de evaluación independientes. Cada uno necesita dos GPU durante una hora y todos los resultados vencen a las cinco. Lanzar los cuatro a la vez exige ocho GPU. Si se escalonan dos a mediodía y dos a la una, todo termina a las dos usando solo las cuatro GPU disponibles.

Si los tiempos de ejecución y los recursos auxiliares no cambian, ambos planes consumen las mismas horas de GPU. La diferencia es que escalonar reduce la demanda punta y los trabajos siguen terminando a tiempo sin ampliar el pool. Herramientas como Kueue ofrecen un punto de control de admisión que, con cuotas y políticas configuradas, decide cuándo se admite el trabajo. El equipo sigue teniendo que decidir cómo representar y hacer cumplir fechas límite y requisitos.

Mide cuánto trabajo útil sostiene tu despliegue

La planificación flexible alivia la presión, pero en inferencia hay que revisar además cómo encajan el modelo y la configuración de servicio con la carga real. Una actividad alta en la GPU no garantiza que quede margen de rendimiento. La documentación de perfilado de Nvidia recuerda que la actividad de los multiprocesadores de streaming puede incluir warps esperando por memoria. Métricas de servicio como peticiones en ejecución, peticiones en espera y ocupación de caché aportan contexto, y los contadores de preempción ayudan a explicar el comportamiento. En vLLM, el uso de la caché KV mide la fracción de bloques ocupados, pero no mide directamente la capacidad total de servicio.

Para estimar capacidad sostenible hay que hacer una prueba de carga representativa: mantener fijos modelo, hardware, ajustes de servicio y mezcla de peticiones, subir la tasa de llegada y observar rendimiento, calidad y latencia. La tasa sostenida más alta que siga cumpliendo los requisitos —incluidos límites de error y percentiles de latencia— da una estimación útil. En generación interactiva hay que incluir el tiempo hasta el primer token y la entrega posterior, no solo el tiempo medio de finalización.

Las colas breves pueden ser picos temporales; las persistentes quizá exijan diagnóstico. Ninguna de las dos identifica por sí sola el recurso limitante.

Conecta coste con resultados verificados

La comunidad FinOps enmarca la eficiencia de la IA en coste y resultados útiles. En Kubernetes se puede concretar combinando coste de la carga, comportamiento del servicio y resultados de la aplicación. La API de asignación de OpenCost permite obtener costes por carga en intervalos definidos y cruzarlos con telemetría de servicio y registros de resultados usando identidades y marcas de tiempo. OpenCost también ofrece seguimiento opcional de coste de inferencia, incluido el coste por millón de tokens.

Al calcular coste por resultado hay que incluir GPU, CPU, memoria y otros costes de infraestructura, y documentar cómo se reparten los compartidos y los de inactividad. Una métrica útil es el coste por resultado verificado: coste total atribuible dividido entre los resultados que cumplen la calidad exigida y llegan en plazo. Hay que contar reintentos, fallos, arranques y periodos de inactividad cuando contribuyan al total, y contar el resultado de negocio final una sola vez.

Qué recomendamos desde ForgeNEX

Para una pyme o un equipo de IT con recursos limitados, la tentación de ampliar hardware es comprensible, pero cara. Nuestra recomendación es tratar el pool de GPU como cualquier otro recurso crítico: con métricas de negocio, no solo de utilización.

• Define el resultado antes de comprar. Para cada carga, deja por escrito fecha límite, tiempo esperado, recursos y tolerancia a interrupciones. Sin esto, cualquier ampliación es a ciegas.
• Escalona antes de escalar. Revisa si las colas se resuelven moviendo el inicio de los trabajos. Herramientas de admisión como Kueue pueden ayudar si el volumen lo justifica.
• Haz una prueba de carga representativa antes de afirmar que necesitas más capacidad. La actividad de GPU engaña.
• Une coste y resultado. OpenCost da la parte de coste; tú tienes que aportar la definición de calidad y plazo. Sin ambas, el dato no sirve para decidir.

En un contexto donde el talento TI escasea y cada euro de infraestructura compite con otras prioridades —como comentábamos al hablar del salario TI y la falta de perfiles—, exprimir la capacidad instalada antes de ampliarla no es una optimización menor: es gestión responsable. Y si tu equipo también está lidiando con la seguridad de la cadena de suministro, conviene no perder de vista casos como el zero-day en VeloCloud, donde una cuenta de lectura basta para comprometer el entorno.

Ampliar un pool de GPU sin medir el resultado es una forma cara de posponer una conversación que tu equipo debería tener igualmente: qué trabajo aporta valor, en qué plazo y a qué coste.

Fuente: The New Stack. Análisis y adaptación: ForgeNEX.