SLO-Aware Compute Resource Allocation for Prefill-Decode Disaggregated LLM Inference

Each language version is independently generated for its own context, not a direct translation.

Imagine que você está gerenciando um restaurante de luxo muito popular, onde os clientes pedem pratos complexos (os LLMs ou Modelos de Linguagem). O processo de servir um prato tem duas etapas distintas:

A Preparação (Prefill): O chef lê o pedido, pega os ingredientes e começa a cozinhar. Isso exige muita força e atenção, mas é rápido.
O Serviço (Decode): O prato é entregue ao cliente e ele começa a comer, pedindo mais um pouco de cada vez. Isso exige menos força do chef, mas é um processo contínuo e lento.

No passado, o mesmo chef fazia as duas coisas ao mesmo tempo. O problema? Quando o chef estava focado em preparar o próximo pedido (Preparação), ele demorava para atender o cliente que já estava comendo (Serviço). Isso criava um gargalo: o cliente ficava esperando a primeira garfada (o "Primeiro Token") e, depois, a comida saía devagar.

Para resolver isso, a indústria criou a Desagregação P/D (Prefill-Decode). Agora, temos dois tipos de cozinheiros:

Cozinheiros de Preparação (Prefill): Super rápidos, focados apenas em pegar o pedido e começar a cozinhar.
Cozinheiros de Serviço (Decode): Focados apenas em entregar a comida e manter o cliente satisfeito enquanto come.

O Problema: Quantos Cozinheiros Contratar?

Aqui entra o dilema que este artigo resolve. Se você contratar muitos Cozinheiros de Preparação e poucos de Serviço, os pedidos ficam prontos, mas ninguém os entrega rápido, e os clientes reclamam que a comida chega fria (o "Token por Tempo" fica alto). Se contratar muitos de Serviço e poucos de Preparação, os clientes ficam esperando horas para receber o primeiro prato (o "Tempo até o Primeiro Token" fica alto).

A pergunta difícil é: Qual é a quantidade exata de cada tipo de cozinheiro que eu preciso para atender X clientes por hora, sem que ninguém fique insatisfeito e sem gastar dinheiro com cozinheiros ociosos?

A Solução: A Receita Mágica (O Método do Artigo)

Os autores deste artigo propuseram uma "receita" inteligente que mistura matemática teórica com testes práticos para descobrir o número perfeito de cozinheiros.

1. A Teoria do Trânsito (Para a Preparação)

Para saber quantos "Cozinheiros de Preparação" são necessários, eles usam uma teoria chamada M/M/1 (que é basicamente como estudamos filas de banco ou trânsito).

A Analogia: Imagine que o Cozinheiro de Preparação é uma única janela de atendimento. Se muitos clientes chegam de uma vez, eles formam uma fila.
O Truque: Eles medem o quanto o cozinheiro consegue fazer no máximo (quando não há fila). Depois, eles calculam: "Se o cliente exige que a primeira garfada chegue em 2 segundos, quantos clientes posso atender por vez sem criar uma fila longa demais?"
Resultado: Eles descobrem que, para ser rápido, o cozinheiro precisa trabalhar um pouco menos do que sua capacidade máxima, para não deixar ninguém esperando. Isso define quantos cozinheiros de preparação você precisa.

2. O Teste de Resistência (Para o Serviço)

Para os "Cozinheiros de Serviço", a lógica é diferente. Eles podem atender vários clientes ao mesmo tempo (como um garçom que leva várias bandejas).

A Analogia: Se o garçom carrega 10 pratos de uma vez, ele é super eficiente, mas se ele carregar 20, ele pode tropeçar e demorar mais para entregar cada um (o tempo por token aumenta).
O Truque: Eles fazem testes práticos (benchmarks) para ver qual é o "número mágico" de pratos que o garçom pode carregar sem violar o tempo de entrega prometido ao cliente.
Resultado: Eles descobrem exatamente quantos pedidos o garçom pode processar por segundo mantendo a promessa de rapidez.

3. O Equilíbrio Final

Com esses dois números (quantos pedidos a preparação consegue fazer e quantos o serviço consegue entregar), eles usam uma fórmula simples para descobrir a proporção ideal.

