无问芯穹 PDD 跨集群异构推理架构完全拆解：三级流水线怎么把 TTFT 砍半、Token 成本再降近四成

本文由 莫潇羽@无忆研习社（www.wuyi.wiki）撰写，转载请注明出处。

快速摘要

如果你只有三分钟，这篇文章要讲的是无问芯穹在 2026 世界人工智能大会上发布的一个新架构 —— PDD（Prefill-RelayDecode-MainDecode）。它把传统的"P-D 两级"推理拆成了"P-RLD-MD 三级"，用一个位于主机房的"中继解码"实例作为跳板，把跨集群以太网上那几秒到十几秒的 KV Cache 传输延迟藏了起来。

实测数据是这样的：在 DeepSeek-V4-pro 模型加真实 Agent 工作负载 Trace 下，PDD 让首字延迟（TTFT）的 P90 从 18.3 秒降到 9.8 秒，降幅约 46%；P99 更是从 29.7 秒降到 14.4 秒，降幅约 51.5%（外部报道里经常引用的就是这个 P99 数字，读的时候留意一下口径）。总成本下降约 3.5% 到 7.1%；有效吞吐量（Goodput）提升 27.8%；综合下来性价比指标（BCR）拉高了 37.5%。

核心机制我可以用一句话概括：让"偏科"的芯片只干自己擅长的事，用本地 RLD 抢跑首字，靠一个反直觉的"只传 Token ID、本地重算 KV Cache"的接力方式把长途传输的锅背走。

想看完整拆解，往下翻 —— 从原理、数据、架构图到工程细节，这篇长文都会说清楚。

本文写作时参考了无问芯穹官方公开的技术资料与 WAIC 2026 的公开报道，技术数据以论文原文（https://github.com/infinigence/pdd）为准。

一、Token 工厂里的"生死线"：为什么这套架构不得不出现

大模型推理这一年，行业的情绪写在脸上：谁能把 Token 成本再压一位数，谁就能活得更从容。

从 ChatGPT 引爆行业开始，我们习惯了看模型能力的排行榜。但真正上过生产的同学都懂，能力这条线是天花板，成本这条线才是"地板"。地板往下塌，产品端各种花活儿就展不开 —— 限速、限量、限并发，最后掏出账单一看，服务费吃掉了利润的绝大部分。

我自己折腾 Agentic 应用的时候有过一次亲身感受：一个用来跑客服助手的原型，在几个月的迭代里模型换了三代、上下文越拉越长。一开始只是几毛钱一次对话，后面动辄小几块。等接入了多轮反思、工具调用之后，单次会话的 Token 消耗直接翻了一个数量级。那种感觉就像开了一辆越换越快的车，但油表上的针也在越走越猛。

1.1 Agent 时代来了，Token 消耗曲线陡到吓人

传统对话场景的用户是"人"，一个问题几百个字，回答几百字，节奏是慢的、间歇的。

Agent 时代不一样。一个自主智能体一旦跑起来，它自己就是一个疯狂的 Token 消费大户：读一份长文档，几万 Token；调用工具、拿到工具返回结果，又几千 Token；反思、复盘、多轮迭代，Token 消耗再叠一层。用户看到的可能只是最后一个漂亮的回答，背后可能有几十次、上百次的模型调用在"打底"。

这就带来一个非常朴素的问题：推理系统的 Token 成本和延迟，成了 Agent 产品能不能跑起来的"生死线"。

不夸张地说，Token 成本每往下降一半，都会有一大批之前算不过账来的 Agent 应用重新变得可行 —— 这也是无问芯穹、DeepSeek、月之暗面这些团队死磕推理系统架构的核心动机。

1.2 推理系统的两条"地基"：吞吐和延迟

要把推理系统聊清楚，绕不开两个指标。

• 吞吐（Throughput）：单位时间内能处理多少 Token 或多少请求。它决定了单位算力能"卖出去"多少产能，直接和成本挂钩。
• 延迟（Latency）：一个请求从进来到出结果需要多久，尤其是首字延迟（TTFT，Time To First Token），直接决定用户体验。

这两个指标在同一台机器上是打架的 —— 你想让吞吐拉满，就得让请求排排队、批处理；可你想让首字延迟低，就得让请求尽量快过。要在两者之间找一个精妙的平衡，是所有推理系统架构师的宿命。

