💻 computer science

DriftSched: Adaptive QoS-Aware Scheduling under Runtime Token Drift for Multi-Tenant GPU Inference

Este artículo presenta DriftSched, un marco de planificación consciente de la QoS para la inferencia de LLM multi-inquilino que utiliza un mecanismo de retroalimentación en línea para corregir los errores de estimación de tokens en tiempo de ejecución, demostrando que si bien la calibración adaptativa mejora significativamente la precisión de la estimación, la política de planificación de el Trabajo Más Corto Primero (SJF) produce las reducciones más sustanciales en la latencia de extremo a extremo y en la latencia de cola.

Autores originales: Kathiravan Palaniappan

Publicado 2026-06-03

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Kathiravan Palaniappan

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que diriges un restaurante muy popular con una sola cocina (la GPU) y un solo chef. Tienes tres tipos de clientes:

VIPs (Premium): Que quieren su comida rápido y están dispuestos a pagar extra.
Clientes Regulares (Estándar): Que solo quieren una comida normal.
Compradores al por mayor (Batch): Que están pidiendo bandejas enormes de catering y no les importa esperar.

¿El problema? La cocina se ve abrumada. Los pedidos se acumulan y algunos esperan una eternidad mientras otros son atendidos rápidamente. El chef necesita decidir a quién cocinarle después. Esto se llama "programación" (scheduling).

El problema central: Adivinar la carga de trabajo

Para decidir a quién atender después, el programador necesita saber cuánto trabajo representa cada pedido.

¿Es una ensalada sencilla (trabajo corto)?
¿O es una cena compleja de 5 tiempos (trabajo largo)?

Si el programador adivina mal, se produce el caos. Si piensa que un pedido enorme de catering es pequeño, podría atenderlo antes que un aperitivo rápido de un VIP, haciendo que el VIP espere demasiado. Esto se llama "Clasificación Errónea de la Carga de Trabajo" (Workload Misclassification).

Las dos formas de adivinar

El artículo, DriftSched, pone a prueba dos formas de adivinar qué tan grande es un pedido:

La "Adivinanza Perezosa" (Proxy de Espacios en Blanco/Whitespace Proxy): Imagina contar las palabras en el ticket del pedido. Si tiene 10 palabras, probablemente es pequeño. Si tiene 100, es grande. Esto es rápido y fácil para el anfitrión, pero es inexacto. Una frase corta puede ser compleja de cocinar, y una frase larga puede ser simple.
La "Adivinanza del Experto" (Conciencia del Tokenizador/Tokenizer-Aware): Imagina que el anfitrión realmente lee la receta y sabe exactamente cuántos ingredientes y pasos involucra. Esto es preciso, pero toma un poco más de tiempo y esfuerzo para que el anfitrión lo calcule.

La Solución: DriftSched

DriftSched es un sistema inteligente que gestiona este restaurante. Tiene una característica especial llamada "Calibración Adaptativa" (o EMA).

Piénsalo de esta manera: Si el anfitrión usa la "Adivinanza Perezosa" y se da cuenta de que consistentemente subestimó cuánto tiempo toma un plato de "Reporte Técnico", DriftSched aprende de sus errores. Dice: "Ah, cada vez que adivinamos que un Reporte Técnico es pequeño, en realidad tarda un 20% más. La próxima vez, añadiré un 20% a la estimación".

Con el tiempo, la "Adivinanza Perezosa" se vuelve casi tan buena como la "Adivinanza del Experto" porque el sistema corrige sus propios errores basándose en lo que realmente sucedió en la cocina.

Las cinco estrategias de programación

El artículo probó cinco reglas para decidir quién come después:

