Cómo Migrar de la API de OpenAI a un Modelo Local con Fine-Tuning: Un Plan de 90 Días

OpenAI firmó un contrato con el Departamento de Defensa de EE.UU. Anthropic rechazó un acuerdo similar. Las deprecaciones de modelos continúan. Los precios son impredecibles. Y tú estás ejecutando una carga de trabajo de IA en producción que depende de infraestructura que no controlas.

Si has decidido que es hora de ser dueño de al menos una parte de tu stack de IA, este es el plan.

Esta no es una guía teórica. Es un plan operativo de 90 días para mover una carga de trabajo real de IA — tus tareas de mayor volumen y más predecibles — desde una API en la nube a un modelo con fine-tuning que posees y ejecutas localmente. Para el día 90, tendrás un sistema de IA en producción sin costos por token, sin cambios de comportamiento del proveedor y sin pivotes estratégicos.

Cuándo NO Migrar

Antes de empezar, sé honesto sobre qué cargas de trabajo son buenas candidatas y cuáles no.

No migres tareas que: requieran razonamiento de frontera en problemas abiertos y novedosos (escritura creativa al más alto nivel, razonamiento complejo de múltiples pasos en dominios amplios); tengan volumen muy bajo (menos de 1,000 llamadas API por mes — la nube es más barata a esa escala); cambien sus requisitos de entrada/salida frecuentemente, haciendo costoso el mantenimiento de datos de entrenamiento; o genuinamente necesiten las capacidades más recientes de modelos que el open-source aún no ha alcanzado.

Buenos candidatos para migración tienen: alto volumen (más de 10,000 llamadas por mes); alcance de tarea consistente y estrecho (clasificación, extracción, resumen con formato definido, Q&A sobre un dominio específico); datos de entrenamiento disponibles de logs o ejemplos etiquetados existentes; y requisitos de calidad donde 90-95% de precisión en la tarea específica es suficiente (que lo es para la mayoría de cargas de trabajo de dominio específico).

La Auditoría Pre-Migración

Antes de escribir una línea de datos de entrenamiento, haz inventario de tus cargas de trabajo de IA. Para cada caso de uso, captura: volumen mensual, estimación de costo mensual de API, tipo de tarea (clasificación/extracción/generación/Q&A), si el formato de entrada/salida es consistente, y si tienes o puedes crear más de 200 buenos ejemplos.

Puntúa cada caso de uso: alto volumen × tarea consistente × datos de entrenamiento disponibles = alta prioridad de migración. Elige tus 1-3 candidatos principales. Empieza con uno. No intentes migrar todo de una vez.

Días 1–30: Construye Tu Base de Evaluación

El trabajo más importante en la migración es la evaluación. Necesitas poder medir si el modelo con fine-tuning realmente iguala tu configuración actual de API antes de cambiar cualquier cosa en producción.

Construye Tu Dataset de Entrenamiento

Desde tus logs de API (la mayoría de proveedores de API te permiten exportar), recopila ejemplos donde el modelo produjo buenas salidas. Estás buscando:

200–500 pares de entrada/salida de alta calidad que representen la distribución real de tu caso de uso
Cobertura de patrones comunes (el 80% de entradas que se ven similares) y casos edge (el 20% que son más difíciles)
Salidas limpias — no incluyas ejemplos donde la API produjo algo que tuviste que corregir manualmente

Formatéalos como JSONL con la estructura {"messages": [{"role": "user", "content": "..."}, {"role": "assistant", "content": "..."}]}.

Si no tienes logs de API, crea ejemplos manualmente. 200 ejemplos de alta calidad superan a 2,000 ruidosos. Calidad sobre cantidad es el principio más importante del fine-tuning.

Construye Tu Set de Evaluación

Separado de los datos de entrenamiento: 50–100 ejemplos reservados que no usarás para entrenar. Así es como mides la calidad del modelo.

Asegúrate de que tu set de evaluación incluya casos edge que puedan exponer fallas — formatos de entrada inusuales, condiciones límite, el 10% más difícil de tu carga de trabajo real.

Establece Tu Línea Base de API

Ejecuta todo tu set de evaluación a través de tu configuración actual de API y registra cada salida. Calcula tus métricas base (precisión para clasificación, ROUGE/BLEU para generación, puntuaciones de juicio humano para tareas abiertas).

Define tus criterios de aceptación ahora: ¿qué necesita lograr el modelo con fine-tuning para reemplazar la API? Un objetivo común es ±5% de la línea base de API en tu set de evaluación. Algunos equipos apuntan a igualar el rendimiento; otros aceptan una pequeña degradación a cambio de los beneficios de costo y control.

Días 31–60: Fine-Tuning y Validación

Elige Tu Modelo Base

Para la mayoría de tareas de dominio específico, un modelo de 7B–14B parámetros con fine-tuning en tus datos igualará o superará el rendimiento de clase GPT-4. Los modelos base más grandes no siempre son mejores — son más lentos, más costosos de ejecutar, y la ganancia del fine-tuning suele ser menor.

Puntos de partida recomendados:

