图 1：deepseek-harness 仓库首页（截图于 2026 年 10 月 29 日，265k stars、32.1k forks、MIT 协议）

DeepSeek V5 真的要来了吗

大消息来了，就在 10 月 27 日晚间，有开发者在 DeepSeek 官方开源项目 deepseek-harness 的测试文件中，发现了一组此前从未出现过的模型标识符：deepseek-v5、deepseek-v5-open、deepseek-v5-next。它们与已有的deepseek-v4-pro并列，位于provider.spec.ts文件第 154 行附近。

消息在开发者社区迅速扩散，不少人将其解读为"DeepSeek V5 已进入发布倒计时"。但在热闹之外，有几个更值得追问的问题：这三个字符串到底是什么、它们能证明什么、又不能证明什么。

截至发稿，DeepSeek 官方未就 V5 系列发布任何公告、模型卡或 API 标识符，也未对代码库中的这组条目作出公开说明。

一、三个后缀，对应三种发布路径

根据代码结构，这三个条目并非可直接调用的模型接口，而是框架层面的占位角色。它们出现在"账号登录通路"的测试文件里，测的是这样一条链路：

用户登录账号后，客户端会向服务端的/models接口请求一份模型清单，再根据清单决定哪些模型可以直接用、哪些需要先把客户端（DSH）更新到新版本。

三个条目的分工如下：

图 2：packages/llm/llm-deepseek-account/tests/provider.spec.ts第 138 至 184 行，高亮区为第 150 至 166 行，三个 V5 标识符与对应的断言一览无余

其中99.0.0-alpha.1这个数字是关键线索。目前公开的 DSH 版本还停留在 0.2.x，距离 99.0.0 差着几十个大的版本号，实际上永远不会达到。这显然不是一个真实的目标版本，而是一个用来稳定触发"版本不足"分支的哨兵值。

核对 GitHub 上的原始文件（packages/llm/llm-deepseek-account/tests/provider.spec.ts），相关段落如下：

constserver=awaitlisting(json({data:[FLASH,{...PRO,id:'deepseek-v5'},{...PRO,id:'deepseek-v5-open',...requires('0.0.1')},{...PRO,id:'deepseek-v5-next',...requires('99.0.0-alpha.1')},{id:'deepseek-v4-pro'},]}))constctx=awaithost(server.origin)awaitctx.plugin(Account,{baseURL:server.baseURL})expect((awaitctx.llm.listModels('deepseek-account')).map(row=>row.id)).toEqual(['deepseek-flash','deepseek-v5-open'])awaitexpect(ctx.llm.prepareCall({provider:'deepseek-account',model:'deepseek-v5'})).rejects.toMatchObject({code:'MODEL_UNSUPPORTED'})awaitexpect(ctx.llm.prepareCall({provider:'deepseek-account',model:'deepseek-v4-pro'})).rejects.toMatchObject({code:'MODEL_UNSUPPORTED'})awaitexpect(ctx.llm.prepareCall({provider:'deepseek-account',model:'deepseek-v5-next'})).rejects.toMatchObject({code:'CLIENT_UPGRADE_REQUIRED',message:expect.stringMatching(/requires DeepSeek Harness 99\.0\.0-alpha\.1 or later; current version is/)asstring})

这段断言把三种结局写得很清楚：清单里返回的 5 个模型，最终只有deepseek-flash和deepseek-v5-open两个能进用户的可用列表；deepseek-v5报MODEL_UNSUPPORTED；deepseek-v5-next报CLIENT_UPGRADE_REQUIRED，提示语是"需要 DeepSeek Harness 99.0.0-alpha.1 或更高版本，当前版本是……"。

同文件另一个用例（第 144 行）还给出了当前的基线：当/models接口挂掉、客户端回退到内置目录时，列表是['deepseek-flash', 'deepseek-v4-pro']。也就是说，V5 目前既不在内置目录里，也没有出现在任何线上接口中。

换句话说，DeepSeek 把 V5 上线时可能遇到的三种局面，提前写进了测试用例。

二、先搞清楚：这里的 DSH 是什么

