🤖 machine learning

Cascade: Exploiting SLO-Aware latency budget for fair and high goodput LLM inference serving

O Cascade é um sistema de serviço de LLM que aproveita um orçamento de latência dinâmico por requisição para otimizar conjuntamente o escalonamento e o gerenciamento de cache KV, melhorando significamente o goodput de conformidade com o SLO e a equidade, ao mesmo tempo em que reduz as violações em comparação com abordagens tradicionais de primeiro a chegar, primeiro a ser servido.

Autores originais: Muhammad Adnan, Rohan Mahapatra, Prashant J. Nair, Daniel Berger, Pantea Zardoshti, Rodrigo Fonseca, Esha Choukse

Publicado 2026-08-10

📖 4 min de leitura☕ Leitura rápida

CC BY 4.0

Autores originais: Muhammad Adnan, Rohan Mahapatra, Prashant J. Nair, Daniel Berger, Pantea Zardoshti, Rodrigo Fonseca, Esha Choukse

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine uma estação de trem movimentada e de alta velocidade, onde milhares de passageiros tentam embarcar em diferentes trens exatamente ao mesmo tempo. Alguns passageiros trazem apenas uma mochila pequena (uma pergunta curta e rápida), enquanto outros arrastam malas enormes e pesadas cheias de anos de memórias (uma história longa e complexa ou uma tarefa de raciocínio profundo). No mundo da Inteligência Artificial, esses "trens" são os Grandes Modelos de Linguagem (LLMs) — os computadores superinteligentes que alimentam chatbots, assistentes de programação e agentes de raciocínio. Os "passageiros" são as solicitações que enviamos a eles.

Para que esses sistemas pareçam rápidos e úteis, eles precisam prometer entregar respostas dentro de um limite de tempo específico, conhecido como Objetivo de Nível de Serviço (SLO). Pense nisso como um bilhete que diz: "Você deve estar no trem e em movimento dentro de 5 segundos". O problema é que os gerentes da estação têm usado uma regra muito antiga: "Primeiro a chegar, primeiro a ser servido". Isso significa que, se um passageiro com uma mala gigante chegar primeiro, todos os outros terão que esperar atrás dele, mesmo que a pessoa logo atrás tenha apenas uma mochila pequena e pudesse ser atendida em uma fração de segundo. Isso causa um congestionamento massivo. Além disso, a estação possui uma quantidade limitada de armazenamento de alta velocidade (como uma sala de espera VIP) para a bagagem dos passageiros. Se a bagagem for armazenada em um armazém lento e distante, buscá-la leva tempo. Se o gerente da estação não souber quanto tempo resta para cada passageiro antes de seu trem partir, ele pode desperdiçar segundos preciosos buscando bagagens para alguém que já está atrasado, enquanto outra pessoa que está no prazo acaba sendo deixada para trás.

Este é o desafio abordado por um novo sistema chamado CASCADE, descrito em um artigo recente de pesquisadores da Universidade da Colúmbia Britânica, Microsoft Azure Research e NVIDIA. Os pesquisadores perceberam que cada solicitação tem um "orçamento de tempo" oculto — a diferença entre o tempo que ela precisa para terminar seu trabalho e o tempo que lhe é permitido levar. Algumas solicitações têm um orçamento enorme (muito tempo extra), enquanto outras quase não têm nenhum. O artigo argumenta que, em vez de apenas olhar para quem chegou primeiro ou quão grande é a solicitação, o sistema deve olhar para este orçamento de tempo restante para decidir quem vai a seguir e como lidar com seus dados.

A ideia central do CASCADE é tratar esse orçamento de tempo como uma moeda compartilhada para dois trabalhos diferentes: decidir a ordem das solicitações e gerenciar onde seus dados residem. Nas simulações do artigo, que utilizaram dados de tráfego do mundo real de servidores de produção e foram testadas em três gigantes de modelos de IA (Qwen-2.5-72B, Llama-3-70B e Llama-3-405B), o CASCADE mostrou resultados impressionantes. Ao calcular constantemente quanto "margem de tempo" cada solicitação tinha restante, o sistema conseguia priorizar aquelas que estavam ficando sem tempo, enquanto permitia que solicitações com bastante tempo esperassem um pouco mais ou buscassem seus dados em um armazenamento mais lento e barato.

