نماذج LLM على Kubernetes: كيف تروّض وحدات GPU دون أن تُفلس على العتاد

بدأت نشوة استخدام واجهات API العامة تتراجع تدريجيًا أمام صحوة قاسية يعيشها أمناء الخزينة في الشركات. فعندما تبدأ بإدخال الذكاء الاصطناعي إلى عملك، يبدو دفع المال لـ OpenAI مقابل كل رمز (token) فكرة ممتازة. لكن ما إن يزداد الحمل وتصبح مسألة أمان البيانات قضية حاسمة، حتى يتجه قطاع الأعمال إلى التفكير في عتاده الخاص. وهنا يتضح أن شراء عشر وحدات H100 لا يكفي. فلا بد من جعلها تعمل بتناغم، وألا تقف عاطلة، وألا تتحول إلى منظومة تدفئة باهظة الثمن لمكتب الشركة. وقد اختار مهندسو Nova AI السير في طريق أقل مقاومة لما يمليه المنطق السليم، فوضعوا تشغيل النماذج اللغوية الكبيرة داخل Kubernetes.

تكمن المشكلة في أن Kubernetes لم يُصمَّم في الأصل للعمل مع الشبكات العصبية. فهو يتعامل ببراعة مع الخدمات المصغّرة (microservices) التي تستهلك فتات الذاكرة، لكنه يتعثر أمام العمالقة التي يبلغ حجمها مئات الغيغابايت. وإذا وضعتَ نموذج LLM في حاوية قياسية، فسيوزّع المجدوِل (scheduler) الموارد بصورة غير فعّالة. ستعمل بطاقة رسوميات واحدة بنسبة مئة بالمئة، فيما تبقى ثلاث بطاقات مجاورة لها في حالة راحة، والشركة تدفع إيجار الرف (rack) طوال الوقت. وتحاول Nova AI حل هذه المشكلة عبر تنسيق ذكي (orchestration)، يصبح فيه كل عنقود GPU كيانًا واحدًا متكاملًا لا مجموعة بطاقات متفرقة.

تقوم بنية الحل على اختصار المسار بين طلب المستخدم وإجابة النموذج إلى أقصى حد. ويتطلب ذلك ضبطًا دقيقًا للغاية لبرامج التشغيل (drivers)، ومراقبة لا ترصد حمل المعالج فحسب، بل المقاييس الخاصة بذاكرة الرسوميات ونوى CUDA. وهذا أمر حاسم في حلول on-prem. ففي السحابة يكفي أن تضغط زرًا لتشتري قدرة حوسبية إضافية، أما في مركز البيانات الخاص بك فأنت مقيّد بالخوادم المادية. ولذلك عليك أن تستخرج أقصى ما يمكن مما هو موجود فعلًا في الرف. وتؤتمت Nova AI هذه العملية، وتتيح إعادة توزيع أوزان النماذج ديناميكيًا بين عقد العنقود.

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

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

وفي نهاية المطاف، لن يعتمد نجاح تطبيق الذكاء الاصطناعي في شركة كبيرة على مدى ذكاء النموذج الذي اختارته، بل على تكلفة الطلب الناجح الواحد. فإذا كان الاستدلال لديك أغلى بثلاث مرات مما هو عند منافسيك، فلن ينقذك أي سحر في الشبكات العصبية. وتصبح عملية التحسين على مستوى Kubernetes والفهم العميق لآلية عمل عناقيد GPU هي الأدوات الخفية التي تفصل بين منتج يعمل وتجربة باهظة الثمن تُغلق بعد نصف عام.

الخلاصة: عصر الحرق العشوائي لساعات GPU يقترب من نهايته، ويبدأ زمن البنية التحتية الذكية. فهل ستتمكن المنصات الروسية مثل Nova AI من منافسة منسّقات العنقود الغربية في ظل شحّ العتاد؟