FIFO (First-In, First-Out): Como una fila estándar de tickets. El primero en llegar es el primero en ser atendido. Es justo, pero si un Comprador al por mayor está delante de ti con un pedido enorme, esperarás una eternidad.
Prioridad (Priority): Los VIPs siempre saltan al frente de la fila. Los Regulares y los Compradores al por mayor esperan. Genial para los VIPs, terrible para todos los demás.
Ponderada (Weighted): Un compromiso. Los VIPs son atendidos el 50% de las veces, los Regulares el 30% y los Compradores al por mayor el 20%. Todos tienen su turno, pero los VIPs reciben más atención.
SJF (Shortest-Job-First / El Trabajo Más Corto Primero): El chef siempre elige el pedido más pequeño y rápido a continuación, independientemente de quién lo haya pedido. Si un Comprador al por mayor tiene un acompañamiento diminuto, se cocina antes que el plato principal de un VIP.
Prioridad por Envejecimiento (Aging Priority): Como la Prioridad, pero si un Comprador al por mayor espera demasiado, su ticket recibe un "sello" que aumenta su prioridad para que no muera de hambre.

¿Qué descubrieron?

1. La precisión importa, pero la estrategia importa más
Usar la "Adivinanza del Experto" (Tokenizador) es mejor que la "Adivinanza Perezosa" (Espacios en blanco). Sin embargo, la regla que usas para elegir al siguiente cliente (la Política de Programación) tiene un impacto mucho mayor en los tiempos de espera que qué tan precisamente adivinaste el tamaño del pedido.

2. SJF es el rey de la velocidad
La regla SJF (El Trabajo Más Corto Primero) fue la más rápida. Redujo el tiempo de espera promedio en aproximadamente un 42% en comparación con la fila estándar (FIFO). ¿Por qué? Porque al despejar primero todos los pedidos pequeños y rápidos, la cocina se mantiene ocupada y eficiente, y menos personas se quedan esperando detrás de un pedido gigante.

3. Priority es el rey de los VIPs
Si te importa mantener contentos a tus VIPs, la Programación por Prioridad (Priority Scheduling) es la mejor. Los VIPs esperaron solo ~77 segundos, mientras que los Compradores al por mayor esperaron ~427 segundos. SJF, por otro lado, no se preocupaba por quién eras; solo le importaba qué tan pequeño era tu pedido. De hecho, bajo SJF, los Compradores al por mayor a veces eran atendidos más rápido que los VIPs porque sus pedidos resultaban ser más pequeños.

4. La "Adivinanza Perezosa" se puede arreglar
La función de autocorrección del sistema (EMA) funcionó bien. Cuando se usaba la "Adivinanza Perezosa" inexacta, el sistema aprendía a ajustar sus estimaciones con el tiempo, reduciendo los errores en un 40%. Sin embargo, si ya usas la "Adivinanza del Experto", la autocorrección no ayuda mucho porque las adivinanzas ya eran precisas.

La conclusión fundamental

Si quieres el servicio más rápido en general: Usa SJF (El Trabajo Más Corto Primero). Despeja la cola más rápido.
Si quieres proteger a tus clientes más importantes: Usa la Programación por Prioridad. Garantiza que los VIPs sean atendidos primero, incluso si eso hace que los demás esperen más.
No te preocupes demasiado por tener una adivinación perfecta: Incluso si tienes una estimación aproximada de cuánto tiempo toma un pedido, la regla de programación que elijas (SJF vs. Prioridad) importa mucho más para el tiempo de espera final. Pero si puedes adivinar con precisión (usando el Tokenizador), el sistema funciona mejor.

En resumen: Cómo haces la fila de los clientes importa más que qué tan perfectamente estimas el tamaño de su pedido.

Resumen Técnico: DriftSched

Declaración del Problema
La rápida adopción de los Modelos de Lenguaje de Gran Escala (LLM) ha intensificado la demanda de un escalonamiento eficiente de GPU multi-inquilino en centros de datos de IA. Si bien los tiempos de ejecución de inferencia modernos como vLLM han optimizado el rendimiento mediante el procesamiento por lotes continuo (continuous batching) y la gestión de memoria, estimar con precisión el costo de ejecución de las solicitudes de inferencia heterogéneas sigue siendo un desafío significativo. Los enfoques de escalonamiento existentes suelen depender de límites estáticos de tokens, restricciones de salida especificadas por el usuario o supuestos de carga de trabajo predefinidos. Estos métodos estáticos no logran capturar el comportamiento dinámico de las cargas de trabajo de LLM en el mundo real, donde las longitudes de salida observadas frecuentemente se desvían de los valores esperados debido a la complejidad del prompt, las características de la respuesta y el comportamiento del modelo.

