Su agente es lento, y quizá no sea culpa del modelo. Los agentes ponen una carga nueva en la ruta del dato

Cuando un agente parece lento, los equipos suelen culpar al modelo y salir a buscar uno más rápido. Muchas veces el modelo es un tercio del problema. El resto está en el camino entre el agente y los datos que necesita: búsquedas vectoriales, consultas a bases de datos, llamadas a API, cada una repetida varias veces por tarea. Google lo mencionó casi de pasada en su anuncio de infraestructura del 5 de octubre, y merece más atención que las especificaciones de las instancias que lo acompañaban.

Qué dijo Google

En el artículo de Google Cloud Modernize, firmado por Souvik Choudhury y Tom Nikl, Google escribió que, con el auge de los agentes de IA en tiempo real que consultan sistemas de backend, las cargas exigen cada vez más infraestructura de alto rendimiento que elimine los cuellos de botella de entrada y salida. Para ese tráfico presentó dos familias de máquinas con mucho almacenamiento local: Z4D, ya en disponibilidad general, con hasta 84.000 GiB de SSD NVMe local y red de 400 Gbps, y Z4M, en vista previa, con hasta 168.000 GiB de NVMe local, 400 Gbps y soporte de RDMA. El objetivo declarado es reducir esperas y evitar tiempos de espera agotados cuando los agentes consultan bases vectoriales, bases operativas y pipelines de datos.

No hacen falta esas máquinas para aprovechar la lección. Los agentes generan un patrón de acceso distinto de aquel para el que se diseñaron sus plataformas de datos.

Anatomía de una tarea de un agente

1. El modelo planifica los pasos
2. Búsqueda vectorial de contexto
3. Consulta a la base operativa
4. El modelo razona sobre los resultados
5. Llamada a una API para actuar o verificar
6. El modelo redacta la respuesta

Tiempo de modeloTiempo en la ruta del dato

Una persona que usa una aplicación hace una consulta, lee el resultado y decide el siguiente paso. Un agente puede hacer decenas de lecturas para terminar una tarea, muchas en paralelo, sin pausas entre ellas. De ahí salen tres efectos:

• La latencia se acumula. Seis pasos en secuencia a 300 milisegundos cada uno suman casi dos segundos antes de contar el tiempo de modelo. Un paso que es lento el 1% de las veces vuelve lenta la tarea completa con mucha más frecuencia, porque cada tarea atraviesa muchos pasos.
• La concurrencia se multiplica. Mil empleados con un agente cada uno pueden generar la carga de consultas de una base de usuarios mucho mayor. Los pools de conexiones, la capacidad de lectura y los límites de peticiones pensados para tráfico humano son lo primero que se agota.
• Un tiempo agotado se convierte en una respuesta peor. Cuando una búsqueda no responde a tiempo, muchos agentes no fallan; siguen con menos contexto y responden igual. Un problema en la ruta del dato aparece como un problema de calidad.

El precio de cada salto entre regiones

La geografía pesa. En España, Google Cloud tiene región en Madrid, pero no todos los modelos ni los servicios de agentes están disponibles en cada región europea; si la custodia exige que los datos se queden en la UE y el modelo responde desde otra región, cada paso de cada tarea paga esa distancia. En Latinoamérica el problema suele ser mayor: con regiones en São Paulo, Santiago o Querétaro para los datos y modelos servidos a menudo desde Estados Unidos, una tarea de diez pasos puede sumar más de un segundo solo de ida y vuelta. Cuando la custodia obliga a mantener los datos cerca, acerque también el índice, las cachés y el estado del agente, y reduzca el número de viajes por tarea.

Diseñe para el tráfico de agentes

Trace cada paso. Instrumente el agente para que cada llamada al modelo, búsqueda, consulta y API aparezca como un span con su propia latencia. Sin eso, optimizará el modelo mientras la base de datos espera. Defendimos lo mismo para la calidad en nuestro artículo sobre medir la búsqueda como un sistema propio.

Dé a los agentes su propio carril. Envíe las lecturas de los agentes a réplicas, cachés o almacenes de lectura, no a la base transaccional principal. Dé a las identidades de los agentes límites y pools de conexiones propios, para que una flota ocupada no ralentice el proceso de pago de los clientes.

Presupueste la latencia por paso. Fije un objetivo por tipo de paso y alerte cuando se incumpla, como con un SLO. Decida qué hace el agente cuando un paso supera su presupuesto: reintentar, degradar o detenerse y decirlo. Nunca seguir en silencio con contexto incompleto.

Trate el estado del agente como dato caliente. La memoria y el estado de sesión se leen en cada turno. Como explicamos en nuestra guía sobre la memoria de agentes como almacenamiento de datos, ese almacén necesita gobernanza; también necesita planificación de rendimiento.

Qué hacer ahora

1. Trace un agente en producción de principio a fin y compare tiempo de modelo con tiempo en la ruta del dato.
2. Separe las lecturas de agentes del tráfico transaccional con réplicas, cachés o almacenes de lectura.
3. Dé a las identidades de agentes límites y pools propios.
4. Cuente los saltos entre regiones por tarea y acerque lo que la custodia ya obliga a mantener cerca.
5. Defina el comportamiento ante tiempos agotados para que la falta de contexto produzca un fallo explícito, no una respuesta peor.
6. Compruebe la disponibilidad regional antes de planificar con instancias nuevas como Z4M, que está en vista previa.

En resumen

Seguirán llegando modelos más rápidos, y no arreglarán un agente que espera a una base de datos saturada. Trate la ruta del dato como parte de la arquitectura del agente: mídala paso a paso, dé al tráfico de agentes su propio carril y haga visibles los tiempos agotados en lugar de dejar que rebajen en silencio la calidad de las respuestas.