Showing Posts From

Llm serving

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/logprobsRodei 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ão Throughput (tok/s) TPOT médio (ms) P99 TTFT (ms)vLLM 0.11.0 8.940 42 380vLLM 0.15.0 11.210 38 340vLLM 1.0.0 12.470 35 310O 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 = 95msO 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.0As 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ãoO 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: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. 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. 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.