एजेंटिक AI को बुद्धिमत्ता की नहीं, उससे पहले बुनियादी ढाँचे की दीवार से टकराना होगा

मॉडल हमारी उस क्षमता से तेज़ी से बेहतर हो रहे हैं, जिससे हम उन्हें सौंपे जा रहे काम पूरे करवा सकते हैं।

AI एजेंटों की दिशा को लेकर ज़्यादातर बहस उनकी क्षमताओं पर केंद्रित है। क्या मॉडल भरोसेमंद ढंग से योजना बना सकता है? क्या वह अपनी गलतियों से उबर सकता है? क्या उसे ऐसे काम सौंपे जा सकते हैं जिनके नतीजे मायने रखते हों?

ये वाकई अहम सवाल हैं। लेकिन अगले कुछ वर्षों में बड़े पैमाने पर एजेंटों की तैनाती होगी या नहीं, यह इन सवालों से तय नहीं होगा—क्योंकि एक और तात्कालिक बाधा सामने है, और वह उम्मीद से तेज़ी से आ रही है। एजेंटों को सेवा देना आर्थिक रूप से कठिन है, और यही कठिनाई उन क्षमताओं के साथ बढ़ती जाती है जिन्हें हर कोई जोड़ना चाहता है।

चैटबॉट और एजेंट अलग-अलग तरह के कार्यभार हैं

बातचीत के लिए भेजा गया अनुरोध एक चक्र में पूरा होता है: प्रॉम्प्ट भेजें, टोकन पाएँ और कनेक्शन बंद करें। आप ऐसे अनुरोधों को बैच में चला सकते हैं, प्रॉम्प्ट के शुरुआती हिस्से को कैश कर सकते हैं और थ्रूपुट का अनुमान एक ही संख्या से लगा सकते हैं।

एजेंट का अनुरोध एक पूरा सत्र होता है। वह किसी टूल को कॉल करता है, इंतज़ार करता है, नतीजा पढ़ता है, तय करता है कि आगे क्या करना है, फिर किसी दूसरे टूल को कॉल करता है और आखिर में जवाब देता है। एक साधारण-से काम में भी मॉडल को छह या आठ बार चलाना पड़ सकता है, और हर बार के बीच इंतज़ार करना पड़ता है।

यह अंतर बुद्धिमत्ता से बिल्कुल अलग वजह से मायने रखता है। अलग-अलग चरणों के बीच एजेंट अपनी स्थिति संभाले रखता है—बातचीत, टूल से मिले नतीजे और अब तक का तर्क-विचार। मॉडल को सेवा देने के दौरान यह स्थिति GPU मेमोरी में KV कैश के रूप में रहती है और पूरे सत्र के दौरान मेमोरी घेरती है—उन सेकंडों में भी, जब एजेंट किसी ऐसे API के जवाब का इंतज़ार कर रहा होता है जो आपका नहीं है।

इसलिए क्षमता की इकाई अब “प्रति सेकंड अनुरोध” नहीं, बल्कि “मेमोरी में एक साथ सक्रिय सत्र” बन जाती है। जिस सिस्टम पर एक सेकंड में एक हज़ार बातचीत-संबंधी अनुरोध आसानी से पूरे हो सकते थे, वही हार्डवेयर अब एक साथ चल रहे एजेंटों के कुछ दर्जन सत्र ही संभाल सकता है।

इंतज़ार ही सबसे महँगा हिस्सा है

यहाँ एक असहज सच्चाई है। टूल कॉल के दौरान एजेंट कुछ नहीं कर रहा होता। कोई टोकन नहीं बन रहा होता और कोई कंप्यूट क्षमता इस्तेमाल नहीं हो रही होती। फिर भी GPU मेमोरी घिरी रहती है, क्योंकि उस संदर्भ को हटाकर दोबारा तैयार करने की लागत उसे बनाए रखने से ज़्यादा होती है।

आपका सबसे महँगा हार्डवेयर ऐसे अनुरोध के लिए आरक्षित रहता है जो उस समय डेटाबेस क्वेरी के जवाब का इंतज़ार कर रहा होता है।

