Découvrez comment créer et gérer un fichier de configuration pour le Model Gateway, y compris les paramètres des fournisseurs, les définitions de modèles, la gestion des identifiants, la configuration TLS et des exemples de déploiement pour les fournisseurs de modèles pris en charge.

Le Model Gateway permet à Bob on-premises de se connecter et d'acheminer les requêtes vers les modèles d'IA pris en charge par différents fournisseurs, notamment les endpoints compatibles OpenAI, AWS Bedrock et Google Vertex AI. Une configuration du Model Gateway définit les endpoints de modèles, les paramètres d'authentification, le comportement de routage et les fonctionnalités des modèles, tandis que les identifiants sensibles et les certificats sont gérés en toute sécurité via config.yaml.

La configuration du model gateway est un fichier YAML qui définit les modèles auxquels la passerelle se connecte et la manière de s'authentifier auprès de chaque fournisseur.

Avertissement :

Configurez un seul modèle d'inférence principal dans le model gateway à la fois. La configuration simultanée de plusieurs modèles principaux n'est pas prise en charge et entraîne un comportement indéfini.

Spécification du modèle

Chaque entrée de la liste models doit avoir un model_name unique. La spécification complète du modèle est :

- model_name: example_model
  # Types de fournisseurs (en choisir un par modèle) :
  openai_compatible:  # — tout endpoint REST compatible OpenAI (Azure, vLLM, …)
  bedrock:            # — endpoint d'appel AWS Bedrock
  vertex:             # — Google Vertex AI (Gemini)

  # Métadonnées du modèle
  model_info:
    exposed: true                         # true : visible dans la liste /v1/model/info ; false : usage interne uniquement
    provider: openai                      # fournisseur de modèle (par ex. openai, anthropic, google, nvidia, mistral)
    family: gpt                           # famille de modèle chez le fournisseur (par ex. gpt, sonnet, gemini)
    version: "5.6-sol"                    # chaîne de version du modèle (voir tableau ci-dessous)
    max_input_tokens: 270000              # taille de la fenêtre de contexte
    max_output_tokens: 20000              # nombre maximal de tokens que le modèle peut générer
    supports_prompt_caching: true         # true si le modèle prend en charge le prompt caching
    supports_vision: true                 # true si le modèle prend en charge les entrées d'images
    mode: chat                            # chat | embedding | image_generation

  # Paramètres de requête de forme libre facultatifs ajoutés à chaque requête envoyée
  # au fournisseur, y compris les paramètres standards (par ex. temperature, top_p,
  # max_tokens) et les extensions spécifiques au fournisseur (par ex. top_k,
  # repetition_penalty, anthropic_beta).
  chat_inference_params:
    temperature: 0.7
    top_p: 0.9

Remarque :

Pour que les utilisateurs puissent envoyer des entrées d'images dans l'interface de chat, le modèle d'inférence principal doit avoir supports_vision: true défini dans son bloc model_info. Si ce flag est absent ou false, l'entrée d'image ne sera pas disponible.

Avertissement :

Si supports_vision est défini sur true pour un modèle qui ne prend pas réellement en charge les entrées d'images, l'utilisation d'images échouera avec une erreur du fournisseur. Assure-toi que ce flag n'est activé que pour les modèles qui prennent en charge les entrées d'images. Note que les modèles suivants ne prennent pas en charge les entrées d'images et doivent avoir supports_vision: false : Laguna S2.1 et Nvidia Nemotron 3.

Valeurs `provider` / `family` / `version` prises en charge

Bob utilise conjointement les champs provider, family et version pour sélectionner les ajustements de prompt et optimisations spécifiques au modèle. Utilise les valeurs correspondantes les plus proches pour les modèles non répertoriés.

`provider`	`family`	`version`	Exemple d'ID de modèle
`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`

Emplacements de noms de modèle réservés

Les valeurs model_name suivantes doivent être présentes dans ta liste models :

`model_name`	Utilisé pour
`premium-ide`	Modèle par défaut pour le chat interactif
`security`	Contrôles de sécurité / garde-fous
`background`	Tâches d'arrière-plan et d'agents autonomes

