DeepSeek V4.1 Flash：一个顶着点版本号的全新基础模型

DeepSeek V4.1 Flash发布已有六天，其发布时留下的三个悬而未决的问题如今都已尘埃落定——其中两个对公司有利，一个则明显不利。模型本身与 9 月 10 日相比没有变化：一个拥有 5520 亿参数的专家混合模型，以 MIT 许可证开放权重，上下文长度达一百万 token，并采用了新的因果编码器-解码器架构，厂商自家的模型卡将其归入公司所称的“新架构家族”。发生变化的是它周围的一切。一家独立评估机构发布了一项评分，而发布当天早上还没有任何评分。公司撤回了其在自家更新日志中宣布的DeepSeek V4 Pro退役计划。而那天早上尚不存在的首日服务工作，如今已在多个主流推理运行时上运行——其中最难的两部分，即 Engram 内存表以及生产部署所依赖的预填充/解码拆分，仍在公开地积极重做中。

命名错位仍然是这篇文章存在的理由。把“V4 Flash 到 V4.1 Flash”理解为一次补丁式升级，是再自然不过的做法，也是错误的做法：版本号距离一次重新调校只差一个小数位，而其底层架构却开创了一个家族。六天来的证据并未让这一点有所缓和。如果说有什么变化，独立数据反而让它更加确凿，因为一个得分超过自家厂商 1.6 万亿参数旗舰的模型，并不是一次小版本发布——它是一代拒绝为自己命名的模型。

9月10日实际发布的内容

这不是一次泄露，也不是测试版。9月8日开始、为期两天的 API 测试，其模型 ID 为deepseek-v4.1-flash-expires-on-0910；它正如其后缀所表明的那样结束了，而此次发布已在 DeepSeek 的网页应用、移动应用和第一方 API 上线，权重和技术报告已在 Hugging Face 上发布，地址为deepseek-ai/DeepSeek-V4.1-Flash。

六天来，实际细节没有任何进展：

• 模型名称 — 调用 deepseek-flash。旧名称 deepseek-v4-flash 和 deepseek-v4-flash-vision-exp 仍被接受，但不再解析为原先的模型：两者均已退役，使用这些名称的请求将由 DeepSeek V4.1 Flash 提供服务，并按 Flash 费率计费。

• 包含哪些内容 —— 100 万 token 上下文窗口、384K 最大输出、JSON 输出、函数调用、原生图像输入，以及默认开启的思考模式，并提供低、高、最高三档推理力度设置。

• 许可证——MIT，权重已包含在内，仓库中有一个推理文件夹和一个单独的编码模块。DeepSeek 明确邀请开源社区在第一天就构建推理支持，而社区的响应速度比这一邀请所暗示的还要快。

那个不是小版本更新的 .1

这篇报道的起因是 teortaxesTex（一位匿名但备受关注的 DeepSeek 观察者）在 9 月 10 日帖子中的说法：这是“DeepSeek 首次用 .1 版本号来标记一个全新的基础模型”，V4.1 与 V4 的差异“比 LLaMA 3 与 LLaMA 1 的差异还要大”，而且 DeepSeek“还不觉得这值得称为 V5”——尽管发帖人无法解释原因。

将因果部分视为推断，将结构部分视为可核查的。推断——为什么 DeepSeek 选择 .1 而非 V5——只是一个观察者的解读，仅此而已；公司内部以外没有人解释过这一决定，DeepSeek 自己的材料也从未提及。可核查的部分是架构，而它读起来并不像一次小版本发布。DeepSeek 的更新日志将 V4.1 Flash 描述为“我们新架构系列中体积最小的模型”，这句话用来描述版本号提升很奇怪：版本号提升是扩展现有系列，而不是开创一个系列。

这种模糊性是有实际代价的，而承担代价的是买家，而不是DeepSeek。版本号是开发者最廉价的信号，用来判断“这是新一代产品还是重新调优？它值得我投入多少评估预算？”DeepSeek现在让这个信号在某个方向上变得不可靠——一个开创了架构系列的模型，与一个只是改变了后训练配方的模型，版本号只相差一个小数位。该公司得以把V5这个标记留作后备。每一个做迁移评估的人都要为这种混乱买单。

