PyTorch Monarch पेश किया गया

• PyTorch Monarch एक नया framework है, जिसे बड़े मॉडलों के कुशल distributed training और inference को सपोर्ट करने के लिए डिज़ाइन किया गया है
• यह मौजूदा PyTorch की modular संरचना का विस्तार करता है और विशाल neural network को कई devices और nodes में अपने-आप विभाजित और प्रबंधित करने की सुविधा देता है
• model parallelism, pipeline parallelism, data parallelism को एकीकृत रूप से नियंत्रित करने वाली API के जरिए डेवलपर्स पर जटिल configuration का बोझ कम करता है
• Monarch खास तौर पर large language models (LLM) और recommendation systems जैसे memory-intensive workloads में उच्च दक्षता दिखाता है
• यह PyTorch ecosystem में scalability और performance optimization को एक साथ हासिल करने की कोशिश का हिस्सा है, और अगली पीढ़ी के distributed training infrastructure का एक प्रमुख घटक है

---

PyTorch Monarch का अवलोकन

• PyTorch Monarch को PyTorch के एक नए component के रूप में पेश किया गया है, जिसका उद्देश्य बड़े मॉडलों के distributed training और inference को सरल बनाना है
  • इसे इस तरह डिज़ाइन किया गया है कि PyTorch की मौजूदा flexibility बनाए रखते हुए, अरबों parameters वाले मॉडलों को कई GPU और nodes पर कुशलता से तैनात किया जा सके
  • जटिल parallelization strategies को manually सेट करने की ज़रूरत बिना, यह स्वचालित partitioning और communication optimization सुविधाएँ प्रदान करता है
• Monarch का मुख्य लक्ष्य model parallelism के abstraction level को बढ़ाना है, ताकि डेवलपर्स मॉडल architecture डिज़ाइन पर ध्यान दे सकें
  • data parallelism, pipeline parallelism, tensor parallelism जैसी विभिन्न parallelization तकनीकों को एक एकीकृत interface से नियंत्रित किया जा सकता है
  • इससे मौजूदा distributed training frameworks की तुलना में code complexity और communication overhead काफी कम हो जाता है

मुख्य फीचर और तकनीकी विशेषताएँ

• Monarch automatic partitioning algorithm के जरिए मॉडल की हर layer को सबसे उपयुक्त device पर रखता है
  • GPU memory capacity, communication bandwidth, computational load आदि को ध्यान में रखकर partitioning strategy को dynamic रूप से तय किया जाता है
  • यह automation खास तौर पर LLM, Transformer-आधारित models, बड़े recommendation systems में उच्च दक्षता दिखाता है
• यह unified parallelization API प्रदान करता है, जिससे डेवलपर्स एक ही codebase से अलग-अलग parallelization strategies पर प्रयोग कर सकते हैं
  • उदाहरण के लिए, एक ही मॉडल को data parallelism और pipeline parallelism के संयोजन के साथ चलाया जा सकता है, या tensor parallelism में बदला जा सकता है
  • यह flexibility मॉडल के आकार और hardware configuration के अनुसार optimization खोजने को आसान बनाती है
• Monarch, PyTorch की मौजूदा DistributedDataParallel(DDP) और Fully Sharded Data Parallel(FSDP) सुविधाओं के साथ compatible है
  • मौजूदा codebase में बड़े बदलाव किए बिना Monarch पर migration संभव है
  • यह PyTorch के TorchScript और TorchDynamo के साथ भी integrate होता है, जिससे compilation और execution optimization को सपोर्ट मिलता है

प्रदर्शन और उपयोग के उदाहरण

• शुरुआती benchmark नतीजों के अनुसार, Monarch ने मौजूदा PyTorch distributed training की तुलना में communication efficiency में 20~30% सुधार और memory usage में 15% कमी हासिल की
  • खासकर अरबों parameters वाले मॉडलों में training speed और GPU utilization में बड़ा सुधार देखा गया
  • बड़े language models (जैसे GPT series) और recommendation systems में इसका प्रयोगात्मक सत्यापन किया गया
• Monarch cloud और on-premise दोनों environments में काम करता है, और AWS, Azure, GCP जैसे प्रमुख cloud infrastructure के साथ compatible है
  • यह PyTorch Lightning, Hugging Face Transformers जैसे higher-level frameworks के साथ integration भी सपोर्ट करता है

PyTorch ecosystem में महत्व

• Monarch को PyTorch द्वारा बड़े AI models के युग के लिए प्रमुख infrastructure expansion के रूप में देखा जा रहा है
  • यह मौजूदा single-GPU-केंद्रित training paradigm से आगे बढ़ते हुए, हजारों GPU का उपयोग करने वाले ultra-large model training की नींव प्रदान करता है
  • शोधकर्ताओं और कंपनियों, दोनों के लिए यह scalability और efficiency को साथ में सुनिश्चित करने वाला standardized distributed training solution बन सकता है
