一、9·10 发布，重点不在跑分

2026 年 9 月 10 日，DeepSeek 正式发布 V4.1 Flash。官方的技术材料里给出了一组很有分量的数字，其中最关键的只有一个：

全局 KV Cache 压到 890 字节/token，约为 DeepSeek-V4-Flash 的 1/4。

如果只按发布会的常规视角看，这次 V4.1 Flash 的定位是「更便宜的 Flash」，配上并发限制从 500 提到 2500、价格同步下调，看起来像一次常规的性价比更新。但把架构和缓存策略摊开看，这是一次针对长上下文推理成本结构的重构。

原因很简单：在 Agent 场景里，账单的大头不是新生成的那几百 token，而是一直拖在显存里的那段上下文。KV Cache 少四分之一，直接改写的就是这部分的地租。

二、架构：CED 非对称，40 层拆成两段

V4.1 Flash 采用全新的 CED（Causal Encoder-Decoder）非对称结构，40 层 Transformer 被明确切成两半：

  • 前 20 层是 causal encoder
  • 后 20 层是 decoder

关键改动在于全局 KV Cache 的来源。传统 decoder-only 架构里，全局 KV Cache 是由每个解码层用自己的隐状态推导出来的 —— 每来一个新 token，40 层都得各走一遍。V4.1 Flash 改成：

decoder 需要的全局 KV Cache，不再由每个解码层自己的隐状态推导，而是从编码器最后一层（第 20 层）的隐状态投影得到。

这带来一个非常直接的工程收益：面对新输入不必把整段 prompt 走完 40 层，主要算前 20 层就能准备好 decoder 所需的全局记忆。对应的计算量变化是：

prefill 计算量从近似 O(NL) 降到 O(NL/2)（N 为序列长度，L 为层数）。

这个 O(NL/2) 值得停一下：prefill 是长上下文场景里最贵的一段 —— 你要塞进 500K token 的代码仓库，第一遍处理这些 token 的开销是线性于 N × L 的。省掉一半不是常数优化，是复杂度层面的折半。而长上下文的痛点恰恰在 prefill 上：首 token 延迟直接决定用户体感。

三、参数结构：552B 主干 + 196B Engram，每 token 只激活约 8B

项目数值
MoE 主干参数552B
Engram 参数196B
prefill 每 token 激活参数约 8B
decode 每 token 激活参数约 16B
上下文窗口1M token
推理强度支持 1–100 连续可调

注意激活参数的非对称性：prefill 阶段每 token 只激活约 8B，decode 阶段约 16B。这正好和 CED 的设计对上 —— prefill 只需要走前 20 层的 encoder，激活少一半；decode 阶段才走满 decoder，激活翻倍。把「计算便宜的那段」放在批量处理上，「计算贵的那段」放在逐 token 生成上，这是典型的针对 Agent 负载特征做的错配优化。

四、KV Cache 的地租：890 字节/token 是怎么来的

现在回到那个核心数字。它由两个机制共同贡献：

1. FP4 KV Cache：主 KV 用 FP4 缓存

主 KV Cache 改用 FP4 存储，精度为 E2M1，每 16 个通道配一个 E4M3 scale 做块级缩放。结果是：

全局 KV Cache 压到 890 字节/token，约为 DeepSeek-V4-Flash 的 1/4。

这里的关键工程判断是「精度损失换显存」的取舍点选在了哪里。用 E2M1 这种低精度格式存 KV 是有代价的 —— 数值范围窄、动态范围小，直接存会掉质量。DeepSeek 的做法是每 16 通道挂一个 E4M3 缩放因子，等于在块级别保住了动态范围。量化方案真正考验的不是能不能压到 4 bit，而是压缩比上去之后，长上下文任务的实际质量有没有掉 —— 这一项只能用你自己的任务集验证，官方数字回答不了。

2. SWA Bounded Replay：不持久化 SWA KV

滑动窗口注意力（SWA）部分的 KV，DeepSeek 没有选择老老实实存下来，而是采用 SWA Bounded Replay：

  • 只回放最近 n 个 token 窗口来重建缺失的 SWA KV 状态
  • 无需把 SWA KV 持久化到 SSD
  • 持久化 KV 占用约为 V4-Flash 的 1/8

这是一个很务实的设计取舍：SWA 窗口内的 KV 本来就可以从原始 token 重新算出来（代价是重算，但只限于最近 n 个 token），那就干脆不存。需要恢复历史上下文时，回放一小段窗口把状态重建出来即可。用一点算力换掉一整块 SSD 持久化开销 —— 对需要跨请求、跨进程复用上下文的 Agent 服务来说，这个取舍非常划算。

