पूर्वनिर्धारित कैश सेवा रेडिक्स ध्यान और KV पुनः उपयोग
Type: Learn
Languages: Python (stdlib, toy radix-tree cache + cache-aware scheduler)
Prerequisites: Phase 17 · 04 (Serving Engine Internals), Phase 14 (Agentic RAG)
Time: ~75 minutes
सीखने के लक्ष्य
- रेखाचित्र रेडिक्स ध्यानः कैसे पूर्वनिर्धारित एक रेडिक्स पेड़ में संग्रहीत कर रहे हैं और कैसे KV ब्लॉक एक ही शाखा में जड़ वाले अनुक्रमों के बीच साझा कर रहे हैं।
- कैश-जाहिर शेड्यूलिंग और क्यों FCFS पूर्वनिर्धारित भारी यातायात के लिए गलत है समझाएं।
- पूर्वनिर्धारित कैश हिट दर और शीघ्र लंबाई वितरण के अनुसार कार्यभार के लिए अपेक्षित गति गणना करें।
- 6.4x संख्या वास्तविक बनाम एक खोई हुई अपसाइड बनाने के लिए शीघ्र आदेश अनुशासन का नाम दें।
समस्या
क्लासिक सेवा प्रत्येक अनुरोध के संकेत को अस्पष्ट मानती है। यहां तक कि जब 5,000 आरएजी अनुरोध सभी एक ही 2,000 टोकन सिस्टम संकेत के साथ शुरू होते हैं और एक ही पुनर्प्राप्ति प्रस्तावना के साथ, वीएलएलएम 2,000 टोकन उपसर्ग को 5,000 बार पूर्वपूर्ति करता है। GPU एक ही काम बार-बार करता है।
अवलोकनः एजेंटीक और आरएजी वर्कलोड में प्रॉम्प्ट लगभग हमेशा लंबे प्रीफिक्स साझा करते हैं। सिस्टम प्रॉम्प्ट, टूल स्कीम, कुछ शॉट उदाहरण, पुनर्प्राप्ति हेडर, वार्तालाप इतिहास सभी अनुरोधों के बीच दोहराएं। यदि आपने उस प्रीफिक्स के लिए केवी कैश को एक बार संग्रहीत किया और इसका पुनः उपयोग किया, तो आप इसे फिर से प्रीफिल नहीं करेंगे।
रेडिक्सएटेंशन ठीक यही करता है। टोकन एक रेडिक्स पेड़ में अनुक्रमित किए जाते हैं; प्रत्येक नोड के पास रूट से अपने पथ पर टोकन अनुक्रम के लिए केवी ब्लॉक होते हैं। एक नया अनुरोध पेड़ पर चलता हैः कोई भी नोड जिसका टोकन मेल खाता है, उस नोड के केवी ब्लॉक का पुनः उपयोग करता है। प्रीफिल लागत "नए" प्रत्यय के समान हो जाती है, न कि पूर्ण प्रॉम्प्ट।
चुनौती शेड्यूलिंग है। यदि दो अनुरोध एक 2,000 टोकन प्रीफिक्स साझा करते हैं और एक तीसरा एक ही प्रीफिक्स के केवल 200 टोकन साझा करता है, तो आप दो लंबे समय तक साझा किए गए अनुरोधों को एक साथ सेवा देना चाहते हैं ताकि लंबे प्रीफिक्स एचबीएम में बने रहे। एफसीएफएस विपरीत करता है यह पहले आने वाले किसी को भी सेवा देता है, संभावित रूप से अगले लंबे प्रीफिक्स अनुरोध से पहले हॉट शाखा को निकाल देता है।
अवधारणा
KV सूचकांक के रूप में रेडिक्स पेड़
एक रेडिक्स पेड़ (कॉम्पैक्ट ट्राई) टोकन अनुक्रमों को संग्रहीत करता है। प्रत्येक नोड में एक टोकन रेंज है और उस रेंज के लिए गणना की गई KV ब्लॉक हैं। बच्चे अनुक्रम को एक या अधिक टोकन तक बढ़ाते हैं।
root
|- "You are a helpful assistant..." (2,000 tokens, 124 KV blocks)
|- "Context: <doc A>..." (500 tokens, 31 blocks)
|- "Question: Alice..." (80 tokens, 5 blocks)
|- "Question: Bob..." (95 tokens, 6 blocks)
|- "Context: <doc B>..." (520 tokens, 33 blocks)एक नया अनुरोध सिस्टम प्रॉम्प्ट + "सामग्रीः <doc A>" + "प्रश्नः कैरोल" के साथ आता है। शेड्यूलर चलता हैः सिस्टम प्रीफिक्स मैच (124 ब्लॉक पुनः उपयोग), डॉक-ए शाखा मैच (31 ब्लॉक पुनः उपयोग), फिर केवल "प्रश्नः कैरोल" (4 ब्लॉक) के लिए नए ब्लॉक आवंटित करता है। प्रीफिल लागतः 4 नए टोकन के ब्लॉक। पेड़ के बिनाः 160 ब्लॉक। ~40x प्रीफिल पर बचत।
कैश-जाहिर शेड्यूलिंग
रेडिक्स ट्री समर्थित पुनर्नवीनीकरण बेकार है यदि कैश चक्कर. दो प्रमुख नीतिः
- Depth-first dispatch. कतार से अगले अनुरोध को चुनते समय, वर्तमान चल रहे सेट के समान शाखा पर रूट किए गए अनुरोधों को प्राथमिकता दें. यह गर्म शाखा को चिपकाकर रखता है.
- LRU at branch level, not block level. व्यक्तिगत ब्लॉक की बजाय पूरे शाखाओं (सबसे कम इस्तेमाल किए जाने वाले पत्तों से शुरू) को हटा दें, ताकि कैश का आकार रेडिक्स के आकार से मेल खाए।
एफसीएफएस दोनों का उल्लंघन करता है. 2,000 टोकन साझा करने के अनुरोध 50 साझा करने के अनुरोध के पीछे है, फिर 2,000 टोकन शाखा को 50 टोकन को स्वीकार करने के लिए बाहर निकाला जाता है।
बेंचमार्क संख्याएं जिन्हें आपको याद रखना चाहिए
- Llama 3.1 8B, H100, ShareGPT 1K संकेतः SGLang ~ 16,200 tok/s vs vLLM ~ 12,500 (~ 29% बढ़त) ।
- पूर्वनिर्धारित भारी आरएजी (एक ही प्रणाली + एक ही दस्तावेज़, अलग-अलग प्रश्न): एसजीएलएंग पर 6.4x तक।
- आवाज क्लोनिंग कार्यभारः 86.4% प्रीफिक्स-कैश हिट दर।
- एसजीएलएंग ग्राहकों में उत्पादन की दरें बढ़ीः शीघ्र अनुशासन के आधार पर 50-99%।
- 2026 में 400,000+ GPU पर तैनात किया जाएगा।
आदेश आप मिल गया
6.4x संख्या लगातार प्रॉम्प्ट-टेम्पलेट आदेश पर निर्भर करता है. यदि आपके ग्राहक के रूप में प्रॉम्प्ट निर्माण करता है[system, tools, context, history, question]कुछ अनुरोधों में और [system, context, tools, history, question]एक मानव के लिए एक साझा पूर्वावलोकन की तरह दिखता है कि दो अलग-अलग अनुक्रमों को एक रूख के लिए है।
इंजीनियर का लीवरः आपका प्रॉम्प्ट टेम्पलेट एक कैश कुंजी है। क्रम को ठीक करें। सब कुछ अपरिवर्तनीय (सिस्टम, उपकरण, योजनाएं) पहले रखें। आगे पुनर्प्राप्ति संदर्भ रखें। अंतिम उपयोगकर्ता प्रश्न रखें। पूर्ववर्ती में गतिशील सामग्री को नहीं छोड़ें।
अनुसंधान से वास्तविक मामलाः कैश करने योग्य पूर्वावलोकन से गतिशील सामग्री को स्थानांतरित करने में एक परिवर्तन में 7% से 74% कैश हिट दर तक एक तैनाती हुई।
जहां रेडिक्सएटेंशन जीतता है और हारता है
जीत:
- आरएजी (एक ही पुनर्प्राप्ति प्रस्तावना, भिन्न प्रश्न) ।
- एजेंट (एक ही उपकरण योजनाएं, भिन्न प्रश्न) ।
- लंबे सिस्टम शीघ्र के साथ चैट करें।
- दोहराए गए प्रस्तावनाओं के साथ आवाज/दृष्टि कार्यभार।
हानि (vLLM स्तर पर पारगमन पर लौटता हैः
- अद्वितीय संकेतों के साथ एकल-शॉट पीढ़ी (कोड पूरा करना, सिस्टम संकेत के बिना खुला चैट) ।
- गतिशील संकेत जहां प्रत्येक अनुरोध अभूतपूर्व सामग्री को पूर्वावलोकन में पार करता है।
यह एक शेड्यूलर समस्या क्यों है, न कि सिर्फ एक कर्नेल समस्या
आप KV को एक कर्नेल ट्रिक के रूप में पुनः उपयोग लागू कर सकते हैं। SGLang का अंतर्दृष्टि यह है कि पुनः उपयोग केवल तभी भुगतान करता है जब शेड्यूलर गर्म शाखा निवासी रखता है। एक साफ़ "पुनः उपयोग यदि उपलब्ध है" नीति मिश्रित भार के तहत कैश को चक्कर देगी। रेडिक्स-ट्री इंडेक्टेड शेड्यूलर वह है जो कर्नेल ट्रिक को 29% उत्पादन किनारे में बदल देता है।
vLLM के साथ बातचीत
2026 में vLLM ने प्रीफिक्स कैशिंग (--enable-prefix-caching) और एक कैश-जागरूक राउटर (vLLM राउटर में जंग) । अंतर बंद हुआ लेकिन पूरी तरह से गायब नहीं हुआ SGLang का पूरा स्टैक रेडिक्स-पहला है; vLLM ने इसे प्रत्यारोपित किया। पूर्वावधान के पुनः उपयोग द्वारा हावी कार्यभार के लिए, SGLang डिफ़ॉल्ट रूप से बनी हुई है। मजबूत पूर्वावधान पैटर्न के बिना सामान्य-उद्देश्य सेवा के लिए, vLLM बराबर या बेहतर बनी हुई है।
इसका प्रयोग करें
code/main.pyएक खिलौना रेडिक्स-tree KV कैश प्लस एक शेड्यूलर दो नीतियों के साथ लागू करता हैः FCFS और कैश-जाहिर। दोनों के माध्यम से एक ही कार्यभार चलाता है, प्रीफिक्स-कैश हिट दर और आउटपुट डेल्टा रिपोर्ट करता है। फिर 6.4x कोलप दिखाने के लिए एक "स्क्रंबल ऑर्डरिंग" कार्यभार चलाता है।
इसे भेजें
यह सबक हमें फल देता हैoutputs/skill-radix-scheduler-advisor.md. कार्यभार विवरण (प्रॉम्प्ट-टेम्पलेट का आकार, रिट्रीव पैटर्न, समवर्ती किरायेदारों की संख्या) को देखते हुए, यह एक शीघ्र आदेश रजिस्टर और SGLang को अपनाने के लिए एक गो/नो-गो का उत्पादन करता है।
व्यायाम
- दौड़ें
code/main.py. एक ही कार्यभार पर FCFS और कैश-जाहिर की तुलना करें. डेल्टा प्रीफिल बचत, डिकोड बचत या कतार देरी से कहां से आता है? - कार्यभार को संशोधित करें ताकि संकेत यादृच्छिक रूप से प्रतिस्थापन करें
[system, tools, context]फिर से चलें, दर पर क्या होगा? - Llama 3.1 8B पर एक रेडिक्स शाखा के रूप में 2,000 टोकन प्रणाली प्रॉम्प्ट निवासी को बनाए रखने की HBM लागत की गणना करें। बिना पूर्वावलोकन के पुनः उपयोग के 16 अनुक्रम बैच की लागत की तुलना करें।
- एसजीएलएंग रेडिक्सएटेंशन पेपर पढ़ें। तीन वाक्य में समझाएं कि पेड़ के आकार के एलआरयू निकासी का प्रीफिक्स-भारी भार के तहत ब्लॉक के आकार के एलआरयू से बेहतर क्यों है।
- एक ग्राहक केवल 8% कैश हिट दर रिपोर्ट करता है. तीन संभावित कारणों का नाम और आप प्रत्येक के लिए चलाने के लिए निदान.
प्रमुख शर्तें
| Term | What people say | What it actually means |
|---|---|---|
| RadixAttention | "the SGLang thing" | KV cache indexed as a radix tree so shared prefixes reuse blocks |
| Radix tree | "compact trie" | Tree where each node owns a token range and its KV blocks |
| Cache-aware scheduler | "hot-branch-first" | Scheduler that prefers requests sharing the resident branch |
| Prefix-cache hit rate | "how much of your prompt was free" | Fraction of prompt tokens served from reused KV blocks |
| FCFS | "first-come first-served" | Default scheduling that breaks prefix locality |
| Branch-level LRU | "evict the leaf" | Eviction policy matched to radix shape |
| Prompt template ordering | "the cache key" | The prompt's component order determines what the tree can share |
| System prompt pinning | "resident prefix" | Keep the immutable system portion pinned to avoid eviction thrash |
आगे पढ़ना
- SGLang GitHub स्रोत और दस्तावेज।
- SGLang documentation Radix ध्यान और समय सारिणी विवरण।
- SGLang paper — Efficiently Programming Large Language Models (arXiv:2312.07104) डिजाइन संदर्भ।
- LMSYS blog — SGLang with RadixAttention बेंचमार्क संख्या और शेड्यूलर तर्क।
- vLLM — Prefix Caching तुलना के लिए vLLM का स्वयं का रेडिक्स-जैसा कार्यान्वयन।
This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.
Browse the complete course catalog or open this lesson on GitHub.