PyTorch कॉन्फ़्रेंस में उत्पादन-स्तर के इन्फ़रेंस स्टैक के साथ llm-d 1.0 का शुभारंभ

llm-d परियोजना के योगदानकर्ताओं ने 20 अक्टूबर, 2026 को PyTorch Conference North America में llm-d 1.0 की घोषणा की। यह Kubernetes-आधारित वितरित इन्फ़रेंस सेवा स्टैक है, जैसा कि IBM Research की घोषणा में बताया गया। IBM ने कहा कि इस रिलीज़ के साथ llm-d अलग-अलग प्रदर्शन तकनीकों के प्रदर्शन तक सीमित नहीं रहेगा। इसका उद्देश्य संगठनों को मॉडल परिनियोजन अपने स्तर पर करने में मदद देना है, क्योंकि इन्फ़रेंस की लागत बढ़ रही है।

llm-d को इस तरह बनाया गया है कि किसी भी मॉडल के लिए, किसी भी एक्सेलरेटर पर और किसी भी क्लाउड में इन्फ़रेंस स्टैक तैनात किया जा सके। Red Hat, IBM और Google इस परियोजना के प्रमुख अनुरक्षक हैं और उन्होंने CoreWeave तथा NVIDIA के साथ मिलकर llm-d की सह-स्थापना की। AMD, Cisco, Hugging Face, Intel, Lambda और Mistral AI ने योगदानकर्ताओं के रूप में इसमें भाग लिया है। Cloud Native Computing Foundation (CNCF) llm-d को सैंडबॉक्स परियोजना के रूप में होस्ट करता है। IBM इसे उन संगठनों के लिए विक्रेता-निरपेक्ष विकल्प बताता है, जो उसकी भाषा में अग्रणी स्तर का इन्फ़रेंस प्रदर्शन चाहते हैं, लेकिन किसी एक मालिकाना मॉडल प्रदाता, क्लाउड या हार्डवेयर प्लेटफ़ॉर्म पर पूरी तरह निर्भर नहीं रहना चाहते।

IBM Research के विशिष्ट इंजीनियर और llm-d के सह-संस्थापक तथा प्रमुख अनुरक्षक Carlos Costa ने कहा कि संस्करण 1.0 llm-d को किसी अन्य महत्वपूर्ण सेवा की तरह चलाने के लिए आवश्यक परिपक्वता प्रदान करता है। उन्होंने स्थिर API, एक ही बुनियादी ढाँचे को साझा करने वाले और अलग-अलग प्राथमिकताओं के लिए प्रतिस्पर्धा करने वाले कई टेनेंट, तथा संचालन बाधित किए बिना किए जा सकने वाले अपग्रेड का उल्लेख किया।

संस्करण 1.0 में क्या नया है

परियोजना के v1.0.0 रिलीज़ नोट्स 20 अक्टूबर, 2026 को GitHub पर हस्ताक्षरित और सत्यापित टैग के साथ प्रकाशित हुए। उनकी प्रमुख विशेषता मल्टी-टेनेंट सेवा गुणवत्ता है: प्राथमिकता और निष्पक्षता को ध्यान में रखने वाला प्रवाह नियंत्रण, जिसमें नियंत्रित लोड शेडिंग भी शामिल है। इसमें प्रायिकता-आधारित अनुरोध-स्वीकर्ता, प्रोग्राम-जागरूक निष्पक्षता और टर्न-प्राथमिकता स्कोरिंग शामिल हैं। इनकी मदद से विलंबता-संवेदनशील अनुरोध और अचानक बढ़ने वाले एजेंट वर्कलोड एक ही संसाधन समूह साझा कर सकते हैं, और अत्यधिक भार के दौरान भी किसी एक को दूसरे की कीमत पर वंचित नहीं होना पड़ता। प्रवाह-नियंत्रण का कॉन्फ़िगरेशन एक ही flowControl फ़ील्ड के अंतर्गत समेकित किया गया है।

