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

目录本文你会看懂什么先解释关键术语先解释报告中的技术表述一、先算清楚 KV Cache 为什么会爆二、Prefill 和 Decode 的瓶颈不同三、PD 分离后多出来的是 KV Cache 传输链路四、KV Cache 池化不是一个大缓存而是分层状态管理五、CXL 和资源池化解决的是容量弹性不是所有时延问题六、推理调度器必须变成缓存感知七、Chunk Prefill、MTP、DeepEP 和 KV Cache 的关系八、逻辑超节点适合推理混部但要避免破坏局部性九、推理系统的关键观测指标十、工程判断清单十一、总结核心术语表本文基于以下三份报告进行汇总、解释和二次整理华为《超节点发展报告》中兴《超节点技术白皮书》H3C《超节点技术白皮书》本文你会看懂什么为什么长上下文推理首先打爆的是KV Cache而不只是算力。PD 分离后Prefill 到 Decode 之间到底多了一条什么数据路径。超节点的统一编址、资源池化和高带宽互联如何服务推理系统的缓存调度。前几篇更多讨论训练Scale-Up、统一内存、并行通信和 MoE。这一篇转到推理但不要把推理理解成“模型部署简单版”。先解释KV Cache是大模型推理时保存历史上下文中 Key/Value 状态的缓存。模型每生成一个新 token都要参考前面的上下文有了 KV Cache就不用每次把完整历史重新算一遍。PD 分离则是把推理拆成两个阶段来调度Prefill负责处理输入上下文并生成 KV CacheDecode负责逐 token 生成输出并反复读取 KV Cache。这两个概念合在一起会把推理系统变成一个状态管理问题。概念先抓住什么KV Cache它是历史上下文的中间状态不是普通业务缓存长上下文上下文越长KV Cache 越大高并发并发越高同时驻留的 KV Cache 越多PD 分离Prefill 和 Decode 可以分开优化但 KV Cache 需要跨阶段传输池化不是简单找地方存而是要按热度、路径和 SLA 管理所以本文讨论的重点不是“KV Cache 是什么”本身而是当 KV Cache 变大、变热、需要跨设备迁移之后超节点为什么开始影响推理系统设计。关键术语先解释术语技术含义报告中的使用方式KV Cache大模型推理中保存历史上下文 Key/Value 的中间状态。华为术语表将其定义为大模型推理中用于存储上下文信息的关键值缓存。Prefill处理输入上下文并生成初始 KV Cache 的阶段。中兴报告把它作为 PD 架构中的 P 阶段。Decode逐 token 生成输出并持续读取 KV Cache 的阶段。中兴报告把它作为 PD 架构中的 D 阶段。PD 聚合Prefill 和 Decode 共享同一组 GPU 资源和并行策略。中兴报告称其适合追求高吞吐的批处理场景。PD 分离Prefill 与 Decode 解耦分别分配 GPU 资源和并行策略。中兴报告称其更适合严格 SLA 约束下的时延敏感场景。Chunk Prefill将长输入分块进行预填充降低显存峰值。中兴报告将其归为框架层面的推理优化。MTPMulti-Token Prediction多 Token 预测。中兴报告称其将 Decode 阶段单 token 生成转为多 token 生成。TTFTTime To First Token首 token 响应延迟。H3C 报告将其列为在线推理延迟类 SLO 的关键指标。TPOTTime Per Output Token每个输出 token 的生成延迟。H3C 报告将其用于衡量连续生成流畅程度。Goodput在满足延迟 SLO 前提下真正完成的有效请求吞吐。H3C 报告把它作为比单纯吞吐量更贴近在线推理的指标。SLOService Level Objective服务等级目标。H3C 报告用 TTFT/TPOT SLO 约束在线推理服务质量。这张表有助于避免一个误解KV Cache 池化不是缓存系统单点优化而是 Prefill、Decode、SLO、显存层级和调度器共同作用的推理架构问题。报告中的技术表述来源技术表述本文如何使用华为报告第 16 页KV Cache 访问效率直接决定推理延迟与并发处理能力多级存储体系可将 KV Cache 从单机显存限制中释放。用来说明 KV Cache 是推理系统关键状态而不是普通缓存。华为报告第 16 页热数据保留在单卡显存冷数据动态迁移到内存或存储层支撑百万 Token 级长上下文。用来解释“分层缓存”而不是简单远端化。中兴报告第 30-31 页PD 聚合适合批处理和离线推理PD 分离通过阶段解耦满足严苛 SLA。用来定义 PD 分离的架构边界。中兴报告第 31 页Chunk Prefill 降低显存峰值并提升并发MTP 提升 Decode 性能EPLB、DeepEP、IBGDA 分别处理专家负载和通信效率。用来补充推理优化栈。H3C 报告第 269-270 页Goodput 将吞吐量与 TTFT/TPOT SLO 绑定比单纯吞吐量更适合衡量在线推理。用来建立推理指标体系。H3C 报告第 310 页vLLM、SGLang 等推理框架需要智能调度器、统一 KV Cache 缓存池和 PD 分离推理。用来说明 KV Cache 池化需要进入软件栈和调度层。长上下文、多轮对话、智能体、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处理输入上下文生成初始 KV Cache算力、显存峰值、长输入批处理TTFT、吞吐Decode逐 token 生成输出反复读取 KV Cache访存、调度、低时延、状态管理TPOT、SLO、并发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 至少可以按热度分成三层。层级适合放什么关注点本地 HBM当前请求最近 token、Decode 热路径极低时延、高带宽同域远端显存/内存可复用前缀、临近请求状态、溢出缓存访问路径和迁移成本CXL/远程内存/存储冷上下文、长会话历史、低频状态容量、回读延迟、淘汰策略所以 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。可以把缓存感知调度拆成下面几类策略。策略作用Prefix cache 命中优先相同系统提示词、RAG 前缀、长文档复用时降低重复 PrefillSession sticky多轮对话尽量回到持有 KV Cache 的 Decode 实例KV 迁移预算控制每个请求允许跨设备传输的缓存量分层淘汰热 token 留 HBM冷 token 迁移到远端层SLA 分级低时延请求优先本地热缓存高吞吐任务可接受远端层拓扑亲和Prefill 和 Decode 选择低跳数、高带宽路径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 压力并不会被单层优化完全解决需要这些层共同作用。可以按阶段理解技术主要作用阶段与 KV Cache 的关系Chunk PrefillPrefill长输入分块处理降低显存峰值提高并发MTPDecode一次预测多个 token降低逐 token 串行开销EPLBMoE 推理缓解专家负载不均减少慢专家拖慢 DecodeDeepEPMoE Dispatch/Combine降低专家分发和聚合通信成本IBGDA跨机通信提升机间数据聚合和通信效率这些能力最终都会影响两类指标首 token 之前的等待也就是 TTFT。每个输出 token 的稳定性也就是 TPOT 和尾时延。所以推理优化不应只看 QPS。长上下文场景下QPS、TTFT、TPOT、SLO、KV Cache 命中率和远端访问时延要一起看。八、逻辑超节点适合推理混部但要避免破坏局部性华为报告给出了逻辑超节点虚拟切分示例。图源华为《超节点发展报告》第 21 页图 4.5。用途说明物理超节点可以被切分成多个逻辑资源域支撑不同任务并行运行。这张图放在推理场景中重点是“切分不能破坏局部性”。逻辑超节点可以提升多业务混部能力但如果 Prefill、Decode 和 KV Cache 被切到远距离资源域可能会牺牲 TTFT、TPOT 和 SLO。推理业务通常是混部的短上下文高并发。长上下文文档问答。RAG 检索增强。MoE 推理。智能体多轮任务。多模型、多租户服务。逻辑超节点的好处是资源可以弹性切分但风险是切分后破坏缓存和通信局部性。例如一个长上下文会话的 Prefill 在逻辑分区 ADecode 却被调度到分区 BKV Cache 就要跨域迁移。资源利用率看起来提高了但 TPOT 可能变差。所以推理侧切分逻辑超节点时要同时考虑模型副本位置。KV Cache 生命周期。Prefill/Decode 拓扑距离。租户隔离。SLA 优先级。HBD 内链路健康度。H3C 报告在业务平台部分提到逻辑超节点支持弹性切分适配小模型推理与碎片化任务并预计整体资源利用率提升 10% 以上。引用这个结论时建议写成“报告预计”避免把它当成所有场景的确定收益。九、推理系统的关键观测指标如果要验证 KV Cache 池化是否有效不建议只看显存占用下降。更应该看下面这些指标。指标说明TTFT请求到首 token 的延迟受 Prefill、排队、KV 传输影响TPOT每输出 token 延迟受 Decode 和 KV 读取影响SLO 达标率反映尾时延和服务稳定性KV Cache 命中率判断复用和缓存调度是否有效KV 迁移耗时判断 PD 分离或请求迁移是否拖慢首 token本地/远端访问占比判断热数据是否被放在正确层级HBM 碎片率判断缓存管理是否导致可用显存碎片化Remote read p95/p99判断远端缓存是否进入关键路径Decode batch 稳定性判断动态批处理是否被长请求打散单位 Token 成本业务最终关心的效率指标这类指标应该和链路、拓扑、GPU 利用率一起看。否则很容易出现“显存省了但服务变慢了”的情况。十、工程判断清单评估一个长上下文推理方案是否真的需要超节点可以按下面的问题追问。问题判断意义单请求 KV Cache 是否可能超过单卡 HBM判断是否必须引入跨卡或分层缓存并发下 KV Cache 总量是否超过单机容量判断是否需要资源池化Prefill 和 Decode 是否存在明显资源错配判断是否适合 PD 分离PD 分离后的 KV 传输是否有带宽保障判断拆分是否会被传输抵消Decode 是否频繁访问远端 KV判断 TPOT 是否会恶化调度器是否知道缓存位置判断是否能做缓存感知路由是否支持前缀复用和会话粘性判断是否能降低重复 Prefill是否能观测 KV 命中率和迁移耗时判断是否能定位性能波动如果这些问题无法回答系统可能只是“把 KV Cache 放远了”还没有形成真正的 KV Cache 池化能力。十一、总结长上下文推理把推理系统从无状态服务推向有状态服务而KV Cache是这个状态的核心。Prefill 负责生成 KV CacheDecode 负责反复读取 KV Cache。PD 分离让两类资源可以分别优化但也引入了 KV Cache 传输和缓存位置管理。CXL、远程内存和资源池化可以缓解容量压力却不能替代 HBM 的热路径价值。因此超节点在推理侧的意义不是“把推理也堆大”而是提供一个高带宽、低时延、可统一编址、可调度的资源域让缓存、计算和网络可以一起被管理。真正可用的长上下文推理系统应该把KV Cache当成一等公民可放置、可迁移、可观测、可分层、可调度。核心术语表术语含义KV CacheTransformer 推理中缓存历史 token 的 Key/Value 状态用于减少重复计算。Prefill推理初始阶段处理输入上下文并生成 KV Cache。Decode逐 token 生成阶段持续读取 KV Cache。PD 分离将 Prefill 与 Decode 拆到不同资源上独立调度。TTFTTime To First Token请求到首 token 的延迟。TPOTTime Per Output Token每个输出 token 的平均生成时间。SLOService Level Objective服务级目标常用于约束延迟和可用性。Chunk Prefill将长输入拆块预填充降低显存峰值并提升并发。CXLCompute Express Link可用于内存扩展、内存池化和设备互联。逻辑超节点在物理超节点上切分出的逻辑资源域用于不同任务或租户调度。下一篇也是技术深度系列最后一篇我们把视角落到工程化无损网络、RAS、训前巡检、拓扑感知调度和可观测性决定超节点能不能长期稳定运行。