Erfahre, wie du eine Model-Gateway-Konfigurationsdatei erstellst und verwaltest, einschließlich Provider-Einstellungen, Modelldefinitionen, Verwaltung von Anmeldeinformationen, TLS-Konfiguration und Deployment-Beispielen für unterstützte Modell-Provider.

Der Model Gateway ermöglicht es Bob self-hosted, Anfragen an unterstützte KI-Modelle verschiedener Provider zu verbinden und weiterzuleiten, darunter OpenAI-kompatible Endpoints, AWS Bedrock und Google Vertex AI. Eine Model-Gateway-Konfiguration definiert Modell-Endpoints, Authentifizierungseinstellungen, Routing-Verhalten und Modellfähigkeiten, während vertrauliche Anmeldeinformationen und Zertifikate sicher über config.yaml verwaltet werden.

Die Model-Gateway-Konfiguration ist eine YAML-Datei, die definiert, mit welchen Modellen sich der Gateway verbindet und wie er sich bei jedem Provider authentifiziert.

Modellspezifikation

Jeder Eintrag in der models-Liste muss einen eindeutigen model_name haben. Die vollständige Modellspezifikation lautet:

- model_name: example_model
  # Provider-Typen (wähle einen pro Modell):
  openai_compatible:  # — jeder OpenAI-kompatible REST-Endpoint (Azure, vLLM, …)
  bedrock:            # — AWS Bedrock invoke-Endpoint
  vertex:             # — Google Vertex AI (Gemini)

  # Modell-Metadaten
  model_info:
    exposed: true                         # true: sichtbar in der /v1/model/info-Liste; false: nur intern
    provider: openai                      # Modell-Provider (z. B. openai, anthropic, google, nvidia, mistral)
    family: gpt                           # Modellfamilie innerhalb des Providers (z. B. gpt, sonnet, gemini)
    version: "5.6-sol"                    # Modellversions-String (siehe Tabelle unten)
    max_input_tokens: 270000              # Größe des Kontextfensters
    max_output_tokens: 20000              # maximale Token, die das Modell generieren kann
    supports_prompt_caching: true         # true, wenn das Modell Prompt-Caching unterstützt
    supports_vision: true                 # true, wenn das Modell Bildeingaben unterstützt
    mode: chat                            # chat | embedding | image_generation

  # Optionale frei konfigurierbare Anfrageparameter, die an jede an den
  # Provider gesendete Anfrage angehängt werden, einschließlich Standardparameter (z. B. temperature, top_p,
  # max_tokens) und Provider-spezifische Erweiterungen (z. B. top_k,
  # repetition_penalty, anthropic_beta).
  chat_inference_params:
    temperature: 0.7
    top_p: 0.9

Hinweis:

Damit Benutzer Bildeingaben in der Chat-Oberfläche senden können, muss für das Core-Inferenz-Modell supports_vision: true im Block model_info festgelegt sein. Wenn dieses Flag fehlt oder false ist, ist die Bildeingabe nicht verfügbar.

Warnung:

Wenn supports_vision für ein Modell auf true gesetzt wird, das Bildeingaben tatsächlich nicht unterstützt, schlägt die Verwendung von Bildern mit einem Fehler des Providers fehl. Stelle sicher, dass dieses Flag nur für Modelle aktiviert ist, die Bildeingaben unterstützen. Beachte, dass die folgenden Modelle keine Bildeingaben unterstützen und supports_vision: false haben sollten: Laguna S2.1 und Nvidia Nemotron 3.

Unterstützte Werte für `provider` / `family` / `version`

Bob verwendet die Felder provider, family und version zusammen, um modellspezifisches Prompt-Tuning und Optimierungen auszuwählen. Verwende die am nächsten übereinstimmenden Werte für nicht aufgeführte Modelle.

