Salesforce 怎样把复合智能体的推理尾时延砍掉一半

Salesforce 的复合人工智能推理：Agentforce 与 ApexGuru 的生产部署

Srikanta Prasad S V（通信 Srikanta.prasad@salesforce.com）、Utkarsh Arora（通信 utkarsh.arora@salesforce.com）。单位：Salesforce India Pvt Ltd，Agentforce AI Platform，班加罗尔。

论文被 ACM Conference on AI and Agentic Systems（ACM CAIS 2026）接收。会议信息栏还写 Conference on Compound AI Systems，2026。

摘要

企业人工智能应用越来越依赖复合人工智能系统。复合人工智能系统把多个模型、检索器和工具组合起来完成复杂任务。把它放进生产，需要推理基础设施能同时服务异构的模型调用，并且成本和时延都可控。

本文是 Salesforce 一套模块化、不绑定单一云厂商的推理架构的生产部署研究。它支持的复合用例包括 Agentforce（自主人工智能智能体）和 ApexGuru（用人工智能做代码分析）。系统把无服务器执行、动态自动扩缩和机器学习运维流水线接在一起，在多组件智能体工作流上提供稳定的低时延推理。

生产结果：尾时延（P95，95% 的请求都不慢于这个时间）降低超过 50%；吞吐最高约 3.9 倍；相对原先的静态部署，成本节省 30%–40%。作者还分析了只在服务智能体负载时出现的问题：多模型扇出开销、级联冷启动，以及异构扩缩。冷启动指实例从零拉起模型、第一次请求要额外等待的时间。

通过案例和运行教训，架构让复合系统能并行扩展模型调用、扛住突发的多智能体流量，并支持快速换模型。

关键词：复合人工智能系统，推理服务，多智能体编排，机器学习运维，自动扩缩，生产部署，时延优化，智能体系统。

1 引言

人工智能正在从单模型转到复合系统：用多个互相作用的组件完成任务，包括模型、检索器和外部工具（文献 1）。代码生成到客户支持上的先进结果，越来越不是单个大语言模型单独取得的（文献 2），而是精心编排的多个能力（文献 3）。一次用户请求可能触发 3 到 5 次不同的模型调用，依赖关系复杂。时延要求也不一样。这超出了传统的单模型服务。

在 Salesforce，Agentforce 用来在业务职能上部署自主智能体，底层是 Atlas Reasoning Engine。一次智能体交互可能在同一次用户请求里调用嵌入模型做知识检索、大语言模型做对话，以及专门模型做意图分类。早期放在静态 GPU 上，暴露出四类只属于复合负载的限制：（1）流量高低都要付 7×24 的固定成本，不能按组件单独扩缩；（2）多种模型抢同一 GPU 池；（3）一个组件冷启动会拖住整个智能体回答，形成级联时延；（4）部署流水线跟不上多组件系统所需要的快速换模型。

为此，作者做了一套面向复合负载的可扩展推理架构。它建立在他们先前的企业人工智能推理架构上（文献 4），并加三项面向复合系统社区的贡献：（1）刻画多模型扇出开销、异构扩缩和级联失败，这些在单模型服务里不会出现；（2）定量说明架构如何处理这些问题，包括并行调用效率、组件级冷启动传播和跨模型资源分配；（3）12 个月以上生产部署的运行教训，给做智能体推理基础设施的人用。

后文：第 2 节相关工作，第 3 节架构，第 4 节评测，第 5 节教训与案例，第 6 节结论。

2 相关工作

Zaharia 等（文献 1）指出，先进结果越来越多来自组合多个模型、检索器和工具的系统。后续工作讨论企业里的蓝图架构（文献 3），以及 DSPy 这类编程复合流水线的框架（文献 5）。DSPy 把声明式的语言模型调用编译成可以自我改进的流水线。

训练侧已有数据并行、模型并行和流水线并行（文献 6–9）。本文补的是推理基础设施这一层（文献 10），让复合系统在生产里能跑。这一层受到的注意少于编程层和优化层。

Amazon SageMaker 一类云平台在专用实例上托管，并带自动扩缩策略（文献 11、12），但仍有空闲成本，也难处理多智能体那种异构、突发的调用。无服务器推理方面，Amazon Bedrock Custom Model Import（文献 13）接近把 AWS Lambda 用到 GPU 推理上：负责扩缩，只按实际使用收费。Salesforce 的方案沿类似原则，但不绑定厂商，并针对复合负载做了适配。

