[洋垃圾跑大模型 #3] 一張 22G 老卡跑 284B:DeepSeek-V4-Flash 比 DGX Spark 快 18%

白話版：284B 的模型塞進一張老顯卡，靠的是「大部分專家都在睡」

先講規模感。這顆模型叫 DeepSeek-V4-Flash，兩千八百多億個參數，光是壓縮過的檔案就 86GB。而我拿來跑它的，是一張 2018 年出的遊戲顯卡，二手改裝過、記憶體加大到 22GB，一張大概一萬一千塊台幣。

聽起來很不合理，關鍵在這種模型的設計方式。它不是一顆什麼都要自己算的大腦，比較像一間分成 43 層的公司，每一層都養了 256 個專家。但每處理一個字，公司只點名 6 個專家出來開會，其他兩百五十個繼續睡。

既然大多數專家隨時都在睡，就沒必要讓它們全擠在昂貴的顯卡裡。我把睡著的那些丟去便宜的一般記憶體（這台機器有 128GB），要用時再叫 CPU 算，只把每個字都一定會用到的那部分留在顯卡上。這一招不是我發明的，這個系列前兩篇都靠它。

有趣的是最後的結果。我原本以為要三張顯卡才跑得動，實測下來，一張跟三張的速度只差 4.3%。多插的卡買到的是空間，不是速度。更意外的是拿它去比那台 2025 年出的 AI 專用小型工作站（NVIDIA DGX Spark），同一顆模型、同一段輸入，老卡每秒吐 17.4 個字，專用機 14.7 個。

當然，兩邊跑的軟體不一樣，這不是嚴格的公平對決。但對想在家裡養一顆大模型的人來說，結論夠實用了：你可能不需要買新機器。

這篇會講我怎麼一路測到這個配置，包括我判斷錯的那兩次——第一次差點讓我第一天就收攤。

---

前言

事情的起頭不是「這顆模型塞不塞得進去」。它早就在跑了，跑在 GX10（NVIDIA DGX Spark）上，一台 2025 年的 AI 小型工作站，天天在服務我自己的 agent。

問題是那台我想拿去做訓練。要把它挪出來，得先有東西接手；家裡剩下的就是 ai-lab 那台洋垃圾——EPYC 7402 配三張改裝 2080 Ti。所以這篇要回答的其實是一個很世俗的問題：洋垃圾接得住嗎？至少一樣快嗎？ 慢一點都不划算，因為推論慢下來的痛，每天都在還。

Part 1 用三張卡跑 119B，Part 2 用一張卡跑 118B。這次的數字大了一個級距：284B。

---

目標不是「載得進去」，是能不能讓 DGX Spark 退休

先把主角跟場地報清楚。

模型：DeepSeek-V4-Flash，284,334,567,511 個參數的 MoE（混合專家：一顆模型內部養很多個小專家，每次只叫醒一小撮出來算）。43 個 block、每個 block 有 256 個 routed expert，每個 token 只點名其中 6 個。我拿的是 Huihui 那顆 abliterated Q2 GGUF：86,720,111,200 bytes、IQ2_XXS（這個量化型別本身是 2.0625 bpw，不過整份混合量化的檔案平均下來大約 2.44 bits/參數），architecture 標的是 deepseek4。

機器：EPYC 7402（24 核 48 緒）、三張改裝 RTX 2080 Ti 22G（compute capability 7.5，Turing，2018 年的卡）、128GB 八通道 DDR4。build 是 llama.cpp main 的 0e4a0362239713ea95a6864a17a8de4b0ad90d62，CUDA 12.4，CMAKE_CUDA_ARCHITECTURES=75。

這裡先埋一件事，後面會回來收：這台上原本那份舊 build，根本沒有 DeepSeek-V4 的實作。它不是「Turing 太老跑不動」，是「這份程式碼裡沒有這顆模型」。這兩種失敗長得很像，但一個是硬體判死刑，一個只是你該去更新。分不清楚，就會把一堵紙牆當成水泥牆。

---

第一個數字是錯的：三張卡比兩張慢 1.8%，而每張 22 GiB 的卡只用了 5 GiB

第一輪我跑得很直覺：-ncmoe 43，把 43 個 block 的專家全部丟給 CPU 算，顯卡只留下每個 token 都要用到的部分。

結果難看。兩張卡 14.22 tok/s、三張卡 13.96——多插一張卡，吐字慢了 1.8%。三張老卡跑 284B，換來這個數字，我當下的念頭是這條路大概到此為止。

差點就收攤了。收攤前我順手看了一眼資源監控，然後愣住：peak VRAM 只有 5.0 / 4.4 GiB。

每張卡有 22 GiB。

也就是說，我剛才量到的不是這台機器的天花板，是一間空房間的天花板。-ncmoe 43 剛好等於 block 總數，看起來像「開到最大」，實際上是「把專家全部趕出顯卡」——那個 43 不是上限，是把顯卡關掉的開關。我拿一個自己親手關掉顯卡的測試結果，去判三張卡的死刑。

---

把記憶體填滿：decode 從 13.9 爬到 18.6 tok/s

既然有一大半的空間閒著，就往回收。-ncmoe 調小一格，就多留一個 block 的專家在顯卡上。

下面這張表看最右邊那欄就好——同樣三張卡，只改一個參數，速度一路往上爬（tg256 中位數，每個點跑 3 次）：

-ncmoe	專家丟給 CPU 的 block 數	tg256 中位數 tok/s
43	全部	13.9125
30	30	16.4087
20	20	17.4036
13	13	18.6241

-ncmoe 13 那格吃掉 61,264 MiB，是 llama.cpp 回報可用量 66,000 MiB 的 92.8%，真的塞滿了。比全丟 CPU 的基線快 33.9%。

同一台機器、同一份 build，差別只在顯卡記憶體有沒有被用到，就差了三成。

---

最反直覺的一格：單卡 17.85 tok/s，是三卡塞滿的 96%

爬完三卡的曲線，我順手補了一個對照組：只用一張卡。-ncmoe 38，也就是只有 5 個 block 的專家待在顯卡上、38 個在 CPU。

17.85 ± 0.21 tok/s。

一張卡是兩張卡的 98%、是三張卡塞好塞滿的 96%。

量之前，我的直覺是一張卡大概也有 20 上下；跟我一起跑這輪 benchmark 的 AI 助手賭 14 到 16。結果 17.85，它的區間根本沒包到。

這個對照有個地方不對等：單卡那個 17.85 是 tg128 量的，前面多卡那幾個數字（18.26、18.62）是 tg256。不是同一把尺。KV cache 養肥之後 decode 會微幅往下掉，所以單卡等於拿到一份比較簡單的考卷，佔了一點便宜。換成同一把尺，單卡跟三卡的差距會比 4.3% 再大一點。

方向倒是沒被推翻。今天同一組單卡配置就掛著跑服務，server 自己回報連續兩次 128-token 的完成速度是 17.47 和 18.03 tok/s，benchmark 那個 17.85 剛好夾在中間。

直覺會中不是因為我比較懂，是這台機器上卡數本來就不是重點。

---

軟地板大約 18：離頻寬該給的還差 3.6 倍，卡住的是每個 token 走完一趟的 latency

一張卡跟三張卡差不多快，這件事需要一個解釋，不然它只是個巧合。

最強的證據其實是實測本身：單卡跟三卡只差 4.3%，而三卡那組可是多了 30 個 block 的專家坐在快的記憶體裡。不管卡住的是什麼，都不是「專家住在哪裡」。

算起來比我原本以為的有意思。這段我第一次算錯了。每個 token 大約會動用到 13B 參數，但不能拿整份檔案平均的 2.44 bits/參數去乘——這顆 GGUF 是非對稱量化的。Q2 的是那 277B 個 routed expert，而它們每次只出動 256 選 6；常駐會用到的那批（attention、shared expert、輸出層）大多是 Q8 或 F16。照張量目錄實際算、專家取 6/256：專家那部分每個 token 只要 1.83 GB，反而是常駐那批要 7.73 GB。合計 約 9.56 GB/token，換算下來 active 的有效精度是 5.76 bits/參數，比整檔平均高一倍有餘。

兩個天花板因此都要重算。八通道 DDR4-2133 的 136.5 GB/s，換算全跑 RAM 的天花板約 14.3 tok/s；2080 Ti 的 616 GB/s 換算全在 VRAM 約 64.4 tok/s。實測 17.85 高於純 RAM 那個數字（混合放置本來就該有這種效果），但離全 VRAM 還差 3.6 倍。

所以頻寬在這裡確實有在做事。它解釋不了的是那 4%。把那 30 個 block 搬上顯卡，是真的把資料從慢的那池挪到快的那池，照理該把 3.6 倍那道差距追回來一些。它沒有。

追不回來的那一段，就是我說的「軟地板」——每個 token 走完整條 pipeline 的固定成本，你怎麼搬記憶體都省不下來：排程、kernel launch、CPU 跟 GPU 之間的來回、專家挑選。它不是硬體物理極限（物理極限還遠得很），但在這個組合下你怎麼加硬體都踩不穿。認清楚這件事，後面所有的決定都變簡單了：不要再往上加卡，順著地板走。

---

多插一張卡要付 8.5% 的稅——所以我沒買第四張

「多一張卡到底是加分還是扣分」這個問題，在一般的參數 sweep 裡永遠問不出答案，因為多一張卡同時給你更多容量、也多一份協調成本，兩件事混在一起。要拆開，只能固定其他所有變因、只動卡數。

固定 -ncmoe 23：兩張卡 18.2618、三張卡 16.7048。多一張卡，慢 8.5%。

一般的 sweep 同時也把容量加大了，變快的好處會把多卡的成本蓋掉，所以你根本看不出來。

那買第四張呢？只看容量的線性回歸長這樣：speed = 20.4434 − 0.14898 × N（N 是丟給 CPU 的 block 數，R² = 0.9770；這條線是六個 sweep 點配出來的，上面那張表只列了其中四個），外推到 N=0（全部專家都在顯卡上，大約要四張卡的量）大概 20.4 tok/s。看起來像是「再買一張就破 20」。

但把實測的每卡稅套回去，四張卡會回落到 18.6 到 19.4 之間——比三張卡塞滿的 18.62 好不了多少，而且要多買一張卡、多一個 PCIe 插槽、多一份電。

所以我沒買第四張。這是這整篇裡最值錢的一個負結果：用一次對照實驗，擋掉一筆沒必要的花費。

---

兩個坑：總量夠不等於單卡塞得下，載得進不等於跑得動

往上爬曲線的路上踩了兩個坑，都不是「參數調錯」那種等級的坑。

坑一：預設的分層方式會把專家全堆到最後一張卡。 會留在顯卡上的專家，位置都在模型後半段；而 llama.cpp 預設是照 block 數平均分給每張卡。兩件事湊在一起，結果就是 -ncmoe 30 時要求 CUDA2 一次 allocate 25,091.43 MiB，然後 OOM，儘管三張卡的總量綽綽有餘。所以每個小於 43 的測試點，我都得明示 -sm layer -ts 手動指定切法（tensor split：自己決定每張卡各扛幾層）。總量夠，不等於單卡塞得下。

坑二：載得進去，不等於跑得動。 -ncmoe 13 用 22/10/11 的切法載入得乾乾淨淨，一行錯誤都沒有。然後第一個輸入進去，GPU0 在 21,984 / 22,000 MiB 的位置 CUDA abort。改成 21/10/12 就過了，總量一樣是 61,264 MiB。

差別在 warmup 跟處理輸入時要建的計算圖需要額外的工作空間，而 loader 沒把這塊算進去。所以容量掃描一定要真的生一次 token，不能看到「載入成功」就打勾。

---

想再快只剩投機解碼，結果連草稿模型都載不進去

軟地板既然踩不穿，剩下的路只有一條：投機解碼（speculative decoding：讓一顆小模型先猜好幾個 token，大模型一次驗完，猜得準就一步收下好幾個字）。這招不需要更快的硬體，它是繞過 per-token latency 的唯一解——正好對症。

而 DeepSeek-V4-Flash 本身就附了 MTP（multi-token prediction，模型內建的一組「多預測幾個字」的權重），不用另外養一顆草稿模型，簡直是天上掉下來的。

結果卡在門口：

error loading model: unknown model architecture: 'deepseek4_mtp_support'
failed to load draft model

那顆 MTP 檔的 general.architecture 寫的是 deepseek4_mtp_support，llama.cpp 不認得。有趣的是主模型自己載得好好的（44/44 層、CUDA0 20,627.70 MiB、CUDA1 21,315.96 MiB），被拒的只有草稿。

---

我判它死路，判了兩次都錯：一次沒讀說明書，一次把「不同架構」當成「不同名字」

看到「unknown model architecture」，我第一時間判死刑：這條路不通。

第一次判錯，是因為我沒照 model card 說的用專屬的 fork。人家寫明要用 Fringe210/llama.cpp-deepseek-v4-flash-cuda，我沒編。補編了才發現兩件事：一是 sm_75 編得過，這條 fork 沒有把 Turing 排除在外，「老卡不支援」是我腦補的；二是它載入時會 hang，真正的原因是 mmap，加 --no-mmap 就過。

但編出來的 fork，一樣拒絕 deepseek4_mtp_support。

第二次判錯，是我以為這只是「同一個東西換了個名字」，改個 architecture 字串就能騙過去。去比對張量命名，確實不一樣：

• mainline 那套要的是 blk.N.nextn.*（eh_proj、embed_tokens、shared_head）
• antirez 那套用的是 mtp.0.*（attn_q、attn_kv、attn_sinks）

然後我矯枉過正。我當時把它們寫成「兩種互不相容的架構」，這也是錯的。兩邊其實都是先做一次投影、再走一整塊 attention、再走 MoE，差的是命名、張量排法，以及投影怎麼打包（mainline 把兩個輸入接起來用一個矩陣算，antirez 那側分開算，代數上是同一件事）。所以要轉過去得寫一個真的轉換器，改名不夠。但那是包裝方式的差別，兩邊骨架一樣。

---

不用下載 86GB 也能驗格式：HTTP range 讀 GGUF 檔頭

知道要找「mainline 格式」的 MTP 檔之後，問題變成：怎麼確認某個 repo 裡的檔案是哪一種？總不能為了看幾個張量名字，把 86GB 下載下來。

不用。GGUF 的 metadata（包含所有張量的名字）都在檔案開頭，所以用 HTTP range request 只抓前面幾 MB 就讀得到。這台上連 numpy 都沒裝，我就手寫了一個純 Python 的 parser 去讀檔頭。

抓一輪就找到了：ddh0/DeepSeek-V4-Flash-GGUF 有一份獨立的 MTP 檔，張量是 blk.43.nextn.*、architecture 是 deepseek4、nextn_predict_layers 等於 1，正是 mainline 那套。

所以「用 mainline 那套命名」的檔案確實存在。結果這件事沒有我以為的那麼關鍵。

---

真正的關卡:llama.cpp 根本還沒實作 DeepSeek4 的 MTP

拿到命名對的檔案，我去翻 llama.cpp 的原始碼，想確認接下來會發生什麼事。

src/models/deepseek4.cpp 從頭到尾沒讀 nextn_predict_layers、沒載 nextn 張量，也沒有建任何 MTP 計算圖。這段程式根本沒寫。真的支援多 token 預測的那些架構，會去讀那個 hyperparameter、另外建一張草稿用的圖，deepseek4 兩件事都沒做。我去翻那條 fork 的同一個位置，那裡掛著一個 TODO。

順帶一提，ddh0 那個檔其實也載不進去。這件事我是讀 loader 讀出來的，不是跑出來的：mainline 要的是完整 44 層的模型，缺第一個張量就直接 throw，而一個只有 blk.43 的獨立檔案，blk.0 到 blk.42 全都沒有。另外，MTP context 在層數為零時會自己跳警告然後回傳 null。

我讀了原始碼，沒有真的去跑那個檔。讀完之後跑它已經沒有意義了——但「命名是對的」跟「它會動」是兩個不同的主張，我只能確認前者。

所以這一路撞的四層牆，誠實的排序是這樣：

1. 不是硬體牆——sm_75 編得過，Turing 沒被排除
2. 不是 build 牆——專屬 fork 編得出來，hang 是 mmap 造成的
3. 不是命名牆——用 mainline nextn 命名的 MTP 檔真的存在
4. 是 runtime 牆——llama.cpp 根本還沒實作 DeepSeek4 的 MTP

前三層我都動得了手，第四層動不了。而我在摸到第四層之前，已經先對前面幾層各判了一次死刑。

那換另一套引擎呢？antirez/ds4（DwarfStar）真的支援 MTP，那正是 GX10 上跑的那套。但這裡要先講清楚一件我上一篇差點寫錯、被出稿前的事實查核擋下來的事：它是 antirez 個人的 MIT 專案，不是 DeepSeek 官方引擎。它有自己的模型格式，不是 llama.cpp 的變體。而且它 README 裡列出的最舊實測硬體級距是 Ada Lovelace，還把那個級距形容成「old-ish」，而 Turing 比 Ada 再老四年。把它移植到這台上是另一個專案，不是改個設定檔。

---

最後跑在家裡的配置：262K context 只吃 16GB VRAM

不硬拚了，順著軟地板走。跑到現在天天在用的就是這一份，單卡：

llama-server \
  -m Huihui-DeepSeek-V4-Flash-BF16-abliterated-ds4-Q2.gguf \
  -ngl 99 -ncmoe 39 -c 262144 \
  -fa on -ctk q4_0 -ctv q4_0 \
  -t 32 -tb 32 -b 2048 -ub 512 \
  --host 0.0.0.0 --port 8093

最值得講的一格是 -c 262144：262,144 個 token 的 context，只吃 16GB VRAM，外加大約 67GB 系統記憶體。

context 幾乎免費，是因為這顆模型的注意力設計：只有 1 個 KV head、MLA 式的壓縮、128 token 的 sliding window，而且 compress_ratios 在 4 到 128 之間交替。照 llama.cpp 的 DeepSeek4 cache 配置、搭配 -ctk q4_0 算下來，KV cache（模型記住前文用的那塊記憶體）在 262K 的長度大約 480 MiB——是幾百 MB 的量級，不是好幾個 GB。這顆模型號稱原生支援 1M context，我停在 262K，夠用而且穩。

要提醒的是這組設定能調的範圍很窄：-ncmoe 40 塞得下，-ncmoe 35 就 OOM。想自己調的話，每動一格都要照前面說的真的生一次 token。

---

同一支 script 兩台對跑：17.41 對 14.75

回到最開始那個問題：洋垃圾接不接得住？

這次我沒有憑記憶。同一支 script、同一段輸入、128 個 token、temperature 0、各跑三次，兩台機器的測試前後只隔一分鐘。下表看最右邊那欄，是熱機後的 end-to-end 速度：

機器	引擎	熱機後 end-to-end tok/s
ai-lab 單張 2080 Ti 22G	llama.cpp -ncmoe 39	17.41 / 17.36
GX10 DGX Spark（GB10）	antirez ds4	14.75 / 14.69

一張大約 NT$11,000 的二手改裝卡（原本 11G、改成 22G），跑 284B 比 2025 年的 AI 專用機快約 18%。

先講清楚這個比較能說明到哪裡：兩邊的引擎跟量化都不一樣（llama.cpp 配 abliterated IQ2_XXS，對上 antirez ds4 的自有格式），所以這是兩套「實際部署狀態」的對照，不是控制變因的硬體 A/B。而且只測了一種 workload：短輸入、128 個 token、單一連線。長輸入、多人同時打，結論可能就不一樣了。

以這次的測試條件來說，答案很明確：接得住，而且 DGX Spark 可以去做訓練了。

---

收穫

最花時間的地方

不是編譯，也不是模型本身。最花時間的是兩組看起來都乾淨可信，卻會讓人得出相反結論的數字。

一個是顯卡記憶體大半空著時跑出來的 benchmark，我看了結果就以為「三張卡跑不動」。

另一個更慘。「Spark 有 20 tok/s」這個對照基線躺在我自己的實驗筆記裡，跟我一起跑這輪的 AI 助手就一輪一輪拿它去下結論，而我一直沒攔。那個數字曾經是真的——只是 Spark 七月就把引擎換掉了，它是舊引擎留下的幽靈。

更好笑的是，我手上明明就有一個 fleet 儀表板，點開就看得到每台機器此刻真正在跑什麼。兩邊都沒去點。最後是我叫它別再憑記憶、直接去量，才量出 14.75。

真正的 debug——MTP 的格式考古、tensor split 的 OOM——反而快，因為那些失敗至少會自己喊出來。不會跳錯誤的那種 bug 才是最貴的。

可搬走的診斷方法

• 信 benchmark 的結論之前，先看資源監控。 22 GiB 的卡只用了 5 GiB，那是空房間，不是天花板。
• 多卡 scaling 比預期差的時候，跑一次「其他全固定、只動一個變因」的 A/B。 第三張卡那 8.5% 的稅，在 sweep 裡隱形，在對照組裡刺眼。
• 驗格式不用下載整顆模型。 GGUF 的 metadata 在檔頭，HTTP range 抓前面幾 MB 就讀得到張量名字。
• 某個功能「不支援」時，要問是哪一層在說不。 architecture 表、loader、還是計算圖——那是三種不同的問題，而只有其中一種輪得到你修。

通用原則

會拿來做決定的數字，在你用它之前重新量一次。

這趟兩個差點翻車的地方，說穿了都是同一個問題：相信了過期的數字。數字當時沒有錯，錯的是它對應的那個配置早就不存在了。空房間 benchmark 是這樣，幽靈 20 tok/s 也是這樣。

---

六條給要在老卡上跑大 MoE 的人

1. 別讓 -ncmoe 停在 block 總數卻把結果當硬體極限——先看 peak VRAM，那個數字會告訴你是不是自己把顯卡關掉了。
2. 多卡 offload 一律明示 -sm layer -ts，別靠預設的平均分配。
3. 每個容量測試點都要真的生一次 token，「載入成功」不算過。
4. 買卡之前，先在固定的 CPU/GPU 比例下測「卡數」這一個變因，看清楚多卡稅。
5. ds4 的 MTP 卡在 llama.cpp 根本還沒實作 deepseek4 的 nextn——不是你的 GPU 不行，也不是你沒找到對的 GGUF。
6. 要拿來做決定的基準線，當天重新量一次。

有同一台洋垃圾、想少踩幾個坑的，可以訂閱我的電子報。有新東西我才寄，不寄廣告。

---

這個系列：Part 1｜Part 2