而当模型的上下文越拉越长、Agent 的调用轮次越来越多，这两个指标之间的矛盾又被放大了一个数量级。所以你能看到，行业里几乎所有的推理系统优化，本质上都在解决同一个问题：在不牺牲用户体验的前提下，把单位算力的 Goodput（有效吞吐）拉高。

1.3 硬件供给的"偏科"，让老架构越来越吃力

真正让事情变复杂的还有第三层因素：硬件本身也不是均质的。

同一台服务器上，某些芯片对计算密集型任务特别友好，另一些则在显存带宽上取胜；不同厂家的推理卡各有各的"性格"；不同代次的 GPU 更是差得离谱。这种"偏科"搁在训练场景问题不大 —— 训练是长周期、可预测的作业。但推理不一样，推理是短时、突发、异质的。

于是行业慢慢意识到一件事：推理这门生意，靠一颗"全能芯片"打天下已经不现实了，未来一定要走"多种芯片各司其职"的路子。

这就是"异构推理"的由来，也是本文主角 PDD 架构的起点。莫潇羽个人的看法是：接下来一到两年，谁能把散落在全国各地、代次和厂商都不一样的存量算力盘活，谁就能在推理这条赛道上拿到更大的定价权。

二、把 Prefill、Decode、KV Cache 三件基础事儿讲透

在讲 PDD 之前，先花点篇幅把三个绕不开的名词讲清楚。哪怕你之前完全没接触过推理系统底层，看完这一节也够了。

2.1 Prefill：一次性把 Prompt 全吃进去

Prefill 中文一般翻译成"预填充"，直白点讲就是：模型第一次读你的输入提示词的过程。

这个阶段有一个很关键的属性：输入的所有 Token 是一次性并行处理的。因为 Transformer 的注意力机制可以让所有输入位置同时参与运算，所以 Prefill 是一个典型的"喂胖它一顿"的动作，非常吃计算算力。

举个例子，你给模型丢一个 32K 长度的上下文，Prefill 阶段要做的就是：把这 32K 个 Token 一次性做 Embedding、走完所有 Transformer 层的自注意力和前馈运算、把每一层的 Key 和 Value 存下来。整个过程算力被拉到最大，属于典型的计算密集型负载。

2.2 Decode：一个字一个字地往外吐

Prefill 走完，模型接下来要开始生成回答。生成阶段就叫 Decode（解码）。

Decode 有一个跟 Prefill 完全相反的特征：它是逐字自回归的。每输出一个新 Token，都要用当前 Token 的 Query 去和之前所有 Token 的 Key/Value 做注意力计算，然后得到下一个 Token 的概率分布，采样，输出。然后再输出下一个，如此往复，直到模型觉得"说完了"。

这里的关键是"逐字"两个字。每一步真正参与运算的只有一个新 Token 的 Query，但要访问的历史 Key/Value 却越攒越多。所以 Decode 阶段最大的瓶颈不是算力，是显存带宽 —— 你得不停地把历史 KV 从显存里搬出来做点积。

一句话总结：Prefill 吃算力，Decode 吃访存。这是理解后面所有优化的原点。

我把两者的差别画成一张对比表，一眼看清：

2.3 KV Cache：以显存换算力的核心"账本"

如果每输出一个 Token 都要把历史 K/V 从头算一遍，那计算量会以平方级爆炸。所以推理引擎里有一个非常朴素的技巧：把已经算过的 Key 和 Value 存下来，下一步直接复用。

这个"存下来的 K 和 V"就是 KV Cache。它相当于一本流水账，每算一个 Token，账本就多一行。

我用一小段伪代码把这件事的骨架呈现出来：

# 极简版：单个请求的 Decode 循环,展示 KV Cache 的复用
kv_cache = prefill(prompt_tokens)  # Prefill 阶段,一次性算出全部历史 KV

next_token = None
while not is_finished(next_token):
    # 只算新一位 Token 的 Q,然后跟历史 KV 做注意力
    q = compute_query(next_token or prompt_tokens[-1])
    logits = attention(q, kv_cache.keys, kv_cache.values)
    next_token = sample(logits)

    # 把新的 K、V 追加到缓存里,下一步继续复用
    new_k, new_v = compute_kv(next_token)
    kv_cache.append(new_k, new_v)

    yield next_token

