Agentes de IA rompen el object storage: el nuevo cuello de botella

El nuevo cuello de botella de la IA ya no son los GPUs: es el almacenamiento

Las empresas llevan 18 meses invirtiendo agresivamente en GPUs, modelos y tooling para agentes de IA. Ahora, al pasar de la experimentación a producción, el rendimiento cae por razones inesperadas. Los GPUs ya no están hambrientos de cómputo: están hambrientos de datos. El problema está en la capa de almacenamiento que mueve objetos pequeños a alta concurrencia desde agentes y pipelines RAG, no en los clústeres que entrenan modelos.

F5, junto a un fabricante global de electrónica en Asia Pacífico y un cliente de servicios financieros, documenta en producción el mismo patrón: el tráfico de agentes rompe las premisas con que se dimensionó el object storage original. La pregunta para cualquier founder que ya opera agentes en producción dejó de ser «qué modelo contratar» y pasó a ser «qué pasa cuando 10.000 agentes piden objetos pequeños al mismo tiempo».

Por qué el entrenamiento y los agentes son workloads opuestos

El entrenamiento lee objetos grandes de forma secuencial, desde un clúster de GPUs conocido, con un único job a la vez. Un job agendado, con un working set preparado de antemano. Mark Menger, solutions architect en F5, lo resume así: «Training tells you what it needs before it starts, but agentic retrieval decides at runtime, so I don’t know what they’re going to ask for, when they’re going to ask, or how much they’re going to ask for».

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

La retrieval agéntica invierte casi todos esos atributos. Llegan volúmenes altos de GET pequeños sobre objetos chicos, mezclados con PUT, HEAD y LIST que jalan metadata. La población de clientes tiene alta cardinalidad porque un agente spawnea a otros agentes, y múltiples tenants comparten el mismo camino por defecto. Quien decide qué pedir es un sistema probabilístico que responde a inputs no controlados por la empresa, lo que retira al application tier como gatekeeper suficiente.

La concurrencia luego amplifica la latencia que carga cada request pequeña. Menger lo compara con la fila de un banco con varios cajeros: «With agents, you have many people in line, a limited number of tellers, and those tellers only operate at a certain pace. Latency stops being a manifestation of how performant the system is and becomes a manifestation of how big that queue is».

El tráfico de piloto no predice nada

El fan-out es lo que dispara el volumen: un prompt genera varias retrievals, esas retrievals disparan tool calls, y las tool calls spawnean más retrievals. El número potencial de agentes y subagentes, herramientas que invocan, sistemas empresariales que tocan y requests que cada uno puede hacer es «staggering», según el artículo original de VentureBeat.

«Half a dozen agents in a lab environment run without incident», dice Menger. «But unless you’re very deliberately thinking about what scale looks like on day two, you’re not going to see it in your pilot. Everything is fine until it’s not». El ratio entre requests y humanos deja de tener un valor estable, y los entornos de piloto pierden su poder predictivo. Lo que funciona con seis agentes en un laboratorio puede colapsar cuando el sistema crece.

Los agentes no aplican backpressure

Cuando un storage está bajo stress devuelve un 429 y pide al cliente reintentar más tarde, lo que funciona cuando un humano está detrás. Los agentes responden a esa señal reintentando automáticamente y en paralelo, sumando más carga al backend justo cuando señaló que no tiene capacidad. Si en lugar de un cliente re-pidiendo cada 10–20 segundos hay 1.000 o 10.000 reintentando a la vez, el sistema colapsa en el momento exacto en que pidió espacio.

Este riesgo cruza límites de la organización. Los agentes se conectan a los sistemas donde vive la data empresarial que necesitan, así que las tormentas de retry golpean infraestructura de la que depende el negocio entero. Sobre esa infraestructura compartida, una docena de clientes con requests sobredimensionadas llenan la cola mientras todos los demás tenants ven timeouts, 429s y 503s para tráfico que nunca se portó mal.

