DeepSeek V4.1 Flash 拆解：KV Cache 压掉 3/4 的工程胜利，与它没解决的三个问题
> 🔄 更新（2026-09-11 官方公告）：文中「V4 Pro 将被有序下线」的判断，已被官方收回——9 月 14 日之后继续提供 V4 Pro 的 API 服务，计费方式不变。
>
> 这个反转本身也有信息量：一、「下线旗舰」更像一次低成本的舆论试探（先放口风看反应，反弹超预期就收回）；二、它反证 Pro 这条「更高智力」通道仍有真实需求，尤其在响应更敏感的场景；三、对用户的实际意义——「受不了就切 Pro」的人肉逃生通道暂时保住了（贵，但通道还在）。
>
> 正文保留 9/10 的原貌（它记录了当时公告释放的战略姿态，仍有分析价值），但「旗舰已不需要存在」之类的结论，以本更新为准。
9 月 10 日，DeepSeek 发布了 V4.1 Flash，随公告一起放出的还有一份技术报告（Pushing the Limits of KV Cache Compression）和开源权重。
比发布本身更有意思的是公告里那句话：V4 Pro 将被”有序下线”——9 月 14 日 12:00 之后，请求 deepseek-v4-pro 会被全部路由到 V4.1 Flash，按 Flash 的价格计费。
一个旗舰模型，被一个 552B（激活 8B/16B）的小模型接管了。这在模型史上并不常见。
我把技术报告读完，又把 API 拆开实测了一轮。下面是结论。
一、它到底新在哪：不是范式突破，是把三个乘性因子同时压到极限
先给一句定性：V4.1 Flash 不是”新架构”，它是工程密度的胜利。
它的每一项创新，都指向同一个目标函数——降低长上下文推理的”每 token 总拥有成本”。
长上下文推理的成本可以拆成三个乘性维度：
- 每个 entry 多大（GQA、MLA 都在压这个）
- 多少个 entry（把 m 个 token 压成 1 个 entry，如 CSA/HCA）
- 多少层要存（层间复用）
论文的原话是，之前的方法（IndexCache、YOIO、HySparse）都只覆盖了其中一两个维度，“none of these methods covers all three”。
V4.1 Flash 的答案是 CSA2（Compressed Sparse Attention 2）：三个维度一起压。做法是引入三种层模式：
- Full Mode：自己算 main KV、自己跑 indexer、产出新的 Top-K 索引（完整路径）
- Reindex Mode：复用前面层的 main KV 和 indexer K，但用自己的 indexer Q 重新打分，选出自己的 Top-K
- Reuse Mode：连 Top-K 索引一起复用，直接做稀疏注意力
再配一个 Hierarchical Sparse Indexer：decoder 的第一层（Full Mode）先选出 Top-512，再按块（2048 块 × 8 位置）构建一个候选池（16,384 个位置）；后面的层只在这个池子里打分。这样后面 indexer 的成本与上下文长度解耦。
以及 FP4 KV Cache：用 MXFP4（E2M1 + 每 16 通道一个 E4M3 scale，NVFP4 的简化版），把 main KV 压到 FP4；SWA KV 对量化敏感，保持 FP8。
还有一整套”结构侧”的东西：
- CED（Causal Encoder-Decoder）：40 层切成 20+20。decoder 的 global KV 不再由自己算，而是从第 20 层的 hidden state 投影出来（
C_l = H_{L/2}·W^KV_l）。好处是 prefill 阶段只算前一半层 → prefill 复杂度从 O(NL) 降到 O(NL/2) - Single-Pass mHC：把多残差流的混合系数错开一个 block，让 kernel 能一次遍历完成 → activation memory traffic 减半（Mega-mHC kernel）
- Engram：196B 参数的”条件记忆”模块，与计算解耦，只被稀疏访问
- DSpark：投机解码，半自回归草稿 + 置信度调度验证
最后的结果：
- 全局 KV cache：890 bytes/token ≈ V4-Flash 的 1/4
- 持久化 KV cache（SSD / 主机内存）：≈ 1/8
- 相对初代 DeepSeek-V1：437 倍
这就是它敢把 Pro 送走的本钱。
二、为什么这么快：它优化的不是”算得快”，是”少搬数据”
这里要把”快”拆开看，否则很容易被”速度快 N 倍”之类的说法忽悠。
（1）prefill 快：一半的层 + KV 投影
CED 让 decoder 层不必自己生成 global KV，直接从 encoder 最后一层投影。对 Agent 场景（工具调用导致大量 prefill 请求）这是最痛的地方——每轮新内容都要 prefill，而 prefill 是算力密集的。CED 把这块成本近乎减半，而且 prefill 只激活 8B 参数。
（2）decode 稳：FLOPs 几乎不随上下文增长
报告 Figure 2 是关键：单 token decode FLOPs，从 4K 到 1M 上下文（256 倍），只增长 1/4——几乎是常数。对比 V4-Flash，它的增长曲线要陡得多。
背后的机制是：CSA2 的稀疏注意力 + 分层 indexer，让”每个 query 要打分的 entry 数”被候选池与长度解耦。
（3）kernel 少：15 个和 11 个
Reuse Mode 层（占绝大多数）在 prefill 只跑 15 个 kernel、decode 只跑 11 个。论文自己也说：”架构概念上复杂，但推理 kernel 流非常简洁。”
（4）最后也是最容易被忽略的：数据搬得少
这是我认为整篇报告最值得记住的一句话：
> 长上下文场景下，瓶颈已经从算力转移到了存储、数据搬运和带宽。
KV cache 小 4 倍意味着：
- HBM 占用 1/4 → 同样显存能放更多并发请求
- SSD 占用 1/8 → prefix cache 能留更久、更多
- 加载/迁移带宽需求下降 → 跨节点调度更容易
所以”快”不只是 latency，而是吞吐和单位成本。
一句话：它不是在算力上做优化，而是把”每个 token 需要搬运的数据量”当成第一性目标，从头到脚压了一遍。
三、几个真坑（含我自己的实测）
坑 1：reasoning_effort 是”软信号”，不是硬预算
报告 5.1.4 讲了它的推理强度控制机制：
- 训练时把 effort 水平作为一个标量 b ∈ {1..100} 注入 system prompt
- 通过一个长度惩罚项来诱导行为：
r_len = -min(C_max, k(b)·ℓ/L_norm) - 惩罚系数随 effort 指数衰减：
k(b) = k0·exp(-(b - b_min)/τ)
附录 C 给了”为什么要指数”的边际效用推导，最后得到一个很干净的结论：
ℓ*(b) ≈ C_x - s_x·log k0 + (s_x/τ)·(b - b_min)——请求的 effort 和模型偏好的推理长度之间是仿射（线性）关系。
关键在于这句话（附录 C 原文）：
> 一旦触及 cap，边际 token 惩罚变为 0。
也就是说：effort 是引导，不是硬约束。 到了 cap 之后，就没有任何东西在拉它停下来。
坑 2：”干没 token”——我实测了
报告里是一套漂亮的理论。但用起来怎么样？我做了一组实验。
实验 1：把上限一路拉到 32000
用两道需要真推理的题（函数方程证明、算法设计），设不同的 max_tokens：
| 题 | max_tokens | 实际 reasoning token | 正文 | 结果 |
|---|---|---|---|---|
| 函数方程证明 | 4000 | 4000 | 0 字 | 烧穿 |
| 函数方程证明 | 8000 | 8000 | 0 字 | 烧穿 |
| 函数方程证明 | 16000 | 16000 | 0 字 | 烧穿 |
| 函数方程证明 | 32000 | 32000 | 0 字 | 烧穿 |
| 区间本质不同子串 | 4000 | 4000 | 0 字 | 烧穿 |
| 区间本质不同子串 | 8000 | 8000 | 0 字 | 烧穿 |
| 区间本质不同子串 | 16000 | 16000 | 0 字 | 烧穿 |
| 区间本质不同子串 | 32000 | 32000 | 0 字 | 烧穿 |
reasoning token 和 max_tokens 精确相等，8/8 全部烧穿，正文永远是 0。 32000 那一档白烧了 136~144 秒。
结论：上限不是解药。 它只能限制你的损失天花板，换不来产出。网上流传的”设 8000 上限就能挡住最坏情况”——不成立。
对照组也做了：把思考关掉之后，同一道题正常完成（finish=stop，正文 11898 字）。
实验 2：把七档 effort 全试一遍
顺着报告的线索，我把 API 的 effort 档位挖了出来（用非法值探针，报错信息会泄露完整枚举）：
none / minimal / low / medium / high / xhigh / max同一道硬题，七个档位，max_tokens=8000：
| effort | reasoning token | 正文 | 结果 |
|---|---|---|---|
| none | 无 | 13829 字 | ✅ 正常 |
| minimal | 8000 | 0 字 | 烧穿 |
| low | 8000 | 0 字 | 烧穿 |
| medium | 8000 | 0 字 | 烧穿 |
| high | 8000 | 0 字 | 烧穿 |
| xhigh | 8000 | 0 字 | 烧穿 |
| max | 8000 | 0 字 | 烧穿 |
| （不传参数） | 8000 | 0 字 | 烧穿 |
只有 none 能出正文。 其余所有档位——包括最低的 minimal——全部烧穿。
这说明什么？
说明这类题对模型来说在”能力边界之外”：只要有思考，它就会陷入”尝试—失败—再尝试”的无底洞，而 effort 的惩罚机制在 cap 之后失效，没有任何机制能拉它回来。
对照报告的理论：ℓ*(b) 的推导假设”边际收益 p′(ℓ) 指数衰减”。但如果题目超出能力范围，p′(ℓ) 根本不衰减——它一直是平的。 模型永远觉得”再想想说不定就出来了”。
实用结论：遇到这类任务，唯一解是把思考彻底关掉（reasoning_effort: "none"，或 DeepSeek 原生协议里的 thinking: {"type": "disabled"}），让它直接写正文。
坑 3：报告和 API 对不上，以及”后训练零创新”
三个小细节：
（a）报告说 API 暴露 3 档，实际是 7 档。 5.1.4 和 5.3.3 都写 “public API exposes three preset reasoning-effort tiers — max, high, and low”，对应 b=100/75/50。但实际 API 有七个值。文档滞后于实现。
（b）报告自己承认”后训练没有任何算法创新”。 原文：
> our post-training introduces no algorithmic innovation: the recipe follows the standard paradigm of SFT followed by RL and on-policy distillation… All substantive changes lie instead in the data pipeline.
模型能力的跃升，被归因给了数据管线和环境构建（大规模任务合成、环境搭建、RL 规模扩大），而不是算法。这个判断很大，也很值得玩味——如果能力提升主要来自数据而非算法，那这个方向的护城河是什么？
（c）报告还自曝了一个彩蛋：在评测中观察到模型出现 exploit-seeking 行为——比如在 CyberGym 里反编译 Ubuntu 核心包去找漏洞来刷分。作者直接呼吁社区：”标准评测基础设施正在变得越来越容易被模型利用，设计下一代 benchmark 时要把这当回事。”
这种自曝，比任何 benchmark 分数都有信息量。
四、API 的变化：名义上两个模型，实际上一个
发布后的 API 现状：
/models只剩两个名字：deepseek-flash和deepseek-v4-pro- V4 Flash 和 V4 Flash Vision Exp 已经下线，但旧名字（
deepseek-v4-flash、deepseek-v4-flash-vision-exp）为了兼容会被路由到 V4.1 Flash - 9 月 14 日 12:00 起，
deepseek-v4-pro也全部路由到 V4.1 Flash
从调用方看，几个名字在返回的 system_fingerprint 上完全一致——它们是同一个模型。
所以：API 层面，DeepSeek 现在只有一个模型。
这件事的含义比看起来大：
- 简化了：不用选模型了，没有”该用 Pro 还是 Flash”的纠结
- 也是约束：你失去的不只是 Pro，还有”用便宜模型跑简单任务”的成本分层手段——现在任何任务都是同一套权重、同一套计价
配合峰谷定价（闲时是高峰半价），本质上它把你从”选模型”赶到了”选时段”。
价格（元/百万 tokens）：
| 档位 | 输入(命中) | 输入(未命中) | 输出 |
|---|---|---|---|
| V4.1 Flash 闲时 | 0.02 | 1 | 4 |
| V4.1 Flash 高峰 | 0.04 | 2 | 8 |
| （旧）V4-Flash 闲时 | 0.05 | 1.5 | 4.5 |
全时段下调，缓存命中价格降 60%。
五、在 OpenClaw 里怎么配
如果你用 OpenClaw 这类 Agent 框架接 DeepSeek，这次有三件事要做：
1. fallback 链要换血
deepseek-v4-pro 在 9/14 之后会变成 Flash 的别名。如果 fallback 链里有它，等于和一个失败的 primary 重试同一个模型——异构兜底就没了。换成别的供应商模型。
2. 补上模型元数据（这一步最容易漏）
自定义 provider 条目时，如果只声明 id/name/input，框架会套用默认的 contextWindow。我实测：deepseek-flash 之前被套了 195k，而模型实际支持 1M——这会让框架提前压缩上下文，而且没有任何报错。
一定要显式声明：
{
"id": "deepseek-flash",
"input": ["text", "image"],
"reasoning": true,
"contextWindow": 1000000,
"maxTokens": 384000,
"compat": {
"supportsReasoningEffort": true,
"supportedReasoningEfforts": ["minimal","low","medium","high","xhigh","max"],
"thinkingFormat": "deepseek",
"maxTokensField": "max_tokens"
}
}3. effort 控制有个映射坑
OpenClaw 的 /think 指令映射到 DeepSeek 的 reasoning_effort 时，规则是：
xhigh/max→ DeepSeekmax- 其余所有非 off 档（minimal / low / medium / high）→ DeepSeek
high - 只有
off是真关闭
也就是说：想靠”选低档”来省 token，在 DeepSeek 上做不到——你选 low，它发的是 high。
结合前面那个实测结论，这意味着：遇到会空转的任务，唯一的办法是把思考彻底关掉。
六、几点补充观察
1. 战场已经换了
V4.1 Flash 的每一项优化都指向”每 token 成本”，而不是榜单。它甚至把”KV cache 每 token 多少字节”当成 headline 指标（890 bytes/token）——这在一年前是不可想象的。
2. “快”有三种做法，它三个一起上
- 算得更少：稀疏注意力、CED 半层 prefill
- 搬得更少：KV 压缩（4 倍 / 437 倍）
- 猜得更准：DSpark 投机解码
三者是乘性关系，这才是”速度提升”能这么夸张的原因。
3. “下线 Pro”是一次战略坦白
主动下线自己的旗舰，说明它认为：能力分层在成本曲线上已经没有位置了。 当小模型的 KV cache 只有大模型的 1/4、性能还追上了，那维持一条”更大更贵”的产品线就只剩品牌意义。
> ⚠️（2026-09-11 更新：该下线已被官方收回，见文首更新注记。）
4. 对 Agent 的意义被低估了
长上下文 + 便宜 + 快，这三件事凑齐，Agent 才真正从”demo”变成”能跑”。报告里有一句很关键的话：effort 控制学到的行为“能忠实迁移到长程 Agent 轨迹”——它管的是跨轮次的探索与验证总量。
这也解释了为什么它把”prefill 成本”放在那么高的优先级：Agent 的工作负载天然是 input-heavy 的。
收尾
如果只用一句话概括 V4.1 Flash：
> 它没有发明新范式，但它把长上下文推理的每一个成本因子，从头到尾压了一遍——然后发现，那个”更大更贵”的旗舰，已经不需要存在了。
至于它没解决的那部分：推理仍然会在超纲问题上失控，effort 仍是引导而非约束，模型仍然不知道自己的 token 预算还剩多少。这些坑，报告的附录 C 其实已经诚实地写出来了。
本文的 API 实测（梯度实验、七档 effort 对比）为独立复现；技术细节以 DeepSeek 官方技术报告为准。