DeepSeek V4.1 Flash：从架构到推理成本

长上下文推理的成本，不只有 attention 的乘加。相同历史在多少层各存一份、命中前缀后还要恢复哪些状态、一个输出 token 要走几次模型，都可能改变系统的瓶颈。

DeepSeek V4.1 Flash 把这些问题放进同一套设计：CED 缩短多数输入 token 的计算路径，CSA2 共享跨层历史，Engram 提供可提前寻址的条件记忆，DSpark 改变输出 token 的生成与验证方式。本文沿这些数据流分析成本，最后对照公开代码说明哪些能力还不能据此认定已经运行。

关心架构先读第 1–3 节；关心容量看第 4 节；评估实际部署时结合第 5–8 节与第 10 节的 Runtime 对照。文中的层号统一从 0 开始。

1. 先区分参数规模、执行路径与存储规模

官方模型卡分别列出 552B backbone 参数与 196B Engram 参数，并报告 Prefill / Decode 每 token 激活参数约为 8B / 16B。这些数字描述的对象不同：backbone 是模型权重规模，Engram 是条件查询表，激活量描述一次计算经过的参数。不能将它们统一乘以某个字节数，直接得到一张 GPU 的显存需求。

下面分别讨论三种减少成本的方法：少执行一些层、少存几份历史、少做重复索引。它们作用于不同环节，不能把各自的压缩比例直接相乘得到加速比。

2. CED：为什么输入和输出不再走同样长的路径

CED 的关键是 decoder 的全局 KV 从最终 encoder hidden states 投影得到。因此，为历史输入建立 decoder 全局缓存，不必让每个输入 token 完整经过全部 decoder 层。这是官方报告中 Prefill 激活量小于 Decode 的架构原因。

flowchart TB
    A[输入 embeddings] --> B[Encoder · 20 层]
    B --> C[Encoder 输出]
    C --> D[投影全局 KV]
    C --> E[末尾窗口恢复 SWA]
    D --> F[开始 Decode]
    E --> F
    F --> G[新 token：完整 40 层]

全局 KV 可以这样建立，局部 SWA 却依赖各 decoder 层自己的 hidden states。报告采用 SWA Bounded Replay：让 prompt 末尾最多一个窗口的 encoder 输出继续通过 decoder，为开始 Decode 准备局部状态。Decode 生成的新 token 仍经过全部 40 层。

这给出了一个比“Prefill 只用一半参数”更实用的成本模型：

这里 $S$ 是无前缀命中时的输入长度；各项按串行阶段记账，不假设相等，也不计排队时间；存在重叠时应改用实际墙钟关键路径。长输入时末尾 replay 相对较小；短输入时，它可能占据明显比例。因而 8B / 16B 激活量不能推出 TTFT 恰好减半，更不能推出 Decode 也减半。

3. CSA2：共享历史，不共享整层输出

3.1 先数清三个可复用对象

参考实现中，SharedAttentionRuntime 分别传递 compress_kv、index_k 和 topk_idxs。这三个对象对应历史表示、用于检索的 key、当前 query 选中的位置。

发布配置的安排可以直接读成下面的分组：

Encoder  0–1    SWA only
         2–7    Full + Reuse × 5     compression ratio 2
         8–13   Full + Reuse × 5     compression ratio 2
        14–19   Full + Reuse × 5     compression ratio 2

Decoder 20–23   Full + Reuse × 3     compression ratio 1
        24–27   Reindex + Reuse × 3  共享 layer 20 的 global KV
        28–31   Reindex + Reuse × 3  共享 layer 20 的 global KV
        32–35   Reindex + Reuse × 3  共享 layer 20 的 global KV
        36–39   Reindex + Reuse × 3  共享 layer 20 的 global KV

对容量建模，按 4 个 KV source 数缓存；对索引计算，按 8 个 index-producing layers 数操作；对 attention 与 MoE 计算，仍要按各层实际执行计数。把 Reuse 层整个删掉，会同时低估计算和通信。

