最新完整技术报告出炉
在刚刚落幕的2026 WAIC世界人工智能大会上，无问芯穹首次公布了其在大模型推理系统架构中的新突破—— 跨集群异构推理架构PDD。
现在， 完整技术报告 来了。
技术报告地址：https://github.com/infinigence/pdd
该架构以高性价比的广域网以太网串联多地已建成的同构数据中心，并将传统的PD分离链路“P-D”创新解构为“P-RLD-MD”的三级分离式推理架构。
在让“偏科”的硬件能够只刷自己最擅长的题的同时，更突破性解决了以太网环境下KV Cache的传输延迟痛点。
实测数据显示，该架构在实现了首Token 延迟降低51.5% 的同时，单Token 成本可降低37.5% 。
这不仅意味着用户端速度体验得到了显著提升，更实现了全域异构算力的最大化调度，让分散各处的存量集群资源能够充分释放产业价值。
今天，无问芯穹推理团队将首次分享这一架构的设计推演全貌，深度还原技术创新背后的思考路径与攻坚细节。
跨集群异构推理的理想与现实
过去的一年里，大模型推理的成本和效率，成为了整个行业共同面对的“生死线”。
行业共识在于：LLM的推理存在Prefill（预填充，计算密集型）和Decode（解码，访存密集型）两个特性迥异的阶段。
理论上的最理想的解法是 “异构分离”路线：让算力强的卡负责Prefill，让显存带宽高的卡负责Decode。
但现实是骨感的。
要在同一个集群里构建大规模异构算力资源，不仅采购成本极其高昂，且一旦模型架构变了，这些固定配比的硬件就会很容易出现部分闲置的情况。
于是，一个很自然的想法冒了出来：
为什么不把分布在各地的、已经建好的同构集群，用低成本的广域网以太网连起来，做跨集群的异构分离式推理呢？
这一想法看似水到渠成，但一旦将其落到具体工程实践中，便立刻撞上了一堵“叹息之墙”—— KV Cache的跨集群传输带宽和延迟瓶颈 。
PDD架构也正是为了攻克这一难题而设计的。
但在深入这一架构的设计与实现细节之前，想先与大家分享无问芯穹团队在前期研究中发现的几个极其关键的 “底层规律” ，它们也是整个跨集群PD方案能够成立的核心前提。
痛点与洞察：硬件“偏科”与流量的“二八定律”
要理解PDD的设计，得从无问芯穹在PDD技术报告中Background部分揭示的三个核心Insights入手。
洞察1：硬件性能的“极度偏科”
LLM推理的Prefill与Decode两个阶段对硬件资源的需求是南辕北辙的，无问芯穹团队在内部基准测试中也发现，芯片的性能是极度“偏科”的：
以8卡的某旗舰高性能GPU为基线，某厂商的E芯片在处理计算密集的Prefill阶段时，只能达到基线约81%的性能；但在访存密集的Decode阶段，它却能爆发出基线 210% 的性能。
如果把这类“偏科”芯片放在同构集群里，既要扛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%之多，成为了最主要的性能瓶颈 。
尽管降低跨集群KV Cache传输延迟的重要性目前已经十分明确，但是对于这1~20s延迟的具体来源及分布，我们仍然一无所知。
为了探寻延迟的真实分布，首先需要了解输入请求的实际情况： 平均90%的缓存命中率，背后的具体命中率分布是什么样的？
在拉取了真实的业务Trace进行分析后我们发现：输入请求的命中率分布是 极度偏斜 的。
大概70%-80%的请求，命中率都在95%以上；只有极少部分的低命中率请求，才会携带巨大的KV Cache数据包。
随后，无问芯穹团队在20Gbps的跨集群专线上做了微基准测试，对比了“真实偏斜分布”和“均匀分布（85%-95%命中率）”的传输表现，结果令人震惊：
真实偏斜分布下，P50传输延迟极低（仅248ms），只有极少数低命中率请求会出现18秒以上的长尾延迟。
而在均匀分布下，所有请求都具有中等大小的数据包，导致网络连接池瞬间被打满（利用率100%），引发严重的排队阻塞，P50延迟飙升到1210ms，全面崩盘。而这还没把因为连接池耗尽而产生的平均1682ms的排队时长算在内。
这个发现极为关键： 极端传输延迟只集中在极少数低命中率的“刺头请求”上 。
偏斜分布下，大量轻量级请求利用了TCP的公平性机制，不会被高负载请求阻塞，并且迅速地释放了连接池。
这说明了，想要解决跨集群PD传输KV Cache的延迟瓶颈，不需要全局去解决网络延迟，只要针对这少部分“刺头”做优化即可。
创新解法：PDD三层架构与“中继接力”跑法
基于上述洞察，无问芯穹提出了PDD（Prefill-RelayDecode-MainDecode）架构。
传统的PD分离只有Prefill（P）和Decode（D）两层，而无问芯穹团队在中间插入了一个“中继站”—— RelayDecode（RLD）实例 。
正是这个中继实例，起到了掩盖以太网KV Cache传输延迟的作用。
整个系统被分成了三层：
- P实例 ：位于主集群，负责处理输入Prompt，生成KV Cache。
- RLD实例 ：和P实例在 同一个集群 ，通过高速RDMA网络互联（KV传输延迟仅几十毫秒）。
- MainDecode实例（MD实例） ：位于遥远的外地集群，通过广域网以太网和主集群相连（KV传输延迟数秒及以上）。
它是怎么工作的呢？
可以把它想象成一场2×100米接力赛：
当P实例算完Prefill后，它会同时干两件事：
第一，通过高速RDMA网络，把KV Cache“瞬间”传给同机房的RLD实例；
第二，通过慢速且延迟不稳定的以太网，把KV Cache传给外地的MD实例。
RLD实例拿到KV Cache后， 立刻开始解码，输出Token给用户 。
此时，用户根本感觉不到跨集群的KV传输延迟，已经开始看到字了。而在后台，以太网可能还在传输。
几秒钟过后，MD实例终于收到了完整的KV Cache，解码任务就会无缝从RLD交接给MD，由MD完成后续大部分的吐字工作。
这就是PDD的核心思想： 用本地的RLD算力，去精准掩盖跨集群那极少数低命中率请求的网络延迟 。
核心机制解析：如何优雅地完成“接力棒交接”？
PDD的三级架构听起来简单，但最大的工程难题在于： 当MD实例准备好后，如何把RLD正在进行的解码任务无缝接管过来？
传统的做法是，RLD一边解码，一边把新生成的“增量KV Cache”通过以太网传给MD。
但这又掉进了跨域网络传输延迟的坑里，而且还要经过繁琐的H2D/D2H（显存到内存、内存到显存）拷贝，延迟高且不稳定。
于是，无问芯穹提出了一个反直觉但极其高效的机制： 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分离别无二致。
流水线编排：如何使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端保持一致 。
← 返回最新