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

مشروع: تصميم منصة تعلم آلة

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

مشروع: تصميم منصة تعلم آلة

أتاحت لك الدروس التسعة السابقة كل لبنة بناء رئيسية: خطوط أنابيب الميزات مع اكتشاف انحراف التدريب عن الخدمة، وتتبع التجارب وسجلات النماذج، وجدولة مجموعات GPU، وبوابات CI/CD لترقية النماذج، وأنماط النشر الكاناري والظلي، والمراقبة متعددة الأبعاد في الإنتاج، وعمليات النماذج اللغوية الكبيرة، وضوابط التكلفة والحوكمة. يطلب منك هذا الدرس الأخير تجميع هذه اللبنات في معمارية متماسكة وذات رأي لفريق متوسط الحجم — اثنا عشر مهندس تعلم آلة، وستة مهندسين من MLOps، وأربعون عالم بيانات — يشحنون ثلاثين نموذجًا نشطًا إلى الإنتاج، مع تفويض بالنمو إلى مئة نموذج خلال ثمانية عشر شهرًا.

تصميم منصة تعلم الآلة ليس قرارًا تقنيًا — بل هو عقد تنظيمي وتشغيلي. كل خيار معماري يُنشئ مجموعة من التجريدات التي إما تُسرّع أو تُعيق الفرق المبنية فوقه. أفضل منصات ML الداخلية في Airbnb وLyft وSpotify وDoorDash تشترك في سمة واحدة: فهي تُعيّر الأجزاء المملة (الوصول إلى البيانات، الحوسبة، تتبع التجارب، النشر) حتى يتمكن علماء البيانات من التركيز كليًا على جودة النماذج.

تقسيم المنصة: ست مستويات

تنقسم منصة ML الإنتاجية بوضوح إلى ست مستويات وظيفية. لكل مستوى مالك رئيسي، ومجموعة من العقود التي يعرضها للمستهلكين في اتجاه المصب، ومجموعة من SLOs يجب الوفاء بها.

مستوى البيانات: استيعاب البيانات الخام، حساب الميزات، مخزن الميزات، وتوليد مجموعات البيانات الصحيحة زمنيًا. SLO: الميزات متاحة في وقت الخدمة بزمن انتظار p99 أقل من 10 مللي ثانية للميزات الآنية؛ يكتمل توليد مجموعة بيانات التدريب في غضون أربع ساعات من الطلب.
مستوى التجارب: بيئات دفاتر الملاحظات، تتبع التجارب (MLflow أو Weights & Biases)، تنسيق اجتياح المعاملات الفائقة (Optuna، Ray Tune)، وسجل النماذج. SLO: تنجح كتابات بيانات التجارب بنسبة 99.9%؛ أي أثر نموذج مسجل قابل للاسترداد خلال ثلاثين ثانية.
مستوى التدريب: مجموعة GPU/TPU، جدولة المهام (Kubeflow Pipelines أو Argo Workflows)، قائمة انتظار المهام، معالجة الاستباق في مثيلات الـ Spot، تنسيق التدريب الموزع (Torch DDP / Horovod). SLO: زمن انتظار إطلاق مهمة التدريب أقل من دقيقتين؛ تستأنف المهام المستباقة في غضون عشر دقائق.
مستوى النشر: وقت تشغيل الخدمة (Triton أو TorchServe أو vLLM للنماذج اللغوية الكبيرة)، خط أنابيب الترقية (staging → canary → production)، متحكم توزيع الحركة، أتمتة التراجع. SLO: يكتمل النشر الإنتاجي في غضون ثلاثين دقيقة من موافقة الترقية؛ يُشغَّل التراجع في غضون دقيقتين من خرق SLO.
مستوى المراقبة: اكتشاف انحراف البيانات، انحراف التنبؤات، الارتباط بمقاييس الأعمال، محفزات إعادة التدريب، تكامل التنبيه مع PagerDuty/Opsgenie. SLO: تُنشر تقارير الانحراف في غضون خمس عشرة دقيقة من إغلاق نافذة الاستنتاج؛ يُطلق تنبيه الانحراف الحرج في غضون خمس دقائق.
مستوى الحوكمة: إسناد التكاليف، تطبيق الحصص، سجلات التدقيق، بطاقات النماذج، أدوات التفسيرية (قيم SHAP المخزنة لكل إصدار نموذج)، رسم بياني لسلسلة البيانات. SLO: تقارير التكلفة متاحة في غضون ساعة من نهاية اليوم؛ الاحتفاظ بسجل التدقيق سبع سنوات.

مبدأ التصميم الأساسي: يعرض كل مستوى عقده كـ API ذات إصدار — وليس مكتبة مشتركة يفرع منها كل فريق نسخته الخاصة. عندما يتغير مخطط مخزن الميزات، فإنه ينشر API الإصدار v2؛ يهاجر المستهلكون في اتجاه المصب وفق جدولهم الزمني.

