Introducción
Un agente de código que revisa pull requests funciona impecable en staging: lee el diff, hace grep sobre el repositorio, corre la suite de tests, consulta el estado del pipeline y redacta un comentario en menos de veinte segundos. Lo desplegás a producción, y a la hora tres de la jornada el mismo agente tarda cuatro minutos en el paso de tests porque el nodo donde aterrizó está saturado por otro agente que disparó una compilación paralela. El modelo no cambió. El prompt no cambió. Lo que cambió fue el entorno de ejecución, y eso determinó si el SLA se sostuvo o se derrumbó.
Este escenario se repite en organizaciones que migran de chatbots a agentes autónomos sin rediseñar su infraestructura. Los equipos de plataforma configuran autoscaling horizontal, load balancers round-robin y capacidad GPU calculada sobre tráfico promedio. Funciona para un LLM que responde una pregunta. Falla estrepitosamente cuando un workflow de cinco a quince pasos encadena inferencias secuenciales, llamadas a herramientas externas y esperas bloqueantes sobre sistemas de terceros. El problema no es el modelo: es que la infraestructura fue diseñada para un patrón de carga que el agente no produce.
Qué ocurrió
Los agentes de IA introducen un modelo de ejecución radicalmente distinto al de una aplicación conversacional. Un chatbot procesa una solicitud, genera una secuencia de tokens y devuelve la respuesta: un ciclo de inferencia aislado, con latencia acotada al tiempo de generación. Un agente opera en un bucle multi-turno (agentic loop) donde cada iteración combina un paso de razonamiento con una interacción externa: consultar un log de deploys, ejecutar una query contra el monitoring, correr un diagnóstico sobre el connection pool de la base de datos. El resultado de cada herramienta se inyecta en el contexto del modelo antes de la siguiente inferencia.
La consecuencia estructural es que la cadena es inherentemente secuencial. Si la consulta al Prometheus cluster tarda 2,3 segundos, el modelo no puede iniciar el siguiente paso de razonamiento hasta recibir ese resultado. Un workflow de ocho pasos donde tres involucran I/O externo acumula 6-9 segundos de espera pura, independientemente de que la generación de tokens tome 40 ms por paso. La latencia end-to-end no es la suma de las latencias de inferencia: es la suma de las latencias de inferencia más las latencias de cada herramienta, más las colas de scheduling en los nodos donde se ejecutan.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
El impacto más inmediato es sobre el p99 de latencia. Cuando el aprovisionamiento se dimensiona sobre el promedio de utilización GPU, los picos transitorios de los workflows agénticos encuentran capacidad insuficiente. Los equipos reportan que el p50 se mantiene aceptable (2-4 segundos por paso) mientras el p99 escala a 30-90 segundos porque los requests se encolan detrás de otros agentes que ocupan los mismos recursos. Para un servicio con SLA de 5 segundos por interacción, esto representa violaciones del 15-25% de las solicitudes en horas pico.
El segundo impacto es económico. Los servicios de inferencia gestionados (SageMaker, Vertex AI, Azure ML) facturan por tiempo de GPU activo. Un patrón de carga tipo heartbeat —flat durante 10-30 segundos mientras el agente espera un resultado externo, spike de 200-500 ms cuando vuelve a inferir— genera una utilización GPU efectiva del 12-20% sobre capacidad aprovisionada para el 100%. El equipo paga por GPUs ociosas durante las fases de espera y por capacidad extra durante los picos, sin que ninguna de las dos se aproveche de forma continua.
Desde la perspectiva de seguridad y gobernanza, los workflows multi-turno amplían la superficie de ataque. Cada llamada a una herramienta externa (filesystem, API interna, base de datos) representa un punto donde el agente ejecuta acciones con credenciales delegadas. La trazabilidad de qué hizo cada agente, en qué nodo, con qué permisos y en qué orden, exige instrumentación que la mayoría de stacks de inferencia no provide out of the box.
Detalles técnicos
El patrón de demanda agéntica se distingue del tráfico conversacional por tres características medibles:
Secuencialidad estricta. A diferencia de requests independientes que un load balancer distribuye en paralelo, cada paso del agentic loop depende del resultado anterior. Un orchestrator como LangGraph, CrewAI o un implementation custom con state machines debe serializar las invocaciones. Si el nodo executor tiene cola, esa cola se propaga a toda la cadena.
Burstiness irregular. La utilización GPU no sigue una curva de demanda creciente. Se observa un patrón de pulso: flatline durante la espera de I/O (query a Postgres, llamada a API REST, compilación en CI), spike breve durante la generación de tokens, flatline otra vez. En Grafana, un dashboard de DCGM_FI_DEV_GPU_UTIL muestra esta firma como una línea discontinua con duty cycle bajo, no como una meseta.
Contexto creciente. Cada herramienta devuelve tokens que se agregan al contexto. Un workflow de 10 pasos que consulta logs, métricas y código puede acumular 40.000-80.000 tokens en el contexto del modelo. La memoria KV-cache crece proporcionalmente, y los nodos con 80 GB de VRAM que soportan 4-6 requests concurrentes en modo chatbot pueden soportar solo 1-2 en modo agente con contexto largo.
Los mecanismos clásicos de escalado reaccionan tarde. Un HPA de Kubernetes con métrica avg_gpu_utilization y target del 70% detecta el spike cuando ya pasó. El pod tarda 45-120 segundos en provisionarse (image pull, warm-up del modelo, carga de pesos). Para un workflow de 15 segundos de duración, ese escalado llega demasiado tarde.
Qué deberían hacer los administradores y equipos técnicos
Instrumentá la cadena completa, no solo la inferencia. Agregá tracing distribuido (OpenTelemetry con spans por paso del agentic loop) para visualizar dónde se acumula latencia. Los métricas clave: tiempo de espera en cola por nodo, tiempo de ejecución de cada herramienta, tamaño de contexto por paso, y GPU utilization efectiva vs. aprovisionada. Sin visibilidad por paso, no podés identificar si el problema es el modelo, la herramienta externa o el scheduler.
Separá los pools de recursos por fase del workflow. Los pasos de inferencia (GPU-bound) y los pasos de I/O (CPU-bound, network-bound) no deberían compartir el mismo nodo ni el mismo autoscaler. En Kubernetes, usá node pools etiquetados con workload=agent-inference y workload=agent-tools, con taints y tolerations específicos. Para el pool de inferencia, considerá warm pools de instancias GPU o modelos como Karpenter (AWS) / Cluster Autoscaler con scaleDownDelayAfterAdd configurado en 300s para evitar thrashing.
Ajustá el autoscaling al patrón real, no al promedio. Reemplazá la métrica de utilización promedio por una métrica de cola: número de requests esperando ejecución en el queue del orchestrator. Un HPA custom con métrica agent_queue_depth y target de 0-1 requests en espera escala antes de que el p99 se degrade. En GKE, los autoscalers de GPU con min_ready_seconds permiten tener instancias en warm state sin costo de facturación completa.
Implementá timeouts y circuit breakers por paso. Un workflow donde la consulta a la API de monitoring se cuelga 60 segundos bloquea toda la cadena. Configurá timeouts agresivos por herramienta (5-10 s para queries internas, 15-20 s para APIs externas) y circuit breakers que fail-fast si un servicio externo degrada. El agente debería poder continuar con un subconjunto de información o reportar parcialidad, no quedarse esperando indefinidamente.
Rediseñá el billing de GPU para carga bursty. Si usás instancias on-demand, el costo por workflow es impredecible. Evaluá modelos de reserva con overcommit (AWS Capacity Reservations + Spot para overflow), serverless GPU (Modal, RunPod, Replicate) que cobra por segundo activo, o autoescalado a escala de cero con cold-start amortizado por batching de workflows.
Conclusión
El modelo de un agente de IA resuelve el problema de razonamiento. La infraestructura resuelve el problema de ejecutar ese razonamiento bajo condiciones reales de carga compartida, recursos finitos y dependencias externas con latencia variable. Los equipos que tratan el despliegue de agentes como «otro microservicio más» con un deployment YAML estándar van a descubrir que el bottleneck no está en los tokens por segundo del modelo, sino en el nodo donde corrió la herramienta, en la cola del orchestrator y en el momento exacto en que el autoscaler decidió escalar. La infraestructura no es un detalle de implementación: es el factor que determina si el agente cumple su promesa o se convierte en una fuente de tickets de soporte.
Fuentes
- https://thenewstack.io/ai-agent-infrastructure-performance/
- https://lwn.net/