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.

Conseil :

Pour des résultats optimaux sur des tâches IBM Z complexes, telles que la refactorisation approfondie de COBOL, l'analyse PL/I et les transformations de code multi-fichiers, les modèles frontière comme Claude Sonnet offrent le niveau le plus élevé de raisonnement, de précision et de qualité de génération.

Modèles frontière (recommandés) : Idéaux pour les charges de travail IBM Z en entreprise nécessitant un raisonnement avancé, une compréhension de grands contextes et une génération de code en plusieurs étapes.
Modèles open-weight auto-hébergés : Idéaux pour une conformité stricte air-gap et une assistance au codage standard. Pour les patterns de langage mainframe complexes, les résultats peuvent bénéficier d'un ajustement ciblé des prompts et d'un contexte spécifique au domaine.

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 Medium 3.5	Documentation Mistral AI / Mistral Medium 3.5
Nvidia Nemotron 3 Ultra	Documentation NVIDIA Nemotron / Nemotron 3 Ultra FP4 / Nemotron 3 Ultra FP8
Poolside Laguna S 2.1	Documentation Poolside Laguna-S-2.1-FP8 / Documentation Poolside Laguna-S-2.1-NVFP4 / Modèles Poolside Laguna

Remarque :

Tu ne peux utiliser Mistral Medium 3.5 que si tu utilises IBM Bob Premium Package for Z. Il n'est pas disponible pour les déploiements généraux de Bob auto-hébergé.

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
    max_output_tokens: 20000
  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.GEMINI_CREDENTIALS
  model_info:
    max_input_tokens: 270000
    max_output_tokens: 20000
    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_input_tokens: 270000
    max_output_tokens: 20000
    exposed: true

Limites de tokens des modèles

Les limites de tokens suivantes sont recommandées pour les modèles pris en charge.

Modèle	Nombre maximum de tokens en entrée	Nombre maximum de tokens en sortie
Laguna S 2.1	270 000	20 000
Nemotron 3 Ultra	262 144	20 000
Mistral Medium 3.5	262 144	20 000
Sonnet 4.6	270 000	20 000

Configurer les limites de tokens des modèles

Indique les limites de tokens dans la section model_info de la définition du modèle.

Par exemple :

model_info:
  provider: poolside
  family: laguna
  version: s2.1
  max_input_tokens: 270000
  max_output_tokens: 20000

max_input_tokens définit le nombre maximum de tokens pouvant être inclus dans une seule requête, y compris les prompts, l'historique de la conversation et tout contexte supplémentaire.

max_output_tokens définit le nombre maximum de tokens que le modèle peut générer dans une réponse.

Configure ces valeurs selon les capacités du modèle sous-jacent.

Définir des valeurs dépassant les limites prises en charge par le modèle peut entraîner des échecs de requête ou des réponses tronquées.

Si un fournisseur de modèle publie des limites mises à jour, mets à jour la configuration pour correspondre aux capacités documentées du fournisseur.

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.

Modèles requis et pris en charge