DwarfStar 4 (ds4) 實現了在高效能 Mac 和 GPU 上進行前沿大型語言模型的本地推論

TL;DR – ds4 的功能與重要性

DwarfStar 4 (ds4) 讓您能在高效能 Mac、NVIDIA CUDA 或 AMD ROCm 硬體上本地執行 DeepSeek V4/V4.1、GLM 5.x 和 Qwen 3.8 等前沿權重大型語言模型，其原理是透過非對稱 2-bit 量化壓縮 MoE 專家模型，並將 KV-cache 串流至 SSD。這使得在單一工作站上執行 2840 億參數模型成為可能，無需依賴昂貴的遠端 API 呼叫。

核心設計 – 專用推論堆疊

ds4 是一個精簡的純 C 語言引擎，專注於一組定義明確的 MoE 模型，並對每個佈局進行端到端驗證。 與通用的 GGUF 執行器不同，ds4 專注於三個模型系列（DeepSeek V4/V4.1、GLM 5.x、Qwen 3.8）並提供三個統一介面：CLI (./ds4)、本地 HTTP 伺服器 (./ds4-server) 以及持久化編碼代理 (./ds4-agent)。

非對稱 2-bit 量化

"壓縮路由專家模型，保持關鍵共享路徑的精確度。這就是受支援的路由 MoE 模型如何適應目標機器的方式。" – ds4 文件

混合專家模型 (MoE) 層中的專家被量化為 2-bit。
共享路由和注意力路徑保留較高的精度，從而保持模型品質。
該技術使 2840 億參數的 DeepSeek V4 模型能夠在 128 GB 的系統上執行。

將 KV-cache 視為磁碟公民

"將長前綴儲存到 SSD 並透過提示雜湊 (prompt hash) 恢復。重啟不必意味著完整的重新預填充 (re-prefill)。" – ds4 文件

前綴 KV-cache 可以刷新到 SSD，允許高達 65k token 的上下文而不會耗盡 RAM。
基於提示雜湊的恢復避免了重啟後的重新預填充，這對於長時間執行的代理至關重要。

統一的三介面模型狀態

./ds4 – 互動式聊天 CLI。
./ds4-server – 與 OpenAI 相容的 HTTP API，適用於編輯器、代理或自訂客戶端。
./ds4-agent – 具有內建狀態管理的持久化編碼工作階段。

支援的模型與硬體適配

ds4 目前支援：

DeepSeek V4 & V4.1 Flash (混合專家模型，2840 億參數)
GLM 5.x (包含 Flash 變體)
Qwen 3.8 Flash Next (可選視覺功能)

記憶體需求與效能

平台	記憶體	模型 (量化)	上下文	預填充 t/s	生成 t/s
Apple M5 Max	128 GB	DeepSeek V4 Q2	2 048 tok	790.2	39.4
Apple M5 Max	128 GB	DeepSeek V4 Q2	65 536 tok	398.5	27.6
NVIDIA DGX Spark	128 GB	DeepSeek V4 Q2	2 048 tok	825.8	18.1
NVIDIA DGX Spark	128 GB	DeepSeek V4 Q2	65 536 tok	823.0	13.8

基準測試表格直接取自 ds4 網站。

硬體矩陣 – 基準模型 (DeepSeek V4 Q2) 可在任何 128 GB 系統上順暢執行。GLM 5.3 Q2 和 Qwen Q4 也適用於 128 GB，而 DeepSeek V4.1 Q2 則從 SSD 串流，允許在 64 GB 的 Mac 上運作。

快速入門工作流程

獲取 GGUF 權重

git clone https://github.com/antirez/ds4
cd ds4 && ./download_model.sh ds4f-q2

為您的後端建置 (Metal, CUDA, 或 ROCm)

make            # 通用建置 (macOS 上的 Metal)
make cuda-spark # CUDA 優化建置

執行

./ds4                     # 互動式 CLI
./ds4-server --ctx 100000 # 啟動與 OpenAI 相容的 API

ds4 不旨在執行任意 GGUF 檔案；僅支援經過驗證的模型佈局。

社群擴充與生態系統

ds4go – 一個 Go FFI 封裝器和 TUI，允許其他語言將 ds4 作為共享函式庫呼叫。由 @neomantra 維護，增加了視覺和 Qwen 支援，並提供可透過 Homebrew 安裝的二進位檔案。(GitHub 發布版本 v0.8.20260)
Club-3090 server – 由 @gchamon 維護的 ds4 網頁前端，實現了對本地引擎的遠端存取。
自訂 SSD-cache 分支 – 使用者已將磁碟快取功能反向移植到 llama.cpp 和其他執行器 (例如 @xlayn 的分支)。

ds4 與其他本地執行器的區別

功能	ds4	llama.cpp / ollama
目標 MoE 模型 (DeepSeek V4, GLM 5.x, Qwen 3.8)	✅	❌ (僅限通用 GGUF)
專家模型的非對稱 2-bit 量化	✅	❌ (通常為統一量化)
KV-cache 持久化至 SSD	✅	❌ (僅限記憶體)
統一的 CLI、伺服器和代理共享狀態	✅	部分 (獨立的二進位檔案)
Apple Silicon 的 Metal 優先實作	✅	有限 (主要是 CPU)

社群成員指出，ds4 的最小依賴哲學與 Redis 相似，使其輕量且易於嵌入。

開放問題與社群回饋

工具呼叫效能 – 使用者如 @cuttothechase 詢問使用函式呼叫時的 TPS 數據；目前的基準測試側重於原始預填充和生成速度。
量化後的模型品質 – @doctorpangloss 提到對激進量化後 DeepSeek V4 檢查點品質的擔憂。
Apple Silicon 上的最小 RAM – 討論顯示了一些困惑：網站引用 64 GB 作為 SSD 串流執行的下限，而 GitHub README 提到全速 Metal 執行需要 96 GB。
與其他執行器的比較 – 幾位評論者 (例如 @locknitpicker) 要求與 ollama 或 llama.cpp 進行並排速度比較；ds4 的利基在於 MoE 特定的優化，而非通用的 GGUF 支援。

結論

ds4 提供了一種實用的途徑，可在單一工作站上本地執行前沿權重 MoE 模型，利用非對稱量化和 SSD 支援的 KV 快取來克服記憶體限制。其專注的模型支援、低依賴的 C 語言實作以及三個統一介面，使其成為需要高品質推論且無雲端延遲的使用者，相較於通用執行器更具吸引力的替代方案。