KV-कैश के पुनः उपयोग से LLM इन्फ़रेंस की लागत घटाने के लिए Tensormesh ने प्लेटफ़ॉर्म लॉन्च किया

जब भी किसी AI सहायक को कोई लंबा दस्तावेज़ मिलता है, तो जवाब देना शुरू करने से पहले उसे उस सामग्री को संसाधित करना पड़ता है। वही दस्तावेज़, निर्देश या बातचीत का इतिहास दोबारा आने पर उस प्रक्रिया का बड़ा हिस्सा फिर से करना पड़ सकता है। उद्यम स्तर पर, इस दोहराव में GPU की महँगी क्षमता खर्च हो सकती है, जबकि कोई उपयोगी काम नहीं जुड़ता।

Tensormesh ने 14 अक्टूबर, 2026 को घोषित Tensormesh Platform के ज़रिए इस समस्या को हल करने का लक्ष्य रखा है। इस कंपनी की टीम ने ओपन-सोर्स LMCache प्रोजेक्ट बनाया था। अब कंपनी उन संगठनों के लिए की-वैल्यू कैशिंग (KV कैशिंग) की उद्यम-स्तरीय प्रबंधन परत ला रही है, जो अपने ही बुनियादी ढाँचे पर बड़े भाषा मॉडल उपलब्ध कराते हैं।

यह प्लेटफ़ॉर्म GPU मेमोरी, CPU मेमोरी और स्टोरेज में इन्फ़रेंस की ऐसी स्थिति का प्रबंधन करता है, जिसका दोबारा उपयोग किया जा सकता है। इसका उद्देश्य सीधा है: GPU समूह को बार-बार प्रॉम्प्ट संसाधित करने की ज़रूरत घटाना और साथ ही ऑपरेटरों को यह नियंत्रित करने के साधन देना कि कैश की गई स्थिति को कैसे रखा, साझा और मॉनिटर किया जाए।

KV-कैश क्यों अहम है

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

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

यह तैयार जवाब को कैश करने से अलग है। सिस्टम साझा संदर्भ से जुड़ी गणना का दोबारा उपयोग कर सकता है और फिर भी नए सवाल का नया जवाब तैयार कर सकता है।

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

उद्यमों के ग्राहकों के लिए अहम सवाल यह है कि उनके वास्तविक कार्यभार के कितने हिस्से में ऐसा संदर्भ है जिसका दोबारा उपयोग किया जा सकता है—और क्या उस संदर्भ को फिर से गणना करने के बजाय अधिक तेज़ी और कम लागत में वापस प्राप्त किया जा सकता है।

कैश को प्रबंधित बुनियादी ढाँचे में बदलना

Tensormesh की घोषणा में परिचालन की पाँच प्राथमिकताएँ बताई गई हैं: सुरक्षा, निगरानी-क्षमता, लचीलापन, नीतियों का प्रबंधन और बहु-किरायेदारी। ये साझा बुनियादी ढाँचे पर कैश किए गए डेटा की सुरक्षा, प्रदर्शन पर नज़र रखने, विफलताओं से उबरने, डेटा को कितने समय तक रखा जाए और कब हटाया जाए, यह नियंत्रित करने तथा टीमों या ग्राहकों को अलग-अलग रखने की व्यावहारिक ज़रूरतें पूरी करती हैं।

कंपनी कैश प्रविष्टियों को पिन करने, ढूँढ़ने, स्थानांतरित करने, संपीड़ित करने और मिटाने के लिए कंट्रोलर API का भी वर्णन करती है। इससे कैश के जीवनचक्र का प्रबंधन एक स्पष्ट परिचालन ज़िम्मेदारी बन जाता है, न कि ऐसा काम जिसे पूरी तरह अलग-अलग इन्फ़रेंस प्रक्रियाओं पर छोड़ दिया जाए।

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