DSH 指的是deepseek-harness，DeepSeek 官方开源的模型调用框架。可以理解成"连接用户和 DeepSeek 模型之间的客户端适配层"：它负责拿模型清单、判断哪些能用、处理版本不够时的提示与回退。因为它在 GitHub 上公开开发，任何人都能看到提交记录，这次的线索正是从这里被翻出来的。

这一点决定了线索的边界：发现位置是客户端适配层的测试文件，不是模型权重仓库，也不是模型卡。所以它能证明的是"客户端这边已经准备好了"，而不是"模型那边已经好了"。

这次被翻出来的文件是packages/llm/llm-deepseek-account/tests/provider.spec.ts，289 行、11.6 KB，最近一次改动是 10 月 27 日由同一位开发者提交的 badge 相关用例。

这个仓库的分量值得单独说一句：截至发稿，deepseek-harness 在 GitHub 上有约26.5 万颗星、3.2 万个 fork，采用 MIT 协议，今年 8 月 13 日才建库，官方主页挂在 deepseek.com/harness。一个两个月做到 26 万星的开源项目，被开发者逐行翻找是再正常不过的事。这次的线索，本质上就是"开源项目被读得太仔细了"的副产品。

三、真正值钱的是这套机制，不是那三个名字

多位分析者指出，这组代码透露的信息不止于"V5 是否存在"。

在传统的模型发布流程里，新模型上线需要客户端同步发版，用户得先去应用商店更新才能看到新模型。而deepseek-v5-open这条路径意味着：服务端只要改一下/models的返回内容，新模型就能直接对所有客户端开放，无论用户装的是哪个版本。

仓库的更新记录里还有一条相关改动：DeepSeek API key 适配器现在和账号登录使用同样的方式来更新模型列表。这说明这套机制正在被推广到更多入口，不只是 DSH 本身。

用一句大白话概括：DeepSeek 正在把模型迭代变成一次服务端的热更新，客户端只是个壳。

四、提交时间是 9 月 24 日，比传闻早了一个月

一个容易被忽略的细节是：这三个条目并不是 10 月 27 日才上传的。

GitHub 记录显示，实际提交时间是2026 年 9 月 24 日，提交者署名Yichen Jiang（GitHub IDLegGasai）。据公开资料，他毕业于清华大学，是 DSH 项目的核心贡献者之一（初期提交数排名项目第二），参与了模型适配、Web、连接恢复等模块的研发。

也就是说，在 V4.1-Flash 刚发布、外界还在讨论"架构全换了为什么还叫 4.1"的时候，工程团队已经在后台为新版本铺路了。

逐条核对了该文件的提交记录：三个占位符首次出现在提交0a13e89（完整 SHA 为0a13e89b0dd8d9094aa87fbaff867043250af72e），时间2026 年 9 月 24 日 05:10（UTC），提交标题是"让 DeepSeek 账号目录改由账号侧的 listing 提供"。这一次改动涉及 3 个文件，新增 231 行、删除 36 行，提交者署名Yichen Jiang（GitHub IDLegGasai）。

图 4：提交0a13e89，“让 DeepSeek 账号目录改由账号侧的 listing 提供”，3 个文件、+231/-36，作者 LegGasai，Sep 24

同一天的 08:48，这位开发者又提交了一次类型检查相关的修补（6d602d7），占位符原样保留。此后 10 月 22 日至 27 日，该文件又有多轮改动，但 V5 三个条目始终没被动过。

用 GitHub 的 blame 视图逐行回看，可以更直观地确认这一点：三行 V5 代码的归属提交，正是 9 月 24 日那次"serve the DeepSeek account catalog from the account listing"。

图 5：blame 视图下，第 154 至 156 行的归属指向同一次提交

图 6：provider.spec.ts的提交历史。9 月 24 日之后的改动几乎全部出自同一位开发者

顺带纠正一个流传中的细节：有说法称发现者是"翻到最新提交才看到"，实际上从 9 月 24 日到 10 月 27 日，这组代码已经在公开仓库里静静躺了一个月零三天，期间又经过了 7 次提交，没有任何一次删掉它。

五、两派观点：占位符，还是路线图？

对于这组代码的含义，社区分成两派。

