DeepSeek V4 1 对推理 Infra 的挑战：从 KV 状态图到异构 Memory Run

整理日期：2026-09-16。问题起点：DeepSeek V4.1 的模型结构变化，为什么会让 inference infra 明显变难？ 本文不重复模型结构本身，而从 serving runtime 的状态、并行、通信、存储层级和验证方法推导工程影响。当前实现状态以 2026-09-16 的公开 Roadmap / Issue 为准，不把 roadmap 目标写成已稳定支持。

核心判断：DeepSeek V4.1 让推理框架进一步从“逐层执行 Transformer 的 engine”演化为理解模型状态语义的异构、分布式数据流 runtime。最关键的变化不是多几个算子，而是 cache ownership、跨层复用、可重建状态、外部稀疏记忆和 speculative state 开始互相耦合。

1. 传统 inference runtime 的几个隐含假设正在失效

经典 decoder-only serving 常可以近似理解为：

request
  ↓
for layer in layers:
    read KV[layer]
    attention
    MLP / MoE
    append KV[layer]

在这个模型里，状态组织比较规则：每层拥有自己的 KV；Prefill 与 Decode 共享同一套层结构；KV block manager 主要负责 token/block 到物理显存的映射。

V4.1 引入 CED、CSA2、SWA、跨层 KV/index sharing、compressor state、Engram、mHC 和 speculative decoding 后，至少出现以下状态：

• compressed global KV；
• per-layer sliding-window KV；
• indexer key / scale；
• sparse candidate / Top-K selection metadata；
• compressor 的 partial / resumable state；
• Engram 的 n-gram / lookup 相关状态；
• 多路 residual / mHC state；
• speculative decoding 的 draft、target、verification / commit state。

因此真正的问题从“KV block 放在哪里”变成：谁拥有状态、谁消费状态、生命周期多长、哪些状态必须传输、哪些可以重算。

模型结构前置笔记：DeepSeek V4.1-Flash 架构拆解：CED、CSA2、Engram、mHC 与 DSpark。

2. Cache Manager：从二维 block table 走向状态依赖图

CSA2 允许多个层共享物理 KV owner，并进一步复用 index/candidate。逻辑上可以抽象为：

physical owner A
   ├─ compressed KV
   ├─ indexer K / scale
   └─ candidate metadata
        │
        ├─ layer 20 consumer
        ├─ layer 21 consumer
        └─ layer 22 consumer

这会逼迫 runtime 明确区分：

Logical layer：模型定义中的第几层。

Physical state owner：实际分配缓存的层/对象。

Consumer：读取 owner 状态的其他层。

Lifetime：最后一个 consumer 完成之前，slot 都不能被提前回收。

于是 cache manager 需要处理 alias、引用计数、跨层依赖和取消请求后的安全清理。若仍按“一层一份 cache”粗暴复制，不仅浪费显存，还可能破坏共享语义。

这与已有 PD 分离、DCP 与 KV Pool：计算分工、缓存分片和跨节点复用 的 KV Pool 概念不同：KV Pool 解决跨请求/实例的缓存存放与复用；这里讨论的是单个模型内部的状态所有权与依赖图。两者会在实际 serving 中叠加。

3. PD 分离：交接对象不再只是“一坨 KV”

vLLM-Ascend 的 V4.1 Roadmap 明确把 P/D handoff state 拆得很细：Sliding-Window KV、compressed long-context KV、indexer keys/scales、可恢复的 compressor state，并要求保留 shared-cache ownership，使同一个 physical owner 只传一次；Engram 的 N-gram history 在 P→D 边界也需要定义持久化还是重建。vLLM-Ascend DeepSeek V4.1 Roadmap

可把 Prefill 结束时的状态抽象为：

S_P = {G, L, I, C, E, ...}

G = global compressed KV
L = local sliding-window KV
I = indexer / sparse-selection state
C = compressor resumable state
E = Engram-related history/metadata

Decode 端不一定需要把每一项都原样持久化，但必须满足一个更严格的条件：恢复后的状态足以让第一个 decode step 与未分离执行保持语义一致。

所以 PD 的工程问题由：

