PyTorch 2.11

O PyTorch 2.11 tornou possível instalar rodaletes do PyTorch com suporte a CUDA em sistemas Linux aarch64 diretamente do PyPI, eliminando a necessidade de índices de pacotes personalizados e soluções alternativas que anteriormente complicavam a implantação em sistemas como o NVIDIA GH200, GB200 e GB300. Neste artigo, Kaichao You (Inferact) explica como essa mudança de embalagem melhora a experiência de instalação para os usuários do vLLM e destaca como a colaboração entre o vLLM e o PyTorch por meio da Fundação PyTorch ajudou a trazer a solução para a produção.

Essa solução, que levou dois anos para ser implementada, torna a vida muito mais fácil para os usuários do GB200, GB300 e GH200. A história começa em outubro de 2024, quando eu estava no hackathon CUDA MODE (agora GPU MODE) IRL, tentando executar o vLLM em uma caixa GH200. Deveria ter sido um trabalho de cinco minutos. No entanto, eu passei um período frustrante do dia olhando para uma instalação do pip que, à primeira vista, parecia perfeitamente normal – as rodas eram resolvidas, as dependências eram atendidas, a instalação foi concluída sem erros – mas em tempo de execução, o torch.cuda.is_available() teimosamente retornou False. A razão, uma vez que eu investiguei, foi quase cômica: no Linux aarch64, o pip install torch estava puxando a roda apenas para CPU do PyPI. Simplesmente não havia uma roda GPU para aarch64 publicada no índice padrão do PyPI. Para obter uma compilação habilitada para CUDA, você tinha que apontar explicitamente o pip para o índice de downloads do PyTorch.

Isso, por si só, seria apenas ligeiramente irritante. O dano real veio de como isso interagia com dependências transitivas. O PyPI não permite que um pacote especifique um índice personalizado para suas dependências. Então, se qualquer pacote na árvore de dependências do vLLM declarasse uma requisição de torch==, e essa versão não correspondesse, o pip felizmente voltaria ao índice padrão do PyPI, encontraria a roda apenas para CPU, desinstalou silenciosamente a compilação GPU que eu havia instalado com cuidado e a substituiu pela CPU. Você pensaria que tudo estava bem até que o seu modelo se recusasse a encontrar uma GPU. Para qualquer pessoa que tentasse iniciar o vLLM no GH200 – e mais tarde no GB200 / GB300 – isso transformou uma instalação de uma linha em um labirinto de –index-url flags, versões fixadas e verificações de sanidade pós-instalação.

Enquanto esperávamos por uma solução adequada upstream, o vLLM teve que enviar suas próprias soluções alternativas para que os usuários do aarch64 não ficassem presos. A primeira foi use_existing_torch.py, adicionada no vllm-project/vllm#8713 em setembro de 2024 – explicitamente enquadrada no título do PR como “habilitar o PyTorch existente (para GH200, aarch64, nocturno)”. O fluxo é exatamente o que o nome sugere: você instala a compilação certa do torch por conta própria (do índice do PyTorch, ou nocturno, ou uma compilação personalizada), então execute python use_existing_torch.py, que remove todos os requisitos de torch/torchvision/torchaudio de requirements/*.txt, requirements/*.in e pyproject.toml do vLLM. Com esses pinos removidos, a instalação subsequente do vLLM não pode mais acionar o pip para “ajudar” a alcançar o índice padrão do PyPI e silenciosamente trocar a roda habilitada para CUDA do torch pela roda apenas para CPU. É feio – estamos literalmente reescrevendo nossos próprios arquivos de dependência em tempo de instalação – mas manteve os usuários do GH200 desbloqueados por mais de um ano.

Posteriormente, à medida que o uv amadureceu, obtivemos uma opção mais limpa. No vllm-project/vllm#24303, adicionamos o seguinte ao pyproject.toml: isso diz ao uv para não construir o torch em um ambiente isolado – o que na prática significa que o uv reutilizará o torch já presente no ambiente atual em vez de tentar resolver e reinstalar sua própria cópia. Combinado com a instalação do torch primeiro do índice certo, isso nos deu um caminho muito mais ergonômico do que o truque de reescrita de arquivo: uma linha de configuração única no pyproject.toml, e o uv pip install vllm (ou um uv sync) respeitará a roda habilitada para CUDA pré-instalada no aarch64.

A solução alternativa do vLLM é a comunidade improvisando em torno de uma lacuna no padrão de embalagem. A Variante de Roda é a NVIDIA e a Astral formalizando a solução para que a improvisação não seja mais necessária. Avançando para 2025, o vLLM se juntou à Fundação PyTorch, e eu me tornei um de seus representantes no Comitê Técnico Consultivo (TAC). A situação da roda aarch64 continuou surgindo – tanto no meu próprio trabalho quanto de outros usuários do vLLM em sistemas Grace Hopper e Grace Blackwell. Em agosto de 2025, eu arquivei o pytorch/pytorch#160162 para rastrear o problema formalmente, e no início deste ano, em uma reunião do TAC em janeiro de 2026, eu levantei diretamente em nome dos usuários do vLLM.

O pedido foi direto: publicar rodas GPU aarch64 no índice padrão do PyPI para que o pip install torch “funcione” em máquinas da classe GB200, da mesma forma que funciona em x86. Essas rodas dinamicamente vincular