El artículo identifica esta discrepancia como deriva de tokens en tiempo de ejecución (runtime token drift). Este fenómeno introduce errores de estimación que se propagan hacia las decisiones de escalonamiento, lo que conduce a una clasificación errónea de la carga de trabajo, desequilibrio en las colas, latencia de cola inflada, asignación de recursos injusta entre inquilinos y degradación de la Calidad de Servicio (QoS) bajo contención de GPU. Los algoritmos de escalonamiento tradicionales (por ejemplo, FIFO, SJF), diseñados para sistemas con costos de ejecución predecibles, tienen dificultades en entornos de LLM multi-inquilino donde el comportamiento en tiempo de ejecución depende de factores dinámicos como el crecimiento del KV-cache y la dinámica de procesamiento por lotes (batching).

Metodología y Arquitectura del Sistema
Para abordar estos desafíos, los autores proponen DriftSched, un marco de escalonamiento adaptativo consciente de la QoS diseñado para la inferencia de LLM multi-inquilino en GPUs NVIDIA L4. La arquitectura del sistema integra la clasificación de la carga de trabajo, la estimación del presupuesto de tokens, la gestión de colas consciente del inquilino y un mecanismo de compensación de deriva impulsado por retroalimentación en tiempo de ejecución.

Estimación Adaptativa de Tokens: A diferencia de los enfoques estáticos, DriftSched estima el costo de inferencia antes de la ejecución en la GPU combinando la clasificación de la carga de trabajo, factores de seguridad conscientes del inquilino y la complejidad del prompt. Crucialmente, emplea un factor de sesgo adaptativo ( $B_{runtime}$ ) que se actualiza continuamente mediante retroalimentación de ejecución. El recuento estimado de tokens de salida se calcula como:
$T_{estimated\_output} = T_{base} \times B_{runtime} \times S_{tenant} \times F_{input}$
donde $B_{runtime}$ se aprende de la relación entre las longitudes de salida observadas y las estimaciones base.
Clasificación de Carga de Trabajo y Encolamiento: Las solicitudes de inferencia se clasifican en categorías semánticas (short_qa, summary, technical, report) y se mapean a clases de escalonamiento en tiempo de ejecución (short, medium, long) basadas en el presupuesto estimado de tokens. Las solicitudes se asignan a colas específicas de cada inquilino (Premium, Standard, Batch) gestionadas a través de Redis.
Estrategias de Escalonamiento: El marco evalúa cinco políticas de escalonamiento: Primero en Llegar Primero en Servirse (FIFO), Escalonamiento de Prioridad (Priority Scheduling), Escalonamiento Ponderado (Weighted Scheduling), El Trabajo Más Corto Primero (SJF) y Escalonamiento de Prioridad por Envejecimiento (Aging Priority Scheduling).
Ciclo de Retroalimentación: El sistema opera en dos fases: una fase de calibración (primeros 1,000 requests) para recolectar retroalimentación de ejecución y hacer converger los factores de sesgo, y una fase de evaluación de estrés (restantes 2,000 requests) donde el escalonador utiliza los valores de sesgo aprendidos mientras continúa la adaptación en línea. La regla de actualización adaptativa utiliza un Promedio Móvil Exponencial (EMA) para refinar los factores de sesgo basados en la desviación entre los conteos de tokens estimados y observados.

Contribuciones Clave

