MLOps وDevOps لأنظمة الذكاء الاصطناعي

أنماط تقديم النماذج

18 دقيقة الدرس 6 من 28

أنماط تقديم النماذج

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

التقديم الآني (الاستدلال عبر الإنترنت)

يُجيب التقديم الآني على طلب التنبؤ بشكل متزامن ضمن ميزانية زمن استجابي — تتراوح عادةً بين بضعة ملي ثوانٍ للنماذج البسيطة وبضع مئات من الملي ثوانٍ للنماذج العميقة الكبيرة. يظل العميل منتظراً للاستجابة. هذا هو النمط الصحيح عندما تحتاج التنبؤ في وقت الطلب: اكتشاف الاحتيال في لحظة الدفع، أو توصية المنتجات عند تحميل الصفحة، أو اعتدال المحتوى عند نشر المنشور.

تمتلك مجموعة التقديم للاستدلال الآني ثلاث طبقات تعرفها من الخدمات المصغرة التقليدية، بالإضافة إلى طبقة رابعة خاصة بتعلم الآلة:

موازن الحمل / بوابة API: يوجّه طلبات التنبؤ ويطبّق المصادقة وحدود المعدل ويوفر نقطة نهاية HTTPS الخارجية. لا يختلف عن خدماتك الحالية.
خادم النموذج: العملية التي تحتفظ بأوزان النموذج في الذاكرة (VRAM للـ GPU أو RAM للـ CPU) وتنفذ التمرير الأمامي. خوادم النماذج للإنتاج — Triton Inference Server وTorchServe وTF Serving وvLLM — تعرض نقاط نهاية gRPC وREST، وتدعم التجميع، وتتعامل مع إصدارات متعددة من النموذج في آنٍ واحد، وتصدر مقاييس Prometheus. لا تلفّ سكريبت Python خاماً في تطبيق Flask وتسميه خادم نموذج؛ هذا النمط ينهار تحت أي حمل حقيقي.
مخزن الميزات (المسار الآني): للنماذج التي تحتاج ميزات محسوبة مسبقاً غير موجودة في حمولة الطلب، يجلبها خادم النموذج من مخزن ميزات منخفض الزمن الاستجابي (Redis، أو Feast online store، أو Tecton). هذا هو أكبر مساهم في الزمن الاستجابي خارج الاستدلال ذاته؛ أبقِه دون 5 ملي ثوانٍ.
تكامل سجل النموذج: تراقب طبقة التقديم إصدارات النماذج الجديدة في السجل وتستبدلها دون توقف. يدعم Triton هذا بشكل أصلي؛ بينما يستطلع TF Serving دليل النموذج بصفة دورية.

التقديم الآني يُجيب على طلب متزامن؛ التقديم الدُفعي يحسب التنبؤات مسبقاً ويكتبها في مخزن للبحث لاحقاً.

التقديم الدفعي (الاستدلال دون اتصال)

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

المقايضة هي حداثة البيانات. مهمة دفعية تعمل كل 24 ساعة تعني أن التنبؤات قديمة بأقصاه 24 ساعة. لكثير من المشكلات التجارية هذا مقبول. لاكتشاف الاحتيال، فهو ليس كذلك. اختر الدُفعي عندما:

مجموعة المدخلات منتهية وقابلة للحصر (جميع المستخدمين، جميع المنتجات، جميع المستندات).
التنبؤ صالح لفترة كافية بحيث لا يسبب الإهمال ضرراً.
النموذج أكبر من أن يُقدَّم في الوقت الحقيقي ضمن ميزانية الزمن الاستجابي.
التكلفة قيد — الاستدلال الدُفعي على نُسخ GPU المؤقتة أرخص عادةً بمعدل 3-10 أضعاف مقارنةً بنقاط النهاية الآنية الدائمة التشغيل.

على نطاق واسع، يعمل الاستدلال الدفعي على Spark (PySpark مع pandas_udf لتجميع استدعاءات النموذج)، أو Ray Batch، أو مهمة Kubernetes بسيطة تتوازى على شظايا المدخلات. تهبط المخرجات في BigQuery أو DynamoDB أو Redis أو المسار غير المتصل بمخزن الميزات، حسب نمط البحث.

فكرة جوهرية: الآني والدفعي ليسا حصرياً. كثير من أنظمة الإنتاج تستخدم كليهما: دُفعي لحساب درجات خط الأساس بتكلفة منخفضة، واستدلال آني لتحديث تلك الدرجة بأحدث السياق خلال الجلسة وقت الطلب. هذا هو معمارية تقديم لامدا — مسماة باسم معمارية بيانات لامدا — وهو النمط الافتراضي لأنظمة التوصية في Google وMeta وNetflix.

أطر التقديم في الإنتاج