Así se ven estos fallos en producción

F5 documenta dos casos en producción. En un fabricante global de electrónica en Asia Pacífico, aplicaciones RAG y agentes jalan documentos, imágenes y otros inputs desde clusters de storage para soportar decisiones en la línea de manufactura. Dispositivos IoT empujan telemetría al cluster en paralelo, mientras los consumidores de IA leen pesadamente. La capa de entrega de datos de IA tiene que decidir qué flujo toma prioridad bajo carga.

F5 reprodujo ambos modos de falla en su laboratorio contra un cluster de object storage empresarial de 32 nodos. Con clientes S3 conectados directamente al cluster indujeron tráfico mal portado y observaron la cascada: empezó con uno o dos nodos y se propagó hasta dejar al servicio sin responder. «All of a sudden, the service just didn’t respond anymore. It went from ‘I’m struggling’ to nobody responding at all», según Menger.

Colocar un application delivery controller (en este caso BIG-IP de F5) entre los clientes y el cluster cambió ambos escenarios. El controlador interceptó el tráfico mal portado, los clientes bien portados no midieron impacto, y el cluster se mantuvo sano. Cuando el equipo sacó dos nodos, los clientes conectados directo vieron picos de error y caídas, mientras el controller enrutó tráfico alrededor de los nodos muertos. El tráfico a través del BIG-IP se mantuvo dentro de más o menos 6% del baseline directo, desmontando la objeción clásica de que agregar un punto de control entre cliente y storage frena todo.

F5 también comparte un caso de un cliente de servicios financieros global. Tenía que escalar infraestructura de IA con workloads en Kubernetes sobre object storage S3, con balanceo virtual compartido que generaba problemas de performance y confiabilidad. En lugar de invertir en más cómputo, enfocó el límite storage–compute. Desplegó ADC físico dedicado delante del object storage como punto de control centralizado para gestión de tráfico y optimización S3. Logró al menos cinco veces más operaciones de create, read y delete, con mejoras de más de un orden de magnitud en latencia de delete en algunos casos, sin regresión de performance frente al acceso directo a nodos, según el contenido patrocinado de F5 en TechCrunch.

Por qué más capacidad no soluciona un problema arquitectónico

Agregar ancho de banda no resuelve la latencia de cola bajo carga de objetos pequeños en ráfaga, ni separa workloads legítimos de loops descontrolados, ni impide que un tenant consuma más de lo que le corresponde. Fouad Chmainy, global solutions architect for AI and security en F5, lo pone en términos directos: «Capacity purchases leave those problems intact. More bandwidth does nothing for tail latency under bursty small-object load».

El controlador funciona porque entiende semántica de storage, no solo paquetes y puertos. Un controller que reconoce bucket, método y tenant puede enrutar a clusters o nodos específicos, aplicar límites y cuotas por tenant en un solo lugar, y throttlear por operación. Los LIST calls ilustran por qué importa esa granularidad: clientes refrescando su visión del cluster al mismo tiempo pueden reducir el rendimiento del cluster en cerca de 75%, según un partner tecnológico de F5.

Las llamadas LIST muestran dónde está la línea entre lo nuevo y un load balancer tradicional. «An application delivery controller doing bidirectional blast radius control pays close attention to the responsiveness and health of each node, proactively limits traffic to the unhealthy ones to give them breathing space, and sends traffic to the healthy ones», explica Menger.

El iceberg de la infraestructura de IA

Nirav Shah, SVP of product marketing en F5, compara la infraestructura moderna de IA con un iceberg: sobre el agua queda todo lo que los ejecutivos ven, LLMs, aplicaciones de IA, frameworks de orquestación, clusters de GPUs cada vez más caros, y recibe casi toda la atención y casi toda la inversión. Bajo el agua está la infraestructura que decide si esa inversión entrega valor en producción: storage, networking, gestión de tráfico, controles de seguridad y los sistemas que mueven datos entre storage y cómputo.

