الفصل 13 — التوسع التلقائي والتخفيف من البدء البارد

المقالة الثالثة عشرة من الجولة الفصلية لـ LLM Primer VI: توسيع أنظمة الذكاء الاصطناعي. الفصل الذي يُوضِّح لماذا يُنتج مُوسِّع Kubernetes الافتراضي انقطاعات تحت حركة مرور LLM، وكيف تُؤلِّف KEDA وKnative وCRIU الإصلاح.

لماذا يوجد هذا الفصل

يتأرجح مساعد دردشة 30× ذروة-إلى-قاع عبر يوم. تذهب أداة مطوِّر إلى صفر في عطلة نهاية الأسبوع. يركب منتج مستهلك موجةً من المحيط الهادئ إلى الأوروبية. التوفير للذروة يُهدر مالاً في القاع؛ والتوفير للقاع يُسقط طلبات في الذروة. التوسع التلقائي يُبقي النشرة متزامنة مع حركة المرور؛ والتخفيف من البدء البارد يجعل التوسع التلقائي — خاصة التوسع إلى صفر — سريعاً بحيث لا يُلاحظ المستخدمون. يُوضِّح الفصل 13 لماذا HPA القياسي لـ Kubernetes مُوسِّع خاطئ لـ LLM، وعلى أي إشارات يُوسِّع KEDA بدلاً منه، وكيف يُعبِّر Knative عن التوسع إلى صفر، وما يتطلَّبه ضغط بدء بارد من 60–180 ثانية إلى ثوانٍ آحادية.

في سطر واحد: وسِّع على ما يشعر به المستخدم — عمق الطابور، وزمن الرمز الأول، وامتلاء KV — لا على ما يُقرِّره برنامج تشغيل GPU، وارفق المُوسِّع باستعادة CRIU الدافئة لتصل النسخ الجديدة قبل انتهاء الطفرة.

13.1 HPA يفشل على حركة مرور LLM بأربع طرق مُحدَّدة

HPA الافتراضي يُوسِّع على استخدام CPU أو GPU. يفشل على LLM بأربع طرق. أولاً، استخدام GPU إشارة خاطئة — يُبلِّغ nvidia-smi عن نسبة الوقت الذي تعمل فيه بعض نواة، لا ما إذا كانت الدُّفعة معبَّأة جيداً أو الطلبات تُحرِز تقدُّماً. خادم مُستخدَم بنسبة 95 بالمئة بثمانية تعبئات أمامية طويلة مُصطفَّة خلف فك تشفير واحد مُحمَّل زائداً؛ خادم مُستخدَم بنسبة 60 بالمئة بدُفعة مستمرة صحية على ما يرام. ثانياً، مدة طلب LLM (ثوان إلى عشرات الثواني) طويلة مقارنةً بحلقة تحكم HPA (15 ثانية)، فيتأخَّر التوسع عن الحمل بعمر طلب كامل. ثالثاً، وحدة السعة ليست pod؛ نشرة مُفصَّلة تتوسَّع في زُمَر ولا يفهم HPA الزُّمَر. رابعاً، البدء البارد: تأتي pod جديدة على الإنترنت بعد 60–180 ثانية، بعد فترة طويلة من الطفرة التي أطلقتها إما حمَّلت الأسطول زائداً أو تخلَّصت من نفسها كمهل انتهاء. نمط الفشل النموذجي هو انقطاع لمدة دقيقتين خلال مضاعفة حركة مرور، يليه تقليص يترك النشرة ناقصة التوفير للطفرة التالية.

13.2 KEDA يُوسِّع على عمق الطابور وTTFT وامتلاء KV

