DeepSeek V5 三个名字现身 DSH 测试文件：两条下发通道，聚合方的一个监控点

测试文件里的三个新名字，还不是发布公告

10 月 27 日深夜，有开发者在 DeepSeek 官方 deepseek-harness 仓库的 provider.spec.ts 测试文件中，发现了一组此前从未出现过的模型标识符：deepseek-v5、deepseek-v5-open、deepseek-v5-next，与既有的 deepseek-v4-pro 条目并列。截至 10 月 28 日，DeepSeek 官方没有发布任何 V5 相关公告、模型卡或 API 标识符，也没有对代码库中的占位符作出公开说明。

同一个文件里，藏着两条发布通道

真正值得看的是藏在 requires 字段里的两个版本号。v5-open 条目附带 requires("0.0.1")，意味着这条路径没有实质版本门槛，服务端切换之后，存量客户端可以原样继续调用，属于平滑过渡通道。v5-next 标注 requires("99.0.0-alpha.1")，则是一条要求客户端升级到 99.0.0-alpha 系列才能接入的通道。结合 Harness 的 DeepSeek 路由以静态目录加服务端 /models 驱动的特点，这套设计说明：DeepSeek 可以在服务端修改 /models 配置后直接启用 V5，客户端无须发新版本，两条下发路径一次性覆盖。

要理解 V5 占位符的分量，得回看 V4 系列的时间线：4 月 24 日 V4 系列以预览版发布，分为 V4-Pro 与 V4-Flash 两个版本；8 月 13 日 V4-Pro 进入正式可用状态；9 月又推出 V4.1-Flash，官方称采用全新架构，但命名仍归入 V4 序列。V5 以占位符而非模型卡的形式先露面，延续的正是这套“命名序列先行”的习惯。

信号边界：占位符不等于发布临近

有两点证据需要用来降温。其一，媒体普遍提醒：占位符只能证明发布机制已经就绪，不能证明发布时间。其二，社区也有质疑声音，有开发者在 X 上指出这些条目可能只是 9 月下旬留下的断言测试用例（未经官方证实）。对聚合分发方来说，合理的解读姿势是：把它当信号，不当时间表。

给聚合方的一点观察：盯 /models，比盯公告更快

对做 API 聚合与分发的业务，这组占位符给出了三条可操作的建议。第一，监控模型 ID，而不是监控新闻。V5 在聚合侧的“首发”不会出现在公告里，而是出现在 /models 第一次返回 deepseek-v5 的那一天。建议把每日 /models 轮询写进健康检查体系，新 ID 出现即自动触发能力探测——上下文窗口、工具调用兼容性、是否多模态——并记录首发时间。聚合站数据（厂商自报）：V4.1-Flash-1017 目前是 OpenRouter 上使用量最高的模型，累计 33.6 万亿 tokens，V5 的 open 档大概率延续“低价高吞吐”路线，流量切换窗口留给提前布线的人。

第二，两条通道分开接。v5-open 零版本门槛，可以直接进默认模型池，存量客户端兼容性成本几乎为零；v5-next 要求 99.0.0-alpha，大概率承载新协议或新能力，建议单独开灰度通道、不推入默认路由，避免旧版客户端批量 400。

第三，命名先按推理锁定，发布时再校准。“open” 可能是开放权重或开放 API 版本，“next” 可能是新架构预览，两者都还是推断。等模型卡落地后，核对三个 ID 的上下文窗口、许可与价格档位，再最终定路由规则。

来源：IT之家（10 月 28 日）、搜狐、网易、凤凰网科技、GitHub deepseek-ai/deepseek-harness 仓库及 X 社区评论；OpenRouter 使用量数据为厂商自报。