De Prototipo a Producto: Reemplazando Llamadas API con Modelos Ajustados

Tu prototipo funciona. Lo construiste con Lovable o Bolt o Replit, conectaste la API de OpenAI y los usuarios empezaron a registrarse. Quizás tienes 500 usuarios. Quizás 2,000. El product-market fit se siente real.

Pero aquí está el problema en el que no pensaste en la etapa de "simplemente lanzémoslo": cada interacción de IA cuesta dinero. No mucho por llamada — quizás $0.003 a $0.02 dependiendo del modelo y la cantidad de tokens — pero se acumula. Con 2,000 usuarios haciendo 10 solicitudes de IA por día, estás quemando $600–$1,200/mes solo en costos de API.

Tu prototipo funciona. Tu economía unitaria no.

Esta guía es el playbook paso a paso para migrar de APIs en la nube a modelos locales ajustados. Está escrita para vibecoders que tienen un producto funcionando y necesitan hacer que la economía funcione — sin romper lo que ya está funcionando.

La Brecha Prototipo-a-Producción de la que Nadie Habla

Todo tutorial de IA termina en el mismo lugar: "¡y ahora tu app usa GPT-4!" Nadie habla de lo que pasa en el mes 3 cuando tienes usuarios y la factura de API es una línea significativa.

La brecha entre prototipo y producción no es calidad de código ni cobertura de tests. Para apps vibe-coded, es estructura de costos. Tu prototipo asumía llamadas API baratas e infinitas. Producción requiere costos predecibles y acotados.

Aquí están las buenas noticias: no tienes que reescribir tu app. No necesitas convertirte en ingeniero de ML. Necesitas reemplazar las llamadas API más costosas con un modelo que posees y ejecutas tú mismo. El resto se mantiene igual.

Fase 1: Audita Tu Uso de API

Antes de cambiar nada, entiende qué estás gastando y dónde. Registra cada llamada API por 2 semanas. Para cada llamada, rastrea:

• Endpoint/funcionalidad: ¿Qué funcionalidad de tu app la activó?
• Tokens de entrada: ¿Qué tan grande es el prompt?
• Tokens de salida: ¿Qué tan grande es la respuesta?
• Frecuencia: ¿Cuántas veces por día ocurre esta llamada?
• Costo por llamada: Tokens de entrada x precio de entrada + tokens de salida x precio de salida.

Generalmente encontrarás algo así:

Esta auditoría es el paso más importante. Te dice exactamente dónde enfocarte.

Fase 2: Identifica Candidatos para Fine-Tuning

No toda llamada API debería ser reemplazada. Busca llamadas que sean:

• Alto volumen: Las llamadas que ocurren miles de veces al día. Incluso pequeños ahorros por llamada se acumulan.
• Repetitivas: El modelo hace básicamente el mismo tipo de tarea cada vez. Clasifica esto. Resume aquello. Extrae estos campos.
• Específicas de dominio: Tu app tiene un vocabulario, formato o dominio específico. GPT-4 genérico es excesivo.
• Salidas tipo plantilla: La respuesta sigue una estructura o formato consistente.

En el ejemplo anterior, los mejores candidatos son:

1. Clasificación de contenido — Alto volumen, tarea simple, salida estructurada. Un modelo ajustado de 3.8B maneja esto fácilmente.
2. Análisis de tono — Tarea de clasificación simple. No necesita un modelo frontera.
3. Generación de resúmenes — Tarea repetitiva con formato consistente. Territorio de modelo ajustado de 7B.
4. Respuestas de chat — El mayor gasto. Más complejo, pero si tu chat sigue patrones (soporte al cliente, Q&A de dominio), un modelo ajustado de 8B funciona bien.

Qué se queda en la API:

5. Análisis complejo — Bajo volumen, alta complejidad, razonamiento variable. Mantén esto en GPT-4o o Claude. Es solo el 11% de tu gasto pero necesita capacidad de modelo frontera.

Fase 3: Recolecta Datos de Entrenamiento de Tus Logs de API

Has estado pagándole a OpenAI durante meses. El lado positivo: cada llamada API que has hecho es un ejemplo de entrenamiento.

Para cada candidato de fine-tuning, extrae 2,000–5,000 pares de entrada-salida de tus logs. Filtra por calidad:

• Elimina ejemplos donde los usuarios se quejaron o corrigieron la salida
• Elimina ejemplos con respuestas de error o salidas truncadas
• Elimina valores atípicos (prompts anormalmente largos, casos extremos)
• Conserva ejemplos que representen el "camino feliz" de cada funcionalidad

Formatea como JSONL:

{"input": "Classify the following customer message: 'I need to update my billing address'", "output": "category: account_management, intent: update_info, urgency: low"}

Consejo profesional: si no tienes suficientes ejemplos para una funcionalidad específica, ejecuta tu configuración actual de API por otra semana y registra agresivamente. 2,000 ejemplos limpios es el mínimo para un fine-tune sólido. 5,000 es mejor.

Fase 4: Ajusta con Ertas

Para cada funcionalidad candidata, entrena un adaptador LoRA separado. ¿Por qué separados? Porque cada funcionalidad tiene requisitos diferentes, y adaptadores separados te permiten actualizar uno sin tocar los demás.

Aquí está el flujo de trabajo real:

1. Sube tu dataset a Ertas Vault. Un dataset por funcionalidad.
2. Selecciona tu modelo base. Para tareas simples (clasificación, extracción): Phi-4 3.8B. Para tareas moderadas (resúmenes, generación): Qwen 2.5 7B o Llama 3.3 8B.
3. Configura el entrenamiento. Los valores predeterminados funcionan bien. Si quieres ajustar: 3–5 epochs, learning rate 2e-4, LoRA rank 16–32.
4. Entrena. Toma 20–60 minutos por adaptador dependiendo del tamaño del dataset.
5. Evalúa. Ertas te muestra métricas de precisión contra un conjunto de prueba separado. Quieres más del 90% de tasa de coincidencia en tu tarea antes de proceder.

Si la precisión está por debajo del 85%, la solución casi siempre es calidad de datos. Vuelve a tus ejemplos de entrenamiento, elimina los ruidosos, agrega más representativos y reentrena.

Fase 5: Despliega Junto a Tu App

Exporta cada modelo ajustado como un archivo GGUF (cuantización Q5_K_M). Despliega en un VPS ejecutando Ollama.

Tu configuración de producción se ve así:

┌─────────────┐     ┌──────────────────────┐
│  Tu App      │────▶│  Tu VPS (Ollama)     │
│  (Vercel /   │     │                      │
│   Railway)   │     │  ├─ classify-model   │
│              │     │  ├─ summary-model    │
│              │────▶│  └─ chat-model       │
│              │     └──────────────────────┘
│              │
│              │     ┌──────────────────────┐
│              │────▶│  OpenAI API          │
│              │     │  (solo tareas compl.)│
└─────────────┘     └──────────────────────┘

Ollama sirve una API compatible con OpenAI en el puerto 11434. El código de tu app apenas cambia — estás cambiando una URL y nombre de modelo, no reescribiendo lógica.

Para múltiples modelos en un servidor, Ollama maneja la carga y descarga de modelos automáticamente. Un VPS de 32GB de RAM ($50–80/mes) sirve cómodamente 2–3 modelos ajustados de 7B.

Fase 6: Migración Gradual

No cambies todo de golpe. Migra gradualmente:

Semana 1 — Modo sombra. Envía cada solicitud tanto a tu modelo ajustado COMO a la API. Compara salidas. No sirvas la salida del modelo ajustado a los usuarios todavía. Registra discrepancias.

Semana 2 — Enrutamiento al 10%. Enruta 10% del tráfico al modelo ajustado. Monitorea el comportamiento de usuarios — ¿las tasas de completado, métricas de engagement y tasas de error son estables?

Semana 3 — Enrutamiento al 50%. La mitad de tu tráfico va al modelo ajustado. Tu factura de API debería bajar notablemente. Observa casos extremos que el modelo ajustado maneje mal.

Semana 4 — Cambio completo. Enruta todo el tráfico candidato al modelo ajustado. Mantén la API como respaldo para solicitudes donde la confianza es baja.

Este enfoque gradual te permite detectar problemas antes de que afecten a todos tus usuarios. Es la diferencia entre "migramos sin problemas" y "rompimos la app por un día."

La Arquitectura Antes y Después

Antes: Todo API

• Cada funcionalidad de IA → API de OpenAI
• Costo: $3,834/mes y creciendo
• Riesgo: Un cambio de precios de la API rompe tu negocio
• Latencia: 200–800ms por solicitud (red + inferencia)

Después: Híbrido

• Clasificación, tono, resúmenes, chat → Modelos ajustados en VPS
• Análisis complejo → API de OpenAI (conservado para casos extremos)
• Costo: $80/mes (VPS) + $14.50/mes (Ertas) + ~$120/mes (API para tareas complejas) = $214.50/mes
• Ahorro: $3,619/mes (reducción del 94%)
• Latencia: 50–200ms para modelos locales, más rápido que la API

Eso no es un error tipográfico. Pasar de $3,834 a $214.50 es lo que sucede cuando dejas de pagar por token por tareas que un modelo ajustado pequeño maneja mejor de todos modos.

Qué Mantener en APIs

Sé honesto sobre lo que los modelos ajustados no pueden hacer:

• Tareas creativas abiertas donde el usuario puede preguntar literalmente cualquier cosa
• Razonamiento complejo de múltiples pasos que requiere la capacidad de un modelo frontera
• Tareas donde tienes menos de 500 ejemplos de entrenamiento (no es suficiente para ajustar bien)
• Funcionalidades nuevas en las que aún estás iterando (usa la API hasta que la funcionalidad se estabilice, luego ajusta)

El objetivo no es cero costos de API. Es enrutar las solicitudes correctas a los modelos correctos. Modelos frontera para tareas frontera. Tus modelos para tus tareas.

La Mentalidad de Migración

Esto es lo que la mayoría de vibecoders no ven: la migración de API a modelos ajustados no es un proyecto único. Es un cambio de mentalidad.

Cada funcionalidad nueva empieza en la API. Eso está bien — es la forma más rápida de validar. Pero una vez que una funcionalidad se estabiliza y sabes cómo se ve una buena salida, ajustas. Lo mueves a tu stack. Lo posees.

Con el tiempo, tus costos de API se aproximan asintóticamente a un número fijo pequeño — solo las cosas genuinamente complejas. Todo lo rutinario corre en modelos que posees, en infraestructura que controlas, a costos que no escalan con tus usuarios.

Así se ve producción para una app vibe-coded en 2026.

---

Lecturas Adicionales

• Migrate from OpenAI API to a Fine-Tuned Local Model — La guía técnica detallada para cambiar llamadas API por inferencia local.
• From Lovable Prototype to Real Product — Qué más cambia cuando pasas de prototipo a producción.
• Fine-Tune a Model for Your App — Guía de extremo a extremo para entrenar un modelo en tu caso de uso específico.