Cómo migrar de OpenAI a un modelo open source sin reescribir tu código (guía 2026)

La objeción más común cuando propongo migrar a un modelo abierto no es la calidad. Es esta: “ya tengo todo integrado con OpenAI, no quiero reescribir nada”.

La buena noticia: no hay que reescribir casi nada. El ecosistema open source adoptó la API de OpenAI como estándar de facto. Migrar es, en la mayoría de los casos, cambiar dos líneas: la URL base y la API key.

Paso 0: medí lo que gastás hoy

Antes de tocar código, entrá al dashboard de OpenAI o Anthropic y anotá tres números por endpoint:

1. Tokens de entrada por mes
2. Tokens de salida por mes
3. Qué tarea hace cada llamada (chat, clasificación, extracción, resumen, RAG, agente)

Este desglose importa porque el ahorro no es parejo: una tarea de clasificación migra casi sin riesgo; un agente complejo de razonamiento necesita más pruebas.

Paso 1: elegí 2-3 modelos candidatos

Regla práctica por tarea:

• Chat, soporte, resumen, RAG: los modelos abiertos actuales sobran. Candidatos: DeepSeek, Qwen, Llama, GPT-OSS.
• Código y agentes: los modelos abiertos de razonamiento (Kimi, DeepSeek, GLM) compiten de igual a igual en muchos benchmarks.
• Razonamiento de frontera absoluta: acá los cerrados todavía suelen ganar. Si tu producto vive de esto, migrá solo las partes que no lo necesitan.

No elijas por el hype: elegí por el benchmark más parecido a tu tarea, y después validá con tus propios datos (paso 2).

Paso 2: evals con TUS datos, no con benchmarks

Los benchmarks públicos te dicen qué modelos probar, no cuál usar. Armá un set de evaluación con 100-500 casos reales de tu producto (entradas reales, salidas esperadas) y corré los candidatos contra el modelo actual.

• Si el modelo abierto empata o supera → migrás con evidencia.
• Si queda cerca → a veces un prompt ajustado o un modelo un escalón más grande lo resuelve.
• Si queda lejos → no migres esa parte. Migrar donde no cierra la calidad es la forma más rápida de quemar la iniciativa.

Herramientas útiles: promptfoo, Braintrust, o un script propio con la misma interfaz.

Paso 3: proveedor gestionado o self-hosting

Dos caminos, y la decisión es de números, no de ideología:

API de proveedor (Groq, Together, DeepSeek, Fireworks, DeepInfra…)

• Cero operación: mismo modelo de uso que OpenAI, factura por token.
• El precio por token ya es una fracción del de los modelos cerrados.
• Ideal para volumen bajo y medio, o para validar la migración.

Self-hosting (vLLM o SGLang sobre GPUs propias o alquiladas)

• Conviene con volumen muy alto sostenido: frente a las API cerradas el break-even ronda los cientos de millones de tokens al mes, pero frente a un proveedor de modelos abiertos se va a miles de millones; por debajo, la GPU ociosa te come el ahorro (una GPU al 10% de uso multiplica tu costo por token por 10).
• Imprescindible cuando los datos no pueden salir de tu infraestructura (salud, banca, datos regulados).
• Requiere alguien que opere: monitoreo, actualizaciones, colas.

Mi recomendación habitual: empezá por proveedor, medí un mes, y recién ahí evaluá self-hosting si el volumen lo justifica.

Paso 4: el cambio de código (en serio, es esto)

Con cualquier proveedor compatible —o con vLLM, que expone la misma API—:

import os

from openai import OpenAI

client = OpenAI(
    base_url="https://api.tu-proveedor.com/v1",  # antes: api.openai.com/v1
    api_key=os.environ["PROVIDER_API_KEY"],
    # el resto del código no cambia
)

Lo mismo aplica a los SDK de JavaScript, a LangChain, a LiteLLM y a casi cualquier framework: todos aceptan baseURL personalizada.

Paso 5: rollout con red de seguridad

1. Doble escritura: mandá una fracción del tráfico (5-10%) al modelo nuevo y compará salidas en producción.
2. Monitoreo de calidad: las mismas evals del paso 2, corriendo periódicamente contra tráfico real.
3. Rollback en un flag: como la interfaz es la misma, volver atrás es cambiar una variable de entorno.

Errores comunes

• Migrar todo de golpe. Migrá endpoint por endpoint, empezando por el de mayor volumen y menor riesgo.
• Comparar solo el precio de lista. Contá también tokens cacheados, batch discounts y el costo de operación si vas a self-hosting.
• Saltarse las evals. “Se ve bien en el playground” no es una evaluación.
• Ignorar los límites de rate. Verificá que el proveedor aguante tu pico de tráfico antes de mover el 100%.

En resumen

Migrar de OpenAI a un modelo abierto en 2026 no es un proyecto de meses: es una auditoría de uso, una semana de evals y un cambio de URL con rollout gradual. El riesgo se controla con datos; el ahorro, en la mayoría de los casos de uso reales, es de un orden de magnitud.

¿Querés que lo haga por vos? Ofrezco este proceso completo como servicio: migración a modelos de IA open source. Para dimensionar el ahorro, mirá la comparación de precios 2026 y los casos reales de empresas que migraron; y antes de decidir, leé también cuándo NO conviene.