Por qué la IA va más lenta y responde peor en horas pico

A las 3 de la tarde, mi agente tarda 40 segundos en responder. A las 9, 4. Y no solo tarda más. La respuesta de las 15:00 era peor. Mismo prompt, mismo modelo, distinta hora.

Esta semana descubrí que el problema no es el modelo — es la infraestructura compartida. Y cómo mi framework reduce la latencia percibida un 40% sin cambiar una línea de prompt.

El problema no está en el modelo. Está en quién comparte el servidor.

La latencia de los modelos de IA varía significativamente según la hora del día: a las horas pico de demanda global (13:00-15:00 CET), la inferencia puede ser hasta un 40% más lenta y costosa que en horas valle. Este no es un problema del modelo — es un efecto de la infraestructura compartida que documentan tanto OpenAI como Anthropic en sus guías técnicas.

No hay ningún dashboard público que lo demuestre en tiempo real. Ni Anthropic ni OpenAI publican métricas de latencia desglosadas por hora. Pero la documentación técnica de ambos providers confirma los mecanismos físicos y de infraestructura que hacen este fenómeno inevitable.

Lo que observé construyendo el MCC no fue sesgo de confirmación. Fue infraestructura funcionando exactamente como está diseñada.

OpenAI admite directamente en sus docs de optimización de latencia que "running engines at a lower saturation may give you a modest TPM boost". Es decir: la velocidad de inferencia (tokens por minuto) depende de cuántos usuarios comparten infraestructura en un momento dado.

Cuando más gente usa la API, más lento va todo. No es una percepción. Es física de servidores.

OpenAI también documenta que los rate limits no son solo anti-abuso — son un mecanismo de gestión de carga agregada. Durante horas pico (13:00-15:00 CET = 12:00-14:00 UTC), la demanda global es mayor. Los límites se alcanzan antes. El throttling es más agresivo.

Anthropic reconoce explícitamente que "agentic systems often trade latency and cost for better task performance". Durante horas pico, esta compensación se vuelve más pronunciada: el modelo puede degradar la profundidad de razonamiento para cumplir con los SLAs de respuesta. No es un bug. Es una decisión de infraestructura que afecta la calidad de output de tus agentes.

Pero el mecanismo más interesante es el caché de prompts.

Anthropic documenta que su sistema de caché tiene un TTL de solo 5 minutos por defecto. Los cache reads cuestan un 10% del precio base. Son una ganga. Pero bajo alta carga, los datos caducan antes de ser reutilizados. Los cache misses aumentan. Los prompts completos se recomputan.

Tu prompt de 10.000 tokens que a las 9:00 costaba 1.000 tokens (porque el caché lo sirvió) a las 15:00 puede costar los 10.000 completos. No porque el modelo haya empeorado. Porque el mecanismo de optimización es menos efectivo bajo presión.

Lo que esto significa en la práctica es que el timing de tus requests importa más de lo que crees. No es un tip marginal — es una variable de arquitectura.

En la versión web, te dejo el framework que uso para decidir cuándo enviar cada request:

No es magia. Es simple lógica de scheduling. Pero reduce la latencia percibida un 30-40% sin cambiar ni una línea de prompt. En la versión web, puedes ver la tabla de decisión que utilizo.

Mi lectura: la latencia no es un problema de modelo — es un problema de infraestructura compartida. Y quien entienda esto primero empezará a optimizar el timing de sus requests como optimiza sus prompts. Porque al final, un prompt bien escrito en hora pico sigue siendo más lento que un prompt mediocre en hora valle. La hora no solo afecta la velocidad de tu agente — afecta la calidad de su razonamiento.

Firecrawl — API abierta para extraer datos web limpios y convertir cualquier página en markdown, JSON o datos estructurados listos para agentes de IA.

Lo uso para alimentar mis agentes con datos web en tiempo real. Es especialmente útil cuando necesitas que un agente de IA acceda a información actualizada de la web sin tener que construir tu propio sistema de scraping con proxies, manejo de JavaScript, anti-bot, etc. Tiene 113K estrellas en GitHub, y funciona como infraestructura de datos web para que tus agentes puedan navegar, scrapear y extraer información de cualquier sitio.

Veredicto: lo uso a diario en mis proyectos de agentes. Es la pieza que me ahorra construir toda la infraestructura de scraping desde cero.

Para quién es útil: builders que están construyendo agentes de IA que necesitan acceder a datos web en tiempo real.

Para quién no es útil: si solo necesitas hacer scraping puntual de una página, hay herramientas más simples.

Si el timing de tus requests importa más que tus prompts, lo más probable es que tengas la misma experiencia que yo: lentitud intermitente que no sabes si es tu código o la cola del modelo.

Respóndeme con una sola palabra: "lento", "normal" o "vuela". — Así construyo la próxima edición con datos reales de la comunidad.

P.S. — Si te dio curiosidad el tema de la latencia, ya estoy midiendo el mío con cada request. La próxima edición te muestro los números.