[本地 LLM] 我把 FlashMemory 重訓到自己的 Q2 build 上,它還是改善不了 V4-Flash 的 native lightning indexer

白話版:模型自己已經很會挑書,外聘顧問只是想比它更準

想像一間超大的圖書館,你每問一個問題,館員都得決定去哪幾排書架找答案。FlashMemory 這套東西,就像你外聘了一個顧問,叫他事先猜「等下哪些書架要先搬上來」,其他書架先留在地下室、省空間。這主意很聰明——前提是顧問沒有把館員真正會用到的書架漏掉。

問題是,V4-Flash 這顆模型的「館員」本來就很強:它每一步本來就會從可用集合裡抽最相關的書架來看,而且這個抽書架的本事,是它跟其他能力一起練出來的。所以外聘顧問的工作很難:只要它把對的書架留在地下室,再強的館員也沒機會挑到。

我量了內建館員到底多準——拿它去比「如果把整館的書全讀一遍、模型真正會看的是哪些」,它準到 93–96%。那個外聘顧問呢?就算我照我這台機器把它重訓過,頂多也只到 89–92%。不是它爛,是它會限制一個本來就更強的館員。所以我沒裝它。

---

前言

宣稱能省下 90% KV cache 的 benchmark,確實會讓人停下來多看兩眼。FlashMemory-DS-V4 報的是平均 ~13.5% physical KV footprint,以及 500K context 下最高 90% 記憶體下降,品質幾乎沒掉。在一顆 128GB 的 GB10 上,context 能撐多長,最後會卡在 KV cache 預算,這個數字值得追一下。

這是 DeepSeek-V4-Flash on DGX Spark 系列 Part 7。Part 1 讓這顆 284B 跑上單機;Part 2 把它接成每天的 agent。Part 6 拆了 V4-Flash 的架構,包括它內建的 lightning indexer——模型內建的 sparse-attention 機制,在這個 ds4 build 裡每一步只從整段 context 裡抽大約 top-512 個最相關的 KV chunk 來算,而不是全看。如果「lightning indexer」對你還是個陌生詞,先讀那篇,因為這整篇的關鍵全押在它身上。

真正該換的是問法。FlashMemory 是外掛式的 sparse-KV 壓縮器:一個小小的 Neural Memory Indexer(paper 叫它 Lookahead Sparse Attention),每 τ=64 個 decode step 預測一次模型接下來會 attend 到哪些壓縮過的 chunk,把關鍵 chunk fetch 回 GPU、其他留在 cold pool。paper 自己也寫得很清楚:FlashMemory 先 fetch 一個 subset,接著 native Lightning Indexer 還會在這個受限集合裡打分。所以 FlashMemory 對 V4 不是多加一套獨立 selector,而是先限制 native 能看到的候選集合。那個門檻就不是「比 dense 省」了,是「在省記憶體的同時,保住 native 或 golden attention 本來會選到的 chunk」——而 native 是跟模型一起訓練出來的,這道門檻高很多。

後面其實都在量同一件事:一個外掛 retriever,到底能不能先縮小候選範圍,又不丟掉模型自己的權重本來就知道怎麼用的 chunk。

在看數據之前還有一句得先講:FlashMemory 公開 repo 是研究 / demo 版,不是完整 production serving stack。Paper 是真的,repo 也有 retriever + demo(~510MB 權重,MIT),但 README 明講 production 版依賴內部 sglang + DeepSeek-V4 CSA 底層架構,不能釋出;GitHub 也沒有打包好的 release。paper 只報記憶體省了多少,完全沒有速度數字,而且它自己的 dense-recall benchmark 崩掉(MRCR 48% 對 76%)。所以我一開始就是抱著懷疑進去的。但那個記憶體數字夠大,「懷疑」不等於「不試」——你得量。

Act 1 — 直接拿來用,FlashMemory 挑的 chunk 跟亂猜分不出來

第一個測試最便宜:把 FM 的 retriever 原封不動拿來,餵我這顆 ds4 Q2-abliterated 的 indexer key,問它想留哪 512 個 chunk。再拿這組去比 V4 native indexer 在同一份輸入上實際挑的——模型自己的 top-512。如果 FM 有點用,它挑的該跟 native 挑的重疊得比亂猜多很多。

結果沒有。

層	FM 對 native overlap	亂猜 baseline
L10	56.6%	57.6%
L12	58.4%	57.6%
L20	66.4%	57.6%

L10、L12 低於或等於亂猜 baseline。L20 高過 8.8 個百分點,而那已經是最好的一層。這不是「FM 比 native 差一點」,是「看 FM 挑的東西,幾乎看不出模型真正 attend 到什麼」。

