[洋垃圾跑大模型 #4] 把前沿級開源模型搬進自己家:一張 22G 老卡跑 DeepSeek-V4-Flash-0731

前言

倉庫管理員不會把整間倉庫的貨都堆在出貨口。每天都要出的擺在門邊，一年動一次的推到最裡面，要用再進去拿——差別只在多走幾步路。

這個系列前三篇都在做同一件事，只是搬的是模型權重。#3 已經證明一張老卡跑得動 284B，那篇在回答「跑不跑得動、多快」。

這篇要回答的是另一個問題:你手上那台機器，要怎麼把它跑起來，而且跑得好。 7 月 31 日 DeepSeek 放出 0731 正式版，我整台重裝了一次，順便把最關鍵的那個參數量成一條可以套用在任何顯卡上的算式。

0731 是什麼:官方正式版，而且它把 Jinja 樣板拿掉了

先講清楚你要下載的是什麼。

DeepSeek-V4-Flash-0731 是 DeepSeek 在 2026 年 7 月 31 日放出的正式版，官方 model card 說它取代先前的 preview 版本，agentic 能力有明顯加強。

架構沒有變。我把兩個版本的 config.json 都抓下來對過:43 層、256 個專家、每個 token 叫醒 6 個路由專家加 1 個共用專家、位置編碼上限 1,048,576——兩邊一模一樣。換掉的是權重，不是設計。所以你在 #3 學到的東西這裡全部還通用。

值得花一個晚上裝它的理由，在官方那張對照表裡。0731 的 model card 直接把自己跟 Opus-4.8 放在一起比:

評測	DeepSeek-V4-Flash-0731	Opus-4.8
Agents' Last Exam	25.2	25.7
Terminal Bench 2.1	82.7	85.0
AutomationBench Public	25.1	27.2
DSBench-Hard	59.6	71.7

前面三格咬得很住，最後那格明顯落後。官方自己的措辭是 "broadly competitive with the strongest proprietary models available"——同級，不是超越，我把落後的那格也放進表裡就是不想只挑好看的講。

但對這篇的目的來說夠了:你接下來要裝的不是玩具。 它跑在你自己那台機器上，沒有月費、沒有 API 帳單、關掉網路也還在。

對自己架服務的人來說，真正有感的差別在另一個地方:官方這次不附 Jinja 格式的 chat template，改成給一個 encoding 資料夾，裡面是 Python 腳本跟測試案例。

後果是你手上那份 GGUF 的對話樣板，是做量化的人自己補的。我把正在跑的那份樣板 dump 出來，第一行就寫著:

{#- Unsloth template fixes #}

所以在不同人的 GGUF 之間換來換去時，換掉的不只是量化精度，還有那份沒有官方版可以對照的樣板。這也是我這篇固定用 Unsloth 那份的原因:不是它一定最好，是我要有一份跑得穩、而且知道它從哪來的。

為什麼一張 22G 的卡放得下 91GB 的模型

這節是原理。搞懂了你就能自己算參數;不想看也可以直接跳到下面抄設定。

一般的模型(dense)每算一個 token，所有權重都要被讀過一遍。91GB 的權重就要讀 91GB，一張 22G 的卡放不下，也就跑不動。

這顆不是那樣。它是 MoE，每一層養了 256 個專家，但每個 token 只叫醒其中 6 個，加一個每次都要出場的共用專家。所以權重可以分成兩堆:

• 每個 token 都要用到的:注意力、共用專家、embedding、輸出層。這堆很小，但每個 token 都會讀。
• 很少被叫到的:256 個路由專家。這堆很大，佔掉 91GB 的絕大部分，但每個 token 只碰到其中 6 個。

熱的那堆放 VRAM，冷的那堆放一般記憶體。 這就是單卡跑得動 284B 的全部原理。顯卡貴在讀得快，而這個快只有用在「每個 token 都要讀」的權重上才划算。

llama.cpp 用來畫這條分界線的旗標是 -ncmoe N(--n-cpu-moe):前 N 層的專家權重留在 CPU。 分母是模型的層數，這顆是 43。

-ncmoe 43   43 層的專家全部在 CPU      顯卡最省
-ncmoe 38   38 層在 CPU,5 層在 GPU    ← 這篇用的
-ncmoe 0    全部專家都在 GPU           需要約 90GB VRAM

N 越小，搬上 GPU 的層越多、越快，吃的 VRAM 也越多。所以問題變成:你那張卡，能搬幾層?

塞得下 ≠ 跑得起來:顯卡裡裝的不只是權重

在回答上面那個問題之前，要先拆掉一個很合理的誤會。

新手最常見的算法是這樣:模型權重多大、卡有多大，一減發現剛好塞得下，就以為成了。不會成。 VRAM 要同時裝三樣東西:

1. 模型權重 — 你搬上去的那幾層專家，加上熱的那一堆。
2. KV cache — 這段對話到目前為止的內容。你 -c 開多長，這塊就有多大;它是你決定的，不是模型決定的。
3. 計算緩衝區 — 算的時候的暫存空間，prefill 一大段輸入時特別吃。

「權重剛好塞得下」這句話本身沒有意義——權重要是把卡塞滿了，context 就沒地方住。你留給 KV cache 的空間，就是你能開多長的 context。

也因為那個底盤已經含了開滿 1M 的 KV、不是純權重，下一節的公式才會從 11 GB 起算。

你那張卡能搬幾層?一條算式

我把各個 -ncmoe 設定都跑過一遍，記下每組的 VRAM 用量。數字幾乎是等差，可以直接整理成公式。

兩個數字就夠:

• 底盤 11 GB — 專家全部丟 CPU 時的用量(-ncmoe 43，含開滿 1M 的 KV cache)。這是入場費，躲不掉。
• 每層 2 GB — 每把一層專家搬上 GPU 要多付的 VRAM。

於是:

可以搬的層數 = (你的 VRAM_GB − 11) ÷ 2
-ncmoe 要填的值 = 43 − 可以搬的層數

套幾張常見的卡:

你的卡	算出來能搬	-ncmoe
12 GB(3060)	0 層	43(全丟 CPU，剛好卡邊)
16 GB(4060 Ti)	2 層	41
22 GB(改裝 2080 Ti)	5 層	38
24 GB(3090 / 4090)	6 層	37
32 GB(5090)	10 層	33

這張表看中間那列就好:22.5 GB 的卡算出來是 5 層、-ncmoe 38——而那正是我實測跑出來的邊界，不是我先知道答案再湊的公式。

實測的原始數據(1M context，每格跑三次取中位數):

-ncmoe	專家在 CPU	VRAM	decode	結果
43	43 / 43	11,038 MiB	15.40 tok/s	跑得動
40	40 / 43	17,248 MiB	16.07 tok/s	跑得動
38	38 / 43	21,184 MiB	16.50 tok/s	我在跑的
36	36 / 43	載不起來	—	差 1,512 MiB
34	34 / 43	載不起來	—	權重要 24,394 MiB

每往下一格多 2 GB 的規律，在失敗的那幾格也成立:34 層要 24,394 MiB、30 層要 32,266、24 層要 44,762——一路換算下來每層都是 1,970 到 2,080 MiB。載不起來的時候 llama.cpp 會印出它想要多少，那個數字可以拿來校準你自己的算式。

兩種死法要用兩種修法

上面那張表最有用的其實是最後兩列，因為它們死得不一樣。

-ncmoe 36 是這樣死的:

ggml_backend_cuda_buffer_type_alloc_buffer: allocating 1512.00 MiB on device 0: cudaMalloc failed: out of memory
llama_init_from_model: failed to initialize the context: failed to allocate buffer for kv cache

權重放進去了，輪到 KV cache 的時候差 1.5 GB。而 -ncmoe 34 連權重那關都沒過:

ggml_backend_cuda_buffer_type_alloc_buffer: allocating 24394.40 MiB on device 0: cudaMalloc failed: out of memory
llama_model_load: error loading model: unable to allocate CUDA0 buffer

24,394 MiB，而這張卡只有 22,528 MiB。

看訊息裡的最後一個詞就知道要修哪裡:

• 結尾是 kv cache → 權重塞得下，只差 KV 的空間。縮 context、或把 KV 量化再壓一級，不用動 -ncmoe。
• 結尾是 unable to allocate CUDA0 buffer → 權重本身就放不下。只能把 N 調回去，縮 context 一點用都沒有。

我第一次看到這兩段的時候是當成同一種錯在處理的，結果在錯的方向上調了半天。這兩個數字比訊息本身有用:它要 1,512 MiB 跟它要 24,394 MiB，是完全不同的兩件事。

那 context 開多長要付多少?

同樣 -ncmoe 38，只改 context:

context	VRAM	decode
65,536	18,874 MiB	16.48 tok/s
262,144	19,348 MiB	16.46 tok/s
1,048,576	21,184 MiB	16.50 tok/s

context 拉了 16 倍，VRAM 只多 2,310 MiB，吐字速度沒差。第一次看到我還以為量錯了——16 倍的 context 怎麼可能只多兩 GB?

答案在那個 5MB 的 metadata 檔裡。這顆模型的 attention.head_count_kv 是 1(不是常見的 8)、attention.sliding_window 是 128。它走的是混合注意力:局部那條路只看前面 128 個 token，長距離的資訊則以壓縮形式保留，再加上 KV 本身量化成 4-bit。幾個機制疊起來，KV cache 才不會照 context 等比例長——不是「大部分的層只看得到 128 個 token」那麼簡單。

所以這顆模型的 context 直接開滿，不用省。省下來的那 2 GB 換算成 -ncmoe 也只夠多搬一層，而那一層只值 1.4%。

⚠️ 這裡有一個我原本判錯的地方，要講清楚。metadata 裡的 rope 設定長這樣:

rope.scaling.type                    = yarn
rope.scaling.factor                  = 16.0
rope.scaling.original_context_length = 65536

我原本從這三行推論「1M 是硬外推出來的、沒訓練過」——那個推論是錯的。DeepSeek 的技術報告寫得很清楚:V4 的預訓練長度是一路推到 1M 的，官方也說原生支援 1M。YaRN 那組參數描述的是相對 64K 的位置縮放，不等於那個長度沒被訓練過。

真正該留的 caveat 只有一條:長 context 的品質我沒有量過。 這篇只驗到開得起來、跑得穩;到了第 90 萬個 token 還好不好用，我沒有數據。

想再更快，該花錢在哪?

把 VRAM 填滿之後，-ncmoe 43 → 38 買到的是 15.40 → 16.50,+7%。那 7% 是免費的，該拿。

但要理解為什麼只有 7%，不然你會把錢花錯地方:還有 38 層的專家住在一般記憶體裡，每個 token 都要從那邊讀一遍。這台是八通道 DDR4-2133，大約 136 GB/s——吐字速度卡在那條路，不在顯卡上。

三件事的投報率差很多:

• 把 VRAM 填滿:免費的 7%，一定要做。
• 再多買一張同型顯卡:幾乎沒用。專家的大宗還是在 CPU，多一張卡只是讓那 5 層變 10 層，再多 7% 左右就到頂，而且 #3 實測多卡還會付一點通訊的稅。
• 換記憶體頻寬更高的機器:這才是真正的解。同樣的模型搬去 DDR5 八通道或更高的平台，那條路寬多少，吐字就快多少。

講白一點，這台機器的速度是記憶體頻寬決定的，不是顯卡。知道這件事，你才知道什麼時候該停手。

下載:91GB、三個 shard，而 -m 只指第一個

原理講完了，剩下的就是照做。

Unsloth 的 repo 把每一種量化放在自己的資料夾，下載時要指定，不然會把十三種量化全拉下來。

pip install -U "huggingface_hub[cli]" hf_transfer
hf auth login                      # 貼 token,別把 token 寫在指令參數裡

export HF_HUB_ENABLE_HF_TRANSFER=1 # 沒開的話 91GB 會下載很久
hf download unsloth/DeepSeek-V4-Flash-0731-GGUF \
  --include "UD-Q2_K_XL/*" \
  --local-dir ~/models/ds4-0731-ud-q2-k-xl

下載完會看到三個檔案，而第一個只有 5MB:

DeepSeek-V4-Flash-0731-UD-Q2_K_XL-00001-of-00003.gguf       5.3 MB
DeepSeek-V4-Flash-0731-UD-Q2_K_XL-00002-of-00003.gguf      49.4 GB
DeepSeek-V4-Flash-0731-UD-Q2_K_XL-00003-of-00003.gguf      47.4 GB

第一個檔案裡 n_tensors = 0，只裝 metadata。這是正常的，不是下載壞掉——我第一次看到還真的重下了一次。啟動時 -m 就是指這個 5MB 的檔案，llama.cpp 會自己去接後面兩片。

順帶一提，這個 5MB 的檔案很好用:模型規格全在裡面，不用載 91GB 就查得到 block_count(層數)跟 sliding_window。要套上面那條算式，層數就是從這裡拿的。

記憶體要先確認夠:91GB 的權重絕大部分住在一般記憶體。這台 123 GiB 剛好夠，實際常駐 70.3 GiB、Cached 爬到 106 GiB。只有 64GB 的機器這顆就不用試，先看 UD-IQ2 那幾檔。

編一份認得 deepseek4 的 llama.cpp

deepseek4 是比較新的架構，發行版套件裡的 llama.cpp 多半還不認得。自己編，而且要指定顯卡世代。

git clone https://github.com/ggml-org/llama.cpp ~/llama.cpp-0801
cd ~/llama.cpp-0801
git checkout b10217          # 我用的版本,commit ddd4ec1

cmake -B build -DGGML_CUDA=ON \
      -DCMAKE_CUDA_ARCHITECTURES=75 \
      -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release -j$(nproc)

CMAKE_CUDA_ARCHITECTURES=75 是 Turing(2080 Ti 這一代)。你的卡不同就換:Ampere(30 系)86、Ada(40 系)89、Blackwell(50 系)120。

編完先確認它連到哪一版 CUDA:

./build/bin/llama-server --version
ldd build/bin/libggml-cuda.so | grep -E 'cudart|cublas'
# libcudart.so.12 => /usr/lib/x86_64-linux-gnu/libcudart.so.12

這台整台都是 CUDA 12，編出來的也連到 12，一致。如果你的機器裝了多套 CUDA，這裡就可能對不起來——編譯器用新的、跑起來卻連到舊的 runtime，症狀是模型載得進去、一推論就炸，而且錯誤訊息長得完全不像版本問題。我在另一台機器上被這件事咬過，那是下一篇。

開機就跑:寫成 systemd 服務

手動跑起來之後，把它變成常駐服務。這是我正在跑的那份，改路徑就能用:

# ~/.config/systemd/user/llama-ds4-8093.service
[Unit]
Description=DeepSeek-V4-Flash-0731 UD-Q2_K_XL single-GPU server on 0.0.0.0:8093
After=network-online.target

[Service]
Type=simple
Environment=CUDA_VISIBLE_DEVICES=GPU-4555abe2-11c5-7920-32b9-864ad7f7a989
ExecStart=/home/coolthor/llama.cpp-0801/build/bin/llama-server \
  -m /home/coolthor/models/ds4-0731-ud-q2-k-xl/UD-Q2_K_XL/DeepSeek-V4-Flash-0731-UD-Q2_K_XL-00001-of-00003.gguf \
  --alias ds4-deepseek-v4-flash --host 0.0.0.0 --port 8093 \
  -ngl 99 -ncmoe 38 -c 1048576 -ctk q4_0 -ctv q4_0 \
  --parallel 1 --jinja -fa on --metrics --fit off \
  --log-file /home/coolthor/llama-logs/ds4-8093.log
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

systemctl --user daemon-reload
systemctl --user enable --now llama-ds4-8093.service
loginctl enable-linger $USER      # 沒登入也要跑就加這行

幾個參數的理由:

-ngl 99 配 -ncmoe 38 不衝突。-ngl 說「所有層都上 GPU」，-ncmoe 再把其中 38 層的專家部分留在 CPU——注意力那些熱的東西還是在卡上。這兩個要一起下，只下 -ncmoe 的話其他部分不會上去。

CUDA_VISIBLE_DEVICES 填的是顯卡 UUID 不是編號。編號會因為重開機、換插槽而變，UUID 不會。這台三張卡各跑各的服務，填錯編號就是去搶別人的卡:

nvidia-smi --query-gpu=index,uuid,name --format=csv

--fit off 關掉自動配適。開著的時候，llama.cpp 會替你沒指定的參數挑值好讓東西塞得下;你明寫的 -c 它不會動。關掉的理由是量測:少一個「不是我決定的」數值，結果才好解讀。

--parallel 1 留一個 slot。預設是 4 個且 KV 是共用的，所以主要的 context 分配不會直接變成四倍，但每個 slot 的 checkpoint 和 state 仍會增加記憶體壓力;這顆本來就吃記憶體吃得凶，單 slot 最單純。

驗收:三個指令確認它真的在跑你以為的設定

服務起來不等於設定生效。這三個我每次都跑:

# 1. 活著嗎(page cache 熱的話約 11 秒 ready)
curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8093/health

# 2. context 真的是 1M 嗎?有沒有被偷偷改掉?
curl -s http://localhost:8093/props | python3 -m json.tool | grep n_ctx

# 3. 載的是哪顆模型、幾個參數?
curl -s http://localhost:8093/v1/models | python3 -m json.tool | grep -E 'n_ctx|n_params'

對的話第二個回 1048576，第三個回 284334567511。

量速度不用另外裝東西，llama.cpp 的回應自己就帶 timing:

curl -s http://localhost:8093/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"ds4-deepseek-v4-flash",
       "messages":[{"role":"user","content":"用繁體中文寫一段技術說明,解釋混合專家層在推論時做了什麼。"}],
       "max_tokens":256,"temperature":0.7,"seed":42,
       "chat_template_kwargs":{"thinking":false}}' \
  | python3 -c "import sys,json;t=json.load(sys.stdin)['timings'];print('decode %.2f tok/s'%t['predicted_per_second'])"

這台量到的:decode 16.4–16.5 tok/s，中英文沒差。實際流量的 log 撈出來，prefill 短輸入 74–78 tok/s、近 5,000 token 的長輸入 51.6 tok/s，那時 decode 還有 15.49——吐字速度幾乎不隨 context 變，這顆模型用起來很舒服。

進階:四個坑(不讀不影響使用)

到上面為止東西就跑起來了。這節給要繼續往下調的人。

llama.cpp 會建議你關掉 mmap，先別聽。 啟動時會看到:

tensor overrides to CPU are used with mmap enabled - consider using --no-mmap for better performance

關掉之後 91GB 會變成實體常駐記憶體，沒有可回收的緩衝，123 GiB 的機器會變很緊，一個大 prefill 就可能被系統砍掉。用 mmap 讓權重躺在 page cache，慢一點，但不會半夜掛掉。

別用名字殺 process。 這台三張卡跑三個服務，而它們都叫 llama-server。我照著自己的舊筆記打了 pkill -x llama-server，把隔壁那顆模型一起殺了，八分鐘後才發現。要殺就照 PID 或 port 反查:

setsid nohup llama-server ... & echo $! > /tmp/my-seat.pid
kill -TERM "$(cat /tmp/my-seat.pid)"

-f 解決的是「match 到我自己的 shell」，-x 解決不了「match 到鄰居的服務」。兩個都是照名字比對，而名字本來就會撞。

冷啟跟熱啟差很多。 page cache 熱的時候 11 秒 ready，第一次載入要等 91GB 從硬碟讀進來。看到 503 Loading model 別急著重啟，那只會讓它從頭再讀一次。

/props 不會告訴你全部。 它回 n_ctx，但不會回你設的 -ncmoe。要確認那個參數真的吃進去，只能看啟動 argv 或 log。這也是我堅持 --fit off 的原因:關掉自動調整之後，驗收時就少一個會自己變動的參數，也少猜一件事。

收尾

整件事只有三個決定:下載哪一份量化、-ncmoe 填幾、context 開多長。第三項在這顆模型上幾乎不用選，直接開滿;第一項看你的記憶體，真正要算的只有中間那個——而現在你有算式了:(VRAM − 11)÷ 2 是能搬的層數，43 減掉它就是要填的 N。

比算式更值得記的是這句:顯卡的價值，在於加速那批每個 token 都得讀的權重。 每個 token 都會碰到的留在卡上，一年才碰一次的丟去便宜的地方——這一句話同時解釋了為什麼 22G 塞得下 284B，以及為什麼再多買一張卡也快不了多少。

下一篇換 DGX Spark 跑同一顆模型、同一份 GGUF。那台記憶體大得多，-ncmoe 這關直接跳過——但它有另一個坑，而且長得完全不像版本問題。

---

這個系列的其他文章:

• #1 三張 2080 Ti 跑 119B MoE,74 tok/s
• #2 單張 22G 跑 Poolside Laguna S 2.1(118B coding MoE)
• #3 一張 22G 老卡跑 284B，比 DGX Spark 快 18%