`pip install torch` अब एक लाइन में पूरा होगा — Python packaging की पुरानी समस्या क्या आखिरकार हल होने वाली है

 (talkpython.fm)
21 पॉइंट द्वारा darjeeling 18 일 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें

NVIDIA·Astral·Quansight गठबंधन द्वारा पेश Wheel Next: CPU और GPU दोनों के लिए अगली पीढ़ी का packaging standard

स्रोत: Talk Python To Me, Episode #544 |

पृष्ठभूमि: 2009 में रुक गया पहिया

जब आप pip install numpy चलाते हैं, तो कौन-सा binary install होता है? आपका CPU चाहे नवीनतम AMD Zen 4 हो या Apple M4, install होने वाला wheel सिर्फ 2009-स्तर के x86-64 instruction set का उपयोग करने के लिए बना होता है.

भले ही आप SSE4, AVX2 जैसे आधुनिक SIMD instructions का उपयोग करना चाहें, installer के पास यह जानने का कोई तरीका नहीं है कि ये features supported हैं या नहीं. इसका नतीजा PyTorch जैसे packages में लगभग 900MB तक पहुँचने वाली विशाल binary files और “puzzle book” जैसी जटिल installation guide pages के रूप में सामने आता है.

NVIDIA, Astral और Quansight का गठबंधन इस समस्या को हल करने के लिए Wheel Next initiative को आगे बढ़ा रहा है. इसका मूल एक श्रृंखला PEPs है, जिससे package अपनी ज़रूरी hardware requirements घोषित कर सके और uv जैसे installers अपने-आप सही build चुन सकें.

अतिथि परिचय

इस एपिसोड में तीन प्रमुख लोग शामिल थे.

Jonathan Dekhtiar (NVIDIA) — CUDA technology से प्रभावित होकर PhD पूरी करने के बाद NVIDIA में शामिल हुए engineer. पिछले लगभग दो वर्षों से CUDA और Python के interface को बेहतर बनाने पर काम कर रहे हैं, और Wheel Next initiative के प्रमुख प्रेरकों में से एक हैं.

Ralf Gommers (Quansight) — physics में PhD पृष्ठभूमि वाले developer, जो 2004 से Python का उपयोग कर रहे हैं. वे NumPy और SciPy के release manager हैं, और वर्तमान में public-benefit corporation Quansight के co-CEO हैं. वे native Python packaging समस्याओं को व्यवस्थित रूप से समझाने वाली PyPackaging Native guide के लेखक भी हैं.

Charlie Marsh (Astral) — uv, ruff, ty बनाने वाली Astral के founder और CEO. अक्टूबर 2022 में startup शुरू करने के बाद से वे Python ecosystem की speed और user experience सुधारने पर केंद्रित रहे हैं.

मुख्य समस्या: “lowest common denominator” का जाल

यदि x86-64 के लिए wheel बनाया जाता है, तो वह 2009 से पहले की CPU capabilities तक सीमित रहता है. SSE4, AVX2 जैसी बाद में आई instructions का उपयोग ही नहीं किया जा सकता, क्योंकि installer यह पता नहीं लगा सकता कि target system में ये features मौजूद हैं या नहीं.

2009-स्तर की hardware capabilities और 2019~2023-स्तर की capabilities के बीच performance अंतर कुछ मामलों में 10~20 गुना तक पहुँच सकता है.

ARM की स्थिति भी अलग नहीं है. मौजूदा default ARM build target व्यवहार में लगभग Raspberry Pi स्तर का है. यानी M4 Max chip वाले MacBook Pro पर भी Raspberry Pi के लिए बना binary चल रहा होता है.

JetBrains के Python developer survey के अनुसार, लगभग 40~50% Python developers data science या scientific computing क्षेत्रों में काम करते हैं. यानी यह विशाल community व्यवस्थित रूप से भारी performance बर्बाद कर रही है.

NumPy अब तक कैसे संभलता रहा

