A Policy-Driven Runtime Layer for Agentic LLM Serving
यह शोध पत्र एक नए आर्किटेक्चरल "एजेंट रनटाइम लेयर" का प्रस्ताव करता है जो पॉलिसी-संचालित अनुकूलन (policy-driven optimizations) को सक्षम करने के लिए मल्टी-एजेंट फ्रेमवर्क और एलएलएम (LLM) सर्विंग इंजन के बीच के अंतर को पाटता है, और कैशसेज (CacheSage) सिस्टम के माध्यम से यह प्रदर्शित करता है कि यह दृष्टिकोण विविध मल्टी-एजेंट वर्कलोड्स में कैश हिट रेट, टाइम-टू-फर्स्ट-टोकन और थ्रूपुट में महत्वपूर्ण सुधार करता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक व्यस्त, उच्च-स्तरीय (high-end) रेस्तरां चला रहे हैं।
वर्तमान सेटअप: संचार की विफलता (A Communication Breakdown)
अभी, आपके रेस्तरां में दो अलग-अलग परतें हैं जो आपस में ठीक से बात नहीं कर पाती हैं:
- मुख्य शेफ (एजेंट फ्रेमवर्क - The Agent Framework): यह व्यक्ति मेनू जानता है, वेटरों की भूमिकाओं को जानता है, और प्रत्येक टेबल के लिए विशिष्ट निर्देश जानता है। वह जानता है कि कौन क्या ऑर्डर कर रहा है और उन्हें क्या चाहिए। हालाँकि, वह कभी किचन का फर्श नहीं देखता; उसे यह नहीं पता होता कि वर्तमान में कितने बर्तन चूल्हे पर हैं या कौन सी सामग्री कम हो रही है।
- किचन स्टाफ (सर्विंग इंजन - The Serving Engine): यह टीम आने वाले हर एक ऑर्डर को देखती है। वे जानते हैं कि कितने बर्तन उबल रहे हैं और वे कितनी तेज़ी से खाना पका सकते हैं। लेकिन उन्हें यह नहीं पता होता कि ग्राहक कौन हैं या भोजन की "कहानी" क्या है। उनके लिए, हर ऑर्डर बस एक सामान्य अनुरोध है।
समस्या: "सीम" जहाँ चीजें टूट जाती हैं (The "Seam" Where Things Break)
क्योंकि ये दोनों समूह जानकारी साझा नहीं करते हैं, रेस्तरां अक्षम निर्णय लेता है।
- उदाहरण: मुख्य शेफ जानता है कि टेबल 4 हमेशा अपने मुख्य कोर्स से पहले एक ही ऐपेटाइज़र (appetizer) ऑर्डर करती है। लेकिन किचन स्टाफ को यह नहीं पता। इसलिए, हर बार जब टेबल 4 ऑर्डर करती है, तो किचन को प्याज काटने का काम फिर से शून्य से शुरू करना पड़ता है, भले ही उन्होंने पांच मिनट पहले उसी टेबल के लिए वही काम किया हो।
- पेपर इसे "सीम" (seam) कहता है। वर्तमान में, यदि आप इसे ठीक करना चाहते हैं, तो आपको मुख्य शेफ के नोट्स या किचन के वर्कफ़्लो को एक विशिष्ट, एक-बार के नियम (one-off rule) के साथ पैच करना होगा। यह अव्यवस्थित है और बड़े पैमाने पर लागू नहीं किया जा सकता (doesn't scale)।
समाधान: "एजेंट रनटाइम लेयर" (नया फ्लोर मैनेजर - The "Agent Runtime Layer")
लेखक शेफ और किचन के बीच एक तीसरी परत बनाने का प्रस्ताव देते हैं: एक फ्लोर मैनेजर।
इस फ्लोर मैनेजर का एक विशेष काम है। वे शेफ को सुनते हैं (यह जानने के लिए कि भूमिकाएं और पहचान क्या हैं) और किचन को देखते हैं (यह देखने के लिए कि खाना पकाने की घटनाएं क्या हैं)। वे इस संयुक्त ज्ञान का उपयोग करके चार सरल उपकरणों का उपयोग करके स्मार्ट निर्णय लेते हैं:
- ऑब्ज़र्व (Observe - देखना): "मैं देख रहा हूँ कि 'प्लानर' वेटर से एक नया ऑर्डर आ रहा है।"
- स्कोर (Score - अंक देना): "इतिहास के आधार पर, यह 'प्लानर' ऑर्डर बहुत महत्वपूर्ण है और इसके बाद 'कोडर' ऑर्डर आने की संभावना है। इसे उच्च प्राथमिकता दें।"
- प्रेडिक्ट (Predict - अनुमान लगाना): "मुझे यकीन है कि अगला ऑर्डर 'कोडर' वेटर से होगा। चलिए अब उनके लिए सामग्री तैयार कर लेते हैं।"
- एक्ट (Act - कार्य करना): "आगे बढ़ें और 'कोडर' के लिए चूल्हा पहले से गर्म कर दें ताकि कोई देरी न हो।"
यह फ्लोर मैनेजर एक सार्वभौमिक अनुवादक (universal translator) के रूप में कार्य करता है। कोई भी नया नियम (जैसे "सभी टेबल्स के साथ निष्पक्ष रहें" या "ऊर्जा बचाएं") इस मैनेजर में बिना शेफ या किचन को खराब किए जोड़ा जा सकता है।
केस स्टडी: "कैशसेज" (स्मार्ट पेंट्री - "CacheSage")
यह साबित करने के लिए कि यह काम करता है, लेखकों ने एक विशिष्ट फ्लोर मैनेजर बनाया जिसे "पेंट्री" (कंप्यूटर की मेमोरी, या KV कैश) को संभालने के लिए CacheSage कहा गया है।
- पुराना तरीका: किचन सामग्री (मेमोरी) को इस आधार पर फेंक देता है कि उनका उपयोग कब हुआ था। यदि "प्लानर" वेटर ब्रेक के बाद वापस आता है, तो किचन को सब कुछ फिर से काटना और तैयार करना पड़ता है क्योंकि सामग्री फेंक दी गई थी।
- CacheSage का तरीका: फ्लोर मैनेजर पैटर्न को सीखता है। वे देखते हैं कि "प्लानर" लगभग हमेशा "कोडर" की ओर ले जाता है।
- जब "प्लानर" समाप्त होता है, तो फ्लोर मैनेजर कहता है, "मैं भविष्यवाणी करता हूँ कि 'कोडर' अगला है।"
- वे "प्लानर" की सामग्री को सुरक्षित रखते हैं (ताकि उसे फेंका न जाए) और यहाँ तक कि "कोडर" के लिए उनकी सामग्री तैयार करना भी शुरू कर देते हैं, इससे पहले कि ऑर्डर वास्तव में आए।
परिणाम
जब उन्होंने इसे पांच अलग-अलग वास्तविक दुनिया के "रेस्तरां" परिदृश्यों (जटिल AI कार्यों) पर टेस्ट किया:
- कम बर्बादी: उन्होंने पहले की तुलना में 13% से 37% अधिक बार सही सामग्री को पेंट्री में सुरक्षित रखा।
- तेज़ सेवा: ग्राहकों को खाना 12% से 29% तेज़ी से मिला क्योंकि किचन को शून्य से शुरुआत नहीं करनी पड़ी।
- अधिक ग्राहक: रेस्तरां प्रति घंटा 6% से 14% अधिक टेबल की सेवा कर सका।
सारांश में
पेपर का तर्क है कि AI एजेंटों को कुशलतापूर्वक चलाने के लिए, हम केवल ऊपरी परत (लॉजिक) या निचली परत (हार्डवेयर) को बदलकर काम नहीं चला सकते। हमें एक समर्पित "मिडल मैनेजर" की आवश्यकता है जो एजेंटों की पहचान और इंजन की घटनाओं दोनों को समझता हो, और पूरे सिस्टम को स्मार्ट और तेज़ बनाने के लिए चार सरल नियमों का उपयोग करता हो।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।