乐观派认为这是强信号。理由有三：占位符可以用任意字符串，DeepSeek 偏偏选了 V5；它一次性为 V5 设计了"平滑过渡"和"强制更新"两套完整的灰度方案；业内不会为一个不在路线图上的名字，去搭分级发布的基础设施。

谨慎派认为这是过度解读。这些命名仅存在于模拟模型列表之中，主要目的是测试客户端在面对未支持模型或遇到版本升级请求时，能否正确执行拒绝调用或提示升级的回退逻辑。测试用例并未透露任何正式的模型参数规模、发布时间表或可用 API 接口。

IT 之家在报道中给出了一个更稳妥的界定：占位符的出现并不等同于发布临近。现有代码只能证明"发布机制已经就绪"。

六、网传的那些规格，目前都不能信

需要提醒的是，随着消息扩散，网上开始出现一批"DeepSeek V5 详细规格"，包括 1.8 万亿参数、128 个专家、MLA 2.0 注意力、SWE-bench 81.4%、MATH-500 96.8%、每百万 token 0.12 美元 / 0.48 美元的定价、MIT 协议开源等。

经核查，这些数字出自若干第三方内容站点，没有任何一手来源支撑，且彼此之间存在明显矛盾（有站点称 V5 已于 2025 年发布、参数 6710 亿，与"尚未发布"的时间线直接冲突）。

判断一个新模型是否真的可用，唯一可信的三个标志是：官方公告、模型卡（Model Card）、公开上线的 API 标识符。目前这三个一个都没有。

七、DeepSeek 的产品节奏：为什么是现在

把时间线摆出来，这次的猜测才有坐标：

一个值得琢磨的细节是命名策略：V4.1-Flash 明明换了全新架构却没有叫 V5，10 月中旬一次提升明显的更新也没给 V4.2。一种合理的解释是，DeepSeek 把 V5 这个旗舰序号留给了一次真正的代际跨越，而不是小修小补。

八、观察：发布机制比版本号更值得关注

综合现有信息，我的判断有四点。

第一，这确实是有效的工程信号，但强度被高估了。它能证明的是"DeepSeek 内部已经把 V5 当作一个需要认真对待的发布对象来准备基建"，不能证明 V5 已经训练完成、更不代表发布在即。

第二，真正有行业意义的是那套"无感更新"机制。如果模型迭代可以完全由服务端控制、客户端零感知，那么模型厂商就获得了按负载、按区域、按用户类型动态下发不同模型能力的调度自由度。这比某一个版本的分数提升，对行业的影响更长远。

第三，请对"偷跑"式爆料保持克制。开源仓库里的测试用例本来就是工程师的日常工作区，里面出现未发布的字符串是常态。把占位符当成发布倒计时来传播，既容易误导，也容易给官方制造不必要的压力。

第四，顺带说一句这次之外的背景。就在 10 月 20 日，DeepSeek 刚把内部实际运行的推理框架 DeepInfer 连同编解码组件 deepseek-recipe 一起开源，成为首个公开原生生产推理框架的头部厂商。把这件事和 V5 的占位符放在一起看，能拼出一条更清晰的线索：DeepSeek 正在同时加固"模型层"和"服务层"两侧的基础设施。前者决定能力上限，后者决定这个上限能多便宜地交付出去。。

参考来源

• IT 之家报道：https://news.qq.com/rain/a/20261028A0A69M00
• 凤凰网科技报道：https://i.ifeng.com/c/8xaMcSLMa0g
• 腾讯新闻报道：https://news.qq.com/rain/a/20261028A0B7FE00
• deepseek-harness 仓库：https://github.com/deepseek-ai/deepseek-harness
• 涉事测试文件（permalink）：https://github.com/deepseek-ai/deepseek-harness/blob/master/packages/llm/llm-deepseek-account/tests/provider.spec.ts
• 引入占位符的提交0a13e89：https://github.com/deepseek-ai/deepseek-harness/commit/0a13e89b0dd8d9094aa87fbaff867043250af72e
• 该文件提交历史：https://github.com/deepseek-ai/deepseek-harness/commits/master/packages/llm/llm-deepseek-account/tests/provider.spec.ts
• GitHub REST API（仓库元数据、提交记录）：https://api.github.com/repos/deepseek-ai/deepseek-harness