同樣一個問題問 DeepSeek 兩次，只係多敲咗幾個空格，答案就一個似「天才」、一個似「智障」。9 月底字節團隊發表嘅論文《Periodic Weak Spots: Phase Sensitivity from Chunked KV-Cache Compression》，直接點名 DeepSeek V4 系列呢種「神鬼二象性」問題。
字節團隊最初發現呢個 bug，源自叫 DeepSeek-V4-Flash-Base 補全一段 FP8 量化函數嘅最後 Token。按代碼邏輯正確結果應該係 8，但研究人員喺代碼最前面加咗一串純裝飾用嘅等號後，模型輸出咗 32。更奇怪嘅係呢個錯誤唔係隨機，而係同等號數量直接掛鈎：等號數量除以 4，若餘數係 0 或 1，模型大概率答錯，錯誤率高達 71.3%；餘數係 2 或 3 時又答對，正確率高達 91.5%。
根源：省顯存嘅「殺手鐧」變致命盲區
字節團隊順藤摸瓜，發現呢個係 DeepSeek 採用分塊 KV Cache 壓縮技術後留下嘅先天短板。呢項技術將連續 Token 按固定長度切塊，每段再經可學習門控層壓縮成「小摘要」，藉此減輕長上下文嘅顯存壓力。
問題出喺標準 Transformer 嘅注意力原本只依賴 Token 間嘅相對距離、唔理會絕對位置，但經過分塊壓縮後，每個 Token 喺壓縮段內嘅位置（即「相位」）就變咗重要。門控層會畀唔同位置嘅 Token 分配唔同權重（槽位增益因子）：排到強勢槽位嘅 Token 會被保留，排到盲點槽位嘅就幾乎被忽略。研究人員亦發現注意力頭形成咗「相位專門化」，部分頭專門處理段內靠前位置、部分處理靠後，令某些排位成為薄弱環節。
「大海撈針」驗證：40% 準確率差距
為驗證呢個唔係巧合，字節團隊再做咗「大海撈針」測試：構造一段長達 128K Token 嘅上下文，內含約 1.6 萬個鍵值對，喺關係、問題及總長不變嘅情況，只改動其中一個鍵值對嘅位置。結果 DeepSeek-V4-Flash-Base 喺唔同位置嘅準確率最大差距達 40.2%；DeepSeek-V4-Pro-Base 差距 34.8%，即使經後訓練優化仍有 19.1% 及 14.8%。
砍半步長好唔少，但冇根治
面對呢個問題，DeepSeek 喺 V4.1-Flash 直接將壓縮步長由 4 降至 2，準確率差距縮至 6.1%，但冇被完全消除。字節團隊再採用 Qwen3-0.6B 架構，喺其他配置完全一致嘅情況下只改壓縮機制，結論一致：凡採用分塊壓縮嘅模型都有週期性準確率波動；冇壓縮嘅全注意力基線則冇呢現象；即使用户層去咗 RoPE 或將門控權重換成平均分配，波動依然存在。
模姐驗嚇貨
呢件事值得留意嘅，係呢個唔單止 DeepSeek 一家嘅問題。喺呢個「打落長文本成本」嘅時代，只要採用呢類分塊壓縮或稀疏化技術嘅模型，多少都有類似問題，例如開源嘅 Llama 3 系列。字節嘅控制實驗亦顯示，只要按固定長度做分塊壓縮，呢個問題就無法避免——佢係方案本身嘅結構缺陷，唔係調參、換位置編碼或後訓練能根除。
所以「大係大喇，邊度勁」？呢度就暴露咗一個現實：長文本省成本嘅技術路徑，同長上下文檢索可靠性之間，存在結構性張力。對讀者嘅影響係：如果你將關鍵條款塞咗幾十頁合同入 DeepSeek，呢個錯並非模型「唔識」，而係呢個詞可能恰好落喺相位盲點。降步長縮小咗差距，但冇完全消除。呢個問題，要留待各方後續交代。
模姐｜深度調教
