De $500/mes en facturas de OpenAI a $0: migrando flujos de n8n a modelos locales

Empezaste con un flujo de n8n usando OpenAI. Uno simple — tal vez clasificaba emails entrantes o extraía datos de envíos de formularios. La llamada API costaba fracciones de centavo por ejecución. Apenas perceptible. Así que construiste cinco flujos más. Luego diez. Luego agregaste GPT-4 a los que necesitaban mejor razonamiento. Luego tu colega vio lo que construiste y pidió tres más.

Ahora estás mirando una factura de OpenAI de $500/mes. Y está subiendo.

La cuestión es: la mayoría de esos flujos no necesitan GPT-4. Ni siquiera necesitan GPT-3.5. Necesitan un modelo que sea realmente bueno en una tarea específica — clasificar, extraer, reformatear, resumir — y eso es exactamente lo que hace un modelo ajustado de 7B. La migración de llamadas API de OpenAI a modelos locales ajustados no es tan aterradora como suena, y los ahorros de costos son dramáticos: de cientos de dólares al mes a literalmente cero en costos por token.

Esta guía recorre toda la migración, paso a paso. Auditaremos tus flujos, priorizaremos qué migrar, ajustaremos modelos para cada tipo de flujo, los desplegaremos con Ollama e intercambiaremos los endpoints en n8n sin romper nada.

La auditoría de migración

Antes de migrar cualquier cosa, necesitas saber con qué estás trabajando. El objetivo de la auditoría es inventariar cada flujo de n8n que usa un nodo de IA, categorizar cada uno por complejidad y volumen, e identificar las victorias rápidas.

Paso 1: lista cada flujo con un nodo de IA. En n8n, ve a tu lista de flujos y busca flujos que contengan nodos de OpenAI (o cualquier nodo de IA/LLM). Para cada flujo, documenta:

• Nombre y propósito del flujo
• Qué modelo usa (GPT-4, GPT-4o, GPT-3.5-turbo)
• Ejecuciones aproximadas por día
• Conteo promedio de tokens de entrada por ejecución
• Conteo promedio de tokens de salida por ejecución
• Si usa salida estructurada (modo JSON, function calling)

Paso 2: categoriza por tipo de tarea. La mayoría de los flujos de n8n con IA caen en estos grupos:

Paso 3: calcula costos por flujo. Multiplica las ejecuciones diarias de cada flujo por su uso de tokens y la tarifa por token del modelo. Aquí hay una referencia rápida:

Un flujo ejecutándose 500 veces/día con 800 tokens de entrada y 200 tokens de salida en GPT-4o cuesta:

• Entrada: 500 * 800 = 400K tokens/día = 12M tokens/mes = $30/mes
• Salida: 500 * 200 = 100K tokens/día = 3M tokens/mes = $30/mes
• Total: $60/mes por un solo flujo

Multiplica eso por 10-15 flujos y ves cómo se llega a $500/mes rápidamente.

Qué flujos migrar primero

No todos los flujos son candidatos iguales para migración. Los primeros objetivos ideales son:

Alto volumen, baja complejidad. Un flujo que clasifica 2,000 emails por día en 5 categorías es perfecto. Tiene un patrón claro de entrada-salida, alto volumen (así que altos ahorros) y baja complejidad (un modelo ajustado de 3B puede manejarlo fácilmente).

Salida estructurada. Los flujos que esperan salida JSON — como extraer campos de facturas o parsear datos de formularios — son excelentes candidatos. El formato de salida es restringido y predecible, lo que hace el fine-tuning directo y la evaluación simple. O el JSON es correcto o no lo es.

Patrones repetitivos. Si un flujo hace esencialmente la misma transformación miles de veces con solo los datos de entrada cambiando, el fine-tuning funciona de maravilla. El modelo solo necesita aprender el patrón una vez.

Flujos que NO debes migrar primero:

• Cualquier cosa que requiera conocimiento actualizado del mundo (el modelo ajustado sabe con lo que fue entrenado, nada más)
• Cadenas de razonamiento multipaso donde las salidas anteriores alimentan prompts posteriores
• Generación creativa donde la calidad es subjetiva y difícil de evaluar
• Cualquier cosa con consecuencias de seguridad crítica (asesoría médica, legal, financiera)

Aquí hay un marco de priorización:

El marco de migración

La migración sigue cuatro fases. No te saltes fases. No apresures.

Fase 1: exportar datos de ejecución

Para cada flujo que estás migrando, necesitas los pares reales de entrada-salida de ejecuciones reales. Estos son tus datos de entrenamiento.

Desde los logs de ejecución de n8n: n8n almacena datos de ejecución para cada corrida de flujo. Puedes acceder a esto a través de la API de n8n o directamente desde la base de datos si estás autoalojando. Para cada ejecución de un nodo de IA, extrae:

• El prompt/entrada que se envió a OpenAI
• La respuesta/salida que se recibió
• Si el flujo se completó exitosamente (filtra los fallos)

Enfoque con script de exportación:

// Pseudocode for extracting training pairs from n8n executions
const executions = await n8nApi.getExecutions({
  workflowId: "your-workflow-id",
  status: "success",
  limit: 5000,
});

const trainingData = executions.map((exec) => {
  const aiNode = exec.data.resultData.runData["OpenAI Node"][0];
  return {
    input: aiNode.parameters.prompt,
    output: aiNode.data.main[0][0].json.text,
  };
});

// Write as JSONL
const jsonl = trainingData
  .map((d) => JSON.stringify(d))
  .join("\n");
fs.writeFileSync("training-data.jsonl", jsonl);

¿Cuántos datos necesitas por tipo de flujo?

Para la mayoría de los flujos de n8n, dos a cuatro semanas de logs de ejecución proporcionan más que suficientes datos de entrenamiento.

Fase 2: fine-tuning por flujo

Ahora la pregunta: ¿entrenas un modelo para todos los flujos o un modelo por tipo de flujo?

Un modelo por tipo de flujo es casi siempre la elección correcta. Aquí está por qué:

• Cada modelo puede ser pequeño y rápido (3B-7B parámetros) porque solo necesita manejar una tarea
• La calidad es mayor porque el modelo no está confundido por patrones de tareas en competencia
• Puedes actualizar cada modelo independientemente cuando los requisitos cambien
• Si un modelo tiene bajo rendimiento, solo reentreñas ese — no todo

El proceso de fine-tuning con Ertas:

1. Sube tu archivo de entrenamiento JSONL a Ertas
2. Selecciona el modelo base:
   • Qwen 2.5 3B para clasificación y extracción simples (se ejecuta en 4GB RAM)
   • Qwen 2.5 7B para resumen y generación (se ejecuta en 8GB RAM)
3. Configura el entrenamiento LoRA (los valores por defecto están bien para la mayoría de los flujos)
4. Entrena — 500 ejemplos en un modelo 3B toma unos 15 minutos, 7B toma unos 30 minutos
5. Evalúa contra ejemplos de prueba retenidos
6. Exporta como GGUF

Costo de fine-tuning: Ertas a $14.50/mes incluye entrenamientos ilimitados. Si estás migrando 10 flujos y entrenando un modelo por tipo de flujo (después de deduplicar flujos similares), podrías necesitar 5-7 corridas de entrenamiento. Todo incluido.

Fase 3: desplegar y probar

Despliega todos tus modelos ajustados en una sola instancia de Ollama. Ollama maneja múltiples modelos eficientemente — carga el modelo activo en memoria y puede intercambiar entre modelos en segundos.

Configuración de despliegue:

# Install Ollama on your VPS
curl -fsSL https://ollama.com/install.sh | sh

# Create each model
ollama create email-classifier -f Modelfile.email-classifier
ollama create invoice-extractor -f Modelfile.invoice-extractor
ollama create ticket-summarizer -f Modelfile.ticket-summarizer

Dimensionamiento de VPS para múltiples modelos:

Incluso en el extremo alto — $96/mes por ejecutar más de 10 modelos — estás pagando una fracción de tu factura de OpenAI de $500/mes.

Estrategia de pruebas en paralelo: Antes de intercambiar cualquier cosa en producción, ejecuta tus modelos ajustados en paralelo con tus flujos existentes de OpenAI durante al menos una semana. Así es cómo:

1. Clona cada flujo que estás migrando
2. En el clon, reemplaza el nodo OpenAI con un nodo HTTP Request apuntando a tu endpoint de Ollama
3. Ejecuta ambos flujos simultáneamente en los mismos triggers
4. Compara salidas lado a lado

Crea una hoja de comparación simple:

Quieres al menos un 95% de tasa de coincidencia para flujos de clasificación y extracción. Para generación y resumen, se necesita juicio humano — pero las salidas deberían ser funcionalmente equivalentes, no necesariamente idénticas.

Fase 4: intercambiar y monitorear

Una vez que las pruebas en paralelo confirmen la calidad, intercambia los flujos de producción.

Enfoque de transición gradual:

• Semana 1: Migra flujos P0 (clasificación, extracción). Mantén OpenAI como respaldo — si el modelo local devuelve un error o la confianza es baja, recurre a OpenAI.
• Semana 2: Si P0 es estable, elimina el respaldo de OpenAI para flujos P0. Migra flujos P1 con respaldo.
• Semana 3: Elimina respaldo para P1. Evalúa flujos P2.
• Semana 4: Migra o aplaza P2 basándote en los resultados de evaluación.

Patrón de respaldo en n8n:

Entrada → Modelo local (Ollama) → IF (confianza > umbral) → Usar resultado local
                                                           → ELSE → API OpenAI → Usar resultado API

Para flujos de clasificación, puedes implementar umbrales de confianza basados en las probabilidades de salida del modelo. Para extracción y generación, usa una heurística más simple: si el modelo local devuelve una respuesta válida dentro del formato esperado, úsala. Si da error o devuelve salida malformada, recurre al respaldo.

Checklist de monitoreo:

• Rastrea tasas de error por flujo por día
• Compara tiempos de ejecución (local debería ser más rápido para la mayoría de tareas)
• Registra cualquier evento de respaldo a API e investiga por qué
• Monitorea utilización de recursos del VPS (CPU, RAM)
• Verifica calidad de salida semanalmente muestreando 20-30 resultados por flujo

Calculadora de costos de migración

Así se ven los números para una migración típica:

Antes: costos de API de OpenAI

Después: modelos locales ajustados

Ahorro mensual: $355.50. Ahorro anual: $4,266.

Y esta es una estimación conservadora. A medida que los volúmenes de flujos crecen, los costos de API habrían crecido linealmente mientras los costos de infraestructura local se mantienen fijos. Si tu clasificador de emails se duplica a 1,600 ejecuciones/día, tu costo local sigue siendo $48/mes por el VPS. En OpenAI, ese flujo solo saltaría a $90/mes.

Lo que no migramos (y por qué)

La honestidad importa. No todo debería salir de la API. Aquí están los flujos que intencionalmente mantuvimos en OpenAI:

El generador de reportes. Este flujo toma 15 puntos de datos y genera un análisis de 2,000 palabras con recomendaciones estratégicas. Requiere razonamiento genuino, síntesis de múltiples fuentes de datos y marco creativo. Un modelo 7B puede manejar el formato, pero la calidad analítica cae notablemente comparada con GPT-4. Lo mantuvimos en la API. A 50 ejecuciones/día, el costo es manejable ($62/mes), y la diferencia de calidad importa.

El redactor de emails. Similar al generador de reportes — redacta emails complejos de múltiples párrafos que referencian historial de conversación previo y requieren coincidencia de tono matizada. Un modelo ajustado maneja respuestas simples bien pero tiene dificultades con los borradores extensos y ricos en contexto. Mantuvimos los borradores complejos en GPT-4 y migramos las plantillas de respuesta simple al modelo local, dividiendo el flujo en dos.