`provider`	`family`	`version`	Beispiel-Modell-ID
`openai`	`gpt`	`5.6-sol`	`gpt-5.6-sol`
`openai`	`gpt-oss`	`20b`	`openai/gpt-oss-20b`
`anthropic`	`sonnet`	`5`	`us.anthropic.claude-sonnet-5`
`google`	`gemini`	`3.6-flash`	`gemini-3.6-flash`
`google`	`gemini`	`3.1-pro`	`gemini-3.1-pro`
`nvidia`	`nemotron`	`3-ultra`	`nvidia/nemotron-3-ultra-550b`
`mistral`	`medium`	`3.5`	`mistralai/mistral-medium-3-5-0`
`poolside`	`laguna`	`s2.1`	`poolside/laguna-s-2.1`

Reservierte Modellnamen-Slots

Die folgenden model_name-Werte müssen in deiner models-Liste vorhanden sein:

`model_name`	Verwendet für
`premium-ide`	Standardmodell für interaktiven Chat
`security`	Guardrail- / Sicherheitsprüfungen
`background`	Hintergrund- und autonome Agenten-Aufgaben

Das Template definiert security und background as YAML-Merge-Aliase des aktiven Modells, sodass sie alle automatisch derselben Provider-Konfiguration folgen. Für security und background wird ein kleineres und effizienteres Modell empfohlen, sofern verfügbar (zum Beispiel openai/gpt-oss-20b).

Provider

`openai_compatible`

Verbindet sich mit einem extern gehosteten Modell mit einer OpenAI-kompatiblen REST-API (z. B. Azure OpenAI, vLLM, benutzerdefinierte Endpoints).

- model_name: premium-ide
  openai_compatible:
    model: gpt-5.6-sol                     # Model ID as expected by the provider
    base_url: https://<resource>.cognitiveservices.azure.com/openai
    api_key: env.AZURE_API_KEY             # env.<VAR> reads from the model gateway secrets
    extra_headers:                         # Extra headers to include when inferencing
      example_header: env.HEADER_VALUE
    ca_cert_pem: env.CA_CERT               # CA certificate for TLS verification
  model_info:
    exposed: true
    provider: openai
    family: gpt
    version: "5.6-sol"
    max_input_tokens: 270000
    max_output_tokens: 20000
    supports_prompt_caching: true
    supports_vision: true
    mode: chat

`bedrock`

Verbindet sich mit einem über AWS Bedrock bereitgestellten Modell.

- model_name: premium-ide
  bedrock:
    model: us.anthropic.claude-sonnet-5    # Model ID as expected by the provider
    region: us-east-1                      # AWS region where your Bedrock endpoint lives
    access_key_id: env.AWS_ACCESS_KEY      # Bedrock Access Key ID
    secret_access_key: env.AWS_SECRET_ACCESS_KEY
  model_info:
    exposed: true
    provider: anthropic
    family: sonnet
    version: "5"
    max_input_tokens: 270000
    max_output_tokens: 20000
    supports_prompt_caching: true
    supports_vision: true
    mode: chat

`vertex`

Verbindet sich mit einem über Google Vertex AI (Gemini) bereitgestellten Modell. Anmeldeinformationen müssen als base64-kodierter Service-Account-JSON-String bereitgestellt werden.

- model_name: premium-ide
  vertex:
    model: gemini-3.6-flash                # Model ID as expected by the provider
    project: <gcp-project-id>              # GCP project ID
    location: global                       # Vertex AI region / "global" for Global API
    credentials: env.GEMINI_CREDENTIALS    # Service-account JSON, base64-encoded
  model_info:
    exposed: true
    provider: google
    family: gemini
    version: "3.6-flash"
    max_input_tokens: 270000
    max_output_tokens: 20000
    supports_prompt_caching: true
    supports_vision: true
    mode: chat

Router

Der Abschnitt routers konfiguriert die Modellauflösung zwischen dem Frontend und dem Backend. Das konfigurierte default_model ist das Haupt-LLM, das bei Chat-Interaktionen verwendet wird.

routers:
  - name: router
    strategy: static
    static:
      default_model: premium-ide   # must match a model_name in the models list

Feld	Beschreibung
`name`	Router-Name (verwende immer `router`)
`strategy`	Routing-Strategie. Derzeit wird nur `static` unterstützt
`static.default_model`	Der `model_name`, der als Haupt-LLM verwendet werden soll. Muss exakt mit einem `model_name`-Eintrag in der Liste `models` übereinstimmen

