Deja de pagar por usuario por IA: La arquitectura de costo fijo para apps indie

Aquí está el secreto sucio de la mayoría de las apps SaaS con IA: cada nuevo usuario hace el negocio menos rentable. No en el sentido abstracto de "bueno, los servidores cuestan dinero" que aplica a todo software. En el sentido muy concreto de "cada solicitud de IA cuesta $0.003 y mi usuario promedio hace 45 solicitudes por día" que devora tu margen.

SaaS tradicional tiene costos marginales casi cero. Agregar el usuario número 10,001 no te cuesta esencialmente nada — los servidores ya están funcionando, el código ya está escrito. SaaS con IA rompe este modelo. Con precios por token, cada usuario genera un aumento aproximadamente proporcional en tu factura de IA. Tus ingresos escalan con la cantidad de usuarios. Tus costos de IA también escalan con la cantidad de usuarios. Y si tu costo de IA por usuario está cerca de tus ingresos por usuario, tienes un negocio que empeora a medida que tiene éxito.

Hay una mejor arquitectura. Una donde tu infraestructura de IA cuesta lo mismo tengas 100 usuarios o 100,000 usuarios. No es teórica — está corriendo en producción hoy para desarrolladores indie que entendieron las matemáticas temprano. Esta guía explica qué es, cómo construirla y exactamente cuándo funciona y cuándo no.

El problema del costo por usuario

Hagamos el problema dolorosamente concreto. Has construido una app con IA — digamos una herramienta de optimización de contenido. Cada usuario envía texto, la IA lo analiza y devuelve sugerencias. Lo estándar. Estás cobrando $19/mes por usuario.

Así se ven tus costos de IA a medida que creces, asumiendo precios de GPT-4o y uso moderado (30 solicitudes de IA por usuario por día, promediando 1,000 tokens de entrada y 500 tokens de salida por solicitud):

Al 3.6% de los ingresos, esto se ve manejable. Pero este es el escenario optimista. En realidad:

Los usuarios intensivos destruyen tus promedios. Tu top 10% de usuarios genera el 40-60% de tus solicitudes de IA. Algunos usuarios disparan más de 100 solicitudes por día. Ese promedio de "30 solicitudes por usuario por día" enmascara una larga cola de uso intensivo que infla tus costos.

El encadenamiento de prompts multiplica los tokens. Funcionalidades estilo agente, lógica de reintentos y flujos de trabajo de múltiples pasos pueden multiplicar de 2 a 5 veces tu conteo de tokens por acción de usuario. Un solo botón de "optimizar mi artículo" podría disparar tres llamadas al LLM detrás de escena.

Las ventanas de contexto crecen con el tiempo. A medida que los usuarios construyen historial en tu app, los prompts se hacen más largos. Ese promedio de 1,000 tokens de entrada se acerca a 3,000-4,000 tokens a medida que incluyes historial de conversación, preferencias del usuario y resultados anteriores.

Una imagen más realista con usuarios intensivos y encadenamiento de prompts:

Ahora el 10% de tus ingresos se va a inferencia de IA. Para un desarrollador indie sin financiamiento de VC, eso es una porción masiva de tu margen bruto. Y a diferencia de los costos de hosting (que escalan sub-linealmente gracias al caching, CDNs y arquitecturas eficientes), los costos de API de IA escalan linealmente. No hay truco de caching que ayude cuando cada solicitud es única.

Qué significa "costo fijo"

Una arquitectura de IA de costo fijo es una donde tus costos de inferencia de IA están determinados por tu infraestructura, no por tu uso. Pagas por servidores, no por tokens. Ya sea que esos servidores procesen 1,000 solicitudes o 100,000 solicitudes por mes, el costo de infraestructura es el mismo.

La idea central es simple: en lugar de enviar cada solicitud de IA a una API que cobra por token, ejecutas el modelo de IA tú mismo en hardware que controlas. El modelo corre en tu VPS. El VPS cuesta una cantidad fija mensual. El costo por solicitud es cero.

Esto solo es viable gracias a tres desarrollos que convergieron en 2025-2026:

1. Los modelos pequeños open-source se volvieron suficientemente buenos. Qwen 2.5 7B, Llama 3.3 8B y modelos similares pueden manejar la mayoría de las tareas de IA específicas de una app cuando se ajustan. Ya no necesitas GPT-4 para todo.
2. Fine-tuning se volvió accesible. Herramientas como Ertas permiten que desarrolladores que no son de ML ajusten modelos con los datos de su app en menos de una hora. Sin PyTorch. Sin cluster de GPU. Sin PhD.
3. La inferencia local se volvió rápida. Ollama y llama.cpp hicieron posible ejecutar modelos 7B cuantizados en hardware básico a 15-30 tokens por segundo — suficientemente rápido para uso en producción.