يُوسِّع KEDA HPA بـ CRD ScaledObject يربط عبء عمل مستهدفاً بواحد أو أكثر من مُوسِّعات تُحوِّل مقياساً خارجياً إلى عدد نسخ مرغوب. ثلاث إشارات تهم لتخديم LLM. عمق الطابور الأكثر مباشرةً: عد الطلبات المُنتظِرة في المحرك هو فائض العمل الوارد عن سعة التخديم؛ يُصدِّره vLLM كـ vllm:num_requests_waiting. زمن الرمز الأول — تحديداً p95 أو p99 عبر نافذة منزلقة — يلتقط تدهور المرئي للمستخدم ويُمسك الحمل الزائد غير المتماثل الذي يُفوِّته عمق الطابور (تعبئة أمامية مُشبَعة لكن فك تشفير جيد، أو العكس). امتلاء ذاكرة KV تطلعيّ؛ حين يعبر الامتلاء 80 بالمئة، يجب أن تأتي نسخ جديدة على الإنترنت قبل أن تبدأ القائمة بالاستباق أو الرفض. ScaledObject إنتاجي عادة يُؤلِّف الثلاثة، مع أعنفها فوزاً. يعتلي Knative Serving فوق ذلك للتوسع إلى صفر: تحت عتبة تفعيل صغيرة، تُزال كل pods؛ تُحتجَز الطلبات الواردة بمُنشِّط يُقلع pod عند الطلب، وهو اقتصادي فقط حين يكون البدء البارد سريعاً.

13.3 CRIU يضغط بدءاً بارداً من 90 ثانية إلى 3–6 ثوانٍ

بدء بارد 70B يتحلَّل إلى سحب صورة (10–60 ث)، تهيئة Python (2–5 ث)، تحميل أوزان (60–120 ث)، تهيئة سياق CUDA (5–15 ث)، التقاط رسم CUDA (10–30 ث)، تسخين KV (2–10 ث) — إجمالي 90–250 ث. CRIU (Checkpoint/Restore In Userspace) يلتقط لقطة عملية مُسخَّنة كاملة — أوزان مُحمَّلة، وسياق CUDA قائم، ورسوم مُلتقَطة، وتجمُّع KV مُخصَّص، وفحص صحة مجتاز — ويُعيدها لاحقاً من القرص في ثوانٍ. أداة NVIDIA cuda-checkpoint (2024) توسِّع CRIU لمعالجة حالة GPU: تجمُّعات ذاكرة الجهاز، وسياق CUDA، وPTX المُخزَّن، والرسوم المُلتقَطة. لقطة vLLM دافئة تُستعاد في 3–6 ثوانٍ من NVMe المحلي. DaemonSet يُهيِّئ نقطة الفحص مسبقاً على NVMe كل عقدة بحيث تستطيع Knative الاستعادة من ملف محلي بدل الجلب عبر الشبكة. مُدمَجاً مع بثِّ الصورة (ابدأ السحب قبل انتهائه) والتحميل الكسول للأوزان، بدء بارد دون خمس ثوانٍ ممكن في الإنتاج — وهو الرقم الذي دونه يصير التوسع إلى صفر مُدافَعاً عنه اقتصادياً للتطبيقات المواجهة للمستخدم.

يجدر بنا تذكُّره: التوسع إلى صفر ثمنُ عدم الدفع في القاع، والبدء البارد ثمنُ التوسع إلى صفر. كل ثانية تحلقها من البدء البارد تُحرِّك نقطة التعادل بين «دائماً دافئ» و«أحياناً بارد» لصالح المُشغِّل.

ما يُمهِّد له الفصل 13

مشت الفصول 1 حتى 13 على المكدس الفيزيائي لتخديم LLM — العتاد، والمحركات، والمنصات، والتفصيل، والتوسع. تتوجَّه بقية الكتاب إلى المال. يُوضِّح الفصل 14 لماذا الرمز هو وحدة الفوترة، ولماذا يُسعَّر المُخرَج ضعفين إلى خمسة أضعاف فوق المُدخَل، وكيف تنتهي رموز التفكير غير المرئية على الفاتورة. يمشي الفصل 15 على حسابيات التعادل بين الاستضافة الذاتية ومزوِّدي API، وبند هندسة المنصة الذي تُقلِّل أغلب الفرق شأنه. الفصل 16 كتالوج حركات خفض التكلفة التي تتراكم.

التالي — الفصل 14: اقتصاديات الرموز وتسعير API. لماذا تبدو الفاتورة كما هي، وكيف يعمل العدَّاد حين لا يراقبه أحد.

هل تريد الصورة الكاملة؟ يشمل فصل الكتاب YAML KEDA ScaledObject لمُوسِّع LLM بثلاث إشارات، وبيان Knative Revision للتوسع إلى صفر، وتفكيك تشريح البدء البارد الكامل، وDaemonSet مُحضِّر CRIU المُسبَق، وأثر «يوم في الحياة» لنشرة مُوسَّعة تلقائياً عبر منحنى حركة مرور يومي. اطّلع على LLM Primer VI على أمازون ←