`pip install torch` tek satırda tamamlanacak — Python paketlemenin yıllardır süren sorunu sonunda çözülüyor mu?

 (talkpython.fm)
21 puan yazan darjeeling 16 일 전 | 2 yorum | WhatsApp'ta paylaş

NVIDIA·Astral·Quansight ortaklığının ortaya koyduğu Wheel Next: CPU ve GPU ayrımı yapmayan yeni nesil paketleme standardı

Kaynak: Talk Python To Me, Episode #544 |

Arka plan: 2009'da duran tekerlek

pip install numpy çalıştırdığınızda hangi ikili dosya kuruluyor? CPU'nuz ister en yeni AMD Zen 4 olsun ister Apple M4, kurulan wheel, yalnızca 2009 seviyesindeki x86-64 komutlarını kullanacak şekilde derlenmiş oluyor.

SSE4, AVX2 gibi modern SIMD komutlarını kullanmak isteseniz bile, kurucunun bu özelliklerin desteklenip desteklenmediğini bilmesinin bir yolu yok. Sonuç olarak PyTorch gibi paketlerde 900MB'a yaklaşan dev ikili dosyalar ve "bulmaca kitabı" kadar karmaşık kurulum kılavuzu sayfaları ortaya çıkıyor.

NVIDIA, Astral ve Quansight ortaklığı bu sorunu çözmek için Wheel Next girişimini yürütüyor. Paketlerin ihtiyaç duyduğu donanımı bildirmesini ve uv gibi kurucuların otomatik olarak doğru derlemeyi seçebilmesini sağlayan bir dizi PEP bunun merkezinde yer alıyor.

Konuklar

Bu bölüme üç kilit isim katıldı.

Jonathan Dekhtiar (NVIDIA) — CUDA teknolojisine tutkuyla bağlanıp doktorasını tamamladıktan sonra NVIDIA'ya katılan bir mühendis. Son iki yılı aşkın süredir CUDA ile Python'ın kesişimini iyileştirmek için çalışıyor ve Wheel Next girişiminin ana itici güçlerinden biri.

Ralf Gommers (Quansight) — Fizik doktorası geçmişine sahip, 2004'ten beri Python kullanan bir geliştirici. NumPy ve SciPy'nin sürüm yöneticisi, aynı zamanda kamu yararına çalışan Quansight'ın ortak CEO'su. Yerel Python paketleme sorunlarını sistematik biçimde ele alan PyPackaging Native guide'ın da yazarı.

Charlie Marsh (Astral) — uv, ruff, ty araçlarını geliştiren Astral'ın kurucusu ve CEO'su. Ekim 2022'de şirketi kurduğundan beri Python ekosisteminde hız ve kullanıcı deneyimini iyileştirmeye odaklanıyor.

Temel sorun: "en düşük ortak payda tuzağı"

x86-64 için wheel derlediğinizde, yalnızca 2009 öncesi CPU özelliklerini kullanabiliyorsunuz. SSE4, AVX2 gibi daha sonra gelen komutlar, kurucu bu özelliklerin mevcut olup olmadığını bilemediği için hiç kullanılamıyor.

2009 seviyesindeki donanım özellikleriyle 2019~2023 düzeyindeki özellikler arasındaki performans farkı bazı durumlarda 10~20 kata ulaşıyor.

ARM tarafında da durum aynı. Şu an ARM için varsayılan derleme hedefi fiilen Raspberry Pi seviyesi. Yani M4 Max çipli bir MacBook Pro'da bile Raspberry Pi için derlenmiş ikili dosya çalıştırılmış oluyor.

JetBrains'in Python geliştirici anketine göre Python geliştiricilerinin yaklaşık %40~50'si veri bilimi veya bilimsel hesaplama alanında çalışıyor. Yani bu dev topluluk, sistematik biçimde muazzam bir performansı boşa harcıyor.

NumPy bugüne kadar nasıl dayandı

NumPy bu sorunu kendi içinde çözdü. Aynı kaynak kodunu Haswell, Skylake gibi birden fazla CPU mimarisini hedefleyerek birkaç kez derliyor, ardından bunları tek bir Python eklenti modülünde birleştiriyor. Çalışma anında CPU'yu algılayıp en uygun kod yoluna yönlendiriyor.

