【赛迪网讯】一次代码修改任务，可能需要智能体反复读取项目文件、生成方案、调用工具、运行测试，再根据结果继续修改。用户看到的是一项任务，推理系统承接的却可能是数十轮模型请求，以及不断增长的上下文。如何减少这些请求中的重复计算，正在成为Agent规模化应用必须解决的工程问题。

9月22日，百度智能云联合SGLang社区在北京举办“Agent时代的推理基础设施：百度百舸×SGLang生产级实践”Meetup。来自百度智能云、SGLang社区及NVIDIA等方面的技术人员，围绕多芯适配、上下文缓存、显存优化和推理服务治理展开交流，讨论如何将模型能力转化为可持续交付的生产服务。

这些议题指向同一项变化：评价推理基础设施，需要从单次请求的响应速度，进一步延伸到完整任务的执行时间、资源消耗和服务稳定性。

百度智能云主任架构师黎世勇介绍，过去讨论推理优化时，典型负载往往是数千Token输入、上千Token输出；如今，百度内部相关业务的平均上下文已达到约6万Token，并且仍在增长。输入变长、多轮调用增加，使缓存复用和调度策略对系统效率的影响更加突出。

公开基准也呈现出类似特征。SemiAnalysis旗下InferenceX公布的AgentX v1.0包含393个编码智能体会话，其请求输入Token数中位数为142,016，输出Token数中位数为444，44%的会话包含子智能体。这组样本不能代表所有Agent应用，但说明在真实编码任务中，系统需要处理的历史信息，可能远多于每轮新增的输出。

这种负载结构改变了推理优化的重点。大模型通常先处理输入，即预填充阶段，再逐步生成输出，即解码阶段。Agent每次调用工具后，往往需要把此前的对话、工具结果和任务说明重新带入下一轮请求。如果这些重复内容都要重新计算，任务越长，累计开销就越大。

KV Cache的作用，是保存模型计算过程中可复用的中间状态，减少重复处理相同上下文的计算量。它并不等同于应用层的长期记忆，却直接影响智能体连续执行任务时的响应效率。

在此次Meetup上，SGLang社区分享了从RadixAttention到Unified Radix Cache的演进。前者通过前缀树组织缓存，让具有相同输入前缀的请求复用已有计算结果；后者进一步面向混合模型架构，把统一的树结构与不同类型状态的复用规则分开管理。

这项变化有明确的工程背景。全注意力、滑动窗口注意力以及Mamba等架构，对历史状态的保留方式和可复用边界并不相同。简单套用一套规则，可能浪费本可复用的缓存，也可能错误复用已经失效的状态。统一缓存框架需要兼顾管理效率和计算正确性。

这一方向也体现在近期的开源更新中。SGLang于9月18日发布的v0.5.20版本，列出了滑动窗口注意力分支点缓存等优化。在其披露的DeepSeek-V4-Flash测试中，共享前缀Token命中率由43.8%提高至60.8%，平均首Token时延由1.57秒降至1.07秒。这是特定测试条件下的结果，也反映出开源推理引擎正在针对多分支、可复用的上下文结构持续优化。

但缓存并非越多越好。模型权重和KV Cache共同占用显存，长上下文和高并发容易使显存成为瓶颈；将缓存转移到主机内存或远端存储，又会引入额外的数据传输和索引管理开销。

因此，分层缓存需要回答一个实际问题：取回已有计算结果，是否比重新计算更划算？

SGLang的HiCache通过显存、主机内存和共享存储构建多级缓存体系，让较大规模的历史上下文有机会被保留和复用。百度百舸在现场分享中则进一步强调，缓存优化需要同时观察命中率与性能损耗。命中率提高带来的计算节省，只有覆盖数据搬运和管理成本，才能形成实际收益。

这也是基础设施竞争正在向存储、网络和内存管理延伸的原因。NVIDIA今年公布的BlueField-4驱动CMX上下文存储方案，同样将KV Cache跨层存储和传输作为重点，利用Dynamo与NIXL等组件协调上下文在内存和存储层级之间流动。

当推理服务扩展到多个节点，问题还会进一步复杂化：一个节点保存着上一轮的缓存，下一轮请求却可能因负载均衡被分配到另一节点。单个引擎内部的缓存优化，未必能直接转化为整个集群的收益。

百度智能云架构师张彦哲介绍，在其分享的服务架构中，同一会话的多轮请求会优先进入此前所在的地域，地域内调度器再结合缓存分布选择推理节点。如果负载均衡要求请求进入其他节点，系统会通过缓存池化和预取，提前搬运可复用的数据。

其中一个值得关注的设计是，预取可以被中断。当引擎开始处理请求时，系统使用已经到位的缓存，避免为等待剩余缓存而拖延计算。背后的取舍是：缓存命中率、传输时间和节点负载必须共同优化，追求单一指标的最大值未必能带来最短的任务耗时。

硬件适配是另一项直接影响部署成本的因素。企业希望使用更多类型的算力，但如果每增加一种芯片，就需要长期维护一套与开源主干分离的代码，采购端的成本优势可能被软件适配和维护开销抵消。

百度智能云高级工程师董新宇在现场介绍了SGLang-Kunlun插件实践。据其介绍，相关插件已开源，通过平台抽象和扩展机制，将昆仑芯特有的通信、算子及设备能力与推理框架主体解耦，减少跟随社区版本迭代时的重复修改。

这一方案的价值在于，使硬件接入能够围绕相对稳定的接口展开。对于企业用户，评估异构算力时，也需要同时考虑新模型适配速度、输出精度、性能调优工具以及后续维护成本。

实际优化往往还藏在更细的环节中。百度团队在昆仑芯平台的HiCache适配中，介绍了缓存读写异步化、主机内存布局调整以及冗余数据消除等实践。例如，在所述八路张量并行、缓存内容相同的场景下，通过共享内存保存一份数据，可以减少多份重复存储，扩大同等内存预算下的有效缓存容量。

这说明，Agent推理效率既取决于芯片计算能力，也受到CPU、内存和互连链路的约束。某个环节的数据传输或任务下发不及时，都可能让加速卡处于等待状态。

针对超大模型部署，百度方面披露，在相关测试中，MoE专家压缩50%后，长输出、高并发场景的输出吞吐峰值可达到原来的2.23倍。

这一数据展示了压缩技术释放部署资源的潜力，但不宜直接换算为所有Agent任务的成本降幅。具体收益仍取决于模型、硬件、请求分布，以及压缩后能否保持业务所需的任务质量。对于企业而言，吞吐提升只有与任务成功率、响应时间和资源费用结合评估，才能判断实际价值。

从本次Meetup展示的实践看，百度百舸正在把多芯适配、推理引擎优化、上下文管理与集群调度结合起来，解决Agent连续运行时的资源效率问题。随着调用链路拉长，单点性能优化需要通过整套服务的协同，才能转化为用户可感知的改善。

企业最终需要核算的，是一次成功任务花了多少钱、需要等待多久，以及在业务高峰期能否稳定完成。缓存复用减少重复计算，资源管理提高承载能力，调度策略降低排队和搬运开销，这些工程能力共同影响Agent的使用成本。

当Agent从试用走向持续生产，推理基础设施的价值，也将更多体现在这些可衡量的任务结果中。