vLLM ganha camadas hardware-agnósticas para rodar modelos em qualquer GPU

O problema: performance na fronteira vs. portabilidade

O vLLM construiu seu sucesso como camada de abstração para servir diversos modelos em diversos hardwares - NVIDIA, AMD, Intel XPU, Google TPU, IBM Spyre, Huawei Ascend - usando abstrações bem desenhadas e torch.compile para otimização. Mas o ecossistema mudou: modelos de fronteira open-weight trazem camadas sob medida e kernels otimizados (DeepSeek V4 e Kimi K3, por exemplo, atingem contexto de um milhão de tokens por abordagens completamente diferentes), enquanto GPUs como as NVIDIA Blackwell e sistemas rack-scale como o GB300 NVL72 exigem engenharia de kernel específica. Além disso, agentes de código como Claude Code e OpenAI Codex facilitam gerar otimizações para um modelo específico em um hardware específico - desde que não precisem se preocupar com efeitos colaterais em outros modelos ou aceleradores.

A resposta da comunidade foi criar definições de modelo específicas por hardware, os "flat models", que abrem mão do torch.compile em favor de fusões customizadas e otimizações específicas. O custo: as camadas e ops usadas por essas definições serão refatoradas de forma fundamentalmente incompatível com torch.compile e sem suporte a extensão via CustomOp.

Por que isso importa

Hoje o vLLM tem três formas de definição de modelo: os novos flat models, os modelos legados (que estão sendo removidos e redirecionados ao backend transformers) e o backend transformers. Em todos os casos, as camadas comuns (atenção, mixture-of-experts, projeções lineares, norms, ativações) vivem em um único lugar, com dois recursos importantes: suporte a torch.compile - essencial para plugins out-of-tree (OOT) como o IBM Spyre, que depende do TorchDynamo e TorchInductor, e necessário para o backend transformers atingir velocidade nativa em modelos como Qwen3 - e extensibilidade via CustomOp e PluggableLayer, que permite a plugins OOT injetar comportamento próprio.

Quebrar essa compatibilidade cria três problemas: plugins OOT teriam de manter suas próprias definições de modelo e camadas, gerando pull requests em transformers, vLLM e cada plugin - um custo distribuído por várias organizações; os modelos mais antigos ou exóticos, cada vez mais servidos via backend transformers, teriam regressão significativa de performance em GPU sem camadas compiláveis; e GPUs mais antigas ou de consumo deixariam de ser atendidas pelos flat models, embora as estatísticas de uso do vLLM mostrem que parte relevante da base de usuários ainda usa esse hardware.

A solução: camadas hardware-agnósticas

A proposta é um conjunto de camadas hardware-agnósticas dentro do próprio vLLM, guiado por quatro princípios: compiláveis (full-graph torch.compile), extensíveis (mantendo CustomOp e PluggableLayer), isoladas (camadas e ops separados dos caminhos específicos por hardware, para que os dois lados evoluam sem atrapalhar um ao outro) e portáveis (implementadas em PyTorch nativo ou DSLs portáveis como Triton e Helion).

Na prática: o backend transformers teve seu processo de "rewiring" modificado para apontar para as novas camadas em model_executor/hw_agnostic - já disponível no branch principal para um conjunto limitado de camadas, ativável com USE_HW_AGNOSTIC=1. O caminho foi validado com o plugin OOT Spyre em modelos como Gemma 4, Qwen3 e Granite 4.2, e a integração ao CI é o próximo passo. Também está planejado um model.py hardware-agnóstico para cada flat model, com camadas compartilhadas em hw_agnostic e camadas específicas (como a DeepSeekV4FlashMLAAttention) locais - um PR para o DeepSeek V4 está em revisão.

Desempenho e limites

O objetivo declarado não é desempenho de ponta em Blackwell ou CDNA 4, e sim portabilidade de plataforma e de performance em hardwares diversos. Em testes em NVIDIA H100 comparando USE_HW_AGNOSTIC=0 e 1, os modelos hardware-agnósticos, construídos só com implementações portáveis, ficaram próximos - às vezes levemente melhores - das versões nativas que usam bibliotecas otimizadas para CUDA como FlashAttention e CUTLASS: throughput total de tokens dentro de 3,4% da implementação nativa em média geométrica em três modelos recentes.

Os autores enfatizam que o esforço está em andamento, com PRs já aterrissados, e convidam feedback via RFC e o canal #hw-agnostic-models no Slack do vLLM.