突破跨集群异构推理瓶颈：无问芯穹PDD架构如何用“中继接力”破解KV Cache传输难题？

在刚刚落幕的2026 WAIC 世界人工智能大会上，无问芯穹首次公布了在大模型推理系统架构中的新突破——跨集群异构推理架构PDD（Prefill-RelayDecode-MainDecode）。该架构以高性价比的广域网以太网串联多地已建成的同构数据中心，并将传统的 PD 分离链路“P-D”创新解构为“P-RLD-MD”的三级分离式推理架构。在让“偏科”的硬件能够只刷自己最擅长的题的同时，更突破性解决了以太网环境下 KV Cache 的传输延迟痛点。

实测显示，该架构在实现了首 Token 延迟降低 51.5% 的同时，单 Token 成本可降低 37.5%。不仅意味着用户端速度体验得到显著提升，更实现了全域异构算力的最大化调度，让分散各处的存量集群资源能够充分释放产业价值。

今天，无问芯穹推理团队将首次分享这一架构的设计推演全貌，深度还原技术创新背后的思考路径与攻坚细节。

技术报告：https://github.com/infinigence/pdd

过去的一年里，大模型推理的成本和效率，成为了整个行业共同面对的“生死线”。行业共识在于：LLM 的推理存在 Prefill（预填充，计算密集型）和 Decode（解码，访存密集型）两个特性迥异的阶段。理论上的最理想的解法是“异构分离”路线：让算力强的卡负责 Prefill，让显存带宽高的卡负责 Decode。

但现实是骨感的。要在同一个集群里构建大规模异构算力资源，不仅采购成本极其高昂，且一旦模型架构变了，这些固定配比的硬件就会很容易出现部分闲置的情况。

于是，一个很自然的想法冒了出来：为什么不把分布在各地的、已经建好的同构集群，用低成本的广域网以太网连起来，做跨集群的异构分离式推理呢？

这一想法看似水到渠成，但一旦将其落到具体工程实践中，便立刻撞上了一堵“叹息之墙”——KV Cache 的跨集群传输带宽和延迟瓶颈。

PDD 架构也正是为了攻克这一难题而设计的。但在深入这一架构的设计与实现细节之前，想先与大家分享我们在前期研究中发现的几个极其关键的“底层规律”，它们也是整个跨集群 PD 方案能够成立的核心前提。

01 痛点与洞察：硬件“偏科”与流量的“二八定律”

要理解 PDD 的设计，得从无问芯穹在 PDD 技术报告中 Background 部分揭示的三个核心 Insights 入手。

洞察1：硬件性能的“极度偏科”

LLM 推理的 Prefill 与 Decode 两个阶段对硬件资源的需求是南辕北辙的，我们在内部基准测试中也发现，芯片的性能是极度“偏科”的：以 8 卡的某旗舰高性能 GPU 为基线，某厂商的 E 芯片在处理计算密集的 Prefill 阶段时，只能达到基线约 81% 的性能；但在访存密集的 Decode 阶段，它却能爆发出基线 210% 的性能。

表1：不同硬件在预填充和解码阶段的性能测试结果

如果把这类 “偏科” 芯片放在同构集群里，既要扛 Prefill 计算又要做 Decode 输出，非但自身的长板优势无从发挥，反而会拖慢 Prefill 阶段的整体效率。

这一发现强烈激发了我们将 Prefill 与 Decode 拆分解耦、分别部署在最适合它们的硬件上这一想法。

洞察2：DRC 技术带来的 10 倍“带宽”

仅仅考虑计算和访存还不够，跨集群传输庞大的 KV Cache 会瞬间吃掉广域网的带宽。但好在 Agent 业务有个显著的特征：前缀缓存命中率极高。我们利用这一特性，在 Decode 端部署了前缀缓存 RadixCache（简称DRC）。

简单来说，DRC 会在 Decode 实例上缓存历史请求的 KV Cache。当 Prefill 端发现某个请求命中了前缀缓存，它就不需要把整个上下文的 KV Cache 全量传过去，只需要传那一点点“增量”即可。在 90% 的平均命中率下，DRC 理论上能将跨集群的带宽需求降低高达 10 倍，初步缓解了带宽瓶颈。

然而，带宽虽然降下来了，延迟问题却依然棘手。

洞察3：智能体工作负载下的“非均匀延迟”

在 DRC 技术的加持之下， KV Cache 传输数据量得以降低了一个数量级，于是，跨集群 PD 分离最棘手的痛点，集中在了 KV Cache 的传输延迟。

