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, les options de secours (fallbacks) 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, …)
  bedrock:            # — endpoint d'appel AWS Bedrock
  vertex:             # — Google Vertex AI (Gemini)

  # Paramètres d'information sur le modèle (optionnels)
  model_info:
    exposed: true                          # true : visible dans la liste /models ; false : usage interne uniquement
    max_input_tokens: 128000               # taille de la fenêtre de contexte
    max_output_tokens: 4096                # nombre maximal de jetons que le modèle peut générer
    input_cost_per_token: 0.0000025        # coût en USD par jeton d'entrée (utilisé pour la mesure de l'utilisation)
    output_cost_per_token: 0.000010        # coût en USD par jeton de sortie
    cache_read_input_token_cost: 0.00      # coût pour les jetons d'entrée avec correspondance dans le cache (prompt caching)
    cache_creation_input_token_cost: 0.00  # coût pour écrire une nouvelle entrée dans le cache
    supports_prompt_caching: true          # true si le modèle prend en charge le prompt caching
    supports_function_calling: true        # true si le modèle prend en charge les appels d'outils/fonctions
    supports_tool_choice: true             # true si le paramètre tool_choice est honoré
    supports_reasoning: false              # true si le modèle prend en charge un paramètre reasoning_effort
    supports_vision: false                 # true si le modèle accepte les entrées d'images dans les messages de chat
    mode: chat                             # chat | embedding | image_generation

  # Liste ordonnée facultative de valeurs model_name à essayer lorsque ce modèle est indisponible
  fallbacks:
    - fallback_model

  # 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

Avertissement :

Définissez supports_vision: true uniquement sur les modèles qui acceptent les entrées d'images. Si supports_vision est défini sur true pour un modèle qui ne prend pas en charge les entrées d'images, l'envoi d'une image dans le chat entraîne une erreur du fournisseur. Les modèles suivants ne prennent pas en charge les entrées d'images et doivent utiliser supports_vision: false ou omettre l'indicateur : Laguna S2.1 et Nvidia Nemotron 3.

Fournisseurs

`openai_compatible`

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

openai_compatible:
  model: gpt-4o                          # ID du modèle attendu par le fournisseur
  base_url: https://base_url             # URL de base du déploiement du modèle
  api_key: env.API_KEY                   # Clé d'API pour s'authentifier. env.<VAR> lit depuis l'environnement du conteneur
  extra_headers:                         # En-têtes supplémentaires à inclure lors de l'inférence
    example_header: env.HEADER_VALUE
  insecure_skip_verify: true             # Désactiver la vérification TLS (non recommandé pour la production)
  ca_cert_pem: env.CA_CERT               # Certificat CA pour la vérification TLS

`bedrock`

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

bedrock:
  model: claude                                  # 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   # Clé d'accès secrète Bedrock

`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.

vertex:
  model: gemini                              # ID du modèle attendu par le fournisseur
  project: my-gcp-project                    # 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

Ancres YAML

Ancres d'identifiants

Définissez les identifiants une seule fois et référencez-les avec <<: *anchor-name à travers plusieurs entrées de modèle pour éviter les répétitions.

# Identifiants AWS Bedrock — référencés par les modèles bedrock.
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            # fusionner l'ancre d'identifiants définie ci-dessus
    model_info:
      exposed: true
      mode: chat

Ancres de modèle

Fusionnez un bloc de modèle complet à travers plusieurs entrées pour éviter de répéter la configuration du fournisseur et model_info.

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

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

Le bundle CA racine inclut les certificats CA publics standards pour les fournisseurs de cloud. Cependant, 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 pour é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.

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.

Configuration du model gateway :

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

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 couvrant tous les types de fournisseurs. Enregistrez la configuration du model gateway dans un fichier (par exemple, /tmp/example/model-gateway.yaml) et référencez-le lors de l'installation.

Configuration du model gateway (/tmp/example/model-gateway.yaml)

# ── Ancres d'identifiants (partagées entre les entrées de modèles via les clés de fusion YAML) ──
# Identifiants AWS Bedrock
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

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

# ── Ancres de modèles partagées (optionnel) ──────────────────────────────────
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

# ── Modèles ───────────────────────────────────────────────────────────────────
models:
  # Modèle compatible OpenAI (par ex. Azure OpenAI) avec clé d'API
  - 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

  # Modèle AWS Bedrock
  - model_name: my-bedrock-model
    bedrock:
      model: us.anthropic.claude-3-5-sonnet-20241022-v2:0
      <<: *aws-bedrock-auth
    fallbacks:                          # optionnel : liste ordonnée des noms de modèles de secours
      - 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

  # Modèle Google Vertex AI (Gemini) utilisant l'ancre de modèle partagée
  - model_name: my-gemini-model
    <<: *my-base-model

  # Modèle compatible OpenAI avec certificat CA personnalisé
  - 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

  # Modèle compatible OpenAI avec en-têtes supplémentaires
  - 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

Commande d'installation

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

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

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.BOB_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
      BOB_AZURE_API_KEY: "<your-azure-api-key>"

      # Authentification Google Cloud Vertex AI / Gemini
      BOB_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.

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

Spécification du modèle

Fournisseurs

`openai_compatible`

`bedrock`

`vertex`

Ancres YAML

Ancres d'identifiants

Ancres de modèle

Gestion des identifiants et des secrets

Secrets

Exigences TLS et de certificats

Exemple complet

Déploiement de la configuration

Lors de l'installation initiale

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

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

Sur cette page