Resumo Técnico: OmniPilot

Declaração do Problema

Servir Grandes Modelos de Linguagem (LLMs) em clusters de GPU compartilhados e heterogêneos apresenta um complexo problema de decisão pré-submissão. Operadores devem selecionar o tipo de GPU, o grau de paralelismo de tensor (TP) e a precisão numérica antes de comprometer valiosas horas de nó. Este processo é repleto de desafios:

• Altas Taxas de Falha: A seleção cega de configuração leva a falhas imediatas devido a incompatibilidades de hardware ou exaustão por falta de memória (OOM). Nas execu-ções de benchmark dos autores, 14% dos trabalhos falharam imediatamente.
• Interações Não Intuitivas: Receitas de implantação estáticas falham em capturar dinâmicas intrincadas de hardware-software. Por exemplo, a quantização de 4 bits pode ser mais lenta que a de 16 bits em runtimes específicos, e a pressão do cache Key-Value (KV) cria trade-offs de tamanho por precisão não monotônicos.
• Limitações de Dados: Schedulers de cluster tradicionais (ex: Slurm) carecem de visibilidade sobre comportamentos específicos da carga de trabalho (família do modelo, precisão, concorrência) e dependem de telemetria obsoleta (ex: intervalos de amostragem DCGM de 60 segundos) que representa mal o desempenho de serviço ativo.
• Incerteza: Sistemas existentes otimizam a execução dentro de uma configuração pré-selecionada, mas não fornecem estimativas de incerteza calibradas para a escolha dessa configuração, deixando os operadores incapazes de distinguir entre requisições suportadas e não suportadas (Fora de Distribuição - OOD).

Metodologia

O OmniPilot é um assessor de lançamento projetado para prever custos de serviço e recomendar configurações ideais enquanto lida explicitamente com a incerteza. Sua arquitetura consiste em três componentes principais:

1. Infraestrutura de Dados

O OmniPilot utiliza dois repositórios de dados distintos para garantir linhagem e reprodutibilidade:

• Loja Pessoal (Personal Store): Uma grade de benchmark controlada (1.667 linhas) cobrindo famílias de modelos, GPUs e precisões específicas.
• Loja de Cluster (Cluster-wide Store): Telemetria agregada de 500.000 trabalhos históricos, usada para derivar priors de sucesso de lançamento e padrões de demanda.
• Engenharia de Atributos (Feature Engineering): O sistema codifica ~28 atributos, incluindo numéricos log-transformados (tamanho do modelo, concorrência), numéricos lineares (grau de TP, memória) e codificações one-hot para famílias de modelos, tipos de GPU e formatos de quantização. Crucialmente, novos eixos (ex: tipos de quantização) são representados no featurizer antes da coleta de dados para evitar vazamento de atributos (feature leakage).

2. Modelo de Custo de Inferência

O preditor central é um conjunto de regressores de gradiente boosted usando perda de quantil (quantile loss), treinados em espaço logarítmico para lidar com erros multiplicativos.

• Alvos (Targets): Ele prevê oito alvos, incluindo tokens/s agregados, throughput de requisição, Tempo para o Primeiro Token (TTFT), tempo de cold-start, uso de pico do cache KV e potência média.
• Calibração: O modelo emprega Regressão de Quantil Conformalizada (CQR) para gerar intervalos de predição. Ele utiliza um offset aditivo de conformal dividido, calibrado nos resíduos de células mantidas fora (held-out), para atingir 80% de cobertura em cargas de trabalho não vistas.
• Mecanismo de Abstenção: Para lidar com requisições Fora de Distribuição (OOD), o OmniPilot usa uma verificação de distância de suporte (support-distance). Se uma requisição cai fora do envelope de suporte medido (definido através de sete eixos), o sistema a sinaliza como baixa confiança e se abstém, independentemente da largura do intervalo.

3. Utilidade de Decisão e Posicionamento

O OmniPilot classifica as "armas" de configuração (combinações de GPU, TP e precisão) usando uma métrica de utilidade econômica calibrada às preferências do operador.