这份"账本"值多少钱？我给你算一笔：对于像 DeepSeek 这类几百亿参数量级的大模型，一个 64K 上下文的请求，KV Cache 的体积能到几个 GB。这不是文件系统里的几个 GB —— 是必须常驻在显存里的几个 GB。

正因为 KV Cache 又大又必须常驻，它成了推理系统里的核心资产：KV Cache 在哪，Decode 就在哪；KV Cache 搬一次家，代价可能比重新算一遍还要贵。 这句话请在心里记一下，后面 PDD 架构的一个反直觉设计就是靠推翻它的一半才成立的。

2.4 PD 分离：让专业的人干专业的事

回到 Prefill 吃算力、Decode 吃访存这两个矛盾的属性。

在早期的推理引擎里，Prefill 和 Decode 是在同一台机器、同一个进程里连着做的。这样的坏处非常直白：当一台机器上有一个大 Prefill 请求正在跑，其他小请求的 Decode 就要卡一下 —— 两类负载抢同一张卡的资源，谁都跑不痛快。

于是行业慢慢演化出了一个新架构：PD 分离（Prefill-Decode Disaggregation）。

它的核心思想极简单 —— 让 Prefill 和 Decode 跑在不同的机器上：Prefill 实例算完 KV Cache，通过高速网络把这份"账本"传给 Decode 实例，Decode 实例接着往下写字。这就把两个阶段解耦开了，两边都能各自打满。

PD 分离最早在 DistServe、SplitWise 这些学术论文里被系统提出，后来被 vLLM、SGLang、TensorRT-LLM 这几大主流推理框架逐渐吸收，NVIDIA 也把它当作下一代推理服务的核心方向。国内像月之暗面的 Mooncake、DeepSeek 的推理架构，都是走这条路子的典型代表。

从架构演化的角度看，可以粗线条画出下面这张"三代 PD 关系图"，方便你把 PDD 放到大图里去理解：

flowchart LR
    A[第一代:P/D 融合<br/>同一实例做完全部] --> B[第二代:P/D 分离<br/>拆到不同实例、不同卡]
    B --> C[第三代:PD 半分离/异构分离<br/>Semi-PD、PDD 等]
    C --> D[未来:跨集群、多异构组合<br/>PDD 是重要落点]
    style D fill:#FFE066,stroke:#333

到这里，PD 分离基本已经是行业默认答案了。但答完这一题，故事其实才刚刚开始。

因为一旦你想把 P 和 D 放在不同的机房里 —— 问题就来了。

三、跨集群 PD 分离：想法漂亮，落地却撞上一堵"叹息之墙"

PD 分离在同一个机房里跑得挺好，但整个行业很快就意识到一件事：光在一个机房里分是不够的。

3.1 一个自然而然的问题：为什么不跨机房分离？

我们把镜头拉远一点。

现实里的推理算力是什么样？答案是散的：北京有一坨、上海有一坨、内蒙有一坨、贵州有一坨。每一个数据中心里的卡，大概率都是"同一批次采购的同一款卡"，也就是同构集群。这种集群做训练很爽，做推理却有点尴尬 —— 因为推理阶段真正需要的是"异构组合"：有的卡擅长 Prefill，有的卡擅长 Decode。

要让同一个机房里同时有算力型卡和访存型卡，采购成本是天文数字。而且模型架构一换、PD 配比一变，之前买的那些"配对芯片"就有一部分要闲置。

那还有另一条路：把已经建好的、分布在各地的同构集群，用广域网以太网串起来，做跨集群的异构分离式推理。

• 北京机房主打 Prefill 算力型卡；
• 上海机房主打 Decode 访存型卡；
• 中间靠一条广域以太网专线连接；
• 一次请求可以横跨两个机房走完 Prefill 和 Decode。

听起来是"存量算力盘活"的最优解，也符合无问芯穹"前店后厂一中心"的整体战略。但一旦真的落地下去，就会撞上一堵墙。

3.2 KV Cache 传输：跨机房的头号敌人

我在前面反复强调过一句话：KV Cache 在哪，Decode 就在哪。

