Découvrez les modèles requis par Bob on-premises, y compris les modèles d'inférence principaux pris en charge, les modèles de guardrail et les fonctionnalités de sécurité propres aux fournisseurs utilisées pour activer les fonctionnalités basées sur l'IA.

Bob on-premises nécessite l'accès à un modèle d'inférence principal pris en charge pour fournir des fonctionnalités de génération de code, d'explication, de chat et d'assistance. Selon vos exigences de déploiement, vous pouvez connecter Bob à des modèles air-gapped hébergés au sein de votre environnement ou à des modèles frontier accessibles via des fournisseurs cloud. Pour une sécurité renforcée et le respect des politiques, IBM recommande de configurer un modèle de guardrail ou d'utiliser les fonctionnalités natives de guardrail du fournisseur.

Modèles requis

Avant d'installer Bob, assurez-vous que les modèles suivants sont déployés et accessibles.

Rôle du modèle	Objectif
Modèle d'inférence principal	Traite la génération de code, les explications, les requêtes de chat et les interactions d'assistance.
Modèle de guardrail	Examine les entrées et les sorties pour vérifier la sécurité et la conformité aux politiques. L'utilisation d'un modèle de guardrail est fortement recommandée.

Important :

Configurez exactement un modèle d'inférence principal à la fois.

Remarque :

Un modèle de guardrail est fortement recommandé pour tous les déploiements. Pour les déploiements air-gapped, utilisez openai/gpt-oss-20b. Lorsqu'il est configuré, Bob achemine automatiquement les demandes d'évaluation de sécurité et de conformité aux politiques via le service de guardrail.

Modèles pris en charge

Les modèles d'inférence principaux suivants sont disponibles pour une utilisation avec IBM Bob on-premises. Configurez un seul modèle d'inférence principal dans le Model Gateway. L'exécution simultanée de plusieurs modèles d'inférence principaux n'est pas prise en charge.

Modèles air-gapped

Les besoins en ressources (CPU, RAM, GPU/VRAM et dimensionnement de la concurrence) dépendent de la quantification du modèle, de la longueur du contexte, du runtime d'inférence (comme vLLM ou TGI) et du débit cible. Consultez la documentation produit pour connaître les spécifications matérielles et les guides de déploiement.

Modèle	Référence
Mistral 3.5	Documentation Mistral AI
Nvidia Nemotron 3	Documentation NVIDIA NeMo / Nemotron
Poolside Laguna S2.1	Documentation Poolside AI

Modèles frontier

