在 DeepSeek V3/R1 时代，API 中的模型 ID 是 deepseek-chat 和 deepseek-reasoner。随后从 V3/R1 更新版、V3.1 发布、V3.1 更新版，再到 V3.2 发布，这两个模型 ID 也没有任何变化。

别家模型虽然也会提供始终指向最新版模型的 gemini-flash-latest 别名，但一般情况下都会同时提供 gemini-3-flash 这样固定版本的模型名称。

随着 4 月份 DeepSeek V4 Flash 和 V4 Pro 发布，不知道是不是由于 DeepSeek V4 Flash 是思考模型，API 模型 ID 的封印终于松动了，改为 deepseek-v4-flash 和 deepseek-v4-pro。被官方宣布即将退役的 deepseek-chat 和 deepseek-reasoner 两个 ID，则分别对应 V4 Flash 的非思考模式和思考模式。

然而混乱还没有结束。在 4 月份，除了我这样的“聪明人”，没有人注意到新闻稿中的“预览版”三个字，而模型 ID 中也不包含 preview 的后缀。今天 DeepSeek V4 Flash 的正式版发布，然而模型 ID deepseek-v4-flash 再一次没有任何变化。

这就带来了一个问题：除非直接连接官方 API，仅凭模型 ID，我们无法判断自己使用的究竟是预览版还是正式版。

我甚至可以大胆假设，如果有 V4.1、V4.2 这样的迭代，任性的 DeepSeek 会不会继续沿用 deepseek-v4-flash 和 deepseek-v4-pro 两个 ID，这样的混乱是否还会继续？

为什么 DeepSeek 要这么做呢？我个人的猜测是，这是因为 DeepSeek 不希望在旧模型的维护上耗费成本。

你看，假设原先的模型 ID 是 deepseek-v3.2，当 V4 发布时，这个模型 ID 要怎么处理？如果直接路由到 deepseek-v4-flash，那实际调用的模型和 ID 对不上；如果保留 V3.2，那他们就必须在一定时间内留出一些算力资源给旧模型，也留出时间给开发者过渡。

对于 DeepSeek 这样的“小厂”来说，他们不想将有限的算力资源分给旧模型，因此选择通过使用相对固定的模型 ID 来避免维护旧模型带来的成本。

对于想避免频繁更新的开发者，这是一件好事；但这种“无预警替换”的方式对于需要确定模型效果、需要预先了解价格、想在升级模型之前多花费一些时间测试的人来说，则会成为一种包袱。

如果忽略 .x 的小版本更新，现在的两个模型 ID 可以撑过完整的 V4 生命周期。不知道当 DeepSeek V5 到来时，deepseek-v4-flash 和 deepseek-v4-pro 两个 ID 是会直接路由到 V5，还是破天荒地保留旧版模型？