Los limites de tasa de APIs de IA limitaran tu app movil a escala

Tu app es destacada en la App Store. Las descargas se disparan. 5,000 usuarios abren la app en la misma hora. Cada uno activa una funcion de IA. Tu backend dispara 5,000 llamadas a la API de OpenAI.

El Tier 1 de OpenAI permite 500 solicitudes por minuto. Acabas de excederlo por 10x. La API devuelve HTTP 429 (Too Many Requests). Tus usuarios ven mensajes de error o spinners de carga que nunca se resuelven.

Esto no es hipotetico. Es el resultado predecible de combinar patrones de distribucion de apps moviles con limites de tasa de API disenados para uso controlado y empresarial.

Limites de tasa por proveedor

OpenAI

Nivel	Requisito	RPM	TPM
Gratuito	Clave API	3	40,000
Tier 1	Pago de $5	500	30,000-200,000
Tier 2	$50+ gastados, 7+ dias	5,000	450,000-2,000,000
Tier 3	$100+ gastados, 7+ dias	5,000	800,000-4,000,000
Tier 4	$250+ gastados, 14+ dias	10,000	2,000,000-10,000,000
Tier 5	$1,000+ gastados, 30+ dias	30,000	10,000,000-150,000,000

Empiezas en Tier 1 (500 RPM). Llegar a Tier 5 requiere $1,000 en gasto acumulado y 30 dias de historial de cuenta. No hay forma de avanzar mas rapido.

Anthropic

Nivel	Requisito	RPM	TPM
Build	Por defecto	1,000	80,000
Scale	Tras revision	4,000	400,000

Anthropic requiere una actualizacion manual de nivel. Aplicas, ellos revisan, ellos deciden. No hay escalado automatico.

Google Gemini

Nivel	RPM	TPM
Gratuito	15	1,000,000
Pago por uso	2,000	4,000,000
Enterprise	Personalizado	Personalizado

El nivel gratuito de Gemini es extremadamente limitado (15 RPM). El pago por uso es mejor pero aun tiene limites duros.

Como las apps moviles alcanzan los limites de tasa

Picos de uso concurrente

Las apps moviles tienen patrones de uso en rafagas. Un destacado en la App Store, una publicacion viral en redes sociales o un lanzamiento de producto pueden impulsar miles de usuarios simultaneos por primera vez. A diferencia del SaaS web donde el uso crece gradualmente, las descargas de apps moviles pueden dispararse 10-100x en un solo dia.

Horas pico

El uso movil tiene pico entre las 7-9 PM hora local. Si tus usuarios estan concentrados en una zona horaria, el 60-70% del uso diario se comprime en una ventana de 3 horas. Tu promedio diario puede estar bien dentro de los limites, pero tu hora pico los excede.

Rafagas de engagement de funciones

Cuando un usuario abre una funcion de IA por primera vez, frecuentemente hace 5-10 solicitudes rapidas explorandola. Esta "rafaga de exploracion" significa que los nuevos usuarios generan 3-5x mas solicitudes que los usuarios en estado estable. Durante un pico de descargas, esto se acumula.

Las matematicas

1,000 MAU, 3 solicitudes/usuario/dia = 3,000 solicitudes/dia = ~125 solicitudes/hora promedio.

Pero comprime el 60% del uso en 3 horas pico: 1,800 solicitudes en 3 horas = 600 solicitudes/hora = 10 RPM. Comodo en Tier 1.

10,000 MAU con el mismo patron: 100 RPM durante pico. Todavia bien en Tier 1.

50,000 MAU: 500 RPM durante pico. En el limite de Tier 1. Cualquier pico lo excede.

Ahora agrega un destacado en App Store que impulsa 5,000 descargas en una hora, cada una haciendo 3 solicitudes de exploracion: 15,000 solicitudes adicionales en una hora = 250 RPM sobre tu linea base. Necesitas Tier 2 minimo, que requiere $50 en gasto previo y 7 dias de historial de cuenta.

Que pasa cuando alcanzas el limite

Respuestas HTTP 429

La API devuelve un codigo de estado 429 con un header retry-after. Tu app no recibe respuesta de IA. Sin manejo de errores apropiado, el usuario ve un crash, una respuesta vacia o un estado de carga infinito.

