Erfahre, wie du Modell-Endpoints deployest und konfigurierst, wenn deine Umgebung noch keine Modell-Serving-Lösung bereitstellt.

Bevor du IBM Bob mit einem Large Language Model (LLM) verbinden kannst, musst du Zugang zu einem deployten Modell-Endpoint haben. Bob stellt keine Modell-Serving-Infrastruktur bereit, hostet sie oder verwaltet sie. Wenn deine Organisation bereits Modell-Endpoints über OpenShift AI, GPU-basierte Inferenzserver, Cloud-KI-Dienste oder andere Inferenzplattformen bereitstellt, fahre direkt mit Model Gateway konfigurieren fort.

Deployment-Optionen

Wähle die Option, die am besten zu deiner Umgebung und deinen betrieblichen Anforderungen passt.

Option	Verwendung wenn
OpenShift AI (on-cluster, OCI/ModelCar)	Air-Gapped- oder selbst gehostete Modelle; RHOAI bereits auf dem Cluster verfügbar
Public Cloud	Frontier-Modelle über AWS Bedrock, Azure OpenAI oder Google Vertex AI
Private Infrastruktur	Modell auf separaten GPU-Servern oder einem dedizierten Inferenz-Cluster

OpenShift AI (on-cluster, OCI/ModelCar)

Red Hat OpenShift AI (RHOAI) ist die empfohlene Plattform für das On-Cluster-Serving von Modellen, einschließlich Air-Gapped-Deployments. Der bevorzugte Ansatz zum Laden von Modellgewichten ist das OCI/ModelCar-Muster: Modelldateien werden in ein OCI-Image unter /models/ gepackt und in eine private Registry übertragen. Wenn der InferenceService deployed wird, injiziert KServe einen modelcar-init-Init-Container, der das Image abruft und die Gewichte in ein gemeinsames Volume unter /mnt/models/ kopiert, von dem die Serving-Runtime (z. B. vLLM) dann lädt. Das Modell-Image wird nach dem ersten Abruf auf dem Node zwischengespeichert — nachfolgende Neustarts auf demselben Node überspringen den Download vollständig.

Voraussetzungen:

Red Hat OpenShift AI-Operator auf dem Cluster installiert

KServe aktiviert und konfiguriert

GPU-fähige Worker-Nodes mit konfiguriertem NVIDIA-GPU-Operator (oder gleichwertig)

oc-CLI beim Ziel-Cluster authentifiziert mit Berechtigung zur Ressourcenerstellung im Ziel-Namespace

Eine private Container-Registry, die vom Cluster aus erreichbar ist, mit Anmeldeinformationen zum Übertragen von Images

Red Hat OpenShift AI konfigurieren

Konfiguriere die Ressourcen DataScienceClusterInitialization und DataScienceCluster wie folgt:

serviceMesh deaktivieren.

KServe aktivieren, indem managementState: Managed gesetzt wird.

KServe für den RawDeployment-Modus konfigurieren.

Alle ungenutzten Red Hat OpenShift AI-Komponenten entfernen.

Beispiel-KServe-Konfiguration:

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

ModelCar-Unterstützung aktivieren

Die ModelCar-Unterstützung wird über die ConfigMap inferenceservice-config im Namespace redhat-ods-applications gesteuert. Der Schlüssel storageInitializer muss "enableModelcar": true enthalten.

Aktuelle Konfiguration überprüfen:

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

Die Ausgabe muss Folgendes enthalten:

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

Wenn enableModelcar fehlt oder false ist, aktualisiere die 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()))')}}"

Starte den KServe-Controller neu, um die Änderung anzuwenden:

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

Modelldateien in ein OCI-Image packen

