Scopri i modelli richiesti da Bob on-premises, inclusi i modelli di inference core supportati, i modelli guardrail e le funzionalità di sicurezza specifiche del provider usate per abilitare le capacità basate su AI.

Bob on-premises richiede l'accesso a un modello di inference core supportato per fornire generazione del codice, spiegazioni, chat e capacità di assistente. A seconda dei requisiti di deployment, puoi connettere Bob a modelli air-gapped ospitati nel tuo ambiente o a modelli frontier accessibili tramite provider cloud. Per una maggiore sicurezza e conformità alle policy, IBM raccomanda di configurare un modello guardrail o di usare le capacità di guardrail native del provider.

Modelli richiesti

Prima di installare Bob, assicurati che i seguenti modelli siano deployati e accessibili.

Ruolo del modello	Scopo
Modello di inference core	Elabora la generazione del codice, le spiegazioni, le richieste di chat e le interazioni con l'assistente.
Modello guardrail	Verifica input e output per sicurezza e conformità alle policy. Si raccomanda vivamente di usare un modello guardrail.

Importante:

Configura esattamente un modello di inference core alla volta.

Nota:

Un modello guardrail è fortemente raccomandato per tutti i deployment. Per i deployment air-gapped, usa openai/gpt-oss-20b. Quando configurato, Bob instrada automaticamente le richieste di valutazione di sicurezza e policy attraverso il servizio guardrail.

Modelli supportati

I seguenti modelli di inference core sono disponibili per l'uso con IBM Bob on-premises. Configura un singolo modello di inference core nel Model Gateway. L'esecuzione simultanea di più modelli di inference core non è supportata.

Suggerimento:

Per risultati ottimali su attività IBM Z complesse, come il refactoring approfondito di COBOL, l'analisi PL/I e le trasformazioni di codice su più file, i modelli frontier come Claude Sonnet offrono il più alto livello di ragionamento, precisione e qualità di generazione.

Modelli frontier (consigliati): Più adatti per i carichi di lavoro IBM Z aziendali che richiedono ragionamento avanzato, comprensione di contesti estesi e generazione di codice in più fasi.
Modelli open-weight self-hosted: Ideali per la stretta conformità air-gap e l'assistenza alla codifica standard. Per i pattern complessi del linguaggio mainframe, i risultati potrebbero beneficiare di un prompt tuning mirato e di un contesto specifico del dominio.

Modelli air-gapped

I requisiti di risorse (CPU, RAM, GPU/VRAM e dimensionamento della concorrenza) dipendono dalla quantizzazione del modello, dalla lunghezza del contesto, dal serving runtime (come vLLM o TGI) e dal throughput target. Consulta la documentazione del prodotto per le specifiche hardware e le guide al deployment.

Modello	Riferimento
Mistral Medium 3.5	Documentazione Mistral AI / Mistral Medium 3.5
Nvidia Nemotron 3 Ultra	Documentazione NVIDIA Nemotron / Nemotron 3 Ultra FP4 / Nemotron 3 Ultra FP8
Poolside Laguna S 2.1	Documentazione Poolside Laguna-S-2.1-FP8 / Documentazione Poolside Laguna-S-2.1-NVFP4 / Modelli Poolside Laguna

Nota:

Puoi utilizzare Mistral Medium 3.5 solo se utilizzi IBM Bob Premium Package for Z. Non è disponibile per i deployment self-hosted generali di Bob.

Modelli frontier

I modelli cloud frontier sono accessibili tramite API gestite dal provider (come AWS Bedrock, Google Cloud Vertex AI o Azure OpenAI). Consulta la documentazione del prodotto per la disponibilità del servizio, le quote, i limiti di velocità e la configurazione degli endpoint.

Modello	Riferimento
Claude Sonnet 5	Documentazione Anthropic Claude / AWS Bedrock
Claude Opus 4.8	Documentazione Anthropic Claude / AWS Bedrock
Google Gemini 3.7 Flash	Documentazione Google Cloud Vertex AI
OpenAI GPT5.6 Sol	Documentazione Azure OpenAI Service