推理优化上，vLLM 的 PagedAttention 改善了大语言模型服务的内存管理（文献 14、15）。DJL Serving 支持多框架和批调度。Nvidia NIM 把优化过的模型运行时打成可移植容器。本文的架构可以接这些引擎，但处理的是更上面一层：编排多个异构模型后端，去服务复合系统的流量、失败模式和成本。

编排方面，ALTO 做流水线阶段之间的网络流式优化（文献 16）。SGLang 优化大语言模型程序的结构化生成（文献 17）。它们优化的是系统内部的通信和生成。本文补的是生产基础设施：供给、扩缩和管理这些后端。

3 系统设计

3.1 架构概览

推理系统把模型托管、编排逻辑和客户端交互拆开。对复合系统，这是必要的，因为一次用户请求里要同时调多个模型。编排层是 Agentforce 的 Atlas Reasoning Engine：事件驱动的认知工作流，多个推理任务并发执行。它编排一张函数节点的有向图，节点包括检索、规划和动作执行，用发布-订阅的异步模式并行跑。每个组件独立，又保持一致，新工具或新模型可以水平加上去。作者认为，正是这张图把一组模型变成能做多步推理的复合系统。

图 1：Atlas Reasoning Engine 里的认知编排。规划智能体拆用户查询；工具选择器并行派给大语言模型工具（检索增强检索器、代码解释器、SQL 执行器）。推理智能体汇总结果并合成最终回答。每次工具调用都由这套可扩展推理架构支撑。原图入库。

编排层下面是分层的推理服务。客户端把请求发给 Prediction Service，它是统一的推理网关，挡住底层模型基础设施。预处理和后处理单独成模块：功能团队可以写提示构造、结果过滤等业务逻辑，而不改模型服务器。两种部署：

• 轻量的无服务器函数：云函数注入提示、调用推理接口、格式化输出。路径保持无服务器和弹性，适合无状态操作。
• 较重的代理微服务：常驻微服务跑自定义逻辑，再把推理转发到模型后端。可以复用已有监控，避开函数体积限制。代价是少量常开成本和几毫秒额外时延。

两种模式里，推理后端都是按需的模型服务层：有请求才加载实例，并自动扩缩。空闲时缩到零，去掉空闲成本。对时延要求严的模型，保留预置并发。预置并发指提前放着热实例，避免从零拉起。

失败处理上，Prediction Service 按组件做熔断。熔断指某个依赖失败或超时后，不再把整个请求打死，而是返回结构化错误。Atlas Reasoning Engine 收到结构化错误而不是硬崩溃，可以绕开失败。例如 SQL 执行器失败时，退回基于文本的推理。

3.2 按复合系统来扩缩

扩缩层要知道复合系统的调用形态，而不是把流量当成同质的。架构明确处理三点。

扇出放大。一次 Agentforce 用户请求可能扇出到 3 到 5 次模型调用，例如嵌入、大语言模型和分类器。N 个用户请求最多变成 5N 次模型调用，而且同时打到不同后端。扩缩层按每个模型自己的调用率扩，而不是按用户请求总数扩。这样，每条扇出路径都会用到的模型（如嵌入）不会供给不足，只在条件下才用的模型也不会供给过多。

异构时延。嵌入模型可能 50 毫秒返回，对话大语言模型要 3 到 5 秒。Prediction Service 用考虑这种差异的请求优先队列，避免快路径（嵌入、分类）被慢路径堵住。否则便宜、快的操作会因为抢不到资源变成瓶颈。

相关冷启动。空闲之后，第一个用户请求会同时触发多个模型的冷启动，而不只是一个。作者称之为级联冷启动：用户要等最慢的那个，而且依赖图里有些冷启动要等上游先出结果才能开始。

三级办法：

