小編精選 - 技術文章翻譯 · 05月12日

DeepSeek V4 Flash 可以在 128GB 的 M3 Max 上運行，還是 1M 上下文

DeepSeek V4 Flash 可以在 128GB 的 M3 Max 上跑，還支援 1M 上下文

最近 Redis 創始人 Antirez 開源了一個專案 [*ds4*](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fantirez%2Fds4)，**用幾千行純 C 程式碼把 1M 上下文的「DeepSeek V4 Flash MoE 模型」，在一台 128GB 記憶體的 M3 Max MacBook Pro 上完整跑通，同時還能穩定支援 coding agent 迴圈**。

這裡的重點是， ds4 不是一個簡單的量化操作，而是用「不對稱優化」搭配「硬體特性深度綁定」來突破「長上下文必須吃掉巨量 GPU/記憶體」的限制。

ds4 其實不是通用推理引擎（不像 llama.cpp 或 vLLM），它是專門為 DeepSeek V4 Flash 這個特定模型量身打造，核心可以總結為三個技術概念：

（1）不對稱 2-bit 量化（Asymmetric 2-bit Quantization）

這裡核心做法就是把模型「90%+ 參數」在 MoE 的 routed experts 上做 2-bit 量化（up/gate 用 IQ2_XXS，down 用 Q2_K），而關鍵路徑（routing、shared experts、projections 等）全部保持全精度。

因為 MoE 模型的專家部分體積很大，但啟用是稀疏的，量化它們對最終輸出的影響遠小於量化 dense 部分，這一點 Antirez 自己也驗證過：

q2 版本在 coding agent 裡「可靠呼叫工具、迴圈工作良好」。

相較於傳統 2-bit 量化品質會大幅下降，這種「只壓大頭，但保留精華」的不對稱方案，把記憶體占用壓到了 128GB 的水準，同時把 perplexity／品質損失控制在可接受範圍內。

所以，這屬於對模型結構感知的量化，而不是通用量化。

（2）KV Cache 相容到 SSD（Disk-native KV Cache）

ds4 把 KV Cache 做成「記憶體中的活躍狀態」搭配「磁碟持久化前綴快取」的組合，KV Cache 可以移到 SSD，用 SHA1 雜湊 token 前綴當作 key，壓縮後的 KV row 直接以 plain read/write 落地（不用 mmap，避免 macOS 的 VM 壓力）。

支援 cold/continue/evict/shutdown 多種策略，還帶 tool-call replay map，確保 DSML 精確重放。

目前會話仍然會有一個 live KV checkpoint 在記憶體裡，但不同 session、重啟、長前綴重用可以依賴 disk KV cache 恢復，避免每次都從 token zero 重新 prefill。

由於 Apple Silicon 的統一記憶體架構（Unified Memory）加上超高速 NVMe SSD，帶寬與延遲的組合遠勝一般場景，長上下文（1M tokens）產生的 KV Cache 體量巨大（數十到上百 GB），但 SSD 吞吐量足以讓 generation 速度只輕微下降：

在 11k+ token prefill 下，從 26.68 t/s 掉到 21.47 t/s。

這算不算完全的典範轉移？一般來說大家普遍都認為 KV Cache 必須全在記憶體裡，不然延遲會爆炸，但 Antirez 把磁碟當成「擴充記憶體」的測試效果，也證明在特定硬體 + 壓縮 + I/O 優化下其實是可行的。

1M 不靠擴充記憶體，單純 SSD 當 swap 還能穩定 27 tok/s，Apple Silicon 的 unified memory + NVMe IO 鏈路在長 context 上比想像中還強。

（3）純 Metal 原生實作

整個引擎只有幾千行 C + Metal shader，沒有任何通用框架的開銷（不依賴 GGML/llama.cpp 連結）：

Metal worker 單線程序列化推理，避免 race condition
只支援官方釋出的 DeepSeek V4 Flash GGUF（q2 / q4 兩種），tensor layout 和 metadata 都是客製化的
額外支援實驗性的 MTP（speculative decoding），但提升不大

而對應官方 benchmark，M3 Max 128GB q2 版本下的性能測試：

短 prompt：prefill 58.52 t/s，generation 26.68 t/s
11k+ token 長 prompt：prefill 250+ t/s，generation 21.47 t/s

27 t/s 感覺其實不快，但對 agent loop（思考 - 呼叫工具 - 繼續生成）來說其實也夠用，因為 agent 場景本來就不是即時聊天，多輪迭代下也還過得去。

另外 2-bit 量化有一定損失，目前只有 Metal、沒有 CUDA，同時 server 是單請求序列化，CPU path 還會觸發 macOS kernel bug。

雖然有一定侷限性，但是「128GB 的 M3 Max」就能跑了啊！甚至搭配 OpenAI/Anthropic 相容的 ds4-server，就可以直接對接 OpenClaw、Claude Code 了，用高階模型做 Plan 和 Review，本地模型做簡單執行的混合模式，也可行了。

不過說實話，27 t/s 適合 agent，不適合高併發或即時對話，128GB 機型實際建議上下文 100k–300k（1M 是理論上限，記憶體還得留給系統和其他程式），不過目前不支援 Windows 和 Linux，CUDA 版本據說正在開發中，但這確實是一個不錯的方向。

Antirez 提到過 CUDA 版本正在開發中，目前 private branch 已經在 DGX Spark（GB10）上跑通了 ~12 t/s generation + ~200 t/s prefill。

ds4 整體效能可以參考：

目前不少人實測已經跑通了，在 128GB M3 Max 下載 q2 版本就能直接跑，不過目前測試下，q2 量化下 tool calling 偶爾會 hallucinate end tokens 或 parser 狀態損壞。

另外有人測試，預設 DS4 設定下實測可以達到 14–15 t/s，62K 預填充實際編碼對話，記憶體使用量在生成過程中保持穩定 85GB 左右；對於一個完整的 100K 上下文視窗，磁碟快取約為 8GB，最大的限制是每次發生壓縮時，需要等待大約「每 10k 個上下文約 1 分鐘」才能重新開始操作。