机器之心发布

随着大模型推理服务部署面临成本与算力的多机双重约束，Prefill-Decode（PD）分离的构联异构推理已从前沿探索走向生产落地。推理加速器的合发核心差异性体现在不同精度的计算速度、访存带宽与存储容量、布工边界以及机内机间通信带宽等多个维度。业级例如，设计实践在构建异构 Token 工厂时，拆解通常选择计算密集型硬件执行 Prefill 阶段，跨硬而利用高通信带宽硬件执行 Decode 阶段。理服

在此架构下，多机KV Cache 的构联跨硬件、跨精度及跨互联传输成为常态。合发核心然而，布工边界业界长期缺乏统一的业级设计范式 —— 硬件选型、量化精度、设计实践网络拓扑与 KV Cache 分层存储高度耦合。部署运维人员往往只能依靠试错调参，极易引发字节传输成功但推理结果错乱、首 Token 延迟（TTFT）飙升、KV Cache 数据污染及故障恢复失效等严重问题。

近日，上海创智学院、上海交通大学、复旦大学、中国人民大学、沐曦、基流、上海仪电等多家产学研机构联合发布论文《Demystifying the Design Space and Best Practices for Heterogeneous LLM Inference and Serving》，首次系统性拆解了异构 Prefill-Decode 推理的设计空间，提炼出三个核心边界决策与九条部署最佳实践，并在沐曦 C600 GPU 与英伟达 Hopper GPU 的生产环境中完成验证。

论文地址：https://arxiv.org/pdf/2606.29708

异构推理已成常态，但缺一张全景图

大模型推理正经历一场静默的架构变革。当前，异构推理不再是可选项，而是必然趋势：GPU 供应紧张、多厂商混合部署成为常态，且不同推理阶段对算力和带宽的需求存在天然差异。通过将异构推理部署在性价比更优或供应充足的芯片上执行 Prefill 阶段，在带宽更强的芯片上执行 Decode 阶段，并采用混合数值格式传输 KV Cache 状态，系统可跨越异构互联完成完整的推理请求。

然而，多数团队仍沿用同构时代的思路。DistServe、Splitwise、Mooncake、FlowKV 等系统虽各自解决了部分关键问题，但均独立进行决策。对于“使用何种加速器、精度、互联方式及 KV Cache 驻留位置”等问题，缺乏统一的设计框架来回答：哪些决策必须联合做出，哪些可以独立决定？

核心问题：当异构推理组合了不同的加速器、数值格式、互联路径和 KV Cache 驻留层级时，哪些设计决策必须在 PD 边界处联合做出，哪些可以各自独立？

该论文旨在回答上述问题，为快速膨胀的异构推理设计空间划定理论边界。它不提出新的推理架构或调度算法，而是提供一份设计空间的系统性地图，帮助工程团队理解那些看似独立、实则耦合的设计选择，以及它们如何在边界处产生交互。

五个设计轴与一个关键抽象

论文跳出单一模块优化的局限，构建了一套覆盖全链路的标准化分析框架，将异构推理拆解为五个设计维度。基于维度间的强耦合约束，论文收敛出异构部署必须解决的三大核心边界问题。

在同构部署中，这五个设计维度大多可独立调节；但在 Prefill 和 Decode 运行于不同硬件的异构场景下，维度间的耦合显著增强：
* 某款加速器上表现优异的精度格式，可能在另一款加速器上缺乏可执行的引擎路径；
* 传输引擎可能成功搬运了字节，但接收端可能在完全不同的数值语义下解读这些数据。

为此，论文引入了一个关键抽象 —— Runtime KV State（运行时 KV 状态）。该状态不仅包含 KV 张量本身，还涵盖表示格式、元数据、驻留信息和所有权状态。所有异构推理的边界问题，本质上均围绕该对象的生产（Prefill 阶段）、传输（PD 边界交接）和消费（Decode 阶段）展开。

三个必须做出的边界决策

通过分析五个设计轴之间的两两耦合关系，论文识别出六个紧耦合和两个开放耦合，并将其归纳为三个核心边界决策：

决策一：计算放置（Compute Placement）

哪个加速器池服务 Prefill，哪个服务 Decode？
这并非简单地将最快硬件分配给最繁忙的阶段。Prefill 是计算密集型任务，受益于高算力；Decode 是带宽密集型任务，受制于内存带宽和 KV 容量。同一款芯片在不同工作负载下的表现差异巨大：长输入推高 Prefill 压力，而长生成和多并发则推高 Decode 压力。

更关键的是，精度选择与加速器绑定：一种数值格式是否可用，取决于该加速器上是否有成熟的内核实现，而非仅看硬件规格表上的理论支持。这意味着阶段放置、精度选择和负载均衡必须作为同一个决策联合做出。