Lade die Modellgewichte von Hugging Face herunter und packe sie in ein OCI-Image. Das Image muss alle Modelldateien unter dem Verzeichnis /models enthalten. Weitere Informationen findest du in der KServe-Dokumentation. Für vLLM-Deployments die safetensors-Modell-Shards einschließen und Legacy-Checkpoint-Dateien wie .bin, .pt und original/* ausschließen.

Beispiel-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/

Wenn das Modell ein Chat-Template enthält (z. B. chat_template.jinja), füge es hinzu. Alternativ kopiere das gesamte Verzeichnis in einer Anweisung — einfacher, aber schließt Dateien ein, die vLLM nicht benötigt:

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

Image in eine private Registry übertragen

Übertrage das OCI-Image in eine private Container-Registry, die vom Cluster aus erreichbar ist:

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

Du kannst jedes unterstützte Image-Management-Tool verwenden, einschließlich:

Podman
Skopeo
CI/CD-Pipelines
Registry-spezifische Tools

Ziel-Namespace und Image-Pull-Secret erstellen

Erstelle den Projekt-Namespace und konfiguriere Anmeldeinformationen für das Abrufen des Modell-Images:

oc new-project <namespace>

Registry-Pull-Secret erstellen:

# 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 erstellen:

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

Pull-Secret mit dem Service Account verknüpfen:

# 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"}]}'

Hinweis:

Beide Befehle sind erforderlich. Der Eintrag imagePullSecrets wird vom ModelCar-Initialisierungs-Container während des Modell-Image-Abrufs verwendet.

ServingRuntime erstellen

Eine vLLM-basierte ServingRuntime im Ziel-Namespace deployen:

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

Runtime-Konfiguration anwenden:

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

InferenceService deployen

Erstelle einen InferenceService, der das OCI-Modell-Image mit einem oci://-Storage-URI referenziert.

Wichtige Konfigurationsanforderungen:

Referenziere die zuvor erstellte ServingRuntime.
Gib den OCI-Image-Speicherort in storageUri an.
Konfiguriere CPU-, Speicher- und GPU-Ressourcenlimits, die den Modell-Anforderungen entsprechen.
Hänge geteilten Arbeitsspeicher (/dev/shm) für vLLM ein.
Konfiguriere vLLM-Laufzeitargumente und Umgebungsvariablen.

Beispiel:

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-Manifest anwenden:

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

Deployment überprüfen

Deployment-Status, Pod-Start und Laufzeit-Logs überwachen:

# 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>

Wenn der InferenceService READY: True meldet, validiere den Endpoint.

Modellregistrierung überprüfen und eine Test-Inferenz-Anfrage senden:

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
  }'

Fehlerbehebung

Problem	Mögliche Ursache	Lösung
`ErrImagePull`	Fehlende oder ungültige Registry-Anmeldeinformationen	Bestätige, dass `model-registry-secret` vorhanden ist, gültige Anmeldeinformationen hat und mit `model-puller-sa` über sowohl `oc secrets link` als auch den `imagePullSecrets`-Patch verknüpft ist.
`ImagePullBackOff`	Image-Pull-Secret nicht für ModelCar konfiguriert	Stelle sicher, dass der Service Account die `imagePullSecrets`-Konfiguration enthält. Führe `oc patch serviceaccount model-puller-sa -n <namespace> -p '{"imagePullSecrets": [{"name": "model-registry-secret"}]}'` aus.
Predictor verbleibt in `Init:0/1`	Modell-Image-Download läuft	Überprüfe `oc describe pod`-Events auf `Pulling`/`Pulled`-Fortschritt; die Pull-Zeit skaliert mit Image-Größe und Registry-Bandbreite.
Predictor verbleibt dauerhaft in `Init:0/1`	Modelldateien nicht gefunden	Überprüfe, ob Modelldateien unter `/models` im OCI-Image gespeichert sind.
`Engine core initialization failed`	Initiales CUDA-Kompilierungs-Timeout	Der erste Start kann länger dauern, während Caches generiert werden. Neu starten und wiederholen.
Modell-Laden schlägt fehl	Nicht unterstütztes Modelldateiformat	Hugging-Face-safetensors-Dateien verwenden und Legacy-Checkpoints ausschließen.
OpenSSL-FIPS-Selbsttestfehler	Container-Image ist nicht FIPS-kompatibel	Ein FIPS-kompatibles vLLM-Image verwenden.
`OutOfMemory` / `OOMKilled`	Unzureichender GPU-Speicher	GPU-Ressourcen erhöhen, Kontextlänge reduzieren oder ein quantisiertes Modell verwenden.
InferenceService verbleibt in `Pending`	Cluster-Ressourcen nicht verfügbar	GPU-Verfügbarkeit überprüfen und Ressourcen von ungenutzten Workloads freigeben.

Weitere Informationen findest du unter:

Red Hat OpenShift AI — Serving models

KServe-Dokumentation

KServe ModelCar — OCI-Modell-Packaging

Public-Cloud-Modell-Endpoints

Verwende diese Option, wenn Modelle von einem Cloud-Provider gehostet werden, z. B. IBM watsonx, AWS Bedrock, Azure OpenAI oder Google Vertex AI.

Voraussetzungen:

Ausgehende HTTPS-Konnektivität (Port 443) vom OpenShift-Cluster zum Cloud-Service-Endpoint.

Gültige API-Schlüssel, IAM-Anmeldeinformationen oder gleichwertige Authentifizierungsnachweise.

Vor der Konfiguration von IBM Bob

Stelle sicher, dass:

Das Modell-Deployment bereitgestellt und aktiv ist.

Authentifizierungsnachweise generiert und sicher gespeichert sind.

Alle provider-spezifischen Netzwerk- oder Zugriffsanforderungen erfüllt sind.

Nachdem der Endpoint verfügbar ist, fahre mit Model Gateway konfigurieren fort.

Private-Infrastruktur-Modell-Endpoints

Verwende diese Option, wenn Modelle auf kundenverwalteter Infrastruktur außerhalb des IBM-Bob-Clusters gehostet werden, z. B.:

Dedizierte GPU-Server

Separate OpenShift-Cluster

Bare-Metal-Inferenzserver

Enterprise-KI-Plattformen

Voraussetzungen:

Der Modell-Endpoint stellt eine OpenAI-kompatible API bereit.

HTTPS-Konnektivität zwischen dem IBM-Bob-Cluster und dem Endpoint ist vorhanden.

Authentifizierungsnachweise sind als Kubernetes-Secrets verfügbar.

Vor der Konfiguration von IBM Bob

Überprüfe Folgendes:

Netzwerkkonnektivität vom Cluster zum Endpoint.

TLS- oder Mutual-TLS-Konfiguration, falls erforderlich.

Netzwerkrichtlinien und Firewalls erlauben Zugriff.

Endpoint-Authentifizierung funktioniert korrekt.

Nachdem Konnektivität und Authentifizierung verifiziert sind, fahre mit Model Gateway konfigurieren fort.

Modell-Serving-Infrastruktur

Auf dieser Seite