智能体工作负载特征有“三极”：上下文极长（动辄64K）、缓存命中率极高（平均90%）、但输出极短（经常不到100个Token）。用户发个请求，整个输出过程也不过十几秒，但是首字延迟却要等几十秒，产品体验直接被宣判死刑。也正因如此，优化跨集群 KV Cache 的传输延迟，成为了必须突破的核心关卡。

如下图所示，我们分析了线上真实业务的 600 万条请求，其中 30% 左右的请求输出的 Token 个数少于 100 个，40% 左右的请求输出不超过 500 个Token。而对于这些请求来说，1~20s 的 KV Cache 传输占了其端到端总延迟（e2el）的 43%~56% 之多，成为了最主要的性能瓶颈。

图1：请求输出长度分布

图2：KV传输时长在端到端延迟中的占比

尽管降低跨集群 KV Cache 传输延迟的重要性目前已经十分明确，但是对于这 1~20s 延迟的具体来源及分布，我们仍然一无所知。为了探寻延迟的真实分布，我们首先要了解输入请求的实际情况：平均 90% 的缓存命中率，背后的具体命中率分布是什么样的？

在拉取了真实的业务 Trace 进行分析后我们发现：输入请求的命中率分布是极度偏斜的。大概 70%-80% 的请求，命中率都在 95% 以上；只有极少部分的低命中率请求，才会携带巨大的 KV Cache 数据包。

图3：实际业务Trace中请求命中率的分布规律

随后，我们在 20Gbps 的跨集群专线上做了微基准测试，对比了“真实偏斜分布”和“均匀分布（85%-95%命中率）”的传输表现，结果令人震惊：

真实偏斜分布下，P50 传输延迟极低（仅 248 ms），只有极少数低命中率请求会出现18秒以上的长尾延迟。

而在均匀分布下，所有请求都具有中等大小的数据包，导致网络连接池瞬间被打满（利用率 100%），引发严重的排队阻塞，P50 延迟飙升到 1210 ms，全面崩盘。而这还没把因为连接池耗尽而产生的平均 1682 ms 的排队时长算在内。

undefined

表2：命中率分布对传输延迟的影响（RPS=80，平均命中率=90%，20Gbps广域以太网）

这个发现极为关键：极端传输延迟只集中在极少数低命中率的“刺头请求”上。 偏斜分布下，大量轻量级请求利用了 TCP 的公平性机制，不会被高负载请求阻塞，并且迅速地释放了连接池。

这告诉我们，想要解决跨集群 PD 传输 KV Cache 的延迟瓶颈，不需要全局去解决网络延迟，只要针对这少部分“刺头”做优化即可。

02 创新解法：PDD 三层架构与“中继接力”跑法

基于上述洞察，无问芯穹提出了 PDD（Prefill-RelayDecode-MainDecode）架构。传统的 PD 分离只有 Prefill（P）和Decode（D）两层，而我们在中间插入了一个“中继站”——RelayDecode（RLD）实例。正是这个中继实例，起到了掩盖以太网 KV Cache 传输延迟的作用。

图4：PDD总体架构解析图

整个系统被分成了三层：
1. P 实例：位于主集群，负责处理输入 Prompt，生成 KV Cache。

2. RLD 实例：和P实例在同一个集群，通过高速 RDMA 网络互联（KV 传输延迟仅几十毫秒）。

3. MainDecode 实例（MD 实例）：位于遥远的外地集群，通过广域网以太网和主集群相连（KV传输延迟数秒及以上）。

它是怎么工作的呢？可以把它想象成一场 2x100 米接力赛：

当 P 实例算完 Prefill 后，它会同时干两件事：第一，通过高速 RDMA 网络，把 KV Cache“瞬间”传给同机房的 RLD 实例；第二，通过慢速且延迟不稳定的以太网，把 KV Cache 传给外地的 MD 实例。

RLD 实例拿到 KV Cache 后，立刻开始解码，输出 Token 给用户。此时，用户根本感觉不到跨集群的 KV 传输延迟，已经开始看到字了。而在后台，以太网可能还在传输。几秒钟过后，MD 实例终于收到了完整的 KV Cache，解码任务就会无缝从 RLD 交接给 MD，由 MD 完成后续大部分的吐字工作。

这就是 PDD 的核心思想：用本地的 RLD 算力，去精准掩盖跨集群那极少数低命中率请求的网络延迟。

03 核心机制解析：如何优雅地完成“接力棒交接”？

PDD 的三级架构听起来简单，但最大的工程难题在于：当 MD 实例准备好后，如何把 RLD 正在进行的解码任务无缝接管过来？

