OmniPilot: An Uncertainty-Aware LLM Inference Advisor for Heterogeneous GPU Clusters

Resumen Técnico: OmniPilot

Declaración del Problema

Servir Modelos de Lenguaje Extensos (LLMs) en clústeres de GPU compartidos y heterogéneos presenta un complejo problema de decisión previo al envío. Los operadores deben seleccionar el tipo de GPU, el grado de paralelismo de tensores (TP), y la precisión numérica antes de comprometer valiosas horas-nodo. Este proceso está plagado de desafíos:

• Altas Tasas de Fallo: La selección ciega de configuraciones conduce a fallos inmediatos debido a incompatibilidades de hardware o agotamiento por falta de memoria (OOM). En las ejecuciones de benchmark de los autores, el 14% de los trabajos fallaron inmediatamente.
• Interacciones No Intuitivas: Las recetas de despliegue estáticas no logran capturar las intrincadas dinámicas entre hardware y software. Por ejemplo, la cuantización de 4 bits puede ser más lenta que la de 16 bits en ciertos entornos de ejecución, y la presión del caché de Clave-Valor (KV) crea compromisos de tamaño frente a precisión no monotónicos.
• Limitaciones de Datos: Los planificadores de clúster tradicionales (p. ej., Slurm) carecen de visibilidad sobre los comportamientos específicos de la carga de trabajo (familia del modelo, precisión, concurrencia) y dependen de telemetría obsoleta (p. ej., intervalos de muestreo DCGM de 60 segundos) que representa erróneamente el rendimiento de servicio activo.
• Incertidumbre: Los sistemas existentes optimizan la ejecución dentro de una configuración preseleccionada, pero no proporcionan estimaciones de incertidumbre calibradas para elegir dicha configuración, dejando a los operadores incapaces de distinguir entre solicitudes soportadas y no soportadas (Fuera de Distribución o OOD).

Metodología

OmniPilot es un asesor de lanzamiento diseñado para predecir costos de servicio y recomendar configuraciones óptimas mientras gestiona explícitamente la incertidumbre. Su arquitectura consta de tres componentes principales:

1. Infraestructura de Datos

OmniPilot utiliza dos almacenes de datos distintos para garantizar la trazabilidad y la reproducibilidad:

• Almacén Personal: Una cuadrícula de benchmark controlada (1,667 filas) que cubre familias de modelos, GPUs y precisiones específicas.
• Almacén de Todo el Clúster: Telemetría agregada de 500,000 trabajos históricos, utilizada para derivar priors de éxito de lanzamiento y patrones de demanda.
• Ingeniería de Características: El sistema codifica ~28 características, incluyendo numéricos logarítmicos (tamaño del modelo, concurrencia), numéricos lineales (grado de TP, memoria), y codificaciones one-hot para familias de modelos, tipos de GPU y formatos de cuantización. Crucialmente, los nuevos ejes (p. ej., tipos de cuantización) se representan en el featurizer antes de la recolección de datos para evitar la fuga de características (feature leakage).

2. Modelo de Costo de Inferencia

El predictor central es un conjunto de regresores de gradiente potenciado (gradient-boosted regressors) utilizando pérdida de cuantiles, entrenados en el espacio logarítmico para manejar errores multiplicativos.

• Objetivos: Predice ocho objetivos, incluyendo tokens/s agregados, rendimiento de solicitudes (throughput), Tiempo al Primer Token (TTFT), tiempo de arranque en frío, uso pico de caché KV y potencia promedio.
• Calibración: El modelo emplea Regresión de Cuantiles Conformalizada (CQR) para generar intervalos de predicción. Utiliza un desplazamiento aditivo de conformalismo dividido, calibrado sobre los residuales de las celdas retenidas, para lograr una cobertura del 80% en cargas de trabajo no vistas.
• Mecanismo de Abstención: Para manejar solicitudes Fuera de Distribución (OOD), OmniPilot utiliza una verificación de distancia de soporte. Si una solicitud cae fuera de la envolvente de soporte medida (definida a través de siete ejes), el sistema la marca como de baja confianza y se abstiene, independientemente del ancho del intervalo.

3. Utilidad de Decisión y Ubicación

OmniPilot clasifica los "brazos" de configuración (combinaciones de GPU, TP y precisión) utilizando una métrica de utilidad económica calibrada según las preferencias del operador.

