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

التكلفة والحوكمة لبنية الذكاء الاصطناعي التحتية

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

التكلفة والحوكمة لبنية الذكاء الاصطناعي التحتية

في كل نقطة أخرى من مسيرة مهندس DevOps، تُحسِّن الكمون والموثوقية والسرعة. في بنية تحتية للتعلم الآلي، تظل هذه الثلاثة مهمة — لكن بُعداً رابعاً يسيطر على الأجندة التشغيلية: التكلفة. ساعة GPU واحدة من فئة A100 على أي سحابة كبرى تتراوح بين 3 و6 دولارات. تشغيل تدريب بـ 500 عقدة قد يُفوتر بـ 200 ألف دولار قبل أن يُرسل النموذج تنبؤاً واحداً. تُكلِّف أساطيل الاستدلال لنموذج لغوي كبير يخدم 50 مليون مستخدم يومياً ما يزيد على 10 ملايين دولار شهرياً. الحوكمة — معرفة أي فريق أنفق ما، على أي نموذج، بموافقة من، بأي مسار امتثال — هي الانضباط الذي يجعل هذا الإنفاق قابلاً للدفاع عنه وتحمي المنظمة قانونياً.

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

التحكم في تكلفة GPU

هدر GPU يعادل حالات EC2 المعطلة — لكن بتكلفة وحدة أعلى بـ 30 مرة. الضوابط الأربعة ذات التأثير الأكبر هي: التحجيم الصحيح، والحالات الفورية/القابلة للإلغاء، وتحزيم الأعباء، واكتشاف الخمول.

التحجيم الصحيح. يطلب المطورون A100 بدافع العادة حتى حين يكفي T4 أو A10G. افرض نموذج طلب متدرج: يجب على المطور تحديد سبب الحاجة إلى طراز GPU المطلوب. استخدم تنميط ذاكرة GPU (nvidia-smi --query-gpu=memory.used --format=csv أو تكامل Prometheus مع dcgm-exporter) لبناء خريطة حرارية لاستخدام الذروة الفعلي لكل فريق. المهام التي لا تتجاوز 40% من ذاكرة GPU يجب نقلها إلى طبقة أدنى.

الحالات الفورية والقابلة للإلغاء. التدريب هو أكبر فاتورة GPU وهو قابل للاستئناف بطبيعته عبر نقاط التفتيش. على AWS، تكون Spot أرخص بـ 60–80% من On-Demand لأجهزة P4d/P3. المتطلب التشغيلي هو عقد تسامح مع الأخطاء: يجب على كود التدريب حفظ نقطة تفتيش إلى S3 كل N خطوة والاستئناف عند إعادة التشغيل. استخدام Spot للاستدلال مناسب فقط للنماذج عديمة الحالة خلف موازن تحميل — مع الإبقاء على 30% قدرة On-Demand أساسية.

تحزيم الأعباء عبر MIG وMPS. تُقسِّم NVIDIA Multi-Instance GPU بطاقة A100 إلى ما يصل إلى 7 مثيلات GPU مستقلة، لكل منها شريحة ذاكرتها ومحركات تنفيذها. يتيح Multi-Process Service لعمليات CUDA المتعددة مشاركة سياق GPU واحد. للأعباء التي لا يشبع فيها نموذج واحد GPU، يمكن لـ MIG+MPS تحقيق استخدام أفضل للأجهزة بمعدل 4–6 أضعاف.

اكتشاف الخمول والإيقاف التلقائي. خوادم Jupyter التي تعمل طوال الليل هي مصدر الهدر الكلاسيكي. مراقب خمول على مستوى المنصة يجب أن يُنهي أي جلسة خاملة لأكثر من 30 دقيقة خلال ساعات العمل و60 دقيقة ليلاً. امتد هذا إلى مهام التدريب: إذا لم تستهلك المهمة دورات GPU في آخر 10 دقائق (يمكن اكتشافه عبر dcgm_fi_dev_gpu_util الذي يصل إلى الصفر)، أرسل تنبيهاً وألغ المهمة اختيارياً.

طبقتا التحكم في التكلفة والحوكمة في منصة ML — رؤية التكاليف على اليسار تُغذِّي ضوابط الموافقة والطرح على اليمين.

استرداد التكاليف وعرضها

التحكم في التكلفة دون إسناد هو ضبط أعمى. النهج القياسي هو وسم كل عبء عمل Kubernetes الذي يستخدم GPU بـ team وproject وmodel-name وenv، ثم ربط بيانات تكلفة العقدة من API الفوترة السحابية مع مقاييس Prometheus. أدوات مثل Kubecost أو OpenCost تُجري هذا الربط تلقائياً وتعرض تفصيل التكلفة لكل namespace. أرسل هذا إلى لوحة تحكم مالية داخلية لـ عرض التكاليف (الفرق يرى فاتورته دون محاسبة)، أو ادمجه في نظام حصص لـ استرداد حقيقي للتكاليف.