“KV 怎么从 P 卡搬到 D 卡？”

升级成：

“模型的最小可恢复状态集合是什么？哪些状态传、哪些重算、哪些共享、哪些需要布局转换？”

适用条件也更严格：P/D 端至少要对 checkpoint、tokenization、cache dtype / scale、compression ratio、block/layout、owner mapping 有一致理解；若两端异构，则 connector 必须显式完成转换，而不能依赖偶然兼容。

4. DCP：不仅要分 KV，还要保持稀疏索引的全局一致性

传统 DCP 的直觉是沿 context/token 维度分片历史 KV，让多个 rank 各自处理一部分历史，然后合并 attention 结果。已有专题：Decode Context Parallelism（DCP）详解：长上下文解码中的 KV Cache 分片、通信与 vLLM/昇腾实现。

在 CSA2 下，DCP 多出两个问题：

1. KV/index cache 如何共同分片：compressed KV 与 indexer metadata 不能彼此失配。
2. Sparse Top-K 如何全局一致：如果每个 rank 只看本地候选，局部 Top-K 并不天然等价于全局 Top-K；需要定义 ownership、候选交换/merge 或等价的分布式选择算法。

vLLM-Ascend Roadmap 因此单独列出 sliding-window 与 compressed sparse attention 的 DCP、global/local position 语义、sparse-index ownership 和 distributed result merging。V4.1 Roadmap

这说明 DCP 已不只是“KV 容量优化”。它开始进入 模型稀疏算法的分布式实现。

5. Sequence Parallel / Pipeline：token state 与 residual state 也需要对齐

当 Engram lookup 依赖 token-shaped input IDs / N-gram 历史，mHC 又引入额外 residual/mixing state 时，Sequence Parallel、Pipeline Parallel 的边界不再只需要一个 hidden tensor。

实践中应逐项核对：

• token/position 是否在 SP rank 间保持正确映射；
• Engram lookup 所需历史是否本地可得；
• mHC state 在通信前后是否完整；
• chunked prefill 的分块边界是否恰好切断 compressor / n-gram / window 状态。

这类问题很容易表现成“服务能拉起但精度异常”，所以不能只用启动成功判断功能支持。

6. Memory Hierarchy：Engram 把 Host DRAM / NUMA 重新拉进核心路径

传统大模型的性能中心常被简化为：HBM 容量、HBM bandwidth、Tensor Core / AI Core、GPU/NPU 间通信。

Engram 这样的巨大稀疏查找表改变了访问模式：

Dense GEMM / MoE
  → 大块、规则、可批处理

Engram lookup
  → 稀疏、随机、每次只访问少量行

后者更容易受到以下因素影响：

• Host DRAM bandwidth / latency；
• NUMA placement；
• PCIe / CXL / NVLink / NPU Host link；
• page size、TLB miss、page walk；
• lookup batching、prefetch 和 locality。

因此以后 memory planning 不能只画一层 HBM。更合适的模型是：

HBM：当前活跃 KV / window / compute workspace
   ↕
Host DRAM：超大稀疏表、可回载 cache、外部 memory
   ↕
SSD / NVMe：持久化 prefix / KV pool

而 bounded replay 又增加了第四个选择：不存，未来重算。

系统优化因此变成 compute ↔ HBM ↔ DRAM ↔ SSD ↔ network 的联合成本模型。

7. 量化：低比特表示开始进入模型状态契约

V4.1 不只是“权重低比特”。公开技术报告描述 main compressed KV 使用 FP4 路径，local SWA KV 使用 FP8。此时 dtype、scale、rounding 与 layout 都成为 cache 的一部分语义。

这带来两个工程结论：

第一，kernel fusion 不能只追求少一次读写。 如果原计算图中间存在定义好的 quantize/dequantize/scale 行为，融合后必须保持允许误差范围内的数值语义。

第二，不同硬件后端不能机械照搬同一个低比特方案。 vLLM-Ascend 当前 V4.1 Roadmap 对 A2/A3 的 MoE 量化目标是 W8A8，A5 才列出 W4A8；这是平台能力和实现成熟度约束下的 roadmap，不应把 CUDA/Blackwell 上的 FP4 路径直接等同于 910C/A3 的支持路径。V4.1 Roadmap

