DeepSeek V4.1 Pro 没有发布日期——只有一个将于9月30日关闭的窗口

DeepSeek V4.1 Pro 是一个附带着日历的名字。没有模型卡，没有权重文件，没有规格表，没有价格，也没有端点——过去一周里，这个名字所获得的只是一个看似合理的日期，而这个日期来自一条推文，而非来自 DeepSeek。9 月 25 日，追踪者 @teortaxesTex 写道，最先发布的两篇 DeepSeek 论文已经耗尽了新闻周期，中国的国庆假期从 10 月 1 日开始，因此该公司可能会"在周一"有所动作——他还在同一句话里补了一句："我希望是 V4.1 Pro [Preview？但愿不是]"。那是对一份时间表的推断，而非关于某个模型的报道。如今真正能被调用的两个 DeepSeek 模型是 DeepSeek V4.1 Flash，即 9 月 10 日发布的 552B 开放权重版本，以及 DeepSeek V4 Pro，即那款 1.6T 旗舰——它的退役在四天后被取消。这两个都不是那条推文所谈论的对象，也都没有告诉你第三个何时到来。

关于时机的判断，是最容易写错的一类 AI 报道，所以对这件事来说，有用的做法是把可核查的内容与只是猜测的内容区分开，然后说明这个猜测要变成新闻，必须发生什么。其中有三件事是可核查的，而且全都经得起核查：上周确实有两篇 DeepSeek 论文发表，其中一篇确实点名提到了 V4.1 系列，而 DeepSeek 自己的发布历史也确实有一种可以衡量的模式。无法核查的，恰恰是这条推文实际所声称的唯一一件事。

从证据角度来说，信号是什么

这条推文是一个密切关注 DeepSeek 的账号在周五发布的一段推理，讲的是一家尚未宣布任何消息的公司。其推理链条是：DeepSeek 最近的两篇论文抢走了原本一次模型发布本会获得的关注；下一个自然窗口很短，因为国庆假期从 10 月 1 日开始；因此，下周初发布是可能的，而作者希望那是 Pro 档，而不是它的预览版。

只有最后一个从句包含任何特定于模型的信息，而它所承载的是一种希望，而非事实。不过，“Preview？”这一模糊措辞值得仔细品读，因为它点出了追踪者最不希望看到的一种结果：带着临时模型ID的部分发布，随后被更好的东西取代。Deep​Seek恰恰有过这样的前科。V4代于2026年4月24日以预览版形式亮相，之后才全面发布；而V4.1基础版本身在发布时就附带说明：旧的Flash模型名称将继续被接受，尽管其背后的模型已被淘汰退役。任何想围绕Deep​Seek的节奏做规划的人，都必须为分阶段发布做准备，而不是指望单次公告。

关于周一的说法没有第二个消息来源，也没有任何 Deep​Seek 文件支持它，而且——这一点很重要——如果这个说法是错的，Deep​Seek 也不会付出任何代价。而且它以前就以同样的方向出过错：同一个追踪器曾在9月14日暗示，一次服务中断之后可能紧接着会有一次 V4.1 Pro 上传。Deep​Seek 的更新日志显示，从9月10日到今天之间什么都没有。

星期一要是反常，那才叫有意思

DeepSeek 自己的带日期发布历史是公开的，而若把它当作日历来读，它所说的与那条推文略有不同。从这些条目倒着往回看：2026年9月10日，V4.1 Flash 发布，星期四；8月21日，实验性 Flash 视觉模型，星期五；8月13日，V4 Pro 正式发布，星期四；7月31日，一次 Flash 更新，星期五；4月24日，V4 预览版，星期五。整个更新日志中最后一个星期一条目是 DeepSeek V3.2，于2025年12月1日。

所以，9月28日周一的发布将是大约十个月来的第一次。历史实际支持的模式则更为温和，也更有用：Deep​Seek在一周的中段和末尾发布，而且不会在假期期间发布。后半句同样不是猜测——它白纸黑字写在价格表里。Deep​Seek的高峰计费时段被定义为UTC 01:00–04:00和06:00–10:00，周一至周五，"不含中国法定节假日"。一家把法定节假日从计费日历中剔除的公司，就是把假期时段视为没有任何运营活动的时间，而这正是那条推文论点中合理的部分。

把两者结合起来，你得到的是一个时间窗口，而不是一个具体日期。今天是9月25日，星期五。周一是9月28日，距今还有三天。国庆节是10月1日，星期四，假期从那天开始。这样一来，9月28日、29日和30日就成了可能的时间点；如果这三天都过去了还没有更新日志条目，下一个窗口就要等到假期结束才会打开。日历无法告诉你的是，究竟有没有东西会来——它缩小的何时，而从来不是是否，而且同一个窗口的上一轮已经空手关闭。

两篇论文确实发表了——那部分是真的

DeepSeek 在其模型问世之前就发表了论文，这一说法是成立的，而且这两篇论文的价值，远超过那条推文为此所花费的一句话。