"新架构"在权重中意味着什么

模型卡异常具体，这使得代际主张无需任何基准测试即可验证。有五点格外突出——其中第五点正是发布报道大多略过的那个，而对任何想要服务这个模型的人来说，事实证明它最重要。

• 非对称激活——因果编码器-解码器拆分是一个40层Transformer，组织为20层因果编码器后接20层解码器，其中解码器的全局KV缓存由编码器的最终隐藏状态投影而来，而非从每个解码器层自身的状态推导。该设计的要点在于，模型在预填充阶段每个token仅激活8B参数，在解码阶段激活16B参数。输入密集型的智能体工作负载——长文档、长工具调用轨迹——使用模型成本较低的一半；生成则使用成本较高的一半。

• KV cache 压缩，按每 token 计量——DeepSeek-V4.1-Flash 对主 KV 缓存采用 FP4 格式，每 token 占用 890 字节，规格卡显示这一数值约为 DeepSeek V4 Flash 的四分之一。中文报道则更进一步，以第一代 V4 模型为基准，将压缩幅度表述为 437 倍缩减；这一更大的数字是供应商基于不同基准计算得出的，因此应视为宣传说法而非实测数据。

• SWA 有界重放 — 滑动窗口注意力通常迫使你将 KV 状态持久化到 SSD 以重建上下文。该机制改为仅重放最近窗口内的 token 来重建缺失的 SWA KV 状态，从而将持久化 KV 的占用空间削减至 DeepSeek V4 Flash 的约八分之一。

• Compressed Sparse Attention 2 — 每个注意力层以三种静态模式之一运行（Full、Reindex 或 Reuse），跨层共享 KV 和索引器状态；分层稀疏索引器确保更深层的计算成本与上下文长度无关。

• Engram — 一个条件记忆模块，将记忆与计算分离，实现为通过门控注入模型残差流的 n-gram 哈希查找，而不是作为注意力或额外专家。根据 SGLang 自己对该架构的说明，这两个 fp8 表保存了 189 GiB 的权重；而移植了该检查点的运行时供应商则把这两个表算作在 552B 主干之上的约 196B 参数——这就是为什么卡片标题中的参数数量描述的是主干，而不是整个下载内容。Engram 在两个层上训练，采用二阶、三阶和四阶 n-gram，每个阶有八个哈希头，并将归一化后相同的 token 合并，使大小写变体哈希到同一个桶。值得记住的设计细节是它带来的成本：每个解码步骤都会读取这些表，因此你把它们放在哪里，决定了你还剩多少 KV 缓存。

把这五点放在一起看，战略图景就清晰可读了：这首先是一套以稀疏性、缓存效率和内存卸载为核心的架构，其规模经过设定，以便同样的结构日后能够向上扩展。文中提到“新的架构家族”并非虚言——这是在表明还有更多后续。

独立评分终于出炉——而且它支持该供应商

四天前，这一节读起来会大不相同。发布之初，Artificial Analysis 尚未就 DeepSeek V4.1 Flash 发布任何内容，Hugging Face 的模型页面上仍标注着该模型“未被任何推理服务商部署”，而整个发布所倚重的核心论断——一款 Flash 档位的模型在性能、成本、速度和总任务时间上全面胜过一个 1.6T 参数的旗舰模型——不过是厂商的单方面说法，没有任何外部审计。此后，这三个缺口都已补齐。

Artificial Analysis 现已在其智能指数上对该模型进行了测评，简而言之，DeepSeek 的说法经受住了第三方验证：

• Intelligence Index——DeepSeek V4.1 Flash 在最高推理强度下得分为 40，在其对比类别 113 个模型中排名第六，远高于同类开放权重模型 18 的中位数。被指遭它取代的旗舰 DeepSeek V4 Pro 0813 在同一指数上得分为 36。

