Selesai dengan satu baris `pip install torch` — PR lama Python packaging, akhirnya terpecahkan?
(talkpython.fm)Wheel Next dari aliansi NVIDIA·Astral·Quansight: standar packaging generasi berikutnya yang tidak membedakan CPU maupun GPU
Sumber: Talk Python To Me, Episode #544 |
Latar belakang: roda yang berhenti berputar pada 2009
Saat menjalankan pip install numpy, biner seperti apa yang dipasang? Tidak peduli apakah CPU Anda adalah AMD Zen 4 terbaru atau Apple M4, wheel yang dipasang dibangun agar hanya menggunakan set instruksi x86-64 setingkat 2009.
Walaupun ingin memakai instruksi SIMD modern seperti SSE4 atau AVX2, installer tidak punya cara untuk mengetahui apakah fitur tersebut didukung. Hasilnya, untuk paket seperti PyTorch, muncullah file biner raksasa yang mendekati 900MB, serta halaman panduan instalasi yang rumit seperti “buku teka-teki”.
Aliansi NVIDIA, Astral, dan Quansight sedang mendorong inisiatif Wheel Next untuk menyelesaikan masalah ini. Intinya adalah serangkaian PEP yang memungkinkan paket mendeklarasikan kebutuhan perangkat kerasnya, dan installer seperti uv secara otomatis memilih build yang benar.
Perkenalan tamu
Tiga tokoh kunci hadir dalam episode ini.
Jonathan Dekhtiar (NVIDIA) — insinyur yang terpikat oleh teknologi CUDA, menyelesaikan PhD, lalu bergabung dengan NVIDIA. Selama sekitar dua tahun terakhir ia mengerjakan peningkatan di titik temu CUDA dan Python, dan menjadi salah satu penggerak utama inisiatif Wheel Next.
Ralf Gommers (Quansight) — pengembang berlatar belakang PhD fisika yang telah menggunakan Python sejak 2004. Ia adalah release manager NumPy dan SciPy, dan saat ini menjabat sebagai co-CEO organisasi nirlaba Quansight. Ia juga penulis PyPackaging Native guide yang merangkum masalah packaging Python native secara sistematis.
Charlie Marsh (Astral) — pendiri sekaligus CEO Astral, pembuat uv, ruff, dan ty. Sejak mendirikan perusahaan pada Oktober 2022, ia berfokus pada peningkatan kecepatan dan pengalaman pengguna di ekosistem Python.
Masalah inti: “jebakan penyebut persekutuan terkecil”
Jika membangun wheel untuk x86-64, Anda hanya bisa memakai fitur CPU sebelum 2009. Instruksi yang muncul setelahnya seperti SSE4 dan AVX2 sama sekali tidak bisa digunakan, karena installer tidak dapat mengetahui apakah fitur tersebut tersedia.
Perbedaan performa antara kemampuan perangkat keras standar 2009 dan kemampuan standar 2019~2023 bisa mencapai 10~20 kali tergantung kasusnya.
Situasi di ARM juga sama. Target build dasar ARM saat ini pada praktiknya setara dengan Raspberry Pi. Artinya, bahkan di MacBook Pro dengan chip M4 Max, biner yang dijalankan pada dasarnya adalah biner yang dibangun untuk Raspberry Pi.
Menurut survei pengembang Python dari JetBrains, sekitar 40~50% pengembang Python bekerja di bidang data science atau komputasi ilmiah. Komunitas sebesar ini secara sistematis sedang menyia-nyiakan performa dalam jumlah besar.
Bagaimana NumPy bertahan sejauh ini
NumPy menyelesaikan masalah ini dengan caranya sendiri. Kode sumber yang sama dikompilasi berkali-kali untuk berbagai arsitektur CPU seperti Haswell dan Skylake, lalu digabungkan menjadi satu modul ekstensi Python. Saat runtime, CPU dideteksi dan eksekusi dialihkan ke jalur kode yang optimal.
Intel selama bertahun-tahun menugaskan insinyur untuk mengoptimalkan jalur kode x86, dan ARM juga memiliki maintainer NumPy khusus. Hasilnya performanya sangat baik, tetapi pendekatan ini adalah skala yang hanya bisa ditanggung oleh segelintir proyek besar.
SciPy, scikit-learn, Pandas, dan Pillow sudah memiliki optimisasi SIMD di dalam kodenya, tetapi tidak punya cara untuk mengemas dan mendistribusikannya di dalam wheel, sehingga pada praktiknya belum bisa dirilis.
Kasus PyTorch: “buku teka-teki” 900MB
Wheel PyTorch yang diunggah ke PyPI berukuran sekitar 900MB. Itu karena library CUDA untuk 5~6 arsitektur GPU dibundel ke dalam satu biner. Tim PyTorch mengerahkan upaya besar agar ukurannya tidak melewati 1GB.
Pengguna yang membutuhkan versi CUDA tertentu harus mengatur index URL terpisah secara manual, dan halaman instalasi paket seperti vLLM menjadi serumit “buku teka-teki”.
Lalu bagaimana jika Wheel Next selesai?
uv pip install torch
Cukup satu baris ini. Installer akan otomatis mendeteksi GPU, menentukan versi CUDA yang sesuai, lalu mengunduh slim wheel sekitar 200~250MB yang dioptimalkan untuk perangkat keras tersebut. Astral bahkan sudah membangun prototipe yang berjalan di branch uv dengan dukungan variant-enabled.
Filosofi desain Wheel Next: sistem yang dapat diperluas, bukan daftar tetap
Cara saat ini melakukan hardcode platform tag ke nama file. Setiap kali ada kebutuhan baru, tag baru harus ditambahkan, dan jika ini terus diulang maka pada akhirnya akan menjadi beban maintenance tanpa akhir.
Wheel Next berbeda. Paket dapat mendeklarasikan metadata variant arbitrer, dan melalui antarmuka plugin installer dapat mendeteksi atribut platform secara dinamis untuk memilih wheel yang paling tepat. Alih-alih menempelkan tag untuk setiap versi CUDA, yang dibangun adalah sistem yang umum dan dapat diperluas.
Desain ini terinspirasi dari archspec milik package manager superkomputer Spack, Conda-forge, dan Nix.
Status PEP
PEP utama yang terkait dengan inisiatif ini:
| PEP | Judul | Status |
|---|---|---|
| PEP 817 | Wheel Variants Beyond Platform Tags | Draft |
| PEP 825 | Wheel Variants Package Format | Draft |
PEP 817 mencetak rekor sebagai PEP terpanjang sepanjang sejarah. Hanya untuk peninjauan oleh editor PEP saja butuh lebih dari sebulan. Setelah itu, pembahasannya dipecah menjadi unit yang lebih mudah dikelola, dengan diskusi terpisah untuk installer, build backend, dan index server.
Python Build Standalone: tuas yang bekerja diam-diam
Ada satu fakta menarik yang disebut Charlie Marsh. Astral memelihara proyek Python Build Standalone. Saat memasang Python lewat uv, build yang sebenarnya diunduh adalah build dari proyek ini.
Tujuan Astral adalah merilis distribusi Python tercepat hanya melalui optimisasi build, tanpa mengubah source code CPython. Charlie mengatakan ia merasa saat ini mereka memiliki Python tercepat, tetapi tidak akan mengklaimnya secara resmi karena metodologi benchmark yang ketatnya belum dipublikasikan.
Mengingat banyak pengembang sudah melakukan bootstrap Python dengan uv, pilihan build Astral menjadi tuas yang bisa memberi dampak sangat besar pada performa Python.
Kolaborasi lintas industri yang belum pernah ada sebelumnya
Pada Maret 2025, diadakan summit luring yang mempertemukan perwakilan dari sekitar 20 perusahaan. Tim PyTorch dari Meta dan tim JAX dari Google mempresentasikan tantangan masing-masing.
Saat ini, perusahaan dan proyek open source yang berkontribusi pada inisiatif Wheel Next adalah sebagai berikut:
Perusahaan: NVIDIA, Astral, Quansight, Meta, AMD, Intel, Google, Red Hat, Anaconda, Huawei, Preferred Networks, dan lebih dari 14 pihak lainnya
Proyek open source: NumPy, SciPy, PyTorch, scikit-learn, JAX, dan lainnya
Dalam proses pembuatan prototipe, mereka telah mengerjakan fork untuk hampir semua komponen ekosistem packaging Python, termasuk pip, warehouse (PyPI), setuptools, scikit-build-core, dan library packaging. Tentu saja tujuan akhirnya adalah menyatukan semuanya kembali.
Jadwal ke depan
Menurut perkiraan Ralf, sepanjang 2026 akan diisi dengan review PEP dan pembaruan prototipe, lalu setelah itu PyPI, Twine, dan berbagai alat konsumsi metadata akan diperbarui. Seluruh ekosistem tampaknya baru akan siap setelah 2026.
Namun Jonathan optimistis. Begitu standar ini bisa digunakan, ia memperkirakan adopsi di ekosistem ML dan komputasi ilmiah akan berlangsung cepat. Alasannya, paket-paket kunci sudah ikut serta dalam working group Wheel Next.
Ringkasan istilah kunci
| Istilah | Penjelasan |
|---|---|
| Wheel | Format distribusi biner standar untuk paket Python (.whl) |
| Wheel Variants | Ekstensi yang diusulkan di PEP 817/825. Membedakan beberapa build dari paket yang sama berdasarkan atribut perangkat keras |
| SIMD | Instruksi CPU yang memproses banyak data sekaligus dengan satu instruksi (SSE4, AVX2, ARM Neon, dll.) |
| Fat Binary | Biner yang menggabungkan kode hasil kompilasi untuk banyak target perangkat keras. Saat ini dipakai oleh NumPy dan PyTorch |
| Platform Tags | Informasi OS, arsitektur, dan versi Python yang dienkode di nama file wheel |
| Python Build Standalone | Proyek build CPython yang dapat didistribusikan ulang dan dikelola Astral |
| Variant Provider Plugin | Antarmuka yang memungkinkan installer mendeteksi atribut perangkat keras secara dinamis (mis. versi driver GPU) untuk memilih variant wheel yang tepat |
Penutup
“Idealnya, pengguna biasa tidak perlu memikirkan semua ini. Mereka cukup mendapatkannya secara otomatis lewat uv atau pip.” — Charlie Marsh
Sistem packaging Python dirancang pada masa yang lebih sederhana. Namun kini, ketika workload data science dan AI tumbuh eksplosif, desain itu menjadi bottleneck dalam performa, bandwidth, dan pengalaman pengguna.
Wheel Next adalah contoh langka ketika para pesaing (NVIDIA, AMD, Intel, Google, Meta) duduk di meja yang sama, menulis PEP bersama, dan berinvestasi pada infrastruktur bersama. Prototipe uv sudah membuktikan kelayakan teknisnya. Walau butuh waktu hingga seluruh ekosistem menyusul, masa depan itu layak untuk ditunggu.
Tautan terkait
- wheelnext.dev — situs resmi proyek Wheel Next
- PEP 817 — Wheel Variants Beyond Platform Tags
- PEP 825 — Wheel Variants Package Format
- pypackaging-native.github.io — panduan masalah packaging Python native
- astral.sh/pyx — registry paket pyx dari Astral
Artikel ini merupakan terjemahan dan penyuntingan dari Talk Python To Me Episode #544.
2 komentar
Untungnya, Wheel Next juga diikuti oleh perusahaan domestik, Lablup.
https://wheelnext.dev/who_are_we/
Semua perusahaan AI lainnya tidak memberikan sponsor, dukungan, maupun ikut berpartisipasi.
Labelup keren banget!!