As descobertas sugerem que essa abordagem é um divisor de águas para a eficiência. Em seus testes, o CASCADE melhorou o número de solicitações bem-sucedidas que o sistema conseguia lidar (chamado de "goodput") em até 2,4 vezes em comparação com o método padrão "primeiro a chegar, primeiro a ser servido" usado por sistemas populares como o vLLM. Mais importante ainda, ele reduziu o número de solicitações que perderam seus limites de tempo (violações de SLO) em 40%. Talvez de forma mais criativa, ele fez isso sem fazer com que as solicitações longas e complexas sofressem. Ao contrário de outros métodos que poderiam apressar as solicitações curtas e deixar as longas passarem fome, o CASCADE manteve a experiência justa para todos, garantindo que tanto os passageiros da "mochila" quanto os da "mala gigante" fossem atendidos no prazo. O sistema alcançou isso decidindo dinamicamente se deveria buscar os dados na memória rápida, no armazenamento mais lento ou simplesmente recalculá-los, baseando-se inteiramente no orçamento de tempo disponível para aquela solicitação específica para absorver o atraso.

Resumo Técnico: CASCADE

Definição do Problema

As plataformas de serviço de Large Language Models (LLMs) enfrentam atualmente um descompasso fundamental entre os Objetivos de Nível de Serviço (SLOs) e a natureza heterogênea das requisições recebidas. Embora os SLOs (especificamente o Tempo para o Primeiro Token [TTFT] e o Tempo por Token de Saída [TPOT]) sejam definidos ao nível do serviço, o custo de execução de requisições individuais varia em ordens de magnitude devido às diferenças no comprimento da entrada, no comprimento da geração e na disponibilidade de estados reutilizáveis de cache Key-Value (KV).

Os sistemas de serviço atuais, como o vLLM, tipicamente empregam escalonamento de Primeiro a Chegar, Primeiro a Ser Servido (FCFS) ou heurísticas simples baseadas em tamanho (ex: Trabalho Mais Curto Primeiro [SJF]). Essas abordagens falham em considerar o "orçamento de latência" de cada requisição individual — a diferença entre o prazo do SLO de uma requisição e seu tempo de execução previsto. Consequentemente:

Bloqueio de Cabeça de Linha (HOL Blocking): Requisições de contexto longo podem bloquear requisições curtas e urgentes, causando violações de SLO para estas últimas.
Gestão Ineficiente de KV: Os sistemas frequentemente recuperam estados de KV de camadas profundas de memória (ex: NVMe) para economizar tempo de computação. No entanto, sem considerar o orçamento de latência específico da tarefa solicitante, essas transferências podem introduzir atrasos que excedem a folga de SLO restante da requisição, transformando um acerto de cache (cache hit) em uma violação de SLO.
Injustiça (Unfairness): Políticas que priorizam tarefas curtas (SJF) sistematicamente privam de recursos (starvation) as cargas de trabalho de contexto longo (ex: agentes de codificação, tarefas de raciocínio), enquanto o FCFS falha em distinguir entre requisições que possuem orçamento amplo e aquelas que são criticamente urgentes.

Escalonadores existentes tratam o ordenamento de requisições e a gestão de cache KV como problemas independentes, falhando em reconhecer que ambos consomem o mesmo recurso: o orçamento de latência por requisição.

Metodologia: O Sistema CASCADE

O CASCADE é um sistema de serviço de LLM projetado para coordenar conjuntamente o escalonamento de requisições e a gestão de cache KV multi-camada usando um orçamento de latência unificado por requisição.

1. Definição e Estimativa do Orçamento de Latência

O CASCADE define o orçamento de latência ( $B_r$ ) para uma requisição $r$ como:
$B_r = S_{TTFT}^{c(r)} - L_r$
Onde $S_{TTFT}^{c(r)}$ é o alvo de SLO da classe e $L_r$ é o tempo de serviço restante estimado.

Estimativa: O sistema utiliza um Estimador de Latência de TTFT que modela a latência de prefill com base no comprimento da entrada, no comprimento de saída previsto, nos estados de prefixo KV disponíveis através da hierarquia de memória (HBM, DRAM, NVMe) e na carga atual do sistema.
Conservadorismo: Para garantir a confiabilidade, o estimador faz a média das latências previstas sob carga real e capacidade máxima, escalonadas por um fator de margem de segurança empírico ( $\gamma$ ) para contabilizar erros de estimativa e contenção.

2. Arquitetura de Escalonamento de Dois Níveis

O CASCADE utiliza um mecanismo de fila de dois níveis baseado no orçamento calculado:

Nível 1 (Orçamento Positivo): Requisições com $B_r > 0$ são admitidas em uma fila de prioridade. Elas são escalonadas na ordem de Menor Orçamento Remanescente Primeiro (Least-Remaining-Budget-First). Isso garante que requisições com prazos apertados (baixo orçamento restante) sejam priorizadas em relação àquelas com ampla folga, independentemente de seu tamanho de entrada.
Nível 2 (Orçamento Negativo): Requisições com $B_r \le 0$ são rebaixadas para uma fila secundária. Elas não são descartadas, mas executadas oportunisticamente durante períodos de ociosidade do cluster. Uma fração fixa de cada lote (batch) é reservada para o Nível 2 para evitar a privação de recursos (starvation), e as requisições são promovidas de volta ao Nível 1 se seu orçamento se tornar positivo conforme a carga diminui.