تنبيهات الميزانية هي آلية التطبيق التشغيلي. اضبط تنبيه فوترة سحابي عند 80% من ميزانية GPU الشهرية؛ عند 100%، يجب أن يوقف متحكم المنصة قبول تقديمات مهام التدريب الجديدة من ذلك الفريق حتى يُعتمد استثناء الميزانية.

# terraform/modules/mlplatform/budget_alert.tf
# حارس ميزانية صارم لكل فريق: يحجب المهام الجديدة عند تجاوز إنفاق GPU الشهري للحد.

resource "aws_budgets_budget" "ml_team_gpu" {
  for_each     = var.ml_teams           # { "search" = 40000, "recommendations" = 60000 }
  name         = "ml-gpu-${each.key}"
  budget_type  = "COST"
  limit_amount = tostring(each.value)
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  cost_filter {
    name   = "TagKeyValue"
    values = ["user:team$${each.key}"]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 80
    threshold_type             = "PERCENTAGE"
    notification_type          = "ACTUAL"
    subscriber_email_addresses = ["ml-platform-oncall@example.com"]
  }

  notification {
    comparison_operator       = "GREATER_THAN"
    threshold                 = 100
    threshold_type            = "PERCENTAGE"
    notification_type         = "ACTUAL"
    subscriber_sns_topic_arns = [aws_sns_topic.budget_hard_stop.arn]
  }
}

resource "aws_sns_topic" "budget_hard_stop" {
  name = "ml-budget-hard-stop"
}

فخ إنتاجي — طلبات Spot غير الموسومة: حالات Spot/القابلة للإلغاء التي تُطلقها SageMaker أو Vertex AI تُفوتر تحت مسؤول IAM الخدمة وليس تحت وسم فريقك. إذا اعتمد نظام استرداد التكاليف على الوسوم فقط، ستُسند تكاليف التدريب المُدار بشكل ناقص. قاطع بين بُعد UsageType في API الفوترة وبيانات مهمة SageMaker لإعادة ربط التكاليف بالفرق.

حوكمة النماذج

الحوكمة هي العقد التنظيمي حول النموذج: على أي بيانات دُرِّب، من وافق على طرحه في الإنتاج، ما فحوص العدالة والتحيز التي اجتازها، وما خطة التراجع إذا تسبب في ضرر. هذه ليست إجراءات بيروقراطية — إنها متطلبات قانونية في مجموعة متوسعة من الولايات القضائية (قانون الذكاء الاصطناعي الأوروبي، والأمر التنفيذي الأمريكي 14110، وإطار NIST AI RMF تتطلب جميعها شكلاً من أشكال توثيق النماذج وإمكانية التدقيق).

سجل النماذج هو المرساة التقنية للحوكمة. كل نموذج يصل إلى التجهيز أو الإنتاج يجب تسجيله بحد أدنى من: تجزئة نسب بيانات التدريب، ومعرف تشغيل التجربة، ومقاييس الأداء، وحالة الموافقة، واسم المهندس أو اللجنة الموافقة، والطابع الزمني. سجل MLflow Model Registry وسجل SageMaker يدعمان هذه الحقول أصلاً؛ تربطهما في خط CI/CD الخاص بك عبر بوابة موافقة تحجب الترقية إلى الإنتاج ما لم تكن status == "Approved".

فحوص العدالة والتحيز هي بوابة CI، وليست مراجعة بعد النشر. شغِّلها في خط CI للنموذج باستخدام أدوات مثل Fairlearn أو Aequitas أو Model Cards Toolkit من Google. إذا تسبب سمة محمية في تدهور أداء النموذج لمجموعة فرعية بما يتجاوز حد التفاوت المُتفق عليه، يفشل تشغيل CI ولا يمكن ترقية النموذج.

# model_governance.yaml — مُدمَج مع كود التدريب في مستودع النموذج.
# تُقيِّمه بوابة CI للعدالة قبل أي ترقية للإنتاج.

model_name: credit-risk-v4
owner_team: financial-ml
compliance_tags: [eu-ai-act-high-risk, gdpr-article-22]

fairness_constraints:
  protected_attributes: [age_group, gender, country_region]
  metrics:
    demographic_parity_difference:
      threshold: 0.05       # الفجوة القصوى المسموح بها بين المجموعات
      fail_on_breach: true
    equalized_odds_difference:
      threshold: 0.08
      fail_on_breach: true

performance_floor:
  auc_roc: 0.82
  precision_at_k: 0.75

data_lineage:
  training_dataset_sha256: "a3f8c21..."
  feature_store_version: "v2.7.3"
  training_cutoff_date: "2025-01-01"

