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 On-Premises, 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, Fallback-Optionen 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.

Warnung:

Konfiguriere jeweils nur ein Core-Inferenz-Modell im Model Gateway. Die gleichzeitige Konfiguration mehrerer Core-Modelle wird nicht unterstützt und führt zu undefiniertem Verhalten.

Modellspezifikation

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

- model_name: example_model
  # Provider types (pick one per model):
  openai_compatible:  # — any OpenAI-compatible REST endpoint (Azure, …)
  bedrock:            # — AWS Bedrock invoke endpoint
  vertex:             # — Google Vertex AI (Gemini)

  # Model info parameters (optional)
  model_info:
    exposed: true                          # true: visible in /models list; false: internal-only
    max_input_tokens: 128000               # context window size
    max_output_tokens: 4096                # maximum tokens the model may generate
    input_cost_per_token: 0.0000025        # cost in USD per input token (used for usage metering)
    output_cost_per_token: 0.000010        # cost in USD per output token
    cache_read_input_token_cost: 0.00      # cost for cache-hit input tokens (prompt caching)
    cache_creation_input_token_cost: 0.00  # cost to write a new cache entry
    supports_prompt_caching: true          # true if the model supports prompt caching
    supports_function_calling: true        # true if the model supports tool/function calls
    supports_tool_choice: true             # true if tool_choice param is honoured
    supports_reasoning: false              # true if the model supports a reasoning_effort param
    supports_vision: false                 # true if the model accepts image inputs in chat messages
    mode: chat                             # chat | embedding | image_generation

  # Optional ordered list of model_name values to try when this model is unavailable
  fallbacks:
    - fallback_model

  # Optional free-form request parameters appended to every request sent to
  # the provider, including standard parameters (e.g. temperature, top_p,
  # max_tokens) and provider-specific extensions (e.g. top_k,
  # repetition_penalty, anthropic_beta).
  chat_inference_params:
    temperature: 0.7
    top_p: 0.9

Warnung:

Setze supports_vision: true nur für Modelle, die Bildeingaben akzeptieren. Wenn supports_vision für ein Modell, das keine Bildeingaben unterstützt, auf true gesetzt wird, führt das Senden eines Bildes im Chat zu einem Provider-Fehler. Die folgenden Modelle unterstützen keine Bildeingaben und müssen supports_vision: false verwenden oder das Flag weglassen: Laguna S2.1 und Nvidia Nemotron 3.

Provider

`openai_compatible`

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

openai_compatible:
  model: gpt-4o                          # Model ID as expected by the provider
  base_url: https://base_url             # Base URL of model deployment
  api_key: env.API_KEY                   # API key to authenticate. env.<VAR> reads from the container environment
  extra_headers:                         # Extra headers to include when inferencing
    example_header: env.HEADER_VALUE
  insecure_skip_verify: true             # Disable TLS verification (not recommended for production)
  ca_cert_pem: env.CA_CERT               # CA certificate for TLS verification

`bedrock`

Verbindet sich mit einem über AWS Bedrock bereitgestellten Modell.

bedrock:
  model: claude                                  # 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   # Bedrock Secret Access Key

`vertex`

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

vertex:
  model: gemini                              # Model ID as expected by the provider
  project: my-gcp-project                    # GCP project ID
  location: global                           # Vertex AI region / "global" for Global API
  credentials: env.GEMINI_CREDENTIALS        # Service-account JSON, base64-encoded

YAML-Anker

Anmeldeinformations-Anker

Definiere Anmeldeinformationen einmal und referenziere sie mit <<: *anchor-name über mehrere Modelleinträge hinweg, um Wiederholungen zu vermeiden.

# AWS Bedrock credentials — referenced by bedrock models.
x-aws-bedrock-auth: &aws-bedrock-auth
  region: us-east-1
  access_key_id: env.AWS_ACCESS_KEY
  secret_access_key: env.AWS_SECRET_ACCESS_KEY

models:
  - model_name: my-bedrock-model
    bedrock:
      model: claude
      <<: *aws-bedrock-auth            # merge credentials anchor defined above
    model_info:
      exposed: true
      mode: chat

Modell-Anker

Füge einen vollständigen Modellblock über mehrere Einträge zusammen, um die Wiederholung von Provider-Konfigurationen und model_info zu vermeiden.

x-my-base-model: &my-base-model
  vertex:
    model: gemini-2.5-pro
    project: my-gcp-project
    location: global
    credentials: env.GEMINI_CREDENTIALS
  model_info:
    exposed: false
    supports_reasoning: true
    mode: chat

models:
  - model_name: my-gemini-model
    <<: *my-base-model

  - model_name: my-second-gemini-model
    <<: *my-base-model

Verwaltung von Anmeldeinformationen und Secrets

Secrets

Für alle im Modell-Config 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

Das Root-CA-Bundle enthält Standard-Public-CA-Zertifikate für Cloud-Provider. Wenn du jedoch 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, um TLS-Vertrauen herzustellen.

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.

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.

Model-Gateway-Konfiguration:

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

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 alle Provider-Typen abdeckt. Speichere die Model-Gateway-Konfiguration in einer Datei (z. B. /tmp/example/model-gateway.yaml) und referenziere sie zum Installationszeitpunkt.

Model-Gateway-Konfiguration (/tmp/example/model-gateway.yaml)