La arquitectura de costo fijo combina las tres: ajusta un modelo pequeño para tu tarea específica, despliégalo en un VPS de costo fijo y sirve a todos tus usuarios desde esa infraestructura.

La arquitectura

Aquí está la arquitectura completa para una app de IA de costo fijo:

┌──────────────────────────────────────────────┐
│  Your App (Frontend + API)                    │
│  Hosted on Vercel / Railway / Fly.io          │
└────────────────────┬─────────────────────────┘
                     │
          ┌──────────┴──────────┐
          │                     │
          ▼                     ▼
   ┌────────────┐     ┌──────────────────┐
   │  Request    │     │  Database         │
   │  Router     │     │  (Supabase/Neon)  │
   │             │     └──────────────────┘
   └──┬──────┬──┘
      │      │
  95% │      │ 5%
      ▼      ▼
┌──────────┐ ┌──────────┐
│  Ollama   │ │ OpenAI   │
│  (Local)  │ │ API      │
│  $30/mo   │ │ (fallback│
│  flat     │ │  only)   │
└──────────┘ └──────────┘

Cuatro componentes hacen que esto funcione. Repasemos cada uno.

Componente 1: Modelos pequeños ajustados

La base de la IA de costo fijo es usar un modelo que está específicamente entrenado para tu caso de uso, en lugar de un modelo de frontera de propósito general.

Por qué los modelos pequeños funcionan para tareas específicas de apps: La mayoría de las funcionalidades de IA en apps SaaS realizan una tarea estrecha y repetitiva. Clasificar este texto. Extraer estos campos. Reescribir este párrafo en este tono. Generar un resumen de estos datos. Estas no son tareas que requieran toda la amplitud del conocimiento de GPT-4 sobre la historia romana antigua y la mecánica cuántica. Requieren un modelo que ha aprendido profundamente un patrón específico.

Un modelo de 7B parámetros ajustado con 1,000 ejemplos de tu tarea específica igualará el rendimiento de GPT-4 para esa tarea aproximadamente el 90-95% del tiempo. Para el 5-10% restante de casos límite, tienes un fallback (Componente 3). Pero la idea clave es: no necesitas perfección del modelo local. Necesitas "suficientemente bueno para el 95% de las solicitudes" — porque ese 95% es lo que te cuesta dinero a escala.

Eligiendo tu modelo base:

Para la mayoría de las apps indie, Qwen 2.5 7B es la opción predeterminada. Ofrece el mejor balance entre capacidad y eficiencia de recursos.

Fine-tuning con Ertas: Sube tus datos de entrenamiento JSONL (pares de entrada-salida de tus logs de API existentes), selecciona el modelo base y entrena con LoRA. Todo el proceso toma 30-60 minutos en Ertas. Costo: $14.50/mes por ejecuciones de entrenamiento ilimitadas.

Los datos de entrenamiento provienen de tu app existente. Si has estado usando la API de OpenAI, ya tienes miles de pares de entrada-salida en tus logs. Expórtalos, límpialos y súbelos. Literalmente estás entrenando tu modelo de reemplazo con el trabajo que el modelo caro ya hizo.

Componente 2: Inferencia local con Ollama

Ollama es el runtime que sirve tu modelo ajustado como una API local. Instálalo en un VPS, carga tu modelo, y cada solicitud de IA que haga tu app se sirve localmente con cero costo por token.

Opciones de infraestructura y costos:

Un VPS de $26/mes en Hetzner ejecutando Ollama con un modelo 7B cuantizado maneja 15-25 tokens por segundo. Para una app típica donde cada solicitud de IA genera 200-500 tokens de salida, eso se traduce en aproximadamente 2-4 solicitudes por segundo de throughput sostenido. Eso es de 170,000 a 345,000 solicitudes por día.

A menos que tu app tenga tráfico extremadamente irregular, un solo VPS de $26/mes maneja más tráfico del que la mayoría de las apps indie jamás verán.

Componente 3: Enrutamiento inteligente de solicitudes

No toda solicitud necesita ir a tu modelo local. Y no toda solicitud puede ser manejada por tu modelo local. El enrutamiento inteligente es el pegamento que hace que la arquitectura funcione de manera confiable.

La lógica de enrutamiento es simple:

1. Toda solicitud de IA llega primero al router
2. El router envía la solicitud al modelo local de Ollama
3. Si Ollama devuelve una respuesta válida dentro del formato esperado, úsala
4. Si Ollama da error, agota el tiempo o devuelve una respuesta malformada, recurre a la API de OpenAI

