البنية التحتية لتقديم النماذج

تقديم النماذج هو جوهر أنظمة MLOps الإنتاجية. يختبر المحاورون معرفتك بأطر التقديم والأنماط والمفاضلات.

مقارنة أطر التقديم

الإطار	الأفضل لـ	زمن الاستجابة	القابلية للتوسع	نقاط المقابلة
TensorFlow Serving	نماذج TF، gRPC	منخفض	عالي	TF أصلي، التجميع
Triton Inference	متعدد الأطر	منخفض جداً	عالي جداً	التجميع الديناميكي، مشاركة GPU
BentoML	التكرار السريع	متوسط	عالي	أصلي Python، تغليف سهل
Ray Serve	خطوط أنابيب معقدة	منخفض	عالي جداً	التوسع التلقائي، التركيب
TorchServe	نماذج PyTorch	منخفض	عالي	PyTorch أصلي، صيغة MAR

سؤال المقابلة: هندسة التقديم

السؤال: "صمم نظام تقديم لنموذج توصيات مع SLA زمن استجابة 50ms."

هيكل الإجابة:

# مناقشة الهندسة عالية المستوى
architecture = {
    "load_balancer": "AWS ALB أو Envoy",
    "serving_layer": "Triton Inference Server",
    "caching": "Redis لميزات المستخدم",
    "feature_store": "Feast للميزات في الوقت الفعلي",
    "monitoring": "Prometheus + Grafana"
}

# التحسينات الرئيسية للمناقشة
optimizations = [
    "تكميم النموذج (FP32 -> INT8)",
    "التجميع الديناميكي (انتظار 5ms، تجميع حتى 32)",
    "إدارة ذاكرة GPU (نماذج متعددة على GPU واحد)",
    "مجموعة النماذج الدافئة (نماذج محملة مسبقاً)",
    "تخزين الميزات مؤقتاً (تخزين تضمينات المستخدم)"
]

تعمق في التجميع الديناميكي

# تكوين Triton للتجميع الديناميكي
# config.pbtxt
"""
dynamic_batching {
    preferred_batch_size: [8, 16, 32]
    max_queue_delay_microseconds: 5000  # انتظار 5ms
}

instance_group [
    {
        count: 2
        kind: KIND_GPU
    }
]
"""

# لماذا هذا مهم
interview_talking_points = """
- بدون التجميع: طلب واحد = استدلال GPU واحد
- مع التجميع: 32 طلب = استدلال GPU واحد
- استخدام GPU: 10% -> 80%+
- مفاضلة زمن الاستجابة: +5ms انتظار، -20ms استدلال
"""

تقديم النماذج المتعددة

سؤال المقابلة: "كيف تقدم 100 نموذج على موارد GPU محدودة؟"

# الاستراتيجية: مشاركة ذاكرة GPU مع Triton
model_config:
  model_name: "fraud_detector_v1"
  instance_group:
    - count: 1
      kind: KIND_GPU
      gpus: [0]  # مشاركة GPU 0 مع نماذج أخرى

# استراتيجية تحميل النموذج
loading_strategy:
  type: "on-demand"  # التحميل عند وصول أول طلب
  unload_after_seconds: 300  # إلغاء التحميل بعد 5 دقائق خمول

# تكوين الذاكرة
memory_config:
  gpu_memory_limit_mb: 2048  # الحد لكل نموذج
  cpu_memory_limit_mb: 4096

نقاط الحديث الرئيسية:

1. تحديد أولوية النماذج: النماذج الساخنة محملة دائماً، النماذج الباردة عند الطلب
2. مشاركة GPU: نماذج متعددة على نفس GPU مع حدود الذاكرة
3. تخفيف الحمل: رفض الطلبات عند تجاوز السعة مقابل الانتظار في قائمة

اختبار A/B والنشر الكناري

# Istio VirtualService لتقسيم الحركة
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: model-serving
spec:
  hosts:
  - model-serving
  http:
  - match:
    - headers:
        x-canary:
          exact: "true"
    route:
    - destination:
        host: model-serving-canary
        port:
          number: 8080
  - route:
    - destination:
        host: model-serving-stable
        port:
          number: 8080
      weight: 90
    - destination:
        host: model-serving-canary
        port:
          number: 8080
      weight: 10

متابعة المقابلة: "كيف تقيس إذا كان الكناري ناجحاً؟"

إطار الإجابة:

• مقاييس الأعمال: معدل النقر، التحويل، الإيرادات
• مقاييس تقنية: زمن الاستجابة p99، معدل الخطأ، استخدام GPU
• الأهمية الإحصائية: تحليل بايزي أو اختبارات ترددية
• التراجع الآلي: إذا معدل الخطأ > 1% أو زمن الاستجابة p99 > SLA

رؤية خبير: اذكر أن اختبارات A/B للنماذج تحتاج أحجام عينات أكبر من اختبارات A/B لواجهة المستخدم بسبب التباين الأعلى في توقعات ML.

في الدرس التالي، سنغطي أسئلة البنية التحتية لـ ML الخاصة بالسحابة. :::