أمازون تطرح معمارية تخزين مُتدرجة لتسريع نماذج اللغة الضخمة

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

السبب الجذري بسيط: نظام vLLM يحتفظ بمفاتيح وقيم الانتباه لكل رمز معالج في ذاكرة مخصصة، ليتجنب إعادة حسابها في كل خطوة. التخزين المؤقت المسبوق يعزز هذا بإعادة استخدام الذاكرة عبر الطلبات التي تشترك في نفس الرموز الأولى كالتعليمات الموحدة للنموذج. لكن على معالجات مثل ml.g6e.4xlarge التي توفر 48 غيغابايت لكل معالج رسومات، بعد تخصيص أوزان النموذج والعمليات الأخرى، تنكمش مساحة التخزين المتاح بسرعة كلما كبر حجم النموذج أو زادت الطلبات المتزامنة.

قدمت أمازون ويب سرفيسز معمارية تخزين مُتدرجة على HyperPod توسع التسلسل الهرمي للذاكرة إلى ثلاث طبقات: ذاكرة GPU (L0)، والذاكرة العامة للمعالج (L1)، وتخزين NVMe موزع مشترك (L2) عبر Curvine، نظام ملفات تخزين موزع خفيف الوزن. هذا يتيح إعادة استخدام ذاكرة التخزين المؤقت عبر نسخ البرنامج بسرعات قريبة من سرعات الأقراص المحلية.

في اختبار عملي، حققت هذه المعمارية معدل نجاح تخزين بنسبة 100 بالمائة عبر الوحدات، وتحسناً في سرعة الوصول إلى أول رمز بمقدار 2.7 مرات، وكمون قراءة بين العقد حوالي 56 ميلي ثانية لطلب يقارب 1900 رمز. النتيجة: أعباء العمل التي كانت تتطلب معالجات P5 الأغلى ثمناً يمكنها الآن العمل على معالجات G6e الأرخص، مما يقلل تكاليف كل نقطة نهاية بناءً على حجم النموذج وملف حركة المرور.

الحل يتطلب مجموعة SageMaker HyperPod مُركبة على Amazon EKS بما لا يقل عن عقدتي معالجات رسومات. المعمارية تعتمد على مشغل الاستدلال الذي يدير دورة حياة المكونات، ويوزع طلبات المستخدمين على النسخ الأكثر احتمالاً لامتلاك الذاكرة المطلوبة بناءً على تقنيات التوجيه الذكي المدمجة في منصة أمازون.