• 每项任务成本——V4.1 Flash 在 Intelligence Index 任务上为每项 0.27 美元，而 V4 Pro 0813 为 0.67 美元。这就是其“单位美元能力”的主张，且已获独立复现：在这一衡量指标上，更便宜的模型反而能力更强，每完成一项任务的成本仅为前者的约 40%。

• 速度——每秒输出 212.1 个 token，同类模型的中位数为每秒 73.1 个 token；首 token 时间为 1.31 秒，中位数为 2.37 秒。在同一测试框架下，V4 Pro 0813 测得每秒 94.4 个 token，首 token 时间为 1.72 秒。

• 价格 — Artificial Analysis 记录显示，每百万输入 token 为 $0.30，每百万输出 token 为 $1.20，并享受 98% 的缓存折扣；这是 DeepSeek 官方公布的高峰费率，而非第三方的溢价加收。

把标签标对，因为标签已经变了。这些是独立测量结果，不是厂商数据——但它们是在单一第三方评测框架上进行的独立测量，而一个指数并不能构成对某个模型的定论。它真正能确定的，比排行榜上的名次范围更窄，也更有用：DeepSeek 为证明自家产品线合理性而提出的那个具体主张——Flash 会在能力和成本上同时胜过 Pro——如今有了外部印证，而不是背后只有一份更新日志。

另一方面也有一个诚实的保留意见，而且它来自与之前相同的厂商报告。DeepSeek 自己的数据显示，V4.1 Flash 在对阵 Kimi K3 的 16 项对比中赢下 13 项，在对阵 GLM-5.3 的 13 项中赢下 11 项，但在较新的 Terminal-Bench 3.0 和 4.0 任务以及 ProgramBench 上，仍落后于 GPT-5.6 Sol 和 Claude Opus 5。这是一个连贯的形态——在该架构所优化的编程、终端和智能体自动化工作上最强，在前沿推理任务上较弱——而这正是一个真正的代际跃迁会呈现的形态。独立指数与这一轮廓一致，但并未敲定每一个单元格。

DeepSeek 宣布 Pro 退役——随后又取消了

这就是与 DeepSeek 自己声明的计划相比发生变化的部分，而且是最有可能影响实际集成的部分。

发布时，DeepSeek 表示 DeepSeek V4 Pro 将从其 API 中退役。从北京时间 9 月 14 日 12:00 起，指定deepseek-v4-pro的请求将被路由到 V4.1 Flash，并按 Flash 的价格计费——对于任何将 Pro 模型名称硬编码的人来说，输出成本大约降低 70%——并且会一直按此方式路由，直到未来的 V4.1 Pro 发布。在发布当天的价目表上，这意味着 Pro 每百万输出 token 3.96 美元在高峰时段骤降至 Flash 的 1.20 美元，无需更改代码，除了更新日志条目外也没有任何通知。

那并没有发生。9月11日，DeepSeek 在其自家的开放平台上发布了一则通知，称应用户需求，将在9月14日之后继续提供 DeepSeek V4 Pro API 服务，计费方式不变——该通知在9月14日当天、切换时刻已经过去之后仍展示在平台上，因此这是一份仍在展示的第一方声明，而不是关于此类声明的传闻。所报道的原因是这个故事里最不令人意外的一点：开发者反对供应商在生产集成中悄悄替换某个模型名称背后的权重，而 DeepSeek 自己的多方测试发现，即便 V4.1 Flash 在公开评测中胜出，V4 Pro 在某些团队的真实工作负载上仍保持质量优势。

实际解读与发布日报道所建议的完全相反。如果你把9月14日圈进日历，准备重新测试锁定Pro版本的集成，那这个截止日期已经作废：DeepSeek V4 Pro仍然是DeepSeek V4 Pro，定价也一如既往，而V4.1 Pro依旧没有公布——没有模型卡、没有参数量、没有日期，也没有权重。没有改变的是行进方向——DeepSeek显然打算将其产品线收敛到新架构上，而关于旧架构，它唯一确认的是不会在某个固定日期强制迁移。

为其提供服务：189 GiB 的 n-gram 表，而工作仍未完成

