DwarfStar 4 深度拆解：当 Redis 之父决定「干掉全部通用推理引擎」——一个专用 MoE 推理栈如何用 2-Bit 量化和磁盘 KV 缓存在 MacBook 上跑出 26 tok/s

一、背景：本地运行 284B 大模型成为现实

2026 年 5 月，一个名为 DwarfStar 4（简称 ds4）的开源项目在 GitHub 上迅速获得了 10K+ Star。它的作者不是别人，正是 Redis 创始人 Salvatore Sanfilippo（antirez）——那个用 C 语言写出全球最快内存数据库的人。

这一次，antirez 把目光投向了另一个极端：本地大模型推理。

在 ds4 出现之前，本地运行一个 284B 参数的大模型被认为是不切实际的。模型太大，显存不够，推理速度慢到无法使用。但 DeepSeek V4 Flash 的 MoE（Mixture of Experts，混合专家）架构改变了这一切——每次推理只激活约 30B 参数，配合激进的 2-bit 量化，可以在消费级硬件上流畅运行。

antirez 在项目 README 中写道：

"DeepSeek V4 Flash is special. It deserves a dedicated inference engine."

这不是又一个通用 GGUF 加载器。这是一个只为一个模型而生的极简推理栈。从模型加载、prompt 渲染、工具调用、KV 状态管理、HTTP 服务到编码 Agent 集成，全部围绕 DeepSeek V4 系列一起设计、一起测试。

二、为什么需要一个专用推理引擎？

2.1 通用 vs 专用：两种哲学的碰撞

在 LLM 推理领域，一直存在两种截然不同的设计哲学：

通用派（以 llama.cpp 为代表）：一个引擎支持所有模型，通过 GGUF 格式统一量化标准，靠社区驱动持续扩展。优势是覆盖面广，劣势是无法为某个特定模型做极致优化。

专用派（以 ds4 为代表）：只支持一个模型，但把所有优化手段都用到极致。优势是性能和功能的天花板更高，劣势是模型一换就得重写。

antirez 选择了后者，原因很实际：

1. MoE 架构的特殊性：DeepSeek V4 Flash 的 MoE 路由机制决定了专家权重的访问模式是高度可预测的，通用引擎无法利用这个特性
2. KV 缓存的极致需求：1M token 上下文窗口意味着 KV 缓存管理是核心瓶颈，通用方案无法做到磁盘级持久化
3. Agent 场景的工具调用：编码 Agent 需要精确的 tool-id 映射和 DSML 格式回复，通用 API 无法保证一致性

2.2 antirez 的设计哲学

antirez 的代码风格一贯是「用最少的代码做最多的事」。ds4 继承了这个传统：

核心设计原则：
├── 非通用实现 — 只针对 DSV4 一个模型，不做通用 GGUF loader
├── KV 缓存是"一等磁盘公民" — 不仅存在于 RAM，还可以持久化到磁盘
├── 三件套 — 推理引擎 + HTTP API + 特制 GGUF 量化文件
└── AI 辅助开发 — 使用 GPT 5.5 辅助编码，antirez 主导设计和调试

这种「一个人 + AI」的开发模式本身就是 2026 年开源项目的一个标志性趋势。

三、架构深度解析

3.1 整体架构

ds4 的架构可以用一张图来概括：

