Scopri come creare e gestire un file di configurazione del Model Gateway, incluse le impostazioni del provider, le definizioni dei modelli, la gestione delle credenziali, la configurazione TLS e gli esempi di deployment per i provider di modelli supportati.

Il Model Gateway consente a Bob on-premises di connettersi e instradare le richieste verso modelli AI supportati di diversi provider, inclusi endpoint compatibili con OpenAI, AWS Bedrock e Google Vertex AI. Una configurazione del Model Gateway definisce gli endpoint dei modelli, le impostazioni di autenticazione, il comportamento di routing, le opzioni di fallback e le capacità dei modelli, mentre credenziali e certificati sensibili sono gestiti in modo sicuro tramite config.yaml.

La configurazione del model gateway è un file YAML che definisce a quali modelli il gateway si connette e come autenticarsi con ogni provider.

Attenzione:

Configura un solo modello di inference core nel model gateway alla volta. La configurazione simultanea di più modelli core non è supportata e produce comportamenti indefiniti.

Specifica del modello

Ogni voce nell'elenco models deve avere un model_name univoco. La specifica completa del modello è:

- 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

Attenzione:

Imposta supports_vision: true solo sui modelli che accettano input di immagini. Se supports_vision viene impostato su true su un modello che non supporta input di immagini, l'invio di un'immagine nella chat produce un errore del provider. I seguenti modelli non supportano input di immagini e devono usare supports_vision: false o omettere il flag: Laguna S2.1 e Nvidia Nemotron 3.

Provider

`openai_compatible`

Si connette a qualsiasi modello ospitato esternamente con un'API REST compatibile con OpenAI (ad esempio, Azure OpenAI, endpoint personalizzati).

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`

Si connette a un modello servito tramite AWS Bedrock.

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`

Si connette a un modello servito tramite Google Vertex AI (Gemini). Le credenziali devono essere fornite come stringa JSON dell'account di servizio con codifica base64.

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

Anchor YAML

Anchor per le credenziali

Definisci le credenziali una volta sola e fai riferimento ad esse con <<: *anchor-name in più voci del modello per evitare ripetizioni.

# 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

Anchor per i modelli

Unisci un blocco modello completo tra più voci per evitare di ripetere la configurazione del provider e 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

Gestione di credenziali e secret

Secret

Per qualsiasi secret referenziato nella configurazione del modello (chiavi API, password, certificati), configurali nel file di installazione config.yaml sotto bob.modelGateway.secrets. I secret vengono montati nel container dell'Inference Service in fase di runtime.

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

Fai riferimento a un secret nella configurazione del modello usando la sintassi env.<VAR_NAME>:

api_key: env.VAR_BAR_1

Requisiti TLS e certificati

Il bundle CA root include certificati CA pubblici standard per i provider cloud. Tuttavia, quando si usano endpoint privati o server di modelli interni (ad esempio, vLLM o OpenShift AI con certificati enterprise personalizzati o self-signed), è necessario fornire il certificato CA Root/Intermediate interno per stabilire la trust TLS.

Nota:

Questa configurazione TLS dell'endpoint del modello è separata dal certificato necessario per la connessione di Bob IDE e Bob Shell al backend Bob. Per i passaggi relativi al certificato dell'endpoint backend e alla trust del client, vedere Certificati TLS.

I certificati TLS personalizzati seguono lo stesso pattern di configurazione distribuita a due file delle credenziali API:

In model-gateway.yaml: Imposta ca_cert_pem su un nome di variabile d'ambiente (ad esempio, env.CA_CERT).

In config.yaml: Aggiungi il nome della variabile corrispondente sotto bob.modelGateway.secrets e incolla la stringa del certificato completa con codifica PEM.

Configurazione del 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           # Points to the variable name defined in config.yaml
    model_info:
      exposed: true
      mode: chat