approval_required:
  staging: ["ml-lead"]
  production: ["ml-lead", "risk-compliance"]
  channels: ["#ml-approvals"]

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

الطرح المسؤول

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

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

طرح الكناري يعرض النموذج الجديد لنسبة صغيرة من حركة المرور الحية (1% ← 5% ← 20% ← 100%) مع مراقبة مقاييس الأعمال — وليس المقاييس التقنية فقط. لنموذج توصيات، قد تكون SLO للأعمال: يجب ألا تنخفض نسبة النقر أكثر من 0.5% نسبياً، وتحويل الإضافة إلى السلة ألا ينخفض أكثر من 1% نسبياً، مقاساً على نافذة 24 ساعة كحد أدنى في كل مرحلة. إذا انتهك أي SLO، تتوقف عملية الطرح وتُنبِّه المنصة مهندس المناوبة. هذا التدرج مُرمَّج كـ Argo Rollout أو كائن Flagger canary في Kubernetes — نفس أدوات التسليم التدريجي التي تستخدمها لنشر خدمات التطبيقات.

# kubernetes/rollouts/fraud-model-canary.yaml
# كناري Argo Rollouts لـ Deployment لاستدلال النموذج.
# يُرقِّي عبر 5% ثم 20% ثم 50% ثم 100% مع بوابات تحليل تلقائية.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: fraud-model-v4
  namespace: ml-inference
spec:
  replicas: 20
  selector:
    matchLabels:
      app: fraud-model
  template:
    metadata:
      labels:
        app: fraud-model
    spec:
      containers:
      - name: model-server
        image: registry.example.com/fraud-model:v4.2.1
        resources:
          limits:
            nvidia.com/gpu: "1"
  strategy:
    canary:
      steps:
      - setWeight: 5
      - pause: {duration: 1h}
      - analysis:
          templates:
          - templateName: model-business-slo
      - setWeight: 20
      - pause: {duration: 2h}
      - analysis:
          templates:
          - templateName: model-business-slo
      - setWeight: 50
      - pause: {duration: 4h}
      - setWeight: 100
---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: model-business-slo
  namespace: ml-inference
spec:
  metrics:
  - name: click-through-rate-delta
    interval: 10m
    successCondition: "result[0] >= -0.005"
    failureLimit: 2
    provider:
      prometheus:
        address: http://prometheus:9090
        query: |
          (
            sum(rate(ml_prediction_accepted_total{variant="canary"}[10m]))
            /
            sum(rate(ml_prediction_served_total{variant="canary"}[10m]))
          )
          /
          (
            sum(rate(ml_prediction_accepted_total{variant="stable"}[10m]))
            /
            sum(rate(ml_prediction_served_total{variant="stable"}[10m]))
          ) - 1

ممارسة احترافية — افصل SLO الأعمال عن SLO التقنية في بوابات الكناري: يجب أن تكون SLO التقنية (كمون p99، معدل الخطأ) شرطاً مسبقاً لبدء الكناري — إذا لم يتمكن النموذج الجديد من خدمة الطلبات بشكل نظيف، لا تعرضه للمستخدمين. SLO الأعمال (معدل التحويل، التفاعل، معدل اصطياد الاحتيال) هي شروط بوابة الكناري: تكتشف انحدارات جودة النموذج الأكثر دقة التي تجتاز جميع الفحوص التقنية.

الحوكمة على مستوى النماذج اللغوية الكبيرة

تُقدِّم النماذج اللغوية الكبيرة تحديات حوكمة غير موجودة في التعلم الآلي الكلاسيكي. المخاوف الأساسية هي: حقن المطالبات وكسر القيود (حوكمة المدخلات)، تصفية المخرجات (حوكمة الاستجابات)، إقامة البيانات (الامتثال القانوني للمدخلات المُرسَلة إلى API النموذج)، وإسناد تكلفة الرموز.

على طبقة البنية التحتية، مرِّر كل استدعاء LLM عبر بوابة (أمثلة: Portkey، LiteLLM proxy، AWS Bedrock Guardrails) تُطبِّق: ميزانيات الرموز لكل فريق، وقواعد تصفية المحتوى، واكتشاف المعلومات الشخصية وإخفائها في الطلب والاستجابة، وسجل تدقيق غير قابل للتغيير لكل استدعاء استدلال. يجب أن يُغذِّي إنفاق الرموز محرك استرداد التكاليف: input_tokens * $X + output_tokens * $Y لكل استدعاء API، مُسنَداً عبر وسم الفريق في رأس الطلب. في Google DeepMind وفي المنصات الداخلية لـ OpenAI، هذا النمط للبوابة إلزامي — لا يستدعي أي فريق API النموذج مباشرة.

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