┌─────────────────────────────────────────────────┐
│                  DwarfStar 4                     │
├─────────────┬─────────────┬─────────────────────┤
│  ds4 CLI    │ ds4-server  │  download_model.sh  │
│  交互式推理  │  HTTP API   │   模型下载脚本       │
├─────────────┴─────────────┴─────────────────────┤
│              核心推理引擎                          │
│  ┌───────────┬──────────┬───────────┬──────────┐│
│  │ Prompt    │ MoE 路由  │ KV Cache  │ Quantize ││
│  │ Renderer  │ Scheduler│ Manager   │ Engine   ││
│  └───────────┴──────────┴───────────┴──────────┘│
├─────────────────────────────────────────────────┤
│              硬件后端                              │
│  ┌────────┐ ┌────────┐ ┌────────┐ ┌──────────┐ │
│  │ Metal  │ │ CUDA   │ │ ROCm   │ │ CPU      │ │
│  │ ✅主力  │ │ ✅支持  │ │ ⚠️社区 │ │ ⚠️调试  │ │
│  └────────┘ └────────┘ └────────┘ └──────────┘ │
├─────────────────────────────────────────────────┤
│              特制 GGUF 量化文件                    │
│  q2-imatrix / q4-imatrix / mxfp4 / pro-q2      │
└─────────────────────────────────────────────────┘

3.2 非对称 MoE 量化策略

这是 ds4 最核心的技术创新之一。

传统量化对模型的所有权重一视同仁，但 MoE 架构的权重并不是同等重要的。在 DeepSeek V4 Flash 的 284B 参数中：

• 路由专家权重（routed experts）：每次推理只激活约 30B，但占据了绝大部分存储空间
• 共享权重（shared expert + projection）：每次推理都会用到，必须保持精度
• 门控权重（gate/up）：决定激活哪些专家，对精度敏感

ds4 的 q2-imatrix 量化策略：

这种不对称量化的好处是：在 2-bit 的极端压缩下，仍然能保持编码 Agent 工具调用的可靠性。imatrix 版本通过权重重要性矩阵（importance matrix）进一步优化量化精度。

3.3 磁盘 KV 缓存：一等公民

传统本地推理的 KV 缓存完全在 RAM 中。这意味着：

• 对话历史随进程重启而消失
• 长上下文推理需要巨大的内存开销
• 无法实现「断点续传」式的对话恢复

ds4 的磁盘 KV 缓存彻底改变了这个局面。核心数据结构：

// KV 缓存文件结构（简化表示）
struct kv_cache_entry {
    char        sha1_prefix[41];  // 渲染文本的 SHA1 哈希
    int64_t     token_ids[];      // 精确的 token ID 序列
    graph_state graph;            // 完整的计算图状态
    tool_id_map tools;            // tool-id 映射表（DSML 格式）
};

// 四个保存时机
enum kv_save_timing {
    KV_COLD,      // 冷启动：首次加载
    KV_CONTINUED, // 续写：对话继续时增量保存
    KV_EVICT,     // 驱逐：内存不足时换出到磁盘
    KV_SHUTDOWN   // 关闭：进程退出时持久化
};

这意味着你可以：

1. 关闭服务器去吃饭
2. 回来重启服务器
3. 之前的对话上下文自动恢复，无需重新处理整个提示

对于编码 Agent 场景，这个功能的价值是巨大的——你的 Claude Code 会话不会因为重启 ds4-server 而丢失上下文。

3.4 SSD 流式加载：内存不够的救命稻草

对于 64GB 或更小内存的 Mac，ds4 提供了 SSD 流式加载模式：

# 64GB MacBook 的保守起点
./ds4 -m ./ds4flash.gguf \
  --ssd-streaming \
  --ssd-streaming-cache-experts 16GB

# 128GB MacBook 跑 PRO q2 流式
./ds4 \
  -m gguf/DeepSeek-V4-Pro-IQ2XXS-w2Q2K-AProjQ8-SExpQ8-OutQ8-Instruct-imatrix.gguf \
  --ssd-streaming --nothink

工作原理：

• 非路由权重（shared expert、projection）仍然驻留内存
• 路由 MoE 专家放在内存中的动态缓存
• 缓存未命中时，直接从 GGUF 文件流式加载
• 代价是生成速度变慢，但 prefill 仍然很快

这种设计让 64GB 内存的机器也能运行 284B 模型，虽然速度不是最优，但「能跑」本身就是一个突破。

四、实测性能数据

4.1 Metal 后端（Apple Silicon）

关键观察：

