整理 | 屠敏
出品 | CSDN（ID：CSDNnews）
几天前，DeepSeek V3.1 版本低调上线。这一次升级虽然算是小版本更新，但亮点也不少：它采用了混合推理架构，一个模型同时支持“思考模式”与“非思考模式”，推理效率提升 20%-50%，同时兼容 128K 长上下文处理；另外，它也引入 UE8M0 FP8 参数精度格式，内存占用降低 75%，还适配了国产下一代芯片，降低对进口 GPU 的依赖。
只不过近来，随着越来越多开发者上手测试，问题也冒出来了——V3.1 在生成文本时，会莫名其妙地跑出「极」、「極」、「极速」或者「extreme」这些 token，而且概率完全随机。
更令开发者有些发懵的是，即便你提醒 DeepSeek V3.1 这个问题，它也不能百分百解决与修复。
用户实测
根据网友的反馈，最开始是在火山引擎、chutes 等第三方 API 上出现的这个问题：
来源： https://linux.do/t/topic/897789
也有知乎用户@Fun10165 称，在调用 VolcEngine DeepSeek V3.1 帮忙整理一份物理试卷的时候发现输入包含了“极板”这些词：
硅基的 API 也有这样的问题存在：
另外，还有人在腾讯新推出的 Codebuddy AI 编程工具中发现了类似的问题，譬如这款工具会自行在 UI 界面里面添加“极速赛车开奖”、“极速电竞”等 token。
来源：小红书用户@ 奈绪白 Nine-piece shell
起初，大家猜测可能是第三方服务商在模型量化、部署配置或硬件上的差异导致的，是个偶然的 Bug。
然而，随着实测的增多，大家陆续发现，不止第三方 API，DeepSeek 官网同样也存在这个问题。只不过，相比官网，第三方平台出现概率更高一些。
一旦出现了这些 token，后续还会变得更加频繁：
不止国内社区，国外社交媒体平台 Reddit 上也有用户反馈自己遇到了这个问题。
网友@notdba 在一封为「DeepSeek V3.1 – “extreme” / “极” / “極” 令牌无缘无故出现问题」帖子中写道，他在使用 DeepSeek V3.1 做测试时，发现模型会在完全意想不到的地方生成以下 token：
" extreme" (id:15075)"极" (id:2577, 简体中文的“极”)"極" (id:16411, 繁体中文的“極”)
和大部分开发者一样，他一开始也是以为自己做的 extreme IQ1_S 量化或者 imatrix 校准数据集的某个边缘情况导致的，但后来在 Fireworks 提供的 FP8 全精度模型上同样出现了这个问题。
对此，他还贴了几个测试案例：
案例 1（local ik_llama.cpp，top_k=1，temperature=1）：
期望输出：time.Second
生成结果：time.Se极
Logprobs：
"top_logprobs": [{"id": 2577,"token": "极","bytes": [230,158,129],"logprob": -1.3718461990356445},{"id": 1511,"token": "cond","bytes": [99,111,110,100],"logprob": -1.5412302017211914},{"id": 1957,"token": " second","bytes": [32,115,101,99,111,110,100],"logprob": -1.9008493423461914}]
案例 2（本地 ik_llama.cpp，top_k=1，temperature=1）：
期望输出：time.Second
生成结果：time.Se extreme
Logprobs：
"top_logprobs": [{"id": 15075,"token": " extreme","bytes": [32,101,120,116,114,101,109,101],"logprob": -1.0279325246810913},{"id": 2577,"token": "极","bytes": [230,158,129],"logprob": -1.077283263206482},{"id": 9189,"token": " extrem","bytes": [32,101,120,116,114,101,109],"logprob": -1.8691496849060059}]
案例 3（Fireworks，top_k=1，temperature=1）：
期望输出：V1
生成结果：V极
Logprobs：
"top_logprobs": [{"token": "极","logprob": -0.27936283,"token_id": 2577,"bytes": [230,158,129]},{"token": "1","logprob": -1.90436232,"token_id": 19,"bytes": [49]},{"token": "極","logprob": -2.40436196,"token_id": 16411,"bytes": [230,165,181]}]
@notdba 表示，“我对所有流行的编程模型都做了同样的评测，这是我第一次遇到这种问题。”
同时他还追加了自己的几个发现：
在 Novita 上也看到同样的问题，所以问题很可能不是推理堆栈引起的。
目前怀疑问题可能被 MTP 掩盖，当推理堆栈不支持 MTP 时就显得很明显。
情况比想象中的还严重。 @notdba 透露，他 查了之前版本上有关“极”Token 出现的评测，发现 DeepSeek V3 0324 也有上述的情况发生，会在随机的位置出现「极」、「extreme」。
除此之外，@notdba 称，他还发现，最近的 Qwen3 235B A22B Instruct 2507 和 Qwen3 Coder 30B A3B Instruct 也出现同样的症状，可能出现在和 DeepSeek V3 0324 类似的阶段。同时，Qwen3 Coder 480B A35B Instruct 只有在强量化后才会出现类似症状。「看起来这两个实验室可能使用了相同被污染的数据。 」GLM 4.5 不受影响。
对此，有网友认可这样的发现， 称 V3-0324 确实有类似问题：
还有人想起了曾经的 R1 也会在输出的 token 中包含中文“极”，只是当时没注意：
此外，在 DeepSeek V3.1 输出时，还会有不少中英文混杂、各种省略号（…）的情况。
或是数据集“污染”
至于为什么 DeepSeek V3.1 会突然冒出「极」或者「extreme」，官方到目前为止还没有回应。
不过，一些技术人分析发现，这个「极」字在模型中的 token ID 是 2577，而它紧邻省略号（…） token ID 是 2576，对此，他们认为有两种可能性：
一是数据集“污染”：可能是在数据清洗阶段，有些包含特殊或错误字符的数据没有被彻底过滤掉。
二是模型“偷懒”：在训练时，模型可能找到了一种“捷径”——当它遇到不确定的上下文时，会优先选择一些频繁出现或邻近的 token，从而导致「极」「extreme」这种奇怪的输出频繁出现。
也有知乎用户@AI 解码师（https://www.zhihu.com/question/1942934856603505597/answer/1943250946730726808）判断——这是训练数据和蒸馏链条里遗留下来的瑕疵，其解释道：
模型在枚举数列时，会在长串输出的尾部插入一个奇怪的收尾标记，例如“极长的列表”。这个词很可能是在预训练或 SFT 数据合成时遗留下来的。换句话说，数据里本身就存在“极长的…”这样的表达，没有被清洗掉，而模型在学习枚举模式时，不小心把「极」当成了一种语义边界符。
而且，当这个模式一旦进入 RL 或自蒸馏阶段，它就可能被放大。模型会把「极」误认为是某种 终止符或切换标记，于是即使在正常的推理输出中，也可能随机触发。这种触发率往往很低（比如千分之一），但是在大规模用户测试里就会显得刺眼。这背后反映出一个更深层次的问题：大模型并不是在真正理解语言，而是在学习数据分布里的统计规律。如果训练数据中混入了“极长的数组”这种模式，模型就可能把它当成一种“隐含的指令”，而不是单纯的自然语言。
毋庸置疑，这个问题影响还是不小的——这些奇怪字符频繁出现，会让模型在编程、结构化输出等需要精确结果的场景下表现不稳定，也可能干扰信息的准确性。目前，还得等 DeepSeek 官方的回应和修复。
话说，你在使用过程中有没有遇到类似的情况呢？
参考：
https://www.reddit.com/r/LocalLLaMA/comments/1mzsg6v/deepseek_v31_getting_token_extreme_%E6%9E%81_%E6%A5%B5_out_of/
https://linux.do/t/topic/897789/16
https://www.zhihu.com/question/1942934856603505597/answer/1943250946730726808