3. Gestão de Cache KV Consciente do Orçamento

O mesmo orçamento de latência governa as decisões de memória através da hierarquia (GPU HBM, CPU DRAM, NVMe):

Restauração Viável: Quando um estado de prefixo KV é encontrado em uma camada profunda, o CASCADE calcula o tempo de transferência necessário para restaurá-lo. A restauração só é iniciada se o tempo de transferência couber dentro do orçamento restante da requisição.
Fallback para Recomputação: Se o atraso de transferência violar o SLO, o sistema ignora a busca na camada profunda e recomputa o prefixo na GPU, evitando uma violação de SLO.
Preempção: Sob pressão de memória HBM, o CASCADE interrompe (preempt) requisições ativas com os maiores orçamentos restantes. Como estas requisições possuem folga significativa, o custo de reexecução dificilmente causará uma violação de SLO.

4. Implementação

O CASCADE é implementado como uma extensão do motor de serviço vLLM. Ele se integra ao LMCache para posicionamento e movimentação de blocos de KV multi-camada. O sistema adiciona um overhead mínimo ao passar metadados (SLO, latência estimada, tempo de chegada) através dos objetos de requisição existentes e realizar os cálculos de orçamento na CPU, sobrepondo-se à execução da GPU.

Principais Contribuições

Identificação do Orçamento de Latência como um Recurso Comum: O artigo identifica que o escalonamento de requisições e a movimentação de cache KV competem pelo mesmo recurso — o orçamento de latência por requisição. Demonstra que prazos de serviço, tamanho da requisição e estado de cache isoladamente são insuficientes para determinar quanto overhead uma requisição pode tolerar.
Mecanismo de Coordenação Conjunta: O CASCADE apresenta um sistema de serviço de LLM que mantém e atualiza um orçamento de latência por requisição e o utiliza para coordenar o ordenamento de requisições com a restauração, pré-busca (prefetching), posicionamento e recomputação de cache KV através da hierarquia de memória.
Escalonamento de Alta Produtividade e Justo: O escalonador baseado em orçamento proposto reduz o bloqueio de HOL sem privar sistematicamente as requisições de contexto longo, preservando a justiça (fairness) entre diferentes classes de requisições heterogêneas.
Validação Empírica: O sistema é avaliado em traços de produção em três modelos grandes (Qwen-2.5-72B, Llama-3-70B, Llama-3-405B) utilizando perfis de hardware NVIDIA GB200 NVL72.

Resultados

Avaliações em traços de produção contendo cargas de trabalho de ChatBot, Tool&Agent, Coder e Reasoning demonstram o seguinte:

Melhoria de Goodput: O CASCADE melhora o goodput de SLO atendido em até 2,4× comparado ao escalonador FCFS padrão do vLLM.
Redução de Violação de SLO: Reduz as violações de SLO em 40% em relação ao FCFS.
Justiça (Fairness): O CASCADE mantém um alto Índice de Justiça de Jain (próximo a 1.0) entre diferentes classes de tamanho de requisição, enquanto o Shortest Job First (SJF) causa uma privação severa de recursos para requisições de contexto longo (fazendo a justiça cair para ~0.6 em cargas pesadas).
Robustez: Sob alta carga e capacidade reduzida do cluster, o CASCADE sustenta alto goodput e baixas taxas de violação, enquanto os modelos de referência sofrem com severo bloqueio de HOL e acúmulo de filas.

Significância e Alegações

O artigo alega que a causa primária das violações de SLO nos sistemas atuais não é a falta de orçamento de computação intrínseco, mas sim o desperdício deste orçamento devido ao bloqueio de HOL e transferências de cache KV não coordenadas. Ao tornar o orçamento de latência uma quantidade de tempo de execução explícita, o CASCADE direciona os overheads inevitáveis (fila, movimentação de dados) para as requisições que podem absorvê-los, enquanto protege as requisições urgentes.

Os autores afirmam que esta abordagem permite que os provedores maximizem a utilização de aceleradores e o goodput enquanto aderem estritamente aos SLOs de latência e garantem a justiça entre diversos tipos de aplicações (desde interações curtas de chat até tarefas longas de raciocínio), tudo isso sem exigir hardware adicional ou mudanças nos pesos do modelo. O sistema preenche a lacuna entre escalonamento e gestão de memória, tratando-os como um problema de otimização unificado impulsionado pela urgência específica de cada requisição.