“接力跑”盘活全国算力,PD分离终于破局:延迟砍半、成本直降近40%!

AITNT-国内领先的一站式人工智能新闻资讯网站
# 热门搜索 #
“接力跑”盘活全国算力,PD分离终于破局:延迟砍半、成本直降近40%!
5198点击    2026-07-30 15:57

在刚刚落幕的2026 WAIC世界人工智能大会上,无问芯穹首次公布了其在大模型推理系统架构中的新突破——跨集群异构推理架构PDD


现在,完整技术报告来了


“接力跑”盘活全国算力,PD分离终于破局:延迟砍半、成本直降近40%!


技术报告地址: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%的性能。


“接力跑”盘活全国算力,PD分离终于破局:延迟砍半、成本直降近40%!不同硬件在预填充和解码阶段的性能测试结果


如果把这类“偏科”芯片放在同构集群里,既要扛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%之多,成为了最主要的性能瓶颈


“接力跑”盘活全国算力,PD分离终于破局:延迟砍半、成本直降近40%!请求输出长度分布


“接力跑”盘活全国算力,PD分离终于破局:延迟砍半、成本直降近40%!KV传输时长在端到端延迟中的占比


尽管降低跨集群KV Cache传输延迟的重要性目前已经十分明确,但是对于这1~20s延迟的具体来源及分布,我们仍然一无所知。


为了探寻延迟的真实分布,首先需要了解输入请求的实际情况:平均90%的缓存命中率,背后的具体命中率分布是什么样的?


在拉取了真实的业务Trace进行分析后我们发现:输入请求的命中率分布是极度偏斜的。


大概70%-80%的请求,命中率都在95%以上;只有极少部分的低命中率请求,才会携带巨大的KV Cache数据包。


“接力跑”盘活全国算力,PD分离终于破局:延迟砍半、成本直降近40%!实际业务Trace中请求命中率的分布规律


随后,无问芯穹团队在20Gbps的跨集群专线上做了微基准测试,对比了“真实偏斜分布”和“均匀分布(85%-95%命中率)”的传输表现,结果令人震惊:


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


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


“接力跑”盘活全国算力,PD分离终于破局:延迟砍半、成本直降近40%!命中率分布对传输延迟的影响(RPS=80,平均命中率=90%,20Gbps广域以太网)


这个发现极为关键:极端传输延迟只集中在极少数低命中率的“刺头请求”上


偏斜分布下,大量轻量级请求利用了TCP的公平性机制,不会被高负载请求阻塞,并且迅速地释放了连接池。


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


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


基于上述洞察,无问芯穹提出了PDD(Prefill-RelayDecode-MainDecode)架构。


传统的PD分离只有Prefill(P)和Decode(D)两层,而无问芯穹团队在中间插入了一个“中继站”——RelayDecode(RLD)实例


正是这个中继实例,起到了掩盖以太网KV Cache传输延迟的作用。


“接力跑”盘活全国算力,PD分离终于破局:延迟砍半、成本直降近40%!PDD总体架构解析图


整个系统被分成了三层:


  • P实例:位于主集群,负责处理输入Prompt,生成KV Cache。
  • RLD实例:和P实例在同一个集群,通过高速RDMA网络互联(KV传输延迟仅几十毫秒)。
  • 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算力,去精准掩盖跨集群那极少数低命中率请求的网络延迟


核心机制解析:如何优雅地完成“接力棒交接”?


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


传统的做法是,RLD一边解码,一边把新生成的“增量KV Cache”通过以太网传给MD。


但这又掉进了跨域网络传输延迟的坑里,而且还要经过繁琐的H2D/D2H(显存到内存、内存到显存)拷贝,延迟高且不稳定。


“接力跑”盘活全国算力,PD分离终于破局:延迟砍半、成本直降近40%!

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分离别无二致。


流水线编排:如何使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的负载过高而崩溃。


“接力跑”盘活全国算力,PD分离终于破局:延迟砍半、成本直降近40%!使用P-RLD流水线导致的恶性正反馈循环现象


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


架构设计得再精巧,最终都要在真实业务的压力下见真章。


因此,团队在DeepSeek-V4-pro模型上,使用真实的Agentic工作负载Trace,对PDD架构进行了一次全方位的测试。


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


  • CDC-PD(跨集群、异构芯片的PD分离):同样跨中心传输,使用DRC降低传输量,但不使用RLD延迟掩盖机制。
  • 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秒。


