DeepSeek V4.1 Flash：顯示記憶體殺手，本地能跑嗎？

V4.1 Flash 和 V4 Flash 差在哪？

V4.1 Flash 是全新架構，不是 V4 Flash 的小修：層數從 43 減到 40，總參數從 284B 漲到 769B，解碼啟用參數從 13B 漲到 16B，原生帶視覺。 三個版本的關鍵差異：

能力上的差距是實打實的：官方評測裡 V4.1 Flash 在 Terminal Bench 2.1 拿到 90.6 分（V4 Flash 82.7、V4 Pro 87.9），DeepSWE v1.1 解決率 74.2%（V4 Flash 54.4%），Codeforces 評分 3471。DeepSeek 自己的結論是「V4.1 Flash 在效能、成本、速度上全面超過 V4 Pro」，所以 API 上 deepseek-flash 已經指向它，deepseek-v4-pro 也將從 9 月 14 日中午起路由到 V4.1 Flash，直到 V4.1 Pro 發布。

來源：模型卡、技術報告、DeepSeek API 文件。

511 GB 權重由什麼組成？

Engram 查表佔了 189 GiB，專家佔 260 GiB，兩者加起來 94%，都不能砍。 vLLM 團隊給出的原生 checkpoint 構成如下（來源）：

兩點對本地部署很關鍵：

• 專家原生就是 4-bit。 社群常見的「Q4 量化」對 V4.1 Flash 的專家部分幾乎不再壓縮，只能靠 Engram 和注意力層再降精度。所以 V4.1 Flash 的 GGUF 出來以後，Q4 檔體積不會像其他模型那樣砍到原生的 1/4，估計仍在 400 GB 上下。
• Engram 原則上可以放硬碟，但要等執行環境適配。 它是按 2/3/4-gram 雜湊查表的稀疏存取：兩個模組各 8 個雜湊頭，每個 token 一共查 48 行、讀約 12 KB，行為像詞嵌入而不是矩陣乘法；查哪些行只由輸入 token 決定，整段提示詞的位址在前向開始前就能全部算出、整批預取。技術報告 2.4.2 節寫明官方推論就是把表放在主機記憶體、透過 RDMA 背景預取，不佔顯示記憶體；換成 NVMe 只是延遲從微秒變成百微秒，解碼 10 tokens/s 只需 120 KB/s 的讀取頻寬。所以規劃本地記憶體時可以把這 189 GiB 從預算裡拿掉，只留 NVMe 空間。前提是執行環境實作「按需從磁碟查表」這個運算子，截至 9 月 10 日 llama.cpp、vLLM、MLX 都沒有，官方參考程式碼也是整表載入進記憶體。

下表是本站模型庫按通用公式算出的顯示記憶體需求。模型庫沿用官方口徑，參數量記 552B 骨幹、不含 Engram，啟用參數記「8 / 16」；Q4 一列假設的是尚不存在的 Q4_K_M GGUF，真實體積會比它大：

注意 8K 和 128K 兩列的數字幾乎一樣：V4.1 Flash 的全域 KV cache 每 token 只有 890 位元組，128K 上下文才 0.11 GiB，1M 上下文 0.87 GiB。這是本站模型庫裡第一個 KV cache 可以忽略不計的模型，原因見下一節。

為什麼叫它顯示記憶體殺手：KV cache 去哪了？

「顯示記憶體殺手」殺掉的是 KV cache 這一項：V4.1 Flash 把每 token 的全域 KV 壓到 890 位元組，1M 上下文不到 1 GiB，上下文長度從此不再決定顯示記憶體。 先看它和其他模型的差距，KV 每 token 位元組數按各模型的注意力結構計算，V4 Flash 取官方「V4.1 是它的 1/4」的口徑：

按 DeepSeek 自己的圖，這個數字比 V1 時代小了 437 倍。技術報告 2.3 到 2.4 節給出的四步壓縮，每一步都是架構層面的，不靠量化損失換來：