一旦 P 和 D 分在不同机房，就意味着每个请求的 KV Cache 都要通过广域网从北京搬到上海。这份数据有多大？我们前面算过 —— 一个 64K 上下文的请求，KV Cache 可能是几 GB 起步。

几个 GB 走什么网络？

• 走高速 RDMA 网络：机房内典型带宽 200 到 800 Gbps，延迟几十微秒。这种网络出机房是没法用的。
• 走广域以太网专线：典型带宽 20 到 100 Gbps 已经不错了，跨省的话延迟起码几毫秒 RTT，还要看链路拥堵情况。

这里补一小段网络工程的常识，帮不太熟悉底层的朋友把差距量化出来：

从这张表你能看清一件事：每往上跳一级，带宽提升几十倍，但成本也随之膨胀，扩展性反而下降。所以业界的共识是"能不出机房就尽量不出机房"。而 PDD 之所以敢跨机房，恰恰是因为它找到了一种在广域网上"藏延迟"的办法，让机房间那条相对便宜的以太网也能承担起 KV Cache 传输的重任。

拿 20 Gbps 的跨机房专线来说，理论上传一份 5 GB 的 KV Cache 至少要 2 秒。真实生产环境里链路不会天天空着，一遇上其他流量抢道，几秒钟到十几秒钟的传输时延就是家常便饭。

这就是行业里所说的跨集群 KV Cache 传输带宽与延迟瓶颈，也是一直以来把很多跨机房 PD 分离方案卡在原型阶段的关键原因。

无问芯穹自己也拉过一组对比数据：在 64K 总长度、90% 前缀命中率下，同机房内做 PD 分离，P50 首字延迟平均值约 4.2 秒；如果把解码搬到另一座城市的机房，这个数字变成 6.7 秒。多出来的 2.5 秒，就是 KV Cache 在广域以太网上"爬行"的时间。

对于短输出、快问答的 Agent 场景来说，2.5 秒是一个非常糟糕的数字。因为很多请求本身的整个输出加起来也就十几秒，你光首字延迟就吃掉了小半个体验。

3.3 有没有可能"用一个大网卡"直接怼过去？

有同学可能会想，那我把跨机房网络堆得更粗一点行不行？

理论上可以，但性价比很差。跨广域网的带宽单价，比机房内的高一个数量级不止。 靠堆带宽解决 KV Cache 传输问题，最后得到的还是一个天价方案，反而失去了"用存量算力"的初衷。

而且带宽解决不了物理距离带来的传播延迟。北京到上海直线距离一千多公里，光的传播往返就要有几毫秒的物理下限，堆带宽也堆不掉。

所以问题变成了这样：

• 不能只靠"更粗的管子"；
• 必须从架构上想办法把这几秒的传输延迟"藏起来"；
• 还要保证成本不会失控。

这就是 PDD 架构要回答的核心问题。而在正式讲 PDD 是怎么设计出来之前，我们先看无问芯穹在做研究阶段挖出来的三个关键洞察 —— 这三条几乎决定了后面所有的架构选择。

四、三个关键洞察：延迟的真相被这样一层层扒开

无问芯穹在技术报告里花了很大篇幅讲三个 Insights。莫潇羽的建议是：先花时间把这三条读懂，PDD 的设计思路就顺了一大半。

4.1 洞察一：硬件性能的极度"偏科"

第一个洞察其实是常识的延伸，但被数据量化之后就有了完全不一样的说服力。

无问芯穹的基准测试拿一款 8 卡的旗舰高性能 GPU 作为基线（我们暂且称之为"GPU A"），然后拉了另一款"E 芯片"来做对照。结果是这样的：

看到 Decode 那一栏没有？"偏科"到 2.1 倍。

如果把 E 芯片放在同构集群里，让它既扛 Prefill 又扛 Decode，你会发现：它做 Prefill 的时候拖了整个集群的后腿，做 Decode 的时候优势又发挥不出来，因为要跟 Prefill 抢资源。

这个数据一出来，事情就非常清晰了：把"偏科生"送去他擅长的科目专门刷题，收益能立刻兑现。 让 GPU A 专门做 Prefill，让 E 芯片专门做 Decode，整体吞吐必然会大幅上一个台阶。

而这，正是把 P 和 D 拆到不同集群、跑在不同硬件上的最强动机。

4.2 洞察二：DRC 前缀缓存，把带宽需求砍掉一个数量级