उद्यमों के लिए बनाया गया यह प्लेटफ़ॉर्म इसी आधार पर तैयार किया गया है। इसकी इंस्टॉलेशन मार्गदर्शिका के अनुसार, Kubernetes ऑपरेटर कैश-इंजन के घटकों का प्रबंधन करता है। कैश सर्वर GPU नोड पर होते हैं, जबकि एक कोऑर्डिनेटर पूरे समूह के समन्वय का काम करता है। तैनाती के लिए Helm का उपयोग किया जाता है, जबकि वेब इंटरफ़ेस और कमांड-लाइन टूल संचालन में मदद करते हैं।

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

एक जैसे प्रॉम्प्ट प्रीफ़िक्स से आगे

जब दो प्रॉम्प्ट एक ही टोकन से शुरू होते हैं, तब प्रीफ़िक्स कैशिंग अच्छी तरह काम करती है। पुनर्प्राप्ति-संवर्धित जनरेशन (RAG) में यह अधिक कठिन हो सकता है: कोई ऐप्लिकेशन प्रासंगिक दस्तावेज़ तो प्राप्त कर लेता है, लेकिन वे अलग-अलग क्रम में या उनसे पहले के अलग-अलग पाठ के बाद आ सकते हैं।

एक ही दस्तावेज़ों का उपयोग करने वाले दो काल्पनिक अनुरोधों पर विचार करें। एक में दस्तावेज़ A के बाद B है, जबकि दूसरे में B के बाद A। दोनों में ऐसी सामग्री है जिसका दोबारा उपयोग किया जा सकता है, लेकिन उनकी शुरुआत का साझा हिस्सा छोटा हो सकता है।

Tensormesh प्रॉम्प्ट की शुरुआत से आगे भी पुनः उपयोग संभव बनाने के लिए CacheBlend का इस्तेमाल करता है। LMCache के दस्तावेज़ के अनुसार, यह कैश किए गए खंडों का पुनः उपयोग करते हुए टोकनों के एक हिस्से की चुनिंदा रूप से फिर से गणना करता है। यह दोबारा गणना इसलिए ज़रूरी है क्योंकि किसी खंड के आसपास का संदर्भ मॉडल की आंतरिक स्थिति को प्रभावित कर सकता है।

EuroSys 2025 में प्रस्तुत CacheBlend के शोधपत्र में, मूल्यांकित कार्यभारों में KV की पूरी पुनर्गणना की तुलना में, पहले टोकन तक पहुँचने का समय 2.2–3.3 गुना तेज़ और थ्रूपुट 2.8–5 गुना अधिक बताया गया है। लेखकों ने तीन ओपन-सोर्स मॉडल और चार बेंचमार्क डेटासेट का मूल्यांकन किया।

ये विशिष्ट परिस्थितियों में प्राप्त शोध-परिणाम हैं, Tensormesh के हर परिनियोजन में बचत की गारंटी नहीं। हालांकि, ये बताते हैं कि साझा प्रीफ़िक्स से आगे बढ़कर पुनः उपयोग करना तकनीकी रूप से दिलचस्प क्यों है: इससे ऐसी उपयोगी गणना दोबारा हासिल की जा सकती है जिसे पारंपरिक प्रीफ़िक्स मिलान पहचान नहीं पाता।

नोडों के बीच पुनः उपयोग और संस्करण-विशिष्ट समर्थन का महत्व

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

ये इन्फ़रेंस को व्यवस्थित करने के पूरक तरीके हैं। संगत स्थिति साझा करने से किसी दूसरे नोड पर उसकी दोबारा गणना करने की ज़रूरत नहीं पड़ती; वहीं, चरणों को अलग करने से इन्फ़्रास्ट्रक्चर टीमें संसाधनों का आवंटन उनकी प्रसंस्करण संबंधी मांगों के अनुसार अलग-अलग कर सकती हैं।