पारंपरिक वितरित प्रणालियों में हमने इस समस्या का हल बहुत पहले निकाल लिया था—संसाधन छोड़ दीजिए और जवाब आते ही काम फिर शुरू कर दीजिए। मॉडल को सेवा देने में ऐसा करने के लिए KV कैश को होस्ट मेमोरी या डिस्क में भेजकर बाद में वापस लाना पड़ता है। इस डेटा-हस्तांतरण की लागत इतनी अधिक है कि ज़्यादातर सिस्टम ऐसा करने की जहमत नहीं उठाते। ठीक इसी समस्या पर सक्रिय रूप से शोध हो रहा है, क्योंकि इसे हल करना महँगा पड़ता है।

क्रमिक निष्पादन से समस्या और बढ़ जाती है

लगभग हर एजेंट फ्रेमवर्क में टूल कॉल एक के बाद एक किए जाते हैं। मॉडल मौसम की जानकारी माँगता है, वह मिलती है; फिर कैलेंडर जाँचने को कहता है, वह पूरी होती है; फिर उड़ान खोजने को कहता है, और वह जानकारी मिलती है।

अक्सर इन तीनों कॉल का एक-दूसरे पर कोई निर्भरता नहीं होती। इन्हें एक ही समय पर चलाया जा सकता था। एक के बाद एक चलाने पर कुल विलंब तीनों के समय का जोड़ होता है। साथ-साथ चलाने पर यह सबसे अधिक समय लेने वाली कॉल के बराबर होता है।

यह एजेंटों के बारे में कोई नई खोज नहीं है—यही संरचनात्मक बात किसी भी ऐसी प्रणाली पर लागू होती है जो एक ही विलंबता-बजट के भीतर कई मॉडल या सेवाएँ चलाती है। कुल विलंबता निर्भरता-ग्राफ के सबसे लंबे रास्ते के बराबर होनी चाहिए, न कि हर चरण के समय के जोड़ के। एजेंटों के मामले में यह बात इसलिए ज़्यादा मायने रखती है कि पूरे सत्र के दौरान GPU मेमोरी इस्तेमाल होती रहती है। इसलिए वास्तविक समय घटाने से सिर्फ़ उपयोगकर्ता का अनुभव बेहतर नहीं होता, बल्कि उसी हार्डवेयर पर एक साथ चलाए जा सकने वाले सत्रों की संख्या भी सीधे बढ़ती है।

सत्र की अवधि आधी कर दें, तो उन्हीं GPU पर एक साथ चलने की क्षमता लगभग दोगुनी हो जाती है—और मॉडल में कोई बदलाव किए बिना।

रीट्राई ऐसे जुड़ते जाते हैं, जैसा किसी ने सोचा ही नहीं था

एजेंट फ्रेमवर्क अपने नीचे इस्तेमाल होने वाली HTTP लाइब्रेरी की रीट्राई सेटिंग्स अपना लेते हैं। आम तौर पर तीन कोशिशें।

मॉडल भी अपने तरीके से फिर कोशिश करता है। जब किसी टूल से अनुपयोगी नतीजा मिलता है, तो तर्क करने वाला मॉडल अक्सर कोई दूसरा तरीका आज़माता है—यह भी रीट्राई ही है, बस इसे किसी ने कॉन्फ़िगर नहीं किया होता।

इन दोनों को जोड़ दें, तो तीन कोशिशों की नीति के साथ ऐसा मॉडल, जो अपने तर्क से स्वतंत्र रूप से तीन और तरीके आज़माता है, कुल नौ कोशिशों की नीति बना देता है—जिसे किसी ने लिखकर तय नहीं किया। इनमें से हर कोशिश मॉडल को पूरी तरह चलाने के बराबर है और हर बार अपने टोकन तथा GPU पर खर्च होने वाले सेकंड लगते हैं।

जब कोई निर्भर सेवा धीमी पड़ती है, तो यही बढ़ोतरी मामूली गिरावट को सेवा-बाधा में बदल देती है। और हर कोशिश की लागत दोबारा किए गए REST कॉल से कई गुना ज़्यादा होती है।

यह बाधा असल में कैसी दिखती है

यह क्षमता की सीमा नहीं है। समस्या कहीं अधिक साधारण है: इकाई-अर्थशास्त्र की ऐसी अड़चन, जो परियोजनाओं को पायलट से उत्पादन तक पहुँचने से रोक देती है।