比較細的地方:FM 的分數不是壞掉的。它的分數是散開的——這個 retriever 有 discriminative power,它很有信心地在排序 chunk。它只是照錯的 relevance 在排。有信心,又是錯的。root cause 不難猜:FM 的 retriever 是在原始、沒量化的 V4 上訓練的,我卻拿它跑在 Q2-abliterated 的 build 上。它學會讀的那些 indexer key,在我手上整個位移了。這是教科書等級的 distribution shift,而它產生的指紋就長這樣——信心值高、接近亂猜的選取。

所以 Act 1 的結論不是「FlashMemory 爛」。是「FlashMemory 原封不動拿來,在我的模型上根本沒法評估,因為它在讀一個它從沒見過的分布的 key」。這就帶出下一個很自然的問題。

Act 2 — 重訓到我的 Q2 build 很便宜,而且有效

如果問題是 distribution shift,那解法就是把我的分布給 FM 看。問題是這要多貴。如果得在 cluster 上整個重訓,那 FlashMemory 對單機設定來說一開始就死了。如果只要在我手上這台跑 ~160 個樣本,那就是另一回事。

結果只要 ~160 個樣本。

我只 fine-tune 了 FM 那幾個小 projection 權重——wq_a、wq_b、weights_proj——用 BCE loss 去對齊 native 的 keep/drop 決定。不是整個 retriever,只是把 indexer key 映射進 FM scoring 空間的那幾層 projection。

層	重訓前(as-is)	重訓後
L10	0.566(≈ 亂猜)	0.91
L12	0.584	0.94
L20	0.664	0.94

train overlap 到 0.98,val 0.91–0.94——差距很小,代表它在 generalize,不是把 160 個樣本背起來。這裡可以先確定兩件事。第一,Act 1 那個接近亂猜的結果主因是 distribution shift:FM 沒有任何架構上的理由對不上 native,因為它一看到 Q2 的 key,幾百個樣本就對到 0.91–0.94。第二,這也是陷阱所在:到這一步,FlashMemory 表面上是成功的。 它從亂猜爬到跟模型自己的 indexer 有 94% 一致。如果我停在這裡,我會寫出一篇結論完全相反的文章。

但「跟 native 有 94% 一致」不是目標。跟 native 一致,只代表「我會模仿 V4 的 indexer」。真正的問題是 FM 能不能做得比 native 好——而要問這個,我需要一個獨立於 native indexer 之外的標準答案。

Act 3 — 重訓到 golden,FM 還是輸給 native

要知道這個 pre-filter 安不安全,你得對著真正的答案打分,不能只對著 native 的答案。真正的答案是 dense attention:如果模型對所有 chunk 做沒遮罩的 softmax、完全不稀疏,它會 attend 到哪些。那才是兩個 selector 都在逼近的 ground truth。所以我把真實的 dense attention dump 出來當 golden,把每個人重新對它打分。

200 個樣本、validation、從 ~800 個 chunk 裡留 512、亂猜 baseline 0.67:

選取器	對 golden(L10)	L12	L20
Native indexer	0.930	0.957	0.956
FM,as-is	0.64	~0.67	0.69
FM,重訓到 golden	0.886	0.910	0.916

先看第一行。V4-Flash 內建的 lightning indexer,追真實 dense attention 追到 93–96%。看到這個數字,這案子差不多就結了。模型自己的 indexer、跟模型一起訓練出來的,已經幾乎貼在 ground truth 上。它上面沒剩多少空間。

FM as-is 對 golden 一樣 ≈ 亂猜(0.64–0.69),原因看起來還是同一個 distribution shift 問題。重訓到 golden,FM 從亂猜爬起來到 0.886 / 0.910 / 0.916——是真的進步,重訓確實有幫助。但它三層全部落在 native 底下。0.886 對 0.930。0.910 對 0.957。0.916 對 0.956。重訓後的 FM、直接對著 golden 目標訓練,還是搆不到 native 天生就有的水準。

結論就是 NO-GO:ds4/GB10 上不裝

FlashMemory 在這套 stack 上是 NO-GO,理由乾淨到一句話講完:V4-Flash 的 lightning indexer 是跟模型一起訓練的,已經追真實 attention 追到 93–96%,所以一個外掛 pre-filter——就算重訓到我的 Q2 build、對著 golden 目標——也保不住足夠多正確 chunk 來改善它。