हालांकि, सार्वजनिक सामग्री में रिलीज़ की स्थिति को लेकर पूरी तरह एकरूपता नहीं है। लॉन्च का परिचय नोडों के बीच साझाकरण और चरणों को अलग करने का वर्णन करता है, जबकि 17 सितंबर की संस्करण-विशिष्ट संगतता मैट्रिक्स में पीयर-टू-पीयर स्थानांतरण और चरणों को अलग करना रोडमैप में शामिल हैं। फ़ीचर दस्तावेज़ों में पूर्वावलोकन वाले पृष्ठ भी हैं।

यही मैट्रिक्स उन फ़ीचरों में भी अंतर करता है जिनका Tensormesh ने अपने परीक्षणों में सत्यापन किया है और जिन्हें अपस्ट्रीम स्तर पर समर्थन तो प्राप्त है, लेकिन प्रोडक्शन में इस्तेमाल से पहले अतिरिक्त परीक्षण की आवश्यकता है। इसमें vLLM और NVIDIA Dynamo को सत्यापित सर्विंग इंजन के रूप में सूचीबद्ध किया गया है, जबकि SGLang और TensorRT-LLM रोडमैप में हैं।

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

लॉन्च का परिचय विशेष रूप से Kubernetes पर vLLM के साथ NVIDIA या ROCm के ज़रिए समर्थित AMD Instinct GPU और फ़ाइल-सिस्टम-आधारित स्टोरेज का वर्णन करता है। इसमें डेंस मॉडल के लिए प्रीफ़िक्स-आधारित न होने वाली कैशिंग और SGLang समर्थन को आगामी सुविधाओं के रूप में बताया गया है। यह भी स्पष्ट किया गया है कि कैश स्व-होस्ट किए गए मॉडलों के साथ चलता है; इसे किसी भी मनमाने होस्टेड-मॉडल API से जोड़ा जा सकने वाला ऐड-ऑन नहीं माना जाना चाहिए।

किन परिस्थितियों में यह किफ़ायती हो सकता है

सबसे उपयुक्त अनुप्रयोग वे हैं जो बार-बार पर्याप्त मात्रा में साझा संदर्भ का प्रसंस्करण करते हैं: आंतरिक ज्ञान सहायक, दस्तावेज़ विश्लेषण सेवाएँ और ऐसे एजेंट जो निर्देशों या संदर्भ सामग्री के किसी स्थिर समूह पर बार-बार काम करते हैं।

एक उपयोगी मूल्यांकन में प्रतिनिधि ट्रैफ़िक के आधार पर ठंडे और गर्म कैश के व्यवहार की तुलना की जाएगी। संचालकों को पहले टोकन तक का समय, थ्रूपुट, कैश से डेटा प्राप्त करने में लगने वाला समय, GPU उपयोग और स्थिति को बनाए रखने की मेमोरी, स्टोरेज तथा नेटवर्क लागत मापनी चाहिए।

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

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

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

बार-बार होने वाले काम को कम करने पर एक व्यावहारिक दांव

कंपनी की घोषणा के अनुसार, लॉन्च के साथ ही Tensormesh Platform उपलब्ध है। इसका महत्व इस बात में है कि यह इन्फ़रेंस की स्थिति को ऐसे संसाधन के रूप में देखता है जिसे पूरे सर्वर-बेड़े में प्रबंधित किया जा सकता है और जिसकी पुनः उपयोग योग्य गणना किसी अनुरोध की तत्काल अवधि बीत जाने के बाद भी सहेजकर रखी जा सकती है।

अपना LLM इन्फ़्रास्ट्रक्चर चलाने वाले उद्यमों के लिए यह दक्षता बढ़ाने का एक ठोस तरीका है: प्रॉम्प्ट के प्रसंस्करण में पहले ही किए जा चुके काम का अधिक पुनः उपयोग करना। नतीजा इस बात पर निर्भर करेगा कि वर्कलोड में दोहराव कितना है, कैश कितना संगत है और डेटा स्थानांतरित करने की लागत क्या है—लेकिन ये ऐसे इंजीनियरिंग सवाल हैं जिन्हें टीमें अपने ट्रैफ़िक के आधार पर मापकर परख सकती हैं।