1. KV 是 512 維潛向量，存成 FP4。 延續 MLA 的思路，每個 token 每層只存一條 512 維的壓縮向量，不存 64 個頭各自的 K 和 V；V4.1 進一步把它用 E2M1 格式儲存，每 16 個通道配一個 E4M3 縮放因子，比 V4 的 FP8 再減半。為此在後訓練裡做了量化感知訓練。
2. 40 層只有 4 層真正產出 KV。 CSA2 把每層設成 Full、Reindex、Reuse 三種模式之一，設定檔裡 kv_source_layer_ids 只有第 2、8、14、20 層是 Full 模式，其餘層複用它們的 KV 和稀疏索引，這就是「跨層複用」。
3. 編碼器每兩個 token 合成一條。 編碼器 18 層 CSA2 的壓縮比是 2，全域 KV 的條數是 token 數的一半；解碼器 20 層的 KV 由編碼器最後一層的輸出投影得到（CED），不再單獨存。
4. 本地注意力視窗固定 128。 滑動視窗那一份 KV 用 FP8 存，但只保留最近 128 個 token，40 層加起來幾 MB，和上下文長度無關。

計算側同樣不隨上下文線性增長：全域注意力只對索引器選出的 512 個位置做，解碼器還把候選範圍限制在前一個 Full 層給出的候選池裡，所以 1M 上下文不只是「裝得下」，也「算得動」。

落到本地部署上，這意味著三件事：

• 上下文長度從顯示記憶體預算裡消失。 一張 24GB 卡跑 Qwen3.8 27B，上下文開到 32K 就要給 KV 留 8 GiB；V4.1 Flash 在卸載模式下的 7 GB 顯示記憶體是常數，8K 和 1M 一個樣。模型頁「什麼顯示卡能跑」一表裡的建議上下文直接給到 128K，原因就在這裡。
• 多會話和狀態存檔幾乎免費。 一個 20 萬 token 的 agent 會話只有 178 MB 全域 KV，llama.cpp 那種把 slot 存檔再復原的做法可以按會話隨手做；伺服器端並行多路長會話也不再被 KV 卡住，這正是 DeepSeek 把 API 價格壓下來的底氣。
• 但它殺不掉權重。 511 GB 的權重一個位元組都沒少，顯示記憶體需求只是從「權重 + 越來越大的 KV」變成「權重 + 幾乎為零的 KV」。所以本地能不能跑，問題從顯示記憶體挪到了記憶體和硬碟，下面三條路線討論的全是權重往哪放。

CED 架構對本地推論意味著什麼？

Causal Encoder-Decoder（CED）把預填充的工作量砍了一半，但解碼一點沒省；對本地使用者，它改善的是長提示詞的等待時間，不是每秒吐字數。 技術報告 2.2 節的機制是：

1. 40 層被分成 20 層「因果編碼器」和 20 層「解碼器」。解碼器各層的全域 KV 不再由自己那一層的隱狀態算出，而是從第 20 層的輸出直接投影得到。
2. 於是預填充（處理提示詞）只需要跑前 20 層，每 token 只啟用 8B 參數；解碼（生成回覆）仍要跑滿 40 層，啟用 16B。
3. 解碼器的滑動視窗注意力（SWA，視窗 128 token）仍按層計算，所以預填充結束時要把提示詞的最後 128 個 token 再過一遍解碼器，重建解碼器的 SWA 狀態。這一步叫 SWA Bounded Replay，代價固定為 128 token，與提示詞長度無關。

落到本地部署上：

