← 架构总览 专题深度分析 · 新架构 × 昇腾性能机会 专题目录

DeepSeek V4.1-Flash 的 CED/CSA2 架构 × vllm-ascend 性能协助点

DeepSeek V4.1-Flash 性能机会点 ×7 基线 vllm-ascend a71b766ce（2026-09-23）· 模型 2026-09-10 发布

接力棒：本文是需求故事 《DeepSeek V4.1-Flash 登陆昇腾（PR #16925）》的续篇—— 那篇讲"改了什么"，本文讲"模型设计给了什么红利、昇腾兑现了多少、还差什么"。建议先读前篇。

本文回答两个问题：

  1. CED / CSA2 到底新在哪？——第二、三节：每个机制配一张"模型说 / 昇腾做 / 差距"对照表，一眼看到哪些对齐了、哪些没兑现。
  2. 哪些"模型设计红利"还没被昇腾吃到？——第五节：7 个性能协助点（P1–P7），先给全局优化地图和总览表，再逐条展开。

一、模型速览：890 B/token 是怎么来的

读图指引：这张图回答"890 B/token 的全局 KV 是怎么算出来的"—— 主链上三刀：CED 砍"谁产 KV"（解码器不自己产，从编码器投影），CSA2 砍"读多少"（三模式共享索引），FP4 砍"每份多大"； 旁路三件（Engram / DSpark / SWA Replay）负责让 decode 维持在低 KV 压力下。
图1 · V4.1-Flash 架构总览（LR）
graph LR A[输入 文本/图像] --> B[CED 20层因果编码器] B --> C[末端隐状态
一次性投影] C --> D[解码器全局KV
FP4 · 890B/token] B --> E[CED 20层解码器
SWA + CSA2 稀疏] E --> F[输出 hidden → logits] G[Engram 记忆 196B] -. 命中注入 .-> E H[DSpark 投机解码] -. 草稿/验证 .-> E I[SWA Bounded Replay] -. 重建滑窗KV .-> E
项值 / 机制
总参数 / 激活552B MoE（1 共享 + 384 路由专家、激活 6）；每 token 激活 prefill 8B / decode 16B
层结构（CED）40 层 = 20 层因果编码器 + 20 层解码器；解码器全局 KV 由编码器末端隐状态投影而来
注意力（CSA2）每层静态分配 Full / Reindex / Reuse 三模式；跨层共享主 KV 与索引 K、复用 Top-K 索引；解码器端分层稀疏索引器让深层索引成本与上下文长度解耦
KV 缓存FP4（E2M1，每 16 通道一个 E4M3 scale）主 KV；全局 KV 890 B/token（≈V4-Flash 的 1/4）；持久 KV ≈ V4-Flash 的 1/8
上下文训练 64K 稀疏注意力，外推 1M
条件记忆 / 投机Engram（196B 稀疏查表）；DSpark 半自回归草稿 + 置信度调度验证
昇腾部署形态A3 双机 16 卡 DP4×TP8+EP、--block-size 128、W8A8 ModelSlim（教程）

二、CED 拆解 × 昇腾现状：KV 的"出身"变了

读图指引：这张图回答"解码器的 KV 从哪来、为什么 prefill 决定一切"—— 编码器 20 层只在 prefill（含 chunked prefill）干活，末端隐状态一次性投影出全局 KV 写入缓存； decode 只消费。看清楚这条主链，第五节的 P1（融合压缩）和 P7（PD 分离）就都有了着力点。
图2 · CED 数据流（TD 时序）
sequenceDiagram participant T as 输入 token participant E as 编码器（20 层 causal） participant P as KV 投影（末端隐状态） participant D as 解码器（20 层） T->>E: prefill（激活 8B/token） E->>P: 最后一层隐状态 P->>D: 投影压缩全局KV（四槽页） D->>D: decode：读压缩KV+SWA
（激活 16B/token） D->>D: 滑窗缺失按 Bounded Replay 重建 D-->>T: hidden → logits（chunked 循环）