Hinweis:

premium-ide ist ein erforderlicher Modellname-Slot (siehe Reservierte Modellnamen-Slots), daher wird empfohlen, default_model: premium-ide beizubehalten und zu ändern, auf welchen Provider/Modell der Eintrag premium-ide in deiner models-Liste verweist.

YAML-Anker

Die Model-Gateway-Konfiguration unterstützt Standard-YAML-Anker (&name) und Merge-Keys (<<: *name). Das Template verwendet dies, um die Wiederverwendung zu unterstützen und Wiederholungen zu vermeiden.

x-providers:
  gemini: &gemini
    vertex:
      model: gemini-3.6-flash
      project: <gcp-project-id>
      location: global
      credentials: env.GEMINI_CREDENTIALS
    model_info:
      exposed: true
      provider: google
      family: gemini
      version: "3.6-flash"
      max_input_tokens: 270000
      max_output_tokens: 20000
      supports_prompt_caching: true
      supports_vision: true
      mode: chat

models:
  - &chat_llm
    <<: *gemini
    model_name: premium-ide

  - <<: *chat_llm
    model_name: security               # überschreibt premium-ide aus dem zusammengeführten Anker

  - <<: *chat_llm
    model_name: background

Verwaltung von Anmeldeinformationen und Secrets

Secrets

Für alle in der Modellkonfiguration referenzierten Secrets (API-Schlüssel, Passwörter, Zertifikate) konfiguriere sie in der Installations-config.yaml unter bob.modelGateway.secrets. Secrets werden zur Laufzeit in den Inferenz-Service-Container eingehängt.

bob:
  modelGateway:
    secrets:
      VAR_BAR_1: FOO_1
      VAR_BAR_2: FOO_2
      VAR_BAR_N: FOO_N

Referenziere ein Secret in der Modellkonfiguration mit der Syntax env.<VAR_NAME>:

api_key: env.VAR_BAR_1

TLS- und Zertifikatsanforderungen

Wenn du private Endpoints oder interne Modellserver verwendest (z. B. vLLM oder OpenShift AI mit benutzerdefinierten oder selbstsignierten Enterprise-Zertifikaten), musst du dein internes Root/Intermediate-CA-Zertifikat bereitstellen, damit Inferenz-Container TLS-Vertrauen herstellen können.

Hinweis:

Diese Modell-Endpoint-TLS-Konfiguration ist von dem Zertifikat getrennt, das Bob IDE und Bob Shell benötigen, um sich mit dem Bob-Backend zu verbinden. Für das Backend-Endpoint-Zertifikat und die Client-Trust-Schritte, siehe TLS-Zertifikate.

Es gibt zwei Möglichkeiten, eine CA für die Inferenz hinzuzufügen:

Option 1 — Inferenz-Trust-Bundle (empfohlen)

Füge die CA zu bob-inferencing-bundle-tls hinzu, indem du ein Kubernetes-Secret labelst. Der Operator erkennt das Label und erstellt das Bundle automatisch neu — es sind keine Änderungen an der Model-Gateway-Konfiguration erforderlich, und die CA steht allen Inferenz-Containern sofort zur Verfügung.

oc create secret generic my-model-endpoint-ca   --from-file=tls.crt=model-ca.crt   -n <instance-namespace>

oc label secret my-model-endpoint-ca   bob.ibm.com/inferencing-bundle-ca=true   -n <instance-namespace>

Das Secret bob-inferencing-bundle-tls wird als Trust-Store in die Inferenz-Container eingehängt. Es enthält immer den gesamten Inhalt von bob-bundle-tls plus alle zusätzlich gelabelten Secrets. Ein Neustart des Pods ist nicht erforderlich — Secrets werden direkt in den laufenden Container projiziert.

Ausführliche Details und Verifizierungsschritte findest du unter TLS-Zertifikate.

Option 2 — CA-Zertifikat pro Modell über `ca_cert_pem` (Model-Gateway-Konfiguration)

