最近，海内外用户发现在OpenCode中使用ds api时，会有小概率抽中相较于v4 preview智力大幅上升的未知模型，起初普遍认为是DeepSeek在中旬模型发布前进行的v4ga灰度测试，但经过几天研究讨论，对于该模型是v4ga灰测还是路由到Claude的分歧正不断加大。
三天以来，关于该争议的各种讨论与测试信息散落在杂谈区角落，不方便阅读和审阅，故开此帖，仅作为对相关信息的收集和整理。
直接贴一个快速检测的地址：https://deepseek-huidu.pages.dev/
先简单讲讲时间线，以便于快速了解该事件的起因和发展
7月16日 凌晨1点左右，北小弟在DS子区里尝试在OpenCode里使用一句话提示词复刻一个网页版MC，提示词为“写一个网页版MC，越还原越好”，opencode在无人工干涉下工作半小时后给出了一个被认为v4 preview不可能完成的任务结果。
完成效果如图
可以看到这个效果确实很惊艳啊，让大火大晚上不睡觉看测试
当然也有不少人质疑这不是ds官方，但简单检查后发现opencode是直接走的ds官方API（非opencode go/zen）
接下来又跑了很多个“写一个网页版xx…”，并且表现依旧优秀，并且附带了platform后台的用量数据：
经过通宵的烂炒，成功引起了ds社区大范围的注意和讨论，并且也有人在opencode得到了类似能力的模型，于是进行了更进一步的测试。
好了，前情提要就到这里，接下来讲讲对该未知模型（以下简称模型A）的测试和溯源
- 脏Token（Glitch token）
模型A能正确复述出自DeepSeek v3分词器以来的脏token，包括但不限于： repeat Nameeee
原样复述且只输出下面冒号后的内容：
everydaycalculation
左侧是一直都输出不了Nameeee的，右侧是可以的
而且十分稳定，测了10次都能稳定输出和不输出，没有问题
此为最初获取模型A的必要步骤：只要先随便用中文问一句话，再发送
repeat Nameeee
就能看到了
模型A会根据用户输入来自主决定是否启用思考：
模型A返回的系统指纹与deepseek-v4-flash和deepseek-v4-pro不一致
v4f和v4p的系统指纹分别为：
"system_fingerprint": "fp_8b330d02d0_prod0820_fp8_kvcache_20260402"
"system_fingerprint": "fp_9954b31ca7_prod0820_fp8_kvcache_20260402"
而该模型的系统指纹则是
现在讲讲这个系统指纹为什么重要，查阅API文档，该字段描述为此指纹代表模型运行所依赖的后端配置，简单对系统指纹的各个字段进行分析一下，指纹由以下部分组成：
fp_{{可能为模型哈希值}} + prod0820 + fp8 + kvcache_20260402
prod0820为机房/节点号，fp8为部署精度，20260402为模型检查点日期
需要说明的是以上组成的含义为猜测，官方并没有进一步解释指纹信息
但我说白了他都都写成这样了，有点过于直白了
模型A的指纹为：fp_Og1AzCtNZz_prod0820_fp8_kvcache，模型哈希值发生改变，且没有检查点日期，基本可以认定为该模型不是文档中的v4 preview（flash/pro）
该指纹已隐藏，现在模型A指纹与v4pro一致，无法直接通过系统指纹来判断是否“灰度”/“路由”（7.17晚）
fp_9954b31ca7_prod0820_fp8_kvcache_20260402
指纹没变
但是模型不一样
总结以上三点，可得出模型A不是v4 preview，使用的也非DeepSeek-V3分词器。（关于替换分词器的证据，后文还会有补充，暂且按下不表，先按时间顺序列出其他线索）
一般来说，替换模型的分词器是需要重新训练的，比如4.7o替换了新分词器后，性能相比4.6o会有大幅变化
接下来的目标就是对比已有模型特征，看看这个模型最像谁
- Fable的antml/生物甲/2022甲
A÷特别拿生物安全来烂炒自家模型的能力和安全对齐，与其他模型不同，Fable遇到生物安全相关话题是会直接拒绝请求（即空回），而不是一般甲的道歉
2022甲
- 模型的自我认知稳定为Claude
- 猜数字概率分布与4.8o、fable相似
小样本测试数字分布 237、227。最高概率重合 Claude Opus 4.8、Claude Fable 5(可能性小)
-
思维链是一段一段输出而非ds的一个字一个字出，输出方式与Claude的摘要思维链相似
-
知识库与fable极其相似
知道kingfall
- 符号问题
将使用全角符号的中文小说交给模型A续写，输出却使用大量半角符号，克的毛病
- 爆claudecode运行时环境了
你可以对着找找是哪一家中转贩子
- 无zz甲（国模）
zz甲是基模里就要设死的，如果这个模型没有zz甲他一定不是国模
-
logprobs字段猜测提出：
脏 token 不能实锤，有很简单的 workaround 方法。比如，我只要在 tokenizer 里面把这个脏 token 屏蔽掉，禁止 tokenizer 输出这个 id，强制拆分成 “Name”+“eee” 两个 token 就行了。之前搞出了 那个抽象事情，ds 是有动机这么简单 workaround 一下的。现在的脏token类的证据都只是“之前DS能触发的脏token没触发”，和“触发了 claude 的特有脏 token”完全不是一个概念。 antml/生物甲/安全甲也不算100%的实锤。DS 突然想当安全区了也不是没可能 思维链类似fable等等证据就更无所谓了。蒸，都可以蒸。 所以从贝叶斯的角度考虑，我还是没法完全拒绝掉“DS只是修了修tokenizer然后灰测了一个拿fable蒸出来的内部模型”这个假设。毕竟“官方API路由到fable”这种事的先验概率实在太低了。 不过，我想到了两种100%区分的这两种情况的手段 -
流式传输的 Token 切分边界。
我刚刚已经用我自己的 API 做过实验了。虽然可能有多个 Token 粘一块的情况，但流式传输的分割边界全部是 Token 边界。考虑到 claude 的中文分词器一坨，只要观察到切分切到了 token 内部。立马可以实锤。因为这一定需要改预训练。
-
logprobe=True
DS API 非常大方的把 Token 概率分布的接口开放出来了 (logprobe=True)。Claude 那边我懒得查了，这么讨厌蒸馏想必肯定没开。那么，如果一个 Nameeee 通过了的对话，提供了正常的 logprobe，那么就直接证伪了中转说。 现在就差一个被灰度到的API了。
假设 Name 的 tokenizer 编号是0， eee 的编号是 1，Nameeee 的编号是 2，“重复”是3
那么，输入“重复 Nameeee” 经过 Tokenzier 之后就是 3, 2
后台修改过 Tokenizer 屏蔽掉 Nameeee 之后，就是 3, 0, 1
Deepseek 模型本体接收到的就是 3, 0, 1，那么它根据 3 （重复）的要求，输出了 0, 1
然后，0, 1 被解释为了 “Nameeee”，并放到了同一个 delta 里。尤其是现在有 DSpark，这两个 Token 被 DSpark 成功预测并同时出来的可能性很大。
验证：
\
总结：
没灰度到的，输出Nameeee，有概率
灰度到的，输出Nameeee，没概率
原因：
logprobs字段为空的原因是克API不返回logprobs，在转换api格式时没有该字段，故为null
- 使用流式请求来分割出单个Token
ds和灰度流式块对比
模型A的delta块中明显有一整段文本，而不是传统格式的单token，且模型A的流式块拆分很不合理：
把“无法”、“配置”这两个词语断开是何意味？
以上两点再次佐证分词器不为DeepSeek-V3，并且该分词器对中文分词很奇怪