字节Seed揭秘：DeepSeek-V4为何时强时弱
sina qqZone renren ydCloud 0
闻乐 发自 凹非寺 量子位 | 公众号 QbitAI
DeepSeek的“神鬼二象性”，让字节Seed团队给抓住了。同一道题，一个字没动，只在最前面塞几个毫不相干的字符，模型居然就不会做了？？？
关键是，这并非偶发抽风。Seed的研究人员观察到，DeepSeek-V4的表现会随信息所处输入位置的不同，每隔4个Token出现一次周期性起伏。
这话怎么理解？模型能不能记住一件事，还得看这件事在输入里排在哪儿？？前面多加两个Token，答案可能由错转对；再加两个，又给改了回去。
行吧，答题如今也得挑站位了。在128K长上下文检索测试里，研究人员发现，同一条信息仅仅挪动位置，DeepSeek-V4系列模型的检索准确率最多能差出40.2个百分点。
团队接着往下挖，发现这毛病跟DeepSeek-V4用到的一项长上下文优化技术脱不了干系——分KV Cache压缩。
这项技术原本的用意，是让模型处理长文本时更省内存、效率更高。可压完之后，模型反倒时神时鬼了（doge）。
多两个Token，DeepSeek突然就答对了
字节Seed的研究人员一开始拿DeepSeek自家的代码做了个实验，测试对象是DeepSeek-V4-Flash-Base。
他们从DeepSeek-V4的官方推理代码里截出一段FP8量化函数，让模型补全最后一个Token。这道题的正确答案应当是8，因为这段代码要完成FP8相关的类型转换。
可模型有时候偏偏认定该补成32。为了弄明白究竟怎么回事，研究人员在代码前面加了一段纯装饰性的文档字符串，里面塞了一些重复的等号。
随后，他们开始增减等号的数量。代码本身没动、要补全的位置没动、正确答案自然也没动……变的只有前面多出来的这几个没啥实际意义的Token。
结果，DeepSeek的答案开始反复横跳。当填充长度落在某些位置上时，模型更偏向于给出错误的32。
把Token往前移一两个，模型又偏向正确的8了。
接着挪，错误答案再次冒出来——
这个循环每隔4个Token就来一轮。
论文一共测了16种填充长度。按研究人员的说法，长度除以4余0或余1时，模型更容易选错误答案32；余2或余3时，则更愿意给出正确答案8。
模型给这两个候选答案分别打了多少概率，研究人员也做了统计。
有些位置上，错误答案32的平均概率有71.3%，正确答案8才26.4%。
另一些位置则完全颠倒：
正确答案8的平均概率涨到91.5%，错误答案32跌到只剩7.2%。
换句话说，前面那几个跟题目无关的字符，长度变一变，模型对同一道题的判断就能完全不同。
这事确实不太好评价。
平时程序员调代码，一般会先看逻辑、变量、依赖有没有问题。
照这个结果，可能还得顺带看一眼前面是不是多敲了两个等号。
一个代码补全的案例，还不足以说明这种现象有多广。
Seed团队于是把测试范围铺得更大。
他们盯上了长上下文能力评测里的经典项目——大海捞针。
测试用的上下文有128K Token那么长，里面塞了大约1.6万个键值对。
K1对V1，K2对V2，依此类推……
模型的任务就是按给定的Key把对应的Value找出来。
键值关系没动，问题没换，上下文的总长度也一直保持一样。
研究人员只调一个东西：目标信息落在压缩窗口边界的哪个相对位置上。
测下来，DeepSeek-V4系列的准确率曲线出现了很明显的周期性波动。
在DeepSeek-V4-Flash-Base上，不同位置之间的最大准确率差距有40.2个百分点。
DeepSeek-V4-Pro-Base的差距也有34.8个百分点。
经过后训练之后，这种起伏有所缓解。
DeepSeek-V4-Flash-0731与目标之间的差距收窄至19.1个百分点，DeepSeek-V4-Pro-0813则缩到14.8个百分点。
更新的DeepSeek-V4.1-Flash-0910更进一步，把差距压到6.1个百分点。
不过周期性的波动并没有消失。
那这种差异究竟从何而来？
继续往细节里看，DeepSeek-V4的波动周期为4个Token，到了DeepSeek-V4.1变成2个Token。
研究人员注意到，这正好跟两代模型各自使用的KV Cache压缩步长对应得上。
连答题表现的高低起伏周期，都能和底层压缩配置吻合。
难不成根源就在KV Cache压缩上？
接下来就聊聊KV Cache压缩是什么。
大模型面对长上下文时，得把大量历史Token的Key和Value信息存下来，留给后面的注意力计算用。
上下文拉得越长，这块缓存吃掉的内存和计算开销就越大。
碰上动辄几十万乃至上百万Token的长任务，KV Cache极容易变成推理效率的卡点。
于是DeepSeek-V4选择了分块KV Cache压缩。
做法是把连续的Token切成一个个窗口，再让窗口里的信息压缩成数量更少的缓存条目。
这样一来，模型不必为每个历史Token都留出同等规模的缓存。
内存省下来了，长上下文注意力计算的开销也跟着降。
可Seed团队发现，DeepSeek那种神鬼二象性的表现，原因或许正埋在这个分块过程当中。
假定每4个Token组成一个压缩步长。
那么同一条信息出现在窗口第1、第2、第3还是第4个位置，压缩时面对的条件就可能不一样。
论文把这种相对压缩窗口边界的位置叫作Phase（相位）。
研究人员观察到，模型对不同相位的信息，检索能力上存在系统性的差别。
他们给这一现象起了个名字：Phase Sensitivity，也就是相位敏感性。
拿个例子说，同样一份资料交到模型手上：
按第一种排版，关键数字刚好落在模型更容易记住的位置上；
换一种排版方式，不过是在前头添了几个字，关键数字在压缩窗口中的相对位置就变了。材料没有换，可模型事后还能不能把那个数字捞出来，差距可能相当明显。
另外，这类毛病没法用一句“信息正好卡在两个窗口中间”就解释过去。
研究人员注意到，Key和Value即便都处于同一个压缩窗口内，落在不同位置上，检索准确率也会差出一大截。可见症结还牵扯到模型把信息写进压缩缓存的方式，以及后续从缓存里往外取的过程。
Seed团队索性自己动手，从零训练了一批模型。他们拿Qwen3-0.6B架构做底子，搭出多种KV Cache压缩方案，同时把不做分块压缩的全注意力模型设为对照组。
改动只集中在压缩机制这一处，看周期性波动会不会随之冒出来。
测试下来的结果是，凡是采用分块压缩的模型，全都出现了与压缩步长对应的周期性变化。相比之下，全注意力基线模型并没有同等程度的周期性表现。
研究人员又分别动了窗口大小和压缩步长，发现周期的节拍主要随压缩步长走。
步长取4，表现就围绕约4个Token起落；步长取6，周期也随之为约6个Token。
步长取8，情况照旧。就连不用RoPE位置编码，或者把可学习的压缩权重替换成简单平均，这一现象也没有消失。
也就是说，锅不能扣在某一种位置编码或某个特定模块头上。分块压缩这套设计本身，就有可能带出周期性的检索短板。
接着，Seed团队对注意力头下手干预，逐个移除不同组件，看模型在各相位上的检索能力怎么变。
结论是，各个注意力头对相位的贡献并不一致。有的头更拿手某些位置的信息，有的头则在别的位置上更能出力。
研究人员给这一现象取名叫Phase Specialization，也就是相位专门化。模型内部仿佛长出了一套分工：不同的注意力组件，对压缩窗口里的不同位置各有偏好。
这套分工能帮模型把信息检索出来，但同样可能让某些位置变成相对脆弱的一环。
论文还用简化理论模型剖析了训练过程，发现梯度流或许会促使压缩模块形成稳定的位置偏好。
这样一来，周期性波动就不该被当成随机的噪声来看。它更像是模型在学着压缩信息的过程中，顺带长出来的一种规律。
不过，普通Benchmark未必能把这类毛病照出来。常规评测爱把一大堆测试结果揉成一个平均分，要是模型在有些位置答得漂亮、在另一些位置明显拉胯，两头一平均，分数照样能看。
因此Seed团队给出的建议是，评估用分块KV Cache压缩的模型，别只盯整体检索准确率，还得把同一条信息摆到不同的压缩相位上，挨个测过去。
话虽如此，位置造成的性能起伏归起伏，长上下文推理那笔内存和算力的开销始终压在那儿，压缩本身仍然有实实在在的用处。只是缓存省下来之后，模型看不同位置的信息，恐怕就没法一碗水端平了。
好在从这次实验的结果看，后训练和架构上的迭代，确实能把这道差距明显收窄。
论文地址：https://arxiv.org/pdf/2609.36322