NumPy ने इस समस्या का समाधान अपने स्तर पर किया. वही source code Haswell, Skylake जैसी कई CPU architectures को target करके कई बार compile किया जाता है, और फिर उन्हें एक Python extension module में जोड़ा जाता है. Runtime पर CPU detect करके सबसे उपयुक्त code path पर dispatch किया जाता है.

Intel ने वर्षों तक engineers भेजकर x86 code paths optimize किए, और ARM के पास भी dedicated NumPy maintainer है. इससे performance शानदार है, लेकिन यह तरीका सिर्फ कुछ बड़े projects ही वहन कर सकते हैं.

SciPy, scikit-learn, Pandas और Pillow में code स्तर पर SIMD optimizations मौजूद हैं, लेकिन उन्हें wheel में पैक करके वितरित करने का तरीका न होने के कारण वे वास्तव में shipping नहीं हो पाते.

PyTorch का मामला: 900MB की “puzzle book”

PyPI पर उपलब्ध PyTorch wheel का आकार लगभग 900MB है. इसकी वजह यह है कि 5~6 GPU architectures के लिए CUDA libraries एक ही binary में बंधी होती हैं. PyTorch टीम 1GB से ऊपर न जाने के लिए बहुत मेहनत कर रही है.

जिन उपयोगकर्ताओं को खास CUDA version चाहिए, उन्हें अलग index URL हाथ से सेट करना पड़ता है, और vLLM जैसे packages के installation pages “puzzle book” जितने जटिल हो जाते हैं.

तो Wheel Next पूरा होने पर क्या होगा?

uv pip install torch

बस यह एक लाइन काफी होगी. Installer अपने-आप GPU detect करेगा, सही CUDA version पहचानेगा, और उस hardware के लिए optimized लगभग 200~250MB का slim wheel डाउनलोड करेगा. Astral पहले ही uv की variant-enabled branch में काम करने वाला prototype बना चुका है.

Wheel Next का design philosophy: fixed list नहीं, extensible system

मौजूदा तरीका platform tags को filename में hardcode करता है. हर नई requirement आने पर नया tag जोड़ना पड़ता है, और यह दोहराते रहने पर अंतहीन maintenance burden पैदा होता है.

Wheel Next अलग है. Package मनचाहा variant metadata घोषित कर सकता है, और plugin interface के ज़रिए installer dynamically platform properties detect करके सबसे उपयुक्त wheel चुन सकता है. हर CUDA version के लिए अलग tag जोड़ने के बजाय, यहाँ general-purpose और extensible system बनाया गया है.

इस design को supercomputer package manager Spack के archspec, Conda-forge, और Nix से प्रेरणा मिली है.

PEP की स्थिति

इस initiative से जुड़े प्रमुख PEP ये हैं:

PEP शीर्षक स्थिति
PEP 817 Wheel Variants Beyond Platform Tags Draft
PEP 825 Wheel Variants Package Format Draft

PEP 817 ने अब तक के सबसे लंबे PEP का रिकॉर्ड बनाया. सिर्फ PEP editors की review में ही एक महीने से ज़्यादा समय लगा. इसके बाद इसे manageable हिस्सों में बाँटा गया, और installer, build backend, तथा index server पर अलग-अलग चर्चाएँ चल रही हैं.

Python Build Standalone: एक शांत lever

Charlie Marsh ने एक दिलचस्प बात बताई. Astral Python Build Standalone project को maintain करता है. जब आप uv से Python install करते हैं, तो वास्तव में इसी project का build डाउनलोड होता है.

Astral का लक्ष्य CPython source code बदले बिना केवल build optimization के आधार पर सबसे तेज़ Python distribution जारी करना है. Charlie का कहना है कि उन्हें लगता है कि उनके पास अभी सबसे तेज़ Python है, लेकिन चूँकि उन्होंने अभी तक कठोर benchmarking methodology सार्वजनिक नहीं की है, इसलिए वे इसे आधिकारिक दावा नहीं कहेंगे.

