如果你正在使用 DeepSeek V4 Flash，你大概率已经发现了一个尴尬的事实：这个模型跑起来有点「重」。云 API 按 token 收费不便宜，本地跑的话，llama.cpp 虽然兼容，但针对 DeepSeek V4 的 MoE 架构优化并不彻底。17500 个 star 的 DwarfStar（项目名 ds4）就是为了填这个坑来的——一个完全自包含的本机推理引擎，只服务 DeepSeek V4 Flash 和 PRO，不做别的事，把事情做到极致。

项目作者是 Salvatore Sanfilippo（antirez），Redis 的创造者。他做这个项目的思路跟他写 Redis 时一脉相承：专注一件事，做对，做快。

不是又一个 GGUF 加载器

现在市面上绝大多数的本地推理工具都是通用型的——GGUF 加载器、llama.cpp 包装器、或者大而全的推理框架。ds4 选了一条完全相反的路：它不是通用的。

它只运行自己生成的 GGUF 文件。这些 GGUF 采用不对称量化策略——路由 MoE 专家用 IQ2_XXS / Q2_K 量化，而共享专家、投影层、路由层保持不变。结果是 2-bit 量化的模型表现远超预期，在 coding agent 环境下调用工具的可靠性跟原始模型差距很小。

白物集用 DeepSeek V4 Flash 作为 Hermes Agent 的后端模型已经有几个月了。云 API 每月账单不算低，而且长上下文场景（知识卡片采集、多轮对话）的 token 消耗量持续增长。ds4 的出现让我们认真考虑本地推理的可行性——128GB 的 M5 Max MacBook Pro 就能跑 q2 量化版的全量 DeepSeek V4 Flash，预填充速度 87 t/s，生成速度 34 t/s，这个数字已经接近云 API 的体验了。

三个真正惊艳的设计

SSD 流式加载：模型比内存大也能跑

这是 ds4 最让我兴奋的特性。传统的本地推理有一个铁律：模型必须完整装入 RAM，否则跑不了。ds4 用 SSD 流式加载打破了这条铁律。

它的做法是把路由 MoE 专家放在 SSD 上，内存中只缓存最常被路由到的专家。非路由权重（共享专家、投影层）仍然常驻内存，而路由专家按需从 SSD 加载。现代 MacBook 的 SSD 速度足够快，缓存未命中的开销在可接受范围内。

在 64GB 的 MacBook 上，用 2-bit Flash GGUF + 32GB 专家缓存，就能跑完整版 DeepSeek V4 Flash。虽然生成速度会下降（受 SSD 读取速度限制），但预填充仍然很快。这意味着你不再需要为「模型到底要多大内存」这个问题纠结——从硬性门槛变成了速度的连续谱。

白物集的场景中，知识卡片的批量处理（预填充为主，生成为辅）非常适合 SSD 流式模式。几千上万 token 的预填充耗时没有显著增加，真正慢的是逐 token 生成阶段。

分布式推理：两台 MacBook 跑 PRO

ds4 支持把模型层拆分到多台机器上推理。两台 MacBook Pro M5 Max 通过 Thunderbolt 5 连接，可以将完整 Q4 量化的 DeepSeek V4 Flash 拆成两部分各占一半层数。预填充可以流水线并行——协调器处理 chunk N+1 时，从机同时处理 chunk N，实测长文本预填充加速比达到 1.85x。

更极端的场景是跑完整版 DeepSeek V4 PRO Q4（需要约 512GB 内存），可以拆到两台 Mac Studio M3 Ultra 上。预填充阶段借助双机 GPU 并行，速度接近单机两倍。

不过需要说明：生成阶段不会加速。因为自回归解码的天生限制——token N+1 必须等 token N 完成后才能开始——分布式推理在生成阶段反而会因为机器间传输延迟而略慢（约 19% 的性能损失）。所以分布式推理的定位是「能跑更大的模型 + 加速长文本预填充」，而不是让日常对话更快。

KV Cache 磁盘优先

这可能是 ds4 最反直觉的设计。绝大多数推理引擎把 KV Cache 视为 RAM 的附属品——尽量放内存，放不下就压缩。ds4 直接反了过来：KV Cache 是磁盘的一等公民。

DeepSeek V4 的压缩 KV Cache 设计非常高效，加上现代 MacBook SSD 的极高读写速度，ds4 把 KV Cache 默认放在 SSD 上。这样释放出来的内存可以用来加载更大的模型量化版本，或者承载更长的上下文窗口。这对于需要超长上下文的场景（代码仓库分析、长时间对话记忆）意义重大。

白物集的内容管线中，每天的知识卡片采集和热点深度文章写作都需要处理数万 token 的上下文。如果 KV Cache 占用可以用 SSD 替代，同样的内存预算下就可以支持更大的上下文窗口，这对文章质量有直接帮助。

适合什么，不适合什么

适合： - 拥有 64-128GB 内存 MacBook 或更高配置 Mac Studio 的开发者 - 深度使用 DeepSeek V4 Flash/PRO 的用户 - 需要长上下文、高隐私（本地推理不出网）的场景 - 对推理延迟有要求，愿意投入硬件成本换响应速度

不适合： - 没有 Apple Silicon 或 NVIDIA GPU 的用户（CPU 路径仅限诊断，macOS 上还有 VM bug） - 希望一个工具跑所有模型的人（ds4 一次只服务一个模型） - 对模型质量要求极高且不接受量化（但 2-bit 的实际表现出人意料地好） - 纯粹为了省钱——硬件成本（Mac Studio 512GB）远高于云 API 月费

快速上手

第一步：下载模型

git clone https://github.com/antirez/ds4
cd ds4
./download_model.sh q2-imatrix   # 96/128GB 内存配置

这个脚本从 HuggingFace 下载官方定制 GGUF，支持断点续传，文件存放在 ./gguf/ 目录。

第二步：编译

make              # macOS Metal（M 系列芯片）
make cuda-generic # Linux CUDA
make cpu          # CPU 诊断模式（仅限验证）

编译只需几秒——项目本身就是一个 C 源文件 ds4.c，没有复杂的构建系统。

第三步：运行 CLI

./ds4 -m ./ds4flash.gguf --ctx 32768

输入提示词，模型开始生成。--ctx 32768 设置上下文窗口为 32K token，--nothink 可以关闭推理过程只输出最终答案。

第四步：启动 API 服务

./ds4-server -m ./ds4flash.gguf --port 8080

服务启动后，任何兼容 OpenAI API 格式的客户端都可以连接。Hermes Agent 的 provider 配置中指向 http://localhost:8080/v1 即可切换为本地推理。

第五步：启用 SSD 流式（内存不够时）

./ds4 -m ./ds4flash.gguf --ssd-streaming --ctx 32768

系统自动计算最佳专家缓存预算，无需手动调参。

写在最后

ds4 的出现代表了一个趋势：当模型足够好（DeepSeek V4 Flash 对大多数开发场景已经接近 frontier 水平），优化的重点就从「能不能跑」转向了「能不能跑得好、跑得省」。antirez 用他一贯的「窄而深」哲学给出了答案——不做通用工具，做一个 DeepSeek V4 的最佳搭档。

从白物集的实际需求来看，ds4 的 SSD 流式和分布式推理让本地运行大型 MoE 模型从「理论上可行」变成了「实际可用」。如果你也在用 DeepSeek V4 且手头有 M 系列 Mac，花 10 分钟跑一遍上手步骤，你可能会对本地推理的印象有大改观。