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

Bob On-Premises 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 On-Premises zur Verfügung. Konfiguriere ein einzelnes Core-Inferenz-Modell im Model Gateway. Das gleichzeitige Ausführen mehrerer Core-Inferenz-Modelle wird nicht unterstützt.

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 3.5	Mistral-AI-Dokumentation
Nvidia Nemotron 3	NVIDIA-NeMo/Nemotron-Dokumentation
Poolside Laguna S2.1	Poolside-AI-Dokumentation

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

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_tokens: 12000
    max_input_tokens: 200000
    exposed: true

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 On-Premises-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.

Weitere Informationen zum Deployen eines unterstützten Modells findest du unter Modell-Serving-Infrastruktur.

Erforderliche und unterstützte Modelle