تصميم نماذج اللغة الكبيرة (LLMs) على OpenShift: حل مشكلات SCCs والهوية الهجينة

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
يدرك مهندسو المؤسسات حقيقة النشر على Red Hat OpenShift: لا يمكنك ببساطة تطبيق بيانات قياسية باستخدام kubectl. سواء كنت تعمل محليًا، أو على IBM Cloud Satellite، أو عبر Azure Red Hat OpenShift (ARO)، فإن أساسيات الأمان—تحديدًا قيود سياق الأمان (SCCs)—ستعطل عمليات نشر Kubernetes القياسية الأصلية على الفور.
تعمل TrueFoundry كطبقة تراكبية للتنسيق. نفصل تجربة المطور عن تعقيدات البنية التحتية، مما يتيح لك نشر نماذج اللغة الكبيرة (LLMs) مع الالتزام بالحدود الصارمة لبيئة Red Hat. توضح هذه المقالة كيف نتكامل مع شبكات OpenShift، IBM Cloud IAM، و watsonx.ai.
نموذج النشر: هندسة المستويات المنفصلة
نحن نستخدم هندسة المستويات المنفصلة لتلبية متطلبات إقامة البيانات. أنت تتحكم بشكل صارم في مستوى الحوسبة؛ بينما ندير البيانات الوصفية في مستوى التحكم.
- مستوى التحكم (SaaS أو VPC): يتولى إدارة الهوية، وكتالوجات النماذج، وجدولة المهام.
- مستوى الحوسبة (مجموعتك): يعمل وكيل TrueFoundry مباشرة على Red Hat OpenShift Container Platform.
يبدأ الوكيل اتصال WebSocket صادر فقط بمستوى التحكم. لا تحتاج إلى فتح منافذ جدار الحماية الواردة. يلبي هذا متطلبات الأنظمة المعزولة (air-gapped) أو متطلبات الأمان العالية الشائعة في القطاعات المالية والرعاية الصحية.

الشكل 1: يعمل TrueFoundry ضمن مستوى الحوسبة المحلي، مع احترام المحيط الآمن.
الأمان: أتمتة قيود سياق الأمان (SCCs) والتحكم في الوصول المستند إلى الدور (RBAC)
التحدي الرئيسي في OpenShift هو فرض قيود سياق الأمان (SCCs). على عكس Kubernetes الأصلي، يمنع OpenShift الحاويات (pods) من التشغيل بصلاحيات الجذر (root) أو الوصول إلى مسارات المضيف (host paths) بشكل افتراضي.
التعامل مع Restricted-v2
لقد صممنا وكيل TrueFoundry ليعمل ضمن قيود سياق الأمان (SCC) من نوع restricted-v2.
- حقن معرف المستخدم (UID): لا نقوم بتضمين معرفات المستخدم (User IDs) بشكل ثابت. يكتشف الوكيل نطاق معرف المستخدم (UID) المشروح للمساحة الاسمية (namespace) ويقوم بحقن معرف runAsUser الصحيح ديناميكيًا في مواصفات حاوية الاستدلال (inference pod spec) أثناء التشغيل.
- تجريد وحدات التخزين: نتجاوز متطلبات hostPath باستخدام مطالبات وحدات التخزين الدائمة (PVCs) المدعومة بواسطة IBM Cloud Block Storage أو vSphere CSI للإعدادات المحلية.
اتحاد الهوية: IBM Cloud IAM
تُعد بيانات الاعتماد المضمنة في الأسرار خطرًا أمنيًا. بالنسبة لعمليات النشر على IBM Cloud، نطبق اتحاد الهوية باستخدام ملفات تعريف IBM Cloud الموثوقة.
يتيح ذلك لأعباء عمل OpenShift الخاصة بك الحصول على هوية ديناميكية. يقوم الـ pod بتبديل رمز حساب الخدمة المحلي الخاص به برمز IBM Cloud IAM، مما يمنح وصولاً مؤقتًا إلى تخزين كائنات IBM Cloud (COS) أو IBM Key Protect.

الشكل 2: تدفق المصادقة الذي يستخدم ملفات التعريف الموثوقة للتخلص من بيانات الاعتماد الثابتة طويلة الأمد.
الشبكات: التكامل مع مسارات OpenShift
غالبًا ما تتطلب موارد Kubernetes Ingress القياسية ترجمة في بيئات Red Hat. تتكامل TrueFoundry مباشرةً مع وحدة تحكم OpenShift Ingress (HAProxy).
- الدخول (Ingress): عند نشر نموذج، نقوم بتوفير مسار OpenShift تلقائيًا، مع معالجة إنهاء SSL عند الحافة.
- الخروج المعزول (Air-Gapped Egress): بالنسبة للبيئات غير المتصلة، ندعم سحب الصور من سجلات Red Hat Quay الداخلية. يمكنك التخزين المؤقت لأوزان النموذج مسبقًا في مخزن داخلي متوافق مع S3 للتخلص من تبعيات الإنترنت أثناء التشغيل.
الحوسبة: جدولة GPU و Watsonx.ai
نتكامل مع NVIDIA GPU Operator للتعامل مع تسريع الأجهزة.
تقسيم MIG
بالنسبة لمجموعات A100 أو H100، ندعم NVIDIA Multi-Instance GPU (MIG). يقوم مُجدوِل TrueFoundry بتحديد ملفات تعريف MIG المتاحة ويستهدف الحاويات (pods) إلى القسم المنطقي الصحيح، مما يزيد من كثافة استخدام الأجهزة دون الحاجة إلى تكوين تقارب يدوي.
البوابة الموحدة
للفرق التي تستخدم IBM watsonx.ai، نوفر بوابة ذكاء اصطناعي موحدة.
- ترجمة البروتوكول: يستخدم المطورون مخططًا قياسيًا متوافقًا مع OpenAI. تتولى البوابة مهمة التحويل إلى واجهة برمجة تطبيقات watsonx.ai.
- القياسات عن بعد الموحدة: نسجل الطلبات لكل من النماذج المستضافة ذاتيًا (Llama 3، Mistral) ونماذج SaaS (Granite، Watsonx) في لوحة واحدة لمراقبة التكلفة والتدقيق.

الشكل 3: توحد البوابة حركة المرور بين الحاويات المستضافة ذاتيًا وخدمات IBM المُدارة.
مقارنة تشغيلية
يوضح الجدول أدناه التحولات التشغيلية المحددة عند تركيب TrueFoundry على OpenShift الأصلي.
الاستمرارية المعمارية
يمكّنك دمج TrueFoundry مع IBM Cloud و Red Hat OpenShift من الحفاظ على الوضع الصارم للامتثال لبيئة Red Hat مع تسريع نشر النماذج. تحتفظ بإقامة البيانات على OpenShift—سواء كان ذلك في الموقع أو في IBM Cloud—وتوفر لفرق الهندسة لديك واجهة موحدة تجرد قيود البنية التحتية الأساسية.
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.
The fastest way to build, govern and scale your AI

















.png)
.webp)










.webp)






