Day 17｜ds4 深度解析：Redis 之父只為一種模型造了一個引擎

2026 iThome 鐵人賽

DAY 17

AI Engineering

128GB 統一記憶體的三十天：DGX Spark 地端 LLM 與生成式 AI 部署實戰系列第 17 篇

18th鐵人賽

ivanusto

2026-08-30 22:00:03

236 瀏覽

分享至

從通則到特例

昨天講選型方法論，五個問題幫你在眾多模型裡挑一個。今天講一個把整套邏輯推到極端的特例，如果你已經知道自己要的就是那一款模型，接下來的問題就變成，願不願意為它放棄通用性，換取把它跑到最好呢。

這個問題有一個現成的答案叫 ds4（DwarfStar），作者是 antirez，寫出 Redis 的那位大神。它在 Day 6 的引擎圖鑑裡客串過「第五人格」，今天稍微詳細說明一下它的優點，因為它是我 Spark 1 上跑了 2 個月的日常主力引擎，服役時數比本系列任何一個通用引擎都長。

它是什麼 ? 一個專用的推論引擎

先講清楚它的定位。它不是 llama.cpp 的包裝，不是通用 GGUF 執行器，也不支援你選擇其他的模型給它用。它是純 C 寫成、完全自包含的原生推論引擎，深度支援的模型原本只有 DeepSeek V4 Flash 與 PRO 這兩款，現在又多了社群也很關注的 GLM 5.2 這款強大模型。這位大神作者在 README 裡誠懇致謝 llama.cpp 與 GGML 開出的路，而這個專案的程式碼是他精心打造的，維持了良好的執行效率。

這個「只服務一顆模型」的決定，換到的效益，每一樣都跟通用引擎的取捨相反：

KV cache 能從記憶體外放到 SSD 上

通用引擎的 KV 通常是活在記憶體裡，行程一關就蒸發。ds4 把 KV cache 設計成可以串流到 SSD 的持久資料，長對話關掉重開，上下文直接從磁碟回來，不用重算 prefill。對照本系列 Day 9 到 15 一路在算的 KV 記憶體帳，這是完全不同的解題路線，DS4 並不是採用省 KV 的路線，它反而讓 KV 可以不用住在最貴的地段，放到在 SSD 也能用，可讓記憶體載入量化過的 DeepSeek V4 Flash 模型。

量化配方為特定硬體量身訂做

它的 2-bit imatrix 量化可說是寫給 96GB 到 128GB 記憶體等級的機器採用，DeepSeek V4 Flash 壓到約 81 GB，正好讓 Spark 這一級的裝置塞得下一顆旗艦級 MoE 還有餘裕。Day 12 講過低位元沒有 imatrix 幾乎不能用，ds4 的 2-bit 就是 imatrix 功力的展示品。如果是更大尺寸檔案的版本，則可以放到更大記憶體的機器，特別是新世代 Mac 機器上，有更多的統一記憶體選項可用。

Makefile 裡有一行 make cuda-spark

專門為 GB10 特調的建置目標，官方效能表直接列 DGX Spark 實測成績（q2 量化、7,047 token 提示詞，prefill 343.81 t/s、生成 13.75 t/s）。一個開源專案把你的機器當一級支援平台，這種待遇通用引擎給不了。

ds4-server 支援度廣
OpenAI 相容與 Anthropic 相容端點都有，上層工具不管認哪一家的 API 格式都接得上。單一即時 session 的設計聽起來寒酸，對照 Day 11 的結論其實誠實，單人場景本來就不需要 continuous batching 的武器庫。

服役 2 個月的實話

規格講完，講體感，這部分是官方 README 沒有的。

它讓「旗艦 MoE 當日常」成立。 DeepSeek V4 Flash 的能力等級與 27B 級模型不是同一個等級的東西，通用引擎路線下它的量化檔對 128GB 是緊的，而 ds4 的 2-bit 讓它變成常駐可行。過去一個月我的查詢、翻譯、文件整理都是由它提供服務的，品質穩定，這是垂直整合最直接的紅利。

