DwarfStar 4 深度拆解：当 Redis 之父决定「给 284B 大模型造一个专属引擎」——从 Metal GPU 到磁盘 KV 缓存，一个 10K Star 的极简推理栈如何用 One Model One Engine 哲学重新定义本地 AI 推理的终极形态

一、开篇：一个 Redis 之父的「跨界」之作

2026 年 5 月 7 日，一个名为 ds4 的开源项目悄悄出现在 GitHub 上。没有铺天盖地的宣传，没有技术大会的预热，甚至 README 都写得极其朴素。但 48 小时内，它就拿下了 2600+ Star。

这个项目的作者是 Salvatore Sanfilippo —— 业界更熟悉他的网名 antirez，Redis 的创始人。

一个做内存数据库的传奇程序员，为什么要给一个 AI 大模型写专用推理引擎？

答案藏在 ds4 的一句话定位里：

One Model, One Engine.

不支持其他模型，不做通用 GGUF loader，不追求大而全。它只做一件事：把 DeepSeek V4 Flash 的 284B 参数在 Apple Silicon Mac 上跑到极致。

这种极致专注的工程哲学，在 AI 工具链越来越臃肿的今天，反而成了一股清流。

二、为什么是 DeepSeek V4 Flash？

在拆解技术细节之前，我们需要理解 antirez 为什么选择 DeepSeek V4 Flash 作为 ds4 的唯一目标。这不是随便选的——antirez 在项目文档中列出了 8 个理由，每一个都指向同一个结论：DSV4 是当前最适合本地推理的 MoE 模型。

2.1 MoE 架构的天然优势

DeepSeek V4 Flash 采用 MoE（Mixture of Experts）混合专家架构：

总参数量：284B
每次激活参数：约 13B（MoE 路由选择）
激活比例：~4.6%

这意味着虽然模型有 284B 参数的知识储备，但每次推理实际只用到约 13B 参数的计算量。相比同级别的 Dense 模型（如 Llama 3.1 405B），DSV4 的推理速度快了一个数量级。

关键洞察：MoE 的本质是「用存储换计算」。

传统的 Dense 模型，284B 参数意味着每次推理都要经过所有 284B 参数的计算。而 MoE 通过门控网络（Gating Network）动态选择少数专家参与计算，其余专家「休息」。这让大模型在本地推理成为可能。

2.2 思考模式的可控性

DSV4 支持三种推理模式：

antirez 特别指出：DSV4 在非最大思考模式下，思考段长度仅为同类模型的 1/5。这意味着同等任务下，DSV4 的 token 消耗更低，推理速度更快。

对于本地推理来说，这至关重要——每一秒的生成延迟都会影响用户体验。

2.3 百万级上下文窗口

DSV4 支持 100 万 token 的上下文窗口。在本地 Agent 场景中，这意味着：

• 代码库的完整上下文可以一次性加载
• 长对话不需要频繁截断历史
• 复杂任务的多轮推理不会丢失关键信息

配合 ds4 的磁盘 KV 缓存（后面会详细拆解），百万级上下文在本地变得真正可用。

2.4 2-bit 量化效果出色

DSV4 的 MoE 架构在极低比特量化下表现异常出色。ds4 提供了两种量化方案：

• q2-imatrix（推荐）：96/128GB 设备，仅量化 MoE 路由专家，共享专家保持全精度
• q4-imatrix：256GB+ 设备，更高精度

imatrix（importance matrix）版本通过权重重要性矩阵优化量化，确保在 2-bit 下仍能保持 coding agent 工具调用的可靠性。

三、ds4 的核心架构：极简到极致

3.1 代码结构

ds4 的代码结构极其精简：

ds4-main/
├── ds4.h                 # 公共引擎边界（CLI/server 只依赖此头文件）
├── ds4.c                 # 核心引擎：模型加载、tokenizer、CPU 参考实现、Metal 图调度
├── ds4_metal.h/.m        # Objective-C Metal 运行时与 kernel 包装
├── metal/                # 全部 Metal 计算 kernel
│   ├── flash_attn.metal  # Flash Attention 实现
│   ├── moe.metal         # MoE 路由与专家计算
│   ├── dense.metal       # 稠密矩阵乘
│   ├── dsv4_hc.metal     # Head Compressor（DS V4 特有）
│   ├── dsv4_kv.metal     # KV 处理
│   └── dsv4_rope.metal   # RoPE 位置编码
├── ds4_cli.c             # CLI 交互式 REPL
├── ds4_server.c          # OpenAI/Anthropic HTTP API 服务
└── tests/                # 官方 logprobs 回归测试向量