Verwende diese Option, wenn du eine CA für einen einzelnen spezifischen Modell-Endpoint bereitstellen möchtest, ohne andere Inferenz-Container zu beeinflussen. Benutzerdefinierte TLS-Zertifikate folgen demselben Zwei-Datei-Verteilungskonfigurationsmuster wie API-Anmeldeinformationen:

In model-gateway.yaml: Setze ca_cert_pem auf einen Umgebungsvariablennamen (z. B. env.CA_CERT).

In config.yaml: Füge den passenden Variablennamen unter bob.modelGateway.secrets hinzu und füge den vollständigen PEM-kodierten Zertifikats-String ein.

1. Model-Gateway-Konfiguration (model-gateway.yaml):

models:
  - model_name: example-model
    openai_compatible:
      model: mistral-3.5
      base_url: https://vllm.internal.corp:8000/v1
      api_key: env.MODEL_API_KEY
      ca_cert_pem: env.CA_CERT           # Points to the variable name defined in config.yaml
    model_info:
      exposed: true
      mode: chat

2. Installations-Config (config.yaml):

bob:
  modelGateway:
    secrets:
      MODEL_API_KEY: "<your-api-key>"
      # The actual PEM certificate content matching env.CA_CERT above:
      CA_CERT: |
        -----BEGIN CERTIFICATE-----
        MIIFazCCA1OgAwIBAgIRAIIQjJaDSmJT3g4qg05...
        ... [full PEM-encoded CA certificate data] ...
        -----END CERTIFICATE-----

Während des Deployments injiziert bobctl CA_CERT in das Kubernetes-Secret bob-inference-model-secrets. Dieses wird dann in den Inferenz-Gateway-Service eingehängt und für den TLS-Handshake gegen deinen privaten Modellserver verwendet.

Vollständiges Beispiel

Das folgende ist ein vollständiges Beispiel, das die Struktur von config-model-gateway-template.yaml aus dem Bob-Bundle widerspiegelt. Speichere es in einer Datei (z. B. /tmp/example/model-gateway.yaml) und referenziere es zum Installationszeitpunkt.

Model-Gateway-Konfiguration

# ── Provider-Definitionen ─────────────────────────────────────────────────────
# Der Schlüssel x-providers wird vom Model Gateway ignoriert — er dient als
# YAML-Notizblock für Provider-Beispiele. Unten wird nur der Anker des aktiven Providers referenziert.
x-providers:

  # AWS Bedrock
  bedrock: &bedrock
    bedrock:
      model: us.anthropic.claude-sonnet-5
      region: us-east-1
      access_key_id: env.AWS_ACCESS_KEY
      secret_access_key: env.AWS_SECRET_ACCESS_KEY
    model_info:
      exposed: true
      provider: anthropic
      family: sonnet
      version: "5"
      max_input_tokens: 270000
      max_output_tokens: 20000
      supports_prompt_caching: true
      supports_vision: true
      mode: chat

  # Google Vertex AI (Gemini)
  gemini: &gemini
    vertex:
      model: gemini-3.6-flash
      project: <gcp-project-id>
      location: global
      credentials: env.GEMINI_CREDENTIALS
    model_info:
      exposed: true
      provider: google
      family: gemini
      version: "3.6-flash"
      max_input_tokens: 270000
      max_output_tokens: 20000
      supports_prompt_caching: true
      supports_vision: true
      mode: chat

  # Azure OpenAI
  azure: &azure
    openai_compatible:
      model: gpt-5.6-sol
      base_url: https://<resource>.cognitiveservices.azure.com/openai
      api_key: env.AZURE_API_KEY
    model_info:
      exposed: true
      provider: openai
      family: gpt
      version: "5.6-sol"
      max_input_tokens: 270000
      max_output_tokens: 20000
      supports_prompt_caching: true
      supports_vision: true
      mode: chat

  # Benutzerdefinierter Inferenz-Service (RHOAI, vLLM, etc.)
  inference_service: &isvc
    openai_compatible:
      model: nvidia/nemotron-3-ultra-550b
      base_url: https://<llm-inference-server>
      api_key: env.INFERENCE_API_KEY
    model_info:
      exposed: true
      provider: nvidia
      family: nemotron
      version: "3-ultra"
      max_input_tokens: 262144
      supports_vision: false
      mode: chat

