Phase 17: Infrastructure & Production

خدمة الاحتفاظ بالخزنة المسبقة RadxAttention و KV Reuse

تعامل مخزن KV كمواد ذات مستوى أولى قابلة للاستعمال المخزنة في شجرة الجذور ، وتغييرات في الجدول مع ذلك: بدلاً من FCFS (أول من يأتي ، أول من يخدم) كجدولات vLLM ، يقوم مخطط ذا أهمية المخزن بتحديد الأولوية لطلبات مع مخططات مشتركة أطول بشكل فعال عبر الجذور الأول عمقًا حتى تبقى الفرع الساخنة مقيمًا في HBM. (سجلانغ) هو المحرك الذي بنيت حول هذه الفكرة. على Llama 3.1 8B مع إشارات 1K مثل ShareGPT، SGLang يصل ~ 16,200 tok / s إلى ~ 12,500 vLLM، حافة ~ 29٪. على عبء عمل RAG الثقيل من المواصلات، تصل الميزة إلى 6.4x. على حمولات العمل على شكل نسخ الصوتية، تمت إزالة معدل إضافة الكاش 86٪ تم نشرها على 400،000+ GPU في 2026 عبر xAI، LinkedIn، Cursor، Oracle، GCP، Azure، AWS. المشكلة هي أن الرقم 6.4x يتبخر عندما يكون التنظيم المسبق غير متسق

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

أهداف التعلم

الرسم البياني RadixAttention: كيف يتم تخزين المضافات في شجرة radix وكيف يتم تقاسم كتلة KV عبر تسلسلات متجذرة في نفس الفرع.
شرح جدولة الاحتفاظ بالخزنة والسبب في خطأ FCFS في حركة المرور الكثيفة.
احسب التسارع المتوقع لحمل العمل مع معدل ضربات الاحتفاظ بالمسجلات السابقة وتوزيع الطول السريع.
اسم التنظيم السريع الذي يجعل رقم 6.4x حقيقي مقابل صعود مفقود.

المشكلة

تعامل خدمة الكلاسيكية طلب كل طلب على أنه غير واضح. حتى عندما تبدأ 5,000 طلبات RAG مع نفس طلب نظام 2,000 رمز بالإضافة إلى نفس المبدأ الاستردادي، فإن vLLM يملأ هذا المقبل 2000 رمز 5000 مرة. تقوم GPU بنفس العمل مرارا وتكرارا.

الملاحظة: الإشعارات في أحمال العمل الوكالة والجيهارية تشارك إشعارات طويلة دائمًا تقريبًا. إشعار النظام، مخططات الأدوات، أمثلة القليل من اللقطات، عناوين الاسترداد، تاريخ المحادثات كل تكرار عبر الطلبات. إذا قمت بتخزين الاحتفاظ الكهربائي للفضلات مرة واحدة وإعادة استخدامه، فلن تقوم بتشغيله مرة أخرى.

تقوم RadixAttention بذلك بالضبط. يتم تحديد رموز في شجرة راديكس. كل عقد يملك كتلة KV لترتيب الرمز على مسارها من الجذر. يمر طلب جديد في الشجرة: أي عقد يطابق الرمز يستخدم مرة أخرى كتلة KV تلك العقدة. يصبح تكلفة الإعداد مساوية للفاصلة "الجديدة" ، وليس الإشارة الكاملة.

التحدي هو الجدول. إذا كانت طلبين يشتركان في إضافة 2000 رمز وحدة تحديد وتشارك ثالثة 200 رمز فقط من نفس الإضافة، فأنت تريد تقديم الطلبين المشتركين الطويل معا حتى يبقى الإضافة الطويلة في HBM. يقوم FCFS بالعكس فإنه يخدم من وصل أولا، وربما يطرد الفرع الساخن قبل أن يصل طلب إضافة الطويل التالي.

المفهوم