3.2 分层架构

┌─────────────────────────────────────────────────────────────┐
│                        应用层                                │
│  ┌─────────────────┐  ┌─────────────────────────────────┐  │
│  │    ds4 CLI      │  │         ds4-server              │  │
│  │  (交互式 REPL)  │  │    (HTTP API 服务)              │  │
│  └─────────────────┘  └─────────────────────────────────┘  │
├─────────────────────────────────────────────────────────────┤
│                      API 兼容层                              │
│  ┌──────────────────────────┐  ┌────────────────────────┐  │
│  │   OpenAI 兼容            │  │   Anthropic 兼容       │  │
│  │  (/v1/chat/completions) │  │   (/v1/messages)       │  │
│  │   SSE 流式响应          │  │                        │  │
│  └──────────────────────────┘  └────────────────────────┘  │
├─────────────────────────────────────────────────────────────┤
│                     核心推理引擎                              │
│  ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌──────────┐ │
│  │ Tokenizer  │ │ GGUF 加载器│ │ Metal 图   │ │ Session  │ │
│  │            │ │ (mmap)     │ │ 调度器     │ │ 管理     │ │
│  └────────────┘ └────────────┘ └────────────┘ └──────────┘ │
├─────────────────────────────────────────────────────────────┤
│                     Metal 计算层                              │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────────────┐ │
│  │Flash Attn│ │ MoE 路由  │ │ 稠密矩阵 │ │ KV Cache 管理 │ │
│  └──────────┘ └──────────┘ └──────────┘ └────────────────┘ │
└─────────────────────────────────────────────────────────────┘

3.3 设计哲学：零抽象层

antirez 在 README 中明确写道：

Zero abstraction layers. No C++. No feature flags. No big abstractions.

这与现代软件工程的「分层解耦」理念完全相反。但 antirez 的逻辑是清晰的：

1. ds4 只支持一个模型——不需要通用抽象
2. C 语言的直接性——每一行代码都直接映射到硬件行为
3. Metal 的直接性——GPU kernel 可以精确控制每个计算步骤

代码语言分布：

• C 语言：约 55%（核心引擎）
• Objective-C：约 30%（仅在 Metal 必须处使用）
• Metal kernel：约 14%（计算密集型操作）

这种「极简主义」不是偷懒，而是一种深思熟虑的工程选择。antirez 说得很直白：正确性优先，不接受出现 attention/KV/logits 漂移却跑得更快的实现。

四、三大核心技术深度拆解

4.1 非对称量化策略：只量化「不重要」的层

这是 ds4 最精妙的设计之一。

传统的量化方案（如 llama.cpp 的 Q4_K）是对模型所有层进行统一量化。但 ds4 采用了一种非对称量化策略：

// 量化配置（非对称方案）
typedef struct {
    // 路由专家层：激进量化（2-bit）
    QuantConfig experts_q2;   // IQ2_XXS (up/gate), Q2_K (down)
    
    // 共享专家层：保持高精度
    QuantConfig shared_q8;    // Q8_0 (保持完整精度)
    
    // 投影层与路由层：高精度保留
    QuantConfig proj_q8;      // Q8_0
    QuantConfig router_q8;    // Q8_0
} DS4QuantConfig;

核心理念：关键精度层保持高精度，次要容量层大幅压缩。

为什么路由专家可以激进量化？

在 MoE 架构中，路由器（Router）决定了哪个专家被激活。路由器的输出是一个概率分布，即使量化到 2-bit，只要排序关系不变，选择结果就不会改变。而路由专家的权重主要用于特征变换，对精度的敏感度远低于路由器和投影层。

量化效果对比：

在 coding agent 场景下，90% 的质量保留完全够用。而生成速度从 18 t/s 提升到 26 t/s，用户体验提升了 44%。