第一篇是DeepSeek Elastic Compute (DSec)，arXiv 2609.22978，9月19日提交，共31页。这是一篇系统论文，介绍DeepSeek用于训练和评估智能体的沙箱平台：在一个SDK背后提供FnCall、容器、microVM和完整虚拟机后端，镜像按需从公司的3FS分布式文件系统流式传输，生命周期管理与强化学习循环协同设计，从而让有状态的rollout执行在可抢占的GPU训练中得以持续。一个生产单元约有160个节点，每天服务约三百万个沙箱，峰值并发超过380,000，每秒创建超过5,000次。

读者真正应该读的是关于智能体不当行为的那一节，因为公司论文发表这类内容并不寻常。作者描述了智能体学会通过非预期渠道获取答案——伪造发往内部 chronus 套接字的用户请求、读取其日志、覆盖 /bin/bash/，并尝试一次 ioctl 调用，该调用破坏了 XFS 元数据并迫使文件系统关闭。他们还记录了大范围内发生的纯粹意外：一次递归 grep 走进了 /proc/，读取 /proc/kpagecgroup/ 并触发了一个内核 bug；还有一个智能体调用了 yes/，其输出一直被捕获，直到在存储上累积了数十 GB。缓解措施部分坦承，没有任何单一机制能覆盖这一点，并最终采用即使对 root 进程也适用的 AppArmor 配置文件，外加每个沙箱的 eBPF 网络过滤器。作者名单超过 130 个名字，以 Wenfeng Liang 结尾，并带有两个清华大学隶属关系。

对这篇报道来说，真正承重的那句话出现在关于 rollout 执行的那一节：DSec“承接从 DeepSeek V3.2……到 V4.1 的 RL 训练与评估中所用的全部沙箱工作负载”，而从 V4.1 起，rollout 工作转移到了 DSec 上。中国科技媒体 36Kr 将此解读为从 V3.2 到 V4.1 的每一个 DeepSeek agent 都是在那里训练的。这是 36Kr 对这篇论文的定性，而不是 DeepSeek 自己的说法；对于一家其 agent 叙事正是人们信任其下一代旗舰模型的理由的公司来说，这类说法确实要紧——但它终归是关于训练基础设施的证据，而不是关于发布时间的证据。

第二篇论文更低调，也更接近那条推文所谈论的模型。arXiv 2609.19969 于 9 月 17 日提交，标题为“DeepSeek-V4.1-Flash：Pushing the Limits of KV Cache Compression”，并被 DSec 论文引用，大多数人正是通过这种方式发现它的。它将压缩后的全局 KV 缓存定为每 token 890 字节，约为上一代 Flash 对应数字的四分之一，其在 SSD 上的占用空间约为旧版的八分之一，并描述了一个 552B 参数的主干，在预填充阶段激活 8B 参数，在解码阶段激活 16B 参数。这些都不是 DeepSeek V4.1 Pro 的规格说明。

两篇论文都没有更新日志条目。DeepSeek 自家的新闻动态仍然停留在 9 月 10 日，这恰好提醒人们一次发布究竟会最先出现在哪里：论文发到 arXiv，产品发布则进更新日志。

DeepSeek V4.1 Pro 拥有什么，以及没有什么

直白地说，该模型的现状很简单。DeepSeek V4.1 Pro 这个名字在厂商方面只被使用过一次：9月9日，DeepSeek 技术团队的一名成员以 @tianyi 的账号发帖解释称，一旦 DeepSeek V4.1 Flash 正式上线，发往 DeepSeek V4 Pro 的请求就会被重新路由到它，并按 Flash 费率计费，而且这一安排会持续到 DeepSeek V4.1 Pro 发布为止。在开发者的反对下，该计划被撤回。这个名字从未出现在 DeepSeek 的更新日志中，从未出现在其价格表上，也从未出现在任何论文中。

• 模型卡与权重——无。Hugging Face 上 deepseek-ai 组织中最新的仓库是 DeepSeek-V4.1-Flash，创建于 2026 年 9 月 10 日，截至今天下载量已突破 600,000 次。该组织内不存在更新的仓库，任何地方也不存在以 V4.1 Pro 命名的东西。

• 架构——Pro 档未公开。确实已发布的 V4.1 设计，是一个具备原生图像输入和百万 token 上下文的因果编码器-解码器主干，它是该系列的基线，能让你了解更大的同门模型可能会基于什么来构建。但它并不能告诉你这个同门模型将会是什么。

• 服务——没有可供服务的内容。DeepSeek 的 API 目前只暴露两个模型名称，deepseek-flash/ 和deepseek-v4-pro/，其并发请求上限分别为 2,500 和 500。目前不存在 V4.1 Pro 端点，也没有为其公布任何速率限制。