3.2 两级索引缩短的是后续搜索域

Decoder 的 layer 20 先对可见历史评分，同时选择至多 2048 个块，每块 8 个位置，形成至多 16,384 个候选位置。后续 Reindex 层在这个池中重选自己的 top-512；它们选中的位置可以不同。

这里有三个不同规模：完整可见历史、候选池、最终 attention top-k。16,384 不是每层 attention 都要读取的条目数，512 也不是首次索引只需扫描的条目数。

对单个 Decode query，忽略常数项与选择开销，可以写出一个索引评分工作量的结构式：

前三项来自 encoder 的 3 个索引源、decoder 的首次全局索引及 4 次候选池重评分。这个式子仅数被评分的位置，不是 FLOPs 或 kernel 时间；它说明后续索引有上界，但整网仍保留随上下文增长的扫描项。

4. 890 B/token 是怎么得到的

可从配置和参考代码里的量化分组，独立推导一个理想紧凑存储口径。

Main KV 每条 512 维，4 bit 数据配每 16 维一个 1 byte scale；indexer K 每条 128 维，4 bit 数据配每 32 维一个 1 byte scale。因此：

三个 encoder source 各以 2:1 压缩保存历史，一个 decoder source 以 1:1 保存。忽略页尾取整后，每个原始 token 对应的全局缓存是：

这与模型卡给出的全局 KV 数字一致。按此口径，1,048,576 token 的单请求逻辑全局缓存为 890 MiB。这里已经包含 main KV 和 indexer K 的 scale，不能再只按“4 bit × 维度”计算。

这套设计把“需要保存多少份历史”与“每份历史需要多少字节”一起降低。与此同时，每层 query 仍需访问所选历史；共享存储不自动保证跨层共享 HBM 读取，需要实际 kernel 和 cache 行为支持。

5. Prefix 复用：容量换回来的是什么

Global KV 和 SWA KV 的生命周期不同。前者覆盖长历史，适合持久化；后者是每层近期窗口，恢复时还受前层状态影响。

报告中的 Encoder SWA Bounded Replay 处理一种具体情况：全局前缀缓存命中，但 encoder SWA 状态已不在。系统重放命中前缀末尾一个窗口，复用已有 global KV，重建 SWA，再处理新增后缀。Decoder 则在 Prefill 末尾为 Decode 准备 SWA，不将其作为持久化前缀状态。

这个恢复是近似的。 只重放一个窗口，截断了更早的局部依赖；它与完整前向的 SWA 状态并不数学等价。报告中的质量验证不能替代具体部署对 cache-hit 边界、任务和精度的验证。

因此，评估这种缓存设计至少要同时记录三件事：省下的持久化字节数、命中后的 replay 开销、恢复路径的输出质量。只给 hit ratio 会漏掉恢复成本；只要求逐位一致，又会把原设计的近似语义误当成实现 bug。

6. Engram：先知道地址，才可能提前取数据

在固定配置中，Engram 位于 layer 1 和 14。参考 Engram.forward 的数据流是：token n-gram hash → 查询 embedding rows → K/V 投影 → 与当前 hidden state 计算 gate → 写入残差流。它查询离散 token 历史，不随请求增长为另一套 KV Cache。

每个模块采用 2、3、4 阶 n-gram，每阶 8 个 hash heads，每个 head 取 256 维。忽略重复地址和传输对齐，每 token、每模块的查询结果逻辑大小为：

如果传回 FP8 行，则约为 6 KiB/module/token，两个模块约 12 KiB/token，另有量化元数据。这是请求的数据量估算，不是 196B 参数整表的搬运量，也不是已经测得的网络流量。

地址由 token 决定，使它有机会早于消费层发起预取。若选择 host / RDMA 放置，性能问题应写成“传输有多少暴露在关键路径上”：

这里 $T_{\mathrm{lead}}$ 是可用的提前量。带宽、请求粒度、并发争用和重复行复用都会改变结果。确定性地址只提供调度机会，不能证明完全隐藏传输；而 host 放置也应被当作部署选择，不能仅凭模型含有 Engram 就认定已经 offload。