传统的做法是，RLD 一边解码，一边把新生成的“增量 KV Cache”通过以太网传给 MD。但这又掉进了跨域网络传输延迟的坑里，而且还要经过繁琐的 H2D/D2H（显存到内存、内存到显存）拷贝，延迟高且不稳定。

图5：PDD中使用的两种不同交接模式——一次性交接和追赶式交接

于是，无问芯穹提出了一个反直觉但极其高效的机制：Extend-Decode Handoff（扩展解码交接）。其做法是：RLD 绝对不传庞大的 KV Cache，它只把生成的“Token ID”传给MD。 传输几个 Token ID 仅仅是几 KB 的数据量，网络开销几乎为零。

MD 收到这些 Token ID 后，利用一种叫做“Extend-Decode”（常见于MTP多Token预测和投机解码）的技术，在本地重新计算这些 Token 对应的 KV Cache，同时生成下一个新 Token。

有人可能会问：重算难道不慢吗？

这里又有个反直觉的硬件原理：Decode 阶段是访存密集型的，计算其实非常轻量。我们在 MD 端重算 100 个 Token 的 KV Cache，平均耗时仅为 305.2ms，最大延迟被死死锁在 321.4ms，标准差极小（仅4.8ms）。而对于更少的 Token 的重计算，其平均耗时会更低，甚至基本和单个 Token 的解码时间一致，这也是MTP 以及投机解码等机制能加速解码阶段的基本工作原理。

而如果走传统的以太网传 KV Cache，平均要 185.4ms，一旦网络拥堵，峰值能飙升到 512.6ms，标准差高达 96.3ms，还额外增加 24.5ms 的 H2D/D2H 开销没算在内，这还没计算在实际运行中它很有可能面临的额外排队延迟。

通过这种“只传 Token，本地重算”的方式，我们把一个受网络波动影响极大、不可控的操作，变成了一个确定性的、可预测的本地计算操作。

为了平衡用户体验和 RLD 负载，我们还设计了“追赶式”和“一次性”两种交接模式，可以根据系统的实时负载动态切换。如果使用了追赶式的交接模式，PDD 会以略微更大的 RLD 负载，保证用户的首字延迟（TTFT）和每秒输出 Token 数（OTPS）体验都和同集群 PD 分离别无二致。

04 流水线编排：如何使 RLD 不成为系统瓶颈？

RLD 虽然好，但它毕竟占用了宝贵的算力。因此，我们的原则是：RLD 只负责“掩藏延迟”，只给它极少数的计算资源，绝对不能让它干重活。

基于之前发现的“命中率极度偏斜”规律，我们设计了两种不同的流水线编排方式：

P-MD 流水线：对于命中率>95%的高频请求（占70%+），因为数据包极小，直接走以太网传给 MD，根本不需要RLD 中继。

P-RLD-MD 流水线：只有那些命中率低、数据包大、传输必然卡顿的“刺头请求”，才送去 RLD 进行延迟掩盖。

这种设计排除了 P-RLD 这种编排方式，有效地保证了 RLD 不被压垮。在我们的实测中，RLD 只承担了系统 6.2% 的Token 生成任务，而 93.8% 的重活都被 MD 包揽了。

此外，很关键的一点是它还保证了 MD 端的缓存命中率始终和 P 端保持一致。这种一致性又进一步保证了 RLD 的负载稳定地处于低位。

否则如下图所示，将请求的生命周期终结于RLD，会导致一种恶性正反馈循环的产生，最终导致 RLD 的负载过高而崩溃。

图6：使用P-RLD流水线导致的恶性正反馈循环现象

05 实战成绩单：降本增效的终极证明

架构设计得再精巧，最终都要在真实业务的压力下见真章。因此，我们在 DeepSeek-V4-pro 模型上，使用真实的 Agentic 工作负载 Trace，对 PDD 架构进行了一次全方位的测试。

为了公平对比，这里设定了两种不同的基线：

1. CDC-PD（跨集群、异构芯片的 PD 分离）：同样跨中心传输，使用 DRC 降低传输量，但不使用 RLD 延迟掩盖机制。

2. IDC-PD（单机房、同构芯片的 PD 分离部署方案）：传统的某旗舰高性能 GPU 单机房集群，P 和 D 完全同构且都在同一个RDMA网络域内。

实测结果不仅验证了我们的理论，甚至超出了最初的预期，主要表现在三个维度：

延迟表现：“网络延迟”的几近 100% 掩藏

