2026年8月6日作者：Lei阅读 --

DeepSeek-V4-Flash 为什么这么快：三代论文对同一个分母的围剿

结合 DeepSeek-V4 技术报告（arXiv:2606.19348）与它的论文谱系（MLA→NSA→DSA→CSA/HCA），把 V4-Flash 的"快"拆成一个公式：解码速度 ≈ 带宽 ÷ 每 token 要搬的字节数。所有架构创新都是在砍这个分母的五个因子——激活参数、KV 宽度、看多少条、存多少条、每个数占几位。

LLM AI Infra 论文深读

DeepSeek-V4-Flash 在官方 API 上跑出约 120 tokens/s 的解码速度——同级开源模型的中位数是 57 t/s（Artificial Analysis 实测）；它默认开着 100 万 token 的上下文窗口，输出定价却只有 $0.28 / 百万 token。第一反应往往是”又有什么新魔法”。但翻开 V4 技术报告会发现：没有单一魔法。它的快，是从 2024 年的 MLA、2025 年的 NSA 和 DSA、到 2026 年的 CSA/HCA——三代论文对着同一个分母连续锤了三遍的结果。这篇文章就把这个分母亮出来，再看每一代论文各砍掉了它的哪个因子。

一句话主线

解码速度的上限 ≈ 显存带宽 ÷ 每生成一个 token 要搬运的字节数。V4-Flash 的全部”快”，都是在砍这个分母的五个因子：激活多少参数（MoE）、每条 KV 多宽（MLA 血统）、注意力看多少条（DSA）、缓存里存多少条（CSA/HCA）、每个数占几位（FP4/FP8）。

记住这个公式，下面每一节都只是往里面填因子。

一、先立地基：解码不是计算问题，是搬运问题

在《KV Cache 的显存账》和《把 LLM 推理当操作系统看》里铺过的地基，这里一句话复述：自回归解码阶段，每生成一个 token，GPU 都至少要从显存里读一遍两样东西——

这次前向要用到的模型参数（MoE 模型只读被激活的那部分）；
这个请求积累至今的全部 KV cache（注意力要拿新 token 的 query 去和历史逐条比对）。

矩阵乘法本身快得很，慢的是等字节从 HBM 流进计算单元。所以单请求解码的速度上限不是 FLOPs 决定的，而是：

\text{tokens/s} \lesssim \frac{\text{显存带宽}}{\text{每 token 搬运字节数}} = \frac{BW}{\underbrace{P_{\text{active}} \cdot b_{p}}_{\text{参数流量}} + \underbrace{L_{\text{cached}} \cdot w_{\text{entry}} \cdot b_{kv}}_{\text{KV 流量}}}

其中 $P_{\text{active}}$ 是激活参数量、 $b_p$ 是每参数字节数、 $L_{\text{cached}}$ 是缓存里的条目数、 $w_{\text{entry}}$ 是每条的宽度、 $b_{kv}$ 是每个数的字节数。

一个工程上的重要细节：批处理能摊薄参数流量（一批请求共享同一次参数读取），但摊不薄 KV 流量（每个请求的 KV cache 各自独立，都得读）。所以上下文越长、并发越高，KV 流量越是主要矛盾——这就是为什么接下来三代论文全在打 KV 的主意。

二、分母的五个因子：一张地图

因子	物理含义	谁在砍	砍到多少
$P_{\text{active}}$	每 token 激活的参数	DeepSeekMoE	284B 总参只激活 13B（≈4.6%）
$w_{\text{entry}}$	每条 KV 的宽度	MLA（V2 起）	576 个数/层，约为标准 MHA 的 1/57
看多少条	注意力实际比对的条目数	DSA（V3.2 起）	全序列 → top-k 条
$L_{\text{cached}}$	缓存里存的条目数	CSA/HCA（V4 新增）	每 4 条压 1 条 / 每 128 条压 1 条
$b_p$ 、 $b_{kv}$	每个数占几位	FP4/FP8 量化	路由专家 FP4，KV 存储 FP8

这张表就是这篇文章可复用的心智模型：下次再看到任何”推理加速”工作，先问它砍的是哪个因子。五个因子相互正交，所以可以叠乘——这正是 V4-Flash 快的数学结构。

下面按论文谱系的时间顺序，看三次关键砍伐。

三、第一代：MLA 砍”每条多宽”（2024，DeepSeek-V2）

DeepSeek-V2 论文提出 Multi-head Latent Attention（MLA）：不再给每个注意力头分别缓存 K 和 V，而是把它们联合压进一个低秩 latent 向量，缓存这个 latent，用时再解压。配合解耦的 RoPE 维度，V3 谱系的配置是每 token 每层缓存 512（latent）+ 64（RoPE）= 576 个数。