مخطط المعمارية المرجعية

يوضح المخطط أدناه المنصة الكاملة بجميع مستوياتها الست وتدفقات البيانات الحرجة بينها. اقرأه من اليسار إلى اليمين لمسار التدريب، ومن الأسفل إلى الأعلى لمسار الخدمة.

المعمارية المرجعية لمنصة تعلم الآلة: ست مستويات مع مستوى الحوكمة كاهتمام متشعب. تُظهر الخطوط المتقطعة حلقة إعادة التدريب المُشغَّلة بالانحراف ومسار الميزات الآنية إلى وقت الاستدلال.

هيكل البنية التحتية كرمز

تعيش المنصة على Kubernetes. النمط الذي يتوسع من ثلاثين إلى مئة نموذج هو مجموعة مشتركة مع عزل فضاء الأسماء لكل فريق، وليس مجموعة لكل نموذج. يحصل كل فريق على فضاء أسماء Kubernetes بـ ResourceQuotas لـ GPU والـ CPU والذاكرة. تُعالج مجموعة عقد مشتركة من مثيلات A100 الـ Spot مهام التدريب؛ بينما تُعالج مجموعة عقد on-demand من مثيلات g5.2xlarge طلبات الاستدلال. يُدير Terraform المجموعة ومجموعات العقد؛ أما مخططات Helm أو طبقات Kustomize فتُدير مكونات المنصة.

# terraform/modules/ml-platform/main.tf  — EKS cluster with two node pools

module "eks" {
  source          = "terraform-aws-modules/eks/aws"
  version         = "~> 20.0"
  cluster_name    = "ml-platform-prod"
  cluster_version = "1.30"

  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnets

  eks_managed_node_groups = {

    # Training: spot A100 instances — preemptible, cheaper
    training = {
      instance_types  = ["p4d.24xlarge"]
      capacity_type   = "SPOT"
      min_size        = 0
      max_size        = 20
      desired_size    = 2
      labels = { role = "training" }
      taints = [{ key = "nvidia.com/gpu", value = "true", effect = "NO_SCHEDULE" }]
    }

    # Serving: on-demand GPU for low-latency inference
    serving = {
      instance_types  = ["g5.2xlarge"]
      capacity_type   = "ON_DEMAND"
      min_size        = 2
      max_size        = 40
      desired_size    = 4
      labels = { role = "serving" }
      taints = [{ key = "nvidia.com/gpu", value = "true", effect = "NO_SCHEDULE" }]
    }

    # CPU workers: feature pipelines, drift jobs, orchestration
    cpu-workers = {
      instance_types = ["m6i.4xlarge"]
      capacity_type  = "ON_DEMAND"
      min_size       = 3
      max_size       = 30
      desired_size   = 6
    }
  }
}

# Per-team namespace with GPU quota
resource "kubernetes_namespace" "team_recommendations" {
  metadata { name = "team-recommendations" }
}

resource "kubernetes_resource_quota" "team_recommendations" {
  metadata { name = "gpu-quota"; namespace = "team-recommendations" }
  spec {
    hard = {
      "requests.nvidia.com/gpu" = "8"
      "limits.nvidia.com/gpu"   = "8"
      "requests.cpu"            = "128"
      "requests.memory"         = "512Gi"
    }
  }
}

خط أنابيب الترقية كرمز

خط أنابيب الترقية هو الحد التعاقدي بين التجريب والإنتاج. يجب أن يُشغَّل من سجل النماذج (وليس من إنسان يفتح PR)، وأن يكون مؤتمتًا بالكامل حتى بوابة الكاناري، وأن يُوقَف بواسطة أي مما يلي: مقاييس التقييم أدنى من العتبة، درجة انحراف البيانات أعلى من 0.2، عدم تطابق المخطط بين أثر السجل وعقد الخدمة، أو غياب بطاقة النموذج.

# .github/workflows/model-promote.yml

name: Model Promotion Gate

on:
  repository_dispatch:
    types: [mlflow-model-staging]

jobs:
  evaluate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install evaluation deps
        run: pip install mlflow great_expectations evidently pandas

      - name: Pull candidate model metadata
        id: meta
        run: |
          python scripts/fetch_model_meta.py \
            --model-name "${{ github.event.client_payload.model_name }}" \
            --version "${{ github.event.client_payload.version }}" \
            --out model_meta.json
          echo "accuracy=$(jq -r .metrics.accuracy model_meta.json)" >> $GITHUB_OUTPUT

      - name: Fail if accuracy below threshold
        run: |
          python -c "
          import sys
          acc = float('${{ steps.meta.outputs.accuracy }}')
          if acc < 0.92:
              print(f'FAIL: accuracy {acc} < 0.92')
              sys.exit(1)
          print(f'OK: accuracy {acc}')
          "

      - name: Check feature schema against serving contract
        run: |
          python scripts/schema_check.py \
            --candidate model_meta.json \
            --contract contracts/fraud_model_v3.yaml

      - name: Promote to Production (canary 5%)
        if: success()
        run: |
          mlflow models transition-stage \
            --model-name "${{ github.event.client_payload.model_name }}" \
            --version "${{ github.event.client_payload.version }}" \
            --stage Production
          kubectl apply -f k8s/canary/fraud-canary-5pct.yaml