बिना किसी डाउनटाइम के संचालन के लिए, राउटर में हॉट स्टैंडबाय और सुरक्षित क्रमिक अपडेट के साथ उच्च उपलब्धता जोड़ी गई है। DisaggregatedSet कंट्रोलर प्रीफ़िल और डिकोड प्रतिकृतियों को एक तार्किक इकाई के रूप में प्रबंधित करता है। इसमें समन्वित रोलआउट, एक साथ किए जाने वाले अपग्रेड, Pod स्नैपशॉट के आधार पर निर्धारित तत्परता और मूल रूप से उपलब्ध रिविज़न रूटिंग शामिल हैं। राउटर कॉन्फ़िगरेशन API अब v1 स्तर पर पहुँच गया है, Responses API अब previous_response_id का समर्थन करता है, और विश्वसनीयता, प्रदर्शन तथा मापनीयता बेहतर करने के लिए एंडपॉइंट-चयनकर्ता के अनुरोध-पथ को मज़बूत किया गया है। DRA और DRANET के लिए टोपोलॉपी-जागरूक एक्सेलरेटर मार्गदर्शिका भी शामिल है।

एजेंट-जागरूक सेवा में session-state-producer प्लगइन और बदलती बातचीत के साथ ढलने वाली सत्र-आसक्ति जोड़ी गई है, ताकि कई टर्न वाली बातचीत अपने कैश किए गए संदर्भ के पास बनी रहे। टर्न-प्राथमिकता शेड्यूलिंग और Responses API की स्थिति एजेंटों को अलग-अलग टर्न में संदर्भ का फिर से उपयोग करने में मदद करती है। इस रिलीज़ में परियोजना के सभी घटकों को v1.0.0 पर एकरूप किया गया है और इकोसिस्टम के कुछ हिस्से भी जोड़े गए हैं। इनमें मॉडल वेट को पीयर-टू-पीयर लोड करने के लिए ai-dynamo/modelexpress के साथ एकीकरण, llm-d-api-extensions पैकेज और llm-d-pd-utils डायग्नोस्टिक्स टूलिंग शामिल हैं। साथ ही, परियोजना के अपने llm-d-rocm कंटेनर इमेज बिल्ड अब अप्रचलित घोषित किए गए हैं। मॉडल-सर्वर इमेज में विभिन्न एक्सेलरेटर लक्ष्यों के लिए vLLM और SGLang बिल्ड शामिल हैं। प्रीफ़िल/डिकोड पृथक्करण मार्गदर्शिका के लिए अब LeaderWorkerSet v0.11.1 या उससे नया संस्करण, और DisaggregatedSet API का सक्षम होना आवश्यक है।

मुख्य तकनीकें और प्रवाह नियंत्रण

शुरुआत से ही परियोजना ने इन्फ़रेंस को बेहतर बनाने के पाँच तरीकों पर ध्यान दिया है: प्रीफ़िक्स-कैश-जागरूक रूटिंग, जो अनुरोध को ऐसे बुनियादी ढाँचे तक पहुँचाती है जहाँ उसका साझा संदर्भ पहले से मौजूद हो सकता है; KV-कैश ऑफ़लोडिंग, जो कैश की गई जानकारी को GPU, CPU और स्टोरेज संसाधनों के बीच ले जाती है; बैच इन्फ़रेंस का अनुकूलन; प्रीफ़िल/डिकोड पृथक्करण, जो प्रॉम्प्ट पढ़ने और जवाब तैयार करने की प्रक्रियाओं को अलग करता है; और व्यापक विशेषज्ञ समानांतरता, जो बड़े मिक्सचर-ऑफ़-एक्सपर्ट्स मॉडल को कई एक्सेलरेटरों में वितरित करती है। ये तकनीकें संस्करण 1.0 से पहले से मौजूद थीं। IBM के अनुसार, नया पहलू इनके इर्द-गिर्द किया गया एकीकरण और संचालनगत परिपक्वता है—यानी दूसरे दिन के संचालन का वह अनुशासन, जिसके तहत ट्रैफ़िक बदलने, हार्डवेयर ख़राब होने, सॉफ़्टवेयर अपडेट होने या अलग-अलग उपयोगकर्ताओं के एक ही संसाधनों के लिए प्रतिस्पर्धा करने पर भी प्रदर्शन बनाए रखा जाता है।

