Galahad-kv يحفظ KV-cache على NVMe ويحمّل الكتلة أسرع بـ2,8–4,3 مرة من إعادة الحساب

فحص باحثون طبقة ذاكرة لنماذج LLM لا تعيد حساب الموجّه (prompt) من الصفر، بل تستخرج حالة KV الجاهزة من القرص. شغّلوا حزمة galahad-kv على 50 مليون توكن من نص عام حقيقي عبر vLLM على بطاقة NVIDIA H100 واحدة، مع نموذجي Gemma 4 12B وGemma 4 31B. عادت جميع الكتل المفحوصة، أي 100 من 100، من التخزين دون إعادة حساب. وكان التحميل أسرع بـ2,8–4,3 مرة، فيما استهلكت GPU طاقة أقل بـ8,8–12,3 مرة.

كيف تعمل طبقة الذاكرة

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

يقسّم Galahad-kv التدفق إلى كتل يبلغ حجم كل منها نحو 16 000 توكن. تُكتب حالة KV لكل كتلة على قرص NVMe محلي مشفّر، وتُعاد عند الطلب مطابقة بايتًا ببايت. وبحسب تقدير تقريبي، تعطي 50 مليون توكن نحو 3 100 كتلة. ويُقاس حجم التخزين هنا بالتيرابايت.

يوضح المؤلفون من البداية أن الأمر يتعلق بإعادة استخدام حالة محفوظة. فنافذة الانتباه تبقى كما هي، وتُحمَّل كتلة واحدة في كل مرة، وتعتمد جودة الإجابة على النموذج نفسه.

ماذا أظهرت القياسات

أُجري الاختبار على بطاقة H100 واحدة تحت vLLM، وبلغ عمق الكتل المفحوصة 50 مليون توكن. أبرز المؤشرات:

• تحميل 100 من 100 كتلة مفحوصة من التخزين المشفّر دون إعادة حساب، على النموذجين معًا، وعلى أعماق من 0 إلى 50 مليون توكن؛
• تحميل الكتلة أسرع من إعادة حسابها بـ2,8–4,3 مرة؛
• استهلاك طاقة GPU أقل بـ8,8–12,3 مرة؛
• بقيت ذاكرة GPU ثابتة على امتداد تدفق الـ50 مليون توكن؛
• أجاب Gemma 4 12B إجابة صحيحة عن 82 سؤالًا من 100، وGemma 4 31B عن 98 من 100؛
• لم يختلق أي من النموذجين إجابة.

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

أين الحدود ولمن يفيد

للنهج ثلاثة قيود. أولًا، كتابة الذاكرة تكلّف مرة واحدة: إذ يجب حساب كل كتلة وحفظها مرة واحدة. ثانيًا، يحتاج التخزين إلى تيرابايتات من NVMe المحلي. ثالثًا، لا يُحمَّل في الوقت نفسه سوى كتلة واحدة، لذا فإن الأسئلة التي تتطلب الجمع بين وقائع من أماكن كثيرة في المدونة النصية دفعة واحدة لا يغطيها هذا الاختبار. وهذه نسخة أولى من ورقة بحثية منشورة مسبقًا، ولا تظهر حتى الآن أي عمليات إعادة إنتاج مستقلة. لكن المؤلفين يصفون بروتوكولًا صُمّم للحماية من الطرق المعتادة للالتفاف على اختبارات السياق الطويل، ويقدمون إمكانية إعادة إنتاج النتائج على GPU واحدة ببرمجيات عامة وترخيص مجاني للحزمة.

والخلاصة العملية للمهندسين كالتالي. يكون النهج مجديًا حيث يُقرأ المخزون النصي الكبير نفسه مرارًا وتكرارًا: مستودعات الشيفرة، والتوثيق، والأرشيفات، والتاريخ الطويل للوكيل (agent). وهنا تلتهم إعادة حساب البادئة (prefix) الجزء الأكبر من زمن GPU. وقبل التطبيق، ينبغي تقدير ثلاثة أمور: كم تيرابايت من NVMe سيلزم لمدونتكم النصية، وهل تستردّ الكتابة لمرة واحدة كلفتها عند معدل الوصول لديكم، وهل نموذجكم كافٍ لقراءة الكتلة المحمّلة قراءة دقيقة. وللتحقق تكفي بطاقة H100 واحدة والمكدس العام المذكور في الورقة. وسيُظهر التشغيل على بياناتكم الخاصة سريعًا ما إذا كانت الأرقام ستتكرر: 2,8–4,3 مرة في السرعة و8,8–12,3 مرة في الطاقة.