Implementación en tu app:

async function aiRequest(input: string): Promise<string> {
  try {
    // Try local model first
    const localResponse = await fetch("http://ollama-vps:11434/api/generate", {
      method: "POST",
      body: JSON.stringify({
        model: "my-fine-tuned-model",
        prompt: input,
        stream: false,
      }),
      signal: AbortSignal.timeout(10000), // 10s timeout
    });

    const result = await localResponse.json();

    // Validate response format
    if (isValidResponse(result.response)) {
      return result.response;
    }

    // Invalid format — fall back
    return await openaiRequest(input);
  } catch (error) {
    // Error or timeout — fall back
    return await openaiRequest(input);
  }
}

En la práctica, la distribución de enrutamiento se ve así:

La idea clave: no necesitas manejar el 100% localmente desde el primer día. Comienza en 80% local e itera. Cada mes, revisa las solicitudes que cayeron al API, agrégalas a tus datos de entrenamiento, reentrena y despliega el modelo actualizado. Con el tiempo, el modelo local maneja más y más casos límite, y tus costos de API se acercan a cero.

En la etapa madura, el 2-3% que todavía va al API es genuinamente difícil — casos límite novedosos, entradas inusuales, solicitudes que son fundamentalmente diferentes de tus datos de entrenamiento. Ese costo residual de API es trivial.

Componente 4: Escalado horizontal

En algún momento, un VPS no es suficiente. Cuando alcanzas tráfico alto sostenido que excede el throughput de una sola instancia, escalas horizontalmente — agregas más instancias de VPS, cada una ejecutando el mismo modelo.

Las matemáticas del escalado:

Nota el costo por usuario. Con escalado horizontal, tu costo de IA por usuario disminuye a medida que creces. Con 100,000 usuarios, estás pagando $0.002 por usuario por mes en inferencia de IA. Con la API de OpenAI a la misma escala, estarías pagando aproximadamente $0.68 por usuario por mes (basado en las estimaciones de costos realistas anteriores).

Eso es una diferencia de costo de 340 veces.

El balanceo de carga entre múltiples instancias de Ollama es sencillo. Usa un balanceador de carga simple de round-robin o least-connections (nginx, HAProxy o el LB integrado de tu proveedor de nube) frente a tu flota de Ollama. Cada instancia ejecuta el modelo idéntico, así que cualquier instancia puede manejar cualquier solicitud.

Modelado de costos: API vs costo fijo a escala

Aquí está la comparación completa, incluyendo todos los costos de infraestructura:

El punto de equilibrio es notablemente bajo — alrededor de 100-200 usuarios, dependiendo de los patrones de uso. Por debajo de eso, la arquitectura de costo fijo es comparable o ligeramente más barata. Por encima, los ahorros son dramáticos y se acumulan con cada usuario adicional.

Con 10,000 usuarios, estás ahorrando $6,582.50 por mes — $78,990 por año. Eso no es un error de redondeo. Eso es la diferencia entre un negocio de estilo de vida y uno que lucha.

Planteémoslo de otra manera. Si cobras $19/mes por usuario y tienes 10,000 usuarios, tus ingresos mensuales son $190,000. Con la arquitectura de API, $6,750 van a OpenAI (3.6% — o realistamente $19,000 al 10% con usuarios intensivos). Con la arquitectura de costo fijo, $167.50 van a infraestructura de IA (0.09% de los ingresos). Esa diferencia de margen se acumula cada mes.

Cuándo el costo fijo no funciona

La arquitectura de costo fijo no es universalmente superior. Aquí están los escenarios donde quedarse con una API (o usar un enfoque híbrido) tiene más sentido:

Tareas multimodales en tiempo real. Si tu app procesa imágenes, audio o video con IA, necesitas modelos y hardware que son significativamente más caros de auto-hospedar. Los modelos de visión requieren GPUs con VRAM sustancial. Los modelos de transcripción de audio como Whisper son intensivos en CPU. Las matemáticas de costo fijo todavía funcionan, pero los costos de infraestructura son más altos, empujando el punto de equilibrio a 1,000-5,000 usuarios.

Tareas de razonamiento de vanguardia. Si tu app genuinamente requiere razonamiento a nivel de GPT-4 o Claude — análisis complejo de múltiples pasos, escritura creativa matizada, generación avanzada de código — un modelo 7B ajustado puede no ser suficiente. Estas tareas representan la frontera de la capacidad de IA, y los modelos pequeños simplemente no pueden replicarlas. Sin embargo, audita tu app honestamente: la mayoría de las afirmaciones de "necesitamos GPT-4" no sobreviven al escrutinio. La mayoría de las tareas de IA en apps son más estrechas de lo que los desarrolladores piensan.