• PyTorch टीम ने Monarch को open source के रूप में जारी किया है और community feedback को शामिल करते हुए इसे लगातार विकसित करने की योजना बनाई है
  • आगे चलकर इसमें automatic optimization, dynamic scheduling, hybrid parallelization जैसी सुविधाएँ जोड़ी जाएँगी
  • PyTorch के अगली पीढ़ी के distributed training framework के रूप में, इससे AI infrastructure के लोकतंत्रीकरण और accessibility में सुधार की उम्मीद है

[GN⁺]

Hacker News की राय

• लगता है कि यह प्रोजेक्ट Tinker से अलग लेयर को टार्गेट करता है
  Tinker परिचय लेख को देखें तो Tinker एक managed fine-tuning service है, जबकि Monarch infra primitive देने वाली संरचना है
  इसलिए यह जानने की जिज्ञासा है कि क्या Monarch के ऊपर Tinker जैसी service बनाई जा सकती है

  • अभी TorchForge जैसी चीज़ें उसके ऊपर चल रही हैं

• लगता है PyTorch की oxidation शुरू हो गई है
  Monarch, Python-आधारित frontend और Rust में implement किए गए backend में बंटा हुआ है
  कुल मिलाकर यह काफ़ी दिलचस्प प्रोजेक्ट लगता है

  • कई स्रोतों के मुताबिक Monarch, PyTorch का experimental framework है, replacement नहीं
    यानी अब भी std::shared_ptr-आधारित cyclic graph और memory leak का आनंद लिया जा सकेगा
    अफ़सोस है कि इसे किसी functional language में पूरी तरह से नया लिखकर नहीं बनाया गया
  • यह किसी मौजूदा प्रोजेक्ट का oxidized version नहीं, बल्कि पूरी तरह नया प्रोजेक्ट लगता है

• मैंने खुद PyTorch extension बनाया है — mycelya-torch
  मेरा version अभी inter-node communication support नहीं करता, लेकिन Monarch जिस तरह performance हासिल करता है वह दिलचस्प लगा
  Monarch शायद cloudpickle का इस्तेमाल करके code को सभी nodes में share करता है, जिससे सिर्फ शुरुआती setup cost लगती है और यह काफ़ी efficient है
  एक single controller से messages को fan-out करने वाली संरचना भी प्रभावशाली लगी
  लेकिन custom kernel support है या नहीं, और actors के बीच communication control कितना granular है, यह जानना चाहूँगा
  कुल मिलाकर मुझे multi-controller की तुलना में यह approach ज़्यादा पसंद है

  • custom kernel इस्तेमाल करने के लिए remote worker initialization code में थोड़ा बदलाव करना पड़ सकता है
    लेकिन ज़रूरी kernel या system code को सीधे bake-in भी किया जा सकता है

• यह Ray जैसी संरचना लगती है

  • code example Ray से लगभग एक जैसा है
    Monarch का Actor और Ray का @ray.remote class वही pattern follow करते हैं
  • सोच रहा हूँ कि Ray की जगह Monarch क्यों इस्तेमाल किया जाए — शायद PyTorch या tensor abstraction के साथ ज़्यादा tight integration की वजह से?
  • Dask भी इसी तरह का distributed processing करता है, लेकिन वह मूल रूप से HPC के लिए था, इसलिए GPU support सीमित है
    Dask की आधिकारिक साइट देखें
  • मैंने भी यही सोचा था। खासकर PyTorch और Ray की हाल की collaboration announcement देखकर यह और भी लगा
    संबंधित ब्लॉग

• दिलचस्प है, यह मूल रूप से Fortran coarray(2008) की अवधारणा याद दिलाता है

  • या फिर Hadoop(2006) जैसा भी लगता है
    बस फ़र्क यह है कि MapReduce या Fortran को सीधे इस्तेमाल नहीं करना पड़ता, इसलिए यह काफ़ी बेहतर लगता है

• एक पंक्ति थी: “single host bottleneck से बचने और message passing के लिए distributed cluster में पूरे mesh का उपयोग करता है”,
  अगर कोई इसे edit कर सकता हो तो अच्छा होगा कि reference numbers भी जोड़ दे

• यह अच्छा प्रोजेक्ट लगता है
  मेरे कुछ सवाल हैं

  • क्या यह openMPI जैसा है?
  • mesh कैसे बनता है? क्या यह सिर्फ एक ही host के अंदर संभव है?

• यह coarray world में महत्वपूर्ण प्रोजेक्ट बन सकता है, लेकिन समस्या के संकेत अभी से दिख रहे हैं
  tensor engine CUDA और RDMA(ibverbs) से बंधा हुआ है, और GPUDirect RDMA इस्तेमाल करने वाला code है
  आखिरकार इससे CUDA dependency और बढ़ती दिखती है
  OpenUCX इस्तेमाल किया गया होता तो शायद बेहतर होता

• यह Jax की तुलना में functionally weaker लगता है
  Jax एक शक्तिशाली compiler से inter-node communication को optimize करता है

  • लेकिन Monarch का फ़ोकस single-controller paradigm पर है, जबकि Jax multi-controller SPMD संरचना है
    single controller को समझना आसान है, और multi-controller कुछ खास dataflow के लिए ज़्यादा optimized होता है
    इन दोनों approaches को मिलाने वाली कुछ दिलचस्प कोशिशें भी हैं