决策二：KV 表示（KV Representation）

运行时 KV 状态如何在 PD 边界上被表示、传输和消费？
在同构部署中，两端共享相同的运行时环境，此问题并不存在。但在异构部署中，Prefill 和 Decode 可能使用不同的内核、不同的精度策略甚至不同的张量布局。

论文指出一个易被忽视的失败模式：现有的 KV Cache 传输引擎（如 NIXL、Mooncake）本质上搬运的是字节而非张量语义。若生产者和消费者对数值格式的理解不一致，传输本身不会报错，字节虽成功到达，但会被错误解释。这不是传输故障，而是语义故障。

论文将 KV 可移植性定义为：Decode 必须能够直接消费或通过显式验证的转换来消费传输过来的状态。兼容性检查应分为两类：
1. 不可转换的不变量：模型身份、适配器、Token 范围。
2. 可转换的差异：布局、分区、数值表示。

决策三：KV 所有权与生命周期（KV Ownership & Lifecycle）

运行时 KV 状态成功传输至 Decode 端并不意味着任务结束。系统还必须管理其完整生命周期：何时预留容量、谁持有状态、何时释放资源、如何处理失败和取消。

论文通过源码级分析，对比了 vLLM和 SGLang两大推理框架在 PD 交接路径上的生命周期管理差异：
* vLLM (NIXL pull 模式)：Decode 端在 Prefill 返回坐标后才发起读取、分配目标空间。
* SGLang：Decode 端预分配目标并主动发送元数据。

两种模式在容量核算、故障恢复和拥塞控制上具有截然不同的特性。

九条部署最佳实践

结合异构推理生产集群实测、vLLM/NIXL 与 SGLang/Mooncake 源码审计、以及多组单节点对照实验，论文输出 9 条落地准则，覆盖硬件选型、量化配置、KV Cache 传输及 KV 缓存全生命周期管理：

沐曦 + 英伟达的异构 Token 工厂实践

论文提供了一个关键的生产部署案例 CPHD-GLM5.1：在沐曦 C600 GPU 上执行 Prefill（INT8 / W8A8）阶段，在英伟达 Hopper GPU 上执行 Decode（FP8）阶段，提供 GLM-5.1 模型的推理服务。

该部署在输入长度为 64K、90% 前缀缓存命中率下，关键指标如下：

在 AIME 25、AIME 26 和 SWE-Bench Verified 等基准测试上，异构执行的结果与官方参考值偏差在可接受范围内，验证了异构配置不会引入可测量的质量退化。

受控实验揭示耦合效应

除了生产部署，论文还在单节点环境中进行了受控的 SLA 性能测量，系统性验证了设计轴之间的耦合效应。

计算放置与 KV 格式不可分离

在 Qwen3-32B、SGLang PD、NIXL 的单节点 SLA 压测中，论文首先固定 BF16 KV 表示，比较不同 P:D 拓扑的服务上限：
* 当配置从 6P2D调整为 4P4D时，最高可满足 SLA 的请求注入率从 0.2降至 0.1。
* 随后，在相同 4P4D拓扑下，将 KV 表示从 BF16切换为 FP8 e4m3，SLA 约束下的最高请求注入率提升至 1.0。

这一结果说明，P:D 资源比例不能脱离 KV 表示单独评估；KV dtype 会直接改变 Decode 侧的带宽、容量和尾延迟压力，从而反过来影响计算资源放置的最优选择。因此，计算放置与 KV 表示应作为异构 PD 部署中同一个决策的两面。

精度策略的非对称影响

在单机精度策略对全局影响的实验中，FP8 和 AWQ INT4 相比 BF16 均提升了 Decode 侧效率，但代价不同：

• FP8：改善了 TPOT（Time Per Output Token）。
• AWQ INT4：进一步提升了吞吐量，增加了 TTFT（Time To First Token）。

精度选择在不同阶段产生非对称的延迟影响，再次强化了论点：精度策略应属于运行时角色，而非全局设置。

两个待解的开放问题

论文同时指出当前产业仍待突破的两大开放耦合问题，为后续学术研究与工程落地指明方向：

1. 跨厂商硬件 KV 统一传输栈：不同厂商加速器的通信库、内存注册机制不互通，现有适配层仅能做封装适配，缺少原生标准化的跨硬件传输抽象。KV 传输本质上是端到端通信栈的属性，而非单纯的传输层特性。
2. 互联网络与 PD 资源协同规划：标准部署网络带宽固定，只能通过软件调度适配 KV 流量；定制化场景可将网络拓扑、网络带宽作为顶层设计变量，与 Prefill/Decode 硬件池同步规划。目前缺乏一体化规划方法论，互联带宽、跨机架链路和集群级拓扑均受 PD 工作负载结构的影响。