7. DSpark：看每轮提交多少 token

配置中的 num_nextn_predict_layers=3 描述 draft 模型深度；dspark_block_size=5 描述并行草稿位置数。参考代码还单独实现了 Markov head 与 confidence head，所以不能把它简化成“普通 MTP 连跑三步”。

草稿生成、target 验证和最终提交是三个阶段。对单个请求的连续验证轮，评估收益时可以统计：

分子是该请求观测窗口内各轮实际耗时，分母是同期提交的输出 token，包含实现规定的 bonus / correction token；不要只除以 draft 长度或被接受的草稿数。若组件并行执行，各组件耗时之和也不能直接代替整轮墙钟时间。服务整体吞吐另以总提交 token 数除以观测窗口墙钟时间计算，不能将并发请求的轮耗时相加作为分母。

报告描述的 confidence 调度会结合接受概率预测与 engine profile 选择验证长度。要在自己的服务里认定这条路径生效，至少要看到实际 draft/verify 调用、每轮验证长度和提交数。配置字段、模型里存在 forward_spec，都不足以证明生成循环已经启用投机解码。

8. 公开参考代码与报告路径：逐项核对

本次核对的 inference/README.md 将其定位为可读参考实现，并明确生成采用普通自回归采样。具体到 model.py，可以得到更精确的范围：

读模型源码时，这一步应当先于性能估算。同一份权重在不同 runtime 中可能采用不同缓存布局和执行路径；报告、参考实现与某个实际服务的结果需要分别引用。

9. 与 Kimi K3 放在一起看

Kimi K3 把多数层的历史压进固定 recurrent state；V4.1 Flash 保留可检索的压缩全局历史，同时减少跨层副本与重复索引。两者让性能分析关注不同的对象：

• K3 要看 state 更新与搬运、周期性 MLA 扫描，以及 KDA checkpoint 与 MLA cache 的共同命中边界。
• V4.1 Flash 要看 KV source 的共享关系、索引搜索域、SWA 恢复和 CED 实际执行路径。
• 两者都仍需单独分析 MoE 权重访问、专家通信及调度；attention 更省不代表整网瓶颈同比例缩小。

下一步的验证应从固定 runtime 的真实路径开始：确认 cache dtype/layout、Prefill 层执行、prefix 恢复和投机生成，再在相同硬件、并发及输入/输出长度下比较 TTFT、TPOT 与满足 SLO 的吞吐。本文的推导提供待测对象，不给出未经测量的速度排名。

10. vLLM 0.31：把模型机制接到实际执行路径

vLLM 0.31.0 的固定提交是 db9527a46873454610df6dbedf79a36d6bf1a7f6。本节检查其中的 NVIDIA 实现；AMD、其他 backend 与后续 main 的能力应分别核对。第 8 节对参考实现的判断继续成立，它描述的是另一个固定版本的代码。

10.1 先记录 resolved backend，再算 cache bytes

_select_dsv4_attn_cls 会先处理显式 backend。自动选择时，SM12 走 FlashInfer；满足 kernel 与拓扑条件的 SM10x 使用 FlashMLA mega attention，其余组合继续进入其他 FlashMLA 路径。仅写“Blackwell + vLLM”不足以固定执行合同。

Mega attention 把 Q RoPE、稀疏 attention、输出 inverse RoPE 和 FP8 cast 放进融合路径。它偏好的压缩 cache dtype 是 nvfp4_ds_mla；该格式仍保留 FP8 sliding-window record，只有 compressed cache 使用 NVFP4。auto / fp8 在 packed 路径中会被解析为 kernel 偏好的具体格式，并回写 cache configuration。

采集证据时同时保存：resolved backend、resolved KV dtype、每组 cache shape、record/page size、SWA 与 global KV 的层级拥有者，以及 allocator 的 resident/peak bytes。这样才能回答紧凑格式是否真正减少了显存。