这一刀的力度可以手算（以下数字均已用脚本验算）：V3 有 61 层，标准 MHA（128 头 × 128 维）每 token 需要缓存 $2 \times 128 \times 128 \times 61 \approx 200$ 万个数，BF16 下 100 万 token 上下文的 KV cache 约 4 TB——物理上不可行。MLA 压到 $576 \times 61 = 35{,}136$ 个数/token，同条件下约 70 GB——57 倍的压缩，把”长上下文”从不可能变成昂贵但可行。

注意 MLA 砍的是 $w_{\text{entry}}$ （每条多宽），没动条目数：100 万 token 依然是 100 万条，解码时依然要逐条比对。这是留给下一代的问题。

四、第二代：NSA 与 DSA 砍”看多少条”（2025）

4.1 NSA：证明”稀疏注意力可以原生训练”

Native Sparse Attention（NSA，ACL 2025 最佳论文）回答的根本问题是：注意力真的需要看全部历史吗？它把注意力拆成三个并行分支——粗粒度压缩（把 token 块池化成摘要）、细粒度选择（挑 top-k 个重要块精读）、滑动窗口（保底看最近的局部）——再用可学习的门控加权融合。64K 序列上，解码阶段实测约 11.6 倍加速。

NSA 有两个后来被反复继承的立场：一是硬件对齐——稀疏模式必须按块组织，否则 GPU 上省了 FLOPs 省不了时间；二是原生可训练——稀疏结构要从预训练就在场，而不是训完了再往上打补丁。

4.2 DSA：lightning indexer 让”挑重点”本身变得便宜

稀疏注意力有个先有鸡还是先有蛋的问题：要挑出 top-k 个重要 token，你得先给全部 token 打分——打分这一步如果和注意力一样贵，就白忙了。DeepSeek-V3.2-Exp（技术报告发布于 GitHub，后续 V3.2 论文见 arXiv:2512.02556）的 DSA 给出的答案是 lightning indexer：一个头数很少、可以跑在 FP8 的轻量打分器，用 ReLU 激活换吞吐，快速算出 query 和每个历史 token 的 index score，只把 top-k 送进真正的注意力。

训练方法同样值得记：先冻结主干、单独训练 indexer，让它模仿 dense 注意力的分布（约 2.1B token），然后才放开全模型稀疏训练。这是 NSA “原生可训练”立场的工程化落地。效果：128K 上下文下约 3–6 倍成本下降，发布当天 API 降价 50%+。

DSA 砍的是”看多少条”：比对从 $O(L^2)$ 降到 $O(L \cdot k)$ 。但缓存里存的条目数没变——100 万 token 还是要存 100 万条 latent。显存占用和”每次挑重点要扫过的候选集”依然随 L 线性涨。第三刀来了。

五、第三代：CSA/HCA 砍”存多少条”（2026，V4）

V4 技术报告的混合注意力是这个谱系的合流点，两个组件：

CSA（Compressed Sparse Attention）：先把每 $m$ 个 token 的 KV 压缩成一条（可学习的压缩权重），再在压缩后的序列上跑 DSA 的 top-k 稀疏选择，另配一小段滑动窗口 KV 保住局部细节。解读文章普遍给出 $m=4$ （Sebastian Raschka 的架构图解、知乎技术报告精读）——100 万 token 先变成 25 万条，再在 25 万条里只看 top-k。
HCA（Heavily Compressed Attention）：同样的压缩思想推到极致，压缩率 $m' \gg m$ （解读给出 128），100 万 token 只剩约 7,800 条摘要，直接稠密扫一遍也便宜。它承担”全局粗看”的职责，与 CSA 的”精挑细读”分工，两类层交替堆叠。

对照 NSA 的三分支（压缩/选择/滑窗），你会发现 CSA/HCA 是把当年的三个分支从一层内的并行部件，升级成了跨层交替的一等公民架构——压缩不再是给选择打辅助的摘要，而是缓存本身就以压缩形态存在。这也是它和 MLA 的本质区别：MLA 是每 token 一条、把条压窄；CSA/HCA 是把序列本身变短。两者正交，可以同时用。

lightning indexer 在 V4 里也被继续压榨：低秩化（query 先下投影再上投影），打分计算直接跑 FP4。

三刀叠加的结果，论文原文：V4-Flash 在百万 token 场景下，单 token 推理 FLOPs 只有 V3.2 的 10%，KV cache 只有 7%（Pro 版对应 27% 和 10%）。套回第一节的手算：V3.2 谱系 1M 上下文约 70 GB 的 KV，Flash 降到约 5 GB——一个请求的长上下文状态从”独占半张卡”变成”一张卡能塞十几个”。

六、配角也在省字节：MoE、量化、MTP

主线之外，分母公式里剩下的因子也各有人管：