在跨集群场景下，传统的 PD 分离架构中用户感受到的 TTFT 受制于广域网以太网的传输延迟。由于网络拥堵以及部分低命中率请求带来的高传输负载，TTFT 的 P90 延迟飙升至 18.3 秒，P99 甚至逼近 30 秒。

而 PDD 架构成功将这部分传输延迟掩盖在了 RLD 的抢先输出阶段。由于 RLD 通过同机房 RDMA 拿到 KV Cache 后立刻开始吐字，用户感知不到后台以太网那几秒钟到十几秒钟的慢速传输。最终，PDD 的 P90 TTFT降低了约 46%（从 18.3 秒降到 9.8 秒），P99 也从 29.7 秒降至 14.4 秒。

表3：PDD和CDC-PD之间的TTFT对比

负载分布：中继站“只藏延迟不干重活”

我们非常关注 RLD 实例会不会成为系统的瓶颈。实测数据打消了这一疑虑：在真实流量下，RLD 实例仅仅承担了系统 6.2% 的 Token 生成任务（约 27 万个 Token），而远端 MD 实例包揽了 93.8% 的重活（约 412 万个 Token），两者负载差异高达 15.2 倍。

图7：64K输入，90%命中率，1K输出下测试得到RLD和MD之间的负载比例

这证明了我们的路由策略的有效性：绝大多数高命中率请求直接通过 P-MD 管线快速通过，只有那些携带庞大 KV Cache 的“刺头请求”才借用 RLD 的算力缓冲一下，且这些请求在完成 KV Cache 传输后迅速把后续的解码任务交接给远端的MD实例，不会任由长输出请求无限期占用自己的计算和存储资源。

性价比：用更少的钱，跑出更高的有效吞吐

这是最重要的结果，直接展现了使用 PDD 架构带来的有效吞吐（Goodput）提升效果，证明了 PDD 的实际生产价值。我们将 PDD 与传统的“单机房同构某旗舰高性能 GPU 集群（IDC-PD）”进行了成本收益核算对比。

在 PDD 部署中，我们在以某旗舰高性能 GPU A 为核心算力的主机房部署 P 实例和极小部分的 RLD 实例，在以某旗舰高性能 GPU B 为核心算力的远端机房部署 MD 实例。在严格的 TTFT 约束下（P90 TTFT < 10s，P99 TTFT < 15s），结果显示：PDD 在总成本下降约 3.5%~7.1% 的前提下，请求的有效吞吐量（RPS Goodput）反而提升了 27.8%，最终使得性价比（Benefit-Cost Ratio，BCR）提升了高达 37.5%！

表4：资源的单位价格说明

表5：实际达到的延迟指标

表6：IDC-PD 与 PDD 的 BCR 对比（64K 上下文，90% 命中率，符合 SLA 的有效吞吐量）

需要特别指出的是，这个结果还不是 PDD 的极限。

受限于测试资源，我们的 RLD 使用了 3 个某旗舰高性能 GPU A 节点（这是以 DP 并行方式跑通 DeepSeek-V4-pro 的最小规模）。如果在更大规模的部署中，RLD 的固定开销将被进一步摊薄；

并且，如果我们引入比某旗舰高性能 GPU B 更极致的专用推理芯片，性价比还将拥有巨大的提升空间。

此外，因为与 DRC 存在暂时的兼容性问题，我们的实验中并未开启某些关键优化机制，比如 MTP。在开启了这些优化机制之后，异构的性价比还有进一步提升的空间。

06 写在最后：未来 MaaS 基础设施的畅想

PDD 架构不仅仅是一个跨域以太网传输延迟优化技巧，它也承载着我们对下一代模型即服务（Model-as-a-Service，MaaS）基础设施的核心设计理念与底层判断——极简局部异构 + 灵活远端分离。

未来，我们不需要在同一个机房里堆砌庞杂的异构芯片，只需要在主算力中心保留极小比例的“接力手”，就能像云原生调度资源一样，把庞大的解码任务分发到全国乃至全球的低成本算力节点上。

这为下一代大模型推理基础设施，勾勒出了一幅极具弹性和经济性的蓝图。

多种多样的异构算力可以零散、低成本地分散在多个集群，而这些集群之间通过可扩展性极强的跨域以太网构成具有“多对一”、“多对多”在内的复杂拓扑的推理基建。在面对因模型迭代、PD 配比变化而带来的资源闲置问题时，这种 “极简局部异构 + 灵活远端分离” 的跨集群范式，也能大幅盘活存量算力，压低资源空置比例。

最终，每一块芯片都能被利用起来做自己擅长的工作，全域内的异构算力都将被最大化地释放产业价值。