从聊天机器人到复合AI系统：多模型工具应用的基础设施模式
2026/08/26 08:29阅读量 3
随着AI应用从单一LLM转向由检索、分类、代码解释器等多组件构成的“复合AI系统”，传统的基础设施架构已无法适应。Salesforce基于2026年大规模生产数据的研究揭示了此类系统在扩展性、延迟和资源管理上的新挑战。核心发现包括请求扇出导致的非均匀负载、异构延迟引发的资源争用，以及状态管理的复杂性，要求基础设施具备细粒度的追踪与隔离能力。
事件概述
生成式AI的生产部署正经历从“单一模型服务”向“复合AI系统（Compound AI Systems）”的范式转移。正如Matei Zaharia等人在2024年提出的观点，当前最先进的AI成果往往依赖于包含多个组件的系统工程，而非单体模型。2026年4月，Salesforce发布了一项针对企业级复合AI推理部署的长期研究（覆盖12个月以上），分析了在8,000用户规模下，日均72.2万次LLM推理、峰值达140万次的生产环境数据。该研究指出，现有的基础设施模式若仍沿用单模型服务的思维，将无法应对复合系统带来的复杂性与性能瓶颈。
核心信息
1. 请求扇出放大（Fan-out Amplification）与非均匀扩展
在复合AI系统中，单个用户请求不再对应单次模型调用，而是触发多次并发的模型推理。根据Salesforce的数据，典型的Agent查询会扇出至2-4次模型调用，广义上常见为3-5次。这些调用涉及不同功能的模型组合，如嵌入模型（Embedding）、对话LLM、意图/安全分类器、代码解释器或SQL执行器。
基础设施影响：
- 扩展逻辑失效： 如果平台仅基于聚合的用户请求率进行统一扩缩容，会导致资源分配严重失衡。例如，嵌入模型需随100%的请求率扩展，而SQL执行器可能仅在25%的请求中触发。
- 实际案例： 在10倍流量激增测试中，嵌入模型扩展了10倍，对话LLM扩展了6-7倍，而SQL执行器仅扩展了2-3倍。若采用统一扩展策略，SQL执行器将被过度配置3-5倍，而嵌入模型可能面临资源不足。
- 解决方案： 基础设施必须实现**按模型调用次数（Per-model invocation）**的独立追踪与扩展，而非仅追踪用户请求数。
2. 异构延迟特征与资源争用
复合系统中的各组件具有截然不同的延迟特性。嵌入模型可能在50毫秒内响应，对话LLM需3-5秒，而代码解释器可能耗时数十秒。当这些模型共享底层基础设施（如GPU集群）时，慢速模型会阻塞快速模型，导致资源饥饿和队列积压。
基础设施影响：
- 资源竞争： Salesforce的研究记录了一个具体场景：快速的嵌入模型与慢速的对话LLM在共享队列中竞争GPU资源。由于缺乏延迟类别隔离（Latency-class isolation），快速任务被慢任务阻塞，整体吞吐量下降。
- 关键需求： 基础设施需提供细粒度的资源隔离机制，确保低延迟敏感型任务（如嵌入、分类）不受高延迟任务（如长文本生成、代码执行）的影响。
(注：原文在此处截断，后续关于状态管理和可观测性的内容未提供)