Guardrail del provider

Si raccomanda vivamente di usare un modello guardrail per il filtraggio della sicurezza, della tossicità e della screening delle policy su tutti gli input e output. Consulta la documentazione del repository del modello e del serving runtime per i dettagli sul deployment e le linee guida hardware.

Modello	Riferimento	Descrizione
`openai/gpt-oss-20b`	Hugging Face Model Hub / Documentazione OpenAI	Richiesto per lo screening di sicurezza e policy

Per i modelli air-gapped, usa openai/gpt-oss-20b per implementare i guardrail. Dopo la configurazione di questo modello guardrail, i client IDE e Bob Shell vengono automaticamente configurati per usarlo per il filtraggio dei contenuti.

Guardrail dei modelli frontier

Quando si usano modelli frontier, è possibile usare la capacità di guardrail del provider al posto del modello guardrail openai/gpt-oss-20b.

Guardrail AWS Bedrock

Crea un guardrail Bedrock e ottieni il suo guardrailId e la versione. Per una guida, vedere la documentazione sui guardrail Bedrock e il riferimento API CreateGuardrail. Aggiungi la configurazione del guardrail sotto chat_inference_params per il modello 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

Configura i filtri di sicurezza di Vertex AI in chat_inference_params. Vedere la documentazione sui filtri di sicurezza di Vertex AI.

Categorie supportate	Soglie supportate
`HARM_CATEGORY_SEXUALLY_EXPLICIT`, `HARM_CATEGORY_HATE_SPEECH`, `HARM_CATEGORY_HARASSMENT`, `HARM_CATEGORY_DANGEROUS_CONTENT`	`BLOCK_NONE`, `BLOCK_ONLY_HIGH`, `BLOCK_MEDIUM_AND_ABOVE` (predefinito), `BLOCK_LOW_AND_ABOVE` (più restrittivo)

- 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

In Azure, crea un filtro contenuti e assegnalo al deployment del modello; non sono necessarie modifiche alla configurazione del model gateway. Vedere la documentazione sui filtri contenuti di Azure OpenAI. Per applicare invece una policy al momento della richiesta, configura l'header 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

Limiti di token del modello

I seguenti limiti di token sono consigliati per i modelli supportati.

Modello	Massimo token di input	Massimo token di output
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

Configurare i limiti di token del modello

Specifica i limiti di token nella sezione model_info della definizione del modello.

Ad esempio:

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

max_input_tokens definisce il numero massimo di token che possono essere inclusi in una singola richiesta, inclusi prompt, cronologia delle conversazioni e qualsiasi contesto aggiuntivo.

max_output_tokens definisce il numero massimo di token che il modello può generare in una risposta.

Configura questi valori in base alle capacità del modello sottostante.

L'impostazione di valori che superano i limiti supportati dal modello può causare errori di richiesta o risposte troncate.

Se un provider di modelli pubblica limiti aggiornati, aggiorna la configurazione in modo che corrisponda alle funzionalità documentate dal provider.

Infrastruttura di model serving

Bob richiede l'accesso a uno o più endpoint di inference del modello per eseguire attività basate su AI. Bob si connette ai modelli deployati tramite il Model Inference Gateway ma non esegue il provisioning, l'hosting o la gestione dell'infrastruttura di model serving.

La maggior parte degli ambienti on-premises dispone già di un'infrastruttura di model serving, che si tratti di un cluster GPU condiviso che esegue run.ai, Red Hat OpenShift AI, una farm di serving vLLM dedicata o l'accesso all'API del modello di un provider cloud pubblico (AWS Bedrock, Azure OpenAI, Google Vertex AI). Bob richiede un endpoint raggiungibile dalla rete dal cluster OpenShift che esponga un'API compatibile con OpenAI.

Modelli richiesti e supportati