Se os pedidos são longos (muitos ingredientes), você precisa de mais Cozinheiros de Preparação.
Se os pedidos geram respostas longas (o cliente come muito), você precisa de mais Cozinheiros de Serviço.

O Resultado na Prática

Os autores testaram essa "receita" em um cenário real, usando modelos de IA gigantes (como o DeepSeek) em computadores superpotentes (GPUs H200).

O Cenário: Eles precisavam atender 5 milhões de "bocas" por minuto, garantindo que o primeiro prato chegasse em 2 segundos e a comida continuasse chegando a cada 20 milissegundos.
A Descoberta: A fórmula deles disse: "Você precisa de 3 Cozinheiros de Preparação e 4 Cozinheiros de Serviço".
A Confirmação: Quando eles montaram exatamente essa equipe, o restaurante funcionou perfeitamente, atendendo a meta de velocidade e volume. Se tivessem usado 3 e 3, os clientes teriam reclamado da lentidão na entrega. Se tivessem usado 3 e 5, teriam gastado dinheiro com um garçom extra que não era necessário.

Resumo em uma frase

Este artigo ensina como calcular a quantidade exata de "cérebros rápidos" (para começar a tarefa) e "cérebros contínuos" (para terminar a tarefa) que você precisa para rodar uma Inteligência Artificial, garantindo que ela seja rápida para todos e não desperdice dinheiro com equipamentos parados. É como encontrar o equilíbrio perfeito entre cozinheiros e garçons para um restaurante lotado.

Each language version is independently generated for its own context, not a direct translation.

Aqui está um resumo técnico detalhado do artigo "SLO-Aware Compute Resource Allocation for Prefill-Decode Disaggregated LLM Inference", apresentado em português:

1. O Problema

A inferência de Grandes Modelos de Linguagem (LLMs) enfrenta um desafio crítico na otimização de recursos quando utiliza a estratégia de desagregação Prefill-Decode (P/D). Neste paradigma, as fases de pré-preenchimento (prefill) e decodificação (decode) são executadas em instâncias de hardware separadas para evitar interferências e otimizar métricas de Serviço (SLOs) como Time-To-First-Token (TTFT) e Time-Per-Output-Token (TPOT).

No entanto, a indústria carece de uma metodologia estabelecida para determinar a quantidade ótima de recursos de hardware (número de GPUs para P vs. D) para uma carga de trabalho específica. Alocações inadequadas resultam em:

Subutilização de recursos (custos elevados).
Falha em atender aos requisitos de SLO (má experiência do usuário).
Dificuldade em equilibrar a taxa de transferência total (throughput) com as restrições de latência.

Soluções existentes, como o AIConfigurator da NVIDIA, focam em configurações de paralelismo, mas não fornecem um método abrangente para calcular a proporção e a quantidade de instâncias P/D baseadas em requisitos de throughput e SLOs do usuário.

2. Metodologia

Os autores propõem uma abordagem híbrida que combina modelagem teórica com medições empíricas (benchmarking) para calcular a alocação de recursos. O processo divide-se em três etapas principais:

A. Modelo Teórico de Alocação

O objetivo é calcular o número de instâncias de pré-preenchimento ( $N_{prefill}$ ) e decodificação ( $N_{decode}$ ) necessárias.

Entradas: Throughput total exigido ( $TP_{total}$ ), comprimentos médio de entrada ( $L_{in}$ ) e saída ( $L_{out}$ ), e as taxas de transferência alcançáveis por instância ( $TP_{prefill}$ e $TP_{decode}$ ).
Equilíbrio: O sistema assume inferência em pipeline, onde o tempo total é determinado pelo gargalo. Para evitar ociosidade, os tempos de computação de ambas as fases devem ser iguais.
Fórmula de Proporção: A razão ideal P/D é derivada como:
$R_{P/D} = \frac{L_{in} \times TP_{decode}}{L_{out} \times TP_{prefill}}$
O desafio reside em determinar os valores reais de $TP_{prefill}$ e $TP_{decode}$ sob restrições de SLO.

B. Determinação do Throughput de Prefill (Restrição TTFT)

Para garantir que o TTFT atenda aos requisitos do usuário, os autores modelam o processo de pré-preenchimento como uma fila M/M/1:

Considera-se o tempo de espera na fila ( $T_{queuing}$ ) e o tempo de computação ( $T_{computation}$ ).
O TTFT total inclui também o tempo de overhead ( $T_{overhead}$ ), que abrange a transmissão de dados entre usuário e servidor e a transferência do KV Cache entre as instâncias P e D.
Utilizando a teoria das filas, derivam-se a taxa de serviço ( $\mu$ ) e a taxa de chegada ( $\lambda$ ) para calcular a utilização do sistema ( $\rho$ ).
Resultado: Uma fórmula que permite calcular o throughput efetivo de pré-preenchimento ( $TP_{prefill}$ ) com base no TTFT alvo e no throughput máximo medido, garantindo que a latência não seja violada.

C. Determinação do Throughput de Decode (Restrição TPOT)

Para a fase de decodificação, a relação entre o tamanho do lote (batch size) e o desempenho é não linear:

Lotes maiores aumentam o throughput, mas também aumentam o TPOT.
Os autores realizam benchmarks empíricos para traçar curvas de TPOT vs. Throughput em função do tamanho do lote de decodificação.
Identificam o tamanho de lote máximo que ainda satisfaz o requisito de TPOT, derivando assim o throughput efetivo de decodificação ( $TP_{decode}$ ).

3. Contribuições Principais

Modelo Teórico Unificado: Estabelecimento de uma fórmula para calcular o número de instâncias P/D baseada em requisitos de throughput, SLOs e comprimentos de sequência.
Modelagem de Fila para Prefill: Aplicação da teoria de filas M/M/1 para prever o throughput efetivo de pré-preenchimento sob restrições estritas de TTFT, superando a simples medição de pico.
Otimização Empírica para Decode: Uso de medições reais para determinar o tamanho de lote ótimo que maximiza o throughput sem violar o TPOT.
Validação Prática: Demonstração de que o método prevê com precisão a alocação de recursos em cenários reais, equilibrando custo e desempenho.

4. Resultados e Avaliação

Os autores validaram sua metodologia em um cenário real utilizando o modelo DeepSeek-V3.1-Terminus em GPUs NVIDIA H200, com os seguintes requisitos de SLO:

TTFT: 2 segundos.
TPOT: 20 ms.
Throughput Alvo: 5 milhões de tokens por minuto (M TPM).
Comprimentos: Média de 6144 tokens de entrada e 512 de saída.

Descobertas Chave:

Cálculo da Proporção: O método calculou uma razão P/D de 0.82:1.
Alocação Proposta: Para atender ao throughput de 5 M TPM, o método sugeriu uma configuração de 3 instâncias de Prefill e 4 de Decode (3P4D).
Desempenho: A configuração 3P4D atingiu simultaneamente os limites de TTFT (2s) e TPOT (20ms) em aproximadamente 4,8 M TPM, muito próximo do alvo.
Comparação: Uma configuração alternativa (3P3D) só conseguiu atingir os SLOs em ~3,6 M TPM, demonstrando que a alocação proposta pelo método é mais eficiente em termos de recursos (0,69 M TPM/nó vs. 0,6 M TPM/nó).
Precisão do Modelo: A comparação entre o TTFT medido e o previsto pela teoria M/M/1 mostrou consistência de tendência perfeita, com pequenas discrepâncias atribuídas ao tempo de transferência do KV Cache.

5. Significado e Impacto

Este trabalho preenche uma lacuna crítica na operação de LLMs em produção. Ao fornecer uma metodologia sistemática para dimensionar recursos em arquiteturas desagregadas, ele permite que provedores de nuvem e engenheiros de ML:

Otimizem Custos: Evitem o provisionamento excessivo de GPUs.
Garantam SLOs: Assegurem que os requisitos de latência (TTFT/TPOT) sejam cumpridos consistentemente.
Escalem Eficientemente: Tenham uma base matemática e empírica para planejar a infraestrutura necessária para cargas de trabalho variáveis.

O método proposto pode ser integrado a ferramentas de configuração existentes (como o AIConfigurator) e tem potencial para ser generalizado para sistemas multimodais com separação de três componentes (EPD).