想象一个场景：你把一份128K token的合同丢进本地跑的DeepSeek，问中间某个条款。它有时答得准，有时死活找不到。你怀疑是显存不够、量化太狠或者推理框架抽风——都不是。字节Seed团队把真凶逮到了：问题不在你的机器，在信息"站"的位置。
多敲两个等号，答案就翻车
起点是个很离谱的实验。Seed研究员拿DeepSeek-V4官方推理代码里的一段FP8量化函数，让模型补全最后一个token。标准答案是8，模型却总想写32。
研究员没动任何代码，只在前面一段装饰性注释里逐个加等号——答案开始在8和32之间反复横跳，每4个token一个轮回。有的位置，错误答案概率高达71.3%；挪两个token，正确答案概率飙到91.5%。连补代码都开始讲"站位"了。量子位
这不是孤例。字节Seed联合普林斯顿、斯坦福、伯克利的研究者做了个"大海捞针"测试：128K token上下文塞进约1.6万个键值对，关系、问题、总长度全不变，只挪目标信息的位置。结果DeepSeek-V4-Flash-Base的检索准确率最大相差40.2个百分点，Pro-Base也差34.8个百分点。结论写进了65页的论文《Periodic Weak Spots》——其中52页是附录，这现象被命名为"相位敏感性"。量子位AI前线
病根，本地玩家其实很熟
元凶是DeepSeek-V4为省长文本算力搞的分块稀疏注意力（CSA），本质是分块KV Cache压缩。玩过长上下文的人都知道KV Cache多能吃显存：把连续token切成窗口、压缩成少量缓存条目，长文本才跑得起。AI前线
但压缩有代价。假设压缩步长是4，同一句话落在窗口里第1、2、3还是第4个位置，被压缩时的条件就不一样。V4的波动周期恰好是4个token，V4.1换了步长，周期跟着变成2——严丝合缝。Seed团队还用Qwen3-0.6B架构从头训了一批小模型验证：所有用分块压缩的都出现周期性波动，全注意力对照组没有。所以这不是DeepSeek一家的bug，是这类压缩方案的通病。量子位
三句实在话
一，版本在变好，选对能躲大半。Base版差40.2个百分点，后训练的Flash-0731缩到19.1，V4.1-Flash-0910只剩6.1。本地选模型优先V4.1和后训练版，Base能躲就躲。量子位AI前线
二，别折腾机器，病根在权重里。现在不少人用192GB的迷你主机本地跑V4-Flash，Q4量化大约17 tok/s。不管你用的是这种一体机还是双卡老主机，相位敏感性都跟着权重走，重装系统、换框架治不了它。哔哩哔哩
三，用法上留个心眼。长文里没找到答案，别急着信"没有"：换个问法、把关键信息前后挪几个字再问一遍，相位一变结果可能就变。正经任务别赌模型在128K里自己捞针，切块做RAG更稳。部署前拿自己的业务数据，把同一条信息放在不同位置各测一遍——论文作者特意提醒：平均分是会骗人的，这种缺陷在常规跑分里根本看不出来。量子位
最后说句题外话。这次硬伤是"对家"挖出来的，恰恰因为DeepSeek开放了权重，字节才能一路解剖到注意力头内部。评论区有人感慨："全世界的程序员都是我的工程师。"对本地部署的人来说，这就是开源最实在的时刻——缺陷摆在明面上，你才躲得开。AI前线
