问大家一个事：你用DeepSeek写代码、查长文档的时候，有没有遇到过它突然“犯糊涂”？
同一道题，什么都没改，它一会儿答对一会儿答错，你还以为是自己的提示词没写好。
最近字节Seed团队发了篇论文，把这个锅从用户身上摘了下来。
第一个，现象很具体。
研究人员拿DeepSeek-V4的官方FP8量化代码做补全测试，正确答案是8。
代码一个字没动，只在前面的文档字符串里增减等号。
等号数量一变，模型在8和32之间反复横跳，周期刚好是4个Token。
第二，问题不只是代码。
在128K长上下文“大海捞针”测试里，信息内容、问题和总长度都没变，只调整信息的位置。
DeepSeek-V4-Flash-Base的检索准确率，不同位置之间最多差40.2个百分点。
第三，根子在分块KV缓存压缩。
为了省内存，模型把连续Token按固定步长压成更少的缓存条目。
这样一来，Token相对于压缩窗口边界的位置，也就是论文说的“相位”，就成了一个新变量。
基础版波动周期是4个Token，DeepSeek-V4.1变成了2个Token，正好和两代模型各自的压缩步长对上。
研究团队从头训练了一批小模型做对照，全注意力模型没有这种周期性。
好在后训练能收窄差距，DeepSeek-V4.1-Flash的落差已经降到6.1个百分点。
我的立场很清楚：省显存和保准确率，不该是非此即彼的选择题。
对开发者来说，别只调提示词，多换个格式重测一遍更实在。
对评测机构来说，只报一个平均分，可能把最要命的短板盖过去了。