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

Resumo Técnico: DriftSched

Definição do Problema
A rápida adoção de Modelos de Linguagem de Grande Escala (LLMs) intensificou a demanda por um escalonamento de GPU multi-inquilino (multi-tenant) eficiente em datacenters de IA. Embora os runtimes de inferência modernos, como o vLLM, tenham otimizado o rendimento (throughput) por meio de batching contínuo e gerenciamento de memória, estimar com precisão o custo de execução de requisições de inferência heterogêneas continua sendo um desafio significativo. As abordagens de escalonamento existentes baseiam-se tipicamente em limites estáticos de tokens, restrições de saída especificadas pelo usuário ou suposições de carga de trabalho predefinidas. Esses métodos estáticos falham em capturar o comportamento dinâmico de cargas de trabalho reais de LLM, onde os comprimentos de saída observados frequentemente divergem dos valores esperados devido à complexidade do prompt, características da resposta e comportamento do modelo.

O artigo identifica essa discrepância como drift de tokens em tempo de execução (runtime token drift). Esse fenômeno introduz erros de estimativa que se propagam para as decisões de escalonamento, levando à classificação incorreta de carga de trabalho, desequilíbrio de filas, inflação da latência de cauda, alocação injusta de recursos entre inquilinos e degradação da Qualidade de Serviço (QoS) sob contenção de GPU. Algoritmos de escalonamento tradicionais (ex: FIFO, SJF), projetados para sistemas com custos de execução previsíveis, enfrentam dificuldades em ambientes de LLM multi-inquilino onde o comportamento em tempo de execução depende de fatores dinâmicos, como o crescimento do KV-cache e a dinâmica de batching.

Metodologia e Arquitetura do Sistema
Para enfrentar esses desafios, os autores propõem o DriftSched, um framework de escalonamento adaptativo consciente de QoS, projetado para inferência de LLM multi-inquilino em GPUs NVIDIA L4. A arquitetura do sistema integra classificação de carga de trabalho, estimativa de orçamento de tokens, gerenciamento de fila consciente de inquilino e um mecanismo de compensação de drift baseado em feedback em tempo de execução.

1. Estimativa Adaptativa de Tokens: Diferente das abordagens estáticas, o DriftSched estima o custo de inferência antes da execução na GPU combinando classificação de carga de trabalho, fatores de segurança conscientes de inquilino e complexidade do prompt. Crucialmente, ele emprega um fator de viés adaptativo ($B_{runtime}$) que é continuamente atualizado usando feedback de execução. A contagem estimada de tokens de saída é calculada como:
   $$T_{estimated\_output} = T_{base} \times B_{runtime} \times S_{tenant} \times F_{input}$$
   onde $B_{runtime}$ é aprendido através da razão entre os comprimentos de saída observados e as estimativas de linha de base.

2. Classificação de Carga de Trabalho e Enfileiramento: Requisições de inferência são classificadas em categorias semânticas (short_qa, summary, technical, report) e mapeadas para classes de escalonamento de tempo de execução (curta, média, longa) com base no orçamento estimado de tokens. As requisições são atribuídas a filas específicas de cada inquilino (Premium, Standard, Batch) gerenciadas via Redis.

3. Estratégias de Escalonamento: O framework avalia cinco políticas de escalonamento: First-Come First-Serve (FIFO), Escalonamento de Prioridade (Priority Scheduling), Escalonamento Ponderado (Weighted Scheduling), Shortest-Job-First (SJF) e Escalonamento de Prioridade com Envelhecimento (Aging Priority Scheduling).

4. Loop de Feedback: O sistema opera em duas fases: uma fase de calibração (primeiros 1.000 requests) para coletar feedback de execução e convergir os fatores de viés, e uma fase de avaliação de estresse (2.000 requests restantes) onde o escalonador utiliza os valores de viés aprendidos enquanto continua a adaptação online. A regra de atualização adaptativa usa uma Média Móvel Exponencial (EMA) para refinar os fatores de viés com base no desvio entre os tokens estimados e os observados.

