Masked diffusion LLMs: serving em hardware real revela gargalo de CPU

O que aconteceu

O paper "Serving Masked Diffusion LLMs: Characterization and Design Principles from Real Hardware", disponível no arXiv (arXiv:2608.23807v1), mede o comportamento de diffusion language models (dLLMs) sob carga real de servidor. A equipe usou o LLaDA-8B-Instruct, um modelo de 8 bilhões de parâmetros da família LLaDA, com um adaptador LoRA chamado D2F (Discrete Diffusion Forcing), rodando em uma única GPU NVIDIA H200. Os benchmarks foram GSM8K e HumanEval.

Três achados principais:

1. A dificuldade da requisição, medida pelo número de etapas de denoising, é discreta, não contínua. As requisições caem em 11 níveis fixos de contagem de passos (descritos como 178 + 29k), e nenhuma das variáveis testadas consegue prever esse nível antes da geração começar (melhor R2 = 0,150).

2. Benchmarks com orçamento de geração curto, abaixo de 320 tokens, subestimam a variância do serving, porque as requisições são cortadas antes que a dispersão de latência apareça.

3. Apenas 24% do tempo de parede de uma requisição individual é computação de GPU. O restante, 76%, é overhead de despacho do lado da CPU. O batching ajuda principalmente por amortizar esse overhead: compartilhar uma passagem direta por etapa de denoising melhora o throughput em 16,0x com batch de tamanho 16, comparado a uma linha de base de despacho por requisição.

Além disso, os autores argumentam que a qualidade da saída não deve degradar com o tamanho do batch, apoiando a afirmação em três suposições. Mediram 74 a 76% de acurácia no GSM8K em escala de requisição única. Por fim, derivaram uma regra de batch-timeout para batching sincronizado de preenchimento fixo sob chegadas de Poisson.

Contexto

Modelos de linguagem por difusão mascarada (masked diffusion language models, dLLMs) podem, em princípio, gerar texto mais rápido que os autorregressivos (AR), porque denoisam muitos tokens de uma vez. Sistemas recentes começaram a construir infraestrutura de serving para dLLMs, mas nenhum havia antes medido como esses modelos se comportam sob carga concorrente real. Isso é crítico porque sistemas de serving construídos sem essa base correm o risco de herdar premissas do serving AR que podem não valer para os dLLMs.

Modelos autorregressivos geram token por token, de forma sequencial. Os diffusion geram o texto inteiro em paralelo, por etapas de denoising. No AR, o custo de computação é proporcional ao comprimento da saída; no diffusion, é proporcional ao número de etapas de denoising, que é um parâmetro fixo por requisição. Essa diferença muda a dinâmica de admissão e evicção em um servidor.

Por que importa

Para quem opera modelos generativos em produção, o resultado indica que o custo predominante no serving de dLLMs não está na GPU, mas na CPU que coordena o despacho das requisições. Se as empresas continuarem a dimensionar servidores seguindo o modelo AR, vão subalocar CPU e superalocar GPU, elevando o custo por token. O ganho de 16x com batch mostra que investir em batching pode reduzir significativamente o número de GPUs necessárias, desde que o software de serving amorteça o overhead de CPU.

Além disso, a impossibilidade de prever a dificuldade da requisição antes de começar (R2 = 0,150) significa que sistemas de roteamento de requisições não podem tomar decisões antecipadas. Ter que alocar recursos sem conhecer o custo real força o sistema a ser conservador, o que pode aumentar a latência média.

Impacto

No curto prazo, quem desenvolve frameworks de serving, como vLLM, SGLang ou protótipos acadêmicos, precisa revisar a forma como fazem agendamento e batching. A regra de batch-timeout derivada no estudo, para chegadas de Poisson, dá uma base quantitativa para decidir quando esperar mais requisições e quando processar o batch atual.

No médio prazo, se a tendência se confirmar, provedores de nuvem que oferecem GPUs como a NVIDIA H200 precisarão repensar o pacote de CPU associado. Um workload de diffusion pode exigir mais vCPUs por GPU do que um workload autorregressivo equivalente.

O que muda

Para engenheiros de ML, a principal mudança prática é que o paralelismo deve acontecer em cada etapa de denoising, não entre requisições. Isso altera a interação entre admissão e evicção, porque o forward pass já é compartilhado entre requisições do mesmo batch. Sistemas AR tradicionais tratam admissão e evicção como operações independentes; no diffusion, elas precisam ser coordenadas com o ciclo de denoising.

O que vem agora

O paper foi submetido em 24 de agosto de 2026 e entrou no arXiv em 26 de agosto. Os autores não anunciaram versão revisada nem código público. O próximo passo natural é validar as conclusões em mais de uma GPU e com outros modelos diffusion, além de testar a regra de batch-timeout em implantações reais. Também falta medir como a qualidade da saída (os 74 a 76% de acurácia) se comporta com batch, já que a argumentação estrutural ainda não foi comprovada empiricamente em escala.