💻 computer science

StepCache: Step-Level Reuse with Lightweight Verification and Selective Patching for LLM Serving

يُعد StepCache نظاماً مستقلاً عن البنية التحتية الخلفية (backend-agnostic) يعمل على تحسين خدمة النماذج اللغوية الكبيرة (LLM) لأعباء العمل ذات الهياكل المشتركة والقيود المحلية، وذلك عبر تنفيذ إعادة الاستخدام على مستوى الخطوة، والتحقق خفيف الوزن، والرقع الانتقائي لتقليل زمن الاستجابة واستهلاك الرموز (tokens) بشكل كبير مع ضمان صحة المخرجات.

المؤلفون الأصليون: Azam Nouri

نُشر 2026-04-01

📖 4 دقيقة قراءة☕ قراءة في استراحة قهوة

CC BY 4.0

المؤلفون الأصليون: Azam Nouri

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

تخيل أنك رئيس طهاة ماهر يدير مطعماً مزدحماً. يستمر زبائنك (المستخدمون) في طلب أطباق متشابهة تماماً، ولكن مع تعديلات طفيفة ومحددة.

الزبون (أ) يريد "دجاج ستير فراي حار".
الزبون (ب) يريد نفس طبق الستير فراي تماماً، لكنه طلب فقط "ثوم إضافي" بدلاً من "فلفل حار إضافي".
الزبون (ج) يريد نفس الطبق، لكنه يحتاج أن يكون "خالياً من الغلوتين".

الطريقة القديمة: المطبخ "الكل أو لا شيء"

في الماضي، كانت النماذج اللغوية الكبيرة (LLMs) تتعامل مع هذه الطلبات مثل طاهٍ يرفض إعادة استخدام أي جزء من طبق سابق.

إذا طلب الزبون (ب) طبقاً، يتجاهل الطاهي حقيقة أنه قد طبخ بالفعل الدجاج والخضرووات للزبون (أ). يرمي الطبق القديم بالكامل ويبدأ في طبخ الطبق بالكامل من الصفر.
المشكلة: هذا بطيء للغاية ويهدر الكثير من المكونات (قوة الحوسبة).
البديل (التخزين المؤقت الدلالي - Semantic Caching): حاول بعض الطهاة اتباع نهج مختلف: "إذا بدا الطلب مشابهاً بنسبة 90%، فقدم لهم نفس طبق الزبون (أ) تماماً".
- المخاطرة: إذا قدمت للزبون (ب) طبق "الحار"، سيحصل على فلفل بدلاً من الثوم. الطبق سيكون خاطئاً. وإذا قدمت للزبون (ج) طبق "خالٍ من الغلوتين"، فقد يحصل على طبق يحتوي على صويا صوص غير آمن له. هذا النهج "هش"؛ لأنه ينكسر بسهولة مع التغييرات الصغيرة.

الطريقة الجديدة: StepCache

StepCache هو بمثابة مساعد طاهٍ (Sous-chef) فائق التنظيم يغير طريقة عمل المطبخ. بدلاً من التفكير من منظور "أطباق كاملة"، يفكر في منظور "خطوات".

إليك كيف يعمل StepCache، باستخدام تشبيه المطبخ الخاص بنا:

1. تقسيم الوصفة إلى خطوات

عندما يطبخ الطاهي أول طبق "دجاج ستير فراي حار"، لا يقوم StepCache بحفظ الطبق النهائي فحسب، بل يقسم الوصفة إلى قائمة من الخطوات:

تقطيع الدجاج.
تشويح الثوم.
إضافة صلصة الفلفل الحار.
تقديم الطبق.

2. "المطابقة الذكية"

عندما يأتي الزبون (ب) ويطلب "ستير فراي بالثوم"، يبحث StepCache في الوصفة القديمة ويجدها. يقول: "مهلاً، الخطوات 1 و2 و4 متطابقة تماماً! يمكننا إعادة استخدامها".

3. "الفحص الخفيف"

قبل إعادة استخدام أي خطوة، يقوم StepCache بفحص سريع وبسيط.