شجرة الجذور كمرجع 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 كتلة تستخدم مرة أخرى) ، تطابقات فرع doc-A (31 كتلة تستخدم مرة أخرى) ، ثم يخصص كتلة جديدة فقط لـ "سؤال: كارول" (4 كتلة). تكلفة إعداد مسبق: 4 كتلة من الرموز الجديدة. بدون الشجرة: 160 كتلة. ~40x توفير على إعداد مسبق.

التخطيط المعرف على الاحتفاظ بالخزنة

إعادة استخدام الأشجار المدعومة من "راديكس" لا فائدة منها إذا كان الاحتفاظ بالخزنة يزعج.

Depth-first dispatchعند اختيار الطلب التالي من الصف، تفضل طلبات متجذرة في نفس الفرع مع مجموعة تشغيل الحالية. هذا يبقى الفرع الساخن محصورة.
LRU at branch level, not block level. إزالة فروع كاملة (بدءا من أقصر الأوراق المستخدمة) بدلاً من كتلة فردية، بحيث تشكل الاحتفاظ بالتطابق مع شكل الجذور.

ويتم تخطي الاتحاد الفيدرالي للشؤون الثنائية، ويتم إعادة طلب مشاركة 2000 رمز وراء طلب مشاركة 50 رمز ثم يتم إخلاء فرع 2000 رمز للاعتراف بالشخصية الـ50 رمز

أرقام المقاييس التي يجب أن تتذكرها

Llama 3.1 8B، H100، ShareGPT 1K طلبات: SGLang ~ 16,200 tok/s مقابل vLLM ~ 12,500 (~ 29٪ حافة).
المواصلات المثقلة RAG (النظام نفسه + الوثيقة نفسها، سؤال مختلف): حتى 6.4x على SGLang.
عبء عمل النسخ الصوتية: 86.4% معدل النقاشات في الاحتفاظ بالمسجلات.
معدلات التصنيع في جميع أنحاء عملاء SGLang: 50-99% اعتمادا على الانضباط السريع.
يتم نشر على 400،000+ GPU في عام 2026.

لقد حصلت على طلبك

الرقم 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 Router in Rust). تم إغلاق الفجوة ولكنها لم تختفي تمامًا تعتبر كومة SGLang بأكملها من أشكال radix-first؛ تم زرعها على vLLM. بالنسبة لتحملات العمل التي تهيمن عليها إعادة استخدام الممثلة، تظل SGLang هي الافتراض الافتراضي. بالنسبة للخدمة العامة دون أنماط الممثلة القوية، تظل vLLM متساوية أو أفضل.

استخدمها

code/main.pyينفذ جهاز التخزين KV لعبة radix-tree بالإضافة إلى جهاز جدولة مع سياستين: FCFS و cache-aware. يعمل بنفس حمل العمل من خلال كليهما ، ويذكر معدل ضربات الاحتياطي المسبق و دلتا الانتقال. ثم يعمل على حمل عمل "تزويج ترتيب" لإظهار انهيار 6.4x.

أرسله

هذا الدرس يُنتجoutputs/skill-radix-scheduler-advisor.md. بالنظر إلى وصف الحملة (شكل نموذج العرض، نمط الاسترداد، عدد المستأجرين المتزامنين) ، فإنه ينتج وصفة طلب العرض والذهاب / عدم الذهاب لتبني SGLang.

التمارين

أركضcode/main.py. مقارنة FCFS و cache- aware على نفس عبء العمل. من أين يأتي دلتا تخفيضات التمديد المسبق، وتفكيك تخفيضات، أو تأخير الصف؟
تعديل حمولة العمل حتى تطلبات العشوائية التحول[system, tools, context]إعادة التشغيل، ماذا يحدث مع ضرب السرعة؟
حساب تكلفة HBM للحفاظ على نظام محرك محرك محرك 2000 رمز مقيم كفرع واحد على Llama 3.1 8B. مقارنة بتكلفة 16 سلسلة بدون إعادة استخدام المواصلات.
اقرأ ورقة SGLang RadixAttention. شرح في ثلاث جمل لماذا تطرد LRU شكل شجرة يفوق LRU شكل كتلة تحت الحمل الثقيل المسبق.
يبلغ عميل عن معدل إصابة الكاش 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