`pip install torch` en une seule ligne — l’éternel casse-tête du packaging Python est-il enfin en train d’être résolu ?
(talkpython.fm)Wheel Next, proposé par l’alliance NVIDIA·Astral·Quansight : un standard de packaging nouvelle génération qui ne fait plus de distinction entre CPU et GPU
Source : Talk Python To Me, Episode #544 |
Contexte : une roue arrêtée en 2009
Quand on exécute pip install numpy, quel binaire est réellement installé ? Que votre CPU soit un récent AMD Zen 4 ou un Apple M4, le wheel installé est compilé de manière à n’utiliser que des instructions x86-64 au niveau de 2009.
Même si l’on veut exploiter des instructions SIMD plus modernes comme SSE4 ou AVX2, l’installateur n’a aujourd’hui aucun moyen de savoir si elles sont prises en charge. Résultat : pour des paquets comme PyTorch, on se retrouve avec d’énormes fichiers binaires approchant les 900 Mo, ainsi qu’avec des pages d’installation aussi complexes qu’un « livre d’énigmes ».
Pour résoudre ce problème, l’alliance NVIDIA, Astral et Quansight pousse l’initiative Wheel Next. Son cœur repose sur une série de PEP permettant aux paquets de déclarer le matériel dont ils ont besoin, afin que des installateurs comme uv puissent sélectionner automatiquement le bon build.
Présentation des invités
Trois figures clés participaient à cet épisode.
Jonathan Dekhtiar (NVIDIA) — Ingénieur passionné par CUDA, au point d’y consacrer un doctorat avant de rejoindre NVIDIA. Depuis un peu plus de deux ans, il travaille à améliorer l’interface entre CUDA et Python et fait partie des principaux moteurs de l’initiative Wheel Next.
Ralf Gommers (Quansight) — Docteur en physique et développeur Python depuis 2004. Il est release manager de NumPy et SciPy, et aujourd’hui co-CEO de Quansight, une organisation d’intérêt public. Il est aussi l’auteur du guide PyPackaging Native, qui structure de manière systématique les problèmes du packaging Python natif.
Charlie Marsh (Astral) — Fondateur et CEO d’Astral, à l’origine de uv, ruff et ty. Depuis la création de l’entreprise en octobre 2022, il se concentre sur l’amélioration des performances et de l’expérience utilisateur dans l’écosystème Python.
Le problème central : le piège du « plus petit dénominateur commun »
Lorsqu’on construit un wheel pour x86-64, on ne peut utiliser que les fonctionnalités CPU d’avant 2009. Les instructions apparues ensuite, comme SSE4 ou AVX2, restent inutilisables, car l’installateur ne peut pas savoir si la machine cible les prend en charge.
Selon les cas, l’écart de performances entre les capacités matérielles de 2009 et celles de 2019 à 2023 peut atteindre 10 à 20 fois.
La situation est similaire sur ARM. Aujourd’hui, la cible de build par défaut pour ARM correspond en pratique au niveau d’un Raspberry Pi. Autrement dit, même sur un MacBook Pro équipé d’une puce M4 Max, on exécute un binaire compilé comme pour un Raspberry Pi.
D’après l’enquête développeurs Python de JetBrains, environ 40 à 50 % des développeurs Python travaillent dans la data science ou le calcul scientifique. Toute cette immense communauté gaspille donc de manière systématique une quantité considérable de performances.
Comment NumPy a tenu jusqu’ici
NumPy a résolu ce problème en interne. Le projet compile plusieurs fois le même code source pour différentes architectures CPU comme Haswell ou Skylake, puis regroupe le tout dans un unique module d’extension Python. À l’exécution, il détecte le CPU et redirige vers le chemin de code optimal.
Intel a détaché des ingénieurs pendant des années pour optimiser les chemins de code x86, et ARM dispose aussi d’un mainteneur NumPy dédié. Les performances sont excellentes, mais cette approche n’est gérable qu’à l’échelle d’un petit nombre de grands projets.
SciPy, scikit-learn, Pandas et Pillow disposent bien d’optimisations SIMD dans leur code, mais faute de mécanisme de distribution adéquat dans les wheels, ils ne peuvent pas réellement les livrer aux utilisateurs.
Le cas de PyTorch : un « livre d’énigmes » de 900 Mo
Le wheel PyTorch publié sur PyPI pèse environ 900 Mo. La raison : les bibliothèques CUDA pour 5 à 6 architectures GPU différentes sont regroupées dans un seul et même binaire. L’équipe PyTorch déploie d’énormes efforts pour rester sous la barre du gigaoctet.
Les utilisateurs ayant besoin d’une version CUDA spécifique doivent configurer eux-mêmes une URL d’index distincte, et les pages d’installation de paquets comme vLLM ressemblent à un véritable « livre d’énigmes ».
Que se passera-t-il quand Wheel Next sera prêt ?
uv pip install torch
Cette seule ligne suffira. L’installateur détectera automatiquement le GPU, déterminera la bonne version de CUDA et téléchargera un wheel allégé d’environ 200 à 250 Mo, optimisé pour le matériel concerné. Astral a déjà construit un prototype fonctionnel dans une branche variant-enabled de uv.
La philosophie de conception de Wheel Next : un système extensible, pas une liste figée
Aujourd’hui, les tags de plateforme sont codés en dur dans le nom de fichier. À chaque nouveau besoin, il faut ajouter un tag ; à répéter ce processus, on finit inévitablement avec une charge de maintenance sans fin.
Wheel Next prend une autre direction. Un paquet peut déclarer des métadonnées de variante arbitraires, et via une interface de plugins, l’installateur peut détecter dynamiquement les propriétés de la plateforme pour choisir le wheel optimal. Au lieu d’ajouter un tag pour chaque version de CUDA, on construit un système générique et extensible.
La conception s’inspire d’archspec du gestionnaire de paquets pour supercalculateurs Spack, ainsi que de Conda-forge et de Nix.
État des PEP
Les principaux PEP liés à cette initiative sont les suivants :
| PEP | Titre | Statut |
|---|---|---|
| PEP 817 | Wheel Variants Beyond Platform Tags | Draft |
| PEP 825 | Wheel Variants Package Format | Draft |
Le PEP 817 est devenu le PEP le plus long de l’histoire. Rien que l’examen par les éditeurs de PEP a pris plus d’un mois. Il a ensuite été découpé en unités plus gérables, afin de mener séparément les discussions sur les installateurs, les build backends et les serveurs d’index.
Python Build Standalone : un levier discret
Charlie Marsh a aussi mentionné un point intéressant : Astral maintient le projet Python Build Standalone. Quand on installe Python avec uv, c’est en réalité un build issu de ce projet qui est téléchargé.
L’objectif d’Astral est de publier la distribution Python la plus rapide possible uniquement via l’optimisation du build, sans modifier le code source de CPython. Charlie estime disposer aujourd’hui du Python le plus rapide, mais précise qu’il ne l’affirme pas officiellement tant qu’il n’a pas publié de méthodologie de benchmark rigoureuse.
Comme un très grand nombre de développeurs utilisent déjà uv pour amorcer leur installation de Python, les choix de build d’Astral constituent un levier potentiellement énorme sur les performances de Python.
Une collaboration inter-industrielle sans précédent
En mars 2025, un sommet en présentiel a réuni des représentants d’une vingtaine d’entreprises. L’équipe PyTorch de Meta et l’équipe JAX de Google y ont présenté leurs problématiques respectives.
Voici les entreprises et projets open source qui contribuent actuellement à l’initiative Wheel Next :
Entreprises : NVIDIA, Astral, Quansight, Meta, AMD, Intel, Google, Red Hat, Anaconda, Huawei, Preferred Networks, entre autres, soit plus de 14 acteurs
Projets open source : NumPy, SciPy, PyTorch, scikit-learn, JAX, etc.
Au cours du prototypage, les équipes ont travaillé sur des forks de presque tous les composants de l’écosystème packaging Python : pip, warehouse (PyPI), setuptools, scikit-build-core, bibliothèque packaging, etc. L’objectif final reste bien sûr de tout réunifier.
Le calendrier à venir
Selon l’estimation de Ralf, l’année 2026 sera largement consacrée à l’examen des PEP et aux mises à jour des prototypes, avant que PyPI, Twine et les outils consommateurs de métadonnées ne soient mis à jour à leur tour. Une préparation complète de l’écosystème ne semble donc pas probable avant après 2026.
Jonathan se montre toutefois optimiste. Dès que le standard sera utilisable, il s’attend à une adoption rapide dans l’écosystème ML et calcul scientifique, car les paquets clés participent déjà au groupe de travail Wheel Next.
Glossaire des termes clés
| Terme | Explication |
|---|---|
| Wheel | Format standard de distribution binaire pour les paquets Python (.whl) |
| Wheel Variants | Extension proposée dans les PEP 817/825. Permet de distinguer plusieurs builds d’un même paquet selon les propriétés matérielles |
| SIMD | Instructions CPU traitant plusieurs données en parallèle avec une seule instruction (SSE4, AVX2, ARM Neon, etc.) |
| Fat Binary | Binaire regroupant du code compilé pour plusieurs cibles matérielles. NumPy et PyTorch l’utilisent actuellement |
| Platform Tags | Informations sur l’OS, l’architecture et la version de Python encodées dans le nom du fichier wheel |
| Python Build Standalone | Projet de builds CPython redistribuables maintenu par Astral |
| Variant Provider Plugin | Interface permettant à l’installateur de détecter dynamiquement les propriétés matérielles (comme la version du pilote GPU) et de choisir la bonne variante de wheel |
En conclusion
« Dans l’idéal, l’utilisateur lambda n’a même pas à se soucier de tout cela. Il doit juste pouvoir l’obtenir automatiquement via uv ou pip. » — Charlie Marsh
Le système de packaging de Python a été conçu à une époque plus simple. Mais avec l’explosion des charges de travail en data science et en IA, cette conception est désormais un goulot d’étranglement en matière de performances, de bande passante et d’expérience utilisateur.
Wheel Next constitue un cas rare où des concurrents comme NVIDIA, AMD, Intel, Google et Meta s’assoient à la même table pour rédiger ensemble des PEP et investir dans une infrastructure commune. Le prototype de uv a déjà démontré la faisabilité technique. Il faudra du temps pour que tout l’écosystème suive, mais l’avenir qui se dessine mérite largement l’attente.
Liens associés
- wheelnext.dev — Site officiel du projet Wheel Next
- PEP 817 — Wheel Variants Beyond Platform Tags
- PEP 825 — Wheel Variants Package Format
- pypackaging-native.github.io — Guide des problèmes du packaging Python natif
- astral.sh/pyx — Registre de paquets pyx d’Astral
Cet article est une traduction et adaptation du contenu de Talk Python To Me Episode #544.
Aucun commentaire pour le moment.