NVIDIA Triton Inference Server هو المعيار الصناعي لأعباء العمل على GPU. يدعم TensorFlow SavedModel وONNX وPyTorch TorchScript وTensorRT والخلفيات المخصصة بـ Python. يتيح جدولة المجموعات في Triton ربط ما قبل المعالجة والاستدلال وما بعد المعالجة كطلب منطقي واحد. يجمع التجميع الديناميكي الطلبات الواردة خلال نافذة قابلة للتهيئة في استدعاء كرنل GPU واحد، محسناً بشكل كبير استخدام GPU دون أن يعلم العميل.

# نشر Triton على Kubernetes (Helm)
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update

helm install triton nvidia/triton-inference-server \
  --namespace mlserving --create-namespace \
  --set image.imageName=nvcr.io/nvidia/tritonserver:24.08-py3 \
  --set resources.limits."nvidia.com/gpu"=2 \
  --set modelRepository.storageType=gcs \
  --set modelRepository.path=gs://my-model-registry/triton-models

# تخطيط مستودع النموذج (GCS):
# gs://my-model-registry/triton-models/
#   fraud-detector/
#     config.pbtxt
#     1/
#       model.onnx

# config.pbtxt — إعداد التجميع الديناميكي
cat <<'EOF' > fraud-detector/config.pbtxt
name: "fraud-detector"
platform: "onnxruntime_onnx"
max_batch_size: 64
dynamic_batching {
  preferred_batch_size: [16, 32, 64]
  max_queue_delay_microseconds: 2000
}
input [{ name: "input_features" data_type: TYPE_FP32 dims: [128] }]
output [{ name: "fraud_score"   data_type: TYPE_FP32 dims: [1]   }]
EOF

vLLM هو المعيار لتقديم نماذج اللغة الكبيرة. يطبّق PagedAttention — إدارة كاش KV مقتبسة من الذاكرة الافتراضية في أنظمة التشغيل — للقضاء على هدر الذاكرة من التسلسلات متغيرة الطول. على A100 80GB واحد، يحقق vLLM عادةً إنتاجية أعلى بمقدار 3-5 أضعاف مقارنةً بحلقة generate() النائفة من HuggingFace.

TF Serving هو الخيار القياسي لعمليات نشر TensorFlow SavedModel. إنه أبسط من Triton ومُجرَّب في الإنتاج عبر البنية التحتية الداخلية لـ Google. إذا كانت مؤسستك تعتمد TensorFlow بكثافة ولا تحتاج دعم أطر متعددة، فإن TF Serving هو الخيار الأقل تعقيداً تشغيلياً.

Ray Serve يملأ الفجوة عندما تحتاج مرونة Python أولاً: منطق مخصص لما قبل وبعد المعالجة، أو نماذج مجمّعة، أو رسوم نشر بها تفريعات. يتكامل مع النظام البيئي الأوسع لـ Ray (Ray Train وRay Tune) للتعامل مع دورة حياة MLOps الكاملة على مجموعة عناقيد واحدة.

التوسع التلقائي للاستدلال

أعباء عمل الاستدلال متقطعة. خدمة التوصيات ترى ارتفاعاً في الحركة بمقدار 10 أضعاف خلال ساعات ذروة التسوق. نموذج الاحتيال يرى ارتفاعاً كلما أجرى تاجر كبير عرضاً ترويجياً. التوفير الثابت للتعامل مع الذروات يعني إنفاق ميزانية GPU على طاقة خاملة خلال ساعات الهدوء. عند 2-4 دولارات/ساعة للـ GPU الواحد من نوع A10G، تتراكم تكلفة الخمول سريعاً.

Kubernetes Horizontal Pod Autoscaler (HPA) يعمل للنماذج المعتمدة على CPU لكنه أعمى عن الإشارات الخاصة بـ GPU الأكثر أهمية: استخدام GPU، وعمق طابور التجميع، وعدد الطلبات المعلقة. الجواب في الإنتاج هو KEDA (Kubernetes Event-Driven Autoscaling) مقترناً بمقاييس مخصصة من خادم النموذج:

# KEDA ScaledObject — توسع Triton بناءً على عمق طابور الطلبات المعلقة
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: triton-fraud-scaler
  namespace: mlserving
spec:
  scaleTargetRef:
    name: triton-fraud-deployment
  minReplicaCount: 1
  maxReplicaCount: 20
  cooldownPeriod: 120
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus.monitoring.svc:9090
        metricName: triton_pending_request_count
        query: |
          sum(nv_inference_queue_duration_ms{model="fraud-detector"}) /
          sum(nv_inference_count{model="fraud-detector"})
        threshold: "50"   # توسع عندما يتجاوز زمن انتظار الطابور 50 ملي ثانية

