ذاكرة التخزين المؤقت KV ذات الطبقات لنماذج اللغات الكبيرة على Amazon SageMaker HyperPod مع Curvine

Amazon Web ServicesAmazon Web Services MetaMeta DeepSeekDeepSeek vLLMvLLM
يصف هذا المنشور بنية ذاكرة تخزين مؤقت KV ذات طبقات على Amazon SageMaker HyperPod، مما يوسع التسلسل الهرمي للذاكرة المؤقتة من وحدة معالجة الرسومات إلى وحدة المعالجة المركزية إلى تجمع NVMe مشترك باستخدام Curvine، وهو نظام ملفات موزع للذاكرة المؤقتة. يتيح ذلك إعادة استخدام ذاكرة التخزين المؤقت KV عبر النسخ المتماثلة، مما يحقق معدل إصابة يصل إلى 100% في الذاكرة المؤقتة عبر Pods وتحسين زمن الوصول حتى 2.7 مرة للوقت حتى أول رمز (TTFT). يقلل الحل من تكاليف البنية التحتية من خلال السماح بتشغيل أعباء العمل على مثيلات G6e منخفضة التكلفة بدلاً من P5.
تشغيل استدلال نموذج اللغة الكبير (LLM) على نطاق واسع يفرض عادةً مقايضة في ذاكرة التخزين المؤقت للقيم الرئيسية (KV cache): إما دفع تكاليف حالات GPU كبيرة الحجم لاستيعاب ذاكرة تخزين مؤقت متنامية، أو قبول بطء في زمن الوصول حتى أول رمز (TTFT) حيث تُعاد معالجة المطالبات المتطابقة في كل طلب. بالنسبة للفرق التي تنشر كتالوجًا واسعًا من نماذج الأساس المتاحة للجمهور (FMs)، مثل Qwen وLlama وDeepSeek وغيرها، عبر نقاط نهاية لكل خط أعمال، أو خطوط أنابيب لتوليد الاسترجاع المعزز (RAG)، أو تطبيقات الحوار متعدد الأدوار، تُترجم هذه المقايضة مباشرةً إلى تكلفة بنية تحتية أعلى وتجربة مستخدم أسوأ. السبب الجذري هو أنه أثناء التوليد، يخزن vLLM مفاتيح الانتباه والقيم لكل رمز في ذاكرة تخزين مؤقت للقيم الرئيسية، وتعيد التخزين المؤقت للبادئات استخدام تلك الذاكرة عبر الطلبات ذات الرموز الأولى المشتركة. في الحالات الفعالة من حيث التكلفة مثل ml.g6e.4xlarge (48 جيجابايت لكل GPU)، تكون الذاكرة المتبقية للتخزين المؤقت للبادئات محدودة، وتنخفض معدلات ضربات الذاكرة المؤقتة على المطالبات الطويلة، وتُعاد معالجة أنظمة المطالبات المتطابقة مسبقًا في كل طلب، وتحتفظ نسخ vLLM الموسعة أفقيًا بذاكرات مؤقتة معزولة. الحل يبني تسلسلًا هرميًا للذاكرة المؤقتة من ثلاث طبقات: L0 (ذاكرة التخزين المؤقت للبادئات على GPU)، L1 (تفريغ إلى ذاكرة وحدة المعالجة المركزية)، وL2 (تجمع NVMe الموزع المشترك عبر Curvine). L0 هي طبقة الانتباه المقسّم الأصلية في vLLM، وL1 تستخدم LMCache لتفريغ كتل GPU المطرودة إلى ذاكرة المضيف (DRAM)، وL2 تجمع محركات NVMe المحلية في مساحة أسماء مشتركة عبر Curvine، ويُركَّب كحجم PVC قابل للقراءة والكتابة من عدة عقد (ReadWriteMany) في كل جراب استدلال. يوجّه التوجيه الذكي في HyperPod الطلبات إلى النسخ الأكثر احتمالًا لاحتواء كتل القيم الرئيسية ذات الصلة، مع استراتيجيات تشمل: مدرك للبادئات، ومدرك للقيم الرئيسية، وتوزيع دائري. التأثير الصافي: فقط عند عدم وجود ضربة كاملة يعيد النظام المعالجة المسبقة من الصفر، مما يقلل بشكل كبير من زمن الوصول حتى أول رمز لأحمال العمل ذات التداخل المتوسط إلى العالي في المطالبات. في نشر اختباري، حقق هذا ما يصل إلى 100% من معدل ضربات الذاكرة المؤقتة عبر الجرابات، وتحسينًا في زمن الوصول حتى أول رمز يصل إلى 2.7x، وزمن قراءة عبر العقد في L2 يبلغ حوالي 56 مللي ثانية لمطالبة مكونة من ~1,900 رمزًا. مع هذه البنية، يمكن لأحمال العمل التي كانت تتطلب سابقًا حالات P5 أن تعمل على حالات G6e منخفضة التكلفة، مما يقلل التكلفة لكل نقطة نهاية. يتطلب التنفيذ SageMaker HyperPod مع تمكين التخزين الطبقي، ومجموعة EKS، وتثبيت مشغل الاستدلال وCurvine. يشرح المقال خمس مراحل: تمكين التخزين الطبقي، وتثبيت مشغل الاستدلال والتبعيات، وتثبيت Curvine، وتصحيح مشغل الاستدلال للطبقة L2 المدعومة بنظام الملفات، وقياس الأداء.
المصدر: AWS ML blog — الأصلي
منشوراتنا السابقة حول هذا الموضوع ↓
أخبار جديدة