这与已有 W8A8C8 与 GPQA：把量化位宽、数值误差和模型能力分开看 的结论一致：W/A/C 位宽不仅影响容量和速度，也会进入质量验证和模型 contract。

8. MoE 通信：模型支持必须写成“拓扑 × 并行 × 后端 × 版本”的矩阵

V4.1 仍是大规模 MoE，EP / All-to-All 通信继续是核心问题。vLLM-Ascend Roadmap 同时追踪 MC2、fullmesh_v2 等路径，但这只是支持计划。

截至 2026-09-12 的公开 issue，有用户在 2 个 A3 节点、DP4 / TP8 / EP32 上部署 DeepSeek-V4.1-Flash 时报告多种 MoE 通信路径均失败，涉及 MoeDistributeDispatchV2 kernel fault 或 HCCL AllGather mismatch。vLLM-Ascend Issue #16419

它说明一个重要实践原则：

“支持 DeepSeek V4.1”不是布尔值。

真正的支持矩阵至少应写成：

model checkpoint
× quantization
× device generation
× node count / topology
× TP / DP / EP / DCP
× communication backend
× vLLM / vLLM-Ascend / CANN version
× feature combination

这也是为什么单机混部成功不能直接推出双机 EP、PD、DCP 或 KV Pool 已可用。

9. Scheduler：CED 让 Prefill 与 Decode 的资源模型进一步分裂

CED 的 input-active / output-active 参数量不同，本身就说明输入阶段和输出阶段的计算强度不同。再叠加 global compression、SWA、Engram 和 sparse retrieval 后，P 与 D 可能在以下维度呈现不同最优配置：

• batch size；
• tensor / expert parallel degree；
• HBM 预算；
• Engram placement；
• kernel 组合；
• CPU/Host memory 与 IO 预算。

这使 PD 分离不只是“避免长 Prefill 阻塞 Decode”，而进一步可能成为 异构资源配置问题：P worker 与 D worker 不必长得一样。

但是否值得异构化必须用真实 workload 验证。若传输和状态转换开销大于阶段隔离收益，理论上的非对称性不会自动变成线上收益。

10. DSpark / Speculative Decoding：feature cross-product 开始爆炸

Speculative decoding 单独实现时已经要管理：draft → verify → accept/reject → rollback / commit。

如果再同时打开：

PD separation
× DCP
× Prefix Cache
× KV Pool
× CSA2 cross-layer sharing
× DSpark

状态生命周期会彼此耦合。例如：

• prefix hit 后 draft state 怎么初始化；
• P→D 时传 target state 还是同时传 speculative state；
• rejected token 的 compressed/window/cache owner 状态如何回滚；
• DCP shard 上的 candidate/index state 如何保持一致；
• 请求取消时共享 slot 什么时候才能释放。

这类 feature cross-product 是未来 serving framework 复杂度增长的主要来源之一，而不是简单增加若干 kernel。

11. 对 910C / A3 的现实含义

截至 2026-09-16，vLLM-Ascend 已建立 DeepSeek V4.1 专门 Roadmap，但大量项目仍是待完成或待验证目标。对 A2/A3，公开路线主要围绕 W8A8、Sparse Attention / Compressor / Indexer / Engram / mHC、MoE 通信、DCP、PD、KV Pool 等逐项适配。V4.1 Roadmap

因此在 Ascend 上做 V4.1，不应把任务理解成“新增一个 model class”。真正工作链更像：

model semantics
   ↓
state/cache abstraction
   ↓
Ascend kernel / quant path
   ↓
HCCL / MoE communication
   ↓
distributed parallelism
   ↓
PD / KV transfer / pool
   ↓
accuracy + performance validation

这也解释了为什么在 Ascend 生态里，模型结构知识与 infra 知识很难彻底分开：上游每增加一个新的模型 primitive，都可能要求后端重新实现 kernel、通信和 state management。

12. 推荐的实践验证顺序

不要一开始就把 PD、DCP、Pool、speculation 和跨节点 EP 全开。更稳妥的是建立逐层递增的实验矩阵：