1. 协调预热。已知流水线里某个模型第一次被访问时，主动预热下游。对 A→B→C，预热 A 会并行预热 B 和 C。相对各模型独立预热，复合冷启动时延降低 65%。
2. 分层预置并发。时延关键的流水线只给关键路径模型（通常是冷启动最长的大语言模型）保留预置并发。更快的模型（嵌入、分类器）允许从零扩，冷启动大约 20–30 秒可以接受。只供给瓶颈模型的成本大约是全部供给的 20%，同时去掉大约 70% 的用户可感知冷启动延迟。
3. 按流量信号预测性预热。复合流量在粗粒度上往往可预测，例如工作时间和批作业时刻。平台支持按计划预加载。对 Agentforce，工作日早晨预热去掉了高峰时段 90% 以上的冷启动。

动态路由默认在 auto 模式：请求先去专用实例。专用实例不可用或超过并发上限时，溢流到无服务器后端。这样不必为了时延 SLA 把专用硬件配得过满。SLA 是事先约定的服务水平。

3.3 高方差负载

无服务器推理要在短时间里体积、成分和时延要求都剧烈波动时保持稳定。复合系统把方差拉到多个维度。

体积。产品发布、批处理或黑客松时，用户请求率可以尖峰到 10–50 倍。新 GPU 实例在数秒内拉起，并支持跨多个可用区的突发容量。测得系统吃下 10 倍尖峰时，P95 仍在稳态的 1.5 倍以内，是变差而不是失败。

成分。工作时间 Agentforce 偏大语言模型；非工作时间 ApexGuru 的代码分析批作业偏嵌入。每个模型独立扩缩，成分变化不会互相抢：大语言模型缩下去时嵌入可以扩上来。静态共享基础设施上，这要么手工再平衡，要么按最坏组合过度供给。

时延要求。有的流水线是交互的，Agentforce 聊天的 SLA 是 5–8 秒；有的可以等批处理，ApexGuru 60 秒以上也可以。Prediction Service 按带时延类别的元数据路由：交互请求优先用热实例，批处理可以忍受冷启动。避免为了最严的 SLA 把整个系统都过度供给。

3.4 机器学习运维与部署流水线

复合系统放大了模型生命周期：一个系统依赖多个以不同速度演进的模型。流水线叫 Falcon，是统一的模型交付持续集成与交付。团队训练新版本并登记到 Model Store（基于 S3 的制品库）后，流水线调用推理服务的导入接口。部署自动化，加在大约 1 小时的发布过程上的开销大约是秒级。每个模型有一个由 Prediction Service 路由的端点标识。YAML 配置写模型 ID 和后端类型（无服务器或专用），换版本不用改代码。平台接入集中监控，按模型看请求率、时延和错误。冷启动时，Prediction Service 对最初的请求做重试和排队。产品团队改配置就能换模型提供方，供给由平台完成。

对复合系统关键的一项是组件级 A/B 测试。因为每次模型调用独立路由，团队可以在流水线里只测一个组件，例如新的检索模型，而不动其他组件。单体部署必须整系统替换，做不到这一点。实践中，模型实验周期从数周降到数小时。

3.5 模块化与可移植

模型执行引擎抽象成一致接口，下面可以是 TensorRT 或 PyTorch。DJL Serving 提供与引擎无关的层，并用滚动批推理提高 GPU 利用率。组件跑在容器或函数里，可以放到其他云或本地。Prediction Service 这一层抽象之后，模型可以由 AWS Bedrock、Azure ML、GCP Vertex AI 或本地 Nvidia NIM 容器来服务，改动很小。原型里已经把 Agentforce 接到私有 Kubernetes 上的 Nvidia NIM。对企业客户的多云或数据驻留合规，不绑定厂商是必要的。

4 评测

五个维度：单模型时延与吞吐、成本、复合系统开销、复合负载下的可靠性、对下游质量的影响。实验用的是生产负载和生产模型。

规模：当时的 Salesforce 部署服务超过 8,000 个企业用户，日均约 722,000 次大语言模型推理，业务高峰日约 140 万次请求（2026 年 3 月）。峰值供给容量 2,250 RPS（每秒请求数），即 135,000 RPM（每分钟请求数），分布在 21 个全球生产推理区域。仅 2026 年 3 月处理 1,360 亿 token，约每天 44 亿 token。token 是模型计费和长度的基本单位。请求量同比增长 8.7 倍。

4.1 时延与吞吐