• Função de Utilidade: $Utilidade = (Throughput \times Runtime \times Valor) - (Custo de Computação + Espera na Fila + Custo de Falha Esperado + Custo de Violação de SLO + Penalidade de Saturação de KV)$.
• Prior de Sucesso de Lançamento: Um estimador beta-binomial contrai as taxas de falha por configuração em direção a uma taxa agrupada do cluster, levando em conta a observação de que configurações multi-GPU (ex: TP=4) têm um sucesso de lançamento significativamente menor (~38%) do que setups de GPU única.
• Penalidade de Saturação de KV: Uma penalidade de throughput multiplicativa é aplicada quando a ocupação do cache KV excede 0.85, convertendo preempções em custos de utilidade.

Principais Contribuições

1. Assessor Calibrado e Consciente de Abstenção: O OmniPilot é o primeiro sistema a combinar modelos de custo de quantil conformalmente calibrados com uma camada de abstenção OOD explícita para inferência de LLM. Ele prevê métricas de desempenho junto com intervalos calibrados e um sinal de segurança para bloquear requisições não suportadas.
2. Avaliação Acoplada à Decisão: O artigo introduz um framework de avaliação livre de vazamento usando GroupKFold (agrupado por célula de carga de trabalho) para comparar o assessor contra baselines sem modelo. Demonstra que otimizar para utilidade econômica (incorporando custo e risco de falha) produz uma precisão de posicionamento significativamente melhor do que políticas baseadas apenas em throughput ou regras.
3. Estudo de Telemetria de Cluster (Resultado Negativo): Os autores demonstram que, embora os metadados do scheduler (Slurm) sejam suficientes para derivar demanda e priors de sucesso de lançamento, eles são insuficientes para construir um assessor de throughput de cluster, pois registram a alocação de recursos (como uma GPU foi usada) em vez da carga de trabalho de software específica (o que rodou nela).

Resultados

Avaliado através de 460 execuções de benchmark em hardware A100, H100 e H200:

• Precisão de Predição: O OmniPilot prevê o throughput agregado com um Erro Médio Percentual Absoluto (MAPE) de 6,2% e um $R^2$ de log-espaço de 0,92.
• Precisão de Posicionamento: O assessor atinge 95% de precisão top-1 na seleção da configuração ideal, com um regret de utilidade média de 0,003. Isso é uma ordem de magnitude melhor do que baselines como regras de "limiar de tamanho" (regret 1,97) ou políticas de "maximização de throughput" (regret 4,73).
• Tratamento de OOD: Em um conjunto de teste de 5 células não suportadas (novas famílias de modelos ou contextos extremos), o erro de predição subiu para 24–46%, e os intervalos conformes falharam em cobrir os valores reais. No entanto, a camada de abstenção sinalizou com sucesso todas as cinco como baixa confiança, evitando implantações arriscadas.
• Eficiência de Dados: A precisão satura após aproximadamente 150 linhas de treinamento uma vez que os eixos da tarefa são cobertos, indicando que a cobertura do espaço de configuração é mais crítica do que o volume bruto de dados.

Significância e Alegações

O artigo afirma que o OmniPilot preenche uma lacuna macro de nível crítico em clusters de GPU compartilhados e multiusuários ao transformar a seleção de configuração de hardware em uma decisão econômica calibrada. Sua significância reside em:

• Segurança e Confiabilidade: Ao se abster explicitamente em requisições OOD, evita falhas dispendiosas que configurações estáticas ou schedulers de "melhor esforço" incorreriam.
• Otimização Econômica: Move-se além da simples maximização de throughput para otimizar uma função de utilidade complexa que equilibra custo, risco de falha e SLOs, alinhando-se com as restrições reais dos operadores.
• Rigor Metodológico: Estabelece um framework de design "feature-before-data" e demonstra que muitos problemas de desempenho são melhor resolvidos através de um design de utilidade refinado (ex: penalidades de saturação de KV) ou precisão de medição (ex: janelas de frescor) em vez de simplesmente aumentar a capacidade do modelo.

Os autores mantêm modéstia quanto ao escopo, observando que o sistema é atualmente limitado ao serviço de inferência vLLM de nó único. Cargas de trabalho de treinamento, recuperação de falhas e arquiteturas de serviço multi-nó são explicitamente adiadas para pesquisas futuras. O sistema depende de dados empíricos de um cluster específico (Kempner AI), e limiares absolutos (ex: joelho de saturação de KV) são específicos de cada implantação.