3. 口径说明

这三个数字的基线各不相同，混用会得出错误结论：

指标数值基线
全局 KV Cache890 字节/token约为 DeepSeek-V4-Flash 的 1/4
持久化 KV 占用—约为 V4-Flash 的 1/8
KV Cache 规模（更长跨度）缩小约 437 倍相对初代模型（官方口径）

437 倍是官方给出的更长跨度对比，基线是初代模型，和上面两行的基线不是同一个口径，不能相乘也不能混用。

五、为什么 KV Cache 是「长上下文推理成本的地租」

这个说法值得展开，因为它是理解这次发布真正价值的钥匙。

在长短文混合的 Agent 负载里，一次交互的成本大致分成三块：

  • prefill：把新进来的上下文（仓库结构、文档、工具返回）喂进模型 —— 由 O(NL) 决定
  • KV Cache 显存占用：把历史上下文的隐状态一直留在显存里 —— 这是随对话轮次单调增长、且不随输出长度下降的部分
  • decode：逐 token 生成 —— 由激活参数量决定

在典型的 Agent 场景里，真正昂贵的是第二块。Agent 改到第 40 个文件的时候，显存里拖着的上下文包括：仓库结构、测试输出、工具返回、失败记录、重试历史 —— 而它刚刚生成的那几百 token 相比之下几乎可以忽略。

这就是「地租」的含义：KV Cache 是你为占着显存不放的那段上下文持续缴纳的租金，租金按上下文长度逐 token 计，跟你这次说了多少话无关。

所以把全局 KV Cache 压到 1/4，直接对应两件事：

  • 同样显存可以服务约 4 倍的并发上下文 —— 同样的卡、同样的并发上限，能挂住更多长会话
  • 同样负载用约 1/4 的显存 —— 同样规模的 Agent 集群，硬件采购和机房成本直接降一档

这两条改写的正是长文本智能体（代码仓库理解、长文档审阅、多轮 Agent 记忆）的单位经济性。对这类负载，KV Cache 压缩比跑分重要得多 —— 跑分决定「能不能做」，KV Cache 决定「做一次要花多少钱、能不能撑到并发规模」。

六、基准：Flash 在若干维度超过了上一代旗舰

官方给出的对比对象是上一代旗舰 V4-Pro-0813（厂商发布的对比数据，非第三方独立测评）：

基准V4.1 FlashV4-Pro-0813
Terminal-Bench 2.190.6%87.9%
DeepSWE v1.174.2%62.7%
NL2Repo-Bench65.4%61.5%
CyberGym88.1%83.3%

另有 GPQA Diamond 90.9%、HLE 36.8%、Codeforces Rating 3471（Codeforces 为评分制，不是百分比）。

几点读法：

  • 新一代 Flash 在 Terminal-Bench 2.1 上超过了上一代旗舰（90.6% vs 87.9%），DeepSWE v1.1 的差距更明显（74.2% vs 62.7%）。如果这些数字在你的任务分布上成立，那么「Pro 级能力」的历史预算需要重新审视
  • HLE 36.8% 与 Terminal-Bench 2.1 的 90.6% 分属不同难度量纲，不能直接相减。二者共同说明：该模型在长程工具使用上表现突出，而知识密集型推理（以 HLE 为参照）相对保守 —— 具体差异需看同基准的横向对比。别因为它代码和 Agent 基准强就默认它也擅长需要大量背景知识的开放式推理
  • 另外 V4.1 Flash 的视觉理解是做进基础模型的（原生支持图像与文本输入，不是外挂视觉编码器），这一点在多模态任务上少一层拼接损耗，但同样需要用你的图文混合任务验证

七、模型名变更：迁移路上的坑

这次发布附带了一轮命名调整，这是接入方最需要注意的部分：

  • API 新模型名为 deepseek-flash
  • 旧名 deepseek-v4-flash、deepseek-v4-flash-vision-exp 随模型下线，请求会被暂时兼容路由到 V4.1 Flash
  • 官方计划有序下线 V4 Pro
  • 并发限制从 V4 Pro 的 500 提升到 2500
  • API 价格同步下调

「暂时兼容路由」这个措辞很关键 —— 它意味着旧模型名不会立刻报错，而是静默地路由到新模型。好消息是不会有硬失败，坏消息是：你的响应格式、输出长度、乃至某些任务的答案质量可能在不报错的情况下发生变化，而你的监控看板上一个红灯都不会亮。