从静态端点迁到自动扩缩之后，13B 参数的 ApexGuru 模型：低并发（1–2 个并行用户）时 P95 从大约 13–15 秒降到大约 7–8 秒，约快 45%。更高并发时，SageMaker 的 P95 升到大约 37 秒，新系统保持大约 10–11 秒，降低超过 50%。旧的单 GPU 端点在 50–60 RPM 饱和；自动扩缩系统维持 200 RPM 以上，峰值约 232 RPM，吞吐约 3.9 倍。表 1 是三个复合用例。

表 1：三个复合人工智能用例的主要结果。P95 为下降比例，TPS 为吞吐倍数，Cost 为成本下降倍数。

摘要里的 30%–40% 成本节省，对应第 4.3 节去掉夜间空闲之后的高峰服务成本；表 1 的成本列是优化后相对旧方案的倍数，两者不是同一个数。

4.2 复合系统开销

这些测量不在先前的基础研究（文献 4）里。作者称，就生产智能体系统而言，他们未见别处报告过。

#### 4.2.1 扇出开销

典型 Agentforce 查询扇出到 2–4 次模型调用。模型已热时，扇出开销（超出最慢那一次模型调用的时间）平均 45–80 毫秒，主要是 Prediction Service 的路由和应答汇总。相对 5–8 秒的总回答时间，开销不到 2%。并行分发的协调税很小。旧架构必须串行调用同样的模型，会多等 1.5–3 秒，3 个以上模型的流水线就做不成交互时延。

#### 4.2.2 级联冷启动

空闲 15 分钟后测复合流水线。没有协调预热时，第一个智能体请求同时冷启动 3 个模型：嵌入约 30 秒，对话大语言模型约 150 秒，分类器约 20 秒。Atlas 流水线有依赖，嵌入必须先完成，大语言模型才能生成带上下文的回答。有效冷启动约 180 秒，是依赖链串起来的时间，而不是最长单个冷启动的约 150 秒。协调预热把复合冷启动从约 180 秒降到约 65 秒，降 65%，做法是并行独立预热并预加载依赖链。

#### 4.2.3 异构扩缩

生产里 Agentforce 流量到基线的 10 倍时，嵌入调用按比例到 10 倍，因为每个请求都要嵌入。对话大语言模型只到 6–7 倍，因为规划步骤会滤掉一部分可以从缓存知识回答、不必完整调用大语言模型的查询。SQL 执行器只到 2–3 倍，因为它是有条件调用的。按模型独立扩缩能跟上这种不对称。若按用户请求数把所有模型均匀扩到 10 倍，SQL 执行器会被过度供给 3–5 倍，嵌入则可能供给不足。

表 2：10 倍流量尖峰下的复合系统扩缩。

4.3 成本

改成按使用付费后，服务成本马上改善。旧模式下，功能主要在工作时间用，GPU 仍 7×24 开着。无服务器之后，GPU 成本随真实需求走。ApexGuru 高峰服务成本降 30%–40%，因为去掉了夜间空闲。有条件才调用的模型（如 SQL 执行器）只在触发时耗资源，不必作为单体部署的一部分永久供给。代价是：持续高利用率时，无服务器的按 token 计价可能高于专用 GPU。作者的建议是，变化或中等负载用自动扩缩，持续重负载留专用容量（第 5.1 节）。

4.4 复合负载下的可靠性

一次用户请求扇出到多个模型，任一组件失败都会让整个回答变差。自动扩缩后端在实例过载时自动替换，并支持多区域故障转移。突然 10 倍流量时，P95 保持在稳态的 1.5 倍以内；静态基础设施是 3–4 倍变差。

为量化高方差，作者重放 30 天生产流量日志，并人为加大方差：把到达间隔时间的变异系数加倍。变异系数是标准差除以均值。在此条件下，自动扩缩系统 98% 的时间把 P95 保持在稳态的 2 倍以内，最极端尖峰时有短暂越出。剩下 2% 的区间对应 3 个以上模型同时冷启动，就是第 3.2 节的级联冷启动。打开协调预热后，P95 越界率降到 0.5% 以下。

混合成分切换时（工作时间的交互负载转到晚间批处理），按模型独立扩缩没有资源争用，也不需要人工干预。运行上的要点：突发复合负载下自动扩缩避免过度供给；混合部署用预热模型池把冷启动降低 65%；GPU 装箱平均利用率 70%–80%。熔断和动态路由使部分模型中断时智能体可用性仍高于 95%，峰值负载下消息丢弃率低于 0.05%。