# ── Credential anchors (shared across model entries via YAML merge keys) ──────
# AWS Bedrock credentials
x-aws-bedrock-auth: &aws-bedrock-auth
  region: us-east-1
  access_key_id: env.AWS_ACCESS_KEY
  secret_access_key: env.AWS_SECRET_ACCESS_KEY

# Google Vertex AI credentials
x-vertex-auth: &vertex-auth
  project: my-gcp-project
  location: global
  credentials: env.GEMINI_CREDENTIALS

# ── Shared model anchors (optional) ───────────────────────────────────────────
x-my-base-model: &my-base-model
  vertex:
    model: gemini-2.5-pro
    <<: *vertex-auth
  model_info:
    exposed: true
    max_input_tokens: 200000
    max_output_tokens: 12000
    input_cost_per_token: 0.00000125
    output_cost_per_token: 0.00001
    cache_read_input_token_cost: 0.000000125
    supports_reasoning: true
    mode: chat

# ── Models ────────────────────────────────────────────────────────────────────
models:
  # OpenAI-compatible model (e.g. Azure OpenAI) with API key
  - model_name: my-gpt-model
    openai_compatible:
      model: gpt-4o
      base_url: https://<resource>.cognitiveservices.azure.com/openai
      api_key: env.BOB_AZURE_API_KEY
    model_info:
      exposed: true
      max_input_tokens: 128000
      max_output_tokens: 4096
      input_cost_per_token: 0.0000025
      output_cost_per_token: 0.000010
      supports_function_calling: true
      supports_tool_choice: true
      mode: chat
    chat_inference_params:
      temperature: 0.7
      top_p: 0.9

  # AWS Bedrock model
  - model_name: my-bedrock-model
    bedrock:
      model: us.anthropic.claude-3-5-sonnet-20241022-v2:0
      <<: *aws-bedrock-auth
    fallbacks:                          # optional: ordered list of fallback model names
      - my-fallback-model
    model_info:
      exposed: false
      max_input_tokens: 200000
      max_output_tokens: 8192
      input_cost_per_token: 0.000003
      output_cost_per_token: 0.000015
      cache_creation_input_token_cost: 0.00000375
      cache_read_input_token_cost: 0.0000003
      supports_prompt_caching: true
      supports_function_calling: true
      supports_tool_choice: true
      mode: chat
    chat_inference_params:
      temperature: 0.7
      top_k: 50

  # Google Vertex AI (Gemini) model using shared model anchor
  - model_name: my-gemini-model
    <<: *my-base-model

  # OpenAI-compatible model with custom CA certificate
  - model_name: example-model-mini
    openai_compatible:
      model: gpt-4o-mini
      base_url: https://llm-mock-server.ca-tor.containers.appdomain.cloud
      ca_cert_pem: env.CA_CERT
    model_info:
      exposed: true
      max_input_tokens: 131072
      input_cost_per_token: 0.00000015
      output_cost_per_token: 0.0000006
      supports_function_calling: true
      supports_tool_choice: true
      mode: chat

  # OpenAI-compatible model with extra headers
  - model_name: another-example-model-mini
    openai_compatible:
      model: gpt-4o-mini
      base_url: https://llm-mock-server.ca-tor.containers.appdomain.cloud
      extra_headers:
        model_key: env.MODEL_KEY
    model_info:
      exposed: true
      max_input_tokens: 131072
      input_cost_per_token: 0.00000015
      output_cost_per_token: 0.0000006
      supports_function_calling: true
      supports_tool_choice: true
      mode: chat

Secrets (config.yaml)

bob:
  modelGateway:
    secrets:
      BOB_AZURE_API_KEY: someapikeyvalue
      AWS_ACCESS_KEY: someapikeyvalue
      AWS_SECRET_ACCESS_KEY: someapikeyvalue
      GEMINI_CREDENTIALS: <base64_vertex_credentials>
      CA_CERT: <PEM encoded CA cert>
      MODEL_KEY: apikeyvalue

Installationsbefehl

bobctl install --model-config /tmp/example/model-gateway.yaml

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

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.BOB_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 authentication
      AWS_ACCESS_KEY: "<your-aws-access-key-id>"
      AWS_SECRET_ACCESS_KEY: "<your-aws-secret-access-key>"

      # Azure OpenAI authentication
      BOB_AZURE_API_KEY: "<your-azure-api-key>"

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

      # Custom endpoint API keys / tokens or internal proxy auth
      # RITS_APIKEY: "<your-api-key>"

      # Custom CA certificate in PEM format for self-signed internal endpoints
      # 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.

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 muss neben bobctl vorhanden sein (aus config-template.yaml kopieren)

helm ≥ 3.14.0 muss in deinem PATH vorhanden sein

Häufige Verwendung:

# Update only the model config file
bobctl update-model-config --model-config ./my-model-config.yaml

# Update only the secrets (keys come from config.yaml)
bobctl update-model-config --update-secrets

# Update both at once
bobctl update-model-config --model-config ./my-model-config.yaml --update-secrets

# Preview what would be applied without touching the cluster
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

Provider

`openai_compatible`

`bedrock`

`vertex`

YAML-Anker

Anmeldeinformations-Anker

Modell-Anker

Verwaltung von Anmeldeinformationen und Secrets

Secrets

TLS- und Zertifikatsanforderungen

Vollständiges Beispiel

Konfiguration deployen

Während der Erstinstallation

Wie Anmeldeinformationen im Cluster deployed werden

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

Auf dieser Seite