Erfahre mehr über die für Bob Self-Hosted erforderlichen Modelle, einschließlich unterstützter Core-Inferenz-Modelle, Guardrail-Modelle und provider-spezifischer Sicherheitsfunktionen zur Aktivierung KI-gestützter Funktionen.

Bob Self-Hosted erfordert Zugang zu einem unterstützten Core-Inferenz-Modell, um Code-Generierung, Erklärungen, Chat- und Assistenzfunktionen bereitzustellen. Abhängig von deinen Deployment-Anforderungen kannst du Bob mit Air-Gapped-Modellen, die in deiner Umgebung gehostet werden, oder mit Frontier-Modellen verbinden, auf die über Cloud-Provider zugegriffen wird. Für verbesserte Sicherheit und Richtlinienkonformität empfiehlt IBM die Konfiguration eines Guardrail-Modells oder die Nutzung provider-nativer Guardrail-Funktionen.

Erforderliche Modelle

Stelle vor der Installation von Bob sicher, dass die folgenden Modelle deployed und zugänglich sind.

Modellrolle	Zweck
Core-Inferenz-Modell	Verarbeitet Code-Generierung, Erklärungen, Chat-Anfragen und Assistenz-Interaktionen.
Guardrail-Modell	Prüft Eingaben und Ausgaben auf Sicherheit und Richtlinienkonformität. Die Verwendung eines Guardrail-Modells wird dringend empfohlen.

Wichtig:

Konfiguriere jeweils genau ein Core-Inferenz-Modell.

Hinweis:

Ein Guardrail-Modell wird für alle Deployments dringend empfohlen. Für Air-Gapped-Deployments verwende openai/gpt-oss-20b. Wenn konfiguriert, leitet Bob Sicherheits- und Richtlinienbewertungsanfragen automatisch durch den Guardrail-Service.

Unterstützte Modelle

Die folgenden Core-Inferenz-Modelle stehen für IBM Bob Self-Hosted zur Verfügung. Konfiguriere ein einzelnes Core-Inferenz-Modell im Model Gateway. Das gleichzeitige Ausführen mehrerer Core-Inferenz-Modelle wird nicht unterstützt.

Tipp:

Für optimale Ergebnisse bei komplexen IBM Z-Aufgaben – wie tiefgehendem COBOL-Refactoring, PL/I-Analyse und dateiübergreifenden Code-Transformationen – bieten Frontier-Modelle wie Claude Sonnet das höchste Maß an Reasoning, Genauigkeit und Generierungsqualität.

Frontier-Modelle (empfohlen): Bestens geeignet für unternehmensweite IBM Z-Workloads, die erweitertes Reasoning, großes Kontextverständnis und mehrstufige Code-Generierung erfordern.
Selbst gehostete Open-Weight-Modelle: Ideal für strenge Air-Gap-Compliance und standardmäßige Coding-Unterstützung. Bei komplexen Mainframe-Sprachmustern können die Ergebnisse von gezieltem Prompt-Tuning und domänenspezifischem Kontext profitieren.

Air-Gapped-Modelle

Ressourcenanforderungen (CPU, RAM, GPU/VRAM und Concurrency-Sizing) hängen von Modellquantisierung, Kontextlänge, Serving-Runtime (wie vLLM oder TGI) und Zieldurchsatz ab. Die Produktdokumentation enthält Hardwarespezifikationen und Deployment-Leitfäden.

Modell	Referenz
Mistral Medium 3.5	Mistral-AI-Dokumentation / Mistral Medium 3.5
Nvidia Nemotron 3 Ultra	NVIDIA-Nemotron-Dokumentation / Nemotron 3 Ultra FP4 / Nemotron 3 Ultra FP8
Poolside Laguna S 2.1	Poolside-Laguna-S-2.1-FP8-Dokumentation / Poolside-Laguna-S-2.1-NVFP4-Dokumentation / Poolside-Laguna-Modelle

Hinweis:

Mistral Medium 3.5 kann nur verwendet werden, wenn du IBM Bob Premium Package for Z verwendest. Es ist nicht für allgemeine Bob-Self-Hosted-Deployments verfügbar.

Frontier-Modelle

Auf Frontier-Cloud-Modelle wird über provider-verwaltete APIs (z. B. AWS Bedrock, Google Cloud Vertex AI oder Azure OpenAI) zugegriffen. Die Produktdokumentation enthält Informationen zur Serviceverfügbarkeit, Kontingenten, Ratenlimits und Endpoint-Konfiguration.

Modell	Referenz
Claude Sonnet 5	Anthropic-Claude-Dokumentation / AWS Bedrock
Claude Opus 4.8	Anthropic-Claude-Dokumentation / AWS Bedrock
Google Gemini 3.7 Flash	Google-Cloud-Vertex-AI-Dokumentation
OpenAI GPT5.6 Sol	Azure-OpenAI-Service-Dokumentation

