Guías de integración · 2026-09-11

Migrar del SDK de OpenAI a una pasarela compatible sin reescribir la aplicación

Cambiar de proveedor de modelos de lenguaje suele ser cuestión de dos líneas: la URL base y la clave. Qué se mantiene igual, qué hay que fijar por identificador de modelo y qué comprobar antes de pasar a producción.

Esquema de una migración del SDK de OpenAI a una pasarela compatible mostrando el cambio de URL base, la clave y el identificador de modelo.

Lo que cambia son dos líneas

Una pasarela compatible con OpenAI expone la misma superficie de API que ya está usando. En la práctica eso significa que el SDK sigue siendo el mismo y que la migración se reduce a apuntar la URL base a otro sitio y usar otra clave.

El resto de su código (construcción de mensajes, herramientas, streaming, manejo de errores) no cambia, porque el formato de petición y de respuesta es el mismo.

Cliente de OpenAI apuntando a una pasarela compatible

from openai import OpenAI

client = OpenAI(
    base_url="https://llmtr.com/v1",
    api_key="SU_CLAVE_DE_API",
)

respuesta = client.chat.completions.create(
    model="proveedor/identificador-del-modelo",
    messages=[{"role": "user", "content": "Resume este contrato en cinco puntos."}],
)

print(respuesta.choices[0].message.content)

Fije el modelo por identificador, no por alias

Un alias cómodo del tipo modelo-ultimo es agradable durante el desarrollo y desagradable en producción: el modelo que hay debajo puede cambiar sin que su código se entere, y con él cambian el coste, la latencia y el comportamiento.

La alternativa es fijar el identificador completo con su versión y tratar el cambio de modelo como lo que es: un despliegue. Si el proveedor retira un modelo, lo que quiere recibir es un error explicable que nombre al sucesor, no una respuesta distinta de un modelo que nunca eligió.

Claves y control de gasto

Una migración es un buen momento para arreglar algo que casi siempre está mal desde el primer día: la clave vive en el cliente, o en un repositorio, o en las dos cosas.

La clave pertenece al servidor. El navegador y la aplicación móvil hablan con su backend, y el backend habla con la pasarela. Además de evitar la fuga, eso le da el único sitio donde puede aplicar límites por usuario, registrar el uso y cortar una fuga de gasto sin publicar una versión nueva de la aplicación.

Antes de pasar a producción

Cinco comprobaciones que se hacen en una tarde y evitan las sorpresas caras.

  • Ejecute su conjunto de evaluación contra el modelo nuevo antes de cambiarlo, no después.
  • Verifique que el streaming y las llamadas a herramientas se comportan igual en su caso concreto.
  • Confirme qué devuelve la API cuando el modelo elegido ya no está disponible.
  • Revise el registro de uso: debe poder saber meses después qué modelo atendió una petición.
  • Deje el proveedor anterior configurado hasta que el nuevo lleve una semana en producción.

Frequently asked questions

¿Tengo que cambiar de SDK?

No, si la pasarela expone la superficie compatible con OpenAI. El cliente oficial sigue funcionando cambiando la URL base y la clave.

¿Cambian los precios de los modelos al pasar por una pasarela?

En LLMTR los precios de los modelos se mantienen tal y como figuran en el catálogo. El margen de plataforma se aplica únicamente a la recarga de saldo, no al precio por token del modelo.

¿Puedo seguir usando streaming y llamadas a herramientas?

Depende del modelo y del proveedor que haya detrás, no de la pasarela en abstracto. Compruébelo para el modelo concreto que va a usar antes de migrar.

Artículos relacionados