1. 单节点最小基线：关闭额外缓存/并行 feature，验证 logits / benchmark / 基础 decode。
2. 长 Prefill 与 chunked prefill：覆盖 compression boundary、window boundary、不同 prompt 长度。
3. Prefix Cache：比较 cold / hit 输出和 TTFT，验证 replay / partial state。
4. PD 分离：先只做同构 P/D，验证第一个 decode token 与混部 baseline 一致。
5. DCP：检查 shard mapping、index candidate merge 和长上下文 TPOT。
6. KV Pool / 外部存储：记录实际 transfer bytes、hit rate、回载时间和重算时间。
7. 跨节点 EP / MoE：再引入真实 HCCL / 网络拓扑。
8. Speculative decoding：最后叠加 rollback/commit 复杂度。
9. 高并发：观察 cache pressure、fragmentation、tail latency 与失败恢复。

每一步至少记录：

checkpoint / quant config
vLLM + vLLM-Ascend + CANN version
device / node / topology
TP / DP / EP / DCP / PD config
cache dtype + block size + compression ratio
TTFT / TPOT / throughput / P95/P99
HBM / Host DRAM / SSD occupancy
KV transfer bytes + latency
prefix hit rate / replay tokens
MoE collective time
accuracy / logits diff / benchmark score

13. 正确性测试比“服务拉起”更重要

V4.1 这类模型建议把以下 invariants 直接纳入 CI / 回归：

• 混部 baseline 与 PD 第一个 decode step 对齐；
• cold prefill 与 prefix-cache hit 在允许容差内一致；
• chunk boundary 前后不改变 compressor / SWA 语义；
• compression ratio = 1 / 2 都覆盖；
• cross-layer owner 只分配/传输一次，但所有 consumer 都可正确读取；
• request cancel / preemption 后 slot 无泄漏、无提前复用；
• 多 rank 稀疏 Top-K 与单机 reference 一致；
• 量化 kernel 更换后重新跑精度，而不是只比较吞吐。

这类测试能把“偶发精度异常”从最终 benchmark 阶段提前到状态边界定位阶段。

14. 对 inference infra 学习框架的扩展

从 V4.1 可以把推理 Infra 的知识树增加一条一级主线：

Model State & Memory Architecture

KV representation
├─ MHA / GQA / MLA
├─ compressed KV
├─ sparse index / candidate
├─ cross-layer ownership
├─ sliding-window state
├─ recursive state
├─ external memory / Engram
├─ replayable state
└─ speculative state

Runtime operations
├─ allocate / alias / evict
├─ shard / merge
├─ transfer / restore
├─ persist / reload
├─ recompute / replay
└─ commit / rollback

它连接了你此前单独学习的 MLA/DSA/KDA、DCP、PD、KV Pool、Mooncake/AscendStore、量化、MoE 通信与长上下文。换句话说，这些不是零散 feature，而是在共同回答一个问题：

大模型推理过程中产生的“状态”应该如何表示、放置、移动、共享、恢复和验证？

15. 相关笔记

• 模型结构：DeepSeek V4.1-Flash 架构拆解：CED、CSA2、Engram、mHC 与 DSpark
• MLA / DSA / KDA：MLA、DSA 与 KDA：三种 Attention 优化如何改变缓存与推理
• DCP：Decode Context Parallelism（DCP）详解：长上下文解码中的 KV Cache 分片、通信与 vLLM/昇腾实现
• PD / DCP / KV Pool：PD 分离、DCP 与 KV Pool：计算分工、缓存分片和跨节点复用
• W8A8C8 与精度：W8A8C8 与 GPQA：把量化位宽、数值误差和模型能力分开看

16. 主要资料

• DeepSeek-V4.1-Flash 官方发布
• DeepSeek-V4.1-Flash 模型仓库
• vLLM-Ascend DeepSeek V4.1 Roadmap RFC #16375
• vLLM-Ascend 双节点 A3 MoE 通信问题 #16419

一句话收束：V4.1 的价值不只在于“更省 KV”，而在于它清楚展示了下一代 inference engine 的方向——模型算法、状态管理、分布式通信与存储层级会越来越深地共同设计。