Together AI 推出 CPD 架构,长上下文推理提速 40%

深度2026年3月4日6 分钟阅读
Together AI 推出 CPD 架构,长上下文推理提速 40%
长提示词推理不必再忍受缓慢的响应。Together AI 提出了一种缓存感知的预填充-解码解耦(CPD)架构,通过分离冷热推理工作负载,将长上下文大语言模型推理的吞吐量提升了 40%,并显著降低了首词元延迟。

如今的原生 AI 应用正在将上下文长度推向新极限。从多轮对话、编码助手到智能体记忆和检索增强生成(RAG)系统,长提示词正成为常态。但高效地服务这些大型上下文仍然是个挑战:首词元延迟(TTFT)上升且波动性增大。推理性能越来越不单由模型计算决定,还取决于系统处理共享上下文的效率。

在实际工作负载中,许多请求并非完全全新。有些包含大量之前已见过的上下文——例如共享的系统提示、对话历史或常见文档。我们称这些为热请求(Warm Requests)。另一些则引入了大部分新上下文,需要完整计算——这些是冷请求(Cold Requests)

像前缀缓存和预填充-解码解耦(PD)这样的最新进展已经改善了长上下文服务。前缀缓存通过复用先前计算的提示词前缀的 KV 缓存来减少冗余工作,而 PD 则将计算密集的预填充阶段与延迟敏感的的解码阶段分离,以减少它们之间的干扰。连同其他相关技术,如分块预填充、序列/上下文并行等,它们共同帮助降低开销并提高硬件利用率。

然而,在极高负载下的实际工作负载带来了超出常见服务场景的新挑战。设想一个系统,一些并发用户提交超过 10 万词元的全新大提示词,而其他用户则继续进行主要复用先前上下文的多轮对话。PD 确保了解码不被预填充阻塞,但所有预填充——无论是冷的还是热的——仍然共享相同的预填充容量。大型冷提示词会一次占用这些资源数秒,而本可以通过缓存复用快速服务的暖请求最终却要在同一个队列中等待。结果,TTFT 增加并不是因为这些请求需要大量计算,而是因为它们被那些确实需要大量计算的请求堵在后面。

为了解决这个问题,我们构建了一个缓存感知的解耦服务架构,它用独立的计算资源处理热请求和冷请求。通过识别一个请求包含多少可复用上下文,系统可以做出更智能的调度决策——减少不必要的等待,并更有效地将工作路由到计算资源上。系统不再让昂贵的冷预填充主导共享容量,而是为热请求铺平快速通道,同时仍能高效处理新上下文。

因此,缓存感知的解耦设计使系统在负载下能够更优雅地扩展。如图 1 所示,在尾部敏感的 SLA 下,它持续维持着比传统基线更高的可实现吞吐量。在我们的评估中,CPD 将可持续 QPS 比现有的解耦设计提升了 35–40%,同时即使在存在大型冷提示词的情况下也能保持更严格的尾部延迟界限。

__wf_reserved_inherit

图 1. 延迟 SLO 下的最大可实现 QPS。

CPD 如何工作

我们提出了缓存感知的预填充-解码解耦(CPD),它通过缓存感知路由共享 KV 缓存层级扩展了标准的预填充-解码解耦服务。核心思想很简单:不要让昂贵的“冷”预填充阻塞可复用上下文的快速通道

系统将推理分为三个角色:

  • 预填充前节点(Pre-Prefill nodes):处理低复用率(冷)提示词,计算新上下文,并将 KV 缓存写入分布式缓存。
  • 预填充节点(Prefill nodes):优先处理高复用率(热)请求,从缓存读取 KV 块,而不是重新计算前缀。
  • 解码节点(Decode nodes):保持对延迟的关注,并与预填充干扰隔离。

预填充和解码已经解耦,但 CPD 增加了一个专门的预填充前层,用于处理几乎没有或没有缓存复用的请求。这些节点计算大型新上下文,并将其 KV 缓存写入分布式缓存。同时,普通的预填充节点专注于可以复用现有状态的请求,从缓存读取 KV 块而不是重新计算它们。解码节点保持隔离和延迟敏感。

在底层,CPD 依赖于一个三级 KV 缓存层级,如图 2 所示。最快的层位于 GPU 内存中,其次是主机 DRAM,以及通过 RDMA 连接的集群范围的分布式缓存。当冷请求被预填充前节点处理时,其 KV 状态被写入分布式缓存。后续的类似请求可以以高带宽批量获取此状态,将原本需要数秒的计算转化为数百毫秒的传输和少量重新计算。随着时间的推移,频繁访问的上下文自然会移动到更靠近 GPU 的位置,进一步缩短延迟。