磁碟 KV 在長專案裡真的有感。 如果有某個工作 session 跨好幾天，重開機後上下文還在，這個體驗會讓人回不去。代價是 SSD 的寫入量，拿 Day 10 的儲存視角看，它把 KV 的頻寬壓力從記憶體轉嫁到了 NVMe，長期跑要留意 SSD 的寫入壽命，產生的影響，我會在維運篇補算。

它的極限也很誠實。 想換更多模型，沒有，目前只有兩種主流模型可選用。想平行處理服務公司更多人，沒有。當之後模型換代（V4 變 V5）時，這個托論引擎要等作者跟進才有辦法用，這是把身家押在單一專案節奏上的風險。Day 6 說過的那句話一個月後仍然成立，當你的日常主力就是那一顆模型時，這個取捨非常划算，前提是你要想清楚。

GLM 5.2 入列，還教你兩台機器合體

DS4 深度支援名單從 DeepSeek 雙款擴充到近期熱門的 GLM 5.2，之後還會有 5.3，這件事的意義不只是多一顆模型可選，而是官方順手示範了一個新玩法，把一顆模型拆到兩台 128GB 的 MacBook 上合跑。GLM 5.2 的常駐 expert 分片約需 97.5 GiB，再加上 KV 與 scratch 的開銷，單機記憶體會比較難順跑，DS4 官方的做法是 coordinator 與 worker 各扛一段層（例如 --layers 0:19 與 --layers 20:output），兩台機器用 Thunderbolt 直連。

設定上有兩個每次開機要做一次的前置。第一是把 GPU 可鎖定記憶體上限拉高，macOS 預設約為 RAM 的 75%，要用 sudo sysctl iogpu.wired_limit_mb=120000 放寬到約 117 GB。第二是 RDMA over Thunderbolt 要求 IPv4 位址直接掛在實際接線的成員介面上，掛在 bridge 上的 IP 不算數，接受 TCP fallback 的話可以跳過這步。載入模型前可用 rdma_ctl status 與 ibv_devinfo -v 確認 verbs 裝置就緒。

官方也給了一張很誠實的網路連線對照表，同樣兩台 M5 Max、同一份 91 GB 的 Flash 量化檔案、8192 token 提示詞、生成 128 token，只換連線方式。

連線	Ping 平均	Prefill	生成
Thunderbolt 5	0.45 ms	582.99 t/s	25.09 t/s
WiFi	77.20 ms	250.70 t/s	10.70 t/s
Internet / VPN	152.10 ms	114.88 t/s	3.63 t/s

WiFi 與 VPN 的數字會隨現場環境變動，官方強調重點在型態，延遲直接打擊生成速度，頻寬不足則把長 prefill 也拖下水。拿本系列 Day 3 文章的視角看，這張表等於幫本系列的 10GbE 與雙 Spark 直連規劃背了一次書，跨機推論這件事，網路連線就是運算路徑的一部分，不能不重視。

官方載入模型的三條路線

README 這次也把模型進入 ds4 的途徑寫清楚了。

第一，原生 safetensors 加 config.json，官方推薦。
直接把 ds4 指向 Hugging Face 模型目錄，走原生 loader。官方明講這條路永遠比轉檔過的 GGUF 可靠。對照 Day 5 的 NFS 模型庫規劃，我們集中存放的本來就是 HF 原始格式，這條路等於零額外成本。

第二，預轉換的 .ds4 檢查點。
單一檔案，tokenizer 與量化中繼資料都內嵌，適合發佈與搬運。

第三，經 llama.cpp 工具轉出的 GGUF。
支援的架構可以用，但官方附上一個很重要的警告，轉檔工具遇到不認得的 tensor 名稱時會寫入假 tensor，而不會報錯中止。這解釋了社群偶爾回報的「檔案能載入、輸出卻不對勁」的靈異現象，問題不在推論引擎，在轉檔那一刻就發生了。官方的結論很乾脆，能用 safetensors 就用 safetensors。