发布时对可用性的表述是“只能在供应商的 API 上运行，别处都不行”。这已不再是事实，而它在何处不再成立，对理解这一架构很有启发。

SGLang 和 Miles 在 9 月 10 日就为 DeepSeek V4.1 提供了首日支持，与模型本身几乎同时亮相——因此发布时挂在 Hugging Face 页面上的那条“无第三方服务”说明，几小时内就已过时。有意思的不是它能跑起来，而是跑起来要付出什么代价。由于每个解码步骤都要读取 Engram 表，SGLang 的做法是让你把它们放在 GPU 内存或主机内存中，而主机卸载可为 KV 缓存每块 GPU 腾出约 46 GiB，代价是节点上约 200 GB 的主机内存。在四 GPU 的 GB300 配置上，主机卸载将 KV 缓存容量提升了 36%，解码吞吐和首 token 时间相当，而且全部 28 个贪心探针补全结果都与全部放在 GPU 上的基线一致。它是可选项，由一个环境变量控制，并非默认行为。vLLM 则在做方向相反的并行工作——将表的各个分片从磁盘内存映射，而不是保存在主机内存中——这从两个角度说明了同一件事：制约这个模型能以多低成本提供服务的，是 Engram 表，而不是权重。

整个故事里最新的改动就在这儿，而且都是些小改动，也理应被标注为小改动。9月15日，一位SGLang贡献者打开了拉取请求#39666，为项目的DeepSeek V4.1分支添加了一个Engram模块和一个共享的请求历史适配器——7个文件，+1205/−11，该适配器在调度器和前向批次上暴露可选的n-gram历史字段，并在前缀命中、撤回和槽位复用过程中重建该历史。它处于打开且未合并状态，CI运行接连失败，并且正等待九位代码所有者的审查；作者自己的总结直言其局限，指出查找检查并不能证明请求生命周期的正确性。它是9月15日在该分支上打开的一批DeepSeek V4.1拉取请求之一，其中大多数来自同一位贡献者，涵盖模型构建、视觉塔、聊天编码和内核层。

然后，在9月16日，关于服务中更困难那一半的计划公之于众。一个路线图 issue #39700 将 B200 平台上 DeepSeek V4.1 的 prefill/decode 分离列为分阶段清单：先是 prefill 侧的上下文并行，然后是 prefill 工作与 MegaMoE、BCG 和多流相结合，接着是 decode 侧的条目，其中包括 DP attention 和 CUDA-graph memory。第一阶段以拉取请求 #39748 落地，标题为“[DSV4.1-PD-1/8] Support prefill node use cp parallel strategy”，由同一作者在同一天提交。它让分离式部署中的 prefill 节点能够运行上下文并行策略，参考配置为八块 B200，采用 TP4/EP4，运行 flashinfer_mxfp4 MoE runner 和 DSPARK 推测解码。prefill 节点在 Mooncake 传输后端上使用 --enable-prefill-cp --cp-strategy interleave 以及 --disaggregation-mode prefill；decode 节点则完全不使用任何 CP 标志运行。验证方式是 gsm8k 评分，加上针对文本和图像路径的单元测试。与 Engram 拉取请求一样，它处于打开、未合并状态，目前在 CI 中因缺少 run-ci 标签而被阻塞。

要说清楚这一切是什么、不是什么。它是已经为模型提供服务的运行时内部的基础设施管道——它不会改变 DeepSeek V4.1 Flash 能做什么、成本是多少，或者你是否应该使用它。它之所以值得写这几行，只是因为它标出了剩余尖锐边缘所在。在 Engram 这一侧，n-gram 历史在撤回和前缀缓存复用后仍然保留，正是那种区分演示与生产端点的正确性细节。在解聚合这一侧，目标用户是把预填充和解码拆分到独立资源池中的运维者，这样每一半都能针对各自的瓶颈进行并行化——这种部署的参考配置从八块 B200 起步，这是资本决策，而不是配置文件里的一行。而这个系列标为 1/8，路线图 issue 却把它的阶段列举为六部分，整个解码那一半仍未写出：连编号都是临时的。如果你不做那个资本决策，从你所处的位置根本看不到这些——DeepSeek V4.1 Flash 已在 OrcaRouter 上线，采用下方所述的直通费率，而这些管道仍留在端点运营方那一侧。

