[本地 LLM] 怎麼判斷一個被吹爆的 LLM 優化,搬到你機器上是不是真的:讀原始碼、找天花板、跑一個實驗

白話版:別跟宣傳語吵架,讀規格、量天花板、切一塊試片

每隔幾天,本地 LLM 的圈子就冒出一個「新神器」:某個能幫你省一大半記憶體的外掛、某個號稱快好幾倍的花招。這篇要講的不是哪個神器好,而是你怎麼「不花一個禮拜」就判斷出:這東西搬到你自己的機器上,到底是真有用,還是只是別人家的漂亮數字。

我把它想成一個裝潢師傅在聽人推銷「神級隔熱棉」。你不會照著 DM 上的數字就信,也不會憑感覺就把整面牆拆了。你會做三件事:先看規格書、把它跟你牆裡本來那層最好的隔熱棉比、再切一小塊試片實測。三件事少做一件,不是被話術騙,就是把好東西誤殺。

這三件事搬到 LLM 優化上,就是:先讀原始碼跟原論文(別讀宣傳標題)、對「理論上最好的答案」量(別只跟現成的方法比)、卡在理論吵不出來時,設計一個「只會有一種結果」的實驗讓它當裁判。整篇就是把這三件事,用我上一篇那次 FlashMemory 的調查,一件一件做給你看。

---

前言

判斷一個優化值不值得裝,很像裝潢師傅在聽人推銷神級隔熱棉:你不跟 DM 上的數字吵,也不憑信仰就拆牆——你讀規格、拿它比牆裡本來最好的那層、再切一塊試片。三步少一步,不是買到話術,就是誤殺好東西。

這是 DeepSeek-V4-Flash on DGX Spark 系列的 Part 8,也是最後一篇——前面每一篇忙完之後的「所以呢」。Part 6 拆了架構;Part 7 是這篇背後的案例——把我差點裝上一個外掛 KV 壓縮器、結果發現它想解的問題模型早就解掉的那整段,一拍一拍講完。想看帶滿註解的數字,去讀 Part 7。這篇我只把方法抽出來,因為真正能搬到別的優化上的是方法,不是那組數字。

先講一句老實話:這不是什麼通則,是我在一台「實驗很便宜、整套 stack 都我自己的」單盒設定上,實際跑得通的做法。如果你沒法 dump 模型內部的 activation、也沒法在手上這台重訓一層 projection,體感會不一樣。但「原始碼 → 天花板 → 實驗」這個順序,不管規模大小都成立。

---

動作一 — 讀 code 跟 paper:還沒跑任何東西,問題就已經變了

標題是「500K context 省 90% KV」。人的直覺是直接跳到「這在我機器上跑不跑得起來?」——這個問題問早了,而讀兩份一手資料,把它整個重新框過。

先讀 code,ds4 自己的。FlashMemory 是外掛式的 sparse-KV 壓縮器:它預測哪些 KV chunk 重要、其餘丟掉。但一讀 ds4 的實作就發現,V4-Flash 本來就有一套 native lightning indexer,每一步都在做 top-512 稀疏選取(這是 Part 6 的內容)。這一個事實就把問題翻了面。FlashMemory 對 V4 不是「加稀疏」——它是要取代模型本來就在做的選取。門檻就不是「比 dense attention 省」,是「比 native 更好」。高很多,而且我還沒跑任何東西就知道了。

再讀 paper,FlashMemory 自己的。那個標題數字是真的,但很窄。paper 的結果表只報記憶體佔用跟準確度:paper 裡沒有速度數字。 它自己的 dense-recall benchmark 崩掉(MRCR 48% 對 76%)。而且這是個沒人養的孤兒專案——主導者走了、停擺。這些在「省 90%」的貼文裡一個字都不會出現;而全部,都只差你去讀一次那份 arXiv PDF。

所以在花掉任何一秒 GPU 之前,問題已經從「我要不要撿這個白撿的記憶體便宜?」變成「一個外掛的、沒人養的、paper 只證明過記憶體佔用跟 recall 的 retriever,比不比得過模型本來就在跑、又跟模型一起訓練出來的選取器?」這是一個完全不同、而且懷疑很多的問題——而讀資料讓我免費走到這裡。標題告訴你這東西號稱什麼。code 跟 paper 告訴你它實際上做了什麼,同樣重要的是,它沒做什麼。

動作二 — 對真正的天花板量,別對順手的替身量

一旦你跑了什麼,「有用/沒用」在你不知道「好」長什麼樣之前是沒意義的。這一步,FlashMemory 這次調查差點翻車。

最直覺的比法:FlashMemory 挑的 chunk,跟 native indexer 挑的一不一樣?直接拿來用,它跟 native 的 overlap 三層分別是 56.6% / 58.4% / 66.4%,對比亂猜 baseline 57.6%——基本上就是亂猜。看起來死透了。但 native 是個替身。拿 FM 跟 native 比,只告訴你 FM 像不像 native,不告訴你兩個到底哪個好。如果 native 本身就很普通,「FM 跟 native 不合」根本不算什麼結論。

真正的天花板是 dense attention——如果模型對每個 chunk 做沒遮罩的 softmax、完全不稀疏,它會 attend 到哪些。那才是兩個選取器都在逼近的 ground truth。所以我把真實的 dense attention dump 出來當 golden,把每個人重新對它打分。native 追 golden 追到 0.93–0.96——接近最優。而我能生出來的最強版本 FM,也只到 0.90。對替身比,FM 看起來就是壞掉;對天花板比,真正的樣子才浮出來:native 幾乎完美,所以留給任何外掛方案的縫只有 4–7 個百分點,而且它得完美才填得滿。