الخطوة 1 (تقطيع الدجاج): "هل لا تزال صالحة؟" نعم. (أعد استخدامها!)
الخطوة 2 (تشويح الثوم): "هل هي صالحة؟" نعم. (أعد استخدامها!)
الخطوة 3 (إضافة الفلفل الحار): "انتظر، الطلب الجديد يقول ثوم، وليس فلفل حار". لا. (هذه الخطوة معطلة).

4. "الرقع الجراحية" (إعادة التوليد الانتقائي)

بدلاً من رمي الطبق بالكامل والبدء من جديد، يقوم StepCache فقط بـ ترقيع الجزء المعطل.

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

النتيجة هي أن المطبخ يوفر وقتاً هائلاً ومكونات كثيرة لأنه لم يضطر لتقطيع الدجاج أو تشويح الثوم مرة أخرى.

التعامل مع المواقف الصعبة

ماذا لو كان التغيير كبيراً؟

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

لماذا هذا مهم (النتائج)

اختبرت الورقة البحثية هذا على المسائل الرياضية وتوليد بيانات JSON (البيانات المهيكلة).

السرعة: لأن StepCache يعيد استخدام الخطوات "السهلة"، انخفض متوسط وقت الانتظار من 2.13 ثانية إلى 0.67 ثانية. هذا يشبه الانتقال من انتظار وجبة بطيئة التحضير إلى الحصول على قهوة في ثوانٍ.
الدقة: في التخزين المؤقت القديم (الكل أو لا شيء)، إذا أعدت استخدام إجابة خاطئة، فستكون خاطئة. لكن StepCache يفحص كل خطوة. إذا كانت الخطوة خاطئة، فإنه يصلحها. وكانت النتيجة إجابات صحيحة بنسبة 100%، بينما كانت الطريقة القديمة صحيحة بنسبة 72% فقط تقريباً.
الكفاءة: استخدم "مكونات" (Tokens/قوة حوسبة) أقل بنسبة 24%.

الصورة الكبيرة

StepCache هو "وسيط ذكي" يجلس بين المستخدم والذكاء الاصطناي. إنه يعامل إجابة الذكاء الاصطناعي ليس ككتلة واحدة من النص، بل كسلسلة من لبنات البناء.

إذا كانت اللبنة لا تزال جيدة، فإنه يعيد استخدامها.
إذا كانت اللبنة معطلة، فإنه يستبدل تلك اللبنة فقط.
إذا كان الأساس بأكمله مهزوزاً، فإنه يبدأ من جديد.

هذا يجعل خدمات الذكاء الاصطناعي أسرع، وأرخص، وأكثر موثوقية، خاصة عندما يطلب المستخدمون تنويعات طفيفة على نفس المهمة (مثل إصلاح خطأ في كود برمجي، أو تغيير متغير في مسألة رياضية، أو إضافة حقل جديد إلى ملف بيانات).

إليك ملخص تقني مفصل لورقة البحث بعنوان: "StepCache: إعادة الاستخدام على مستوى الخطوات مع التحقق خفيف الوزن والترقيع الانتقائي لخدمة النماذج اللغوية الكبيرة (LLM)."

1. بيان المشكلة

تُستخدم النماذج اللغوية الكبيرة (LLMs) بشكل متزايد في الأنظمة التفاعلية حيث تُعد قيود زمن الاستجابة (latency) والتكلفة أمراً حاسماً. تعاني آليات التخزين المؤقت (caching) الحالية لخدمة النماذج اللغوية الكبيرة من مشكلتين رئيسيتين:

التخزين المؤقت الدلالي للاستجابة (Semantic Response Caching): يعيد استخدام استجابات كاملة بناءً على تشابه المطالبة (prompt). هذا الأسلوب "هش" لأن التغييرات الموضعية الطفيفة (مثل اسم متغير مختلف، أو مفتاح JSON جديد، أو ثابت متغير) تجعل الاستجابة المخزنة بالكامل غير صحيحة، مما يفرض إعادة توليد كاملة.
تخزين البادئة/القيم المفتاحية (Prefix/KV Caching): يعيد استخدام حالات النموذج الداخلية (Key-Value cache) للبادئات المتكررة في المطالبة. هذا النوع مرتبط ارتباطاً وثيقاً ببنيات نماذج محددة، وأجهزة الترميز (tokenizers)، والأنظمة الخلفية، ويقوم بشكل أساسي بتسريع مرحلة المطالبة بدلاً من إعادة استخدام أجزاء من الإجابة المولدة.

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

