Modelos necessários e suportados
Saiba mais sobre os modelos necessários para o Bob on-premises, incluindo modelos de inferência principal suportados, modelos guardrail e recursos de segurança específicos de provedores usados para habilitar capacidades com IA.
O Bob on-premises requer acesso a um modelo de inferência principal suportado para fornecer geração de código, explicações, chat e capacidades de assistente. Dependendo dos seus requisitos de implantação, você pode conectar o Bob a modelos air-gapped hospedados em seu ambiente ou a modelos frontier acessados por provedores de nuvem. Para maior segurança e conformidade com políticas, a IBM recomenda configurar um modelo guardrail ou usar as capacidades guardrail nativas do provedor.
Modelos necessários
Antes de instalar o Bob, certifique-se de que os seguintes modelos estão implantados e acessíveis.
| Função do modelo | Finalidade |
|---|---|
| Modelo de inferência principal | Processa geração de código, explicações, solicitações de chat e interações com assistente. |
| Modelo guardrail | Filtra entradas e saídas para segurança e conformidade com políticas. Usar um modelo guardrail é altamente recomendado. |
Configure exatamente um modelo de inferência principal por vez.
Um modelo guardrail é fortemente recomendado para todas as implantações. Para implantações air-gapped, use openai/gpt-oss-20b. Quando configurado, o Bob roteia automaticamente as solicitações de avaliação de segurança e política pelo serviço guardrail.
Modelos suportados
Os modelos de inferência principal a seguir estão disponíveis para uso com o IBM Bob on-premises. Configure um único modelo de inferência principal no Model Gateway. Executar múltiplos modelos de inferência principal ao mesmo tempo não é suportado.
Modelos air-gapped
Os requisitos de recursos (CPU, RAM, GPU/VRAM e dimensionamento de concorrência) dependem da quantização do modelo, comprimento de contexto, runtime de serviço (como vLLM ou TGI) e throughput alvo. Consulte a documentação do produto para especificações de hardware e guias de implantação.
| Modelo | Referência |
|---|---|
| Mistral 3.5 | Documentação da Mistral AI |
| Nvidia Nemotron 3 | Documentação NVIDIA NeMo / Nemotron |
| Poolside Laguna S2.1 | Documentação da Poolside AI |
Modelos frontier
Os modelos de nuvem frontier são acessados via APIs gerenciadas pelo provedor (como AWS Bedrock, Google Cloud Vertex AI ou Azure OpenAI). Consulte a documentação do produto para disponibilidade de serviço, cotas, limites de taxa e configuração de endpoints.
| Modelo | Referência |
|---|---|
| Claude Sonnet 5 | Documentação Anthropic Claude / AWS Bedrock |
| Claude Opus 4.8 | Documentação Anthropic Claude / AWS Bedrock |
| Google Gemini 3.7 Flash | Documentação Google Cloud Vertex AI |
| OpenAI GPT5.6 Sol | Documentação Azure OpenAI Service |
Guardrails de provedor
Usar um modelo guardrail é altamente recomendado para filtragem de segurança, toxicidade e triagem de políticas em todas as entradas e saídas. Consulte o repositório do modelo e a documentação do runtime de serviço para detalhes de implantação e diretrizes de hardware.
| Modelo | Referência | Descrição |
|---|---|---|
openai/gpt-oss-20b | Hugging Face Model Hub / Documentação OpenAI | Necessário para triagem de segurança e política |
Para modelos air-gapped, use openai/gpt-oss-20b para implementar guardrails. Após este modelo guardrail ser configurado, os clientes IDE e Bob Shell são automaticamente configurados para usá-lo para filtragem de conteúdo.
Guardrails de modelos frontier
Ao usar modelos frontier, você pode usar a capacidade guardrail do provedor em vez do modelo guardrail openai/gpt-oss-20b.
Guardrails AWS Bedrock
Crie um guardrail Bedrock e obtenha seu guardrailId e versão. Para orientação, consulte a documentação de guardrails do Bedrock e a referência da API CreateGuardrail. Adicione a configuração de guardrail em chat_inference_params para o modelo 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
chat_inference_params:
guardrailConfig:
guardrailIdentifier: <guardrail-id>
guardrailVersion: <version-number-or-DRAFT>Google Vertex AI
Configure os filtros de segurança do Vertex AI em chat_inference_params. Consulte a documentação de filtros de segurança do Vertex AI.
| Categorias suportadas | Limites suportados |
|---|---|
HARM_CATEGORY_SEXUALLY_EXPLICIT, HARM_CATEGORY_HATE_SPEECH, HARM_CATEGORY_HARASSMENT, HARM_CATEGORY_DANGEROUS_CONTENT | BLOCK_NONE, BLOCK_ONLY_HIGH, BLOCK_MEDIUM_AND_ABOVE (padrão), BLOCK_LOW_AND_ABOVE (mais restritivo) |
- 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_ABOVEAzure OpenAI
No Azure, crie um filtro de conteúdo e atribua-o à implantação do modelo; nenhuma alteração na configuração do model gateway é necessária. Consulte a documentação de filtro de conteúdo do Azure OpenAI. Para aplicar uma política no momento da solicitação, configure o 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: trueInfraestrutura de serviço de modelo
O Bob requer acesso a um ou mais endpoints de inferência de modelo para realizar tarefas com IA. O Bob se conecta a modelos implantados por meio do Model Inference Gateway, mas não provisiona, hospeda nem gerencia infraestrutura de serviço de modelo.
A maioria dos ambientes on-premises já possui infraestrutura de serviço de modelo disponível, seja um cluster GPU compartilhado executando run.ai, Red Hat OpenShift AI, uma farm de serviço vLLM dedicada, ou acesso à API de modelo de um provedor de nuvem pública (AWS Bedrock, Azure OpenAI, Google Vertex AI). O Bob requer um endpoint acessível pela rede a partir do cluster OpenShift que expõe uma API compatível com OpenAI.
Para mais informações sobre a implantação de um modelo suportado, consulte Infraestrutura de serviço de modelo.