• Función de Utilidad: $Utilidad = (Throughput \times Runtime \times Valor) - (Costo de Cómputo + Espera en Cola + Costo de Fallo Esperado + Costo de Violación de SLO + Penalización de Saturación de KV)$.
• Prior de Éxito de Lanzamiento: Un estimador beta-binomial reduce las tasas de fallo por configuración hacia una tasa agrupada del clúster, teniendo en cuenta la observación de que las configuraciones multi-GPU (p. ej., TP=4) tienen un éxito de lanzamiento significativamente menor (~38%) que las configuraciones de una sola GPU.
• Penalización de Saturación de KV: Se aplica una penalización de rendimiento multiplicativa cuando la ocupación del caché KV supera el 0.85, convirtiendo las interrupciones (preemptions) en costos de utilidad.

Contribuciones Clave

1. Asesor Calibrado y con Capacidad de Abstención: OmniPilot es el primer sistema que combina modelos de costo de cuantiles con calibración conformal y una capa de abstención OOD explícita para la inferencia de LLM. Predice métricas de rendimiento junto con intervalos calibrados y una señal de seguridad para bloquear solicitudes no soportadas.
2. Evaluación Acoplada a la Decisión: El artículo introduce un marco de evaluación libre de fugas utilizando GroupKFold (agrupado por celda de carga de trabajo) para comparar el asesor contra baselines sin modelo. Demuestra que optimizar para la utilidad económica (incorporando costo y riesgo de fallo) produce una precisión de ubicación significativamente mejor que las políticas basadas solo en throughput o reglas.
3. Estudio de Telemetría de Clúster (Resultado Negativo): Los autores demuestran que, si bien los metadatos del planificador (Slurm) son suficientes para derivar priors de demanda y éxito de lanzamiento, son insuficientes para construir un asesor de throughput para todo el clúster, ya que registran la asignación de recursos (cómo se usó una GPU) en lugar de la carga de trabajo de software específica (qué se ejecutó en ella).

Resultados

Evaluado a través de 460 ejecuciones de benchmark en hardware A100, H100 y H200:

• Precisión de Predicción: OmniPilot predice el throughput agregado con un Error Absoluto Porcentual Medio (MAPE) del 6.2% y un $R^2$ en el espacio logarítmico de 0.92.
• Precisión de Ubicación: El asesor logra una precisión top-1 del 95% en la selección de la configuración óptima, con un arrepentimiento (regret) de utilidad media de 0.003. Esto es un orden de magnitud mejor que los baselines como las reglas de "umbral de tamaño" (regret 1.97) o las políticas de "máximo throughput" (regret 4.73).
• Manejo de OOD: En un conjunto de prueba de 5 celdas no soportadas (nuevas familias de modelos o contextos extremos), el error de predicción aumentó a 24–46%, y los intervalos conformes no cubrieron los valores reales. Sin embargo, la capa de abstención identificó con éxito las cinco como de baja confianza, evitando despliegues riesgosos.
• Eficiencia de Datos: La precisión se satura después de aproximadamente 150 filas de entrenamiento una vez que los ejes de la tarea están cubiertos, lo que indica que la cobertura del espacio de configuración es más crítica que el volumen bruto de datos.

Significancia y Reivindicaciones

El artículo afirma que OmniPilot llena un vacío crítico a nivel macro en clústeres de GPU compartidos y multi-usuario, transformando la selección de configuración de hardware en una decisión económica calibrada. Su significancia radica en:

• Seguridad y Fiabilidad: Al abstenerse explícitamente en solicitudes OOD, evita los fallos costosos que las recetas estáticas o los planificadores de "mejor esfuerzo" incurrirían.
• Optimización Económica: Va más allá de la simple maximización del throughput para optimizar una función de utilidad compleja que equilibra el costo, el riesgo de fallo y los SLOs, alineándose con las restricciones reales de los operadores.
• Rigor Metodológico: Establece un marco de diseño "característica-antes-de-los-datos" y demuestra que muchos problemas de rendimiento se resuelven mejor mediante un diseño de utilidad refinado (p. ej., penalizaciones de saturación de KV) o precisión de medición (p. ej., ventanas de frescura) en lugar de simplemente aumentar la capacidad del modelo.

Los autores mantienen la modestia sobre el alcance, señalando que el sistema actualmente está limitado a la inferencia de servicio vLLM de un solo nodo. Los flujos de trabajo de entrenamiento, la recuperación de fallos y las arquitecturas de servicio multi-nodo se difieren explícitamente para investigaciones futuras. El sistema depende de datos empíricos de un clúster específico (Kempner AI), y los umbrales absolutos (p. ej., la rodilla de saturación de KV) son específicos de cada despliegue.