Intel yıllarca mühendis görevlendirerek x86 kod yollarını optimize etti; ARM tarafının da NumPy için özel bir ana bakımcısı var. Bu sayede performans çok iyi olsa da, bu yaklaşım ancak az sayıdaki büyük projenin kaldırabileceği bir ölçekte uygulanabiliyor.

SciPy, scikit-learn, Pandas ve Pillow'da SIMD optimizasyonları kodun içinde zaten var; ancak bunları wheel içine koyup dağıtmanın bir yolu olmadığı için pratikte dağıtılamıyorlar.

PyTorch örneği: 900MB'lık bir "bulmaca kitabı"

PyPI'deki PyTorch wheel'ları yaklaşık 900MB boyutunda. Bunun nedeni, 5~6 GPU mimarisi için gereken CUDA kütüphanelerinin tek bir ikili dosyada paketlenmesi. PyTorch ekibi 1GB sınırını aşmamak için çok büyük çaba harcıyor.

Belirli bir CUDA sürümüne ihtiyaç duyan kullanıcıların ayrı bir index URL'yi elle ayarlaması gerekiyor; vLLM gibi paketlerin kurulum sayfaları da adeta bir "bulmaca kitabı" kadar karmaşık.

Peki Wheel Next tamamlandığında ne olacak?

uv pip install torch

Tek gereken bu satır olacak. Kurucu GPU'yu otomatik olarak algılayacak, uygun CUDA sürümünü belirleyecek ve o donanıma optimize edilmiş yaklaşık 200~250MB'lık ince bir wheel indirecek. Astral, uv'nin varyant destekli dalında çalışan bir prototipi şimdiden hazırlamış durumda.

Wheel Next'in tasarım felsefesi: sabit liste değil, genişletilebilir sistem

Mevcut yaklaşım platform etiketlerini dosya adına sabit kodluyor. Her yeni gereksinimde yeni etiket eklemek gerekiyor; bu da zamanla sonu gelmeyen bir bakım yüküne dönüşüyor.

Wheel Next farklı bir yol izliyor. Paketler, isteğe bağlı varyant metadata'sı bildirebiliyor; kurucular da plugin arayüzü üzerinden platform özelliklerini dinamik olarak algılayıp en uygun wheel'ı seçebiliyor. Her CUDA sürümü için ayrı etiket tanımlamak yerine, genel amaçlı ve genişletilebilir bir sistem kuruluyor.

Tasarımda süper bilgisayarlar için geliştirilen paket yöneticisi Spack'in archspec yapısından, Conda-forge ve Nix'ten ilham alınmış.

PEP durumu

Bu girişimle ilgili başlıca PEP'ler şunlar:

PEP Başlık Durum
PEP 817 Wheel Variants Beyond Platform Tags Draft
PEP 825 Wheel Variants Package Format Draft

PEP 817, şimdiye kadarki en uzun PEP olma rekorunu kırdı. PEP editörlerinin incelemesi bile bir aydan uzun sürdü. Sonrasında konu daha yönetilebilir parçalara bölündü ve kurucular, build backend'leri ve index sunucuları için tartışmalar ayrı ayrı ilerliyor.

Python Build Standalone: sessiz bir kaldıraç

Charlie Marsh'ın değindiği ilginç bir nokta var. Astral, Python Build Standalone projesinin bakımını yürütüyor. uv ile Python kurduğunuzda indirilen derleme aslında bu projenin çıktısı.

Astral'ın hedefi, CPython kaynak kodunu değiştirmeden yalnızca build optimizasyonlarıyla en hızlı Python dağıtımını sunmak. Charlie şu anda en hızlı Python'a sahip olduklarını düşündüğünü, ancak katı bir benchmark metodolojisini henüz yayımlamadıkları için bunu resmî bir iddia olarak öne sürmeyeceğini söyledi.

Pek çok geliştiricinin zaten uv ile Python bootstrap etmesi düşünüldüğünde, Astral'ın build tercihleri Python performansı üzerinde çok büyük etkisi olabilecek bir kaldıraç hâline geliyor.

Eşi benzeri görülmemiş sektörler arası iş birliği

