超节点技术深度篇五：长上下文推理与 KV Cache 池化：从显存压力到 PD 分离调度

本文基于以下三份报告进行汇总、解释和二次整理：

• 华为《超节点发展报告》
• 中兴《超节点技术白皮书》
• H3C《超节点技术白皮书》

本文你会看懂什么

• 为什么长上下文推理首先打爆的是KV Cache，而不只是算力。
• PD 分离后，Prefill 到 Decode 之间到底多了一条什么数据路径。
• 超节点的统一编址、资源池化和高带宽互联，如何服务推理系统的缓存调度。

前几篇更多讨论训练：Scale-Up、统一内存、并行通信和 MoE。这一篇转到推理，但不要把推理理解成“模型部署简单版”。

先解释

KV Cache是大模型推理时保存历史上下文中 Key/Value 状态的缓存。模型每生成一个新 token，都要参考前面的上下文；有了 KV Cache，就不用每次把完整历史重新算一遍。

PD 分离则是把推理拆成两个阶段来调度：Prefill负责处理输入上下文并生成 KV Cache，Decode负责逐 token 生成输出并反复读取 KV Cache。

这两个概念合在一起，会把推理系统变成一个状态管理问题。

所以本文讨论的重点不是“KV Cache 是什么”本身，而是当 KV Cache 变大、变热、需要跨设备迁移之后，超节点为什么开始影响推理系统设计。

关键术语先解释

这张表有助于避免一个误解：KV Cache 池化不是缓存系统单点优化，而是 Prefill、Decode、SLO、显存层级和调度器共同作用的推理架构问题。

报告中的技术表述

长上下文、多轮对话、智能体、RAG、MoE 推理、PD 分离，会把推理服务变成一个在线状态管理系统。这个状态的核心，就是KV Cache。

华为报告第 16 页明确把 KV Cache 作为资源池化的典型对象：它的访问效率直接决定推理延迟与并发处理能力。这个判断很关键，因为它把推理瓶颈从“单次算力”推到了“状态访问和迁移”。

一、先算清楚 KV Cache 为什么会爆

Transformer 解码时，为了避免每生成一个 token 都重新计算完整历史，会把每层 Attention 的 Key 和 Value 保存下来，这就是 KV Cache。

KV Cache 的规模可以用一个简化公式理解：

KV Cache 大小 ≈ 层数 × 2(K,V) × 序列长度 × KV head 数 × head_dim × 精度字节数 × 并发请求数

不同模型会因为MHA、MQA、GQA、量化精度、并行切分方式不同而有所差异，但增长规律不变：它随上下文长度和并发请求数线性放大。

H3C 报告在模型选型章节中给过一个直观例子：

对于 70B 参数模型，在 128K 上下文长度下，仅 KV Cache 就可能超过 150GB 显存，占用超过单张 H100 80GB 的容量上限。

报告还在在线 AIGC 对话推理案例中估算，峰值 QPS 为 400、单轮生成 512 Token 时，KV 缓存需求约 480GB，总显存需求叠加参数和中间计算后超过 800GB。

这说明长上下文推理的第一性问题不是“卡够不够快”，而是：

• KV Cache 放在哪里。
• Decode 每步读得有多快。
• 高并发下是否会频繁换入换出。
• 请求迁移时缓存能否跟上。
• 缓存远端化后尾时延是否可控。

二、Prefill 和 Decode 的瓶颈不同

推理通常可以拆成两个阶段。

Prefill更像一段大批量矩阵计算，Decode更像一段强状态、低批量、反复访存的循环。

如果把这两个阶段放在同一组 GPU 上，容易出现资源错配：

• 长输入请求占用 Prefill 计算，短请求的 Decode 被阻塞。
• Decode 需要持续持有 KV Cache，显存被状态占满。
• Prefill 更适合做吞吐优化，Decode 更适合做时延优化。
• 不同阶段混在一起，调度器很难同时优化 TTFT 和 TPOT。

所以PD 分离的工程价值，是把两个阶段拆开调度，让 Prefill 资源和 Decode 资源分别按瓶颈优化。

中兴报告第 30 页把推理服务架构分为 PD 聚合和 PD 分离两类。
PD 聚合适合高吞吐批处理、离线推理、批量内容生成；
PD 分离把 Prefill 与 Decode 解耦，为每个阶段独立分配 GPU 资源和并行策略，更适合严格 SLA 的时延敏感场景。