संस्करण 1.0 में प्रवाह नियंत्रण, निष्पक्षता और प्राथमिकता निर्धारण का उद्देश्य अचानक बढ़ने वाले वर्कलोड को विलंबता-संवेदनशील सेवाओं पर हावी होने से रोकना है—चाहे वर्कलोड एक ही हार्डवेयर साझा करें या अलग-अलग एक्सेलरेटरों के मेल पर चलें। कई टर्न में अनुरोधों को उपयुक्त बुनियादी ढाँचे से जोड़े रखा जा सकता है, ताकि प्रीफ़िक्स कैश सक्रिय बना रहे। llm-d, vLLM या SGLang जैसे इन्फ़रेंस इंजन के साथ काम करता है और उनके ऊपर वितरित रूटिंग तथा संचालन संबंधी क्षमताएँ जोड़ता है। Red Hat के मुख्य प्रौद्योगिकी अधिकारी के कार्यालय में उपाध्यक्ष Stephen Watt ने कहा कि llm-d, Kubernetes-आधारित ऑर्केस्ट्रेशन को सीधे vLLM और आधुनिक इन्फ़रेंस इंजनों तक पहुँचाकर PyTorch और CNCF इकोसिस्टम को एकजुट करता है।

प्रदर्शित परिणाम और बताई गई लागतें

22 जुलाई 2026 को प्रकाशित एक बेंचमार्क पोस्ट में, परियोजना ने GLM-5.2 की एजेंट-आधारित सर्विंग का मापन किया। पोस्ट में इसे 744 अरब पैरामीटर वाला मिक्सचर-ऑफ़-एक्सपर्ट्स मॉडल बताया गया है, जिसमें 39 अरब सक्रिय पैरामीटर और 78 लेयर हैं। वर्कलोड विश्लेषण 219 उत्पादन Claude Code सत्रों पर आधारित था। इनमें मुख्य एजेंट के अनुरोध में इनपुट के औसतन 195 हज़ार टोकन थे और जवाब में 317 आउटपुट टोकन मिले; साथ ही, मुख्य एजेंट के 96% चरणों में उनके कम-से-कम 90% इनपुट का दोबारा उपयोग हुआ। पोस्ट के अनुसार, प्रीफ़िक्स को ध्यान में रखकर की गई रूटिंग ने वर्कलोड में उपलब्ध कैश के दोबारा उपयोग का 96–97% हासिल किया। H200 के लिए प्रति GPU-घंटे $2.71 की अनुमानित किराया दर पर, पोस्ट में दो 64-GPU विन्यासों पर स्वयं होस्ट की गई सर्विंग की लागत प्रति दस लाख इनपुट टोकन $0.05 से $0.08 और प्रति दस लाख आउटपुट टोकन $1.92 से $3.55 बताई गई है। लेखकों के अनुसार, इन आंकड़ों में केवल GPU का किराया शामिल है और इनमें निरंतर लोड मानकर चला गया है।

एक अलग प्रदर्शन में, IBM और Red Hat ने GLM-5.2 को 544 NVIDIA H100 GPU पर तैनात किया। IBM Research के विवरण में इसे लगभग 753 अरब पैरामीटर वाला ओपन-वेट मॉडल बताया गया है, जिसमें करीब 39 अरब सक्रिय पैरामीटर हैं। IBM के मुताबिक, इस तैनाती ने चरम पर प्रति मिनट 66 लाख से अधिक आउटपुट टोकन दिए और बिना किसी प्रीएम्प्शन के एक साथ 3,000 तक कोडिंग एजेंटों को सेवा दी; वहीं, 2,500 एजेंटों के संचालन स्तर पर प्रति मिनट 7,612 अनुरोधों की दर बनी रही। IBM का कहना है कि मौजूदा क्लाउड किराया दरों पर, H100 GPU पर llm-d के साथ GLM-5.2 को स्वयं होस्ट करने की प्रति टोकन लागत समान वाणिज्यिक API मूल्य निर्धारण से 5 से 10 गुना कम है। Red Hat की इन्फ़रेंस इंजीनियरिंग टीम के वरिष्ठ प्रिंसिपल मशीन लर्निंग इंजीनियर Maroon Ayoub ने कहा, “एक साथ हज़ारों एजेंटों को बिना प्रीएम्प्शन के सेवा देना ऑपरेटरों को बेंचमार्क के नतीजे से उत्पादन में तैनाती तक पहुँचने का एक विश्वसनीय रास्ता देता है।”

उसी विवरण के अनुसार, इन नतीजों के पीछे काम कर रहे अलग-अलग घटकों वाले डेटा प्लेन ने 62 लाख KV-कैश ट्रांसफ़र पूरे किए। प्रति ट्रांसफ़र औसतन 2.71 GiB डेटा था और कोई भी ट्रांसफ़र विफल नहीं हुआ। सभी बेंचमार्क भी सर्विंग में बिना किसी त्रुटि के पूरे हुए।