Mart 2025'te, yaklaşık 20 şirketin temsilcilerinin bir araya geldiği fiziksel bir zirve düzenlendi. Meta'nın PyTorch ekibiyle Google'ın JAX ekibi kendi sorunlarını anlattı.

Şu anda Wheel Next girişimine katkı veren şirketler ve açık kaynak projeleri şunlar:

Şirketler: NVIDIA, Astral, Quansight, Meta, AMD, Intel, Google, Red Hat, Anaconda, Huawei, Preferred Networks ve diğerleriyle birlikte 14'ten fazla şirket

Açık kaynak projeleri: NumPy, SciPy, PyTorch, scikit-learn, JAX vb.

Prototipleme sürecinde pip, warehouse(PyPI), setuptools, scikit-build-core, packaging kütüphanesi gibi Python paketleme ekosisteminin neredeyse tüm bileşenleri fork edilerek üzerinde çalışıldı. Elbette nihai hedef bunları yeniden birleştirmek.

Bundan sonra takvim nasıl ilerleyecek

Ralf'a göre 2026 boyunca PEP incelemeleri ve prototip güncellemeleri sürecek; ardından PyPI, Twine ve metadata tüketen araçlar güncellenecek. Tüm ekosistemin hazır hâle gelmesi ise muhtemelen 2026 sonrasını bulacak.

Ama Jonathan daha iyimser. Standardın kullanılabilir hâle geldiği anda, ML ve bilimsel hesaplama ekosisteminin hızlı biçimde benimseyeceğini düşünüyor. Çünkü kilit paketler zaten Wheel Next çalışma grubunun içinde yer alıyor.

Temel terimler

Terim Açıklama
Wheel Python paketlerinin standart ikili dağıtım biçimi (.whl)
Wheel Variants PEP 817/825'te önerilen genişleme. Aynı paketin birden fazla derlemesini donanım özelliklerine göre ayırır
SIMD Tek komutla birden çok veriyi aynı anda işleyen CPU komutları (SSE4, AVX2, ARM Neon vb.)
Fat Binary Birden fazla donanım hedefi için derlenmiş kodu tek dosyada birleştiren ikili biçim. NumPy ve PyTorch bunu bugün kullanıyor
Platform Tags Wheel dosya adına kodlanan OS, mimari ve Python sürümü bilgileri
Python Build Standalone Astral'ın bakımını yaptığı, yeniden dağıtılabilir CPython derleme projesi
Variant Provider Plugin Kurucunun donanım özelliklerini (GPU sürücü sürümü vb.) dinamik olarak algılayıp doğru wheel varyantını seçmesini sağlayan arayüz

Kapanış

"İdeal olarak normal kullanıcıların bunların hiçbirini düşünmesi gerekmemeli. Her şeyin uv ya da pip üzerinden otomatik gelmesi gerekiyor." — Charlie Marsh

Python paketleme sistemi, her şeyin daha basit olduğu bir dönemde tasarlandı. Ancak veri bilimi ve yapay zeka iş yüklerinin patlayıcı biçimde arttığı bugün, bu tasarım performans, bant genişliği ve kullanıcı deneyimi açısından bir darboğaza dönüşmüş durumda.

Wheel Next, rakiplerin (NVIDIA, AMD, Intel, Google, Meta) aynı masaya oturup birlikte PEP yazdığı ve ortak altyapıya yatırım yaptığı nadir örneklerden biri. uv prototipi teknik uygulanabilirliği zaten göstermiş durumda. Tüm ekosistemin buna yetişmesi zaman alacak, ama ortaya çıkacak gelecek beklemeye fazlasıyla değer.

İlgili bağlantılar

Bu yazı, Talk Python To Me Episode #544 içeriğinin çevrilip düzenlenmiş bir sürümüdür.

İlgili okumalar

2 yorum

 
darjeeling 16 일 전

Neyse ki Wheel Next'e yerli bir şirket olan Lablup da katılıyor.
https://wheelnext.dev/who_are_we/

Diğer tüm yapay zeka şirketleri ise sponsor olmuyor, destek vermiyor veya katılmıyor.
 
roxie 15 일 전

Level-up harika görünüyor!!