洞察一告诉我们该拆，但没告诉我们怎么把跨集群那条网线的压力降下来。

无问芯穹给出的答案是 DRC（Decode-side Radix Cache，解码端基数树缓存）。

先解释一下前缀缓存这个概念。Agent 类应用有一个非常鲜明的特征：相同的 System Prompt、相同的知识库、相同的工具描述，会被同一个 Agent 反复调用。这些 Token 在很多请求里长得几乎一样，它们对应的 KV Cache 是可以复用的。

前缀缓存干的事情就是：把这些高频出现的前缀 Token 的 KV Cache 常驻在显存里，下次同样的前缀进来直接命中，不再重算、也不再传输。

Radix Tree（基数树）是一种特别适合做前缀匹配的数据结构，SGLang 里的 RadixAttention、vLLM 里的 Hash Prefix Cache 都是这条路线上的产物。

DRC 的关键创新是把这套前缀缓存搬到了 Decode 端：Decode 实例上会缓存历史请求的 KV Cache。当 Prefill 端发现某个新请求的前缀已经在 Decode 端命中了，它就不需要把整个上下文的 KV Cache 都传过去，只需要传那一点点"增量"。

我给你算一下这里的省电效果。假设 Agent 的平均前缀命中率是 90%：

原始 KV Cache 大小:     100%
需要跨集群传输的部分:   10%(未命中的增量)

跨集群带宽需求 ≈ 原来的 1/10

理论上跨集群的带宽需求能被削到原来的十分之一。"流量过载"这个头号敌人，被 DRC 一记闷棍打回去了大半血。

但事情没完 —— 带宽降了，延迟还在。

4.3 洞察三：智能体流量的"非均匀延迟"，罪魁祸首是极少数刺头

带宽虽然降了，但延迟不是一个单纯"数据除以带宽"的算术问题，它还牵扯到网络排队、连接池、拥塞控制等一堆动态因素。

无问芯穹对 600 万条真实业务请求做了分析，发现 Agent 工作负载有一个非常鲜明的"三极"特征：

• 上下文极长：一次请求 64K Token 是家常便饭；
• 前缀缓存命中率极高：平均 90%；
• 输出极短：30% 左右的请求输出不超过 100 Token，40% 左右不超过 500 Token。

在这些请求上，1 到 20 秒的 KV Cache 传输占了端到端总延迟的 43% 到 56%。也就是说，用户看到的整个"卡顿"体验，一半以上都是网络在拖后腿。

但真正让人意外的是下面这条：命中率的分布是极度偏斜的，不是均匀的。

真实业务 Trace 显示，大概 70% 到 80% 的请求命中率都在 95% 以上；只有极少部分（不到 20%）的低命中率请求，才携带着巨大的 KV Cache 数据包。

无问芯穹在 20 Gbps 的跨集群专线上做了一组微基准测试，对比了"真实偏斜分布"和"人工均匀分布（85% 到 95% 命中率）"两种情况：

差异接近 5 倍。

这个数据非常反直觉，但仔细想想又极其合理：在偏斜分布下，大量轻量级请求利用了 TCP 的公平性机制，快进快出，不停释放连接池；而在均匀分布下，所有请求都够重，谁都占着连接池不肯走，反而互相拖死。

这一条洞察给了架构设计一把非常锋利的手术刀：

想要解决跨集群 KV Cache 的延迟瓶颈，不需要在全局层面对抗网络延迟，只需要精准地针对那少部分低命中率的"刺头请求"做优化。

这句话是 PDD 架构最关键的思想起点。整个 PDD 的三级设计，都是围绕这句话展开的。

4.4 三条洞察串起来看

我把这三条串成一句话：

• 硬件偏科 决定了必须拆成异构集群；
• DRC 前缀缓存 让跨集群传输的带宽压力可以承受；
• 命中率偏斜 告诉我们只要照顾好极少数"刺头"，其它请求都会安然无恙。

下一节，我们就来看无问芯穹是怎么把这三条洞察拧成一个具体架构的。

五、PDD 三级架构：一场 2 × 100 米接力赛

PDD 的英文全称是 Prefill-RelayDecode-MainDecode，中文可以叫"预填充—中继解码—主解码"三级架构。