4.5 对复合系统质量的影响

可扩展后端直接带来输出质量变化。Agentforce 的 Atlas Reasoning Engine 并行编排多步推理和工具后，相对单大语言模型实现，回答相关性提高 2 倍，端到端任务成功率提高 33%。这些收益来自同时使用不同知识源，而这只有在后端能高效处理多次同时的模型调用时才可行。ApexGuru 分析的 P95 降到 8 秒以内，开发者采用增加。

5 讨论

5.1 复合系统的混合部署

复合系统里，对话大语言模型可能持续高 QPS，专门工具模型则偶尔才被调用。QPS 是每秒查询数。架构用透明的混合路由同时支持无服务器和专用。Prediction Service 的路由表给每个模型端点标部署模式：无服务器、专用或 auto。auto 是多数模型的默认：专用实例可用且低于容量阈值就走专用，否则溢流到无服务器。

在一条 Agentforce 流水线里，不同模型可以同时处于不同模式。对话大语言模型 QPS 稳、时延严，走专用实例。嵌入模型量大但冷启动快，走无服务器。SQL 执行器稀疏、有条件，走无服务器且不预置并发。编排引擎只看见统一的推理端点。同一套流水线和监控覆盖两种模式。把一个模型从一种模式换到另一种，只改 YAML，不改代码。这种混合比纯无服务器或纯专用再降 15%–20% 的总推理成本，因为每个模型用适合自己流量形态的更省模式。

5.2 案例：ApexGuru

ApexGuru 是代码评审助手，用专门的 13B 大语言模型。最初在专用 GPU 实例上服务，解析逻辑嵌在里面。非工作时间 GPU 空转，尖峰时单实例成为瓶颈。迁移后，团队把模型上传到 Model Store，部署由系统完成。领域处理挪到 Lambda 函数，服务变成无服务器。结果：P95 减半，成本按实际使用计费，团队可以同时部署多个模型变体做快速 A/B 测试。

5.3 案例：Agentforce 对话智能体

一次典型交互编排：大语言模型做意图理解，向量检索做知识检索，Atlas Reasoning Engine 做多步推理。50 个智能体会话同时开始时，所需模型实例在 GPU 池上拉起，用完拆除。在碰到外部接口上限之前，吞吐随每块新增 GPU 线性增长。相对单大语言模型机器人，Atlas Reasoning Engine 在无需人工介入的情况下多解决约 33% 的支持案例。即便涉及 2–3 个模型和一次检索，整体对话响应仍在 5–8 秒。

5.4 十二条运行月里的教训

企业规模上跑了十二个月，有几条并不显而易见。

教训 1：冷启动是按依赖相乘，不是相加。最初以为复合冷启动等于单个冷启动的最大值。实际上智能体图里的依赖造成串行段。三个模型的冷启动若是 150 秒、30 秒和 20 秒，有效冷启动约 180 秒而不是 150 秒，因为嵌入必须先出结果，大语言模型才能生成带上下文的回答。这推动了第 3.2 节的协调预热。

教训 2：只看模型级可观测性不够。单模型的时延、吞吐和错误率都在自己的 SLA 内，合进流水线后仍可能打破智能体级 SLA。作者做了流水线级可观测：端到端智能体响应时间按组件拆开，用来找某条工作流上的关键路径瓶颈。

教训 3：成本归属要知道流水线。按次计量把成本记到单个模型上，看不出哪条复合流水线贵。一个模型被 5 种智能体共用时，成本很难拆。计量扩展为带上发起方的流水线 ID，才能按智能体类型报成本。这是在复合系统里做成本优化的前提。

教训 4：组件级 A/B 测试是复合系统的长处。在多模型流水线里只换一个模型，例如升级检索模型而大语言模型不动，能隔离单个组件的影响。单体部署做不到。平均模型改进周期从 2–3 周降到 2–3 天。第 3.4 节写的是实验周期从数周到数小时，这里是改进周期从周到天，原文两处都保留。

教训 5：体面降级比峰值性能更重要。非关键模型失败时，例如 SQL 执行器，系统应降级而不是整单失败。Prediction Service 按组件熔断：模型失败时，Atlas Reasoning Engine 收到结构化错误并改道，例如用文本推理代替 SQL。部分模型中断时，智能体可用性仍高于 95%。