這不是在酸 FlashMemory 這個技術,是在講這套 ds4/GB10 stack 的適用範圍。FlashMemory 是真的 ultra-long context prefetch/offload 設計,paper 裡的記憶體數字也很漂亮。但 V4-Flash 內部早就把稀疏選取這件事解掉了。在這裡裝 FlashMemory,等於拿一個 89–92% 的 retrained pre-filter 去限制一個 93–96% 的 native selector,還說這是升級。

唯一沒測到的 caveat:lookahead

誠實起見,這裡還是得打個星號說明。我的 golden 是 current-token 的 attention——模型當下這一步會 attend 到什麼。FM 原本想解的是 lookahead:它預測的是接下來 64 個 token 的 attention,不是當下這個。native 是逐 token 的。所以我測 FM 的時候,稍微把它拉離了它的主場。

FM 有沒有可能在 lookahead 的 golden 上把差距扳回來?理論上,有——那可能是唯一一個 native 沒有特別最佳化的地方。但我不看好,理由很具體:FM 在它確實被重訓過的 current-token 目標上,已經落後 native 4–5 個百分點。要純靠 lookahead 這個框架扳回 4–5 個百分點、還要反超一個 93–96% 的 native 選取器,這要求太高了。而且量一個 lookahead golden 貴很多——你得對每個樣本 dump 涵蓋 64 個 token 視野的 dense attention。看 current-token 的結果,我不覺得那筆計算成本會換來不一樣的結論。誰想證明我錯,那就是那個實驗。

我差點被 94% overlap 騙過去

最花時間的地方

不在重訓——重訓 ~160 個樣本、很快就跑完。花時間的是 Act 2 那個陷阱。FM 對到 native 94% 一致的時候,我是真的以為我拿到正面結果了,還差點就這樣寫出去。我差點省下那一小時,也差點錯過整篇重點:我後來拿那一小時去做 golden attention baseline,確認「跟 native 一致」和「比 native 更好」不是同一件事。結果不是,而那個差別就是整篇的發現。跟模型一致,不等於比模型更好。

值得帶走的診斷方法

在你把任何外掛式 sparse-KV 方案裝上一個模型之前,先跑一個量測:模型的 native 選取器對真實 dense attention 有多準。 把沒遮罩的 softmax dump 出來當 golden,拿內建 indexer 去對它打分。看到那個數字,你就知道上限在哪。如果 native 已經在 93–96%,那留給任何外掛方案的空間也只剩 4–7 個百分點,而且它得完美才填得滿——你不該期待一個帶著 distribution shift 的 retriever 會剛好完美。如果 native 只在 70%,故事可能就不一樣了。不 dump golden,你根本不知道自己在哪個世界,而 golden 很便宜。評估任何外掛之前,先做這件事。

通用原則

在你想替模型解一個問題之前,先量它自己解得多好。 FlashMemory 是個好技術、瞄準一個真問題——只是用錯了模型。V4-Flash 本來就有一套 native、跟模型一起訓練、接近最優的稀疏選取器,所以外掛一個等於在解一個已經被解掉的問題,而且解得更差。失敗不在 FlashMemory 的設計,也不在重訓。是我一開始以為這題還沒被 V4 自己解掉。

結論 checklist

1. 先確認有沒有 native indexer。 如果你的模型本來就在做 sparse KV 選取(V4-Flash 的 lightning indexer 就是),外掛壓縮器就得在省記憶體的同時保住 native/golden 本來會選到的 chunk。這比「幫 dense baseline 加稀疏」難很多。
2. 把 dense attention dump 出來當 golden。 沒遮罩的 dense attention 就是 ground truth。拿 native 選取器去對它打分——V4-Flash 是 93–96%,幾乎到上限。
3. 別把「對得上 native」當成「比 native 更好」。 重訓後的 FM 對到 native 94% 一致,對 golden 還是比 native 差(89–92% 對 93–96%)。一致不等於進步。
4. distribution shift 看起來像天生不行,但不是。 as-is 的 FM 在我的 Q2 build 上 ≈ 亂猜,純粹是因為它在沒量化的 V4 上訓練;只用 ~160 個樣本就修掉 shift。你若在一個 retriever 沒見過的量化上評估它,先重訓 projection 再下判斷。
5. ds4/GB10 上 NO-GO。 FlashMemory 可以省記憶體,但在這套 stack 上,它限制的是一個本來就更強的 native selector。唯一還沒排除的變數是 lookahead golden,而要從這點扳回 4–5 個百分點,機會不大。

---

本系列其他篇:Part 1 — 在 128GB 小盒子上跑 284B,然後錯怪了 2-bit · Part 2 — 把 15 tok/s 的 284B 當每天的 agent 大腦 · Part 6 — 拆 V4-Flash 的架構跟它的 lightning indexer