• 長提示詞的預填充成本約減半。 走專家卸載時，預填充要把每層啟用的專家權重從記憶體搬進顯示卡，V4.1 Flash 只搬 20 層、8B 參數，而 V4 Flash 要搬 43 層、13B。給 agent 餵幾十 KB 的程式碼或文件，這一段等待會明顯短於 V4 Flash。
• 解碼速度不受益，反而更慢。 解碼啟用 16B 比 V4 Flash 的 13B 多 23%，在記憶體頻寬被卡死的卸載模式下，預估約 9 tokens/s，V4 Flash 約 12 tokens/s。
• 會話狀態幾乎不佔空間。 全域 KV 每 token 890 位元組，一個 20 萬 token 的 agent 會話只有 178 MB，llama.cpp 那種把 slot 存檔再復原的用法會變得非常便宜。SWA 狀態則不需要持久化，復原時按官方做法回放最後 128 個 token 即可。
• 單機使用者可以比官方更精確。 官方伺服器端的 SWA 回放是近似重建，技術報告第 6 節承認在快取復原邊界上可能有未知退化。單一使用者的本地執行環境不需要這個近似：把 SWA KV 一直留在記憶體裡就是精確狀態，40 層 × 128 token 的 SWA 快取只有幾 MB。
• 執行環境的實作難度高於 V4。 預填充和解碼走不同的層數，再加上分層稀疏索引器、Engram 雜湊查表、FP4 KV 反量化和 mHC 殘差流，llama.cpp 要新寫的圖結構比支援 V4 Flash 時多得多。V4 Flash 0731 發布當天 unsloth 就建了 GGUF 倉庫，V4.1 Flash 不能照這個節奏預期。

三條部署路線各要什麼條件？

資料中心一條路今天能走，Mac Studio 和消費卡兩條路都在等軟體。 各裝置在本站公式下的預估速度：

帶星號的是專家卸載速度，前提是 llama.cpp 已支援；本站模型庫按官方 552B 骨幹參數計算、不含 Engram，卸載所需的 304 GB 記憶體和下文布局 B 的原生 280 GB 是同一口徑。DGX Spark 只有 128GB 統一記憶體，表裡的卸載數字對它不成立。

路線一：vLLM 多卡資料中心，今天就能跑

vLLM 0.30.0 起提供專門的 Docker 映像，官方在四種硬體上驗證過：8 卡 H200 節點（1128 GB 顯示記憶體）、GB200 NVL4 單托盤（768 GB）、GB300，以及 AMD MI350X。vLLM 給出的最低顯示記憶體是 614 GB（511 GB × 1.2 餘量），所以 4 卡 H200（564 GB）不夠；A100 一代沒有 FP8 和 FP4 支援，不在驗證清單裡。DeepSeek 自家推論程式碼的範例也是 8 路張量平行。首次載入要讀完 511 GB 權重，官方把引擎就緒逾時設成了一小時。

路線二：Mac Studio M3 Ultra 512GB，等 MLX 支援 Engram 放硬碟

統一記憶體 512GB 是家用裝置裡唯一接近的容量。把 476 GiB 原生權重整個裝進去不行：macOS 預設只允許 GPU 佔用約 75% 的統一記憶體，即便用 iogpu.wired_limit_mb 調到極限也只剩幾 GB 餘量。但如果 Engram 留在 SSD 上，記憶體裡只剩專家、注意力和詞嵌入，原生 FP4 精度約 290 GiB，512GB 裝得下還有餘量，不需要再壓專家精度。所以 Mac 這條路等的不是低位元版本，而是 MLX 實作 V4.1 架構加磁碟查表；mlx-community 截至 9 月 10 日還沒有任何 V4.1 轉換。等版本出來後，按 819 GB/s 頻寬和 16B 啟用參數推算，解碼約 40 tokens/s，會是家用裝置裡最快的方案。

路線三：消費卡或工作站卡 + 大記憶體，等 llama.cpp

把 Engram 放硬碟之後，剩下的專家、注意力和詞嵌入有兩種放法，都是 llama.cpp 現有的機制，只等它支援 V4.1 架構：