Provider-Guardrails

Die Verwendung eines Guardrail-Modells wird dringend für Sicherheit, Toxizitätsfilterung und Richtlinienprüfung über alle Eingaben und Ausgaben hinweg empfohlen. Die Modell-Repository- und Serving-Runtime-Dokumentation enthält Deployment-Details und Hardware-Leitfäden.

Modell	Referenz	Beschreibung
`openai/gpt-oss-20b`	Hugging Face Model Hub / OpenAI-Dokumentation	Erforderlich für Sicherheits- und Richtlinienprüfung

Für Air-Gapped-Modelle verwende openai/gpt-oss-20b, um Guardrails zu implementieren. Nachdem dieses Guardrail-Modell konfiguriert wurde, werden die IDE- und Bob-Shell-Clients automatisch konfiguriert, es für die Content-Filterung zu verwenden.

Frontier-Modell-Guardrails

Bei der Verwendung von Frontier-Modellen kannst du die Guardrail-Funktion des Providers anstelle des openai/gpt-oss-20b-Guardrail-Modells verwenden.

AWS-Bedrock-Guardrails

Erstelle ein Bedrock-Guardrail und ermittle seine guardrailId und Version. Anleitungen findest du in der Bedrock-Guardrails-Dokumentation und der CreateGuardrail-API-Referenz. Füge die Guardrail-Konfiguration unter chat_inference_params für das Bedrock-Modell hinzu:

- 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

Konfiguriere die Vertex-AI-Sicherheitsfilter in chat_inference_params. Siehe die Vertex-AI-Sicherheitsfilter-Dokumentation.

Unterstützte Kategorien	Unterstützte Schwellenwerte
`HARM_CATEGORY_SEXUALLY_EXPLICIT`, `HARM_CATEGORY_HATE_SPEECH`, `HARM_CATEGORY_HARASSMENT`, `HARM_CATEGORY_DANGEROUS_CONTENT`	`BLOCK_NONE`, `BLOCK_ONLY_HIGH`, `BLOCK_MEDIUM_AND_ABOVE` (Standard), `BLOCK_LOW_AND_ABOVE` (strengste)

- 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

Erstelle in Azure einen Content-Filter und weise ihn dem Modell-Deployment zu; keine Änderungen an der Model-Gateway-Konfiguration sind erforderlich. Siehe die Azure-OpenAI-Content-Filter-Dokumentation. Um stattdessen eine Richtlinie zur Anfragenzeit anzuwenden, konfiguriere den 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

Modell-Token-Limits

Die folgenden Token-Limits werden für die unterstützten Modelle empfohlen.

Modell	Maximale Eingabe-Tokens	Maximale Ausgabe-Tokens
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

Modell-Token-Limits konfigurieren

Gib die Token-Limits im Abschnitt model_info der Modelldefinition an.

Beispiel:

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

max_input_tokens definiert die maximale Anzahl von Tokens, die in einer einzelnen Anfrage enthalten sein können, einschließlich Prompts, Gesprächsverlauf und zusätzlichem Kontext.

max_output_tokens definiert die maximale Anzahl von Tokens, die das Modell in einer Antwort generieren kann.

Konfiguriere diese Werte entsprechend den Fähigkeiten des zugrunde liegenden Modells.

Das Setzen von Werten, die die unterstützten Limits des Modells überschreiten, kann zu Anforderungsfehlern oder abgeschnittenen Antworten führen.

Wenn ein Modell-Provider aktualisierte Limits veröffentlicht, aktualisiere die Konfiguration entsprechend den dokumentierten Fähigkeiten des Providers.

Modell-Serving-Infrastruktur

Bob benötigt Zugang zu einem oder mehreren Modell-Inferenz-Endpoints, um KI-gestützte Aufgaben auszuführen. Bob verbindet sich über den Model Inference Gateway mit deployed Modellen, stellt aber keine Modell-Serving-Infrastruktur bereit, hostet sie oder verwaltet sie.

Die meisten Self-Hosted-Umgebungen haben bereits eine Modell-Serving-Infrastruktur verfügbar, sei es ein gemeinsamer GPU-Cluster mit run.ai, Red Hat OpenShift AI, eine dedizierte vLLM-Serving-Farm oder Zugang zur Modell-API eines Public-Cloud-Providers (AWS Bedrock, Azure OpenAI, Google Vertex AI). Bob erfordert einen netzwerkerreichbaren Endpoint vom OpenShift-Cluster aus, der eine OpenAI-kompatible API bereitstellt.

Erforderliche und unterstützte Modelle