2. المنهجية: StepCache

يعتبر StepCache طبقة إعادة استخدام غير مرتبطة بنظام خلفي محدد (backend-agnostic)، تقع فوق وقت تشغيل النموذج (model runtime). وهو يعامل استجابة النموذج اللغوي الكبير ليس ككتلة واحدة، بل كـ تسلسل مرتب من الخطوات.

سير العمل الأساسي

التقسيم (Segmentation): عند التوليد الأول، يتم تقسيم المخرجات إلى قائمة مرتبة من الخطوات.
- الاستدلال (Heuristic): التقسيم بناءً على الفقرات أو التعدادات الصريحة.
- الوعي بالمهمة (Task-Aware): بالنسبة لـ JSON، فإنه يستخرج كائن JSON الصالح كخطوة واحدة.
الاسترجاع (Retrieval): بالنسبة لطلب جديد، يقوم StepCache بحساب تضمين للمطالبة (prompt embedding) واسترجاع أفضل طلب مطابق واحد باستخدام البحث التقريبي عن أقرب الجيران (FAISS).
التحقق لكل خطوة (Per-Step Verification): بدلاً من قبول الاستجابة بأكملها، يقوم StepCache بالتحقق من كل خطوة مخزنة مقابل المطالبة الجديدة والقيود باستخدام قواعد خفيفة الوزن وخاصة بالمهمة.
- الرياضيات: التحقق مما إذا كانت المعادلات الوسيطة والقيم النهائية تتطابق مع الثوابت الجديدة.
- JSON: تحليل JSON والتحقق من وجود المفاتيح المطلوبة.
إعادة التوليد الانتقائي (الترقيع - Patching):
- النجاح (Pass): إذا تم التحقق من الخطوة، يتم إعادة استخدامها.
- الفشل (Fail): إذا فشلت الخطوة، يقوم StepCache بتفعيل الترقيع للكتل المتصلة (contiguous block patching). حيث يعيد توليد الخطوة الفاشلة وجميع الخطوات اللاحقة المعتمدة عليها، بدلاً من إعادة توليد الاستجابة بأكملها.
- تخطي إعادة الاستخدام (Skip-Reuse): إذا أشارت إشارات عدم الاتساق إلى أن الكثير من الخطوات ستفشل (على سبيل المثال، >50% من الخطوات أو تغيير دلالي في الثوابت الأساسية)، يتخطى النظام عملية إعادة الاستخدام بشكل متحفظ ويقوم بتوليد كامل لتجنب عمليات الترقيع غير المثمرة.
الربط والتحقق من السلامة (Stitching & Integrity Check): يتم ربط الخطوات المعاد استخدامها والمُرقعة معاً. يتم بعد ذلك إجراء فحص نهائي لسلامة المهمة (مثل تحليل JSON، أو اتساق الحل الرياضي).
- الإصلاح المحدود (Bounded Repair): إذا فشل الفحص النهائي، يتم إجراء محاولة إصلاح لمرة واحدة.
- العودة إلى الحل الحتمي (Deterministic Fallback): بالنسبة للمعادلات الخطية، إذا فشل الإصلاح، يعيد StepCache حلاً حتمياً أدنى ( $v = v^*$ ) يتم حسابه مباشرة من المعادلة التي تم تحليلها، مما يضمن الصحة.

3. المساهمات الرئيسية

