`pip install torch` in einer Zeile erledigt — wird ein langjähriges Python-Packaging-Problem endlich gelöst?
(talkpython.fm)NVIDIA, Astral und Quansight stellen Wheel Next vor: einen Packaging-Standard der nächsten Generation, der CPU und GPU gleichermaßen abdeckt
Quelle: Talk Python To Me, Episode #544 |
Hintergrund: ein Rad, das 2009 stehen geblieben ist
Wenn man pip install numpy ausführt, welches Binärpaket wird dann installiert? Es spielt keine Rolle, ob Ihre CPU ein aktueller AMD Zen 4 oder ein Apple M4 ist. Das installierte Wheel ist so gebaut, dass es nur x86-64-Befehle auf dem Stand von 2009 verwendet.
Selbst wenn man moderne SIMD-Befehle wie SSE4 oder AVX2 nutzen möchte, hat der Installer keine Möglichkeit zu erkennen, ob diese Funktionen unterstützt werden. Das Ergebnis sind bei Paketen wie PyTorch riesige Binärdateien mit fast 900 MB und Installationsanleitungen, die so kompliziert sind wie ein „Puzzlebuch“.
Die Allianz aus NVIDIA, Astral und Quansight treibt zur Lösung dieses Problems die Initiative Wheel Next voran. Im Kern steht eine Reihe von PEPs, mit denen Pakete die benötigte Hardware deklarieren können und Installer wie uv automatisch den richtigen Build auswählen.
Die Gäste
In dieser Episode waren drei zentrale Personen dabei.
Jonathan Dekhtiar (NVIDIA) — ein Ingenieur, der von CUDA so begeistert war, dass er darin sogar promovierte und anschließend zu NVIDIA ging. Seit gut zwei Jahren arbeitet er daran, die Schnittstelle zwischen CUDA und Python zu verbessern, und ist ein zentraler Treiber der Wheel-Next-Initiative.
Ralf Gommers (Quansight) — Entwickler mit Physik-Promotion, der seit 2004 Python verwendet. Er ist Release Manager von NumPy und SciPy und heute Co-CEO der gemeinnützigen Organisation Quansight. Außerdem ist er Autor des PyPackaging Native Guide, der Probleme beim nativen Python-Packaging systematisch aufarbeitet.
Charlie Marsh (Astral) — Gründer und CEO von Astral, dem Unternehmen hinter uv, ruff und ty. Seit der Gründung im Oktober 2022 konzentriert sich Astral darauf, Geschwindigkeit und User Experience im Python-Ökosystem zu verbessern.
Das Kernproblem: die „Falle des kleinsten gemeinsamen Nenners“
Wenn ein Wheel für x86-64 gebaut wird, darf es nur CPU-Funktionen verwenden, die es schon vor 2009 gab. Befehle wie SSE4 oder AVX2, die später eingeführt wurden, können überhaupt nicht genutzt werden, weil der Installer nicht erkennen kann, ob die jeweilige Hardware sie unterstützt.
Der Leistungsunterschied zwischen dem Hardware-Stand von 2009 und dem von 2019 bis 2023 beträgt je nach Fall das 10- bis 20-Fache.
Bei ARM sieht es ähnlich aus. Das aktuelle Standard-Build-Ziel für ARM entspricht praktisch dem Niveau eines Raspberry Pi. Das bedeutet: Selbst auf einem MacBook Pro mit M4 Max läuft ein Binärpaket, das für einen Raspberry Pi gebaut wurde.
Laut der Python-Entwicklerumfrage von JetBrains arbeiten rund 40 bis 50 % der Python-Entwickler im Bereich Data Science oder Scientific Computing. Diese riesige Community verschwendet also systematisch enorme Mengen an Performance.
Wie NumPy sich bisher durchgeschlagen hat
NumPy hat dieses Problem intern selbst gelöst. Dabei wird derselbe Quellcode mehrfach kompiliert, jeweils für verschiedene CPU-Architekturen wie Haswell oder Skylake, und anschließend zu einem einzigen Python-Erweiterungsmodul zusammengeführt. Zur Laufzeit wird die CPU erkannt und dann auf den optimalen Codepfad verzweigt.
Intel hat über Jahre hinweg Ingenieure abgestellt, um die x86-Codepfade zu optimieren, und auch ARM hat einen dedizierten NumPy-Maintainer. Das sorgt zwar für starke Performance, ist aber ein Ansatz in einer Größenordnung, die nur wenige große Projekte stemmen können.
SciPy, scikit-learn, Pandas und Pillow haben SIMD-Optimierungen zwar bereits im Code implementiert, können sie aber nicht tatsächlich über Wheels ausliefern, weil dafür ein geeigneter Distributionsmechanismus fehlt.
Der Fall PyTorch: ein 900-MB-„Puzzlebuch“
Die auf PyPI bereitgestellten PyTorch-Wheels sind rund 900 MB groß. Der Grund ist, dass CUDA-Bibliotheken für 5 bis 6 GPU-Architekturen in einer einzigen Binärdatei gebündelt werden. Das PyTorch-Team betreibt enormen Aufwand, um unter 1 GB zu bleiben.
Wer eine bestimmte CUDA-Version benötigt, muss eine separate Index-URL manuell setzen, und Installationsseiten für Pakete wie vLLM sind so komplex wie ein „Puzzlebuch“.
Wie würde es aussehen, wenn Wheel Next fertig ist?
uv pip install torch
Diese eine Zeile würde genügen. Der Installer erkennt automatisch die GPU, ermittelt die passende CUDA-Version und lädt ein schlankes, auf die jeweilige Hardware optimiertes Wheel mit etwa 200 bis 250 MB herunter. Astral hat bereits einen funktionierenden Prototypen in einem variant-enabled Branch von uv aufgebaut.
Die Designphilosophie von Wheel Next: kein festes Verzeichnis, sondern ein erweiterbares System
Der aktuelle Ansatz codiert Plattform-Tags fest im Dateinamen. Bei jeder neuen Anforderung muss ein weiterer Tag hinzugefügt werden — auf Dauer führt das zu endlosem Wartungsaufwand.
Wheel Next geht einen anderen Weg. Pakete können beliebige Variant-Metadaten deklarieren, und über eine Plugin-Schnittstelle kann der Installer Plattform-Eigenschaften dynamisch erkennen und das optimale Wheel auswählen. Anstatt jede einzelne CUDA-Version mit einem eigenen Tag zu versehen, entsteht so ein allgemeines und erweiterbares System.
Das Design wurde von archspec aus dem Supercomputer-Paketmanager Spack, von Conda-forge und von Nix inspiriert.
Stand der PEPs
Die wichtigsten PEPs im Zusammenhang mit dieser Initiative sind:
| PEP | Titel | Status |
|---|---|---|
| PEP 817 | Wheel Variants Beyond Platform Tags | Draft |
| PEP 825 | Wheel Variants Package Format | Draft |
PEP 817 stellte einen Rekord als längster PEP überhaupt auf. Allein die Prüfung durch die PEP-Editoren dauerte mehr als einen Monat. Danach wurde er in handhabbarere Teile zerlegt; Diskussionen zu Installer, Build-Backend und Index-Server laufen nun getrennt.
Python Build Standalone: ein stiller Hebel
Charlie Marsh erwähnte noch einen interessanten Punkt: Astral betreut das Projekt Python Build Standalone. Wenn Python mit uv installiert wird, wird in der Praxis genau ein Build aus diesem Projekt heruntergeladen.
Astrals Ziel ist es, ohne Änderungen am CPython-Quellcode allein durch Build-Optimierungen die schnellste Python-Distribution bereitzustellen. Charlie sagte, er glaube zwar, aktuell das schnellste Python zu haben, wolle dies aber nicht offiziell behaupten, solange noch keine strenge Benchmark-Methodik veröffentlicht sei.
Da bereits sehr viele Entwickler Python über uv bootstrappen, kann Astrals Wahl der Builds zu einem Hebel werden, der enormen Einfluss auf die Python-Performance hat.
Beispiellose Zusammenarbeit über Unternehmensgrenzen hinweg
Im März 2025 fand ein Summit vor Ort statt, bei dem Vertreter von rund 20 Unternehmen zusammenkamen. Das PyTorch-Team von Meta und das JAX-Team von Google stellten jeweils ihre eigenen Herausforderungen vor.
Derzeit tragen folgende Unternehmen und Open-Source-Projekte zur Wheel-Next-Initiative bei:
Unternehmen: NVIDIA, Astral, Quansight, Meta, AMD, Intel, Google, Red Hat, Anaconda, Huawei, Preferred Networks und mehr als 14 insgesamt
Open-Source-Projekte: NumPy, SciPy, PyTorch, scikit-learn, JAX und weitere
Während des Prototypings wurde praktisch fast jede Komponente des Python-Packaging-Ökosystems geforkt und bearbeitet, darunter pip, warehouse (PyPI), setuptools, scikit-build-core und die Bibliothek packaging. Das endgültige Ziel ist natürlich, diese Arbeiten wieder zusammenzuführen.
Der weitere Zeitplan
Ralf erwartet, dass sich PEP-Review und Prototyp-Updates über das gesamte Jahr 2026 erstrecken und danach PyPI, Twine sowie Tools, die Metadaten verarbeiten, aktualisiert werden. Dass das gesamte Ökosystem bereit ist, dürfte also erst nach 2026 realistisch sein.
Jonathan ist jedoch optimistisch. Sobald der Standard verfügbar ist, dürfte die Akzeptanz im ML- und Scientific-Computing-Ökosystem schnell zunehmen — nicht zuletzt, weil die wichtigsten Pakete bereits in der Wheel-Next-Arbeitsgruppe vertreten sind.
Wichtige Begriffe im Überblick
| Begriff | Erklärung |
|---|---|
| Wheel | Standardformat für die binäre Distribution von Python-Paketen (.whl) |
| Wheel Variants | In PEP 817/825 vorgeschlagene Erweiterung. Unterscheidet mehrere Builds desselben Pakets anhand von Hardware-Eigenschaften |
| SIMD | CPU-Befehle, die mehrere Daten gleichzeitig mit einem einzelnen Befehl verarbeiten (SSE4, AVX2, ARM Neon usw.) |
| Fat Binary | Binärdatei, die kompilierten Code für mehrere Hardware-Ziele in einem Paket bündelt. Wird derzeit von NumPy und PyTorch genutzt |
| Platform Tags | Im Wheel-Dateinamen codierte Informationen zu OS, Architektur und Python-Version |
| Python Build Standalone | Von Astral betreutes Projekt für weiterverteilbare CPython-Builds |
| Variant Provider Plugin | Schnittstelle, über die ein Installer Hardware-Eigenschaften (z. B. GPU-Treiberversionen) dynamisch erkennt und das richtige Wheel-Variant auswählt |
Zum Schluss
„Im Idealfall müssen normale Nutzer sich um all das gar nicht kümmern. Sie bekommen es einfach automatisch über uv oder pip.“ — Charlie Marsh
Das Python-Packaging-System wurde für eine einfachere Zeit entworfen. Doch heute, da Data-Science- und AI-Workloads explosionsartig zunehmen, wird dieses Design bei Performance, Bandbreite und User Experience gleichermaßen zum Flaschenhals.
Wheel Next ist ein seltenes Beispiel dafür, dass Konkurrenten wie NVIDIA, AMD, Intel, Google und Meta an einem Tisch sitzen, gemeinsam PEPs schreiben und in gemeinsame Infrastruktur investieren. Der uv-Prototyp hat die technische Machbarkeit bereits gezeigt. Bis das gesamte Ökosystem nachzieht, wird es zwar dauern — aber diese Zukunft lohnt das Warten.
Verwandte Links
- wheelnext.dev — Offizielle Website des Wheel-Next-Projekts
- PEP 817 — Wheel Variants Beyond Platform Tags
- PEP 825 — Wheel Variants Package Format
- pypackaging-native.github.io — Leitfaden zu Problemen beim nativen Python-Packaging
- astral.sh/pyx — Astrals Paket-Registry pyx
Dieser Artikel ist eine übersetzte und redaktionell bearbeitete Fassung von Talk Python To Me Episode #544.
2 Kommentare
Bei Wheel Next nimmt glücklicherweise auch das inländische Unternehmen Rablup teil.
https://wheelnext.dev/who_are_we/
Alle anderen AI-Unternehmen leisten weder Sponsoring oder Unterstützung noch nehmen sie teil.
LevelUp ist wirklich cool!!