Funcionar sobre modelos abiertos

Aquí los agentes no se escriben contra un modelo concreto. Todo lo que la capa de agentes necesita —chat, vectorización, llamadas a herramientas— pasa por una pasarela que habla la forma HTTP compatible con OpenAI, así que el modelo que hay detrás puede ser una API de frontera alojada, un modelo abierto que usted mismo ejecute, o varios a la vez.

Esta página es el detalle de ingeniería que sostiene esa afirmación. Existe porque «soporta modelos abiertos» se dice fácil y se comprueba difícil, y quien está evaluando una plataforma hace bien en preguntar.

La pasarela

Los backends son filas de una tabla, acotadas por inquilino. Cada uno lleva una URL base, una clave de API, un nombre de modelo, un tipo (chat o embedding) y un peso. Añadir uno o cambiarlo es un cambio de configuración: no hay despliegue ni hay que reescribir ningún agente.

No hay ningún SDK de proveedor en todo el árbol de dependencias. La pasarela hace HTTP normal contra la superficie compatible con OpenAI, y por eso funciona sin código de adaptación cualquier cosa que implemente esa superficie: vLLM, Ollama, servidores de llama.cpp, la mayoría de las APIs comerciales.

Las capacidades se consultan, no se suponen

Al arrancar, la pasarela llama a /v1/models en un backend habilitado y lee lo que ese modelo ofrece de verdad: ventana de contexto, dimensión de la vectorización, capacidades declaradas.

Nada del modelo está fijado en el código. Esto importa más de lo que parece: una plataforma que da por hecha una ventana de contexto del tamaño de un modelo de frontera desbordará en silencio a un modelo abierto con una ventana de 32K, y el fallo aparece como una respuesta truncada o sin sentido en lugar de como un error.

Cuatro formas en que fallan los modelos abiertos pequeños

No son hipótesis. Cada una está resuelta porque apareció en la práctica.

1. Las llamadas a herramientas llegan como texto

Muchos modelos abiertos ignoran el campo estructurado tool_calls y escriben la llamada dentro del cuerpo de la respuesta. Hay dos formas habituales:

<tool_call>
  <function=search_docs>
    <parameter=query>política de devoluciones</parameter>
  </function>
</tool_call>

<tool_call>
{"name": "search_docs", "arguments": {"query": "política de devoluciones"}}
</tool_call>

Si no se hace nada, no se ejecuta nada y el usuario final ve marcado en bruto en el chat. El bucle de herramientas interpreta ambas formas, invoca la herramienta con normalidad y, como última red, elimina cualquier resto de marcado <tool_call> del texto antes de enviarlo. La sintaxis en bruto de una llamada a herramienta no debe llegar jamás a un usuario final, ni siquiera si falla la interpretación.

2. Las llamadas en streaming llegan troceadas

Los servidores compatibles con OpenAI no se ponen de acuerdo sobre cómo repartir una llamada a herramienta entre los fragmentos del streaming. Una sola llamada puede llegar en varios deltas parciales, a veces entremezclados cuando el modelo pide más de una herramienta. Los fragmentos se acumulan por índice y se reensamblan en llamadas completas antes de ejecutar nada.

3. El presupuesto de contexto sale de la ventana real

El presupuesto de entrada utilizable se deriva, no se configura:

presupuesto_entrada =
    ventana_de_contexto_consultada − reserva_de_salida − margen_de_seguridad

con un suelo para que una reserva agresiva no pueda dejar el presupuesto en cero. En un modelo de 32K esto da un presupuesto muy distinto que en uno de un millón de tokens, que es justamente la idea: la misma definición de agente funciona correctamente en ambos.

4. El razonamiento se come la respuesta

En los modelos que emiten razonamiento antes de la respuesta final, un presupuesto de salida dimensionado solo para la respuesta se lo lleva el razonamiento, y el usuario recibe una contestación cortada. El margen de salida se amplía para tener en cuenta los tokens de razonamiento, de modo que la respuesta en sí sobrevive.

Enrutado y conmutación por fallo

Los backends del mismo tipo se eligen por peso, así que el tráfico se puede repartir: por ejemplo, la mayoría de las peticiones a un modelo pequeño autoalojado y el resto a uno alojado más potente. Cuando una petición falla de una forma reintentable, la pasarela prueba con los demás backends elegibles antes de recurrir a la espera exponencial contra el que tiene.

El patrón práctico es repartir por consecuencia y no por dificultad: lo de solo lectura y bajo riesgo en el modelo más barato, y todo lo que escribe o compromete algo en el más potente.

Qué no hace esto

Ser honestos con los bordes resulta más útil que una lista de funcionalidades más larga:

• No convierte un modelo pequeño en uno grande. La selección de herramientas —decidir a cuál llamar y con qué argumentos en una situación enredada de varios pasos— es donde más se nota la calidad del modelo. Pruebe sus propias tareas antes de mover a un modelo más pequeño trabajo de consecuencias serias.
• No gestiona su infraestructura de inferencia. Si se autoaloja, la capacidad de GPU, el servidor de modelo y su disponibilidad son suyos. La pasarela esquiva un backend caído; no puede hacer que uno vaya más rápido.
• No certifica modelos concretos. El trabajo de compatibilidad va sobre las formas que producen los modelos, no sobre una lista probada. Se espera que funcione cualquier endpoint compatible con OpenAI; qué modelo conviene a su carga de trabajo es una evaluación que le toca hacer a usted.

Relacionado

• Traiga su propio modelo — el mismo tema, para quien decide y no para quien integra
• Herramientas y MCP — qué puede invocar realmente el agente
• Privado por diseño — aislamiento, cifrado y qué sale de su entorno