PD 聚合减少跨阶段传输复杂度，但 Prefill 与 Decode 会互相争抢同一组资源；
PD 分离提升资源匹配度，但必须解决KV Cache 从 P 节点到 D 节点的传输、注册和访问路径问题。

三、PD 分离后，多出来的是 KV Cache 传输链路

PD 分离不是免费午餐。

当 Prefill 和 Decode 不在同一组设备上时，Prefill 生成的 KV Cache 必须交给 Decode。这个链路可以抽象成：

请求进入 -> Prefill 计算输入上下文 -> 生成 KV Cache -> KV Cache 传输或注册 -> Decode 节点持续读取 KV Cache -> 输出 token

这里有三个关键点。

第一，KV Cache不是一次性小对象。长上下文和高并发会让它变成大状态。

第二，Decode 不是只读一次。后续每个 token 都要访问历史 KV Cache，因此缓存位置会持续影响 TPOT。

第三，传输路径可能影响 TTFT。如果 Prefill 算完后 KV Cache 迟迟不能到达 Decode，首 token 延迟会被拉长。

H3C 报告在推理性能优化需求中指出，Prefill 和 Decode 两阶段之间需要传输中间数据，即 KV Cache，需要高速网络和优化传输，超节点相比普通服务器节点集群更有优势。这个结论正是 PD 分离能否落地的关键。

四、KV Cache 池化不是一个大缓存，而是分层状态管理

华为报告第 16 页提出“显存-内存-存储”多级存储体系：热数据保留在单卡显存，冷数据动态迁移到内存或存储层，从而支撑百万 Token 级长上下文和更大的批处理规模。

按“热度分层”来说：最热的 KV Cache 留在本地 HBM，访问频率下降的数据可以迁移到内存或存储层。这里的关键不是容量无限扩大，而是不同层级的访问代价要被调度器和推理框架感知。

在工程上，KV Cache 至少可以按热度分成三层。

所以 KV Cache 池化不是“把缓存扔到远端”，而是要根据访问热度、请求生命周期和SLA做分层。

一个常见错误是只看容量：远端空间足够大，但 Decode 每步都要远端访问，TPOT 会明显恶化。真正可用的池化必须有热数据保留、冷数据迁移和访问代价感知。

五、CXL 和资源池化解决的是容量弹性，不是所有时延问题

H3C 报告把 CXL 放在资源池化章节中讨论，用来说明内存从单机附属设备走向可组合资源。

图源：H3C《超节点技术白皮书》第 102 页，图 73。用途：说明 CXL 可以把内存纳入资源池化体系。

这张图对应 KV Cache 池化里的“容量弹性”。CXL 内存或共享内存池可以承接冷数据和溢出状态，但如果 Decode 热路径持续访问远端层，就会把容量问题转化为 TPOT 和尾时延问题。

再看 CXL Fabric。

图源：H3C《超节点技术白皮书》第 108 页，图 79。用途：说明多主机、多设备、多内存池之间如何形成 Fabric 化组织。

这张图要和调度器一起看：Fabric 化之后，内存资源可组合，但访问路径不等价。推理调度必须知道某块 KV Cache 到某个 Decode 实例之间的拓扑距离、带宽和时延。

放到 KV Cache 场景里，CXL 的价值主要在三点：

• 扩大可用内存容量，缓解单卡 HBM 不足。
• 支持更灵活的内存资源组合和回收。
• 让部分冷数据不必长期占用昂贵 HBM。

但CXL或远程内存并不意味着所有 KV Cache 都应该远端化。

Decode 热路径对时延非常敏感。只要远端访问进入每 token 的关键路径，就要关注 p95/p99 TPOT，而不是只看平均吞吐。

因此，正确的系统策略通常不是“远端内存替代 HBM”，而是“HBM 保热路径，远端内存接冷状态，调度器控制迁移边界”。

六、推理调度器必须变成缓存感知

传统推理调度器可能主要看：

• 哪张 GPU 空闲。
• 哪个实例排队短。
• 哪个模型副本可用。

长上下文和 PD 分离之后，只看这些不够。调度器还要知道：

• 请求的 KV Cache 在哪里。
• Decode 节点是否能快速访问该缓存。
• 当前上下文长度会不会触发溢出。
• Prefill 输出传给哪个 Decode 实例最短。
• 迁移一次缓存的收益是否大于代价。
• 同一个会话是否应该保持 sticky。

可以把缓存感知调度拆成下面几类策略。