Backoff exponencial

La estrategia estandar de reintentos es backoff exponencial: espera 1 segundo, reintenta, espera 2 segundos, reintenta, espera 4 segundos, reintenta. Esto agrega latencia sobre las ya lentas llamadas a la API.

Para un usuario esperando 1-2 segundos por una respuesta de IA, agregar 1-4 segundos de reintentos con backoff significa 3-6 segundos totales. La mayoria de usuarios se rinden.

Congestion de cola

Si implementas una cola del lado del servidor para solicitudes con limite de tasa, la cola crece durante los picos. Un pico de 10 minutos al doble de tu limite de tasa crea un backlog que toma 10 minutos en limpiar. Los usuarios al final de la cola esperan 10+ minutos por una respuesta.

Experiencia degradada para todos los usuarios

Los limites de tasa son por organizacion, no por usuario. Cuando un pico de uso activa el throttling, todos los usuarios de tu app se ven afectados. El usuario que ha estado usando la funcion diariamente por meses recibe el mismo error 429 que el nuevo usuario que acaba de descargar.

Estrategias de mitigacion

Throttling de solicitudes

Implementa limitacion de tasa del lado del cliente. Limita solicitudes por usuario por minuto. Esto protege contra abuso individual pero no resuelve el problema de usuarios concurrentes.

Cola del lado del servidor

Enruta todas las solicitudes de IA a traves de tu propio servidor. El servidor gestiona una cola y despacha a la API de IA dentro de los limites de tasa. Esto suaviza los picos pero agrega latencia y costos de infraestructura de servidor.

Multiples claves de API

Distribuye solicitudes entre multiples claves de API o cuentas de proveedor. Esto multiplica tu limite de tasa efectivo pero viola los Terminos de Servicio de la mayoria de proveedores si se detecta.

Cadena de respaldo de modelos

Si tu proveedor principal tiene limite de tasa, recurre a un proveedor secundario. OpenAI con limite? Enruta a Gemini. Esto agrega complejidad y requiere mantener multiples integraciones.

Caching

Para solicitudes identicas o similares, cachea respuestas. Esto reduce llamadas a la API pero solo ayuda si los usuarios preguntan cosas similares. Las entradas unicas de usuario (la mayoria de interacciones de chat) no se pueden cachear.

La solucion estructural

Los limites de tasa existen porque los proveedores en la nube comparten capacidad finita de GPU entre todos los clientes. Mas usuarios en la plataforma significa limites mas ajustados para todos.

La inferencia en el dispositivo no tiene limites de tasa. El "servidor" es el telefono del usuario. Cada usuario tiene su propia capacidad de inferencia. 1,000 usuarios concurrentes significa 1,000 instancias de inferencia paralelas, cada una ejecutandose independientemente.

Factor	API en la nube	En el dispositivo
Limite de tasa	500-30,000 RPM (compartido)	Ninguno (por dispositivo)
Usuarios concurrentes	Limitado por nivel del proveedor	Ilimitado
Manejo de picos	Limitado	Sin cambio
Infraestructura necesaria	Servidor de cola + logica de reintentos	Ninguna
Confiabilidad	Depende del proveedor	Depende del dispositivo

El modelo de escalado es fundamentalmente diferente. Las APIs en la nube comparten un pool. El dispositivo le da a cada usuario su propio pool.

Planificando para escala

Si estas construyendo con APIs en la nube hoy:

Conoce tu nivel. Verifica tus limites de tasa actuales y que tan cerca estas de ellos.
Monitorea tasas de 429. Rastrea con que frecuencia tus usuarios alcanzan limites de tasa. Si es mas del 0.5%, tienes un problema.
Estima tu techo. A que MAU tu RPM de hora pico excede tu limite de nivel? Ese es tu precipicio de escalado.
Construye el respaldo. Cola, reintentos y degradacion elegante son requisitos basicos para apps en produccion.
Planifica la salida. La inferencia en el dispositivo es la respuesta a largo plazo. Fine-tunea un modelo con tus datos de dominio con una plataforma como Ertas, exporta GGUF y despliega en dispositivos de usuarios. Sin limites de tasa, sin infraestructura compartida, sin precipicios de escalado.