模型说 / 昇腾做 / 差距

模型说昇腾做（a71b766ce）差距
解码器全局 KV 由编码器末端投影，压缩比 1/2compressor.py:14 投影：ratio-2 走 Triton 环形池化（:53）+ 32 行状态环（cache_config.py:22）；四槽页打包见 cache_config.py:47ratio-1 还是 wkv+RMSNorm 两个小算子 → P1
编码器 20 层只在 prefill 参与model.py:494 build_layer_plan 静态拓扑：源层/消费者/候选源启动时定死未映射到 PD 分离部署 → P7
压缩状态逐源层维护32 行 FP32 状态环（CircularBufferSpec）+ dsa_v41.py:378 仅源层写压缩缓存已对齐 ✅
代码 · ratio-1 压缩路径：目前就是两个小算子（compressor.py:67）
看这段代码，只需抓一个点：这两步就是 P1 要融合掉的全部—— V4 已有按架构选键的融合 Compressor 模板，V4.1 还没接上。
def forward(self, x):
    """Project an uncompressed source; ratio-2 uses ``pool_projected``."""
    return self.norm(self.wkv(x))  # ⚡ratio-1：Linear + RMSNorm 两个小算子串行（见机会点 P1）

三、CSA2 拆解 × 昇腾现状：40 层不用各算各的索引

读图指引：这张图回答"40 层注意力为什么不用各算各的索引"—— 首个 Full 层把候选池建好（无过滤位置 TopK + 候选块 ID），后面的层要么在池内重排（Reindex）， 要么直接复用共享 TopK（Reuse）。一次索引工作，全模型摊薄。
图3 · CSA2 三模式与分层索引器（LR）
graph LR A[首个 Full 模式层
候选源] --> |候选块 INT32（-1 填充）| B[Reindex 模式层
候选消费者] B --> |共享 topk_indices 复用| C[Reuse 模式层
普通位置 TopK] A -. 主KV/索引K 共享 .-> B A -. 同页打包 .-> C

模型说 / 昇腾做 / 差距

模型说昇腾做（a71b766ce）差距
Full / Reindex / Reuse 三静态模式model.py:494 拓扑字段：is_candidate_source / uses_candidate_filter / 共享 topk_indices（SharedAttentionState model.py:476，定址稳定适配 ACL Graph）已对齐 ✅
分层稀疏索引器（候选池逐层收窄）QLI V3 算子（QLI = Quantized Lightning Indexer，量化闪电索引器）：npu_quant_lightning_indexer_v3（indexer.py:210）候选三模式一个算子已对齐 ✅
FP4 主 KV（E2M1，每 16 通道一个 E4M3 scale）SparseFlashMla 只编 BF16 的 TND/PA_BBND 调用（TND/PA_BBND = 查询按 token×头、键按分页块×头存放的两种张量布局）未兑现 → P2（最大单项）
单头 CSA 内核特化A2/A3 编 6 键含单头 CSA 特化；A5 编 12 键仅 split-G 寻址A5 缺口 → P3

算子契约速记（仓库 QLI 开发者指南 · A3 现状）

四、算子通道现状：本需求用到了哪三条通道

通道本需求用到的算子 / 内核位置
torch.ops._C_ascend
（自研 AscendC）		npu_sparse_flash_mla（SWA 滑窗 + 压缩全局 CSA 双阶段，带 sinks 与 mask mode）
npu_quant_lightning_indexer_v3（INT8 索引 + 候选三模式）
inplace_partial_rotary_mul（interleave 部分旋转，输入/输出两处原地）		dsa_v41.py:477 _forward_attention
models/deepseek_v41/indexer.py:210
dsa_v41.py:270 _project_kv / :547（forward 内）
triton-ascendcompressor_from_projected（ratio-2 环形池化）
prepare_indexer_indices / quantize_indexer_query
Engram INT8 gather-dequant（设备/主机 UVA 两份 kernel）		compressor.py:54
indexer.py:16-17
models/deepseek_v41/engram/npu.py:64 / :235
主机侧扩展
（ctypes / UVA）		HostUvaBuffer（UVA = Unified Virtual Addressing，主机钉住内存可被设备直接寻址）+ 主机库 ctypes.CDLL；SharedUvaBuffer 跨 DP 副本共享（#17134）engram/npu.py:156 / :173 / :325