# ── Modelle ───────────────────────────────────────────────────────────────────
models:

  # ── AKTIVES MODELL ──────────────────────────────────────────────────────────
  # Ändere <<: *bedrock in z. B. *azure, *gemini oder *isvc, um den Provider zu wechseln.
  - &chat_llm
    <<: *bedrock                       # ← Provider hier ändern
    model_name: premium-ide
    model_info:
      exposed: true

  # ── Aliase ──────────────────────────────────────────────────────────────────
  - <<: *chat_llm
    model_name: security               # überschreibt premium-ide aus dem zusammengeführten Anker

  - <<: *chat_llm
    model_name: background

# ── Router ────────────────────────────────────────────────────────────────────
routers:
  - name: router
    strategy: static
    static:
      default_model: premium-ide

Secrets (`config.yaml`)

bob:
  modelGateway:
    secrets:
      AWS_ACCESS_KEY: "<your-aws-access-key-id>"
      AWS_SECRET_ACCESS_KEY: "<your-aws-secret-access-key>"
      GEMINI_CREDENTIALS: "<base64-encoded service-account JSON>"
      AZURE_API_KEY: "<your-azure-api-key>"
      INFERENCE_API_KEY: "<your-inference-api-key>"
      CA_CERT: <PEM encoded CA cert>

Installationsbefehl

bobctl install --model-config /tmp/example/model-gateway.yaml --accept-license --registry-creds <username:password>

In einer vernetzten Umgebung musst du deinen Entitling-Key für icr.io angeben. --registry-creds darf nur weggelassen werden, wenn du eine private Registry verwendest, die keine Authentifizierung zum Abrufen erfordert.

Konfiguration deployen

Während der Erstinstallation

Übergib den Pfad zu deiner Model-Gateway-Konfigurationsdatei mit dem Flag --model-config zum Installationszeitpunkt:

bobctl install --model-config path/to/model-gateway-config.yaml --accept-license --registry-creds <username:password>

Warnung:

Wenn bobctl install ohne --model-config ausgeführt wird, wird Bob mit einer leeren Model-Gateway-Konfiguration installiert. Der Inferenz-Service läuft, hat aber keine Verbindung zu einem Modell für Inferenz. Verwende bobctl update-model-config nach der Installation, um eine Modellkonfiguration in den Cluster zu laden.

Wie Anmeldeinformationen im Cluster deployed werden

Die Model-Gateway-Konfigurationsdatei referenziert Anmeldeinformationen als Umgebungsvariablen (z. B. env.AWS_ACCESS_KEY, env.AZURE_API_KEY). Verschiedene Modell-Provider erfordern unterschiedliche Secrets — AWS-IAM-Schlüssel für Bedrock, API-Schlüssel für Azure OpenAI oder Service-Account-JSON für Google Gemini.

Während der Installation werden diese Anmeldeinformationen in deiner config.yaml unter bob.modelGateway.secrets bereitgestellt. Die bobctl-CLI verarbeitet diesen Abschnitt automatisch und erstellt ein Kubernetes-Secret namens bob-inference-model-secrets im Cluster, wobei die Schlüssel als Umgebungsvariablen direkt im Inferenz-Gateway-Service-Container eingehängt werden.

bob:
  modelGateway:
    secrets:
      # AWS Bedrock-Authentifizierung
      AWS_ACCESS_KEY: "<your-aws-access-key-id>"
      AWS_SECRET_ACCESS_KEY: "<your-aws-secret-access-key>"

      # Azure OpenAI-Authentifizierung
      AZURE_API_KEY: "<your-azure-api-key>"

      # Google Cloud Vertex AI / Gemini-Authentifizierung
      GEMINI_CREDENTIALS: "<your-gemini-credentials-json>"

      # Eigene API-Schlüssel / Token für Endpunkte oder interne Proxy-Authentifizierung
      # RITS_APIKEY: "<your-api-key>"

      # Eigenes CA-Zertifikat im PEM-Format für selbstsignierte interne Endpunkte
      # CA_CERT: |
      #   -----BEGIN CERTIFICATE-----
      #   ...
      #   -----END CERTIFICATE-----

