Por qué 'compatible con OpenAI' es necesario pero no suficiente
“Compatible con OpenAI” significa que un servidor usa la misma forma de solicitud y respuesta que la API de Chat Completions de OpenAI, así que los SDK y las herramientas existentes apuntan a él con solo cambiar una URL. Eso es realmente útil: es la razón por la que se puede cambiar a un modelo local. Pero Chat Completions es sin estado y mínima: se envía el historial completo de mensajes en cada turno, se recibe texto de vuelta y, en general, eso es todo. La promesa de compatibilidad cubre el protocolo, no las capacidades, y los servidores locales implementan subconjuntos distintos, muchas veces el más limitado.
El resultado: la demostración funciona y luego producción deja al descubierto todo lo que el endpoint no hace por usted. Abajo está la lista de verificación de lo que realmente significa “más que un endpoint”.
La brecha, punto por punto
Conversaciones con estado
Chat Completions no guarda estado: usted almacena y reenvía todo el historial en cada turno, lo que se vuelve caro y engorroso a medida que crecen las conversaciones. La API más reciente de OpenAI, Responses, agrega estado del lado del servidor (un previous_response_id para continuar un hilo), de modo que el servidor lleva el contexto por usted. La mayoría de los servidores locales no exponen la API de Responses o solo exponen su variante sin estado, así que usted termina reconstruyendo por su cuenta la persistencia de las conversaciones.
Llamadas a herramientas y funciones
Los agentes necesitan que el modelo llame herramientas de forma confiable y que el servidor haga el ida y vuelta de la llamada y su resultado. Los endpoints compatibles varían muchísimo en la fidelidad de las llamadas a herramientas según el modelo y la implementación: algunos la anuncian y en silencio devuelven prosa en lugar de una llamada estructurada. Si su producto es agéntico, esto es lo primero que hay que probar, no suponer. Vea la explicación sobre el uso de herramientas.
Salida estructurada
Obtener JSON válido garantizado (salida restringida por un esquema) es una función del servidor, no algo que venga dado. Sin ella se obtiene “algo que casi es JSON” y se escriben analizadores frágiles. Algunas plataformas locales admiten decodificación restringida o esquemas JSON; muchas no, y es justo el tipo de cosa que un benchmark sobre sus tareas revela rápido.
Streaming, y eventos en streaming
El streaming de tokens es común, pero el streaming de eventos estructurados (fragmentos de llamadas a herramientas, pasos de razonamiento, salida estructurada parcial) es donde los endpoints compatibles divergen. Una interfaz de chat puede funcionar bien; una interfaz de agente que muestra en vivo los pasos de las herramientas necesita un streaming más rico que el que da el mínimo.
Archivos y multimodal
Subir un archivo o una imagen y hacer referencia a ellos a lo largo de varios turnos es una capacidad administrada en las grandes API. En local, normalmente uno mismo conecta el almacenamiento, la extracción y la inyección en el contexto: el endpoint solo recibe texto.
Conteo de tokens y observabilidad
No se puede optimizar lo que no se ve. Los conteos de tokens por solicitud, la latencia, las tasas de error y las trazas son la forma de detectar una regresión o un gasto desbocado. Un endpoint a secas registra poco; producción necesita trazabilidad (existen opciones de código abierto, como la observabilidad al estilo de Langfuse) para que el costo y la calidad se puedan medir, la misma razón por la que todo este sitio mide modelos.
Manejo de errores, límites y seguridad
Los desbordamientos de longitud de contexto, los límites de tasa, los tiempos de espera, los reintentos, la autenticación y los topes por usuario quedan todos a su cargo. Las API alojadas absorben buena parte de esto; un endpoint local se lo devuelve. El ángulo del gasto desbocado está en el Manual contra el impuesto de tokens.
El estándar a seguir: Open Responses
Esto no es solo una queja sobre las herramientas locales: el ecosistema se está moviendo. OpenAI cambió su propia interfaz recomendada de Chat Completions a la API de Responses (con estado, herramientas, eventos en streaming y multimodalidad integrados), y luego desarrolló, junto con un amplio grupo de actores del ecosistema que incluye a NVIDIA, Vercel, OpenRouter, Hugging Face, LM Studio, Ollama y vLLM, una especificación abierta: Open Responses. La dirección es clara: el piso del servicio local está subiendo de “un endpoint de chat” hacia “un endpoint de Responses con estado y capaz de usar herramientas”. Al elegir hoy una plataforma de servicio, revise en qué punto de esa curva está, no solo si /chat/completions responde.
Construirlo o ponerle algo enfrente: la decisión
Hay dos opciones honestas para cerrar la brecha, y la correcta depende de la escala:
- Construir usted mismo la capa que falta: almacén de conversaciones, ida y vuelta de herramientas, validación de esquemas, trazabilidad. Control total y un costo de ingeniería real; tiene sentido cuando sus necesidades son acotadas o poco comunes.
- Poner un gateway delante del modelo que agregue esa capa. Es una categoría de producto, no una sola herramienta: gateways de API o proxies (por ejemplo, proxies del tipo LiteLLM para presupuestos, claves y enrutamiento), capas de observabilidad (trazabilidad del tipo Langfuse) y una clase más nueva de gateways para la API de Responses que ponen conversaciones con estado, herramientas, archivos y observabilidad delante de un entorno local como Ollama. Evalúelos según qué puntos de la brecha cierran de verdad para su plataforma, no según la lista de funciones.
La misma división que planteamos para el enrutamiento (usted decide el qué, el gateway se encarga del cómo) aplica aquí: conserve las partes que son el valor de su producto y delegue la plomería que no lo es.
En resumen
Alojar por su cuenta un modelo abierto es el 80% fácil. Un endpoint compatible con OpenAI le da una solicitud que funciona en minutos, y luego el 20% restante (estado, herramientas, salida estructurada, archivos, observabilidad, límites) es la mayor parte del producto real. Planee la capa de servicio con tanto cuidado como planea el modelo: elija una plataforma por lo que sirve, no solo por lo que responde, y mida las capacidades de las que depende antes de lanzar. Un modelo que pasa su benchmark pero no puede llamar una herramienta de forma confiable a través de su endpoint en realidad no se ha lanzado.
- Cómo entrenar un modelo abierto: el paso previo a este; servir el modelo es lo que viene después.
- El Manual contra el impuesto de tokens: la palanca del autoalojamiento y las cuentas del punto de equilibrio.
- Usar modelos chinos con seguridad: aislamiento de red para el servicio autoalojado.
- Enrutamiento de prompts · Uso de herramientas: las capacidades que la capa de servicio tiene que soportar.