Llama 3.1 8B o 3.3 70B (Meta): uso comercial permitido; la Licencia Comunitaria de Llama 3 permite redistribución de modelos con fine-tuning
Qwen 2.5 7B o 14B (Alibaba): uso comercial permitido; fuerte rendimiento multilingüe
Mistral 7B (Mistral): licencia Apache 2.0 — completamente permisiva para uso comercial
Phi-4 (Microsoft): licencia MIT; excelente rendimiento a escala pequeña

Si tu tarea involucra documentos largos o razonamiento complejo, empieza con el rango de 14B. Si tu tarea es estrecha y de alto volumen (clasificación, extracción), 7B generalmente es suficiente.

Ajusta con Ertas Studio

Sube tu dataset de entrenamiento, selecciona tu modelo base y configura los ajustes de LoRA (Low-Rank Adaptation). El fine-tuning con LoRA entrena una pequeña capa de adaptador sobre el modelo base congelado — eficiente, rápido, y el adaptador resultante típicamente es de 50–200MB en lugar del tamaño completo del modelo.

La configuración toma unos 2 minutos. Entrenar un modelo 7B con 500 ejemplos típicamente se completa en menos de una hora en GPUs en la nube.

Evalúa Contra Tu Línea Base

Ejecuta el modelo con fine-tuning en tu set de evaluación completo. Compara con la línea base de API que estableciste en los Días 1–30.

Si la calidad cumple tus criterios de aceptación: exporta a formato GGUF y procede al despliegue.

Si la calidad no alcanza: las correcciones más comunes son:

Expandir datos de entrenamiento (agregar 200 ejemplos más de alta calidad enfocados en los casos donde el modelo falla)
Ajustar el rango de LoRA (mayor rango = más capacidad para aprender; prueba rango 16 o 32 si empezaste en 8)
Probar un modelo base más grande (7B → 14B)
Revisar la calidad de tus datos de entrenamiento — ejemplos inconsistentes confunden al modelo más que cantidad insuficiente

La mayoría de equipos necesitan 1–2 iteraciones. Tres rondas de refinamiento es un techo razonable antes de reconsiderar la preparación de la tarea para migración.

Exportar a GGUF

GGUF es un formato abierto que se ejecuta en Ollama, llama.cpp, LM Studio y otros runtimes de inferencia. Exportar a GGUF te da un modelo portátil que funciona en cualquier hardware compatible — sin dependencia de la nube, sin API de inferencia, solo los pesos que posees.

Días 61–90: Despliegue en Paralelo y Transición

Aquí es donde reduces el riesgo de la transición. Ejecutas el modelo con fine-tuning junto con la API, cambiando tráfico gradualmente.

Semana 9: Despliega el modelo con fine-tuning en tu infraestructura local (Ollama es el punto de partida más simple — ollama run your-model). Enruta el 10% del tráfico de producción al modelo con fine-tuning. Monitorea las salidas por problemas de calidad.

Semana 10: Si las métricas de calidad de la primera semana coinciden con tus expectativas, enruta el 25% del tráfico al modelo con fine-tuning. Empieza a rastrear el ahorro de costos.

Semana 11: Enruta el 50% del tráfico. Revisa cualquier caso que activó un fallback a la API — estos son tus candidatos de casos edge para la siguiente iteración de fine-tuning.

Semana 12: Si todas las métricas se mantienen, enruta el 100% del tráfico al modelo con fine-tuning. Mantén el código de integración con la API en su lugar pero desactívalo para esta carga de trabajo. Déjalo como fallback por 30 días mientras construyes confianza, luego evalúa si eliminarlo por completo.

La Economía

Un ejemplo real: una agencia ejecutando 15 flujos de automatización de clientes en la API de OpenAI estaba gastando AU$4,200/mes. Adaptadores LoRA por cliente ejecutándose localmente en infraestructura compartida cuestan AU$14.50/mes. Eso es una reducción del 99.6% — y los modelos con fine-tuning realmente superaron a la API en las tareas específicas del dominio.

Con 8,000 usuarios en una app SaaS indie: API en la nube a $620/mes se convierte en aproximadamente $28/mes en inferencia local. Con 40,000 usuarios, la nube era $3,000/mes. Local sigue siendo aproximadamente $28/mes — el costo por consulta es esencialmente cero una vez que la infraestructura está funcionando.

El punto de equilibrio de la inversión en fine-tuning (tu tiempo para datos de entrenamiento + costos de cómputo de fine-tuning) es típicamente de 2–4 meses a volumen moderado.

Lo Que Posees en el Día 90

Una carga de trabajo de IA en producción con:

Versión de modelo fijada: tú decides cuándo se actualiza, no tu proveedor
Comportamiento determinista: el modelo no cambia hasta que entrenas una nueva versión
Cero costos por consulta: la inferencia local funciona a costo de infraestructura, no por token
Portabilidad total: GGUF se ejecuta en cualquier hardware compatible
Gobernanza completa: sabes exactamente con qué fue entrenado el modelo, cuándo y por quién

Sin cambios de comportamiento del proveedor. Sin pivotes estratégicos. Sin avisos de deprecación. Sin aumentos de precio. El modelo es tuyo.

Ver precios early bird →

Ertas Studio maneja todo el pipeline desde la carga del dataset hasta la exportación a GGUF — sin Python, sin configs YAML, sin CLI. Empieza con una cuenta gratuita y ajusta tu primer modelo antes de comprometerte con nada.