教训 6：抽象的路由和队列是可复用的基本件。作者建议社区采用面向复合系统的优先队列，避免快路径被饿死，以及与托管无关的 Prediction Service 抽象。这把编排和托管拆开，便于多云可移植，也便于任何多智能体架构做降级。

5.5 复合系统里的安全与信任

数据流过多个组件，会带来安全问题。架构用模块化的信任接入处理：合规检查，例如专有的 Trust Layer，用来做毒性过滤和数据遮蔽，在预处理层、模型调用之前执行。这样无论后端是哪个模型，安全检查是同一套。原文没有展开攻击步骤或绕过方法。

6 结论与后续

本文是企业规模上、面向复合人工智能系统的可扩展推理架构的生产部署研究。除文献 4 已报告的时延、吞吐和成本之外，本文刻画了复合系统特有的推理问题，定量给出扇出开销和异构扩缩，并记录服务 Agentforce 与 ApexGuru 超过 12 个月的运行教训。

给实践者的四点：（1）复合系统的推理基础设施应按各模型的真实调用形态独立扩缩，而不是按总请求数；（2）冷启动沿依赖图相乘传播，需要协调缓解；（3）流水线级的可观测和成本归属，不能停在模型级指标；（4）组件级 A/B 测试是模块化推理架构才有的优化杠杆。

后续包括 GPU 复用和新加速器（AWS Inferentia、NVIDIA Grace Hopper）以进一步降成本，跨区域负载均衡，以及与 DSPy 一类编程框架更紧地集成，以便按流水线阶段做端到端的推理资源分配。作者也在探索预测性扩缩：用智能体工作流图，在请求到达之前预判模型调用形态。

参考文献

按原文编号保留，不另增。

1. M. Zaharia 等，The Shift from Models to Compound AI Systems，Berkeley AI Research Blog，2024 年 2 月。
2. T. Brown 等，Language Models are Few-Shot Learners，NeurIPS，第 33 卷，1877–1901，2020。
3. S. Suri 等，A Blueprint Architecture of Compound AI Systems for Enterprise，arXiv:2406.00584，2024。
4. S. Prasad、U. Arora 等，Scalable Inference Architectures for Operationalizing AI/ML in Enterprise Systems，IEEE AIMLSYS，2025 年 10 月。
5. O. Khattab 等，DSPy，arXiv:2310.03714，2023。
6. J. Dean 等，Large scale distributed deep networks，NeurIPS，第 25 卷，1223–1231，2012。
7. D. Narayanan 等，PipeDream，ACM SOSP，1–15，2019。
8. Z. Jia、M. Zaharia、A. Aiken，Beyond Data and Model Parallelism for Deep Neural Networks，MLSys，2020。
9. S. Rajbhandari 等，ZeRO，SC，2020。
10. K. Sreedharan 等，Scalable Inference Serving Systems for Deep Learning Models，USENIX NSDI，135–149，2022。
11. S. R. Kotini 等，Improved ML model deployment using Amazon SageMaker Inference Recommender，AWS Machine Learning Blog，2023。
12. R. Jadav、R. Aggarwal，How AWS SageMaker Inference Components Save AI Inference Costs by Up to 8x，AWS Machine Learning Blog，2025。
13. S. Prasad、U. Arora 等，How Amazon Bedrock Custom Model Import streamlined LLM deployment for Salesforce，AWS Machine Learning Blog，2025 年 10 月。
14. W. Kwon 等，Efficient Memory Management for Large Language Model Serving with PagedAttention，USENIX OSDI，1159–1177，2023。
15. N. Parmar 等，Scalable and Efficient Foundation Model Inference with PagedAttention，arXiv:2309.17453，2023。
16. K. Santhanam 等，ALTO，4th Workshop on ML and Systems，117–125，2024。
17. L. Zheng 等，Efficiently Programming Large Language Models using SGLang，arXiv:2312.07104，2023。

出处：Srikanta Prasad S V，Utkarsh Arora，Scalable Inference Architectures for Compound AI Systems: A Production Deployment Study，2026-04-28，https://arxiv.org/abs/2604.25724，CC BY 4.0。