五、性能协助机会点：7 个点打在链路哪一段

读图指引：这张图回答"7 个点分别打在执行链路哪一段"—— P1/P2 打 prefill 与 KV 存取（模型红利兑现），P4/P5/P6 打 decode 路径（流水压榨）， P7 是部署形态级红利，P3 是硬件模板补齐。看图定优先级，再看总览表，最后需要细节才往下读卡片。
图4 · 全局优化地图：7 个机会点的落位（TD）
graph TD A[Prefill：压缩与KV生成] --> P1[P1 融合Compressor] A --> P2[P2 FP4 main KV] B[Decode：稀疏注意力与投机] --> P4[P4 Engram 异步查表] B --> P6[P6 decode 双流深化] B --> P5[P5 DSpark 元数据复用] C[部署形态] --> P7[P7 CED×PD 分离] D[硬件内核模板] --> P3[P3 A5 CSA 特化]

总览表（按优先级排序）

P#打在哪一句话现状优先级
P1prefill KV 生成融合 Compressor 模板扩展覆盖 V4.1 压缩比 1/2V4.1 还在小算子（文档明说）★★★
P2KV 存取带宽/容量SparseFlashMla 增加压缩侧 FP4 cmp_kv 模板只编 BF16；模型原生 FP4★★★
P7部署形态编码器锁 P 节点 + layerwise KV 传输压缩 KVPD 能力已就绪，V4.1 未映射★★（专项）
P6decode 流水indexer/SWA 写入编入双流事件链双流框架已有，覆盖面可扩★★
P4decode 访存Engram 查表挪辅助流 + lookback 预取同步 UVA gather★（需 profile）
P5decode 投机元数据缓存移植 + draft/target 候选共享DSA 路径已验证同款手法★（需 profile）
P3A5 内核模板补单头 CSA 特化或实测证伪缺口该特化 A2/A3-only★（低风险）
声明：本机无 NPU 环境，以下均为代码 + 官方文档依据的推断，收益方向未实测，落地前需按机会点做基准对照。

P1融合 Compressor 算子扩展到 V4.1

现状：ratio-1 就是 wkv + RMSNorm 两个小算子（第二节代码），ratio-2 靠 Triton 环形池化；而 V4 已有按架构选键的融合 Compressor 模板（四键/架构，coff 覆盖压缩比 128/4）。

建议：把融合模板的 coff 扩展覆盖压缩比 1/2（至少先融合 ratio-1 的投影+归一化）；评估把 ratio-2 的 Triton 环形池化下沉为 AscendC。

收益方向：CED 的"编码器→解码器 KV 投影"是本代模型的独有热点路径；prefill 每个源层减少 kernel 启动与中间张量，40 层规模化后收益放大。

参考：仓库开发者指南 deepseek_v41_qli_candidate.md（"V4.1 currently uses small operators for compression"）· 链接

P2FP4 main KV 支持

现状：模型卡明确全局 KV 为 FP4 890 B/token，但 SparseFlashMla 只编 BF16——FP4 的容量/带宽红利一分未得；QLI 的 A5 模板已注册 MXFP4 dtype，说明 FP4 数据通路在 A5 上存在。

建议：给 npu_sparse_flash_mla 增加压缩侧 FP4 cmp_kv 模板 + cache dtype 配置链（kv_cache_dtype → 四槽页容量重算 → prefix cache 兼容性验证）；A2/A3/A5 对 FP4 的硬件支持面先摸底。

