21 poin oleh darjeeling 8 hari lalu | 2 komentar | Bagikan ke WhatsApp

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 di tahun 2009

Saat menjalankan pip install numpy, biner seperti apa yang sebenarnya dipasang? Tidak peduli apakah CPU Anda adalah AMD Zen 4 terbaru atau Apple M4. Wheel yang dipasang dibangun agar hanya memakai instruksi x86-64 setara tahun 2009.

Meski ingin memakai instruksi SIMD modern seperti SSE4 dan AVX2, installer tidak punya cara untuk mengetahui apakah fitur itu didukung. Akibatnya, 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 kini 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

Dalam episode ini hadir tiga tokoh kunci.

Jonathan Dekhtiar (NVIDIA) — insinyur yang begitu terpikat teknologi CUDA hingga menempuh PhD lalu bergabung ke NVIDIA. Selama sekitar dua tahun terakhir ia berfokus memperbaiki titik temu antara CUDA dan Python, dan menjadi salah satu pendorong utama inisiatif Wheel Next.

Ralf Gommers (Quansight) — pengembang berlatar belakang doktor fisika yang telah menggunakan Python sejak 2004. Ia adalah release manager NumPy dan SciPy, serta saat ini menjabat co-CEO Quansight, sebuah organisasi nirlaba. 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 itu pada Oktober 2022, ia fokus meningkatkan kecepatan dan pengalaman pengguna di ekosistem Python.


Masalah inti: “jebakan penyebut bersama terendah”

Saat membangun wheel untuk x86-64, kita hanya bisa memakai fitur CPU sebelum 2009. Instruksi yang muncul setelahnya seperti SSE4 dan AVX2 praktis tidak bisa digunakan sama sekali karena installer tidak tahu apakah mesin target memilikinya.

Perbedaan performa antara fitur perangkat keras level 2009 dan level 2019–2023 dalam beberapa kasus bisa mencapai 10–20 kali.

Situasi ARM juga sama. Target build dasar untuk ARM saat ini pada praktiknya setara dengan Raspberry Pi. Artinya, bahkan di MacBook Pro dengan chip M4 Max, biner yang berjalan 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 besar ini secara sistematis membuang performa dalam jumlah sangat besar.


Bagaimana NumPy bertahan sejauh ini

NumPy menyelesaikan masalah ini sendiri. Pendekatannya adalah mengompilasi kode sumber yang sama beberapa kali untuk menargetkan berbagai arsitektur CPU seperti Haswell dan Skylake, lalu menggabungkannya menjadi satu modul ekstensi Python. Saat runtime, CPU dideteksi dan eksekusi dialihkan ke jalur kode yang paling optimal.

Intel selama bertahun-tahun menugaskan insinyur untuk mengoptimalkan jalur kode x86, dan ARM juga memiliki maintainer NumPy khusus. Hasilnya memang performa tinggi, tetapi pendekatan ini berskala hanya untuk segelintir proyek besar.

SciPy, scikit-learn, Pandas, dan Pillow sebenarnya sudah memiliki optimasi SIMD di dalam kodenya, tetapi belum punya cara untuk memasukkan dan mendistribusikannya lewat wheel, sehingga pada praktiknya optimasi itu tidak terkirim ke pengguna.


Kasus PyTorch: “buku teka-teki” 900MB

Wheel PyTorch yang ada di PyPI berukuran sekitar 900MB. Alasannya, library CUDA untuk 5–6 arsitektur GPU dibundel ke dalam satu biner. Tim PyTorch bekerja sangat keras agar ukurannya tidak melewati 1GB.

Pengguna yang membutuhkan versi CUDA tertentu harus mengatur index URL terpisah secara manual, dan halaman instalasi untuk paket seperti vLLM menjadi serumit “buku teka-teki”.

Lalu seperti apa 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: bukan daftar tetap, melainkan sistem yang bisa diperluas

Pendekatan saat ini menaruh platform tag secara hardcode di nama file. Setiap ada kebutuhan baru, tag baru harus ditambahkan, dan jika terus diulang, bebannya pada akhirnya menjadi pemeliharaan tanpa akhir.

Wheel Next berbeda. Paket dapat mendeklarasikan metadata variant sekehendaknya, dan melalui antarmuka plugin, installer dapat mendeteksi atribut platform secara dinamis lalu memilih wheel paling tepat. Alih-alih menempelkan tag untuk setiap versi CUDA satu per satu, pendekatan ini membangun sistem yang generik dan dapat diperluas.