10.2 Prefix 命中需要恢复的状态比 global KV 多

这个版本的发布说明列出 SWA bounded replay，并将 sliding-window KV 排除在持久化 prefix caching 之外。它与第 5 节的模型设计一致：复用 global KV 后，还需准备局部窗口状态。恢复质量与 replay 边界仍需要运行验证。

Engram 另有一类很小但影响正确性的状态：n-gram 所需的历史 token IDs。common/engram.py 明确说明，slot-keyed hash history 不属于 KV payload，从别的实例加载 KV 不会填好这些 slots。Model Runner 因而提供 lookback_token_ids：V2 使用设备上的 token history，V1 的 async 路径还需要区分 prompt IDs 与生成位置的占位。

因此，在 P/D 与 offload 实验中，应把“KV 已经加载”与“所有 forward 前置状态已经齐全”分成两次检查。长前缀命中、chunk 边界、首个 decode token、投机回退与多模态边界都要进入正确性用例。

10.3 Engram 的表、投影与 DP 共享分别落账

源码已经提供 pinned host memory + UVA 的表查询，以及独立 CUDA stream 上的预取。它不是对全模型权重统一启用一次普通 CPU offload：查找地址来自 token IDs，前置层计算为查询提供提前量。

• 大查找表：按 hash head 的 bucket ranges 分片，每 rank 保存对应 FP8 rows 和 ue8m0 scales。
• wkv 投影：无 sequence parallel 时使用 ColumnParallelLinear(..., gather_output=True)；开启 sequence parallel 时 disable_tp=True，每 rank 对自己的 token 分片执行完整投影。
• 同机 DP 共享：DPSharedEngramStorage 通过 /dev/shm、MAP_SHARED 与 cudaHostRegister 让同一节点内的 DP ranks 访问一份 host shard。每 replica 只预取自己的 tokens，省去 Engram 的逐步 DP hashes/rows exchange；TP 侧的 gather 仍存在。

启动阶段还会广播共享文件路径、同步映射和权重加载。这里的“无逐步 Engram DP collective”描述稳态查询，并不表示启动阶段或整个模型都没有 collectives。

完整的容量公式、拓扑约束、配置与构造路径差异，以及实验矩阵见 Engram：TP 分片与同机 DP 共享。

10.4 对照表：实现已存在，收益仍需闭环

先做 eager、固定输入与缓存状态的正确性对照，再启用目标 graph/backend，最后比较相同 ISL/OSL、到达率、并行与 topology 下的 TTFT、ITL 和 SLO-goodput。单项 Kernel 融合可以改变局部时间，系统收益还受到 host 查询、通信、排队和 KV loading 的共同约束。

相关页面

• Kimi K3 架构、训练与推理系统固定状态与混合缓存的另一条路线。
• CSA/HCA 注意力V4 的背景机制；应与本文 V4.1 的 CSA2 版本区分。
• DSpark 与 MTP草稿、验证与调度的专题解释。
• KV Cache容量、分页与前缀复用的基础概念。
• FP4/FP8 量化数据格式、scale 与实际存储的区别。
• Engram：TP 分片与同机 DP 共享表、投影、host 映射与预取的源码研究。
• 分层 KV Cache命中、加载与完整状态恢复的合同。
• P/D 分离从 Prefill 到 Decode 的传输与排队关键路径。

主要来源

• DeepSeek V4.1 Flash 技术报告 v1 — CED、SWA Bounded Replay 与生产系统描述。
• 官方模型卡 · dba1be0a — 参数规模与发布范围。
• 发布配置 · dba1be0a — 层数、source layers、压缩比例与 DSpark 配置。
• 推理参考代码 · dba1be0a — Attention、Indexer、Engram、DSpark 与实际 forward 控制流。
• 参考实现说明 · dba1be0a — 运行范围与生成路径限制。
• vLLM 0.31 发布说明 — 新 Runtime 路径的版本入口。
• vLLM NVIDIA 实现 · db9527a — attention backend、Engram 预取与共享存储。