Dowiedz się o modelach wymaganych przez IBM Bob samodzielnie wdrożonego, w tym obsługiwanych głównych modelach wnioskowania, modelach guardrail i natywnych dla dostawców funkcjach bezpieczeństwa używanych do włączania funkcji AI.

IBM Bob samodzielnie wdrożony wymaga dostępu do obsługiwanego głównego modelu wnioskowania, aby zapewnić generowanie kodu, wyjaśnienia, czat i funkcje asystenta. W zależności od wymagań wdrożenia możesz podłączyć Bob do modeli air-gapped hostowanych w Twoim środowisku lub modeli frontier dostępnych przez dostawców chmurowych. Dla zwiększonego bezpieczeństwa i zgodności z zasadami IBM zaleca konfigurację modelu guardrail lub korzystanie z natywnych dla dostawcy funkcji guardrail.

Wymagane modele

Przed instalacją Bob upewnij się, że następujące modele są wdrożone i dostępne.

Rola modelu	Cel
Główny model wnioskowania	Przetwarza generowanie kodu, wyjaśnienia, żądania czatu i interakcje asystenta.
Model guardrail	Skanuje dane wejściowe i wyjściowe pod kątem bezpieczeństwa i zgodności z zasadami. Korzystanie z modelu guardrail jest wysoce zalecane.

Ważne:

Konfiguruj dokładnie jeden główny model wnioskowania naraz.

Uwaga:

Model guardrail jest zdecydowanie zalecany dla wszystkich wdrożeń. W przypadku wdrożeń air-gapped użyj openai/gpt-oss-20b. Po skonfigurowaniu Bob automatycznie kieruje żądania oceny bezpieczeństwa i zasad przez usługę guardrail.

Obsługiwane modele

Następujące główne modele wnioskowania są dostępne do użytku z IBM Bob samodzielnie wdrożonym. Skonfiguruj jeden główny model wnioskowania w bramie modelu. Uruchamianie wielu głównych modeli wnioskowania jednocześnie nie jest obsługiwane.

Wskazówka:

Aby uzyskać optymalne wyniki w złożonych zadaniach IBM Z, takich jak dogłębny refaktoring COBOL, analiza PL/I i transformacje kodu obejmujące wiele plików, modele frontier, takie jak Claude Sonnet, zapewniają najwyższy poziom rozumowania, dokładności i jakości generowania.

Modele frontier (zalecane): Najlepiej nadają się do korporacyjnych obciążeń IBM Z wymagających zaawansowanego rozumowania, rozumienia dużego kontekstu i wieloetapowego generowania kodu.
Samodzielnie hostowane modele open-weight: Idealne do ścisłej zgodności z wymaganiami air-gap i standardowej pomocy w kodowaniu. W przypadku złożonych wzorców języka mainframe wyniki mogą skorzystać na ukierunkowanym dostosowaniu promptów i kontekście specyficznym dla danej dziedziny.

Modele air-gapped

Wymagania dotyczące zasobów (CPU, RAM, GPU/VRAM i rozmiarowanie współbieżności) zależą od kwantyzacji modelu, długości kontekstu, środowiska uruchomieniowego (takiego jak vLLM lub TGI) i docelowej przepustowości. Zapoznaj się z dokumentacją produktu, aby uzyskać specyfikacje sprzętowe i przewodniki wdrożenia.

Model	Odniesienie
Mistral Medium 3.5	Dokumentacja Mistral AI / Mistral Medium 3.5
Nvidia Nemotron 3 Ultra	Dokumentacja NVIDIA Nemotron / Nemotron 3 Ultra FP4 / Nemotron 3 Ultra FP8
Poolside Laguna S 2.1	Dokumentacja Poolside Laguna-S-2.1-FP8 / Dokumentacja Poolside Laguna-S-2.1-NVFP4 / Modele Poolside Laguna

Uwaga:

Możesz używać Mistral Medium 3.5 tylko wtedy, gdy korzystasz z IBM Bob Premium Package for Z. Nie jest dostępny w standardowych wdrożeniach Bob self-hosted.

Modele frontier

Modele chmurowe frontier są dostępne przez interfejsy API zarządzane przez dostawców (takie jak AWS Bedrock, Google Cloud Vertex AI lub Azure OpenAI). Zapoznaj się z dokumentacją produktu, aby uzyskać informacje o dostępności usług, limitach, ograniczeniach przepustowości i konfiguracji punktów końcowych.