今天调用DeepSeek V4.1 Flash

我们这边的可用性说明也变了，而且变化的方向，恰恰是本文在发布日版本中明确告诉读者不会出现的那个方向。9 月 10 日，OrcaRouter 并未上架 DeepSeek V4.1 Flash——模型页面返回的是“model not found”，本文当时也照实写明，而没有含糊其辞地暗示相反情况。现在它已经上架了：deepseek/deepseek-v4.1-flash已出现在目录中，价格为每百万输入 token 0.15 美元、每百万输出 token 0.60 美元，即按 DeepSeek 自家供应商费率原样透传、加价 0%，这同样也是下次 DeepSeek 调价时可供核对的数字。自上线以来，它已通过该平台流转 54,982.2M tokens，首 token 时间 p50 为 811 毫秒，p95 为 3.03 秒。

除了同样的价目表之外，它能带给你的，是把一套才诞生六天的架构当作实验而非承诺来对待的能力。故障转移意味着，一个在负载下开始报错的 V4.1 Flash 调用，无需部署就能重新指向另一个模型；路由 DSL 意味着你可以把新模型用于一部分流量、把已知可靠的模型用于其余流量，并基于你自己的输入而非排行榜来比较二者；目录中的其他所有模型都位于同一个密钥之后，包括 DeepSeek 系列的其他成员——DeepSeek V4 Flash 和 DeepSeek V4 Pro——因此切回去只需改一个字符串，而不是再签一份合同。

这一点在这里比平时更重要，原因有二，而六天来的新闻已经让它们变得具体。第一，价格优势是真实存在的，但以提供商维持费率为前提，而只有转嫁安排能在费率不再维持时依然保持诚实。第二，发布周的那一条告诫依然成立：能力优势和成本优势如今都已被独立测量，但测量基于同一个评测框架，且针对的是一个命名上说是“小更新”、架构上却并非如此的模型。把它当作新一代来路由，因为它就是新一代；并把它放在一个你可以随时调整的层级之后。

还有什么未解决

三件事，按照它们会告诉你的信息量升序排列。

DeepSeek V4.1 Pro 本应检验这一家族说法。DeepSeek V4.1 Flash 自称是全新架构家族中最小的一款模型，而本可证明该家族存在的同门兄弟至今仍没有模型卡、没有参数量、没有发布日期、没有权重，也没有价格。它也是整个 Pro 路由操作所围绕的那款模型，而如今这一操作已被叫停。

第二次独立评估将检验这一分数。Intelligence Index 为 40，而被它取代的模型为 36，这在一个测试框架上是明确的结果，但对于这个架构是领先一代，还是优化良好的横向一步这一问题，只是一个单一数据点。要关注是否会出现第二个评估方，以及 Engram-offload 服务路径在真实流量下、而非贪心探测下能否站得住脚，还要关注目前正在拉取请求中分阶段推进的预填充/解码拆分，最终是否会变成一个普通团队能够部署的打包方案。

还有一个实用但不起眼的问题：DeepSeek是否会再次这样做。如果另一个新的基础模型再次出现.1标签，这就会把异常变成惯例，而惯例是开发者可以围绕来进行规划的。一个模型是特例。只有当形成规律时，这种命名才会以一种有用的方式变得具有误导性。

就目前而言，实际的解读可以按你是谁清晰地划分。如果你使用的是 DeepSeek V4 Pro，那么这个名称背后的模型不会在 9 月 14 日或任何已公布的日期发生变化——DeepSeek 已经推翻了那一点，你可以不用改动你的集成。如果你使用的是 DeepSeek V4 Flash，你已经在以相同的价格被迁移到 DeepSeek 为规模化而打造的架构上。而如果你一直在等 V5，那么实话是，DeepSeek 似乎已经发布了这一代产品，却拒绝给它命名，随后才发现包装盒上的数字终究还是承重的。