How Portable Are LLM-Serving Scheduler Rankings Across Workloads, Operating Regions, and Metrics?

No cenário digital moderno, os grandes modelos de linguagem tornaram-se os motores por trás de uma vasta gama de aplicações inteligentes, desde assistentes de escrita até ferramentas complexas de codificação. Para que esses sistemas funcionem sem problemas para milhões de usuários, eles dependem de fazendas de servidores sofisticadas onde processadores gráficos potentes atuam como o cérebro. No entanto, esses processadores são recursos caros e limitados. Quando milhares de pessoas enviam solicitações ao mesmo tempo, o servidor deve decidir qual solicitação processar primeiro, como agrupá-las e como gerenciar a memória para que nenhum usuário individual sobrecarregue o sistema enquanto outros esperam. Esse processo de tomada de decisão é tratado por um "escalonador" (scheduler), um software que atua como um controlador de tráfego, rearranjando constantemente o fluxo de dados para manter tudo movendo-se com eficiência.

Durante anos, pesquisadores propuseram novas maneiras de melhorar esses escalonadores, alegando que seus métodos são mais rápidos ou mais justos do que os existentes. Mas essas alegações quase sempre foram testadas sob condições muito específicas: usando um único tipo de tráfego de usuário, em um nível específico de carga do servidor e medindo o sucesso com apenas uma métrica. Isso cria um ponto cego. Um escalonador que parece perfeito quando testado em um fluxo de solicitações calmo e previsível pode falhar miseravelmente ao enfrentar uma explosão súbita e caótica de atividade. A questão fundamental permaneceu sem resposta: se um escalonador é declarado o melhor em um conjunto de dados, essa classificação se mantém quando o tráfego muda, a carga se desloca ou a definição de sucesso muda?

Para responder a isso, um pesquisador do Instituto de Tecnologia de Nova Jersey projetou um teste rigoroso chamado LLM-Serving Scheduler Portability Benchmark (Teste de Portabilidade de Escalonadores de Atendimento de LLM). Em vez de perguntar qual escalonador único é o absolutamente melhor, o estudo perguntou uma questão mais sutil: quão portáteis são as classificações desses escalonadores? Em outras palavras, se você mudar a fonte do tráfego do usuário, a intensidade da carga ou a maneira como mede o desempenho, a ordem dos melhores e piores escalonadores permanece a mesma ou ela inverte? O pesquisador construiu uma simulação para executar treze diferentes estratégias de escalonamento contra uma coleção massiva e congelada de 120 janelas de carga distintas. Essas janelas foram extraídas de três fontes independentes de dados do mundo real: o tráfego de nuvem da Microsoft Azure, a plataforma Bailian/Qwen da Alibaba e um grande conjunto de dados de rastros da Microsoft Azure conhecido como BurstGPT. O sistema foi testado em seis diferentes regiões operacionais, variando de tráfego leve a sobrecarga severa, e avaliado usando múltiplas métricas de desempenho.

Os resultados revelaram que a resposta não é um simples sim ou não. As classificações não são universalmente estáveis, nem completamente caóticas; elas dependem fortemente de qual combinação específica de fatores você está observando. Ao comparar as classificações entre as diferentes fontes de dados, o estudo descobriu que o tráfego da Microsoft Azure e da Bailian/Qwen da Alibaba concordavam quase perfeitamente entre si. Se um escalonador era o melhor na Azure, era quase certamente o melhor na Bailian/Qwen. No entanto, a terceira fonte, o BurstGPT, contou uma história diferente. Quando o BurstGPT foi incluído na comparação, a concordância caiu significativamente, com coeficientes de correlação caindo para tão baixo quanto 0,55. Isso sugere que um escalonador validado apenas em tráfego semelhante ao da Azure pode não performar como o esperado em tráfego semelhante ao do BurstGPT, e vice-versa.

O estudo também observou com que frequência as classificações realmente se inverteram, ou seja, um escalonador que era melhor em um cenário tornou-se pior em outro. De quase mil comparações, apenas cerca de 3,6 por cento mostraram uma inversão que era estatisticamente significativa e grande o suficiente para importar na prática. Essas reversões não estavam espalhadas uniformemente por todas as condições; elas estavam concentradas em áreas específicas, particularmente quando o sistema estava sob carga pesada. Além disso, cada uma dessas reversões significativas envolveu o mesmo par de estratégias de escalonamento e sempre incluiu os dados do BurstGPT de um lado. Isso indica que a instabilidade não é uma falha geral do sistema, mas uma interação específica entre certos mecanismos de escalonamento e as características únicas daquela fonte de tráfego particular.

A descoberta talvez mais surpreendente diz respeito às métricas usadas para julgar o desempenho. Os pesquisadores testaram se um escalonador que ranqueavaia mais alto em uma métrica, como o número de solicitações concluídas, também ranquearia mais alto em outras métricas, como velocidade ou justiça (fairness). Eles descobriram que as classificações eram surpreendentemente frágeis quando a métrica mudava. Em média, a concordância entre diferentes métricas era apenas moderada, e em 68,1% das condições de teste, o escalonador de melhor desempenho mudava dependendo de qual métrica era usada. Isso significa que uma afirmação de "melhor escalonador" é frequentemente silenciosa sobre o objetivo específico que está sendo perseguido; um escalonador otimizado para velocidade pode ser a pior escolha para a justiça, e a classificação depende inteiramente do que o operador valoriza mais.

Para garantir que esses resultados de simulação não fossem apenas artefatos de um modelo de computador, o pesquisador selecionou a reversão mais dramática encontrada na simulação e a testou em hardware físico real usando um processador gráfico padrão. A simulação havia previsto que um escalonador venceria em um tipo de tráfego e perderia em outro, uma inversão na classificação. No hardware real, essa inversão específica não aconteceu; um escalonador venceu em ambos os casos. No entanto, um teste separado de uma classificação estável, onde a simulação previu nenhuma mudança, manteve-se verdadeiro no hardware real. Isso sugere que, embora a simulação seja boa em identificar tendências estáveis, ela pode não prever perfeitamente cada reversão específica no mundo real, destacando um limite onde a fidelidade do modelo termina.

Em última análise, o estudo conclui que não existe um único "melhor" escalonador universal que funcione para todas as situações. O desempenho de uma estratégia de escalonamento é condicional. Ele depende da fonte específica do tráfego do usuário, da carga atual do sistema, da métrica usada para medir o sucesso e da definição específica de um objetivo de serviço. Uma classificação que parece sólida em um conjunto de dados não pode ser assumida como verdadeira em outro sem verificação. Para engenheiros e pesquisadores, isso significa que comparar escalonadores requer uma abordagem muito mais ampla e cuidadosa do que simplesmente testar em um único conjunto de dados. As descobertas não declaram um vencedor, mas fornecem um mapa de onde as classificações são confiáveis e onde elas provavelmente mudarão, garantindo que as futuras avaliações sejam lidas com o necessário contexto e cautela.