أنماط الفشل التي يجب التصميم من أجلها

تصميم المنصة لا يعدو كونه جيدًا بمقدار أنماط الفشل فيه. الأنماط التي تُفشل منصات ML على نطاق واسع ليست أعطال الأجهزة الواضحة — يُعالجها Kubernetes. بل هي أعطال الاقتران الخفية التي يجب على مهندس المعمارية التصميم الصريح ضدها:

بدء بارد لمخزن الميزات عند التراجع: تتراجع من نموذج v4 إلى v3. لكن v3 دُرِّب على ميزات لم تعد موجودة في مخزن الميزات لأن خط أنابيب الميزات تم ترقيته أيضًا. الحل: يخزن سجل النماذج ملف feature_spec.yaml إلى جانب كل أثر، ويفرض مخزن الميزات سياسة احتفاظ لا تقل عن تسعين يومًا لكل ميزة مسماة.
متتبع التجارب كنقطة فشل وحيدة: إذا توقف خادم تتبع MLflow، تفشل مهام التدريب — أو الأسوأ، تنجح بصمت دون تسجيل. الحل: MLflow في وضع التوافر العالي خلف موازن تحميل مع نسختين من PostgreSQL لـ writer، وقاطع دائرة في غلاف مهمة التدريب يتدهور بشكل رشيق إلى تسجيل SQLite المحلي إذا كان خادم التتبع غير قابل للوصول، ثم يُزامن عند اكتمال المهمة.
مجاعة حصة GPU: يُرسل أحد الفرق اجتيازًا لخمسمئة تجربة معاملات فائقة على مثيلات Spot. تنضب طاقة Spot. يتم استباق عقد الخدمة عندما تستعيد AWS المجموعة. الحل: فصل صارم بين مجموعات عقد التدريب والخدمة مع مجموعات Spot متمايزة ومعالجات للمقاطعة. الخدمة على مثيلات on-demand فقط. مهام التدريب لها priorityClassName: batch-low.
بطاقة نموذج قديمة في الإنتاج: يطلب تدقيق تنظيمي استفسارًا عن مصدر بيانات التدريب لنموذج أُدخل الإنتاج قبل أربعة عشر شهرًا. تم تقديم بطاقة النموذج لكنها تشير إلى مسار S3 تم تنظيفه. الحل: بطاقات النماذج كائنات غير قابلة للتغيير مخزنة في السجل ذاته (وليس في تخزين الكائنات)، والحذف مُحجوب بواسطة admission webhook في Kubernetes طالما أن أي نشر إنتاجي يشير إلى إصدار ذلك النموذج.

ممارسة احترافية — وثيقة عقد المنصة: قبل كتابة سطر واحد من Terraform، اكتب وثيقة عقد من صفحة واحدة لكل مستوى: ما تعده، ما لا تعده، وما يجب على الفرق القيام به بأنفسهم. وزّعها على كل مهندس تعلم آلة سيستخدم المنصة. أكثر إخفاقات منصات ML تكلفةً تحدث عندما يفترض علماء البيانات أن المنصة تتعامل مع شيء ما — كالصحة الزمنية في توليد مجموعات البيانات — في حين تجاهله فريق المنصة بصمت.

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

التوسع من 30 إلى 100 نموذج

ستتعرض منصة الثلاثين نموذجًا التي تصممها اليوم لضغوط متوقعة مع نموها. التغييرات الأكثر أهمية في المنصة عند علامة المئة نموذج هي: (1) كتالوج بيانات وصفية للنماذج — فهرس قابل للبحث لجميع النماذج ومالكيها ومخططات المدخلات/المخرجات وـ SLOs والتكلفة لكل استدلال — لأن إيجاد مالك النموذج يصبح مشكلة تشغيلية حقيقية؛ (2) قالب سير عمل تدريب ذاتي الخدمة يمكن لعلماء البيانات تخصيصه دون لمس YAML، لأن فريق MLOps يصبح عنق زجاجة إذا كان كل نموذج جديد يتطلب عمل خط أنابيب مخصصًا؛ و(3) إسناد تكلفة تلقائي حسب النموذج والفريق مُعروض كملخص أسبوعي، لأن تكاليف GPU المقبولة عند ثلاثين نموذجًا تُهدد الميزانية عند مئة. صمّم هذه القدرات الثلاث في المعمارية الأولية حتى لو لم تُطبقها في اليوم الأول. إعادة تجهيزها لمنصة قائمة أكثر تكلفة بمرتبة كاملة من بناء روابطها مسبقًا.