這個道理你一看就懂,但當下很容易漏掉:挑那個能回答你真正問題的基準。問題從來不是「FM 對不對得上 native」,是「FM 有沒有比我本來在跑的更好」。只有對真正的天花板比,才回答得了這件事,而天花板很便宜就 dump 得出來。

動作三 — 一個能定生死的實驗,勝過再多理論

讀完資料到最後下結論之間,有一段很誘人的理論岔路。直接拿來用,FM 在我這顆 Q2 上挑得接近亂猜。為什麼?兩個故事都套得上同一組資料。也許是架構天生學不會我這顆量化——一個真的、致命的極限。也許只是它在錯的分布(沒量化的 V4)上訓練,我的 Q2 key 在它底下位移了——很煩,但可修。這兩個你在扶手椅上可以吵到天荒地老;as-is 那個數字,對兩邊一樣說得通。

所以別吵——去做那個「哪個故事是真的,答案就不一樣」的量測。如果是 distribution shift,用我手上的資料分布去重訓 FM,應該就能修好;如果是架構極限,給了也沒用。我只 fine-tune 了 FM 那幾層小 projection,用 ~160 個 Q2 樣本。val overlap 從 ~0.67 跳到 0.91–0.94。這就實測定案了:純粹是 distribution shift、可修、不是天生做不到。再多對「架構」的空談都走不到這一步;~160 個樣本一個下午就到了。

而 golden 那把比較,是整件事最後的裁判。理論永遠留一個逃生口——「重訓過的 FM 應該會 generalize」「它在 lookahead 目標上會更好」。也許吧。但重訓後的 FM、直接對著 golden 目標訓練,三層還是 0.886 / 0.910 / 0.916——全部落在 native 的 0.930 / 0.957 / 0.956 之下。再怎麼講「應該會怎樣」,都撐不過 0.90 < 0.93–0.96 這個數字。設計一個結果沒得吵的實驗,讓它當裁判。

FlashMemory 在這套 stack 上的結論是 NO-GO——不是因為技術爛,是因為 V4-Flash 本來就內建一套接近最優的 native 選取器,外掛方案能補的縫太小。但那個結論是 Part 7 的故事。這篇講的是這三個動作怎麼帶我走到那裡、又沒浪費掉一個禮拜——而這三個,就是我對這系列每個優化宣傳都在跑的同一套。

收穫

最花時間的地方

不在讀資料,也不在重訓——重訓 ~160 個樣本,一個下午就跑完。花時間(也差點翻車)的是動作二。重訓對到 native 94% 一致之後,我手上有個表面上正面的結果,還差點就這樣寫出去。我以為「省下來」的那一小時,其實正是我拿去 dump golden、去查「對得上 native」跟「比 native 更好」是不是同一個問題的那一小時。結果不是,而這兩者之間的縫,就是整篇的發現。挑錯基準,賠的不是一個錯數字——是一個錯結論,那更糟。

可搬走的診斷方法

三個,照跑的順序。動手之前:讀目標自己的 code,看這問題是不是內部早就處理掉了——一個 native 機制會把「加 X」變成「比 X 更好」,把下游每一道門檻都抬高。信任任何「有用」結果之前:dump 真正的天花板、對它打分,不要對現成的方法——現成的是個替身,可能誤捧也可能誤殺。理論分岔時:設計那個「不同分支給不同結果」的便宜探針——那次重訓探針(0.67 → 0.92)一跑就把「學不會」跟「錯分布」分開,這是再多嘴砲都辦不到的。

通用原則

讀原始碼、找真正的天花板、跑一個能定生死的實驗——照這個順序,因為每一階都在幫下一階縮小要測的範圍。 把問題重新框好,你才會去量對的東西;有了天花板,你才知道「做到更好」到底是什麼;最後那個實驗,負責把剩下的理論分歧收掉。這就是為什麼多數被吹爆的「快 N 倍 / 省 90% 記憶體」最後沒改變我實際在跑的東西:它們通常對某顆模型是真的,而這三個動作很便宜地告訴我,那顆模型是不是我這顆。

結論 checklist

1. 跑任何東西之前,先讀一手資料。 真正的 code 跟真正的 paper,不是標題。讀 ds4 的 code 把「加稀疏」變成「比 native indexer 更好」;讀 FlashMemory 的 paper 撈出「paper 只報記憶體佔用跟準確度、沒有速度數字」跟 dense-recall 崩掉。你該測的問題,通常不是標題丟給你的那個。
2. 找真正的天花板,對它量。 不是現成的方法——是 ground truth。native 對 golden 是 0.93–0.96,就這一個數字讓結論變得乾脆。替身比較(FM 對 native ~0.60)講的是另一個、錯的故事。
3. 理論分岔時,跑那個能把分支分開的實驗。 「學不會」跟「錯分布」在 as-is 資料裡長得一模一樣;一次 ~160 樣本的重訓(0.67 → 0.92)就實測把它們分開。設計那個「你對的話只會有一種結果」的量測。
4. 別把「對得上現成的」當成「逼近真實上限」。 重訓後的 FM 對到 native 94% 一致,對 golden 還是比 native 差。一致不等於進步。
5. 多數被吹爆的宣傳都是真的,但很窄。 「省 90% KV」是真的——對一顆沒有 native indexer 的模型。這三個動作,就是讓你很便宜地查出:那個窄窄的情況,是不是你這顆。

---

本系列其他篇:Part 5 — Depth-1 MTP:speculative decode 照 workload 分流 · Part 6 — 拆 V4-Flash 的架構跟它的 lightning indexer · Part 7 — FlashMemory 比不過 V4-Flash 內建的閃電索引器 · 上游:antirez/ds4