AI智能体与RAG正压垮企业对象存储：事务性负载与批处理架构的根本冲突

模型训练是一个批处理问题，而智能体检索（agentic retrieval）则是一个事务性问题。遗憾的是，目前大多数企业正将事务性AI工作负载运行在为其批处理需求而配置和运维的对象存储上。随着AI智能体和RAG（检索增强生成）从试点环境走向生产环境，这种不匹配导致了大量生产故障。

与此同时，企业AI预算高度集中于GPU，而其底层存储层却受到远少得多的关注。然而，智能体从根本上改变了该存储的访问方式。AI智能体和RAG流水线持续发出高并发的小对象读取请求，而非训练任务所采用的、提前规划的大规模顺序读取。这使得对象存储直接处于每一次AI响应的路径之中：存储延迟会延长用户等待答案的时间，而对并发连接数的限制则可能使系统在智能体活动规模扩大时无法保持响应能力。

F5公司技术联盟解决方案架构师Mark Menger表示：“训练开始前就已明确告知系统它需要什么，但智能体检索则在运行时才决定——因此我无法预知它们将请求什么、何时请求，以及请求多少。没有人会像为批处理那样，为这种场景去规划系统容量。”

智能体颠覆了传统的访问模式

训练作业从一个已知的GPU集群按顺序读取大型对象，这些对象的工作集已在事前完成预置，且系统一次仅运行一个作业。而智能体检索则几乎逆转了上述所有属性：流量表现为大量小型对象GET请求，并混杂着PUT、HEAD和LIST调用以拉取元数据；客户端群体具有高基数特征，因为智能体会派生出其他智能体，且多个租户默认共享同一访问路径；决定请求内容的客户端本身是一个概率性系统，其响应取决于企业无法控制的输入，从而使得应用层不再足以作为抵达数据前的有效把关者。

随后，并发性进一步放大了每个小型请求所携带的延迟。Menger将其类比为一家繁忙的银行大厅。

他表示：“如果大厅里空无一人，仅有一名客户前往一名柜员办理一笔非常大的交易，系统仍能保持响应能力。但在智能体场景下，你面对的是排起长队的众多客户、数量有限的柜员，且每位柜员仅能以特定速度处理业务。此时延迟不再体现系统的性能表现，而转为反映队列长度的指标。”

试点流量无法预测任何情况

扇出（fan-out）驱动着请求量激增：一条提示（prompt）触发多次检索，这些检索又触发工具调用，而工具调用又催生更多检索，因此请求与人类用户之间的比例并无稳定值，试点环境因而丧失其预测能力。潜在的智能体及子智能体数量、所有这些智能体调用的工具数量、这些工具所调用的企业系统数量，以及它们可能发起的请求数量，均令人震惊。

Menger表示：“在实验室环境中，六七个智能体可毫无异常地运行。但除非你从第二天起就刻意思考规模化后的形态，否则你在试点中根本看不到它。一切看似正常，直到突然崩溃——而一旦崩溃，情况就会非常糟糕。”

智能体不施加反压（backpressure）

当存储承受压力时，它返回HTTP 429状态码并要求客户端稍后重试；若请求背后是人类用户，该机制尚可奏效。但智能体收到该信号后会自动并行重试，反而在后端已明确表明自身无余力承载更多负载的时刻，进一步加重其负担。

Menger指出：“如果只有一位客户端礼貌地每隔10秒、15秒或20秒重试一次，那尚属可控。但如果你有1,000或10,000个客户端同时发起重试，你便会在系统明确告知自己急需喘息空间的那一刻，彻底压垮它。”

组织将智能体连接至承载企业所需数据的系统，因此重试风暴可能冲击企业赖以运转的关键基础设施。在这一共享基础设施之上，十几个客户端发出过大或加速的请求即可填满队列，而其他所有租户则会因原本从未失常的流量遭遇超时、429错误及503错误。

这些故障模式在生产环境中的具体表现

F5公司在亚太地区一家全球电子制造商处观察到此类模式：其RAG应用与智能体从存储集群中提取文档、图像及其他输入，以支持制造产线上的决策。物联网设备同时向这些集群推送遥测数据，而AI数据交付层必须在负载压力下判定哪类数据流应被优先处理。

F5公司在实验室中使用一个32节点的企业级对象存储集群复现了上述两种故障模式。团队将S3客户端直接连接至该集群，注入异常流量并观察其级联效应。

Menger表示：“起初仅有一两个节点出现异常，随后问题迅速蔓延开来。突然之间，整个服务完全停止响应——从‘勉强维持’直接恶化为‘彻底无响应’。”

在客户端与集群之间部署一款应用交付控制器（本例中为F5的BIG-IP），彻底改变了两种场景。该控制器拦截了异常流量，行为正常的客户端未观测到任何可测量的影响，集群亦保持健康状态。当团队主动关闭其中两个节点时，直连集群的客户端立即遭遇错误率飙升乃至完全失败；而控制器则将流量绕过失效节点。经由BIG-IP传输的流量，其性能波动范围控制在直连基准值的正负6%以内，有力驳斥了“在客户端与存储之间增加控制点必然拖慢整体性能”的常见质疑。

协议感知能力使该控制点得以发挥作用

AI数据交付在计算与存储交汇边界处部署了一层智能流量管理，其有效性依赖于对存储语义（而非单纯的数据包与端口）的理解。能够识别存储桶（bucket）、操作方法（method）及租户（tenant）的控制器，可将流量路由至特定集群或节点，在统一位置强制执行各租户的配额与限流策略，并按操作类型实施节流。LIST调用即凸显该细粒度控制的重要性：据F5的一家技术合作伙伴称，若所有客户端同时刷新其对集群的视图，集群性能将骤降约75%。但该行为与传统负载均衡之间存在明确界限。

Menger解释道：“执行双向爆炸半径（blast radius）控制的应用交付控制器，会密切关注每个节点的响应能力与健康状况，主动限制流向异常节点的流量以赋予其恢复空间，并将流量导向健康节点，从而显著提升异常节点的恢复概率。”

F5 公司全球人工智能与安全解决方案架构师 Fouad Chmainy 表示，增加容量不会改变底层架构。“容量采购无法解决原有问题。在突发性小对象负载下，增加带宽对尾部延迟毫无改善作用；而在单一无差异路径后增加节点，则会扩大相关故障域。”

为何增加容量无法解决架构问题

增加容量同样无法区分不同工作负载。它既不能将合法的数据检索与失控循环区分开来，也无法防止某一租户消耗超出其应占份额的资源。Menger 补充道，解决这些问题需要一种架构层面的方案。

Chmainy 解释道：“企业需要一个具备弹性与安全性的存储‘前门’。过去，在存储前端部署一款标准的纯软件负载均衡器即可满足需求；但如今，越来越多组织将意识到：若以成功运行为目标进行架构设计，这种数据的正常运行时间、弹性和安全性所带来的长期价值将愈发凸显。”

随着企业从尝试性应用人工智能转向大规模运营人工智能，这一区别变得愈发重要：在基础设施上投入更多资金，并不能替代专为应对由此产生的需求而设计的架构。

Chmainy 表示：“你花钱的能力，并不必然等同于你构建出良好工程化解决方案的能力。假设我将取得巨大成功，那么在人工智能规模下的‘成功’究竟意味着什么？它将呈现出你前所未见的形态。若未配备爆炸半径控制机制，便将此系统连接至企业全部系统，你的业务就可能真正陷入瘫痪。”