«Everybody is focused on the visible 10%», dice Shah. «But it’s the other 90% that determines whether those investments actually work». El síntoma parece un problema de cómputo, pero la causa raíz suele ser data starvation. Una spike de latencia, un bloqueo de throughput o un pico de tráfico que pasaría desapercibido en un entorno convencional tiene un impacto desproporcionado en performance de IA.

El mercado confirma la tendencia

La evidencia del lado de la demanda es contundente. IDC reporta que el 77% de las empresas ya tienen agentes de IA corriendo en producción, según un reciente recuento de CRN. Gartner proyecta que el mercado de servicios de IA alcance US$515 mil millones en revenue para 2029, liderado por iniciativas enfocadas en agentic AI. Y el mismo Gartner estima que el gasto global en IaaS optimizado para IA llegará a US$37.500 millones en 2026, aunque solo el 28% de los casos de uso de IA en infraestructura y operaciones cumple totalmente las expectativas de ROI y un 20% fracasa de plano, según una encuesta a 782 líderes de infraestructura y operaciones recogida por TechTarget.

Mientras tanto, del lado del almacenamiento, WekaIO presentó NeuralMesh 6 como respuesta al mismo problema. Su CPO Ajay Singh explica que los data centers que corren IA productiva hoy se construyeron «in a chaotic way, mixing and matching different platforms, chips and networking technologies from multiple vendors». NeuralMesh 6 apunta a extender la memoria de las GPUs asegurando que el key-value cache crítico viva en storage NVMe, salteando el overhead de recálculo que drena GPUs. WekaIO reportó 10 veces más token throughput y 10 veces más usuarios concurrentes en Oracle Cloud Infrastructure frente a DRAM estándar.

Qué significa esto para tu startup

Si ya operas agentes en producción o estás cerca de hacerlo, el almacenamiento dejó de ser commodity y pasó a ser variable de arquitectura. Comprar más GPUs sin mirar la capa de datos que las alimenta es optimizar el 10% visible del iceberg. Un agente que responde en 4 segundos en lugar de 1 segundo puede parecer aceptable en un piloto, pero multiplicado por 10.000 sesiones concurrentes se convierte en la razón por la que tu agente se siente «lento» sin que ningún KPI de cómputo lo explique.

Cuatro palancas concretas que ya puedes evaluar:

Mide tu fan-out antes de medir tu modelo. Calcula cuántos retrievals dispara un prompt promedio de tu agente, cuántas tool calls genera cada retrieval y cuántos subagentes pueden spawnearse en cascada. Si ese número es mayor a 5–10, tu pila de storage va a comportarse distinto entre piloto y producción.
Inyecta control al límite storage–compute, no después. Un ADC o capa de entrega que entienda S3 (bucket, método, tenant) entre tus clientes y el cluster de object storage te da blast radius control sin sacrificar throughput. El propio test de F5 mostró latencia dentro de ±6% frente al acceso directo mientras se cortaban nodos.
Diseña para backpressure humano y para retry storms de agentes. Los agentes reintentan en paralelo cuando reciben 429. Implementa circuit breakers por tenant, cuotas por operación y jitter exponencial entre reintentos. Lo barato en piloto es carísimo bajo carga de agentes: tratar a tu storage como si fuera una API pública.
Separa el dimensionamiento para batch del dimensionamiento para retrieval agéntica. El cluster que sirve tu pipeline de entrenamiento no puede dimensionar también el tráfico impredecible de tus agentes. Considera tiers de storage diferenciados y un control layer compartido que decida qué priorizar bajo carga.

El mensaje del artículo de VentureBeat es directo: «Your ability to spend money does not necessarily equate to your ability to generate a well-engineered solution». Para founders hispanohablantes construyendo agentes, esto se traduce en una regla operativa: gastar más en GPUs no compensa una arquitectura de datos que no fue pensada para que agentes la ataquen 10.000 veces por segundo con objetos pequeños.