收益方向：压缩 KV 体积 ≈×4 下降 → 同卡容纳更长上下文/更多并发；decode 全局注意力读 KV 的 HBM 带宽大幅下降。1M 上下文场景最大单项。

参考：仓库开发者指南编译矩阵节 · 链接

P7CED × PD 分离映射（架构红利）

现状：编码器 20 层只在 prefill 参与，解码器 KV 由末端一次投影——编码器算力天然可锁在 P 节点；仓库 PD 分离与 KV 传输能力已就绪（#16755 / #16910 / #17183 / #16498）。

建议：验证 V4.1 在 PD 分离下的组件归属——编码器+压缩源层驻 P，解码器+Engram+DSpark 驻 D；用 layerwise KV pool 传压缩后 KV（890 B/token，传输量比全量 MLA 小一个量级）。

收益方向：D 节点显存与 KV 压力大降 → decode 批容量上升；P/D 间迁移带宽成本极低。CED 给昇腾部署的独特红利。

参考：#16755 · #16910 · #17183 · #16498

P6decode 双流重叠深化

现状：multistream_preprocess（dsa_v41.py:310，docstring 即"Overlap Q Vector work with KV Cube work"）已覆盖 Q 投影与 KV 写入；同期 #16977 在 DCP 路径验证了 decode 流优化手法。

建议：把 QLI 索引选择（向量型）与 SWA scatter 写入编入同一事件链；对照 #16977 把 V-up 类投影下沉到 Cube 流。

收益方向：decode 每层 Vector/Cube 交替空隙收窄；对 1M 上下文 decode（CSA 读大 KV 占比高）尤其有效。

参考：#16977

P4Engram 主机卸载异步化

现状：prepare_engram（model.py:1049）在层循环前集中查表；主机卸载路径 HostUvaBuffer + gather_dequantize_host_uva（engram/npu.py:173/:275）是同步调用；#17134 已做跨 DP 头分片共享。

建议：查表-反量化挪入辅助流（仓库已有双流框架 multistream_preprocess 可参照）；对 lookback 窗口做逐步预取。

收益方向：decode 步内隐藏 host 内存访问延迟——Engram 196B 参数无法全驻 HBM，访存必经互连。

参考：#17134

P5DSpark 投机解码 × CSA 元数据复用

现状：草稿侧独立维护 SWA KV（dspark.py:212/:275）；同期主线已在 DSA 路径验证两类元数据优化（#17153 组不变元数据缓存、#15949 SAS 元数据优先），均未覆盖 V4.1 的 MetadataBuilder（dsa_v41.py:571/:718）。

建议：两个已验证手法移植到 V4.1 builder；评估 draft 与 target 共享候选索引/topk 缓冲（SharedAttentionState 已保证定址稳定）。

收益方向：每步元数据构建 CPU 开销下降；投机解码净收益（接受长度 × 步成本）上升。

参考：#17153 · #15949

P3A5 上补 CSA 单头特化模板

现状：开发者指南编译矩阵——"single-head CSA specialization is A2/A3-only and split-G/vectorized addressing is A5-only"（A2/A3 编 6 键、A5 编 12 键）。

建议：A5 模板矩阵验证/补齐单头 CSA 特化；若 split-G 实测无损，显式记录结论避免隐性缺口。

收益方向：950DT/A5 服务器上 CSA 层（解码器多数层）注意力延迟；与 P2 同属低风险模板类改动。

参考：仓库开发者指南编译矩阵节 · 链接

六、小结

对照图4 的地图念一遍：P1 / P2 兑现模型设计红利（压缩融合 + FP4 KV，收益最大）；P3 / P6 补齐模板与流水（低风险增量）； P4 / P5 需要 profile 数据确认瓶颈占比后再动手；P7 是部署形态级专项，值得单独立项验证。 两页读完的完整链条：需求怎么来的（前篇）→ 代码怎么落的（前篇）→ 红利兑现了多少、下一步做什么（本篇）。

七、相关链接

首页