On-Device vs API en la Nube: Las Matemáticas Reales con 10K, 50K y 100K MAU

Tu funcionalidad de IA va perfecta en pruebas. Las respuestas son rápidas, el modelo es capaz, los costes son insignificantes. Entonces alcanzas 10K usuarios activos mensuales y llega la factura.

Este es el momento que separa las apps que escalan de las apps que se acaban reescribiendo en silencio. Según un informe de Forrester de 2026, el setenta por ciento de los CIOs cita la imprevisibilidad del coste de la IA como su principal barrera de adopción. Menlo Ventures encontró que el gasto medio mensual de las organizaciones en IA pasó de 63K$ en 2024 a 85,5K$ en 2025, un aumento del 36% en un solo año. Los márgenes brutos de Replit, según informes, oscilaron de +36% a -14% a medida que los costes de inferencia escalaban con el uso (Sacra).

La buena noticia: puedes modelar todo esto antes de que ocurra. Este artículo enseña las matemáticas.

El Panorama de Precios

Primero, establezcamos los números reales. Todos los precios son por 1 millón de tokens, a principios de 2026.

Los tokens de output cuestan significativamente más que los de input en cada proveedor. Esto importa porque la mayoría de las estimaciones de coste se centran en la longitud del input y subestiman la parte del output.

El Modelo de Coste: Suposiciones

Para hacerlo concreto, necesitamos una suposición de uso de referencia. Aquí tienes un modelo razonable para una app móvil con una funcionalidad de asistente de IA:

• 3 interacciones por usuario al día (conservador para una app de uso diario)
• 500 tokens de input por interacción (un system prompt corto más el mensaje del usuario)
• 500 tokens de output por interacción (una respuesta del tamaño de un párrafo)
• Usuarios activos mensuales en 10K, 50K y 100K

Eso nos da 30 interacciones por usuario al mes, y 1.000 tokens totales por interacción (divididos a partes iguales entre input y output).

Tokens totales por usuario al mes: 30.000 (15K input + 15K output).

Coste de las API en la Nube a Escala

Esto es lo que producen esas matemáticas en tres hitos de MAU.

10.000 MAU

50.000 MAU

100.000 MAU

Estas son estimaciones mínimas. No incluyen lógica de reintentos, sobrecarga de streaming, crecimiento del contexto a medida que las conversaciones se alargan, ni el coste de las llamadas a embeddings si estás corriendo RAG. El uso real de tokens suele ser entre 1,5 y 2 veces mayor que las estimaciones.

La Alternativa On-Device

La inferencia on-device ejecuta el modelo en el hardware del usuario. Una vez distribuido el modelo, cada inferencia te cuesta cero. Sin tarifas por token, sin llamadas a API, sin costes de egress.

Los dos componentes de coste que sí pagas son:

1. Fine-tuning (única vez): Entrenar un adaptador LoRA en un servicio de GPU en la nube cuesta aproximadamente 5$-50$ dependiendo del tamaño del dataset y del modelo base. Es un coste único por versión del modelo, no por usuario ni por inferencia.

2. Distribución del modelo (única vez por instalación): Estás enviando un fichero GGUF con tu app. Tamaños GGUF para modelos prácticos en móvil: Llama 3.2 1B con cuantización Q4_K_M ocupa 808MB; la variante 3B son 2.02GB. El egress de CDN para un fichero de 1GB a tarifas estándar son menos de 0,10$ por instalación. Para 10K usuarios, eso son aproximadamente 1.000$ totales de coste de distribución amortizados en el momento de la instalación, no mensualmente.

Coste mensual recurrente: 0$.

El Punto de Equilibrio

Usando GPT-4o-mini como referencia (una elección común para equipos preocupados por el coste):

El coste único de fine-tuning de 5$-50$ se recupera dentro del primer mes prácticamente con cualquier MAU por encima de unos pocos cientos de usuarios. El único coste real es el tiempo de ingeniería para la integración y la distribución inicial del modelo.

Los Costes Ocultos de las API en la Nube

La tabla de precios no es la historia completa. Las dependencias de API en la nube traen consigo un conjunto de costes que no aparecen en tu factura mensual.

Límites de Velocidad y Picos de Latencia

Cada gran proveedor impone límites de velocidad: tokens por minuto, peticiones por minuto y topes diarios. Están escalonados por nivel de cuenta y pueden requerir semanas de historial de uso para subir. Durante un pico (un momento viral, el lanzamiento de un producto, una funcionalidad que se vuelve tendencia), chocarás con los límites justo cuando más necesitas fiabilidad. Los errores de rate limit requieren lógica de reintentos en el cliente, lo que añade complejidad y puede convertirse en cascada en fallos visibles para el usuario.

La latencia también varía. Los endpoints de modelos en la nube son infraestructura compartida. Las latencias P99 pueden llegar a 5-10 segundos en periodos de carga punta. La inferencia on-device, por contraste, es determinista. Corre en hardware dedicado sin viaje de ida y vuelta por la red.

Vendor Lock-In y Riesgo de Deprecación

