Key Takeaways
- جهاز واحد: GPU واحد، 10-50 مستخدمًا متزامنًا، إعداد بسيط.
- متعدد GPU: 2-8 وحدات GPU، 50-200 مستخدم، تنظيم باستخدام Kubernetes.
- مؤسسي: 5-50 وحدة GPU، 500+ مستخدم، موزّع، توفر عالٍ.
- موازنة الحمل: يوزّع نظام round-robin الطلبات عبر حُجيرات GPU.
- المراقبة: تتبّع زمن الاستجابة، وعمق الطابور، واستخدام GPU، ومعدلات الأخطاء.
- اعتبارًا من أبريل 2026، يُعد Kubernetes المعيار لنشر نماذج LLM في المؤسسات.
كيف توسّع من جهاز واحد إلى نظام موزّع؟
التدرّج من جهاز واحد إلى بيئة الإنتاج:
| مرحلة النشر | عدد وحدات GPU | المستخدمون المتزامنون | اتفاقية مستوى الخدمة للتوفر | تكوين البنية التحتية |
|---|---|---|---|---|
| — | — | — | — | — |
| — | — | — | — | — |
| — | — | — | — | — |
| — | — | — | — | — |
كيف تطبّق موازنة الحمل؟
يوجّه موازن الحمل الطلبات إلى حُجيرة الاستدلال الأقل انشغالًا.
Round-robin: يوزّع بالتساوي عبر الحُجيرات (الأبسط).
الأقل تحميلًا: يرسل إلى الحُجيرة ذات الطابور الأقصر (زمن استجابة أفضل).
الجلسات اللاصقة: يستخدم المستخدم نفسه دائمًا الحُجيرة نفسها (للسياق، لكنه محفوف بالمخاطر إذا فشلت الحُجيرة).
# Kubernetes Service con balanceo de carga
apiVersion: v1
kind: Service
metadata:
name: llm-inference
spec:
selector:
app: vllm-inference
ports:
- port: 8000
targetPort: 8000
type: LoadBalancer
sessionAffinity: None # Round-robin entre podsكيف تطبّق التكرار وتجاوز الفشل؟
يتطلب التوفر العالي مكونات متكررة:
نسخ الحُجيرات: عدة حُجيرات استدلال. إذا فشلت إحداها، تتولى البقية معالجة الطلبات.
فحوص السلامة: يزيل Kubernetes تلقائيًا الحُجيرات غير السليمة.
تكرار التخزين: تُنسخ ملفات النموذج عبر العُقد.
تجاوز فشل DNS: إذا فشل مركز بيانات بأكمله، يوجّه إلى مركز احتياطي.
ماذا يجب أن تراقب؟
يجب أن تراقب عمليات النشر المؤسسية:
- زمن الاستجابة: الوقت لكل طلب (المئينات p50، p95، p99).
- عمق الطابور: عدد الطلبات المنتظرة. >10 = حمل زائد.
- استخدام GPU: يجب أن يكون 70-90%. <50% = مفرط في الحجم. >95% = ناقص في الحجم.
- معدل الأخطاء: % من الطلبات الفاشلة. يجب أن يكون <0.1%.
- الإنتاجية: token/ثانية عبر جميع الحُجيرات.
- التوفر: % من الوقت الذي تكون فيه الخدمة متاحة (الهدف 99.9%).
- التكلفة لكل استعلام: $/طلب (عتاد مُستهلك).
كيف تحسّن التكاليف على نطاق واسع؟
على نطاق واسع، ركّز على:
- استخدام GPU: كلما ارتفع، انخفضت التكلفة لكل طلب. الهدف 80-90%.
- تكميم النموذج: يستخدم Q4 مقابل FP16 ربع VRAM، بالسرعة نفسها. يقلل عدد وحدات GPU المطلوبة.
- حجم الدفعة: الدفعات الأكبر = تكلفة أقل لكل طلب (لكن زمن استجابة أعلى).
- التوسع التلقائي: قلّص ليلًا، وسّع نهارًا (يوفر 30-50% من تكاليف السحابة).
- تعدد المستأجرين: شغّل 2-3 نماذج لكل GPU (إذا سمح VRAM). استخدام أعلى.
أخطاء شائعة عند التوسع في المؤسسة
- تجاهل متطلبات زمن الاستجابة. اتفق على اتفاقية مستوى خدمة لزمن استجابة p99 قبل النشر. قد يبدو زمن استجابة 2 ثانية مقبولًا حتى يشتكي المستخدمون.
- الإفراط في التزويد للذروة. إذا كانت الذروة 100 مستخدم لمدة ساعتين يوميًا، فلا تشترِ عتادًا لـ 100 مستخدم متزامن طوال اليوم. استخدم التوسع التلقائي.
- عزل أعطال ضعيف. إذا أوقف تعطّل حُجيرة واحدة موازن الحمل، فالبنية خاطئة. اختبر سيناريوهات الفشل.
- مراقبة المقاييس الخاطئة. مراقبة استخدام GPU دون زمن الاستجابة أمر معكوس. زمن الاستجابة هو ما يؤثر في المستخدمين.
- افتراض أن أدوات المصدر المفتوح تتوسع إلى المستوى المؤسسي. يعمل Ollama بشكل ممتاز لمستخدم واحد. أما لـ 500 مستخدم متزامن، فيلزم مراقبة وتنظيم مؤسسيان.
ما هي الأسئلة الأكثر شيوعًا حول توسيع نطاق نماذج LLM المحلية؟
كم عدد وحدات GPU التي نحتاجها لنشر مؤسسي؟
يعتمد على التزامن ومتطلبات زمن الاستجابة. 100 مستخدم متزامن على نموذج 7B: ~5-8 وحدات GPU. 500 مستخدم متزامن: 20-30 وحدة GPU. الصيغة: (المستخدمون المتزامنون × زمن الاستجابة المتوقع) / (token/ثانية لكل GPU).
ما الفرق بين موازنة الحمل والتوسع التلقائي؟
موازنة الحمل توزّع الطلبات عبر الحُجيرات الموجودة. التوسع التلقائي يضيف أو يزيل الحُجيرات حسب الحمل. كلاهما ضروري: موازنة الحمل توزّع العمل الآن، والتوسع التلقائي يضبط السعة.
كيف نتعامل مع أعطال GPU؟
يعيد Kubernetes جدولة الحُجيرات تلقائيًا إلى وحدات GPU سليمة. إذا فشلت وحدة GPU، يضع Kubernetes علامة عليها كغير متاحة ويوجّه حركة المرور إلى غيرها. حافظ على التكرار: إذا كنت تحتاج 8 وحدات GPU، فزوّد 10.
ما اتفاقية مستوى الخدمة لزمن الاستجابة التي يجب أن نستهدفها؟
زمن استجابة p99 <2 ثانية هو المعيار لروبوتات الدردشة. p99 <500 ميلي ثانية للإكمال التلقائي في الوقت الفعلي. حدّد اتفاقية مستوى الخدمة وفقًا لتجربة المستخدم واختر العتاد وحجم الدفعة لتحقيقها.
كيف نراقب عنقود استدلال موزّعًا؟
راقب على مستوى الحُجيرة وعلى مستوى العنقود: استخدام GPU، وعمق الطابور، وزمن الاستجابة (p50/p95/p99)، ومعدل الأخطاء، والإنتاجية، والتوفر. استخدم Prometheus + Grafana أو ما يعادلهما.
هل التوسع المحلي أرخص من السحابة؟
نعم، على نطاق واسع. نقطة التعادل ~500 ألف token/شهر. محليًا: تكلفة أولية عالية ($500 ألف-2 مليون عتاد)، ثم تكلفة منخفضة لكل طلب. السحابة: لا تكلفة أولية، تكلفة عالية لكل طلب ($0.15-60/مليون token).
المصادر
- وثائق Kubernetes -- kubernetes.io/docs
- دليل نشر vLLM -- docs.vllm.ai/en/serving/distributed_serving.html
- المراقبة باستخدام Prometheus -- prometheus.io