Les modèles cloud frontier sont accessibles via des API gérées par des fournisseurs (tels qu'AWS Bedrock, Google Cloud Vertex AI ou Azure OpenAI). Consultez la documentation produit pour connaître la disponibilité des services, les quotas, les limites de débit et la configuration des endpoints.

Modèle	Référence
Claude Sonnet 5	Documentation Anthropic Claude / AWS Bedrock
Claude Opus 4.8	Documentation Anthropic Claude / AWS Bedrock
Google Gemini 3.7 Flash	Documentation Google Cloud Vertex AI
OpenAI GPT5.6 Sol	Documentation Azure OpenAI Service

Guardrails des fournisseurs

L'utilisation d'un modèle de guardrail est fortement recommandée pour la sécurité, le filtrage de toxicité et le contrôle des politiques sur toutes les entrées et sorties. Consultez le référentiel du modèle et la documentation du runtime d'inférence pour obtenir les détails de déploiement et les directives matérielles.

Modèle	Référence	Description
`openai/gpt-oss-20b`	Hugging Face Model Hub / Documentation OpenAI	Requis pour le contrôle de sécurité et des politiques

Pour les modèles air-gapped, utilisez openai/gpt-oss-20b pour implémenter des guardrails. Une fois ce modèle de guardrail configuré, les clients IDE et Bob Shell sont automatiquement configurés pour l'utiliser pour le filtrage de contenu.

Guardrails des modèles frontier

Lors de l'utilisation de modèles frontier, vous pouvez utiliser la fonctionnalité de guardrail du fournisseur au lieu du modèle de guardrail openai/gpt-oss-20b.

Guardrails AWS Bedrock

Créez un guardrail Bedrock et récupérez son guardrailId et sa version. Pour obtenir des conseils, consultez la documentation des guardrails Bedrock et la référence de l'API CreateGuardrail. Ajoutez la configuration de guardrail sous chat_inference_params pour le modèle Bedrock :

- model_name: bedrock-model
  bedrock:
    model: <bedrock-model-id>
    access_key_id: env.AWS_ACCESS_KEY
    region: us-east-1
    secret_access_key: env.AWS_SECRET_ACCESS_KEY
  model_info:
    exposed: true
    max_input_tokens: 270000
  chat_inference_params:
    guardrailConfig:
      guardrailIdentifier: <guardrail-id>
      guardrailVersion: <version-number-or-DRAFT>

Google Vertex AI

Configurez les filtres de sécurité Vertex AI dans chat_inference_params. Voir la documentation des filtres de sécurité Vertex AI.

Catégories prises en charge	Seuils pris en charge
`HARM_CATEGORY_SEXUALLY_EXPLICIT`, `HARM_CATEGORY_HATE_SPEECH`, `HARM_CATEGORY_HARASSMENT`, `HARM_CATEGORY_DANGEROUS_CONTENT`	`BLOCK_NONE`, `BLOCK_ONLY_HIGH`, `BLOCK_MEDIUM_AND_ABOVE` (par défaut), `BLOCK_LOW_AND_ABOVE` (le plus strict)

- model_name: gemini-model
  vertex:
    model: gemini-model
    project: <project-id>
    location: global
    credentials: env.BOB_GEMINI_CREDENTIALS
  model_info:
    max_tokens: 20000
    max_input_tokens: 270000
    exposed: false
  chat_inference_params:
    safetySettings:
      - category: HARM_CATEGORY_HATE_SPEECH
        threshold: BLOCK_MEDIUM_AND_ABOVE
      - category: HARM_CATEGORY_HARASSMENT
        threshold: BLOCK_ONLY_HIGH
      - category: HARM_CATEGORY_SEXUALLY_EXPLICIT
        threshold: BLOCK_LOW_AND_ABOVE
      - category: HARM_CATEGORY_DANGEROUS_CONTENT
        threshold: BLOCK_LOW_AND_ABOVE

Azure OpenAI

Dans Azure, créez un filtre de contenu et attribuez-le au déploiement du modèle ; aucune modification de la configuration du model gateway n'est requise. Voir la documentation sur les filtres de contenu Azure OpenAI. Pour appliquer une politique au moment de la requête, configurez l'en-tête x-policy-id :

- model_name: gpt-model
  openai_compatible:
    model: openai/gpt-model
    base_url: https://<endpoint>.azure.com/openai
    api_key: env.AZURE_API_KEY
    extra_headers:
      x-policy-id: <custom-content-filter-name>
  model_info:
    max_tokens: 12000
    max_input_tokens: 200000
    exposed: true

Infrastructure de service de modèles

Bob nécessite l'accès à un ou plusieurs endpoints d'inférence de modèle pour exécuter des tâches basées sur l'IA. Bob se connecte aux modèles déployés via la passerelle d'inférence de modèles (Model Inference Gateway) mais ne provisionne, n'héberge ni ne gère l'infrastructure de service de modèles.

La plupart des environnements on-premises disposent déjà d'une infrastructure de service de modèles, qu'il s'agisse d'un cluster GPU partagé exécutant run.ai, Red Hat OpenShift AI, d'une ferme de serveurs vLLM dédiée, ou d'un accès à l'API de modèle d'un fournisseur de cloud public (AWS Bedrock, Azure OpenAI, Google Vertex AI). Bob requiert un endpoint accessible par le réseau depuis le cluster OpenShift qui expose une API compatible OpenAI.

Pour plus d'informations sur le déploiement d'un modèle pris en charge, voir Infrastructure de service de modèles.

Modèles requis et pris en charge