Le modèle définit security et background comme des alias de fusion YAML du modèle actif, de sorte qu'ils suivent tous automatiquement la même configuration de fournisseur. Pour security et background, un modèle plus petit et plus efficace est recommandé lorsqu'il est disponible (par exemple, openai/gpt-oss-20b).

Fournisseurs

`openai_compatible`

Se connecte à tout modèle hébergé en externe avec une API REST compatible OpenAI (par exemple, Azure OpenAI, vLLM, endpoints personnalisés).

- model_name: premium-ide
  openai_compatible:
    model: gpt-5.6-sol                     # ID du modèle attendu par le fournisseur
    base_url: https://<resource>.cognitiveservices.azure.com/openai
    api_key: env.AZURE_API_KEY             # env.<VAR> lit depuis les secrets du model gateway
    extra_headers:                         # En-têtes supplémentaires à inclure lors de l'inférence
      example_header: env.HEADER_VALUE
    ca_cert_pem: env.CA_CERT               # Certificat CA pour la vérification TLS
  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`

Se connecte à un modèle servi via AWS Bedrock.

- model_name: premium-ide
  bedrock:
    model: us.anthropic.claude-sonnet-5    # ID du modèle attendu par le fournisseur
    region: us-east-1                      # Région AWS où réside votre endpoint Bedrock
    access_key_id: env.AWS_ACCESS_KEY      # ID de clé d'accès Bedrock
    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`

Se connecte à un modèle servi via Google Vertex AI (Gemini). Les identifiants doivent être fournis sous la forme d'une chaîne JSON de compte de service encodée en base64.

- model_name: premium-ide
  vertex:
    model: gemini-3.6-flash                # ID du modèle attendu par le fournisseur
    project: <gcp-project-id>              # ID du projet GCP
    location: global                       # Région Vertex AI / "global" pour l'API globale
    credentials: env.GEMINI_CREDENTIALS    # JSON du compte de service, encodé en base64
  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

Routeurs

La section routers configure la résolution des modèles entre le frontend et le backend. Le default_model configuré sera le LLM principal utilisé lors des interactions de chat.

routers:
  - name: router
    strategy: static
    static:
      default_model: premium-ide   # doit correspondre à un model_name dans la liste models

Champ	Description
`name`	Nom du routeur (toujours utiliser `router`)
`strategy`	Stratégie de routage. Actuellement, seul `static` est pris en charge
`static.default_model`	Le `model_name` à utiliser comme LLM principal. Doit correspondre exactement à une entrée `model_name` dans la liste `models`

Remarque :

premium-ide est un emplacement de nom de modèle obligatoire (voir Emplacements de noms de modèle réservés), la pratique recommandée consiste donc à conserver default_model: premium-ide et à modifier le fournisseur/modèle vers lequel pointe l'entrée premium-ide dans votre liste models.

Ancres YAML

La configuration du model gateway prend en charge les ancres YAML standards (&name) et les clés de fusion (<<: *name). Le modèle utilise ceci pour faciliter la réutilisation et éviter les répétitions.

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               # remplace premium-ide de l'ancre fusionnée

  - <<: *chat_llm
    model_name: background

Gestion des identifiants et des secrets

Secrets