Las API de modelos no son contratos estables. OpenAI ha deprecado GPT-3, GPT-3.5 y múltiples endpoints de fine-tuning. Anthropic, Google y otros han seguido patrones similares. Cuando se depreca un modelo, tienes una ventana de migración, a menudo de 6-12 meses, para actualizar tus prompts, volver a probar y redesplegar. La ingeniería de prompts que funciona bien en GPT-4o-mini no siempre se transfiere directamente a un nuevo modelo.

Los modelos on-device no se deprecan según el calendario del proveedor. Tú controlas cuándo actualizas y puedes mantener el soporte de versiones antiguas de la app indefinidamente sin pagar por un endpoint de API que ya no controlas.

Dependencia de Red

Las apps móviles que requieren conexión activa a internet para cada funcionalidad de IA tienen una restricción dura. Los modelos on-device funcionan sin conexión. Para apps de toma de notas, herramientas de productividad, apps local-first o cualquier app dirigida a regiones con conectividad poco fiable, la capacidad offline es una ventaja competitiva real, no un mero lujo.

Privacidad y Residencia de Datos

Cada llamada a la API envía la entrada del usuario a un servidor de terceros. Para apps que manejan datos sensibles (salud, finanzas, legal, RR.HH.), esto crea una superficie de cumplimiento. La inferencia on-device mantiene los datos del usuario en el dispositivo. Nunca salen.

Cuándo Sí Tienen Sentido las API en la Nube

On-device no es la respuesta correcta para cada caso de uso. Sé honesto sobre estos escenarios:

Prototipado y desarrollo en fase temprana. Cuando tienes menos de unos cientos de MAU, la economía favorece a la nube. Aún estás validando la funcionalidad. Usa GPT-4o-mini o Gemini Flash, instrumenta tu uso de tokens con cuidado y revisa la arquitectura del modelo entre 1K y 5K MAU.

Tareas que requieren capacidad de modelo de frontera. Los modelos on-device en el rango de 1B-7B parámetros son capaces para resúmenes, clasificación, extracción, Q&A simple y generación de formato corto. No son adecuados para razonamiento multietapa complejo, generación de código en codebases grandes o tareas que se beneficien genuinamente de modelos de 100B+ parámetros. Si tu funcionalidad requiere razonamiento al nivel de GPT-4o, on-device no es un sustituto.

Herramientas B2B de bajo volumen. Si tienes 200 usuarios empresariales haciendo cada uno 10 interacciones por semana, tu factura de GPT-4o es de menos de 100$ al mes. La inversión de ingeniería para implementar on-device no merece la pena a ese volumen.

Tareas con requisitos que cambian rápido. Si tu system prompt cambia semanalmente y estás iterando rápido sobre el comportamiento del modelo, el bucle de iteración en la nube es mucho más rápido. Volver a hacer fine-tuning y redistribuir un modelo on-device toma más tiempo que empujar un nuevo system prompt.

Un Marco de Decisión Práctico

La decisión no es binaria. Una arquitectura híbrida común: usa on-device para las funcionalidades centrales (resúmenes, etiquetado, respuestas rápidas) y enruta peticiones específicas de alta complejidad a una API en la nube. Esto mantiene el 80-90% del volumen de inferencia on-device a coste cero por token, preservando el acceso a la capacidad de frontera para los casos límite.

El Camino de Ingeniería hacia On-Device

Históricamente, la barrera práctica para la IA on-device ha sido el toolchain. El fine-tuning requiere infraestructura de ML, exportar a GGUF requiere herramientas de conversión de modelos, e integrar la inferencia en una app móvil requiere bindings específicos de cada plataforma.

Aquí es donde encaja Ertas. La plataforma se encarga del fine-tuning (adaptadores LoRA sobre tu dataset), la cuantización y la exportación a GGUF en un solo pipeline. Tú aportas tus datos de entrenamiento y el caso de uso objetivo. Recibes un fichero GGUF listo para despliegue móvil, junto con guías de integración para iOS (vía bindings de llama.cpp) y Android.

El coste único de fine-tuning de 5$-50$ frente a una factura mensual de API que crece linealmente con cada usuario que adquieres: las matemáticas se resuelven solas rápidamente.

Conclusión

Con 10K MAU usando GPT-4o-mini, estás pagando 337$ al mes. Con 50K MAU son 1.687$. Con 100K MAU son 3.375$ al mes, y eso con un modelo barato y suposiciones de uso conservadoras. GPT-4o con 100K MAU son 56.250$ al mes.

La inferencia on-device cuesta 0$ tras una inversión única en fine-tuning de menos de 50$ y unos costes de distribución del modelo que se amortizan en el momento de la instalación.

El punto de equilibrio no está a meses vista. Para casi cualquier app por encima de unos pocos cientos de usuarios activos, la factura de la API supera el coste del fine-tuning dentro del primer ciclo de facturación tras el lanzamiento. La pregunta no es si on-device es más barato. La pregunta es cuándo lo construyes.

Ship AI that runs on your users' devices.

Early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.

View early bird pricingor join the waitlist →