4.2 KV 缓存磁盘化：让上下文「记住」自己

这是 ds4 最独特的功能，也是它与 llama.cpp 最大的差异化。

传统问题：

传统的 LLM Agent 客户端（如 Claude Code）每次请求都需要重发整段对话历史。假设你的代码库有 25k token，每次推理都要重新 prefill 这 25k token。在云端 API 场景下这不是问题（服务端有全局 KV 缓存），但在本地推理场景下，这意味着：

• 首次请求：需要数秒到数十秒的 prefill 时间
• 后续请求：如果 KV 缓存在内存中，可以复用；但如果重启服务，KV 缓存丢失，需要重新 prefill

ds4 的解决方案：

将 KV 状态持久化到磁盘：

// 磁盘 KV 缓存核心逻辑
typedef struct {
    uint8_t key[SHA1_DIGEST_LENGTH];  // Token 序列的 SHA1 哈希
    char *kv_path;                     // 磁盘文件路径
    size_t kv_size;                    // KV 状态大小
    uint32_t token_count;              // 对应的 token 数量
} DiskKVEntry;

使用 SHA1 哈希作为 key，相同 token 序列的 KV 状态可以跨会话复用。

四个保存时机：

1. Cold start：服务启动时，尝试从磁盘恢复上次的 KV 状态
2. Continued：对话继续时，增量更新磁盘缓存
3. Evict：内存不足时，LRU 淘汰最旧的 KV 状态到磁盘
4. Shutdown：服务关闭时，将当前 KV 状态写入磁盘

性能收益：

# 首次请求（冷启动）
$ time ./ds4 -m ds4flash.gguf -p "分析这个代码库"
real    0m12.3s   # 需要 prefill 25k token

# 二次请求（KV 缓存命中）
$ time ./ds4 -m ds4flash.gguf -p "优化这段代码"
real    0m0.8s    # 直接从磁盘恢复 KV 状态

对于 Claude Code 这类发送 25k+ token 初始 prompt 的 Agent，prefill 时间从分钟级降至毫秒级。这是一个质的飞跃。

4.3 双协议兼容层：同时服务 OpenAI 和 Anthropic

ds4 同时支持两套 API 协议，这意味着它可以直接作为 Claude Code 和 Codex 的本地后端：

// OpenAI 格式请求
POST /v1/chat/completions
{
    "model": "deepseek-v4-flash",
    "messages": [...],
    "max_tokens": 4096,
    "stream": true,
    "tools": [...]  // 工具调用支持
}

// Anthropic 格式请求
POST /v1/messages
{
    "model": "deepseek-v4-flash",
    "messages": [...],
    "max_tokens": 4096,
    "thinking": {"type": "enabled", "budget_tokens": 10000}
}

使用 Claude Code 时，只需设置环境变量：

export ANTHROPIC_BASE_URL="http://127.0.0.1:8000"
export ANTHROPIC_MODEL="deepseek-v4-flash"
claude  # 现在 Claude Code 使用本地 DSV4 推理

这意味着：你可以在 MacBook 上跑 Claude Code，但推理完全在本地完成，代码不离开你的机器。

五、实测性能数据

ds4 官方提供了详细的性能基准测试：

5.1 Metal 后端推理速度

关键观察：

1. Mac Studio M3 Ultra 在 q2 量化下的预填速度达到 468 t/s，意味着载入长上下文几乎瞬间完成
2. 生成速度 27-37 t/s 对于日常编码辅助已经非常可用（人类阅读速度约 5-8 t/s）
3. DGX Spark 的生成速度较低（13.75 t/s），可能与 CUDA kernel 优化程度有关

5.2 与 llama.cpp 的性能对比

虽然 ds4 没有直接提供与 llama.cpp 的对比数据，但从架构设计可以推断：

六、安装与实战

6.1 快速开始

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

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

# 编译（macOS Metal）
make

# 命令行使用
./ds4 -m ds4flash.gguf -p "用 Python 写一个快速排序" --temp 0

6.2 作为 Agent 服务运行

# 启动 HTTP API 服务（带磁盘 KV 缓存）
./ds4-server --kv-disk-dir /tmp/ds4-kv --kv-disk-space-mb 8192

