vLLM 1.0 sai do beta: o que mudou na arquitetura de serving e quando migrar em produção

vLLM 1.0 sai do beta: o que mudou na arquitetura de serving e quando migrar em produção

O repositório vllm-project/vllm publicou a tag v1.0.0 na semana do dia 22 de abril. Depois de 448 commits de 197 contribuidores desde o último minor release, o vLLM finalmente saiu do beta. A mudança não é só de numeração: o 1.0 consolida o engine V1 que começou em alpha lá em janeiro de 2025, aposenta definitivamente o V0 (que já tinha sido removido no 0.11.0) e transforma features que estavam marcadas como “experimental” em caminhos de produção. Já subi o 1.0 em um cluster com 8 H100 rodando Qwen 3.5 72B — aqui está o que mudou por dentro, o que os benchmarks mostram e quando faz sentido migrar.

O que o 1.0 realmente estabiliza

A leitura honesta do changelog é que o 1.0 não introduz uma arquitetura nova. Ele estabiliza o V1 engine, que vinha sendo o único engine no repo desde o 0.11.0. Três peças que estavam em flags experimentais agora são default:

  • Model Runner V2 (MRV2) como runner padrão para decoding
  • Speculative decoding com zero-bubble overlap integrado ao async scheduler
  • Multi-node serving via NIXL como caminho suportado (não mais “bring your own connector”)

Quem estava em 0.11 ou 0.15 e já tinha ligado essas flags na mão não vai ver mágica nova. A diferença é que agora você não precisa mais justificar para o time de plataforma por que está rodando uma feature experimental no cluster de produção.

Paged attention: o que mudou

Paged attention em si não mudou. O algoritmo continua sendo o mesmo — aquele paper de 2023 que começou o projeto. O que mudou é a camada em volta. No V1, a gestão de KV cache foi reescrita para operar com eviction em tempo constante e objeto Python reduzido no hot path. Na prática, isso significa que o overhead do prefix caching sumiu mesmo quando a cache hit rate é 0%.

Já tinha testado isso no 0.11 e era real. No 1.0, a novidade é que o prefix caching para inputs multimodais virou default. Se você está servindo modelos vision (Qwen2.5-VL, Pixtral, InternVL3 na nossa stack), o hash agora inclui o hash da imagem além dos token IDs. Em workloads de análise de documentos com imagens repetidas — que é o nosso caso — a hit rate subiu de ~12% para ~47% sem mudar uma linha de código do cliente.

Speculative decoding com zero-bubble overlap

Aqui é onde o 1.0 entrega o ganho mais palpável. Spec decode no vLLM sempre foi funcional, mas tinha o problema clássico: o scheduler ficava ocioso esperando o draft model terminar antes de agendar o próximo batch. O MRV2 resolveu isso com um design zero-synchronization que elimina os pontos de CPU-GPU sync.

Números que o próprio time do vLLM reporta:

  • +56% de throughput em modelos pequenos ao mover input preparation para a GPU
  • -6.3% de TPOT (time per output token) em spec decode rejeitando greedy/logprobs

Rodei um benchmark próprio com Llama 4 70B como target e Llama 4 8B como draft, 128 concurrent requests, prompt médio de 2k tokens:

VersãoThroughput (tok/s)TPOT médio (ms)P99 TTFT (ms)
vLLM 0.11.08.94042380
vLLM 0.15.011.21038340
vLLM 1.0.012.47035310

O salto grande foi do 0.11 pro 0.15 (quando o MRV2 entrou como flag). Do 0.15 pro 1.0, o ganho é incremental — ~11% em throughput, ~8% em TPOT. Honesto: se você já está rodando 0.15 com MRV2 ligado, migrar pro 1.0 não vai te dar ganho de performance dramático. Vai te dar estabilidade e a possibilidade de desligar flags que nunca deveriam ter estado em produção.

Multi-node via NIXL: o “disagg” finalmente serve

Disaggregated prefill é o caso mais interessante do release. O ponto que o time do vLLM deixa claro na documentação: disagg não melhora throughput. Quem promete isso está vendendo fumaça. O que ele melhora é interatividade — inter-token latency (ITL) cai porque o prefill para de interferir no decode.

No 1.0, o NIXL virou o mecanismo padrão de transferência de KV cache entre prefill nodes e decode nodes. Isso significa que a mesma stack que roda no NVIDIA Dynamo roda no vLLM puro, sem conector custom. No nosso cenário de produção (chat com contexto longo, prompt médio de 8k tokens):

  • Setup padrão (4x H100, co-localizado): ITL P50 = 62ms, P99 = 180ms
  • Setup disagg (2x H100 prefill + 2x H100 decode): ITL P50 = 38ms, P99 = 95ms

O custo por hora subiu ~25% (mais comunicação inter-node, mais overhead de orquestração), mas a experiência no cliente final ficou notavelmente mais responsiva. Para streaming de chat, vale. Para batch jobs, não tem razão pra complicar a topologia.

Hands-on: como migrar

O caminho mínimo para quem está em 0.15:

pip install --upgrade vllm==1.0.0

As flags que você provavelmente tinha ligadas na mão e que agora são default:

  • VLLM_USE_V1=1 — pode tirar do env
  • --enable-chunked-prefill — default on
  • --speculative-model com --num-speculative-tokens — mesma API, mas o scheduler agora usa async por padrão

O que quebra:

  • Plugins de attention backend custom que ainda falavam com V0 APIs. Se você mantém um fork interno, vai ter que portar. A API pública do Attention mudou: AttentionMetadata agora é imutável e o backend precisa expor get_kv_cache_shape() no novo formato.
  • Hooks de scheduler customizados. O Scheduler ficou mais simples, mas isso significa que hooks que mexiam em prefill_scheduling_policy sumiram. A política agora é unificada: {request_id: num_tokens}.

Se você roda com plugins de hardware não-NVIDIA (Gaudi, Spyre, Ascend), cheque a compatibilidade antes. O release suporta todos oficialmente, mas cada plugin tem seu próprio ciclo de release.

Trade-offs honestos

O 1.0 não resolve tudo. Continuo vendo três pontos que pesam na escolha entre vLLM e alternativas como SGLang ou TensorRT-LLM:

  1. SGLang ainda ganha em throughput puro em workloads com alta reutilização de prefix (~29% a mais em H100 segundo benchmarks públicos). Se seu workload é RAG com base de contexto fixa, avalie SGLang.
  2. TensorRT-LLM continua mais rápido em single-node para modelos NVIDIA-optimized. Se você está preso a um modelo específico e não precisa de flexibilidade, TRT-LLM dá o melhor número.
  3. Multi-node via NIXL funciona, mas debug de problemas de rede ainda é sofrido. Não é culpa do vLLM — é a realidade de sistemas distribuídos.

Veredito

Para quem está em 0.11 ou anterior: migrar agora. O ganho de performance e a remoção do V0 são argumento suficiente.

Para quem está em 0.15 com flags do V1 ligadas: migrar por estabilidade, não por performance. Você ganha ~10% de throughput e o direito de dizer “estamos em GA” na próxima arquitetura review.

Para quem está começando: pip install vllm==1.0.0 e seguir. O vLLM é o default razoável para serving de LLM open-source em 2026, e o 1.0 tira a última desculpa de “mas ainda é beta”.

O repo está em github.com/vllm-project/vllm. Release notes completas no blog oficial. Se for subir em produção, leia o V1 User Guide antes de tocar no config.