H3C 报告的软件栈分层架构中，推理与服务框架包含 vLLM、SGLang 等，并提到智能调度器、统一 KV Cache 缓存池、PD 分离推理等能力。这说明 KV Cache 池化不是单个推理框架内部的小优化，而是要进入资源调度和业务平台。

图源：H3C《超节点技术白皮书》第 309 页，图 192。用途：说明推理框架、调度器、通信库和运维平台需要协同支持 KV Cache 池化。

这张图说明 KV Cache 池化不能只写在推理框架内部。推理引擎负责缓存复用和请求调度，通信库负责跨设备传输，调度平台负责资源放置，运维平台负责监控命中率、迁移耗时和链路质量。

七、Chunk Prefill、MTP、DeepEP 和 KV Cache 的关系

中兴报告列出了一组推理优化点，它们不是孤立的。
框架层处理 Chunk Prefill、计算通信重叠和 MTP，算子层处理 MLP 矩阵合并，通信层处理 DeepEP 和 IBGDA，服务层处理多副本和扩缩容。KV Cache 压力并不会被单层优化完全解决，需要这些层共同作用。

可以按阶段理解：

这些能力最终都会影响两类指标：

• 首 token 之前的等待，也就是 TTFT。
• 每个输出 token 的稳定性，也就是 TPOT 和尾时延。

所以推理优化不应只看 QPS。长上下文场景下，QPS、TTFT、TPOT、SLO、KV Cache 命中率和远端访问时延要一起看。

八、逻辑超节点适合推理混部，但要避免破坏局部性

华为报告给出了逻辑超节点虚拟切分示例。

图源：华为《超节点发展报告》第 21 页，图 4.5。用途：说明物理超节点可以被切分成多个逻辑资源域，支撑不同任务并行运行。

这张图放在推理场景中，重点是“切分不能破坏局部性”。逻辑超节点可以提升多业务混部能力，但如果 Prefill、Decode 和 KV Cache 被切到远距离资源域，可能会牺牲 TTFT、TPOT 和 SLO。

推理业务通常是混部的：

• 短上下文高并发。
• 长上下文文档问答。
• RAG 检索增强。
• MoE 推理。
• 智能体多轮任务。
• 多模型、多租户服务。

逻辑超节点的好处是资源可以弹性切分，但风险是切分后破坏缓存和通信局部性。

例如一个长上下文会话的 Prefill 在逻辑分区 A，Decode 却被调度到分区 B，KV Cache 就要跨域迁移。资源利用率看起来提高了，但 TPOT 可能变差。

所以推理侧切分逻辑超节点时，要同时考虑：

• 模型副本位置。
• KV Cache 生命周期。
• Prefill/Decode 拓扑距离。
• 租户隔离。
• SLA 优先级。
• HBD 内链路健康度。

H3C 报告在业务平台部分提到逻辑超节点支持弹性切分，适配小模型推理与碎片化任务，并预计整体资源利用率提升 10% 以上。引用这个结论时建议写成“报告预计”，避免把它当成所有场景的确定收益。

九、推理系统的关键观测指标

如果要验证 KV Cache 池化是否有效，不建议只看显存占用下降。

更应该看下面这些指标。

这类指标应该和链路、拓扑、GPU 利用率一起看。否则很容易出现“显存省了，但服务变慢了”的情况。

十、工程判断清单

评估一个长上下文推理方案是否真的需要超节点，可以按下面的问题追问。

如果这些问题无法回答，系统可能只是“把 KV Cache 放远了”，还没有形成真正的 KV Cache 池化能力。

十一、总结

长上下文推理把推理系统从无状态服务推向有状态服务，而KV Cache是这个状态的核心。

Prefill 负责生成 KV Cache，Decode 负责反复读取 KV Cache。PD 分离让两类资源可以分别优化，但也引入了 KV Cache 传输和缓存位置管理。CXL、远程内存和资源池化可以缓解容量压力，却不能替代 HBM 的热路径价值。

因此，超节点在推理侧的意义不是“把推理也堆大”，而是提供一个高带宽、低时延、可统一编址、可调度的资源域，让缓存、计算和网络可以一起被管理。

真正可用的长上下文推理系统，应该把KV Cache当成一等公民：可放置、可迁移、可观测、可分层、可调度。

核心术语表

下一篇也是技术深度系列最后一篇，我们把视角落到工程化：无损网络、RAS、训前巡检、拓扑感知调度和可观测性，决定超节点能不能长期稳定运行。