`pip install torch` em uma linha só — o antigo desafio do empacotamento em Python finalmente vai ser resolvido?
(talkpython.fm)A aliança entre NVIDIA, Astral e Quansight apresenta o Wheel Next: um padrão de empacotamento de próxima geração que funciona tanto para CPU quanto para GPU
Fonte: Talk Python To Me, Episode #544 |
Contexto: a roda que parou em 2009
Quando você executa pip install numpy, qual binário é instalado? Não importa se sua CPU é um AMD Zen 4 recente ou um Apple M4. O wheel instalado foi compilado para usar apenas instruções x86-64 no nível de 2009.
Mesmo que você queira usar instruções SIMD modernas como SSE4 e AVX2, o instalador não tem como saber se esse suporte existe. No caso de pacotes como o PyTorch, o resultado são arquivos binários gigantescos, perto de 900 MB, e páginas de instruções de instalação complexas como um “livro de quebra-cabeças”.
Para resolver esse problema, a aliança entre NVIDIA, Astral e Quansight está promovendo a iniciativa Wheel Next. No centro dela está uma série de PEPs que permite aos pacotes declararem o hardware necessário, para que instaladores como o uv escolham automaticamente a build correta.
Apresentação dos convidados
Este episódio contou com três personagens centrais.
Jonathan Dekhtiar (NVIDIA) — engenheiro que se encantou com a tecnologia CUDA, fez doutorado na área e depois entrou na NVIDIA. Nos últimos dois anos, vem trabalhando para melhorar a interseção entre CUDA e Python e é um dos principais articuladores da iniciativa Wheel Next.
Ralf Gommers (Quansight) — desenvolvedor com doutorado em física e usuário de Python desde 2004. É release manager de NumPy e SciPy e atualmente co-CEO da organização de interesse público Quansight. Também é autor do guia PyPackaging Native, que organiza de forma sistemática os problemas do empacotamento nativo em Python.
Charlie Marsh (Astral) — fundador e CEO da Astral, criadora do uv, ruff e ty. Desde a fundação da empresa, em outubro de 2022, vem se concentrando em melhorar a velocidade e a experiência de uso do ecossistema Python.
O problema central: a “armadilha do mínimo denominador comum”
Ao compilar um wheel para x86-64, você só pode usar recursos de CPU anteriores a 2009. Instruções como SSE4 e AVX2, surgidas depois disso, simplesmente não podem ser usadas porque o instalador não consegue detectar se o hardware oferece suporte a elas.
Dependendo do caso, a diferença de desempenho entre os recursos de hardware de 2009 e os de 2019~2023 chega a 10 a 20 vezes.
A situação no ARM é semelhante. Hoje, o alvo básico de build para ARM é, na prática, algo no nível de um Raspberry Pi. Isso significa que até um MacBook Pro com chip M4 Max acaba executando binários compilados como se fossem para um Raspberry Pi.
Segundo a pesquisa com desenvolvedores Python da JetBrains, cerca de 40% a 50% dos desenvolvedores Python trabalham com ciência de dados ou computação científica. Ou seja, essa comunidade enorme está desperdiçando sistematicamente uma quantidade imensa de desempenho.
Como o NumPy tem aguentado
O NumPy resolveu esse problema por conta própria. A abordagem consiste em compilar várias vezes o mesmo código-fonte, mirando diferentes arquiteturas de CPU como Haswell e Skylake, e depois reunir tudo em um único módulo de extensão Python. Em tempo de execução, ele detecta a CPU e despacha para o caminho de código ideal.
Durante anos, a Intel destacou engenheiros para otimizar os caminhos de código x86, e o ARM também mantém um mantenedor dedicado do NumPy. Graças a isso, o desempenho é excelente — mas essa abordagem tem uma escala que só alguns poucos projetos grandes conseguem sustentar.
SciPy, scikit-learn, Pandas e Pillow já têm otimizações SIMD implementadas no código, mas não têm como empacotá-las e distribuí-las em wheels, então na prática não conseguem entregá-las aos usuários.
O caso do PyTorch: um “livro de quebra-cabeças” de 900 MB
O wheel do PyTorch publicado no PyPI tem cerca de 900 MB. Isso acontece porque bibliotecas CUDA para 5 ou 6 arquiteturas de GPU diferentes são empacotadas no mesmo binário. A equipe do PyTorch faz um esforço enorme para manter esse arquivo abaixo de 1 GB.
Quem precisa de uma versão específica do CUDA tem de configurar manualmente uma URL de índice separada, e páginas de instalação de pacotes como o vLLM acabam ficando complexas como um “livro de quebra-cabeças”.
Como isso ficaria quando o Wheel Next estiver pronto?
uv pip install torch
Bastaria essa linha. O instalador detectaria automaticamente a GPU, identificaria a versão correta do CUDA e faria o download de um wheel enxuto, com cerca de 200 a 250 MB, otimizado para aquele hardware. A Astral já construiu um protótipo funcional em uma branch do uv com suporte a variantes (variant-enabled).
A filosofia de design do Wheel Next: um sistema extensível, não uma lista fixa
Hoje, a abordagem atual embute platform tags no nome do arquivo. Sempre que surge uma nova necessidade, é preciso acrescentar mais uma tag — e repetir esse processo indefinidamente acaba virando um fardo sem fim de manutenção.
O Wheel Next é diferente. Os pacotes poderão declarar metadados arbitrários de variante (variant), e o instalador, por meio de uma interface de plugin, detectará dinamicamente as propriedades da plataforma para escolher o wheel ideal. Em vez de criar uma tag para cada versão de CUDA, a proposta é um sistema genérico e extensível.
O design foi inspirado em archspec, do gerenciador de pacotes para supercomputadores Spack, além de Conda-forge e Nix.
Situação dos PEPs
Os principais PEPs relacionados a essa iniciativa são:
| PEP | Título | Status |
|---|---|---|
| PEP 817 | Wheel Variants Beyond Platform Tags | Draft |
| PEP 825 | Wheel Variants Package Format | Draft |
O PEP 817 bateu o recorde de PEP mais longo da história. Só a revisão dos editores de PEP levou mais de um mês. Depois disso, ele foi dividido em partes mais administráveis, e as discussões sobre instaladores, build backends e servidores de índice passaram a acontecer separadamente.
Python Build Standalone: a alavanca silenciosa
Charlie Marsh mencionou um fato interessante. A Astral mantém o projeto Python Build Standalone. Quando você instala Python com uv, é justamente uma build desse projeto que é baixada na prática.
O objetivo da Astral é lançar a distribuição de Python mais rápida possível apenas com otimizações de build, sem alterar o código-fonte do CPython. Charlie disse acreditar que hoje eles têm o Python mais rápido, mas preferiu não fazer essa afirmação oficialmente porque ainda não divulgou uma metodologia de benchmark rigorosa.
Como muitos desenvolvedores já usam o uv para fazer bootstrap do Python, a escolha de build da Astral pode se tornar uma alavanca com impacto enorme no desempenho do Python.
Uma colaboração inédita entre setores
Em março de 2025, foi realizado um summit presencial reunindo representantes de cerca de 20 empresas. A equipe do PyTorch na Meta e a equipe do JAX no Google apresentaram, cada uma, suas dificuldades e necessidades.
Atualmente, as empresas e projetos open source que contribuem para a iniciativa Wheel Next incluem:
Empresas: NVIDIA, Astral, Quansight, Meta, AMD, Intel, Google, Red Hat, Anaconda, Huawei, Preferred Networks e mais de 14 no total
Projetos open source: NumPy, SciPy, PyTorch, scikit-learn, JAX etc.
Durante a prototipagem, quase todos os componentes do ecossistema de empacotamento Python foram trabalhados em forks, incluindo pip, warehouse (PyPI), setuptools, scikit-build-core e a biblioteca packaging. Claro, o objetivo final é reunir tudo isso novamente.
Próximos passos
Na estimativa do Ralf, a revisão dos PEPs e as atualizações dos protótipos devem continuar ao longo de 2026, e depois virão as atualizações em PyPI, Twine e nas ferramentas que consomem metadados. Parece provável que a prontidão de todo o ecossistema só venha depois de 2026.
Mas Jonathan está otimista. Assim que o padrão estiver disponível, a adoção no ecossistema de ML e computação científica tende a ser rápida, porque os pacotes centrais já estão participando do grupo de trabalho do Wheel Next.
Glossário dos principais termos
| Termo | Explicação |
|---|---|
| Wheel | Formato padrão de distribuição binária de pacotes Python (.whl) |
| Wheel Variants | Extensão proposta pelos PEPs 817/825. Diferencia várias builds do mesmo pacote conforme as características do hardware |
| SIMD | Instruções de CPU que processam vários dados ao mesmo tempo com um único comando (SSE4, AVX2, ARM Neon etc.) |
| Fat Binary | Binário que reúne código compilado para vários alvos de hardware. Atualmente usado por NumPy e PyTorch |
| Platform Tags | Informações de SO, arquitetura e versão de Python codificadas no nome do arquivo do wheel |
| Python Build Standalone | Projeto de builds redistribuíveis do CPython mantido pela Astral |
| Variant Provider Plugin | Interface pela qual o instalador detecta dinamicamente atributos de hardware (como versão do driver de GPU) para escolher a variante correta do wheel |
Conclusão
“Idealmente, o usuário comum não precisa se preocupar com nada disso. Tudo deve vir automaticamente via uv ou pip.” — Charlie Marsh
O sistema de empacotamento do Python foi concebido em uma época mais simples. Mas agora, com a explosão das cargas de trabalho de ciência de dados e IA, esse design se tornou um gargalo de desempenho, largura de banda e experiência de uso.
O Wheel Next é um caso raro em que concorrentes como NVIDIA, AMD, Intel, Google e Meta se sentam à mesma mesa para escrever PEPs juntos e investir em infraestrutura compartilhada. O protótipo do uv já provou a viabilidade técnica. Vai levar tempo para todo o ecossistema acompanhar, mas esse é um futuro que certamente vale a espera.
Links relacionados
- wheelnext.dev — site oficial do projeto Wheel Next
- PEP 817 — Wheel Variants Beyond Platform Tags
- PEP 825 — Wheel Variants Package Format
- pypackaging-native.github.io — guia sobre os problemas do empacotamento nativo em Python
- astral.sh/pyx — registro de pacotes pyx da Astral
Este artigo é uma tradução e adaptação do conteúdo do Talk Python To Me Episode #544.
2 comentários
Felizmente, a Wheel Next conta com a participação da empresa coreana Rableup.
https://wheelnext.dev/who_are_we/
Todas as outras empresas de IA não estão patrocinando, apoiando nem participando.
A Level Up é incrível!!