पायलट सफल रहता है। उपयोगकर्ता दस हैं, विलंबता स्वीकार्य है और बिल कुल खर्च के सामने मामूली है। फिर कोई दस हज़ार उपयोगकर्ताओं के लिए हिसाब लगाता है और GPU की ज़रूरत अव्यावहारिक लगती है—मॉडल धीमा होने के कारण नहीं, बल्कि इसलिए कि एक साथ चल रहे हर सत्र की पूरी अवधि में मेमोरी घिरी रहती है, और इस अवधि में इंतज़ार का समय भी शामिल है।

यही वह चरण है जहाँ कई आशाजनक आंतरिक डेमो चुपचाप आगे बढ़ना बंद कर देते हैं।

इस अवरोध को कौन हटाता है

इसमें कुछ भी असाधारण नहीं है, और ये सभी मॉडलिंग के बजाय इन्फ्रास्ट्रक्चर से जुड़ी बातें हैं:

स्वतंत्र टूल कॉल्स को एक साथ निष्पादित करें। आज उपलब्ध सबसे बड़ा एकल लाभ, जिसके लिए किसी नए हार्डवेयर की ज़रूरत नहीं है।

सत्र की अवधि को क्षमता का मापदंड मानें। प्रति सेकंड टोकन की संख्या नहीं। GPU का उपयोग नहीं। बल्कि यह कि स्थिति कितनी देर तक मेमोरी में बनी रहती है और कितने सत्र एक साथ समा सकते हैं।

पुनः प्रयासों की सीमा हर कॉल के लिए अलग-अलग तय करने के बजाय पूरे सिस्टम के लिए तय करें। एक वैश्विक सीमा—जिसमें पुनः प्रयास कुल ट्रैफ़िक का एक छोटा प्रतिशत हों—ऊपर बताए गए बढ़ते प्रभाव को रोकती है। Google की SRE पद्धति में अत्यधिक लोड से निपटने और Envoy के पुनः प्रयासों की सीमा में, AI स्टैक के बाहर, इसी विचार को लागू किया गया है।

तर्क-विचार को निष्पादन से अलग रखें। योजना बनाने के लिए एक बड़ा मॉडल और यांत्रिक चरणों के लिए इससे कहीं छोटा मॉडल इस्तेमाल करें। एजेंट जो कुछ करता है, उसके अधिकांश काम के लिए अत्याधुनिक मॉडल की ज़रूरत नहीं होती।

संदर्भ हटाने की लागत कम रखें। क्वांटाइज़्ड KV कैश, पृष्ठ-आधारित अटेंशन और निष्क्रिय सत्रों के लिए ऑफ़लोड के रास्ते। इस समय सर्विंग के क्षेत्र में सबसे दिलचस्प काम यहीं हो रहा है।

मॉडल लगातार बेहतर होते रहेंगे। इस बात पर भरोसा किया जा सकता है। एजेंट इन्फ्रास्ट्रक्चर बनेंगे या डेमो तक ही सीमित रहेंगे, यह एक कम चमकदार सवाल पर निर्भर करता है—क्या हम ऐसे वर्कलोड को संभाल सकते हैं जो प्रतीक्षा के दौरान महँगी मेमोरी घेरता है, और क्या हम क्रमिक चरणों की कुल अवधि के बजाय उनके सबसे लंबे पथ जितनी अवधि का ही भुगतान करना शुरू कर सकते हैं।

मैंने उस अंतिम बिंदु के पीछे के निष्पादन मॉडल को प्रकाशित किया है—एक ही विलंबता बजट के भीतर परस्पर निर्भर मॉडल कॉल्स का समवर्ती निष्पादन—“मशीन लर्निंग सिस्टम में मॉडल रूटिंग के लिए अतुल्यकालिक अनुमान ग्राफ़ निष्पादन”, International Journal of Computer Trends and Technology 72(10), अक्टूबर 2024 में। विशेष रूप से विलंबता-सीमित निर्णय प्रणालियों में जनरेटिव मॉडल के एकीकरण पर, “LLM-संवर्धित ट्रेडिंग और निर्णय मंच: जनरेटिव इंटेलिजेंस को वित्तीय निर्णय प्रणालियों से जोड़ना”, Journal of Information Systems Engineering and Management 11(1s), 2026 देखें।