Arquitectura Adaptativa Consciente de la Deriva: Un novedoso marco de escalonamiento que trata la estimación de la carga de trabajo como un problema de compensación de la deriva de tokens en tiempo de ejecución, actualizando dinámicamente los factores de sesgo para alinear las predicciones con el comportamiento observado.
Mecanismo de Compensación de Deriva de Tokens en Tiempo de Ejecución: Un método impulsado por retroalimentación que reduce el error de estimación al comparar continuamente los presupuestos de tokens estimados contra las longitudes de salida reales, mejorando la precisión del escalonamiento en el momento de la admisión.
Marco de Benchmarking Reproducible: Una configuración de evaluación exhaustiva utilizando vLLM en GPUs NVIDIA L4, simulando tráfico multi-inquilino heterogéneo con variaciones en la complejidad de los prompts y tasas de llegada para evaluar la equidad, la latencia y el rendimiento (throughput).

Resultados Experimentales
Los experimentos se realizaron utilizando 3,000 solicitudes de inferencia a través de tres niveles de inquilinos y cuatro tipos de carga de trabajo semántica en una GPU NVIDIA L4.

Existencia de la Deriva de Tokens: El estudio confirmó una deriva de tokens en tiempo de ejecución medible a través de las categorías de carga de trabajo. La estimación estática del presupuesto de tokens de forma consistente sobreestimó el comportamiento de generación real.
Precisión de la Estimación: El mecanismo de retroalimentación adaptativa redujo el error de estimación de la carga de trabajo en un promedio de 38.8% (MAE) y 40.5% (RMSE) en todas las políticas de escalonamiento evaluadas en comparación con las líneas base estáticas.
Desempeño de Latencia: Entre las políticas de escalonamiento, El Trabajo Más Corto Primero (SJF) logró el mejor desempeño general. En comparación con FIFO, SJF redujo la latencia de extremo a extremo mediana (P50) aproximadamente un 42% y la latencia P99 aproximadamente un 16%. Esta mejora se atribuyó a la priorización de las cargas de trabajo más cortas y a la reducción de la ocupación de las colas.
Compromisos (Trade-offs): Mientras que SJF optimizó la latencia global, los escaladores conscientes del inquilino (Priority, Weighted, Aging) proporcionaron una diferenciación de QoS más fuerte para los inquilinos Premium. Por ejemplo, el escalonamiento de Prioridad redujo la latencia del inquilino Premium a ~77 segundos pero aumentó la latencia del inquilino Batch a ~427 segundos.
Utilización de la GPU: El análisis reveló que la latencia de ejecución de la GPU y la utilización de la memoria se mantuvieron relativamente constantes en todas las políticas de escalonamiento. Esto indica que las diferencias de desempeño se originaron en la gestión de colas y el ordenamiento de la carga de trabajo, más que en cambios en la eficiencia de ejecución de la GPU.

Significancia y Reivindicaciones
El artículo afirma que la deriva de tokens en tiempo de ejecución es un fenómeno medible y prácticamente significativo en los sistemas de servicio de LLM multi-inquilino. La principal significancia de DriftSched radica en su demostración de que la estimación impulsada por retroalimentación adaptativa puede mejorar sustancialmente la caracterización de la carga de trabajo y la efectividad del escalonamiento bajo contención de GPU.

Los autores sostienen que sus hallazgos proporcionan conocimientos prácticos para las plataformas de servicio de IA empresariales, destacando que una estimación precisa de la carga de trabajo en tiempo de ejecución es crítica para los futuros tiempos de ejecución de inferencia adaptativos. El trabajo complementa las arquitecturas existentes (por ejemplo, Orca, Sarathi, vLLM) al introducir la estimación de carga de trabajo adaptativa como una señal de escalonamiento adicional. El estudio concluye que, si bien el escalonamiento consciente de la carga de trabajo (como SJF) reduce significativamente la latencia de cola, implica un compromiso con la equidad a nivel de inquilino, sugiriendo que los sistemas futuros deben equilibrar la eficiencia global con las garantías de nivel de servicio. El artículo señala modestamente que su evaluación se realizó en una plataforma de una sola GPU y un solo modelo, y que trabajos futuros explorarán escenarios de múltiples GPUs y escalonamiento basado en aprendizaje por refuerzo.