Desainnya terinspirasi dari archspec milik package manager superkomputer Spack, serta 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. Bahkan peninjauan oleh editor PEP saja memakan waktu lebih dari sebulan. Setelah itu, isinya dipecah menjadi unit-unit yang lebih mudah dikelola, dan diskusi terpisah kini berlangsung untuk installer, build backend, dan index server.


Python Build Standalone: tuas yang bekerja diam-diam

Charlie Marsh menyebut satu fakta menarik. Astral memelihara proyek Python Build Standalone. Saat memasang Python lewat uv, build yang sebenarnya diunduh berasal dari proyek ini.

Tujuan Astral adalah merilis distribusi Python tercepat hanya lewat optimasi build, tanpa mengubah source code CPython. Charlie mengatakan ia merasa saat ini mereka memiliki Python tercepat, tetapi belum mau mengklaimnya secara resmi karena metodologi benchmark yang ketatnya belum dipublikasikan.

Karena begitu banyak pengembang sudah melakukan bootstrap Python lewat uv, pilihan build Astral menjadi tuas yang bisa memberi dampak sangat besar pada performa Python.


Kolaborasi lintas industri yang belum pernah terjadi sebelumnya

Pada Maret 2025, diadakan summit luring yang mempertemukan perwakilan dari sekitar 20 perusahaan. Tim PyTorch dari Meta dan tim JAX dari Google mempresentasikan persoalan masing-masing.

Perusahaan dan proyek open source yang kini berkontribusi ke inisiatif Wheel Next mencakup:

Perusahaan: NVIDIA, Astral, Quansight, Meta, AMD, Intel, Google, Red Hat, Anaconda, Huawei, Preferred Networks, dan lebih dari 14 organisasi lainnya

Proyek open source: NumPy, SciPy, PyTorch, scikit-learn, JAX, dan lainnya

Selama proses prototyping, mereka mem-fork hampir semua komponen ekosistem packaging Python, termasuk pip, warehouse (PyPI), setuptools, scikit-build-core, dan library packaging. Tentu saja, tujuan akhirnya adalah menyatukannya kembali.


Jadwal ke depan

Menurut perkiraan Ralf, sepanjang 2026 akan diisi peninjauan PEP dan pembaruan prototipe, lalu disusul pembaruan di PyPI, Twine, dan alat-alat yang mengonsumsi metadata. Seluruh ekosistem tampaknya baru akan siap setelah 2026.

Namun Jonathan optimistis. Begitu standarnya tersedia, adopsi di ekosistem ML dan komputasi ilmiah diperkirakan akan cepat, karena paket-paket inti sudah ikut dalam working group Wheel Next.


Ringkasan istilah kunci

Istilah Penjelasan
Wheel Format distribusi biner standar untuk paket Python (.whl)
Wheel Variants Ekstensi yang diusulkan dalam PEP 817/825. Membedakan beberapa build dari paket yang sama berdasarkan atribut perangkat keras
SIMD Instruksi CPU yang memproses beberapa data sekaligus dengan satu instruksi (SSE4, AVX2, ARM Neon, dll.)
Fat Binary Biner yang menggabungkan kode hasil kompilasi untuk beberapa target perangkat keras. Saat ini digunakan oleh NumPy dan PyTorch
Platform Tags Informasi OS, arsitektur, dan versi Python yang dienkode dalam nama file wheel
Python Build Standalone Proyek build CPython yang dapat didistribusikan ulang dan dipelihara oleh Astral
Variant Provider Plugin Antarmuka yang memungkinkan installer mendeteksi atribut perangkat keras secara dinamis (mis. versi driver GPU) lalu memilih variant wheel yang benar

Penutup

“Idealnya, pengguna biasa tidak perlu memikirkan semua ini. Cukup didapatkan secara otomatis lewat uv atau pip.” — Charlie Marsh

Sistem packaging Python dirancang untuk era yang lebih sederhana. Namun sekarang, ketika beban kerja data science dan AI meledak, desain itu justru 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 untuk menulis PEP bersama dan berinvestasi pada infrastruktur bersama. Prototipe uv sudah membuktikan kelayakan teknisnya. Memang akan butuh waktu hingga seluruh ekosistem menyusul, tetapi masa depan itu layak ditunggu.


Tautan terkait


Artikel ini merupakan terjemahan dan suntingan dari Talk Python To Me Episode #544.

2 komentar

 
darjeeling 8 hari lalu

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.

 
roxie 8 hari lalu

Labelup keren banget!!