الدقة على مستوى الخطوة (Step-Level Granularity): يقدم تجريداً للتخزين المؤقت يعمل على خطوات مرتبة بدلاً من الاستجابات الكاملة أو حالات الـ KV الداخلية، مما يسمح بإعادة الاستخدام الجزئي.
الترقيع الانتقائي مع حلول احتياطية آمنة: طور آلية لإعادة توليد المنطقة الفاشلة الدنيا (الكتلة المتصلة) مع الحفاظ على سياسة "تخطي إعادة الاستخدام" التكيفية لمنع الخسائر في الكفاءة عند حدوث تغييرات دلالية.
التحقق والإصلاح الواعي بالمهمة: تنفيذ مُحققات خفيفة الوزن وقائمة على القواعد لمجالين ممثلين:
- JSON المهيكل: فرض المفاتيح المطلوبة وصحة المخطط (schema) مع الإصلاح لمرة واحدة.
- المعادلات الخطية: التحقق من الاتساق الرياضي وتوفير حل حتمي لضمان الصحة.
عدم الارتباط بالأنظمة الخلفية (Backend Agnosticism): يعمل النظام كطبقة تطبيق رقيقة (Python) أمام أي واجهة برمجة تطبيقات متوافقة مع OpenAI، مما لا يتطلب تعديل النموذج الأساسي أو وقت تشغيل وحدة معالجة الرسومات (GPU).

4. النتائج التجريبية

قام المؤلفون بتقييم StepCache باستخدام اختبار قياسي مصغر يعتمد على المعالج المركزي (CPU-only) بـ 222 طلباً للتقييم لكل بذرة (متوسط عبر 3 بذور)، مع التركيز على مهام الرياضيات وJSON مع تغييرات كبيرة (إعادة صياغة، تغيير قيم، إضافة مفاتيح).

مقاييس الأداء (الأساس مقابل StepCache):

زمن الاستجابة (Latency):
- متوسط زمن الاستجابة: انخفض من 2.13 ثانية إلى 0.67 ثانية (تحسن بنحو ~3.2 ضعف).
- وسيط زمن الاستجونة: انخفض من 2.42 ثانية إلى 0.01 ثانية (مما يشير إلى أن معظم الطلبات تصيب مسار إعادة الاستخدام السريع).
- زمن الاستجابة عند p95: انخفاض طفيف من 3.38 ثانية إلى 3.30 ثانية (لا يزال زمن الاستجونة في الذيل يهيمن عليه المسار البطيء للترقيع/العودة للحالة الاحتياطية).
استهلاك الرموز (Token Usage):
- انخفاض إجمالي الرموز بنسبة ~24% (36.1k $\to$ 27.3k).
- انخفاض الرموز لكل طلب من 162.7 إلى 123.0.
الصحة (Correctness):
- تحسنت من 72.5% إلى 100% تحت كل من فحوصات المهمة المحددة وفحوصات سلامة المخرجات المربوطة.
توزيع النتائج:
- 79.7% من الطلبات سلكت المسار السريع "إعادة الاستخدام فقط".
- 5.4% تطلبت الترقيع.
- 14.9% فعلت "تخطي إعادة الاستخدام" (توليد كامل) بسبب التغييرات الدلالية.

5. الأهمية والعمل المستقبلي

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

الاتجاهات المستقبلية:

التكامل في الإنتاج: تقييم StepCache على محركات مدعومة بـ GPU (مثل vLLM) مع مقاييس الإنتاجية (throughput).
مسارات واقعية: اختبار النظام ضد أنماط حركة المرور الواقعية والمتقلبة (مثل مسارات BurstGPT).
محققات موسعة: توسيع منطق التحقق ليشمل توليد الكود وسير عمل الوكلاء المدعوم بالأدوات.
الأمن: تحصين التخزين المؤقت ضد هجمات التشابه العدائية وهجمات تسميم التخزين المؤقت (cache poisoning).

باختصار، يوفر StepCache تحسيناً عملياً وقابلاً للتطبيق المباشر لخدمة النماذج اللغوية الكبيرة، مما يعظم الكفاءة في السيناريوهات التي تكون فيها هياكل الحلول مستقرة ولكن القيود تختلف، محولاً ما كان سابقاً مشكلة تخزين مؤقت "إما الكل أو لا شيء" إلى حل دقيق وعالي الأداء.