ओपन-सोर्स प्रोजेक्ट ZLUDA CUDA ऐप्स को AMD GPUs पर चलाने देता है
ZLUDA नामक एक ओपन-सोर्स प्रोजेक्ट का लक्ष्य CUDA applications को AMD GPUs पर चलाना है, जिससे GPU-accelerated computing में Nvidia के प्रभुत्व को तोड़ने की उम्मीद फिर जगी है। Commenters कानूनी और तकनीकी बाधाओं पर विचार करते हैं, Nvidia की EULA restrictions और cuDNN जैसी proprietary libraries पर निर्भरता से लेकर clean-room reimplementation और performance parity की चुनौतियों तक। बहस का बड़ा हिस्सा AMD के लंबे समय से आलोचित software ecosystem और उसकी रणनीतिक पसंदों पर केंद्रित है, जिसमें यह भी शामिल है कि उसने ZLUDA को फंड करना क्यों बंद किया और क्या ROCm, HIP, या open standards कभी CUDA की maturity और lock-in का मुकाबला कर सकते हैं।
ZLUDA का दायरा और कानूनी सीमाएँ
- ZLUDA एक क्लीन-रूम, ड्रॉप‑इन CUDA कार्यान्वयन है जो गैर‑Nvidia GPUs को लक्षित करता है (पहले Intel, अब AMD)।
- Nvidia की CUDA EULA ने, कम से कम 2022 से, SDK आउटपुट्स का उपयोग गैर‑Nvidia प्लेटफ़ॉर्म को लक्षित करने और प्रमुख लाइब्रेरीज़ (जैसे cuDNN, cuBLAS) को अन्य हार्डवेयर पर चलाने पर प्रतिबंध लगाया है।
- प्रवर्तनीयता पर बहस:
- एक पक्ष: एमुलेशन और API पुनः-कार्यान्वयन सामान्यतः कानूनी हैं; यदि आपने कभी Nvidia की EULA से सहमति नहीं दी, तो आप उससे बंधे नहीं हैं, और यह anti-competitive भी हो सकता है।
- दूसरा पक्ष: यदि ऐप्स Nvidia बाइनरीज़ को बंडल करते हैं, तो उनके लाइसेंस उन्हें थर्ड-पार्टी runtime पर चलाने से रोक सकते हैं; DMCA और गैर-वेंडर हार्डवेयर पर OS से जुड़े पहले के मामलों से व्यावसायिक उपयोग में मजबूत कानूनी जोखिम का संकेत मिलता है।
- क्लीन-रूम रिवर्स इंजीनियरिंग संभव है, लेकिन महंगी और वर्तमान बनाए रखना कठिन है; Nvidia की सभी लाइब्रेरीज़ के लिए ऐसा करना एक बड़ी बाधा है।
AMD की रणनीति और सॉफ़्टवेयर इकोसिस्टम
- कई लोग मानते हैं कि AMD की सबसे बड़ी कमजोरी सॉफ़्टवेयर है: बग्गी OpenCL/ROCm/HIP स्टैक्स, अस्थिर ड्राइवर्स, और छोटे सपोर्ट विंडो, जबकि हार्डवेयर काफ़ी अच्छा है।
- AMD ने लगभग 2 वर्षों तक ZLUDA को फंड किया, फिर “कोई business case नहीं” कहकर रोक दिया; कॉन्ट्रैक्ट के अनुसार कोड ओपन सोर्स बन गया।
- कुछ लोग इसे एक खोया हुआ अवसर और “absurd” मानते हैं, क्योंकि इससे तुरंत AMD उपयोगकर्ताओं को लाभ मिलता है।
- दूसरे तर्क देते हैं कि यह तर्कसंगत है: एक मज़बूत CUDA-on-AMD परत डेवलपर्स को Nvidia-केंद्रित बने रहने दे सकती है, जबकि AMD को केवल सस्ते execution hardware के रूप में उपयोग किया जाएगा, जिससे CUDA और अधिक मजबूत हो सकता है।
तकनीकी और व्यावहारिक सीमाएँ
- मुख्य कठिनाई बुनियादी kernel translation नहीं, बल्कि Nvidia की लाइब्रेरीज़ (cuDNN, cuBLAS, आदि) के लिए उच्च-प्रदर्शन, maintained समकक्ष बनाना है।
- Nvidia के पास PTX एक स्थिर IR है; AMD अक्सर प्रति-आर्किटेक्चर compile करता है, जिससे long-term support और community optimization जटिल हो जाते हैं।
- ZLUDA + llama.cpp के काम करने की रिपोर्टें हैं, लेकिन native ROCm की तुलना में धीमे; AMD APUs आमतौर पर memory bandwidth और छोटे प्रभावी “VRAM” से बाधित होते हैं।
- कुछ hobbyists consumer AMD GPUs पर छोटे LLMs के साथ अच्छे अनुभव बताते हैं; अन्य लगातार crashes, segfaults, और driver bugs की शिकायत करते हैं।
विकल्प और मानक
- उल्लिखित विकल्प: HIP/HIPIFY (source translation, runtime नहीं), ROCm, OpenCL, Vulkan compute, SYCL, OpenMP GPU offload।
- कई commenters का तर्क है कि AMD और Intel को मिलकर SYCL जैसे open standards को आगे बढ़ाना चाहिए; अन्य लोग नोट करते हैं कि fragmentation और खराब implementations ने traction सीमित कर दी है।
व्यापक बाज़ार दृष्टिकोण
- कई टिप्पणियाँ Nvidia, AMD, और Intel को शक्ति मिलने पर उभरते monopolists की तरह प्रस्तुत करती हैं।
- यह अटकल लगाई जाती है कि regulators, विशेषकर EU में, अंततः Nvidia की restrictions को anti-competitive मान सकते हैं, लेकिन परिणाम स्पष्ट नहीं हैं।