Configurazione di installazione (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-----

Durante il deployment, bobctl inietta CA_CERT nel Kubernetes Secret bob-inference-model-secrets. Questo viene poi montato nel servizio inference gateway e usato per l'handshake TLS contro il server del modello privato.

Esempio completo

Di seguito è riportato un esempio completo che copre tutti i tipi di provider. Salva la configurazione del model gateway in un file (ad esempio, /tmp/example/model-gateway.yaml) e fai riferimento ad essa durante l'installazione.

Configurazione del model gateway (/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

Secret (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

Comando di installazione

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

Deployment della configurazione

Durante l'installazione iniziale

Passa il percorso del file di configurazione del model gateway usando il flag --model-config al momento dell'installazione:

bobctl install --model-config path/to/model-gateway-config.yaml --accept-license

Attenzione:

Se bobctl install viene eseguito senza --model-config, Bob viene installato con una configurazione del model gateway vuota. L'Inference Service viene avviato ma non ha connessione ad alcun modello per l'inferencing. Usa bobctl update-model-config post-installazione per inviare una configurazione del modello al cluster.

Come le credenziali vengono deployate nel cluster

Il file di configurazione del model gateway fa riferimento alle credenziali come variabili d'ambiente (ad esempio, env.AWS_ACCESS_KEY, env.BOB_AZURE_API_KEY). Provider di modelli diversi richiedono secret diversi — chiavi IAM AWS per Bedrock, chiavi API per Azure OpenAI, o JSON dell'account di servizio per Google Gemini.

Durante l'installazione, queste credenziali vengono fornite nel tuo config.yaml sotto bob.modelGateway.secrets. La CLI bobctl elabora automaticamente questa sezione e crea un Kubernetes Secret denominato bob-inference-model-secrets nel cluster, montando le chiavi come variabili d'ambiente direttamente all'interno del container del servizio inference gateway.

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

Aggiornamento della configurazione post-installazione (`bobctl update-model-config`)

Usa bobctl update-model-config per inviare una configurazione del model gateway e/o dei secret a un cluster attivo senza reinstallare. Questo è il percorso richiesto quando bobctl install è stato eseguito senza --model-config, ed è lo stesso comando usato per cambiare il modello di inference core.

Il comando gestisce due risorse cluster separate:

Flag	Risorsa cluster	Sorgente
`--model-config <file>`	`ConfigMap` `bob-inference-model-config`	Il file che passi
`--update-secrets`	`Secret` `bob-inference-model-secrets`	`bob.modelGateway.secrets` in `config.yaml`

Almeno uno dei due deve essere fornito — non passarne nessuno è un errore.

Prerequisiti:

Devi essere autenticato al cluster (oc login)

config.yaml deve esistere nella stessa directory di bobctl (copialo da config-template.yaml)

helm ≥ 3.14.0 deve essere nel PATH

Utilizzo comune:

# 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

Tutti i flag:

Flag	Predefinito	Descrizione
`--model-config <file>`		Percorso del file di configurazione del modello da caricare nella ConfigMap
`--update-secrets`		Carica `bob.modelGateway.secrets` da `config.yaml` nel Secret
`--output-config <file>`	`model-gateway-config.yaml`	Dove scrivere il manifest ConfigMap renderizzato
`--output-secret <file>`	`model-gateway-secret.yaml`	Dove scrivere il manifest Secret renderizzato
`--cleanup`	false	Elimina i file manifest renderizzati dopo averli applicati
`--dry-run`	false	Stampa cosa verrebbe eseguito senza eseguire alcun comando `oc`

Configurazione del Model Gateway

Specifica del modello

Provider

`openai_compatible`

`bedrock`

`vertex`

Anchor YAML

Anchor per le credenziali

Anchor per i modelli

Gestione di credenziali e secret

Secret

Requisiti TLS e certificati

Esempio completo

Deployment della configurazione

Durante l'installazione iniziale

Come le credenziali vengono deployate nel cluster

Aggiornamento della configurazione post-installazione (`bobctl update-model-config`)

In questa pagina