“接力跑”盘活全国算力,PD分离终于破局:延迟砍半、成本直降近40%!PDD和CDC-PD之间的TTFT对比


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


团队非常关注RLD实例会不会成为系统的瓶颈。


实测数据打消了这一疑虑:在真实流量下,RLD实例仅仅承担了系统6.2%的Token生成任务(约27万个Token),而远端MD实例包揽了93.8%的重活(约412万个Token),两者负载差异高达15.2倍。


“接力跑”盘活全国算力,PD分离终于破局:延迟砍半、成本直降近40%!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%。


“接力跑”盘活全国算力,PD分离终于破局:延迟砍半、成本直降近40%!资源的单位价格说明


“接力跑”盘活全国算力,PD分离终于破局:延迟砍半、成本直降近40%!实际达到的延迟指标


“接力跑”盘活全国算力,PD分离终于破局:延迟砍半、成本直降近40%!IDC-PD与PDD的BCR对比(64K上下文,90%命中率,符合SLA的有效吞吐量)


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


受限于测试资源,无问芯穹的RLD使用了3个某旗舰高性能GPU A节点(这是以DP并行方式跑通DeepSeek-V4-pro的最小规模)。


如果在更大规模的部署中,RLD的固定开销将被进一步摊薄;


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


此外,因为与DRC存在暂时的兼容性问题,这一实验中并未开启某些关键优化机制,比如MTP。


在开启了这些优化机制之后,异构的性价比还有进一步提升的空间。


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


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


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


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


多种多样的异构算力可以零散、低成本地分散在多个集群,而这些集群之间通过可扩展性极强的跨域以太网构成具有“多对一”、“多对多”在内的复杂拓扑的推理基建。


在面对因模型迭代、PD配比变化而带来的资源闲置问题时,这种“极简局部异构+灵活远端分离”的跨集群范式,也能大幅盘活存量算力,压低资源空置比例。


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


“接力跑”盘活全国算力,PD分离终于破局:延迟砍半、成本直降近40%!传统的同数据中心异构集群


“接力跑”盘活全国算力,PD分离终于破局:延迟砍半、成本直降近40%!PDD的极简局部异构+灵活远端分离部署方案


这一技术突破的背后,是无问芯穹推理团队日夜奋战的成果。


大模型的规模化落地是一场漫长的技术长跑,无问芯穹也会继续在系统架构的深水区持续探索、向前突破。


欢迎大家阅读英文技术报告原文,也期待在评论区与各位技术同好交流探讨。


论文地址:https://github.com/infinigence/pdd


文章来自于"量子位",作者 "允中"。

AI转型,免费服务,就找AITNT
AITNT资源拓展
根据文章内容,系统为您匹配了更有价值的资源信息。内容由AI生成,仅供参考
1
AI代理

【开源免费】Browser-use 是一个用户AI代理直接可以控制浏览器的工具。它能够让AI 自动执行浏览器中的各种任务,如比较价格、添加购物车、回复各种社交媒体等。

项目地址:https://github.com/browser-use/browser-use


2
智能体

【开源免费】AutoGPT是一个允许用户创建和运行智能体的(AI Agents)项目。用户创建的智能体能够自动执行各种任务,从而让AI有步骤的去解决实际问题。

项目地址:https://github.com/Significant-Gravitas/AutoGPT


【开源免费】MetaGPT是一个“软件开发公司”的智能体项目,只需要输入一句话的老板需求,MetaGPT即可输出用户故事 / 竞品分析 / 需求 / 数据结构 / APIs / 文件等软件开发的相关内容。MetaGPT内置了各种AI角色,包括产品经理 / 架构师 / 项目经理 / 工程师,MetaGPT提供了一个精心调配的软件公司研发全过程的SOP。

项目地址:https://github.com/geekan/MetaGPT/blob/main/docs/README_CN.md

3
知识库

【开源免费】FASTGPT是基于LLM的知识库开源项目,提供开箱即用的数据处理、模型调用等能力。整体功能和“Dify”“RAGFlow”项目类似。很多接入微信,飞书的AI项目都基于该项目二次开发。

项目地址:https://github.com/labring/FastGPT

4
prompt

【开源免费】LangGPT 是一个通过结构化和模板化的方法,编写高质量的AI提示词的开源项目。它可以让任何非专业的用户轻松创建高水平的提示词,进而高质量的帮助用户通过AI解决问题。

项目地址:https://github.com/langgptai/LangGPT/blob/main/README_zh.md

在线使用:https://kimi.moonshot.cn/kimiplus/conpg00t7lagbbsfqkq0