الفصل 12 — التخديم المُفصَّل وKubernetes
المقالة الثانية عشرة من الجولة الفصلية لـ LLM Primer VI: توسيع أنظمة الذكاء الاصطناعي. الفصل الذي يُقسِّم أخيراً التعبئة الأمامية وفك التشفير على تجمُّعَي GPU منفصلَين ويُبيِّن بدائيّات Kubernetes التي تُبقي pods على الجانب الصحيح من الترابط.
لماذا يوجد هذا الفصل
رسم الفصل 11 خطاً نظيفاً بين المحركات والمنصات — حتى يُشير المحرك نفسه إلى أن التعبئة الأمامية وفك التشفير عبآ عمل متناقضان. التعبئة الأمامية مُقيَّدة بالحوسبة؛ وفك التشفير مُقيَّد بعرض نطاق الذاكرة. تشغيلهما على نفس GPU يُجبِر قطعة عتاد واحدة على أن تجيد أمرين متناقضين وتنتهي متوسطة في كليهما. يُقسِّم التخديم المُفصَّل الاثنين على تجمُّعَي GPU منفصلَين، ويشحن ذاكرة KV بين التجمُّعين، ويدع كل تجمُّع يُضبَط لعبء عمله. السعر تعقيد تشغيلي، مدفوعٌ في بدائيّات Kubernetes وطوبولوجيا pods ونسيج الشبكة الذي يحمل حركة KV. يمشي الفصل 12 على شكل ذلك التعقيد — المكوِّنات ومسار النقل وCRD (LeaderWorkerSet وPodCliqueSet من Grove وKAI Scheduler) التي تُعبِّر عنه.
12.1 التعبئة الأمامية وفك التشفير يريدان رقاقات مختلفة عند ساعات مختلفة
على نفس H100، تعبئةٌ أمامية طويلة تستطيع فعلاً بلوغ 60–80 بالمئة من ذروة FLOP، وخطوةُ فك تشفير تستخدم 5–15 بالمئة من FLOP بينما تُشبع 70–90 بالمئة من عرض نطاق HBM. تداخُلهما تحت التجميع المستمر تسوية عملية لكنها تسرِّب من طريقَين. تمرير حوسبة التعبئة يضرب نفس ناقل HBM الذي تحاول عمليات فك التشفير المُنتظَرة التدفُّق عبره، فيتضخَّم الوقت بين الرموز. البطاقة تعمل أيضاً عند نقطة تشغيل واحدة: اضبط للتعبئة يُخنَق فك التشفير بعرض النطاق؛ اضبط لفك التشفير تُخنَق التعبئة بالحوسبة. تطاولت المُوجِّهات من مئات إلى آلاف الرموز مع سيطرة RAG والوكلاء على حركة مرور الإنتاج، ونمت كلفة التداخُل معها. يمنح التفصيل كل مرحلة تجمُّعها. يستطيع عاملو التعبئة الأمامية العمل على بطاقات FLOP خام (H100 SXM وB200). ويستطيع عاملو فك التشفير العمل على بطاقات السعة وعرض النطاق (H200 وMI300X). يُقاس حجم كل تجمُّع لعبء عمله — حركة مرور سياق طويل ومُخرَج قصير تحتاج مزيداً من التعبئة الأمامية؛ وحركة الدردشة تحتاج مزيداً من فك التشفير.
12.2 الشكل أربعة مكوِّنات ومسار نقل KV
نشرة مُفصَّلة عاملة لها أربعة مكوِّنات. عاملو التعبئة الأمامية يقبلون طلباً، يحسبون التعبئة، يُصدرون الرمز الأول، ويُهيِّئون ذاكرة KV للنقل. عاملو فك التشفير يقبلون KV واردة وبياناتها الوصفية، يُثبِّتونها في تجمُّع الاهتمام المُصفَّح، ويُشغِّلون التجميع المستمر على توليداتهم أثناء الطيران. مُوجِّه KV — طبقة التحكم — يحتفظ برؤية لسعة KV الحرة لكل عامل فك تشفير وامتلاء دُفعته ومحلية شبكته، ويُعيِّن مُخرَج كل تعبئة لتقليل كلفة النقل وموازنة الحمل. بوَّابة أمامية تُنهي اتصال HTTP للمستخدم، تبثُّ الرمز الأول من عامل التعبئة، ثم تنتقل بشفافية إلى بثِّ الباقي من عامل فك التشفير. القيد الحرج هو نقل KV: تسلسل GQA 70B عند 4,096 رمز 1.5–2 GB، وعليه أن يتحرَّك من عقدة التعبئة إلى عقدة فك التشفير داخل نفس ميزانية TTFT 50–100 ms التي يُشاهدها المستخدم. NVLink عند 900 GB/s داخل عقدة وInfiniBand عند 400 Gb/s بين العقد يجعلان الأرقام تعمل — إن حطَّت pods على الجانب الصحيح من النسيج.
12.3 LeaderWorkerSet وGrove وKAI يُعبِّرون عن الطوبولوجيا
لم يمتلك Kubernetes أصلاً بدائيّة لـ «هذين النوعَين من pods هما نسخة منطقية واحدة». LeaderWorkerSet، المُضاف upstream في 2024، يُعبِّر عن نسخة متعدِّدة pods بقائد (قل التعبئة) وعاملين (قل فك التشفير)؛ يُبقي المُتحكِّم المجموعة كوحدة جدولة واحدة. PodCliqueSet من NVIDIA Grove (2025، جزء من NVIDIA AI Enterprise) يُعمِّم أبعد بزُمر مُصنَّفة (تعبئة، فك تشفير، مُوجِّه)، كلٌّ بقالبها وحجمها، مع وصف طوبولوجيا الزُّمَر لكيف تترابط الزُّمَر. يُقدِّم Grove المجموعة كلها إلى المُجَدوِل معاً مع قيود محلية داخل الزُّمرة وبين الزُّمَر. لا يكفي أي CRD وحده؛ كلاهما يحتاج مُجَدوِلاً يعرف الطوبولوجيا الفيزيائية للعنقود، وهو ما لا يعرفه مُجَدوِل Kubernetes الافتراضي. KAI Scheduler — مفتوح المصدر من Run:ai في 2024 — يستهلك رسماً طوبولوجياً يُنتجه nvidia-smi topo --matrix ومدير شبكة InfiniBand الفرعية، ويُقيِّم المواضع المرشَّحة مقابله. حين تطلب زُمرة Grove nvlinkDomain: required، يُقيِّد KAI الوضع لنطاق NVLink متماسك (ثمانية GPU لوحة أساس HGX واحدة على NVSwitch واحد). حين تقول طوبولوجيا الزُّمَر sameInfiniBandIsland، يُبقي KAI الزُّمَر داخل مجموعة مُبدِّل ورقي واحد حيث تبقى ذهاب-إياب KV تحت 100 μs.
ما يُمهِّد له الفصل 12
أعطى الفصل 12 النشرة صورة ساكنة: في أي لحظة، عدد ثابت من الزُّمَر يعمل ويخدم حركة المرور. حركة المرور الحقيقية ليست ساكنة — مساعدو الدردشة يتأرجحون 30× ذروة-إلى-قاع عبر يوم، وأدوات المطوِّرين تذهب إلى صفر في عطلات نهاية الأسبوع، ومنتجات المستهلك تتبع الشمس. يمشي الفصل 13 على قصة التوسع التلقائي: لماذا HPA القياسي مُوسِّع خاطئ لتخديم LLM، وعلى أي إشارات يُوسِّع KEDA بدلاً منه، وكيف يُعبِّر Knative عن التوسع إلى صفر، وما يضغط بدءاً بارداً من 60–180 ثانية إلى شيء يستطيع تطبيق مواجه للمستخدم امتصاصه.
التالي — الفصل 13: التوسع التلقائي والتخفيف من البدء البارد. KEDA وKnative وCRIU وتخزين رسم CUDA المؤقت وNVMe — المكدس الذي يدع التوسع إلى صفر يتعايش مع مستخدمين حقيقيين.