__wf_reserved_inherit

图 2. 系统概览。

路由器将这一切联系在一起。对于每个请求,它会估算提示词有多少可以从缓存中服务。低复用率的请求被引导至预填充前节点,而高复用率的请求则直接进入普通预填充节点。这种工作负载分离防止了大型冷预填充使共享计算饱和,同时仍允许系统接收新上下文并持续预热缓存。结果是一个服务栈,即使在混合和突发性的长上下文工作负载下,也能保持快速通道的畅通。

重复请求时会发生什么

当相同或相似的长上下文多次出现时——这在助手、智能体和多轮聊天场景中很常见——CPD 的优势就变得很明显。每个请求都将工作负载进一步从计算密集型推向前缀缓存复用。

__wf_reserved_inherit

图 3. 三种请求模式。

请求 1 — 冷(引导)

第一次出现大型上下文时,它被归类为。路由器将其发送到预填充前节点,该节点执行完整的预填充计算。同时,生成的 KV 缓存被写入分布式缓存。

这个请求支付了全部计算成本,但它通过将新上下文转化为可复用状态来启动系统

请求 2 — 热(分布式缓存复用)

当相同上下文再次出现时,路由器现在将其识别为。普通预填充节点通过 RDMA 从分布式缓存获取 KV 块并加载到 GPU 内存中,而不是重新计算前缀。

现在,数秒的计算被高带宽传输和少量处理所取代。延迟急剧下降,GPU 计算压力也随之降低。

请求 3 — 热(本地复用)

如果上下文在同一节点上保持活跃,其 KV 状态可能已经驻留在 GPU 或主机内存中。不需要分布式缓存传输——系统直接复用本地缓存。

此时,预填充的开销变得极小,延迟进一步缩短。最初需要数秒计算的相同 10 万词元上下文,现在可以在几百毫秒内完成服务。此外,CPD 所做的不仅仅是复用前缀——它将重型计算与复用驱动的流量隔离开来,使系统能够扩展长上下文推理,同时不让冷工作负载主导共享资源。

评估

我们从两个互补的维度评估 CPD,这两个维度对于现实负载下的长上下文服务系统至关重要:

  1. 负载增加下的延迟和吞吐量扩展——随着目标 QPS 增加,TTFT(p50 和 p90)和每 GPU 吞吐量如何演变。
  2. 竞争下的有效服务容量——在预填充侧饱和导致延迟急剧膨胀之前,系统每 GPU 能维持多少可持续 QPS。

我们将传统的基于 PD 的部署与 CPD 进行比较,重点关注缓存感知解耦如何重塑混合热冷工作负载下的饱和行为和延迟:

  • 2P1D/2P2D(基线):两个预填充节点和一个或两个解码节点,使用标准的 PD 路由,所有请求共享相同的预填充容量。
  • CPD-1D/2D:一个缓存感知的流水线,包括一个专门的预填充前层、一个普通预填充层和一个或两个解码节点,由区分热冷请求的 CPD 感知路由器协调。

所有实验均在 NVIDIA B200 GPU 上进行。每个预填充阶段在每个节点上使用跨 4 个 B200 GPU 的张量并行,而解码阶段则使用跨 4 个 B200 GPU 的数据并行和注意力分片。我们将最大并发请求数限制在 24,以反映实际的准入控制,并避免无限制的尾部放大。

对于每个目标 QPS,系统在 30 秒内逐步增加流量,然后在 600 秒内维持稳态负载。QPS 从 0.4 到 1.6 以 0.2 为增量进行扫描,以捕获系统从轻负载到饱和的行为。

工作负载配置

为了反映现实的长上下文推理工作负载,我们设计了一个基于编码智能体场景的基准测试,该场景具有大型共享上下文和多轮交互。此工作负载模拟了 AI 辅助软件开发环境,其中智能体在多轮对话中维护大量代码库上下文——读取文件、分析依赖关系、实施更改和迭代修复。使用合成数据,其中包含真实的热冷预填充请求混合,以测试 CPD 的调度决策。

结果

图 4 共同说明了 CPD 如何重塑延迟扩展行为和服务容量,因为系统负载增加。

图 4. 2P1D/2P2D 与 CPD 在目标 QPS 增加下的性能比较。

饱和行为

