El titular de 18x oculta el número que realmente importa
Vercel publicó una mejora de latencia de enrutamiento: 62ms p50 reducido a 3.4ms p50. Cada titular de referencia citó esa cifra de 18x. Es el número equivocado en el que enfocarse.
Para sistemas donde estás encadenando cuatro a seis llamadas de herramientas síncronas—agentes consultando APIs, verificando webhooks, invocando servicios externos en secuencia—la mediana no te envía. La cola sí. Un p50 de 62ms generalmente significa un p99 de 200ms. Un p50 de 3.4ms significa algo más cercano a 18–22ms p99. Esa es la diferencia entre factible e imposible.
Aquí está por qué las medianas mienten para cargas de trabajo de agentes: una llamada lenta en una cadena rompe toda la secuencia. Si tienes seis invocaciones de herramientas y cada una tiene un p99 de 200ms, no estás mirando 6 × 200ms en tiempo de reloj de pared—estás mirando algo más cercano a 1.2 segundos a nivel de cadena, con el p99 de la suma siendo la suma de los p99s cuando son independientes. Tu presupuesto de SLA podría ser 1.5 segundos. Una décima parte de tus llamadas lo violaría antes de que enviaras una sola característica. La varianza de enrutamiento regional era tu bloqueador de SLA, no la calidad del modelo o el rendimiento.
La victoria de Vercel colapsa ese piso de varianza. El colapso de varianza es el titular que importa.
Cómo las réplicas de DNS regionales intercambian consistencia por divergencia con la que puedes vivir
Vercel se movió de una tabla de enrutamiento centralizada a réplicas de DNS por región. Ese es un intercambio de consistencia explícito: consistencia regional eventual (propagación en el rango de segundos) en lugar de consistencia global fuerte.
Esta es la forma correcta para agentes. Aquí está por qué: los agentes que hacen llamadas de herramientas toleran entradas de DNS que están obsoletas por segundos. No toleran solicitudes de DNS que toman 62ms p99. Una tabla de enrutamiento que está 5 segundos atrás en todas las regiones pero responde en 3ms es estrictamente mejor que una que es perfectamente consistente pero te hace esperar 62ms p99 por esa garantía de consistencia.
Cloudflare incorporó este principio en toda su plataforma—anycast con consistencia eventual en más de 200 centros de datos. La ventana de consistencia es parte de la definición del servicio, no un detalle de implementación oculto. Vercel hizo ese intercambio explícito. En términos del teorema CAP, eligieron disponibilidad y tolerancia de partición sobre consistencia, pero cuantificaron la ventana de consistencia para que sepas en qué estás ejecutando.
La mayoría de las plataformas ocultan esta decisión completamente. No sabes si tu enrutamiento es eventualmente consistente en milisegundos o segundos. Ciertamente no sabes la ventana de propagación. Para agentes, esa opacidad es un arma de fuego—terminas ajustando reintentos y tiempos de espera a ciegas.
Dónde tu cadena de agentes de 6 llamadas realmente gasta su tiempo de reloj de pared
Recorre una cadena de agentes concreta: el modelo toma una decisión de llamar a la Herramienta A. Esa decisión ocurre en el tiempo T=0. Aquí está dónde va el tiempo:
- T+0–5ms: Resolución de DNS para el punto final de la Herramienta A. Solía ser 10–60ms p99 dependiendo de tu región y si DNS estaba en caché.
- T+5–15ms: Protocolo de enlace TLS (la sesión en caché ayuda, pero los protocolos de enlace de inicio en frío son reales).
- T+15–85ms: La Herramienta A se ejecuta (llamada a la API de Stripe, consulta de GitHub, webhook de Slack). Esto es externo y no puedes optimizarlo.
- T+85–90ms: Respuesta recibida y analizada.
- T+90–100ms: Razonamiento del agente sobre el resultado, decisión de llamar a la Herramienta B.
- Repetir para las Herramientas B, C, D, E, F.
Suma esto en el enrutamiento antiguo: 200ms llamada de modelo + 6 × (40ms DNS + 10ms TLS + 70ms ejecución de herramienta) = 200 + 6 × 120 = 920ms mejor caso. ¿P99? Estás mirando 1.2–1.4 segundos fácilmente. Después del lanzamiento de esta semana, DNS es 3–4ms p99 en lugar de 40ms p99. Eso es 36ms por salto, multiplicado por seis saltos, multiplicado por el número de llamadas que haces. Una única ejecución de agente podría ahorrar 200–400ms en latencia de cola.
Por qué async no te rescata: algunas llamadas de herramientas necesitan el resultado para razonar hacia adelante. Sí, puedes paralelizar llamadas independientes. Pero la mayoría de los patrones de agentes son secuenciales—cada resultado de herramienta informa la siguiente opción. Estás atrapado con tiempo de reloj de pared.
Los modos de fallo que esto arregla—y los tres que no
La varianza de latencia de enrutamiento es una fuente de incumplimiento de SLA. Las réplicas de DNS regionales colapsan esa fuente. Aquí está lo que no arreglan:
Arreglado: Jitter de enrutamiento de inicio en frío, amplificación de llamadas de herramientas entre regiones, cola de generación de sandbox. Si tu búsqueda de DNS era el piso de varianza, estás hecho aquí.
No arreglado: Límites de velocidad de API ascendente y varianza de retroceso de 429. Stripe te limita la velocidad; su retroceso es exponencial e impredecible. Eso está ascendente de la capa de enrutamiento.
No arreglado: Encolamiento del proveedor de modelos bajo carga. Anthropic y OpenAI tienen colas de solicitudes. Cuando están bajo carga, tu llamada de modelo agrega latencia. El enrutamiento no toca esto.
No arreglado: Amplificación de tormenta de reintentos cuando una herramienta 503s a mitad de la cadena. Si la Herramienta D falla, tu agente típicamente reintenta. Si ese reintento también falla, cascadas. La velocidad de enrutamiento no previene cascadas; solo las hace más ajustadas y más visibles.
La lección: instrumenta latencia p99 por salto, no por solicitud. Si DNS es ahora 3ms p99 y la latencia de la Herramienta D es todavía 200ms p99, sabes dónde vive tu próximo bloqueador de envío. La mayoría de los equipos miden p99 de extremo a extremo y se preguntan por qué los agentes son lentos. Mide los saltos.
Lo que cambiamos en nuestros despliegues después del lanzamiento
Apretamos tiempos de espera por herramienta de 2 segundos a 800ms. Cuando la jitter de enrutamiento era 60ms p99, acolchamos duro. Ahora que DNS es 3ms p99, podemos ser agresivos. Si una herramienta toma más de 800ms, es la herramienta, no la red. Falla rápido.
Eliminamos un cobertor de llamada paralela especulativa. Antes del lanzamiento, a veces estábamos haciendo llamadas redundantes a la misma herramienta (ambas limitadas por tiempo de espera, compitiendo por el primer resultado). La varianza de latencia hizo que ese cobertor se pagara por sí mismo. Después del lanzamiento, es solo desperdicio. Eliminamos el código.
Movimos la verificación de webhook de nuevo en línea en lugar de diferida. La verificación de webhook solía ser su propio paso asincrónico porque no podíamos permitirnos el golpe de latencia durante la invocación de herramientas. Ahora podemos. Máquina de estados más simple, menos errores.
Recalibramos presupuestos de SLA. Una cadena de agentes de seis llamadas bajo 1.5s p99 pasó de "esperanza y reintentos" a realmente alcanzable. Ahora nos comprometemos con ese SLA en contratos y estructuramos nuestra escalera de tiempo de espera de herramientas alrededor de él.
Mantuvimos el anclaje regional para herramientas con estado. Algunas llamadas de herramientas (escrituras de base de datos, capturas de pagos) necesitan golpear la misma región dos veces. Todavía explícitamente anclamos esas para evitar sorpresas de divergencia. Las réplicas regionales son eventualmente consistentes, no fuertemente consistentes. Para algunas cargas útiles, eso importa.
El principio de diseño: elige plataformas que expongan el intercambio
Aquí está lo que importa para agentes a escala: las plataformas que ocultan decisiones de consistencia son plataformas que no puedes instrumentar. No puedes ajustar lo que no puedes medir.
Cuando estés evaluando una plataforma para enrutamiento de agentes, haz tres preguntas:
- ¿Cuál es tu ventana de propagación de DNS? ¿Segundos? ¿Minutos?
- ¿Cuál es tu latencia p99 piso para una búsqueda de enrutamiento?
- ¿Es ese piso predecible, o jitter basado en región o carga?
La mayoría de los proveedores no responderán. Esa es la señal que necesitas pasar. Vercel publicó sus números; también lo hace Cloudflare. Si un proveedor no cuantifica su SLA de enrutamiento, está ocultando algo, y las cargas de trabajo de agentes lo encontrarán a las 2am.
Esto se mapea ascendente también. Las reglas de enrutamiento de Vercel AI Gateway exponen conmutación por error y equilibrio de carga explícitamente. Puedes ver el intercambio. Ese es el patrón a exigir de cada capa: enrutamiento de inferencia, enrutamiento de base de datos, despacho de webhook. Los agentes exponen latencia oculta; las plataformas que publican sus presupuestos de varianza te enviarán más rápido que las plataformas que no lo hacen.
Extrae tus trazas y mide la brecha
Extrae las trazas de agentes de la semana pasada. Grafica p99 menos p50 por salto de herramienta. Si esa brecha es más ancha que tu latencia de llamada de modelo (generalmente 100–150ms), la varianza de enrutamiento es tu próximo bloqueador de envío, no la calidad del modelo o la ventana de contexto. Arréglalo primero. La alineación y gobernanza siguen; la observabilidad viene primero.