$P_{\text{active}}$ ：Flash 沿用 DeepSeekMoE 范式，284B 总参数每 token 只激活 13B（4.6%）。参数流量从 V3.2 谱系 37B@FP8 ≈ 37 GB/token 降到 13B 且大头跑 FP4 ≈ 6.5–13 GB/token。
$b_p$ 、 $b_{kv}$ ：报告明确路由专家参数用 FP4，压缩 KV 存储用 FP8（RoPE 维度保留 BF16）。位宽减半，字节数直接减半——这是最朴素也最诚实的一刀。
MTP（多 token 预测）：配置与 V3 相同，推理时可当投机解码的草稿头用，一次前向验证多个 token——它不砍分母，而是提高每次搬运的产出，即《投机解码的第二本账》里算过的那笔账。

顺带回答”为什么叫 Flash”：它和 V4-Pro（1.6T 总参 / 49B 激活）同架构、同 1M 上下文，区别就是把 $P_{\text{active}}$ 和总参数再砍小一档，用世界知识储备换延迟和成本——实测显示简单 Agent 任务上两者相当，高难任务 Pro 仍明显更强。7 月 31 日的 0731 正式版没有改任何架构，只是重做了后训练（重点是编码、Agent 与工具调用），快的部分与本文完全同源。

七、数字对账：论文的 10 倍与实测的 2 倍

一个诚实的怀疑：论文说 FLOPs 砍到 10%、KV 砍到 7%，为什么实测只比同级中位数快 2.1 倍（120.7 vs 57 t/s），而不是 10 倍？

三个原因，每个都值得记：

对照组不同。论文的 10% 是和 V3.2 自己比、且在 100 万 token 的极端场景下；Artificial Analysis 的实测是常规长度提示词、和”其他也在优化的开源模型”比。分母的收益随上下文长度增长——上下文越长，V4-Flash 的相对优势越大，短对话里体现不出 7% 的威力。
带宽不是唯一瓶颈。真实 serving 还有调度、采样、通信、kernel 启动开销；批处理场景下参数流量被摊薄后,系统可能转为算力受限。第一节的公式是上限，不是预测值。
提供商配置差异巨大。同一个模型在不同 API 提供商上速度相差可达 2.6 倍——架构决定天花板，工程决定你摸到天花板的几分之几。

反过来，价格是比 t/s 更忠实的效率信号： $0.14 /$ 0.28 每百万 token 的定价、缓存命中输入 $0.0028，只有旗舰闭源模型的几十分之一——每 token 的硬件成本降下来了，降价才可持续。

八、边界与另一条路线

这套方案的代价在哪？ 稀疏和压缩都是有损的：indexer 挑错重点，模型就看不到该看的历史。DeepSeek 自己踩过这个坑——V3.2-Exp 发布后官方在 2025 年 11 月承认 indexer 模块的 RoPE 实现有偏差，可能造成性能退化。“挑重点”这个环节引入了一个新的、独立的可错部件，这是 dense 注意力没有的风险面。

同一个分母，还有另一条砍法：线性注意力路线（Kimi 的 KDA，见《KDA 深读》）干脆不存全部历史，把状态压成固定大小的矩阵， $L_{\text{cached}}$ 直接变成常数。对比之下看得更清楚：DeepSeek 路线保留”可回看任意历史”的能力、用压缩+稀疏控制成本；线性路线放弃精确回看、换取常数级状态。V4 的 CSA（保留可检索的压缩条目）恰好站在两者之间——这不是谁对谁错，而是在”记忆保真度 vs 状态大小”光谱上的不同落点。

九、动手验证

按惯例，转述不算学会，这篇的关键论断都可以亲手验：

实测 t/s：用 DeepSeek API 分别以 1K / 32K / 128K 提示词跑 V4-Flash，记录解码 t/s——验证”上下文越长相对优势越大”这个推论（预期：短上下文差距小，长上下文差距拉开）。
复算字节账本：本文所有手算（576×61、70 GB、4 TB、7%→5 GB、13/284）我都用一段 python 验过；用第一节的公式加上你手头 GPU 的带宽标称值，估一个 t/s 上限，和实测比差几倍，差值就是”工程层损耗”的直观感受。
读一段 kernel：DSA 的 indexer kernel 开源在 DeepGEMM，对照第四节看”打分为什么便宜”落实在代码哪一行。

参考来源

arXiv 论文（按谱系顺序）

DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model — MLA 与 DeepSeekMoE 的起点（arXiv:2405.04434）
DeepSeek-V3 Technical Report — 671B/37B、61 层、MTP（arXiv:2412.19437）
Native Sparse Attention: Hardware-Aligned and Natively Trainable Sparse Attention — NSA，ACL 2025 最佳论文（arXiv:2502.11089）
DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models — DSA 的正式论文版（arXiv:2512.02556）；原始技术报告在 GitHub
DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence — CSA/HCA、mHC、Muon（arXiv:2606.19348）

工程实践与实测

本站相关旧文