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

تعرّف على كيفية نشر وتكوين نقاط نهاية النماذج عندما لا توفر بيئتك بالفعل حلاً لخدمة النماذج.

قبل أن تتمكن من ربط IBM Bob بنموذج لغة كبير (LLM)، يجب أن يتوفر لديك وصول إلى نقطة نهاية نموذج منشورة. لا يوفر Bob البنية التحتية لخدمة النماذج أو يستضيفها أو يديرها. إذا كانت مؤسستك توفر بالفعل نقاط نهاية للنماذج من خلال OpenShift AI، أو خوادم استدلال قائمة على GPU، أو خدمات الذكاء الاصطناعي السحابية، أو منصات استدلال أخرى، فيمكنك المتابعة مباشرةً إلى تكوين بوابة النماذج.

خيارات النشر

اختر الخيار الذي يناسب بيئتك ومتطلباتك التشغيلية بشكل أفضل.

الخيارمتى يُستخدم
OpenShift AI (على المجموعة، OCI/ModelCar)النماذج المعزولة عن الشبكة أو المستضافة ذاتيًا؛ عند توفر RHOAI بالفعل على المجموعة
السحابة العامةالنماذج الرائدة (Frontier models) عبر AWS Bedrock أو Azure OpenAI أو Google Vertex AI
البنية التحتية الخاصةالنموذج مخدوم على خوادم GPU منفصلة أو مجموعة استدلال مخصصة

OpenShift AI (على المجموعة، OCI/ModelCar)

يُعد Red Hat OpenShift AI (RHOAI) المنصة الموصى بها لخدمة النماذج على المجموعة، بما في ذلك عمليات النشر المعزولة عن الشبكة (air-gapped). والنهج المفضل لتحميل أوزان النماذج هو نمط OCI/ModelCar: تُضمن ملفات النموذج في صورة OCI تحت المسار /models/ وتُدفع إلى سجل خاص. عند نشر InferenceService، يحقن KServe حاوية تهيئة modelcar-init التي تسحب الصورة وتنسخ الأوزان إلى وحدة تخزين مشتركة عند /mnt/models/، والتي تقوم بيئة تشغيل الخدمة (مثل vLLM) بالتحميل منها بعد ذلك. يتم تخزين صورة النموذج مؤقتًا على العقدة بعد أول سحب — وتتخطى عمليات إعادة التشغيل اللاحقة على العقدة نفسها التنزيل تمامًا.

المتطلبات الأساسية:

  • تثبيت مشغل Red Hat OpenShift AI على المجموعة
  • تمكين KServe وتكوينه
  • عقد عمال (worker nodes) تدعم GPU مع تكوين مشغل NVIDIA GPU (أو ما يعادله)
  • مصادقة واجهة سطر الأوامر oc مع المجموعة المستهدفة مع وجود صلاحيات لإنشاء موارد في فضاء الاسم المستهدف
  • سجل حاويات خاص يمكن الوصول إليه من المجموعة، مع بيانات اعتماد لدفع الصور إليه

تكوين Red Hat OpenShift AI

هيّئ موردي DataScienceClusterInitialization وDataScienceCluster على النحو التالي:

  • عطل serviceMesh.
  • فعّل KServe بضبط managementState: Managed.
  • هيّئ KServe لاستخدام وضع RawDeployment.
  • أزل جميع مكونات Red Hat OpenShift AI غير المستخدمة.

مثال على تكوين KServe:

kserve:
  defaultDeploymentMode: RawDeployment
  nim:
    managementState: Managed
  rawDeploymentServiceConfig: Headed
  serving:
    ingressGateway:
      certificate:
        type: OpenshiftDefaultIngress
    managementState: Removed
    name: knative-serving
  managementState: Managed

تمكين دعم ModelCar

يتم التحكم في دعم ModelCar بواسطة ConfigMap باسم inferenceservice-config في فضاء الاسم redhat-ods-applications. يجب أن يحتوي المفتاح storageInitializer على "enableModelcar": true.

تحقق من التكوين الحالي:

oc get configmap inferenceservice-config \
  -n redhat-ods-applications \
  -o jsonpath='{.data.storageInitializer}'

يجب أن تحتوي المخرجات على:

{
  "enableModelcar": true,
  "cpuModelcar": "10m",
  "memoryModelcar": "15Mi"
}

إذا كان enableModelcar مفقودًا أو مضبوطًا على false، فقم بتحديث ConfigMap:

# Retrieve current value, merge the flag, and patch
CURRENT=$(oc get configmap inferenceservice-config \
  -n redhat-ods-applications \
  -o jsonpath='{.data.storageInitializer}')
PATCHED=$(echo "$CURRENT" | python3 -c "
import json, sys
d = json.load(sys.stdin)
d['enableModelcar'] = True
print(json.dumps(d))
")
oc patch configmap inferenceservice-config \
  -n redhat-ods-applications \
  --type merge \
  -p "{\"data\":{\"storageInitializer\":$(echo $PATCHED | python3 -c 'import json,sys; print(json.dumps(sys.stdin.read()))')}}"

أعد تشغيل وحدة تحكم KServe لتطبيق التغيير:

oc rollout restart deployment kserve-controller-manager -n redhat-ods-applications
oc rollout status deployment kserve-controller-manager -n redhat-ods-applications

حزم ملفات النموذج في صورة OCI

نزّل أوزان النموذج من Hugging Face واحزمها في صورة OCI. يجب أن تحتوي الصورة على جميع ملفات النموذج داخل المجلد /models. لمزيد من المعلومات، راجع وثائق KServe. بالنسبة لعمليات نشر vLLM، قم بتضمين أجزاء نموذج safetensors واستبعد ملفات نقاط التحقق القديمة مثل .bin و.pt وoriginal/*.

مثال على Dockerfile:

FROM busybox:latest

# Model weights — safetensors shards and index
COPY <model-name>/model-*.safetensors         /models/
COPY <model-name>/model.safetensors.index.json /models/

# Model configuration
COPY <model-name>/config.json             /models/
COPY <model-name>/generation_config.json  /models/

# Tokenizer
COPY <model-name>/tokenizer.json           /models/
COPY <model-name>/tokenizer_config.json    /models/
COPY <model-name>/special_tokens_map.json  /models/

إذا كان النموذج يتضمن قالب دردشة (على سبيل المثال، chat_template.jinja)، فأضفه. كبديل، يمكنك نسخ المجلد بأكمله في تعليمة واحدة — وهي طريقة أبسط ولكنها تتضمن ملفات لا يحتاجها vLLM:

FROM busybox:latest
COPY <model-name>/ /models/

دفع الصورة إلى سجل خاص

ادفع صورة OCI إلى سجل حاويات خاص يمكن الوصول إليه من المجموعة:

<registry>/<project>/<model-name>:latest

يمكنك استخدام أي أداة مدعومة لإدارة الصور، بما في ذلك:

  • Podman
  • Skopeo
  • مسارات CI/CD
  • الأدوات المخصصة للسجل

إنشاء فضاء الاسم المستهدف وسر سحب الصور

أنشئ فضاء اسم المشروع وهيّئ بيانات الاعتماد لسحب صورة النموذج:

oc new-project <namespace>

أنشئ سر سحب السجل:

# Pull secret so KServe can pull the model image from your private registry
oc create secret docker-registry model-registry-secret \
  --docker-server=<registry> \
  --docker-username=<username> \
  --docker-password=<password-or-token> \
  -n <namespace>

أنشئ حساب خدمة (Service Account):

# Service account used by the KServe predictor
oc create sa model-puller-sa -n <namespace>

اربط سر السحب بحساب الخدمة:

# Attach the pull secret — both commands are required:
# oc secrets link covers general secret use;
# imagePullSecrets is needed by KServe's ModelCar init container specifically
oc secrets link model-puller-sa model-registry-secret --for=pull -n <namespace>
oc patch serviceaccount model-puller-sa -n <namespace> \
  -p '{"imagePullSecrets": [{"name": "model-registry-secret"}]}'
ملاحظة:

كلا الأمرين مطلوبان. يُستخدم إدخال imagePullSecrets بواسطة حاوية تهيئة ModelCar أثناء استرداد صورة النموذج.

إنشاء ServingRuntime

انشر ServingRuntime يعتمد على vLLM في فضاء الاسم المستهدف:

apiVersion: serving.kserve.io/v1alpha1
kind: ServingRuntime
metadata:
  name: vllm-runtime
  namespace: <namespace>
spec:
  multiModel: false
  supportedModelFormats:
    - name: pytorch
      autoSelect: true
  containers:
    - name: kserve-container
      image: vllm/vllm-openai:<version>
      ports:
        - containerPort: 3000
          protocol: TCP
      livenessProbe:
        httpGet:
          path: /health
          port: 3000
        periodSeconds: 30
        timeoutSeconds: 5
        failureThreshold: 3
      readinessProbe:
        httpGet:
          path: /health
          port: 3000
        periodSeconds: 10
        timeoutSeconds: 5
        failureThreshold: 3
      startupProbe:
        httpGet:
          path: /health
          port: 3000
        periodSeconds: 10
        timeoutSeconds: 5
        failureThreshold: 60

طبّق تكوين بيئة التشغيل:

oc apply -n <namespace> -f serving-runtime-vllm.yaml

نشر InferenceService

أنشئ InferenceService يشير إلى صورة نموذج OCI باستخدام معرف URI للتخزين oci://.

متطلبات التكوين الرئيسية:

  • الإشارة إلى ServingRuntime الذي تم إنشاؤه مسبقًا.
  • تحديد موقع صورة OCI في storageUri.
  • تكوين حدود موارد CPU والذاكرة وGPU التي تتطابق مع متطلبات النموذج.
  • تركيب الذاكرة المشتركة (/dev/shm) لـ vLLM.
  • تكوين وسائط بيئة تشغيل vLLM ومتغيرات البيئة.

مثال:

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: <model-name>
  annotations:
    serving.kserve.io/autoscalerClass: external
    serving.kserve.io/deploymentMode: RawDeployment
spec:
  predictor:
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
            - matchExpressions:
                - key: kubernetes.io/arch
                  operator: In
                  values:
                    - amd64
    tolerations:
      - key: nvidia.com/gpu
        operator: Exists
        effect: NoSchedule
    volumes:
      - name: shm
        emptyDir:
          medium: Memory
          sizeLimit: 64Gi
    model:
      modelFormat:
        name: pytorch
      runtime: vllm-runtime
      storageUri: "oci://<registry>/<namespace-or-project>/<model-name>:latest"
      resources:
        requests:
          cpu: "<cpu-request>"          # e.g. "8"
        limits:
          cpu: "<cpu-limit>"            # e.g. "16"
          memory: <memory-limit>        # e.g. 96Gi — size to model VRAM requirements
          nvidia.com/gpu: "<gpu-count>" # e.g. "1"
      volumeMounts:
        - name: shm
          mountPath: /dev/shm
      args:
        - /mnt/models/
        - --served-model-name=<model-name>
        - --port=3000
        - --enable-auto-tool-choice
        - --tool-call-parser=openai
      env:
        - name: HOME
          value: /tmp
        - name: MAX_LOG_LEN
          value: "100"        # truncate vLLM log lines to avoid log flooding
        - name: HF_HUB_CACHE
          value: /tmp
        - name: TRITON_CACHE_DIR
          value: /tmp
        - name: XDG_CACHE_HOME
          value: /tmp
        - name: HF_HOME
          value: /tmp/hf_home
        - name: NUM_GPUS
          value: "<gpu-count>" # must match nvidia.com/gpu limit above
        - name: CUDA_VISIBLE_DEVICES
          value: "<gpu-indices>" # e.g. "0" for a single GPU; "0,1" for two
        - name: VLLM_WORKER_MULTIPROC_METHOD
          value: spawn
        - name: LOGNAME
          value: vllm
        - name: USER
          value: vllm

طبّق بيان InferenceService:

oc apply -n <namespace> -f isvc-<model-name>.yaml

التحقق من النشر

راقب حالة النشر، وبدء تشغيل الـ pod، وسجلات بيئة التشغيل:

# Watch the InferenceService reach Ready state
oc get inferenceservice <model-name> -n <namespace> -w

# Watch the predictor pod start up
oc get pods -n <namespace> -w

# Tail predictor logs (model load can take several minutes once Running)
oc logs -f deployment/<model-name>-predictor -n <namespace>

عندما يبلغ InferenceService عن READY: True، تحقق من صحة نقطة النهاية.

تحقق من تسجيل النموذج وأرسل طلب استدلال تجريبي:

POD=$(oc get pods -n <namespace> \
  -l app=isvc.<model-name>-predictor \
  -o jsonpath='{.items[0].metadata.name}')

oc exec -n <namespace> "$POD" -c kserve-container -- \
  curl -fsS http://127.0.0.1:3000/v1/models

oc exec -n <namespace> "$POD" -c kserve-container -- \
  curl -fsS http://127.0.0.1:3000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "<model-name>",
    "messages": [{"role": "user", "content": "Hello"}],
    "max_tokens": 50
  }'

استكشاف الأخطاء وإصلاحها

المشكلةالسبب المحتملالحل
ErrImagePullبيانات اعتماد السجل مفقودة أو غير صالحةتأكد من وجود model-registry-secret، وصحة بيانات الاعتماد، وربطه بـ model-puller-sa باستخدام كل من oc secrets link وتصحيح imagePullSecrets.
ImagePullBackOffلم يتم تكوين سر سحب الصورة لـ ModelCarتأكد من أن حساب الخدمة يتضمن تكوين imagePullSecrets. شغّل oc patch serviceaccount model-puller-sa -n <namespace> -p '{"imagePullSecrets": [{"name": "model-registry-secret"}]}'
يظل Predictor في حالة Init:0/1تنزيل صورة النموذج قيد التقدمتحقق من أحداث oc describe pod لمتابعة تقدم Pulling/Pulled؛ يتناسب وقت السحب مع حجم الصورة وعرض النطاق الترددي للسجل.
يظل Predictor في حالة Init:0/1 لأجل غير مسمىملفات النموذج غير موجودةتحقق من تخزين ملفات النموذج تحت المسار /models في صورة OCI.
Engine core initialization failedمهلة تهيئة CUDA الأوليةقد يستغرق بدء التشغيل الأول وقتًا أطول أثناء إنشاء ذاكرات التخزين المؤقت. أعد التشغيل وحاول مرة أخرى.
فشل تحميل النموذجتنسيق ملف النموذج غير مدعوماستخدم ملفات safetensors من Hugging Face واستبعد نقاط التحقق القديمة.
أخطاء الاختبار الذاتي لـ OpenSSL FIPSصورة الحاوية غير متوافقة مع FIPSاستخدم صورة vLLM متوافقة مع FIPS.
OutOfMemory / OOMKilledذاكرة GPU غير كافيةزد موارد GPU، أو قلل طول السياق، أو استخدم نموذجًا مكممًا (quantized model).
يظل InferenceService في حالة Pendingموارد المجموعة غير متوفرةتحقق من توفر GPU وحرر الموارد من أحمال العمل غير المستخدمة.

لمزيد من المعلومات، راجع:

نقاط نهاية نماذج السحابة العامة

استخدم هذا الخيار عند استضافة النماذج بواسطة موفر سحابي، مثل IBM watsonx أو AWS Bedrock أو Azure OpenAI أو Google Vertex AI.

المتطلبات الأساسية:

  • اتصال HTTPS صادر (المنفذ 443) من مجموعة OpenShift إلى نقطة نهاية الخدمة السحابية.
  • مفاتيح API صالحة أو بيانات اعتماد IAM أو بيانات اعتماد مصادقة مكافئة.

قبل تكوين IBM Bob

تأكد من:

  • توفير نشر النموذج ونشاطه.
  • إنشاء بيانات اعتماد المصادقة وتخزينها بشكل آمن.
  • استيفاء أي متطلبات شبكة أو وصول خاصة بموفر الخدمة.

بعد أن تصبح نقطة النهاية متاحة، تابع إلى تكوين بوابة النماذج.

نقاط نهاية نماذج البنية التحتية الخاصة

استخدم هذا الخيار عند استضافة النماذج على بنية تحتية يديرها العميل خارج مجموعة IBM Bob، مثل:

  • خوادم GPU مخصصة
  • مجموعات OpenShift منفصلة
  • خوادم استدلال Bare-metal
  • منصات الذكاء الاصطناعي للمؤسسات

المتطلبات الأساسية:

  • تكشف نقطة نهاية النموذج عن واجهة برمجة تطبيقات متوافقة مع OpenAI.
  • وجود اتصال HTTPS بين مجموعة IBM Bob ونقطة النهاية.
  • توفر بيانات اعتماد المصادقة كأسرار Kubernetes.

قبل تكوين IBM Bob

تحقق من الآتي:

  • اتصال الشبكة من المجموعة إلى نقطة النهاية.
  • تكوين TLS أو TLS المتبادل (mTLS)، إذا لزم الأمر.
  • سياسات الشبكة وجدران الحماية تسمح بالوصول.
  • مصادقة نقطة النهاية تعمل بشكل صحيح.

بعد التحقق من الاتصال والمصادقة، تابع إلى تكوين بوابة النماذج.

ما رأيك في هذا الموضوع؟