• Mac Studio M3 Ultra 在 q2 量化下的 prefill 速度达到 468 t/s，意味着载入长上下文几乎瞬间完成
• 生成速度 27-37 t/s 对于日常编码辅助已经完全可用
• q4 量化比 q2 慢约 5-10%，但质量更好

4.2 CUDA 后端（NVIDIA GPU）

4.3 多用户 LLM 服务

一个特别值得关注的场景：8 张 NVIDIA L40S（Ada Lovelace 架构，已经被 vLLM 不再支持新模型）走 CUDA 多卡 + ds4-server 的微批处理：

• 多 session 并发聚合生成：120 t/s
• Prefill 吞吐：约 2000 t/s

这组数字的意义在于：消费级或二手卡也能跑大模型服务，关键在于推理引擎是否专门为这几张卡的特性调过。

五、代码实战：从安装到部署

5.1 安装与编译

# 克隆仓库
git clone https://github.com/antirez/ds4
cd ds4

# 下载量化模型（推荐 q2-imatrix）
./download_model.sh q2-imatrix

# 编译（macOS Metal）
make

# 编译（Linux CUDA）
make cuda-spark    # DGX Spark
make cuda-generic  # 通用 GPU

5.2 命令行交互

# 基础用法
./ds4 -m ds4flash.gguf -p "用 Python 写一个快速排序" --temp 0

# 指定思考模式
./ds4 -m ds4flash.gguf -p "解释一下 Transformer 的注意力机制" --think

# 最大深度思考
./ds4 -m ds4flash.gguf -p "设计一个分布式缓存系统" --think-max

5.3 作为 Agent 服务运行

# 启动 HTTP API 服务
./ds4-server --kv-disk-dir /tmp/ds4-kv

# 配合 Claude Code 使用
export ANTHROPIC_BASE_URL="http://127.0.0.1:8000"
export ANTHROPIC_MODEL="deepseek-v4-flash"
claude

ds4-server 提供兼容 OpenAI API 格式的 HTTP 接口，可以无缝对接 Claude Code、Codex 等编码 Agent。

5.4 磁盘 KV 缓存配置

# 启用磁盘 KV 缓存，指定 8GB 缓存空间
./ds4-server --kv-disk-dir /tmp/ds4-kv --kv-disk-space-mb 8192

# 缓存文件自动管理
# - 冷启动时加载已有缓存
# - 对话续写时增量更新
# - 内存不足时自动驱逐到磁盘
# - 进程关闭时持久化所有状态

5.5 多机分布式推理

当模型大到一台机器装不下，可以使用流水线并行：

# Machine A: coordinator，layers 0..30
./ds4 -m gguf/DeepSeek-V4-Pro-Q4K-Layers-00-30.gguf \
  --layers 0:30 \
  --coordinator 0.0.0.0:9000

# Machine B: worker，layers 31..output
./ds4 -m gguf/DeepSeek-V4-Pro-Q4K-Layers-31-output.gguf \
  --layers 31:output \
  --coordinator A:9000

实测在直连链路上，分布式生成约 11.47 t/s；每 token 本地层约 39-43 ms，远程层约 44-49 ms。

5.6 GLM 5.2 支持

ds4 不仅支持 DeepSeek V4 Flash，还兼容 GLM 5.2：

# 下载 GLM 5.2 量化模型
./download_model.sh glm-antirez-q2

# 使用 GLM 5.2
./ds4 -m gguf/GLM-5.2-UD-IQ2_XXS_RoutedIQ2XXS_blk78Q2K.gguf \
  -p "你的问题" --glm-mtp

六、深度对比：ds4 vs llama.cpp

关键差异在于设计目标不同：

• llama.cpp 的目标是「让每个人都能在本地跑任何模型」
• ds4 的目标是「让 DeepSeek V4 Flash 在消费级硬件上达到最佳体验」

两者不是竞争关系，而是互补关系。

七、适用场景分析

7.1 最佳场景