正确做法是把模型名替换当成一次主动的、有回归验证的迁移：显式改成 deepseek-flash，用固定测试集对比迁移前后的输出差异，而不是等兼容路由自己过期。

八、第三方生态反应

发布首日，OpenCode Go 就接入了该模型，并限时 72 小时把 V4.1 Flash 的用量限制提升到 4 倍 —— 官网用量表上 5 小时预估请求数从 6,500 改成了 26,000。同时用量表仍把该模型的月度额度列为 $15。

这个生态反应比跑分更能说明问题：一个第三方工具愿意在首日就用「限时 4 倍」的额度补贴来导流，说明它在这个模型上的单位任务成本便宜到值得让利。工具厂商用真金白银投票的信号，通常比基准表更接近生产环境的真实体感。

九、对开发者的影响与选型建议

  • 把「降价」和「架构创新」的关系搞对。这次的降价是架构创新的副产品，不是烧钱补贴：FP4 量化 + SWA Bounded Replay 把单 token 的缓存地租降下来了，成本曲线随之下移，价格下调只是把这条曲线传导出来。这和「先降价再补能力」的路线有本质区别 —— 架构驱动的降价是可复制的、可持续的，补贴驱动的降价会随时反转
  • 优先把长上下文负载切到 Flash。代码仓库理解、长文档审阅、多轮 Agent 记忆这几类任务，是这次架构改动收益最大的场景：prefill 折半、KV Cache 降到 1/4。厂商把该模型的并发上限从 500 提到 2500，是 5 倍；从容量角度看，KV 密度提升 4 倍意味着同卡可承载的并发上下文约 4 倍（前者是厂商给的配额上限，后者是显存密度推出来的容量上限，二者不是同一个量）。多租户 Agent 服务尤其要把这两个数分开看
  • 但要先自己验证 FP4 的质量代价。4 bit KV + 块级缩放是有精度损失的，损失大小取决于你的上下文长度和任务类型。建议做法：拿一批真实的超长上下文任务，对比 FP4 版本和上一代在相同 prompt 上的输出，差异超出可接受范围再回退
  • 不要因为跑分就全线切走。HLE 36.8% 与 Terminal-Bench 2.1 的 90.6% 分属不同基准、不同难度量纲，不能直接相减 —— 但两者指向的方向确实相反：代码与 Agent 基准上强，不代表知识密集型推理同样强。任务分布偏「代码 + 工具调用」的适合切；偏「长知识推理 + 开放式分析」的，先小流量对比再决定
  • 提前排期 V4 Pro 的迁移。官方已明确在有序下线 V4 Pro，而 Flash 在 Terminal-Bench、DeepSWE 上已经超过 V4-Pro-0813。把它当成一次主动的架构简化机会 —— 少维护一条模型线，路由策略也更简单
  • 迁移时显式改模型名。旧名 deepseek-v4-flash / deepseek-v4-flash-vision-exp 的兼容路由是静默的，不会报错但会改变行为。显式改成 deepseek-flash，配一套输出回归测试，比等兼容期结束再被动改要安全得多
  • 在接入层把模型名做成映射表。这次一个 deepseek-flash 就换掉了 deepseek-v4-flash 和 deepseek-v4-flash-vision-exp 两个名字，而官方还预告了 V4 Pro 的下线。模型名变化会持续发生，业务代码里出现任何一个具体的模型 ID，都是未来的一个改动点
  • 把推理强度做成可配置。V4.1 Flash 支持 1–100 连续可调的推理强度，这是比「换模型」细粒度得多的成本旋钮。简单任务调低、复杂任务调高，比一刀切地选 Flash 或 Pro 更精准

十、写在最后

这次发布最值得记住的不是 90.6% 的分数，也不是 552B 参数，而是 890 字节/token。

在长上下文成为主流的今天，KV Cache 已经从「推理框架的内部优化」变成了决定 Agent 产品单位经济性的核心变量。它不体现在任何榜单上，但它决定了你能不能在有限的显存里挂住足够多的长会话、能不能把「每百万 token」这个计价单位真正做小。

更值得注意的是降价和架构的因果顺序。是先把成本压下来，价格才跟着降，而不是先降价再想办法把服务撑住。这和过去两年「先补贴换份额、再找成本结构」的做法是反的 —— 也就意味着，这一轮的低价不太可能是昙花一现。

对使用方来说，接下来该做的两件事很清楚：把长上下文负载尽快切到 Flash 验证单位成本，同时把模型名从业务代码里清出去。前者是这次发布给你的红利，后者是下一次发布不会给你的从容。