NVIDIA Snapshot تستعيد نموذج LLM على GPU خلال 3.6–42.7 ثانية

وصل المستخدمون في وقت واحد، وطابور الطلبات يتزايد، ووحدة GPU الجديدة خُصصت بالفعل، ومع ذلك لا مفر من الانتظار. فقبل تقديم أول رد، يحتاج خادم نموذج اللغة إلى تجهيز التطبيق للعمل. تقترح NVIDIA Snapshot حفظ نتيجة هذا التجهيز واستخدامها عند تشغيل النسخ التالية. وبالنسبة للفريق الذي يشغّل النماذج بنفسه، فهذه طريقة لتقليص الفجوة بين قرار إضافة القدرة الحاسوبية وظهور معالج طلبات جاهز.

ووفق قياسات NVIDIA، تستغرق الاستعادة من 3.6 إلى 42.7 ثانية وتسرّع التشغيل بمقدار 8 إلى 36 مرة. وهذه نتائج الشركة المصنِّعة في ظروف محددة. والسؤال العملي للمطوّر: ما حصة زمن التأخير في توسعة خدمته التي يمكن إزالتها فعلًا بهذه الطريقة؟

حفظ التطبيق بعد تجهيزه

Snapshot أداة مفتوحة المصدر لـ Kubernetes. تحفظ حالة ذاكرة CPU وGPU لتطبيق جُهّز مسبقًا، ثم تستعيدها. ولا حاجة إلى إعادة تحميل الأوزان أو الترجمة البرمجية أو تجهيز رسوم CUDA البيانية (CUDA graphs).

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

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

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

أين تنتهي الثواني الموعودة

استخدمت الاختبارات المنشورة وحدات GPU من طراز B200 وتخزين VAST عبر NFS. أما تخصيص البنية التحتية وتنزيل صورة الحاوية فلا يدخلان ضمن زمن الاستعادة المقيس. لذلك سيكون من الخطأ نقل الأرقام من المقالة مباشرة إلى وعود للعملاء.

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

وهناك أيضًا قيود على قابلية النقل: تتطلب الاستعادة الطراز نفسه من GPU وبرنامج التشغيل نفسه. ويُفرَّغ الكاش الخاص بمعالجة الطلبات السابقة قبل إنشاء اللقطة. وبالتالي لا يجوز أن نعد المستخدم باستئناف توليد انقطع لمجرد وجود Snapshot.

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

ما الذي يجب اختباره في خدمتك

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

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

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