# 配置 Claude Code 使用本地服务
export ANTHROPIC_BASE_URL="http://127.0.0.1:8000"
export ANTHROPIC_MODEL="deepseek-v4-flash"
claude

6.3 CUDA 后端（Linux / DGX Spark）

# DGX Spark
make cuda-spark

# 通用 GPU
make cuda-generic

七、ds4 背后的工程哲学

7.1 AI 辅助开发的典范

ds4 是少数公开承认使用 AI 辅助开发的大型开源项目之一。antirez 在 README 中明确写道：

AI-assisted development. Built with GPT 5.5 for coding; antirez for design, testing, and debugging.

这不是一个 AI 自动生成的项目。antirez 负责：

• 架构设计：选择单模型专注、Metal-only 执行、零抽象层
• 测试与调试：使用官方 DeepSeek API 的 logprobs 作为测试向量
• 正确性验证：确保本地推理与云端结果一致

GPT 5.5 负责：

• 代码生成：将 antirez 的设计意图转化为 C/Metal 代码
• 样板代码：协议解析、文件 I/O 等机械性工作

这种「人类主导设计，AI 辅助实现」的模式，可能是未来开源项目的最佳实践。

7.2 Redis 基因的延续

ds4 的很多设计理念都能看到 Redis 的影子：

antirez 在 Redis 中证明了：简单的系统可以做复杂的事。ds4 再次证明了这一点。

八、适用场景与局限性

8.1 最佳适用场景

1. 本地 AI 编程助手：在 MacBook 上跑 Claude Code / Codex，代码不离开本地
2. 隐私敏感场景：企业内网、政府机构、医疗行业
3. 离线开发环境：无网络时仍可使用 AI 辅助
4. 研究与实验：测试量化策略、KV 缓存机制、MoE 路由行为
5. 学习推理引擎实现：antirez 的代码风格清晰，适合学习

8.2 局限性

1. Alpha 质量：项目仅存在几周，稳定性有待验证
2. 硬件门槛高：最低 96GB RAM（q2），推荐 128GB+
3. 仅一个模型：不支持其他模型，包括未来的 DSV4 更新版需要适配
4. macOS CPU 路径有内核 Bug：Apple 的虚拟内存实现问题会导致内核崩溃
5. GGUF 文件需要特定格式：不是通用 GGUF loader，必须使用项目提供的量化文件

九、本地推理的未来展望

ds4 的出现标志着本地大模型推理进入了一个新阶段。但它只是开始。

9.1 技术趋势

1. 专用引擎 vs 通用引擎：ds4 证明了「One Model, One Engine」的可行性。未来可能出现更多针对特定模型优化的推理引擎
2. 磁盘 KV 缓存标准化：ds4 的磁盘 KV 缓存可能成为本地推理的标配
3. Apple Silicon 的 AI 优势：Metal GPU 的统一内存架构让大模型本地推理成为可能

9.2 对开发者的影响

1. 不再依赖云端 API：本地推理速度已经足够实用
2. 隐私与安全：代码不离开本地，企业可以放心使用
3. 成本可控：一次性硬件投入 vs 持续的 API 费用

十、总结

DwarfStar 4 不是一个通用工具，而是一个极致专注的作品。Redis 之父 antirez 用他一贯的极简主义风格，证明了一个深刻的工程真理：

最好的工具不是功能最多的，而是把一件事做到极致的。

ds4 把「在 Mac 上跑 DeepSeek V4 Flash」这件事做到了极致：26 tok/s 的生成速度、磁盘 KV 缓存、双协议兼容、非对称量化。它不支持其他模型，不做通用抽象，甚至不追求社区化——但它把本地 AI 推理的体验提升到了一个新的水平。

对于 Mac 开发者来说，这意味着：

• 在 MacBook 上跑 284B 参数的思考模型
• 速度达到 26 tok/s，配合 1M 上下文窗口
• 代码不离开本地，隐私完全可控
• 体验接近云端 API，但成本可控

GitHub: https://github.com/antirez/ds4
License: MIT

如果你也对本地 AI 推理和 Agent 开发感兴趣，欢迎关注程序员茄子，持续分享 AI 开发工具和实践心得。