Principais Contribuições

• Arquitetura Adaptativa Consciente de Drift: Um novo framework de escalonamento que trata a estimativa de carga de trabalho como um problema de compensação de drift de tokens em tempo de execução, atualizando dinamicamente os fatores de viés para alinhar as previsões com o comportamento observado.
• Mecanismo de Compensação de Drift de Tokens em Tempo de Execução: Um método baseado em feedback que reduz o erro de estimativa ao comparar continuamente os orçamentos de tokens estimados com os comprimentos reais de saída, melhorando a precisão do escalonamento no momento da admissão.
• Framework de Benchmarking Reproduzível: Uma configuração de avaliação abrangente usando vLLM em GPUs NVIDIA L4, simulando tráfego multi-inquilino heterogêneo com variadas complexidades de prompt e taxas de chegada para avaliar justiça (fairness), latência e rendimento.

Resultados Experimentais
Experimentos foram conduzidos utilizando 3.000 requisições de inferência através de três níveis de inquilinos e quatro tipos de carga de trabalho semântica em uma GPU NVIDIA L4.

• Existência de Drift de Tokens: O estudo confirmou um drift de tokens em tempo de execução mensurável através das categorias de carga de trabalho. A estimativa estática de orçamento de tokens consistentemente superestimou o comportamento real de geração.
• Precisão de Estimativa: O mecanismo de feedback adaptativo reduziu o erro de estimativa de carga de trabalho em uma média de 38,8% (MAE) e 40,5% (RMSE) em todas as políticas de escalonamento avaliadas em comparação com as linhas de base estáticas.
• Desempenho de Latência: Entre as políticas de escalonamento, o Shortest-Job-First (SJF) alcançou o melhor desempenho geral. Em relação ao FIFO, o SJF reduziu a latência fim-a-fim mediana (P50) em aproximadamente 42% e a latência P99 em aproximadamente 16%. Essa melhoria foi atribuída à priorização de cargas de trabalho mais curtas e à redução da ocupação de filas.
• Compromissos (Trade-offs): Embora o SJF tenha otimizado a latência global, escalonadores conscientes de inquilino (Priority, Weighted, Aging) forneceram uma diferenciação de QoS mais forte para inquilinos Premium. Por exemplo, o escalonamento de Prioridade reduziu a latência do inquilino Premium para ~77 segundos, mas aumentou a latidade do inquilino Batch para ~427 segundos.
• Utilização de GPU: A análise revelou que a latência de execução da GPU e a utilização de memória permaneceram relativamente constantes em todas as políticas de escalonamento. Isso indica que as diferenças de desempenho originaram-se do gerenciamento de filas e da ordenação de carga de trabalho, e não de mudanças na eficiência de execução da GPU.

Significância e Alegações
O artigo alega que o drift de tokens em tempo de execução é um fenômeno mensurável e praticamente significativo em sistemas de serviço de LLM multi-inquilino. A principal significância do DriftSched reside na sua demonstração de que a estimativa baseada em feedback adaptativo pode melhorar substancialmente a caracterização da carga de trabalho e a eficácia do escalonamento sob contenção de GPU.

Os autores afirmam que suas descobertas fornecem insights práticos para plataformas de serviço de IA corporativas, destacando que a estimativa precisa da carga de trabalho em tempo de execução é crítica para futuros runtimes de inferência adaptativos. O trabalho complementa arquiteturas existentes (ex: Orca, Sarathi, vLLM) ao introduzir a estimativa de carga de trabalho adaptativa como um sinal de escalonamento adicional. O estudo conclui que, embora o escalonamento consciente da carga de trabalho (como o SJF) reduza significativamente a latência de cauda, ele envolve um compromisso com a justiça entre inquilinos, sugerindo que sistemas futuros devem equilibrar eficiência global com garantias de nível de serviço. O artigo nota modestamente que sua avaliação foi conduzida em uma plataforma e modelo de GPU única, e trabalhos futuros explorarão cenários multi-GPU e escalonamento baseado em aprendizado por reforço.