它的关键动作是：在传统 P-D 两级之间，插进一个新的角色 —— RelayDecode（RLD）实例。

5.1 三个角色的分工

一次请求在 PDD 里要经过三种不同的实例，每个实例扮演的角色都很明确：

• P 实例（Prefill）
• 位置：主集群（比如北京机房）；
• 硬件：算力强的旗舰 GPU；
• 职责：接收用户 Prompt，完成 Prefill 计算，产出 KV Cache。
• RLD 实例（RelayDecode）
• 位置：跟 P 实例同一个集群；
• 硬件：跟 P 类似的高性能 GPU，但只占极小比例；
• 网络：通过高速 RDMA 网络跟 P 相连，KV Cache 传输延迟几十毫秒；
• 职责："中继站"，先替远端把首字吐出来，把跨集群延迟藏起来。
• MD 实例（MainDecode）
• 位置：远端外地集群（比如上海机房）；
• 硬件：显存带宽大、擅长 Decode 的芯片；
• 网络：通过广域网以太网跟主集群相连，KV Cache 传输延迟几秒到十几秒；
• 职责：真正的"解码主力"，承担大部分 Token 生成工作。

三者的位置关系可以用一张时序图表达：

sequenceDiagram
    autonumber
    participant U as 用户
    participant P as P 实例(北京)
    participant R as RLD 实例(北京、与 P 同机房)
    participant M as MD 实例(上海)

    U->>P: 发送请求 Prompt
    P->>P: 计算 Prefill,产出 KV Cache

    par 高速 RDMA 传给本地 RLD
        P->>R: KV Cache(几十毫秒到手)
    and 广域以太网传给远端 MD
        P-->>M: KV Cache(几秒到十几秒才到)
    end

    R-->>U: 立刻开始输出首批 Token(用户看到字了!)
    Note over R,M: 用户体验上没有跨集群延迟

    M->>M: 完整 KV Cache 到达
    R->>M: 接力棒交接(Extend-Decode Handoff)
    M-->>U: 接手后续大部分 Token 生成

5.2 为什么叫"接力赛"？

无问芯穹自己用了一个非常贴切的比喻：这就像一场 2 × 100 米接力赛。

当 P 实例算完 Prefill，它会同时干两件事：

• 动作一（第一棒）：通过高速 RDMA 网络，把 KV Cache "瞬间"传给同机房的 RLD 实例；
• 动作二（第二棒起跑准备）：通过慢速且延迟不稳定的以太网，把 KV Cache 传给远端的 MD 实例。

RLD 实例拿到 KV Cache 后，立刻开始解码，输出 Token 给用户。这时候用户根本感觉不到跨集群的 KV 传输还在进行 —— 因为他已经看到字冒出来了。

而在后台，以太网可能还在慢悠悠地传输。几秒钟过后，MD 实例终于收到了完整的 KV Cache。这时候，解码任务就会无缝从 RLD 交接给 MD，由 MD 完成后续大部分的吐字工作。

用一句话浓缩 PDD 的核心思想：

用本地 RLD 的一点点算力，去精准地掩盖跨集群那极少数低命中率请求所产生的网络延迟。

5.3 谁在跑跨集群？谁不用跑？

回到第四章的洞察三：只有低命中率的"刺头请求"才需要走中继站。

高命中率的请求（占比 70% 以上）由于 DRC 的存在，跨集群传输的数据包本来就很小，直接走以太网到 MD 就好，根本不需要 RLD 掺一脚。

于是 PDD 内部实际上有两种流水线并存：

这套"双管齐下"的调度方式，就是 PDD 在工程上跑得又快又稳的关键。我们放到第七章再展开讲编排逻辑。

5.4 顺便说说 PDD 和无问芯穹自家 Semi-PD 的关系

在写这一节的时候，我特意翻了一下无问芯穹早前的开源项目 Semi-PD。二者虽然名字都带 PD 分离，但解决的问题完全不同，容易混。莫潇羽把差别整理成一张表，方便你区分：

一句话：Semi-PD 解决的是"在一个机房里怎么把 PD 分得更漂亮"；PDD 解决的是"怎么把 PD 分到两个机房也不难受"。 两者是无问芯穹推理架构演化路线上不同阶段的答卷，可以在真实生产里组合使用。