1. 本地 AI 编程助手：在 MacBook 上跑 Claude Code / Codex，取代云 API，代码不离开本地
2. 隐私敏感场景：企业内网部署，数据不出局域网
3. 离线开发环境：无网络时仍可使用 AI 辅助
4. 研究与实验：测试量化策略、KV 缓存机制、MoE 路由行为
5. 学习推理引擎实现：antirez 的代码风格清晰，是学习 LLM 推理的绝佳教材

7.2 不适合的场景

1. 需要运行多种模型：ds4 只支持 DeepSeek V4 Flash 和 GLM 5.2
2. 硬件不匹配：没有 Metal/CUDA/ROCm 支持的硬件
3. 追求最新稳定性：项目仍处于 beta 阶段
4. 超大规模部署：需要成熟的生产级方案

八、局限性与注意事项

1. Alpha 质量：项目仅存在几周，稳定性有待验证。antirez 每次发布前会跑完整 QA，但不稳定完全可能
2. 硬件门槛高：最低 96GB RAM（q2 量化），推荐 128GB+
3. 仅一个模型：不支持其他模型，未来的 DSV4 更新版需要适配
4. macOS CPU 路径有内核 Bug：Apple 的虚拟内存实现问题会导致内核崩溃
5. GGUF 文件需要特定格式：不是通用 GGUF loader，必须使用项目提供的量化文件
6. 分布式生成反而更慢：分布式推理主要用于「装得下更大模型」和「加速长 prefill」，不是为了让 decode 变快

九、对行业的启示

9.1 「一人 + AI」的开发模式

ds4 是 2026 年「一个人 + AI 辅助」开发模式的标杆案例。antirez 用 GPT 5.5、5.6、Claude Fable 辅助编码，自己负责设计、测试和调试。这种模式正在改变开源项目的开发方式：

• 开发速度：一个人可以在几周内完成过去需要团队几个月的工作
• 代码质量：AI 辅助减少了 boilerplate，让开发者专注于核心逻辑
• 项目范围：个人开发者可以挑战过去只有大公司才能做的领域

9.2 专用 vs 通用的永恒命题

ds4 的成功再次证明：在某些领域，专注比全面更有价值。通用方案适合 80% 的场景，但在剩下 20% 的极端场景中，专用方案的性能和功能天花板更高。

这对 LLM 推理领域的启示是：未来可能出现更多「模型专用」的推理引擎，每个引擎都为特定模型家族深度优化。

9.3 本地推理的未来

ds4 的出现标志着本地大模型推理进入了一个新阶段：

• 消费级硬件可用：128GB MacBook 跑 284B 模型，26 tok/s
• Agent 场景成熟：磁盘 KV 缓存 + 工具调用支持 = 本地编码 Agent
• 多机协作：流水线并行让超大模型在消费级集群上成为可能

随着模型压缩技术的进步和硬件内存的增长，本地推理将不再是「玩具」，而是「生产工具」。

十、总结

DwarfStar 4 是 2026 年最值得关注的本地 LLM 推理项目之一。Redis 之父 antirez 用他一贯的极简主义风格，打造了一个极度专注、性能出色的专用推理引擎。

对于 Mac 开发者来说，这意味着可以在本地运行一个 284B 参数的思考模型，速度达到 26 tok/s，配合 1M 上下文窗口和磁盘 KV 缓存，体验接近云端 API——而且代码完全不出本地。

如果你正好拥有 128GB+ 的 MacBook 或 Mac Studio，又想本地跑 DeepSeek V4 Flash 做编码助手，ds4 是目前最好的选择。如果你的硬件不匹配，等它从 beta 走向稳定再入手也不迟。

GitHub: https://github.com/antirez/ds4
License: MIT
作者: Salvatore Sanfilippo (antirez)

本地推理不是未来，而是现在。当你可以在自己的 MacBook 上跑出 26 tok/s 的 284B 模型时，云端 API 的垄断就已经被打破了。