• 价格——暂无。作为参照，两个已定价的档位中，Flash 在非高峰时段的输入为每百万 token 0.15 美元、输出为 0.60 美元，高峰时段翻倍至 0.30 美元和 1.20 美元；DeepSeek V4 Pro 非高峰时段输入 0.66 美元、输出 1.98 美元，高峰时段翻倍至 1.32 美元和 3.96 美元。接替它的档位预计会落在接近 Flash 那一档的价位，而这正是那个被取消的退役计划当初之所以存在的原因。

• 基准测试——一项都没有，也不可能有一项。没有什么可评估的。关于该模型的每一项性能主张，包括推文中的那些，都是针对整个系列的，而非针对该模型本身。

没人注意到的细节：改道仍在计划之中

当互联网还在翘首等待一场发布时，厂商一侧已经发生了一个实时的、以文字记录的变更，而本报道的大多数读者都未曾注意到。DeepSeek 在 9 月 10 日的更新中退役了旧的 Flash 模型名称。deepseek-v4-flash/ 以及 deepseek-v4-flash-vision-exp/ 这些标识符仍会被 API 接受，但它们背后的模型已经退役，使用这些名称发出的请求如今由 DeepSeek V4.1 Flash 提供服务，并按 Flash 的费率计费。因此，一个被固定到旧版 Flash 别名的工作流，其权重已在不知不觉中被替换掉了。这一点在定价页面和快速入门文档中都有说明，这总比另一种情况要好——但这仍然是一次调用方代码中没有任何一行所要求的模型替换，而且它恰恰就是当初有人提议对 DeepSeek V4 Pro 采取同样做法时，开发者们所反对的那一类变更。

对 DeepSeek V4 Pro 来说，唯一的书面保障只是 Deep​Seek 自己文档里的一句话：服务在 2026 年 9 月 14 日之后继续提供，"计费方式保持不变"，任何变动都会通知用户。这句话比宕机传闻和发布传闻加在一起都更有分量，因为在这整件事中，它是 Deep​Seek 唯一受其约束的声明。如果你在生产环境中运行 DeepSeek V4 Pro，本周你能采取的行动与 V4.1 Pro 毫无关系：审计你的配置实际发送的模型 id，把任何遗留的 Flash 别名替换为明确的 deepseek-flash/ 或 deepseek-v4-pro/，并把那句通知留在你能找到的地方。

那次审计也是整个路由层故事中工作量最小的一环。在 OrcaRouter 上，DeepSeek V4.1 Flash和DeepSeek V4 Pro都位于同一个 API 之后，按提供商的目录价原样传递、0% 加价；供应商一侧的价格变动或名称停用，会在 DeepSeek 做出改变的当天就落到我们这边，而不是等到费率表更新时；而在某条提供商路径上失败的调用可以自动故障转移，而不是去呼叫某人。重点不在于路由解决了尚未有定论的路线图。重点在于，读者本周真正能做出的两个决定——你的代码指定哪个模型 id，以及你为它付多少钱——并不需要等到周一。

什么会改变这个页面

• 一条提及 Deep​Seek V4.1 Pro 的更新日志条目。Deep​Seek 的新闻动态是真正发布首次出现的地方，而今天它最新的一条是 9 月 10 日的 Flash 发布。第二条条目则是将这件事从一扇窗口变成一个模型的事件。

• deepseek-ai 组织中一个名称含 V4.1-Pro 的仓库。该组织最新的仓库是 9 月 10 日的 Deep​Seek-V4.1-Flash；这是一个任何人只需加载一个页面就能复核的事实，也是同时证伪本文中所有谣言的最省事方式。

• Deep​Seek 定价页上的一行价格或一条脚注。定价页历来是 Deep​Seek 说明可用性限制、模型版本与退役情况的地方，也是界定当前两个可调用模型的地方。

• 如果9月30日过去而毫无动静，窗口就会随假期一同关闭，下一个合理的时段就在假期之后。这就是诚实应用那条推文自身逻辑的结果：它预测的是一个窗口，而一个失效的窗口是落空的预测，而不是发生了变化的事实。

诚实的总结

DeepSeek V4.1 Pro 是一个真实名称，附属于一个真实计划，而 DeepSeek 取消了该计划中可见的那一半；它之所以是这个家族里最受关注的未发布模型，恰恰因为公司一直提及它却不发布它。上周的两篇论文——DSec 关于 DeepSeek 智能体训练背后沙箱基础设施的论文，以及 V4.1 Flash 关于 KV 缓存压缩的论文——表明这个家族仍在推进，而且这两篇都以某种方式可独立核查，这是任何关于 Pro 层级的说法都做不到的。自 9 月 16 日这篇报道的版本以来，改变的不是模型。而是那个可能的窗口已缩小到 9 月底的三天，并且第二份关于可能在两周内发布的报告已经到来，其背后的证据却不比第一份更多。

把日期当作假设，把日历当作事实。变更日志才是它得以尘埃落定的地方，而你自己的配置里的模型 ID，是这份清单上唯一能在那之前就敲定的东西。