思想领袖

智能体式 AI 撞上基础设施瓶颈的时间,会早于撞上智能瓶颈

mm
将 Unite.AI 添加到您在 Google 上的首选来源

模型进步的速度,已经超过了我们为其所承担任务提供服务的能力。

关于 AI 智能体未来走向的大多数讨论,都围绕能力展开:模型能否可靠地制定计划?能否从自己的错误中恢复?能否放心地让它执行会产生后果的操作?

这些问题确实重要。但它们并不是决定智能体能否在未来几年大规模部署的关键,因为眼下还有一个更迫近的限制,而且它来得更快。为智能体提供服务在经济上并不划算,而大家想要添加的功能越多,这种不划算就越严重。

聊天机器人和智能体的工作负载并不相同

一次对话请求只需一轮往返:输入提示词,生成词元,然后关闭连接。你可以对请求进行批处理、缓存前缀,并用一个数字来衡量吞吐量。

智能体请求则是一个会话。它调用工具、等待、读取结果、决定下一步做什么、再调用另一个工具,最终给出答复。一项不算复杂的任务,可能需要调用模型六到八次,中间还要等待。

这种差异之所以重要,与智能水平无关。在各步骤之间,智能体会保留状态——包括对话内容、工具输出和累积的推理结果。在服务端,这些状态以 KV 缓存的形式存放在 GPU 内存中,并在整个会话期间持续占用内存,包括智能体等待某个并非由你提供的 API 响应的那几秒。

因此,容量的衡量单位不再是“每秒请求数”,而是“驻留在内存中的并发会话数”。一套系统在同一硬件上或许能轻松处理每秒一千个对话请求,但可能只能同时服务几十个智能体会话。

等待才是成本高昂之处

问题在于一个令人不安的事实:调用工具期间,智能体什么也不做。它不会生成词元,也不会消耗计算资源。然而,GPU 内存仍被占用,因为把上下文移出内存、之后再重新计算,成本比一直保留它更高。

你最昂贵的硬件,就这样被一个当下正在等待数据库查询的请求占着。

在传统分布式系统中,这个问题很久以前就解决了:释放资源,等响应到达后再继续处理任务。要在模型服务中采用同样的做法,就必须把 KV 缓存移出到主机内存或磁盘,再恢复回来;数据传输成本高到大多数系统都不愿这么做。针对这一问题的研究正在积极开展,正是因为这个问题代价高昂。

顺序执行让情况变得更糟

几乎所有智能体框架都会依次执行工具调用。模型先查询天气,拿到结果;再检查日历,拿到结果;然后搜索航班,拿到结果。

这三项调用往往彼此没有依赖关系,本可以同时执行。依次执行时,延迟是各项耗时之和;并发执行时,延迟则只相当于其中耗时最长的一项。

这并不是关于智能体的新发现,而是适用于任何在同一延迟预算内运行多个模型或服务的系统的结构性问题。总延迟应由依赖关系图中的最长路径决定,而不是把每个阶段的耗时全部相加。这一点对智能体尤为重要,因为会话在整个过程中都驻留于 GPU 内存中。因此,缩短实际耗时不仅能改善用户体验,还能直接提高同一硬件可容纳的会话数量。

将会话时长减半,在不更换模型的情况下,同一批 GPU 大致就能支持两倍的并发容量。

重试会层层叠加,后果却无人设计

智能体框架会继承其底层 HTTP 库的默认重试设置,通常是尝试三次。

模型也会以自己的方式重试。当工具返回的结果没有帮助时,推理模型往往会改用另一种方法——这也是一次重试,只不过没人配置过。

两种重试叠加起来,就会形成一种没人写明的九次尝试策略:三次重试设置套在一个会自行推理并尝试另外三种方法的模型外。每次尝试都要完整调用一次模型,并消耗各自的词元和 GPU 时间。

依赖服务一旦变慢,这种放大效应就会把性能下降变成服务中断;而且每次尝试的成本比重试一次 REST 调用高出好几个数量级。

瓶颈的真实表现

它不是能力上限,而是更平常的情况:单位经济效益问题让项目止步于从试点走向生产的关口。

试点运行顺利:用户只有十个,延迟可以接受,账单几乎可以忽略不计。接着有人按一万名用户的规模进行测算,发现所需 GPU 数量根本不现实——问题不在于模型速度慢,而在于每个并发会话都会在整个生命周期内占用内存,而生命周期也包括等待时间。

这是许多前景可观的内部演示悄然止步的阶段。

是什么推动了这道瓶颈

没有什么特别复杂的,全都是基础设施问题,而非建模问题:

并发执行彼此独立的工具调用。这是目前收益最大的一项改进,无需添置新硬件即可实现。

将会话时长作为容量指标。不是每秒令牌数,也不是 GPU 利用率,而是状态在内存中驻留多久,以及能够容纳多少个会话。

在全系统范围内统筹重试预算,而不是按单次调用分配。设置全局上限——将重试控制在总流量的一小部分——可以防止上述问题不断累积。Google 的 SRE 实践中有关处理过载的方法,以及 Envoy 的重试预算,都在 AI 技术栈之外实现了这一理念。

将推理与执行分开。用大型模型制定计划,用小得多的模型完成机械性步骤。智能体所做的大多数事情都不需要前沿模型。

降低上下文淘汰的成本。量化 KV 缓存、分页注意力,以及针对空闲会话的卸载路径。目前最有意思的推理服务工作正发生在这一领域。

模型会不断改进,这一点看来有可靠保障。智能体究竟会成为基础设施,还是只停留在演示阶段,取决于一件没那么光鲜的事——我们能否为等待中的工作负载提供服务,同时避免它一直占用昂贵的内存;以及我们能否不再为一连串步骤的总耗时买单,而只为其中最长路径的耗时买单。

我发表了支撑上述最后一点的执行模型——在单一延迟预算内并发执行彼此依赖的模型调用——相关论文“机器学习系统中模型路由的异步推理图执行”刊于《International Journal of Computer Trends and Technology》72(10),2024年10月。关于生成式模型如何融入受延迟约束的决策系统,具体可参阅“大语言模型增强的交易与决策平台:连接生成式智能与金融决策系统”,刊于《Journal of Information Systems Engineering and Management》11(1s),2026年。

Gangadharan Venkataraman从事实时机器学习和决策平台的架构设计工作。他拥有佐治亚理工学院计算机科学硕士学位,并在构建大规模分布式系统和生产级机器学习基础设施方面拥有十余年经验。