Conoce los modelos requeridos por Bob on-premises, incluyendo los modelos de inferencia principal compatibles, los modelos guardrail y las funciones de seguridad específicas de cada proveedor usadas para habilitar las capacidades de IA.

Bob on-premises requiere acceso a un modelo de inferencia principal compatible para proporcionar generación de código, explicaciones, chat y capacidades de asistente. Según tus requisitos de despliegue, puedes conectar Bob a modelos air-gapped alojados en tu entorno o a modelos frontier accesibles a través de proveedores cloud. Para mayor seguridad y cumplimiento de políticas, IBM recomienda configurar un modelo guardrail o usar las capacidades de guardrail nativas del proveedor.

Modelos requeridos

Antes de instalar Bob, asegúrate de que los siguientes modelos están desplegados y son accesibles.

Rol del modelo	Propósito
Modelo de inferencia principal	Procesa solicitudes de generación de código, explicaciones, chat e interacciones con el asistente.
Modelo guardrail	Filtra las entradas y salidas para garantizar la seguridad y el cumplimiento de políticas. Se recomienda encarecidamente usar un modelo guardrail.

Importante:

Configura exactamente un modelo de inferencia principal a la vez.

Nota:

Se recomienda encarecidamente un modelo guardrail para todos los despliegues. Para despliegues air-gapped, usa openai/gpt-oss-20b. Cuando está configurado, Bob enruta automáticamente las solicitudes de evaluación de seguridad y políticas a través del servicio guardrail.

Modelos compatibles

Los siguientes modelos de inferencia principal están disponibles para usar con IBM Bob on-premises. Configura un único modelo de inferencia principal en el gateway de modelos. No se admite la ejecución de varios modelos de inferencia principal al mismo tiempo.

Modelos air-gapped

Los requisitos de recursos (CPU, RAM, GPU/VRAM y dimensionamiento de concurrencia) dependen de la cuantización del modelo, la longitud del contexto, el runtime de servicio (como vLLM o TGI) y el rendimiento objetivo. Consulta la documentación del producto para conocer las especificaciones de hardware y las guías de despliegue.

Modelo	Referencia
Mistral 3.5	Documentación de Mistral AI
Nvidia Nemotron 3	Documentación de NVIDIA NeMo / Nemotron
Poolside Laguna S2.1	Documentación de Poolside AI

Modelos frontier

Los modelos cloud frontier se acceden a través de APIs gestionadas por el proveedor (como AWS Bedrock, Google Cloud Vertex AI o Azure OpenAI). Consulta la documentación del producto para conocer la disponibilidad del servicio, las cuotas, los límites de tasa y la configuración del endpoint.

Modelo	Referencia
Claude Sonnet 5	Documentación de Anthropic Claude / AWS Bedrock
Claude Opus 4.8	Documentación de Anthropic Claude / AWS Bedrock
Google Gemini 3.7 Flash	Documentación de Google Cloud Vertex AI
OpenAI GPT5.6 Sol	Documentación del servicio Azure OpenAI

Guardrails de proveedores

Se recomienda encarecidamente usar un modelo guardrail para el filtrado de seguridad, toxicidad y análisis de políticas en todas las entradas y salidas. Consulta la documentación del repositorio del modelo y del runtime de servicio para conocer los detalles de despliegue y las directrices de hardware.

Modelo	Referencia	Descripción
`openai/gpt-oss-20b`	Hugging Face Model Hub / Documentación de OpenAI	Requerido para el análisis de seguridad y políticas

Para modelos air-gapped, usa openai/gpt-oss-20b para implementar guardrails. Una vez que este modelo guardrail esté configurado, los clientes IDE y Bob Shell se configuran automáticamente para usarlo en el filtrado de contenido.

Guardrails de modelos frontier

Al usar modelos frontier, puedes usar la capacidad de guardrail del proveedor en lugar del modelo guardrail openai/gpt-oss-20b.

Guardrails de AWS Bedrock

Crea un guardrail de Bedrock y obtén su guardrailId y versión. Para más información, consulta la documentación de guardrails de Bedrock y la referencia de la API CreateGuardrail. Añade la configuración del guardrail bajo chat_inference_params para el 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

Configura los filtros de seguridad de Vertex AI en chat_inference_params. Consulta la documentación de filtros de seguridad de Vertex AI.

Categorías compatibles	Umbrales compatibles
`HARM_CATEGORY_SEXUALLY_EXPLICIT`, `HARM_CATEGORY_HATE_SPEECH`, `HARM_CATEGORY_HARASSMENT`, `HARM_CATEGORY_DANGEROUS_CONTENT`	`BLOCK_NONE`, `BLOCK_ONLY_HIGH`, `BLOCK_MEDIUM_AND_ABOVE` (predeterminado), `BLOCK_LOW_AND_ABOVE` (más estricto)

- 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

En Azure, crea un filtro de contenido y asígnalo al despliegue del modelo; no se requieren cambios en la configuración del gateway de modelos. Consulta la documentación de filtros de contenido de Azure OpenAI. Para aplicar una política en el momento de la solicitud, configura la cabecera 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

Infraestructura de servicio de modelos

Bob requiere acceso a uno o más endpoints de inferencia de modelos para realizar tareas impulsadas por IA. Bob se conecta a los modelos desplegados a través del gateway de inferencia de modelos, pero no aprovisiona, aloja ni gestiona la infraestructura de servicio de modelos.

La mayoría de los entornos on-premises ya tienen infraestructura de servicio de modelos disponible, ya sea un clúster de GPU compartido con run.ai, Red Hat OpenShift AI, una granja de servicio vLLM dedicada o acceso a la API de modelos de un proveedor cloud público (AWS Bedrock, Azure OpenAI, Google Vertex AI). Bob requiere un endpoint accesible desde la red del clúster de OpenShift que exponga una API compatible con OpenAI.

Para más información sobre el despliegue de un modelo compatible, consulta Infraestructura de servicio de modelos.

Modelos requeridos y compatibles