البنية التحتية لخدمة النماذج
تعرّف على كيفية نشر وتكوين نقاط نهاية النماذج عندما لا توفر بيئتك بالفعل حلاً لخدمة النماذج.
قبل أن تتمكن من ربط 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)، إذا لزم الأمر.
- سياسات الشبكة وجدران الحماية تسمح بالوصول.
- مصادقة نقطة النهاية تعمل بشكل صحيح.
بعد التحقق من الاتصال والمصادقة، تابع إلى تكوين بوابة النماذج.