نشر وتكوين نقاط نهاية النماذج لـ IBM Bob المحلي عندما لا تتوفر في بيئتك حلول جاهزة لخدمة النماذج.

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

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

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

نشر النماذج باستخدام OpenShift AI (على المجموعة، OCI/ModelCar)

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

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

مُشغِّل Red Hat OpenShift AI مثبَّت على المجموعة

KServe مُفعَّل ومهيَّأ

عقد عمال مزودة بـ GPU مع تكوين NVIDIA GPU Operator (أو ما يعادله)

واجهة سطر أوامر 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:

# استرجع القيمة الحالية، ادمج العلامة، ثم طبّق التغيير
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 حول تحضير صورة OCI تحتوي على بيانات النموذج. لعمليات نشر vLLM، أدرج أجزاء safetensors للنموذج واستبعد ملفات نقاط التفتيش القديمة مثل .bin و.pt وoriginal/*.

مثال على Dockerfile:

FROM busybox:latest

# أوزان النموذج -- أجزاء safetensors والفهرس
COPY <model-name>/model-*.safetensors        /models/
COPY <model-name>/model.safetensors.index.json /models/

# تكوين النموذج
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 push أو skopeo copy أو خط أنابيب CI وما إلى ذلك).

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

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

أنشئ فضاء الاسم:

oc new-project <namespace>

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

# سر السحب حتى يتمكن KServe من سحب صورة النموذج من سجلك الخاص
oc create secret docker-registry model-registry-secret \
  --docker-server=<registry> \
  --docker-username=<username> \
  --docker-password=<password-or-token> \
  -n <namespace>

أنشئ حساب خدمة:

# حساب الخدمة المستخدم من قِبل KServe predictor
oc create sa model-puller-sa -n <namespace>

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

# إرفاق سر السحب -- كلا الأمرين مطلوبان:
# oc secrets link يغطي استخدام السر العام؛
# imagePullSecrets مطلوب خصيصاً لحاوية تهيئة ModelCar في KServe
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>"          # مثلاً "8"
        limits:
          cpu: "<cpu-limit>"            # مثلاً "16"
          memory: <memory-limit>        # مثلاً 96Gi -- حجّم وفق متطلبات VRAM للنموذج
          nvidia.com/gpu: "<gpu-count>" # مثلاً "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"        # اقتطاع سطور سجل vLLM لتجنب الفيضان
        - 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>" # يجب مطابقة حد nvidia.com/gpu أعلاه
        - name: CUDA_VISIBLE_DEVICES
          value: "<gpu-indices>" # مثلاً "0" لـ GPU واحد؛ "0,1" لاثنين
        - 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 وسجلات وقت التشغيل:

# مراقبة InferenceService حتى يصل إلى حالة Ready
oc get inferenceservice <model-name> -n <namespace> -w

# مراقبة بدء تشغيل pod الـ predictor
oc get pods -n <namespace> -w

# تتبع سجلات الـ predictor (قد يستغرق تحميل النموذج عدة دقائق بعد التشغيل)
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` في الخطوة 3.
الـ 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 أو قلل طول السياق أو استخدم نموذجاً مكميًّا.
InferenceService تبقى في حالة `Pending`	موارد المجموعة غير متاحة	تحقق من توفر GPU وحرّر الموارد من أحمال العمل غير المستخدمة.

موارد إضافية

Red Hat OpenShift AI - Serving models

توثيق KServe

KServe ModelCar - تحزيم نماذج OCI

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

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

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

اتصال HTTPS صادر (المنفذ 443) من مجموعة Red Hat OpenShift Container Platform (OCP) إلى نقطة نهاية الخدمة السحابية.

مفاتيح API صالحة أو بيانات اعتماد IAM أو بيانات اعتماد مصادقة معادلة.

قبل البدء:

تأكد من:

أن نشر النموذج مُوفَّر ونشط.

أن بيانات اعتماد المصادقة مولَّدة ومخزَّنة بأمان.

استيفاء أي متطلبات شبكة أو وصول خاصة بالمزود.

بعد توفر نقطة النهاية، انتقل إلى تكوين بوابة استدلال النماذج.

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

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

خوادم GPU مخصصة

مجموعات OpenShift منفصلة

خوادم استدلال على الحديد المجرد

منصات AI للمؤسسات

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

نقطة نهاية النموذج تعرض API متوافقة مع OpenAI.

يوجد اتصال HTTPS بين مجموعة IBM Bob ونقطة النهاية.

بيانات اعتماد المصادقة متاحة كأسرار Kubernetes.

قبل البدء:

تحقق مما يلي:

اتصال الشبكة من المجموعة إلى نقطة النهاية.

تكوين TLS أو TLS المتبادل، إذا لزم.

سياسات الشبكة وجدران الحماية تسمح بالوصول.

مصادقة نقطة النهاية تعمل بشكل صحيح.

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

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

نشر النماذج باستخدام OpenShift AI (على المجموعة، OCI/ModelCar)

تكوين Red Hat OpenShift AI

تفعيل دعم ModelCar

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

موارد إضافية

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

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

في هذه الصفحة