布局 A 的解碼按顯示卡頻寬走，本站公式下 RTX PRO 6000 約 80 tokens/s 量級，多卡拆分會打折；布局 B 被記憶體頻寬卡住，雙通道 DDR5 約 9 tokens/s，8 通道 DDR5 的頻寬約為雙通道的四倍，能到 20 到 30 tokens/s。兩者之間還有折衷：哪 6 個專家被啟用是每個 token 由路由決定的，沒法只把「啟用的專家」放顯示記憶體，但可以把前 N 層的全部專家留在顯示卡上，其餘層卸載，llama.cpp 的 --n-cpu-moe 就是這個語義；原生 FP4 下每層專家約 6.8 GB，24GB 卡能多留兩層，96GB 的 PRO 6000 能留 12 層。

壞消息是 llama.cpp 倉庫裡截至 9 月 10 日沒有 V4.1 架構的 PR，磁碟查表運算子也不存在，這兩條布局目前都走不通。已經有大記憶體工作站的讀者，先用 V4 Flash 0731 的 GGUF 把卸載流程跑通，見顯示記憶體不夠，加記憶體有用嗎。

現在能用什麼命令啟動？

只有 vLLM 一條命令可用，其餘執行環境還沒有對應的模型檔案。 8 卡 H200 節點上按 vLLM 官方 recipe 啟動（來源）：

docker run --gpus all --privileged --ipc=host -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e VLLM_ENGINE_READY_TIMEOUT_S=3600 \
  -e VLLM_USE_RUST_FRONTEND=1 \
  vllm/vllm-openai:deepseekv41-flash-0909 deepseek-ai/DeepSeek-V4.1-Flash \
  --tokenizer-mode deepseek_v41 \
  --tensor-parallel-size 8 \
  --tool-call-parser deepseek_v41 \
  --enable-auto-tool-choice \
  --reasoning-parser deepseek_v41 \
  --mm-encoder-tp-mode data

GB200 NVL4 單托盤把 --tensor-parallel-size 改成 4；AMD 卡換用 vllm/vllm-openai-rocm:deepseekv41-flash-0909 映像。只跑文字任務時加 --language-model-only，跳過視覺編碼器並把這部分顯示記憶體讓給 KV cache（它和 --mm-encoder-tp-mode data 二選一）。

兩個容易踩的坑：

• 預設開啟思考模式，推理強度 50。請求裡 max_tokens 給得小，預算會全花在思考軌跡上，傳回空內容和 finish_reason=length，看起來像模型壞了。要麼在 chat_template_kwargs 裡設 thinking: false，要麼把 max_tokens 放大。
• 推理強度只接受 low / high / xhigh / max 或 1 到 100 的整數，medium 和 minimal 會被拒絕。

Ollama、LM Studio、llama.cpp、MLX：截至 9 月 10 日都沒有可用檔案，出現後本站模型頁會更新啟動命令。

該等還是該買？

不要為 V4.1 Flash 買硬體。 三個理由：

• 它的能力優勢集中在長上下文 agent 任務，這類任務一次會話幾十萬 token，本地卸載模式 9 tokens/s 的解碼速度撐不起來，走 API 用 deepseek-flash 更便宜也更快，算帳方法見本地部署要花多少錢。
• 家用能跑滿血的 DeepSeek 仍然是 V4 Flash 0731：Q4 GGUF 155 GB，一張 24GB 卡加 192GB 記憶體就能卸載執行，配置方案見本地部署 DeepSeek 該選什麼顯示卡。
• 「Flash」不再意味著小。V4 Flash 是 284B，V4.1 Flash 是 769B，命名指的是 API 檔位而不是體積。等 V4.1 Pro 發布時，再判斷是否值得為整個 V4.1 系列升級硬體。

已經有 256GB 以上記憶體工作站或 Mac Studio M3 Ultra 512GB 的讀者，值得盯住 llama.cpp 的 V4.1 支援和 mlx-community 的轉換進度：一旦 GGUF 或 MLX 版本出現並支援 Engram 放硬碟，這兩類機器是最先能跑起來的家用裝置。