Konfiguration nach der Installation aktualisieren (`bobctl update-model-config`)

Verwende bobctl update-model-config, um eine Model-Gateway-Konfiguration und/oder Secrets in einen laufenden Cluster zu laden, ohne ihn neu zu installieren. Dies ist der erforderliche Weg, wenn bobctl install ohne --model-config ausgeführt wurde, und derselbe Befehl, der beim Wechsel des Core-Inferenz-Modells verwendet wird.

Unter der Haube führt der Befehl helm template gegen die Templates model-config.yaml und model-secrets.yaml im lokalen ibm-bob-Chart aus und wendet die gerenderten Manifeste dann auf den Cluster an. Nach dem Anwenden gleicht der ibm-bob-operator das Deployment bob-inference mit der neuen Modellkonfiguration ab.

Der Befehl verwaltet zwei separate Cluster-Ressourcen:

Flag	Cluster-Ressource	Quelle
`--model-config <datei>`	`ConfigMap` `bob-inference-model-config`	Die übergebene Datei
`--update-secrets`	`Secret` `bob-inference-model-secrets`	`bob.modelGateway.secrets` in `config.yaml`

Mindestens eines der beiden muss angegeben werden — keines anzugeben ist ein Fehler.

Voraussetzungen:

Du musst im Cluster angemeldet sein (oc login)

config.yaml must be present next to bobctl (aus config-template.yaml kopieren)

helm ≥ 3.14.0 muss in deinem PATH vorhanden sein

Häufige Verwendung:

# Nur die Modellkonfigurationsdatei aktualisieren
bobctl update-model-config --model-config ./my-model-config.yaml

# Nur die Secrets aktualisieren (Schlüssel kommen aus config.yaml)
bobctl update-model-config --update-secrets

# Beides auf einmal aktualisieren
bobctl update-model-config --model-config ./my-model-config.yaml --update-secrets

# Vorschau der geplanten Änderungen anzeigen, ohne den Cluster zu berühren
bobctl update-model-config --model-config ./my-model-config.yaml --update-secrets --dry-run

Alle Flags:

Flag	Standard	Beschreibung
`--model-config <datei>`		Pfad zur Modellkonfigurationsdatei, die in die ConfigMap geladen werden soll
`--update-secrets`		`bob.modelGateway.secrets` aus `config.yaml` in das Secret laden
`--output-config <datei>`	`model-gateway-config.yaml`	Zieldatei für das gerenderte ConfigMap-Manifest
`--output-secret <datei>`	`model-gateway-secret.yaml`	Zieldatei für das gerenderte Secret-Manifest
`--cleanup`	false	Die gerenderten Manifest-Dateien nach dem Anwenden löschen
`--dry-run`	false	Ausgabe der geplanten Aktionen ohne Ausführung von `oc`-Befehlen

Model Gateway konfigurieren

Modellspezifikation

Unterstützte Werte für `provider` / `family` / `version`

Reservierte Modellnamen-Slots

Provider

`openai_compatible`

`bedrock`

`vertex`

Router

YAML-Anker

Verwaltung von Anmeldeinformationen und Secrets

Secrets

TLS- und Zertifikatsanforderungen

Option 1 — Inferenz-Trust-Bundle (empfohlen)

Option 2 — CA-Zertifikat pro Modell über `ca_cert_pem` (Model-Gateway-Konfiguration)

Vollständiges Beispiel

Model-Gateway-Konfiguration

Secrets (`config.yaml`)

Installationsbefehl

Konfiguration deployen

Während der Erstinstallation

Wie Anmeldeinformationen im Cluster deployed werden

Konfiguration nach der Installation aktualisieren (`bobctl update-model-config`)

Auf dieser Seite