Conjuntos de tareas extremadamente diversos. Si tu funcionalidad de IA maneja cientos de tipos de tareas fundamentalmente diferentes sin un patrón dominante, fine-tuning se vuelve impráctico (necesitarías docenas de modelos especializados). Esto es raro en la práctica — la mayoría de las apps tienen de 3 a 5 tareas de IA principales que representan el 90% de las solicitudes.

Etapa muy temprana (pre product-market fit). Si todavía estás iterando sobre lo que hace tu funcionalidad de IA, comprometerte con fine-tuning es prematuro. Usa la API mientras descifras el producto. Una vez que sepas qué hace tu IA (y puedas articularlo como un patrón claro de entrada-salida), ahí es cuando cambias a costo fijo.

Entornos regulatorios que requieren modelos certificados. Algunas industrias reguladas requieren modelos de IA que hayan sido específicamente certificados o auditados. Los modelos open-source auto-hospedados pueden no cumplir estos requisitos. Consulta con tu equipo de cumplimiento antes de migrar.

Hoja de ruta de implementación

Aquí hay un plan de cuatro semanas para migrar de API a arquitectura de costo fijo:

Semana 1: Recopilación de datos y auditoría

• Habilita el logging en todas las llamadas de API de IA (entrada, salida, latencia, costo)
• Ejecuta durante una semana para establecer métricas base
• Categoriza tus tareas de IA e identifica las de mayor volumen
• Calcula tu costo actual de IA por usuario

Semana 2: Fine-Tuning

• Exporta 500-2,000 pares de entrada-salida de tus logs de API para tu tarea de mayor volumen
• Sube a Ertas y ajusta en Qwen 2.5 7B
• Evalúa: prueba 50 entradas y compara las salidas con las respuestas de GPT-4
• Si la calidad es aceptable (más del 90% de coincidencia), procede. Si no, limpia tus datos de entrenamiento y reentrena.

Semana 3: Despliegue y pruebas en paralelo

• Levanta un Hetzner CX42 ($26/mes) e instala Ollama
• Despliega tu modelo ajustado
• Implementa el router de solicitudes con fallback a API
• Ejecuta en paralelo: envía cada solicitud tanto al local como al API, compara resultados
• Monitorea durante una semana

Semana 4: Cambio y monitoreo

• Cambia el tráfico de producción a la arquitectura local-primero
• Mantén el fallback a API activo (de todos modos estás pagando por él — solo se llama cuando el local falla)
• Monitorea tasas de error, latencia y retroalimentación de usuarios
• Después de una semana de operación estable, considera migrar tu siguiente tarea de IA

Repite las semanas 2-4 para cada tipo de tarea de IA en tu app. La mayoría de las apps indie tienen de 2 a 4 tareas de IA distintas, así que la migración completa toma de 4 a 8 semanas.

La conclusión

Los precios por token de IA crean un modelo de negocio donde el éxito te castiga. Más usuarios significa más costos de IA, y a escala esos costos consumen tu margen.

La arquitectura de costo fijo rompe ese acoplamiento. Tus costos de infraestructura de IA están fijados por el hardware que ejecutas, no por los usuarios que sirves. Un VPS de $26/mes sirve a 5,000 usuarios con cero tarifas por token. Con 50,000 usuarios, cinco instancias de VPS a $130/mes en total reemplazan lo que serían $33,750/mes en llamadas de API.

Fine-tuning (con Ertas, $14.50/mes) hace que el modelo local sea suficientemente bueno para el 95-98% de las solicitudes. El enrutamiento inteligente maneja el resto con un fallback a API. El resultado es una arquitectura de IA donde cada nuevo usuario es margen puro, igual que SaaS tradicional.

No necesitas esperar hasta que tu factura de IA sea dolorosa. El mejor momento para implementar la arquitectura de costo fijo es antes de escalar — cuando la migración es simple y las apuestas son bajas. Construye la arquitectura ahora. Escálala después. Quédate con los ingresos.

---

Lectura adicional

• Costos de modelos de IA para desarrolladores indie en 2026 — Un desglose completo de lo que realmente cuesta la IA para desarrolladores indie.
• IA auto-hospedada para apps indie — Por qué auto-hospedar inferencia de IA es la mayor palanca de margen.
• Costos de funcionalidades de IA en SaaS a escala — Cómo se comportan los costos de funcionalidades de IA a medida que tu SaaS crece.