لأعباء العمل الحساسة للتكلفة أو المتقطعة، فكّر في التوسع إلى الصفر. كل من Knative Serving وAWS SageMaker Serverless Inference يدعم التوسع الحقيقي إلى الصفر: النشر يتقلص إلى صفر نُسخ عند الخمول ويتوسع عند الطلب الأول (زمن بدء التشغيل البارد: 1-30 ثانية حسب حجم النموذج). هذا ممكن للنماذج ذات الحركة غير المتكررة؛ لكنه كارثي للمسارات الحساسة للزمن الاستجابي حيث سيخرق بدء التشغيل البارد هدف مستوى الخدمة.

ممارسة الإنتاج: لحاويات الاستدلال على GPU، اضبط resources.requests.nvidia.com/gpu مساوياً لـ resources.limits.nvidia.com/gpu. موارد GPU في Kubernetes غير قابلة للضغط — إما يضع الجدولي الحاوية على عقدة بها GPU متاح أو لا. ضبط طلب أقل من الحد يؤدي إلى جدولة غير متوقعة وتعارضات في مشاركة GPU. اضبطهما دائماً متساويَيْن.

اختبار حمل مكدس التقديم

لا تُرقِّ نموذجاً للتقديم الآني أبداً دون اختبار حمل على نسخة تجهيزية تطابق نوع GPU وذاكرة الإنتاج. أداة perf_analyzer من Triton مصممة لهذا الغرض تحديداً؛ وبدلاً من ذلك، يعمل k6 مع سكريبت طلب نموذج مخصص على أي نقطة نهاية REST أو gRPC.

# Triton perf_analyzer — زمن استجابي وإنتاجية أساسية
perf_analyzer \
  -m fraud-detector \
  -u triton-staging.internal:8001 \
  --protocol grpc \
  --concurrency-range 1:64:8 \
  --measurement-interval 10000 \
  -b 32 \
  --percentile 99

# أعمدة المخرجات المتوقعة:
# Concurrency | Inferences/sec | p50 latency (ms) | p99 latency (ms) | GPU util %
# اضبط dynamic_batching preferred_batch_size حتى يكون p99 < هدف مستوى الخدمة

# سكريبت k6 لاختبار حمل نقطة نهاية REST (k6 run load-test.js)
# import http from 'k6/http';
# import { check } from 'k6';
# export const options = { vus: 50, duration: '120s', thresholds: { 'http_req_duration': ['p(99)<200'] } };
# export default function () {
#   const payload = JSON.stringify({ inputs: [{ name: "input_features", datatype: "FP32", shape: [1,128], data: Array(128).fill(0.1) }] });
#   const res = http.post('http://triton-staging.internal:8000/v2/models/fraud-detector/infer', payload, { headers: { 'Content-Type': 'application/json' } });
#   check(res, { 'status 200': (r) => r.status === 200 });
# }

فخ الإنتاج — حجم النموذج مقابل عدد النُسخ: تقلل الفرق عادةً من متطلبات VRAM للنموذج وتجدول نسخاً كثيرة جداً لكل عقدة GPU، مما يؤدي إلى عمليات إيقاف بسبب نفاد الذاكرة. دائماً قِس استهلاك VRAM في ذروته عند حجم الدفعة المستهدف باستخدام nvidia-smi خلال اختبار الحمل قبل تحديد maxReplicaCount. قاعدة عامة: اترك هامش VRAM 10-15% لنمو كاش KV وعبء كرنل CUDA وإصدارات النماذج المتزامنة.

إصدارات الكناري للنماذج

يجب أن يتبع نشر إصدار نموذج جديد نفس انضباط الكناري الذي تطبقه على أكواد التطبيق — لكن مع تعقيد إضافي وهو أن جودة النموذج يمكن أن تتدهور بهدوء في مجموعات فرعية غير مرئية في المقاييس المجمّعة. استخدم شبكة الخدمة (Istio أو Linkerd) أو ميزة تقسيم حركة المرور في خادم النموذج لتوجيه 5% من حركة الإنتاج إلى الإصدار الجديد. راقب كلاً من مقاييس البنية التحتية (الزمن الاستجابي، معدل الأخطاء) ومقاييس جودة النموذج (توزيع درجات التنبؤ، مؤشرات الأداء الرئيسية للأعمال) قبل الترقية. إذا تحوّل توزيع درجات النموذج الجديد بشكل كبير نسبةً إلى الإصدار الحالي — مقاساً بفحص KL divergence في خط المراقبة — فتراجع فوراً.

مجموعة سجل النماذج (الدرس 3)، وخط CI/CD الذي يشترط اجتياز مقاييس التقييم (الدرس 5)، وطبقة التقديم الإنتاجية مع التوسع التلقائي المناسب، ومراقبة الانجراف (الدرس 7) — هذه المجموعة هي ما يميز منصة ML ناضجة عن مشروع بحثي يصادف أنه يعمل في الإنتاج.