यह देखते हुए कि बहुत-से developers पहले से uv के माध्यम से Python bootstrap कर रहे हैं, Astral की build choices Python performance पर बहुत बड़ा असर डालने वाला lever बन सकती हैं.

अभूतपूर्व उद्योग-स्तरीय सहयोग

मार्च 2025 में लगभग 20 कंपनियों के प्रतिनिधियों का एक offline summit आयोजित हुआ. Meta की PyTorch टीम और Google की JAX टीम ने अपनी-अपनी समस्याएँ साझा कीं.

वर्तमान में Wheel Next initiative में योगदान देने वाली कंपनियाँ और open source projects इस प्रकार हैं:

कंपनियाँ: NVIDIA, Astral, Quansight, Meta, AMD, Intel, Google, Red Hat, Anaconda, Huawei, Preferred Networks सहित 14 से अधिक

ओपन सोर्स प्रोजेक्ट्स: NumPy, SciPy, PyTorch, scikit-learn, JAX आदि

Prototyping के दौरान pip, warehouse(PyPI), setuptools, scikit-build-core, packaging library सहित Python packaging ecosystem के लगभग सभी components को fork करके काम किया गया. बेशक, अंतिम लक्ष्य उन्हें फिर से एक साथ लाना है.

आगे की समयरेखा

Ralf के अनुमान के अनुसार, 2026 भर PEP review और prototype updates चलते रहेंगे, और उसके बाद PyPI, Twine तथा metadata consumer tools अपडेट किए जाएँगे. पूरे ecosystem के तैयार होने में 2026 के बाद तक समय लग सकता है.

लेकिन Jonathan आशावादी हैं. उनका मानना है कि जैसे ही standard उपयोग के लिए उपलब्ध होगा, ML और scientific computing ecosystem में adoption तेज़ होगा. इसकी वजह यह है कि मुख्य packages पहले से Wheel Next working group में शामिल हैं.

मुख्य शब्दावली

शब्द विवरण
Wheel Python package का standard binary distribution format (.whl)
Wheel Variants PEP 817/825 में प्रस्तावित विस्तार; एक ही package के कई builds को hardware properties के आधार पर अलग करना
SIMD CPU instructions जो एक ही instruction से कई data items को साथ process करते हैं (SSE4, AVX2, ARM Neon आदि)
Fat Binary कई hardware targets के compiled code को एक में बाँधने वाला binary; NumPy और PyTorch अभी इसका उपयोग करते हैं
Platform Tags wheel filename में encode की गई OS, architecture और Python version जानकारी
Python Build Standalone Astral द्वारा maintain किया जाने वाला redistributable CPython build project
Variant Provider Plugin ऐसा interface जिसके ज़रिए installer hardware properties (जैसे GPU driver version) dynamically detect करके सही wheel variant चुनता है

समापन

“आदर्श रूप से सामान्य उपयोगकर्ता को इन सब बातों की चिंता करने की ज़रूरत ही नहीं होनी चाहिए. यह सब उसे बस uv या pip के माध्यम से अपने-आप मिल जाना चाहिए.” — Charlie Marsh

Python packaging system उस दौर में डिजाइन किया गया था जब चीज़ें कहीं अधिक सरल थीं. लेकिन आज, जब data science और AI workloads विस्फोटक रूप से बढ़ चुके हैं, वही design performance, bandwidth और user experience—तीनों में bottleneck बन गया है.

Wheel Next एक दुर्लभ उदाहरण है जहाँ प्रतिद्वंद्वी कंपनियाँ—NVIDIA, AMD, Intel, Google और Meta—एक ही मेज़ पर बैठकर साथ में PEP लिख रही हैं और साझा infrastructure में निवेश कर रही हैं. uv का prototype तकनीकी व्यवहार्यता पहले ही साबित कर चुका है. पूरे ecosystem को वहाँ तक पहुँचने में समय लगेगा, लेकिन यह ऐसा भविष्य है जिसका इंतज़ार किया जा सकता है.

संबंधित लिंक

यह लेख Talk Python To Me Episode #544 की सामग्री का अनुवाद और संपादन है.

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.