随着目标 QPS 增加,一旦预填充容量成为主要瓶颈,两个系统开始出现差异。2P1D 基线更早达到饱和,实现的 QPS 在 每 GPU 0.75–0.8 QPS 左右趋于平缓,之后排队延迟迅速增长。相比之下,CPD 在相同工作负载下继续扩展到大约 每 GPU 1.1–1.15 QPS,代表在进入饱和之前可持续吞吐量增加了约 40%

饱和点的右移与图 4(左下)中的吞吐量曲线一致,其中 CPD 在负载增加时保持更高的有效预填充吞吐量。通过将冷预填充与缓存支持的热请求分离,CPD 防止了长时间运行的冷提示词垄断共享预填充容量,使系统能够在更高的提供负载下高效运行。

负载下的延迟

在轻负载下,2P1D 和 CPD 的中位数 TTFT(p50)相当,表明 CPD 在非拥塞状态下没有引入额外开销。然而,随着 QPS 增加到基线的饱和点附近,行为出现显著差异。

对于 2P1D,TTFT p50 急剧上升超过 1 秒,并迅速进入数秒范围,反映了在大型冷预填充后的排队情况。CPD 表现出明显更平缓的增长:即使在基线已经饱和的目标 QPS 水平下,CPD 仍保持亚秒到低秒级的中位数 TTFT,如图 4(左上)所示。这种改进直接源于工作负载隔离——复用缓存上下文的热请求不再被迫等待昂贵的冷预填充执行。

尾部延迟(TTFT p90)显示出更微妙的模式。在中等负载下,两个系统表现出相似的 p90 行为。随着负载进一步增加,两种设计的 p90 TTFT 都会上升,但 CPD 在整个评估范围内始终低于或与基线相当(图 4,右上)。重要的是,CPD 在中位数延迟方面取得了实质性收益,而没有引入不成比例的尾部放大。虽然冷流量的突发仍然会增加预填充前层内的排队,但其影响在很大程度上得到控制,保持了可预测的尾部行为。

吞吐量效率

图 4 中的吞吐量细分突显了这些改进的根本原因。CPD 在高 QPS 下维持了更高的每 GPU 预填充吞吐量,而基线的预填充吞吐量则趋于平缓,然后随着排队加剧而下降。生成吞吐量在两个系统之间大致相当,表明观察到的性能差异主要是由更高效的预填充调度驱动,而不是解码侧的优化。

关键结果与讨论

图 4 显示,CPD 改变了混合热冷工作负载下长上下文服务的运行点。将解码容量从 1D 增加到 2D 提高了整体吞吐量,并延迟了基线和 CPD 配置的饱和,这证实了解码侧并行性有助于提高服务容量。

重要的是,即使解码容量扩展,CPD 仍能持续提供一致的改进。在 1D 和 2D 设置下,与相应的基线相比,CPD 维持了更高的每 GPU 有效 QPS,并表现出更平缓的中位数 TTFT 增长。此外,CPD 保持相当或更高的解码吞吐量,表明其优势不仅限于预填充隔离,还延伸到了更高效的端到端流水线利用率。

这些改进并非由原始模型执行速度驱动,而是由预填充路径上的缓存感知隔离驱动。通过防止长时间运行的冷预填充阻塞缓存支持的热请求,CPD 即使在重负载下也为复用保留了快速通道。这突显了随着上下文窗口的增长,系统级调度和复用感知设计已成为推理性能的一阶因素,与模型和硬件效率同等重要。

觉得有用?分享给更多人

获取每周 AI 工具精选

工具推荐、实战教程和生态洞察,每周更新。

相关文章

Simon Willison 正在重构 LLM Python 库的抽象层,以支持服务器端工具执行等新功能。他利用 Claude Code 分析了四大 LLM 提供商的客户端库,生成了用于测试的 curl 命令和 JSON 输出。这些调研材料已开源,旨在帮助设计更通用的 API 抽象。

深度Simon Willison·4月5日·1 分钟

智能体技能——包含程序性知识和可执行资源的结构化包,供智能体在推理时动态加载——已成为增强 LLM 智能体的可靠机制。然而,推理时技能增强存在根本性限制:检索噪声引入无关指导,注入的技能内容带来大量 token 开销,而模型从未真正习得它所遵循的知识。我们提出一个问题:技能是否可以被内化到模型参数中,使其在无需任何运行时技能检索的情况下实现零样本自主行为?我们提出 Skill0,一个专为技能内化设计的上下文强化学习框架。Skill0 引入了一种训练时课程,从提供完整技能上下文开始,逐步撤除。技能按类别离线分组,并与交互历史一起渲染为紧凑的视觉上下文,教授模型工具调用和多轮任务完成。动态课程机制…

深度·4月5日·17 分钟

评论