Pour tout secret référencé dans la configuration du modèle (clés d'API, mots de passe, certificats), configurez-les dans le fichier d'installation config.yaml sous bob.modelGateway.secrets. Les secrets sont montés dans le conteneur du service d'inférence lors de l'exécution.

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

Référencez un secret dans la configuration du modèle à l'aide de la syntaxe env.<VAR_NAME> :

api_key: env.VAR_BAR_1

Exigences TLS et de certificats

Lors de l'utilisation d'endpoints privés ou de serveurs de modèles internes (par exemple, vLLM ou OpenShift AI avec des certificats d'entreprise personnalisés ou autosignés), vous devez fournir votre certificat CA racine/intermédiaire interne afin que les conteneurs d'inférence puissent établir la confiance TLS.

Remarque :

Cette configuration TLS de l'endpoint du modèle est distincte du certificat requis pour que Bob IDE et Bob Shell se connectent au backend Bob. Pour le certificat de l'endpoint backend et les étapes de confiance client, voir Certificats TLS.

Il existe deux manières d'ajouter une CA pour l'inférence :

Option 1 — Bundle de confiance d'inférence (recommandé)

Ajoutez la CA à bob-inferencing-bundle-tls en étiquetant un Secret Kubernetes. L'opérateur détecte le label et reconstruit automatiquement le bundle — aucune modification de configuration du model gateway n'est requise et la CA est immédiatement disponible pour tous les conteneurs d'inférence.

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>

Le Secret bob-inferencing-bundle-tls est monté dans les conteneurs d'inférence en tant que magasin de confiance. Il contient toujours l'intégralité de bob-bundle-tls plus les Secrets étiquetés supplémentaires. Aucun redémarrage de pod n'est nécessaire — les Secrets sont projetés dans le conteneur en cours d'exécution.

Pour tous les détails et les étapes de vérification, voir Certificats TLS.

Option 2 — `ca_cert_pem` par modèle (configuration du model gateway)

Utilisez cette option lorsque vous devez fournir une CA pour un endpoint de modèle spécifique unique sans affecter les autres conteneurs d'inférence. Les certificats TLS personnalisés suivent le même modèle de configuration distribuée à deux fichiers que les identifiants d'API :

Dans model-gateway.yaml : Définissez ca_cert_pem avec le nom d'une variable d'environnement (par exemple, env.CA_CERT).

Dans config.yaml : Ajoutez le nom de variable correspondant sous bob.modelGateway.secrets et collez la chaîne de certificat complète encodée en PEM.

1. Configuration du model gateway (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           # Pointe vers le nom de variable défini dans config.yaml
    model_info:
      exposed: true
      mode: chat

2. Configuration d'installation (config.yaml) :

bob:
  modelGateway:
    secrets:
      MODEL_API_KEY: "<your-api-key>"
      # Le contenu réel du certificat PEM correspondant à env.CA_CERT ci-dessus :
      CA_CERT: |
        -----BEGIN CERTIFICATE-----
        MIIFazCCA1OgAwIBAgIRAIIQjJaDSmJT3g4qg05...
        ... [données complètes du certificat CA encodé en PEM] ...
        -----END CERTIFICATE-----

Lors du déploiement, bobctl injecte CA_CERT dans le secret Kubernetes bob-inference-model-secrets. Celui-ci est ensuite monté dans le service de passerelle d'inférence et utilisé pour la négociation TLS avec votre serveur de modèle privé.

Exemple complet

Voici un exemple complet reflétant la structure de config-model-gateway-template.yaml du bundle Bob. Enregistrez-le dans un fichier (par exemple, /tmp/example/model-gateway.yaml) et référencez-le lors de l'installation.

Configuration du Model Gateway

# ── Définitions des fournisseurs ──────────────────────────────────────────────
# La clé x-providers est ignorée par le model gateway — il s'agit d'un bloc-notes
# YAML pour les exemples de fournisseurs. Seule l'ancre du fournisseur actif est référencée ci-dessous.
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

  # Service d'inférence personnalisé (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

# ── Modèles ───────────────────────────────────────────────────────────────────
models:

  # ── MODÈLE ACTIF ─────────────────────────────────────────────────────────────
  # Remplacez <<: *bedrock par ex. par *azure, *gemini ou *isvc pour changer de fournisseur.
  - &chat_llm
    <<: *bedrock                       # ← changer de fournisseur ici
    model_name: premium-ide
    model_info:
      exposed: true

  # ── Alias ────────────────────────────────────────────────────────────────────
  - <<: *chat_llm
    model_name: security               # remplace premium-ide de l'ancre fusionnée

  - <<: *chat_llm
    model_name: background

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

Commande d'installation

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

Pour un environnement connecté, spécifiez votre clé d'habilitation (entitlement key) pour icr.io. --registry-creds ne peut être omis que si vous disposez d'un registre privé qui ne nécessite pas d'authentification pour le téléchargement.

Déploiement de la configuration

Lors de l'installation initiale

Transmettez le chemin vers votre fichier de configuration du model gateway à l'aide du drapeau --model-config au moment de l'installation :

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

Avertissement :

Si bobctl install est exécuté sans --model-config, Bob est installé avec une configuration de model gateway vide. Le service d'inférence s'exécute mais n'a aucune connexion à un modèle pour l'inférence. Utilisez bobctl update-model-config après l'installation pour pousser une configuration de modèle vers le cluster.

Comment les identifiants sont déployés sur le cluster

Le fichier de configuration du model gateway référence les identifiants sous forme de variables d'environnement (par exemple, env.AWS_ACCESS_KEY, env.AZURE_API_KEY). Différents fournisseurs de modèles nécessitent différents secrets — clés IAM AWS pour Bedrock, clés d'API pour Azure OpenAI ou JSON de compte de service pour Google Gemini.

Lors de l'installation, ces identifiants sont fournis dans votre fichier config.yaml sous bob.modelGateway.secrets. La CLI bobctl traite automatiquement cette section et crée un secret Kubernetes nommé bob-inference-model-secrets dans le cluster, en montant les clés sous forme de variables d'environnement directement à l'intérieur du conteneur du service de passerelle d'inférence.

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

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

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

      # Clés d'API / jetons d'endpoint personnalisé ou authentification de proxy interne
      # RITS_APIKEY: "<your-api-key>"

      # Certificat CA personnalisé au format PEM pour les endpoints internes autosignés
      # CA_CERT: |
      #   -----BEGIN CERTIFICATE-----
      #   ...
      #   -----END CERTIFICATE-----

Mise à jour de la configuration après l'installation (`bobctl update-model-config`)

Utilisez bobctl update-model-config pour pousser une configuration de model gateway et/ou des secrets vers un cluster actif sans réinstaller. Il s'agit de la procédure requise lorsque bobctl install a été exécuté sans --model-config, et de la même commande utilisée pour changer le modèle d'inférence principal.

En coulisses, la commande exécute helm template sur les modèles model-config.yaml et model-secrets.yaml dans la charte locale ibm-bob, puis applique les manifestes générés au cluster. Une fois appliqués, l'opérateur ibm-bob-operator réconcilie le déploiement bob-inference avec la nouvelle configuration de modèle.

La commande gère deux ressources de cluster distinctes :

Drapeau	Ressource du cluster	Source
`--model-config <file>`	`ConfigMap` `bob-inference-model-config`	Le fichier que vous transmettez
`--update-secrets`	`Secret` `bob-inference-model-secrets`	`bob.modelGateway.secrets` dans `config.yaml`

Au moins l'un des deux doit être fourni — n'en passer aucun est une erreur.

Prérequis :

Vous devez être connecté au cluster (oc login)

config.yaml doit exister à côté de bobctl (copier depuis config-template.yaml)

helm ≥ 3.14.0 doit être présent dans votre PATH

Utilisation courante :

# Mettre à jour uniquement le fichier de configuration du modèle
bobctl update-model-config --model-config ./my-model-config.yaml

# Mettre à jour uniquement les secrets (les clés proviennent de config.yaml)
bobctl update-model-config --update-secrets

# Mettre à jour les deux à la fois
bobctl update-model-config --model-config ./my-model-config.yaml --update-secrets

# Prévisualiser ce qui serait appliqué sans toucher au cluster
bobctl update-model-config --model-config ./my-model-config.yaml --update-secrets --dry-run

Tous les drapeaux :

Drapeau	Valeur par défaut	Description
`--model-config <file>`		Chemin vers le fichier de configuration du modèle à pousser dans la ConfigMap
`--update-secrets`		Pousser `bob.modelGateway.secrets` depuis `config.yaml` dans le Secret
`--output-config <file>`	`model-gateway-config.yaml`	Emplacement où écrire le manifeste ConfigMap généré
`--output-secret <file>`	`model-gateway-secret.yaml`	Emplacement où écrire le manifeste Secret généré
`--cleanup`	false	Supprimer les fichiers manifestes générés après les avoir appliqués
`--dry-run`	false	Afficher ce qui serait exécuté sans lancer de commandes `oc`

Configuration du Model Gateway

Sur cette page