Model	Odniesienie
Claude Sonnet 5	Dokumentacja Anthropic Claude / AWS Bedrock
Claude Opus 4.8	Dokumentacja Anthropic Claude / AWS Bedrock
Google Gemini 3.7 Flash	Dokumentacja Google Cloud Vertex AI
OpenAI GPT5.6 Sol	Dokumentacja usługi Azure OpenAI

Guardrail dostawców

Korzystanie z modelu guardrail jest wysoce zalecane dla bezpieczeństwa, filtrowania toksycznych treści i skanowania zasad we wszystkich danych wejściowych i wyjściowych. Zapoznaj się z dokumentacją repozytorium modeli i środowiska uruchomieniowego serwowania, aby uzyskać szczegóły wdrożenia i wytyczne dotyczące sprzętu.

Model	Odniesienie	Opis
`openai/gpt-oss-20b`	Hugging Face Model Hub / Dokumentacja OpenAI	Wymagany do skanowania bezpieczeństwa i zasad

W przypadku modeli air-gapped użyj openai/gpt-oss-20b, aby wdrożyć guardrail. Po skonfigurowaniu tego modelu guardrail klienty IDE i Bob Shell są automatycznie konfigurowane do korzystania z niego do filtrowania treści.

Guardrail modeli frontier

W przypadku korzystania z modeli frontier możesz użyć natywnej funkcji guardrail dostawcy zamiast modelu guardrail openai/gpt-oss-20b.

AWS Bedrock guardrails

Utwórz guardrail Bedrock i uzyskaj jego guardrailId oraz wersję. Wskazówki znajdziesz w dokumentacji guardrails Bedrock i dokumentacji API CreateGuardrail. Dodaj konfigurację guardrail w sekcji chat_inference_params dla modelu 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

Skonfiguruj filtry bezpieczeństwa Vertex AI w chat_inference_params. Zobacz dokumentację filtrów bezpieczeństwa Vertex AI.

Obsługiwane kategorie	Obsługiwane progi
`HARM_CATEGORY_SEXUALLY_EXPLICIT`, `HARM_CATEGORY_HATE_SPEECH`, `HARM_CATEGORY_HARASSMENT`, `HARM_CATEGORY_DANGEROUS_CONTENT`	`BLOCK_NONE`, `BLOCK_ONLY_HIGH`, `BLOCK_MEDIUM_AND_ABOVE` (domyślny), `BLOCK_LOW_AND_ABOVE` (najbardziej restrykcyjny)

- 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

Na platformie Azure utwórz filtr treści i przypisz go do wdrożenia modelu; nie są wymagane żadne zmiany konfiguracji bramy modelu. Zobacz dokumentację filtru treści Azure OpenAI. Aby zamiast tego zastosować zasadę w czasie żądania, skonfiguruj nagłówek 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

Limity tokenów modeli

Poniższe limity tokenów są zalecane dla obsługiwanych modeli.

Model	Maksymalna liczba tokenów wejściowych	Maksymalna liczba tokenów wyjściowych
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

Konfiguracja limitów tokenów modeli

Podaj limity tokenów w sekcji model_info definicji modelu.

Na przykład:

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

max_input_tokens określa maksymalną liczbę tokenów, które mogą być zawarte w jednym żądaniu, w tym prompt-y, historię rozmowy i wszelki dodatkowy kontekst.

max_output_tokens określa maksymalną liczbę tokenów, które model może wygenerować w odpowiedzi.

Skonfiguruj te wartości zgodnie z możliwościami bazowego modelu.

Ustawienie wartości przekraczających obsługiwane limity modelu może skutkować błędami żądań lub obciętymi odpowiedziami.

Jeśli dostawca modelu opublikuje zaktualizowane limity, zaktualizuj konfigurację, aby odpowiadała udokumentowanym możliwościom dostawcy.

Infrastruktura do serwowania modeli

Bob wymaga dostępu do jednego lub więcej punktów końcowych wnioskowania modeli do wykonywania zadań opartych na AI. Bob łączy się z wdrożonymi modelami przez bramę wnioskowania modelu, ale nie aprowizuje, nie hostuje ani nie zarządza infrastrukturą do serwowania modeli.

Większość środowisk self-hosted ma już dostępną infrastrukturę do serwowania modeli, czy to w postaci wspólnego klastra GPU z run.ai, Red Hat OpenShift AI, dedykowanej farmy serwowania vLLM, czy dostępu do API modeli dostawcy chmury publicznej (AWS Bedrock, Azure OpenAI, Google Vertex AI). Bob wymaga dostępnego z klastra OpenShift punktu końcowego udostępniającego API zgodne z OpenAI.

Wymagane i obsługiwane modele