5.5 PDD 到底解决了什么？

概念梳理到这里，我们可以给 PDD 打一个总结性的定位：

PDD 不是又一种新的 PD 分离范式，它更像是"跨集群 PD 分离方案的一个必要补丁"。

传统 PD 分离在同机房里工作得不错，一旦跨机房就会被 KV Cache 传输延迟拖垮。PDD 通过引入一个本地中继实例 RLD，把这个延迟从"用户可感知"变成"用户完全无感"，代价则是主集群里额外多出一小撮 RLD 算力。

也就是说，PDD 是拿"极小比例的本地算力"去换"极大幅度的用户体验提升 + 存量算力盘活"。

但只要你稍微琢磨一下，就会发现里面还有一个非常棘手的工程细节：当远端 MD 终于收到完整 KV Cache 的时候，本地 RLD 已经在自顾自地吐了几个 Token 了。这时候两边怎么衔接？MD 怎么"接过接力棒"接着往下写？

如果处理不好，这一次接力就可能变成一次事故 —— 用户看到的输出可能突然卡一下、跳一下、甚至乱一下。

无问芯穹给出的答案叫 Extend-Decode Handoff，我们下一章专门拆它。

六、Extend-Decode Handoff：优雅的"接力棒交接"

如果 PDD 的第一记妙招是"接力跑"，那第二记妙招就是接力棒交接的方式。这一节是全篇最有意思的一节，请你耐心看下去。

6.1 直觉方案：RLD 一边解码，一边把增量 KV Cache 传给 MD

先看一个最"想当然"的方案。

RLD 一边吐 Token，一边把每一步生成的 KV Cache 增量通过以太网传给 MD。等 MD 收全了、追上 RLD 的进度，MD 就能顺利接手。

这个方案听着挺自然，但一实施就发现问题：

• 它又跳回跨集群网络延迟的坑里了。RLD 生成每一个 Token 对应的 KV Cache 都要过一遍广域网，延迟高、抖动大，还很容易被其他大包挤掉。
• 它还得走 H2D/D2H（显存到内存、内存到显存）拷贝。这类操作本身就有额外开销，网络这边一波抖动，那边显存拷贝再叠一层，整体延迟高得离谱。
• 最要命的是，它把"高价值"的显存到显存传输链路给填满了，会反过来把其他低命中率请求的 KV Cache 传输也拖慢。

所以这条路走不通。

6.2 反直觉方案：只传 Token ID，本地重算 KV Cache

无问芯穹给出的解决方案叫 Extend-Decode Handoff（扩展解码交接），做法非常反直觉：

RLD 绝对不传 KV Cache，它只把生成的 Token ID 传给 MD。

Token ID 是什么？就是模型的词表下标，几个整数而已。传几个 Token ID，网络开销从"几个 GB"直接掉到"几 KB"，几乎可以忽略。

MD 收到 Token ID 之后，利用一种叫 Extend-Decode 的技术，在本地重新计算这些 Token 对应的 KV Cache，同时顺手生成下一个新 Token。

这里的 Extend-Decode 技术，其实是 MTP（Multi-Token Prediction，多 Token 预测）和投机解码（Speculative Decoding）这个技术家族里的一个副产品。它的核心能力就是：给定一段前缀 Token，能够在一次前向计算里把这段前缀的 KV Cache 补全，同时把下一步 Token 的概率分布算出来。

你可以把 MD 端的动作理解成："RLD 你告诉我你吐了什么就行，KV Cache 我这边自己算"。

6.3 慢慢地问一句：重算难道不慢吗？

到这里很多人会有一个非常合理的疑问：KV Cache 重算难道不比传输更慢？

这就要回到第二章讲过的那个关键属性：Decode 阶段是访存密集型的，计算量本身非常轻。

无问芯穹在 MD 端做了一组重算的实测：

• 重算 100 个 Token 的 KV Cache：平均耗时 305.2 ms，最大 321.4 ms，标准差 4.8 ms。

反观走以太网传 KV Cache：

• 平均 185.4 ms，一旦网络拥堵，峰值飙升到 512.6 ms，标准差 96.3 ms，另外还有 24.5 ms 的 H2D/D2H 开销没算在内，实际排队延迟也没算在内。

看两组数据，你就能理解这套设计有多稳定了：

平均延