El límite de 25 segundos de Vercel Edge, el cuello de botella de los agentes

Un equipo que construye agentes de IA sobre Next.js ha contado por qué dejó atrás el runtime Edge de Vercel y se pasó a Node.js. El motivo es concreto: el límite de 25 segundos de ejecución por petición se queda corto en cuanto el flujo deja de ser una llamada y una respuesta y pasa a encadenar razonamiento, consultas a base de datos y llamadas a APIs de terceros. El relato es de primera mano, no un anuncio de producto: es un equipo describiendo lo que le reventó en producción.

El reloj corre mientras el agente piensa

El síntoma fueron timeouts intermitentes. Al bucear en los logs, la causa era siempre la misma: la ejecución se cortaba antes de que el agente terminara. Con varias cadenas de razonamiento y servicios externos de por medio, esos 25 segundos se agotan. La salida que describen pasa por cambiar de runtime y declararlo en la propia ruta: export const runtime = 'nodejs' junto a export const maxDuration = 300, que da hasta cinco minutos de margen. Es un cambio de configuración, y según su experiencia es la diferencia entre una aplicación que falla cada tanto y una que aguanta.

Conviene poner esa cifra en su sitio. Los 25 segundos son los que maneja ese equipo, y el texto no trae mediciones propias ni comparativas de latencia entre ambos runtimes. Tampoco hay repositorio ni banco de pruebas detrás.

Desacoplar la inferencia del enrutado

El segundo movimiento es de arquitectura, no de flags. La aplicación Next.js queda como proxy ligero y sin estado que solo sostiene la conexión del usuario y emite el stream de respuesta; el pipeline del modelo se va a pods de workers con GPU dedicados. La capa de API deja de hacer trabajo pesado y el cómputo escala por su cuenta.

Queda el problema del estado. Los entornos serverless llevan mal las conexiones persistentes y bajo concurrencia alta acaban agotando los límites de TCP. Para esquivarlo tiraron de servicios sobre HTTP, Upstash Redis y QStash, y movieron ahí el estado de sesión y las colas de ejecución de herramientas. Con eso, dicen, el sistema sostiene cientos de streams concurrentes sin atascarse. La cifra es suya y no viene acompañada de gráficas.

El consejo que cierran es razonable y aplica más allá de Next.js: si vas a montar funciones con agentes en producción, diseña los límites de ejecución desde el principio en lugar de esperar a que revienten en producción. Lo que no hay es una receta única, porque el margen real depende del proveedor y del plan contratado, y el patrón de workers con GPU fuera del enrutado implica decidir dónde vive el cómputo y quién paga la factura. Queda por ver si más equipos publican sus números, porque hasta ahora lo que hay es un relato, no un benchmark.