Cualquier cosa tocando cálculos financieros. Tenemos un flujo que toma datos crudos de transacciones y produce resúmenes financieros con totales calculados. El cálculo se hace en n8n (no en el LLM), pero el LLM formatea el reporte final. Aunque el LLM solo está formateando, los riesgos son lo suficientemente altos como para mantenerlo en GPT-4 con su menor tasa de alucinación para tareas numéricas. La tranquilidad vale $35/mes.

El patrón: mantén tareas en la API cuando requieran (a) razonamiento genuino sobre entradas novedosas, (b) generación creativa de formato largo, o (c) precisión de alto riesgo donde incluso un 2% de tasa de error es inaceptable.

Resultados después de 30 días

Esto es lo que realmente pasó después de un mes ejecutando el stack migrado:

Reducción de costos: 78%. De $453/mes a $97.50/mes. Esperábamos ahorrar más, pero mantuvimos tres flujos en la API que originalmente planeamos migrar (ver arriba). Los ahorros aún son $4,266/año.

Mejora de latencia: 40% más rápido en promedio. Esto nos sorprendió. La inferencia local en un VPS de Hetzner fue consistentemente más rápida que las llamadas API de OpenAI, especialmente durante horas pico. El clasificador de emails pasó de 800ms promedio (OpenAI) a 320ms promedio (Ollama local). Sin viaje de ida y vuelta de red, sin cola de API, sin limitación de tasa.

Métricas de calidad:

• Precisión de clasificación: 97.2% (local) vs 98.1% (OpenAI). Menos del 1% de diferencia.
• Precisión de extracción: 95.8% (local) vs 96.4% (OpenAI). Diferencia insignificante.
• Calidad de resumen (evaluación humana, 100 muestras): 4.2/5 (local) vs 4.4/5 (OpenAI). Aceptable.

Fiabilidad: Cero tiempo de inactividad en el VPS de Ollama en 30 días. Cero errores de límite de tasa. La API de OpenAI, en comparación, tenía 3-5 errores de límite de tasa por día durante horas pico, cada uno requiriendo lógica de reintento y agregando latencia.

Beneficio sorpresa: privacidad de datos. Con inferencia local, ninguno de nuestros datos de flujo sale de nuestra infraestructura. Para flujos que procesan emails de clientes, facturas y tickets de soporte, esto es un beneficio significativo de cumplimiento que no habíamos valorado completamente al inicio.

La línea de tiempo de migración

Para un equipo con 10-15 flujos de n8n y comodidad técnica moderada, aquí hay una línea de tiempo realista:

• Semana 1: Auditar todos los flujos, categorizar, priorizar. Exportar datos de entrenamiento.
• Semana 2: Ajustar modelos para flujos P0 en Ertas. Configurar VPS con Ollama.
• Semana 3: Pruebas en paralelo para flujos P0. Ajustar modelos P1.
• Semana 4: Cambiar P0 a producción. Iniciar pruebas en paralelo de P1.
• Semana 5-6: Cambiar P1. Evaluar P2. Estabilizar el estado final.

Seis semanas de inicio a fin. Los primeros ahorros de costos llegan en la semana 4. Para la semana 6, estás ejecutando con ahorros completos y confianza.

La factura de OpenAI de $500/mes no era inevitable. Era un artefacto de escalamiento de usar modelos de propósito general para tareas específicas. Los modelos locales ajustados son la solución — y la migración es más directa de lo que crees.

---

Lectura adicional

• De dependiente de API a dueño del modelo: un playbook de migración de 90 días — El plan completo por fases para pasar de API a modelos propios.
• n8n + LLMs locales para automatización compatible con HIPAA — Cómo los modelos locales resuelven el problema de cumplimiento para flujos de salud.
• El playbook de agencia n8n-a-modelo-ajustado — Productizar migraciones de n8n como servicio de agencia.
• El costo oculto del pricing por token de IA — Por qué el pricing por token está fundamentalmente desalineado con negocios sostenibles.