文章总结： Redis创始人antirez开发了专用于DeepSeekV4Flash模型的本地推理引擎ds4.c，仅支持AppleMetal后端。核心创新是将KV缓存作为一等磁盘对象实现持久化，采用不对称量化策略（仅量化routedMoEexperts）。在128GBM3Max上q2量化短提示生成速度26.68t/s，M3Ultra长提示预填达448.82t/s。项目提供HTTP服务并兼容OpenAI/Anthropic协议，目前为alpha质量但为高端Mac用户提供了专用化推理的工程范本。 综合评分： 85 文章分类： 安全工具,AI安全,技术标准,解决方案,安全开发

Redis 之父为 deepseek v4 flash写一台推理引擎

原创

🅼🅰🆈 🅼🅰🆈

独眼情报

2026年5月11日 11:18 湖北

在小说阅读器读本章

去阅读

3天 6 千星，可见实力

长话短说

ds4.c 是 Redis 创始人 Salvatore Sanfilippo（antirez）写的一个 DeepSeek V4 Flash 专用 本地推理引擎，仅支持 Apple Metal。它故意做得很「窄」：不是通用 GGUF 运行器、不是 llama.cpp 包装、不是框架，而是一条围绕 DeepSeek V4 Flash 这一个模型从加载、Metal 图执行、KV 状态到 HTTP 服务全栈打通的路径。项目的核心赌注有两条：「一次只把一个模型做完整」，以及「在 SSD 时代，KV cache 不再属于内存，而是一等公民的磁盘对象」。在 128GB RAM 的 MacBook Pro M3 Max 上用 2-bit 量化跑 q2 模型，短 prompt 约 26.68 t/s 生成、58.52 t/s 预填；Mac Studio M3 Ultra 512GB 上 q4 长 prompt 预填可达 448.82 t/s。截至本文写作时 GitHub 2.3k stars、135 forks，作者自述「alpha 质量」。

一、为什么要写这篇

本地推理（local inference）赛道并不缺项目：llama.cpp、ollama、MLX、vLLM……几乎每个新模型出现，社区都会迅速跟进。在这个生态里 antirez 选择写一个只支持一个模型、只支持一种后端、只支持几款 Mac 的引擎，乍看是反潮流的。

但翻完 README，会发现这恰恰是他想表达的论点——一个本地模型要「感觉完成」，光是「能跑」远远不够。它需要推理引擎、为该引擎特别构造的 GGUF、配合编码 Agent 的端到端验证三者同时到位。ds4.c 是这套主张的具体落地。

这种「窄而深」的工程美学，和 antirez 当年做 Redis 的路数一脉相承——拒绝通用化、拒绝抽象层、追求每个组件单一职责做到极致。

二、项目定位：一次只赌一个模型

ds4.c 的项目定位在 README 第一段就直接划定了边界：

• 不是通用 GGUF 运行器——它只加载作者在 huggingface.co/antirez/deepseek-v4-gguf 发布的特定 DeepSeek V4 Flash GGUF 文件，任意其他 GGUF 不会有匹配的张量布局、量化组合、元数据；
• 不是另一个 runtime 的封装——核心路径是 DeepSeek V4 Flash 专用的 Metal 图执行器；
• 不是框架——没有插件、没有抽象后端层。

作者明确说：「确切的模型可能随生态演化而改变，但约束保持不变：本地推理在高端个人机器或 Mac Studio 上可信地跑起来，起点是 128GB 内存。」

这种「故意窄」的姿态在工程上有个隐含好处——所有优化都不必再考虑通用性的拖累。从张量布局到量化策略到 Metal kernel，每一处都可以为这一个模型量身定制。代价当然也明显：DeepSeek V5 出来之后，这套代码要么大改、要么作废。antirez 显然接受了这种权衡，README 里说预期 DeepSeek 会继续发布 v4 Flash 的更新版本，引擎跟着迭代即可。

三、为什么选 DeepSeek V4 Flash

README 列了七条理由（这里转述，原文有作者的主观判断成分）：

1. 快——active parameters 少（MoE 结构）；
2. 思考链更短且与问题复杂度成正比——在 thinking 模式下，避开 max thinking 时，思考段长度有时是其他模型的 1/5，使得 thinking enabled 这个开关变得真正可用；
3. 百万 token 上下文窗口；
4. 模型大、知识边缘更深——284B 参数比 27B/35B 在长尾知识上有明显差距；
5. 英文和意大利文写作质量高——作者意大利人，这条是亲身判断；
6. KV cache 压缩极强——使长上下文推理在个人电脑可行，并使得磁盘 KV cache 持久化变得有意义；
7. 2-bit 量化下表现良好——前提是用「特殊方式」量化（见下文）。

第 6 条是整个项目最核心的工程主张，下面单独讲。

四、核心创新：把 KV cache 当作一等磁盘对象

这是 ds4.c 最值得拿出来讲的设计。

传统认知里，KV cache 是 GPU/内存里短命的中间状态——会话结束就丢，下次重新预填。但 antirez 观察到两件事在最近几年同时发生：

• DeepSeek V4 这类模型的 KV cache 被压缩得非常小；
• 现代 MacBook 的 SSD 极快。

那么 KV cache 为什么不能落盘、跨会话复用、跨服务重启复用？

ds4-server 实现了一套完整的磁盘 KV 缓存机制：

• 缓存 key 是 token IDs 的 SHA1（按小端 32-bit 哈希，不是文本哈希），文件名为 <sha1>.kv；
• 文件用普通 read/write 而非 mmap 写入——这是个有意的选择，避免给已经 mmap 了模型的进程再增加 VM 映射；
• 文件结构包含 48 字节固定头（含魔数 “KVC”、版本号、量化位数、保存原因、token 数、命中数、创建/最后使用时间戳等）、可读的 token 文本（仅供观测，不参与 key）、以及一段以 “DSV4” 为魔数的 DS4 会话载荷（含 checkpoint tokens、下一 token 的 float32 logits、压缩 KV 行、indexer 行等）。

缓存在四个时机写入：cold（长 prompt 首次到达稳定前缀时）、continued（生成推进一定 token 数时）、evict（被新会话替换前）、shutdown（服务退出时）。冷保存会有意截掉小段尾 token 并对齐到预填 chunk 边界，以避开 BPE 重分词错失。

这个设计对接 Claude Code 这类 Agent 时收益巨大。README 直白地写了：Claude Code 启动时常常先发约 25k token 的初始 prompt，这部分预填代价高，但内容相对稳定。磁盘 KV cache 让首次昂贵预填之后的所有后续会话都能直接复用前缀——这在没有这层机制的引擎上是每次都要重跑的。从架构哲学讲，这是把「内存 vs 磁盘」的边界重新画了一次，类似当年 Redis 重新画「缓存 vs 数据库」边界的思路。

五、量化策略：一种刻意的「不对称」

ds4.c 提供的 2-bit 量化不是粗暴砍精度。README 用「非笑话（not a joke）」来强调——这套量化在 coding agent 下行为良好、工具调用可靠。

具体做法：只量化 routed MoE experts，且其中 up/gate 用 IQ2_XXS、down 用 Q2_K。这些 routed experts 占了模型空间的绝大多数。其他组件——shared experts、projections、routing——保持原精度以保证质量。

这种「按重要性差异化量化」的思路在生态里并不新，但应用到 DeepSeek V4 Flash 这种规模的 MoE 上，配合作者亲自发布的特制 GGUF，可以让 128GB RAM 的 MacBook Pro 装得下这个 284B 的模型（q2 模型本身约 81GB）。

六、性能数据

以下数据来自 README，Metal CLI 单次运行、--ctx 32768、--nothink、greedy decoding、-n 256：

| 机器 | 量化 | Prompt | Prefill | Generation | | — | — | — | — | — | | MacBook Pro M3 Max, 128 GB | q2 | short | 58.52 t/s | 26.68 t/s | | MacBook Pro M3 Max, 128 GB | q2 | 11709 tokens | 250.11 t/s | 21.47 t/s | | Mac Studio M3 Ultra, 512 GB | q2 | short | 84.43 t/s | 36.86 t/s | | Mac Studio M3 Ultra, 512 GB | q2 | 11709 tokens | 468.03 t/s | 27.39 t/s | | Mac Studio M3 Ultra, 512 GB | q4 | short | 78.95 t/s | 35.50 t/s | | Mac Studio M3 Ultra, 512 GB | q4 | 12018 tokens | 448.82 t/s | 26.62 t/s |

q4 需要更大内存机型，所以 M3 Max 上的 q4 数据是 N/A。

注意：READMEで提到 1M token 满上下文大约需要 26GB 内存（仅压缩 indexer 就 22GB）。128GB 机器上跑 q2（模型本身 81GB），实际可用上下文建议 100k~300k token 范围。

七、Agent 集成：HTTP 服务与三种客户端协议

ds4-server 提供同时兼容 OpenAI 和 Anthropic 风格的本地 HTTP 服务。支持的端点：

• GET /v1/models、GET /v1/models/deepseek-v4-flash
• POST /v1/chat/completions（OpenAI 风格，支持 tools、tool_choice、SSE 流式等）
• POST /v1/completions
• POST /v1/messages（Anthropic 风格，Claude Code 客户端走这条）

工具调用部分做了双向转换：OpenAI/Anthropic 的 tool schema 会被渲染成 DeepSeek 的 DSML 工具格式，模型生成的 DSML 工具调用再映射回各自原生格式。思考模式下，reasoning 按各 API 的原生形态流式输出，而不是混进最终文本。

README 给出了三种 Agent 客户端的接入示例：

• opencode：在 ~/.config/opencode/opencode.json 添加 provider 和 agent 条目；
• Pi：在 ~/.pi/agent/models.json 配置；
• Claude Code：通过环境变量包装脚本（ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN、ANTHROPIC_MODEL 等）把请求指向本地 ds4-server。

八、值得明说的局限

按 antirez 一贯的坦率，README 把限制写得很清楚，照搬如下：

• 仅 Metal——CUDA 可能未来支持，但「不会更多」；
• CPU 路径仅供正确性校验——而且当前 macOS 版本有虚拟内存 bug，跑 CPU 推理会导致内核崩溃（需重启电脑），作者明确求助社区帮修；
• 服务器单 worker、不批处理——请求解析和 socket 在客户端线程跑，但推理本身串行通过一个 Metal worker，并发请求要排队；
• MTP 推测解码仍实验性——目前只在 greedy decoding 下有意义，且收益是「轻微加速」而非「明显加速」；
• 2.3k stars，14 commits，alpha 质量——作者自陈「我们可能还没到那里」；
• AI 重度协作开发——README 明说「在 GPT 5.5 强力辅助下开发，人主导想法、测试和调试。如果你不接受 AI 开发的代码，这个软件不适合你」。

结论

ds4.c 不是要替代 llama.cpp，作者自己在致谢里反复强调这一点（「这个项目没有 llama.cpp 和 GGML 就不存在」）。它要回答的是另一个问题：当你愿意为一个具体的模型在一台具体的机器上做完所有事，能做到什么程度？

对于持有 Mac Studio 或 128GB+ MacBook Pro、且正在用编码 Agent 工作的人，这个项目值得现在就装上试一试。对于其他人，它至少提供了三样值得带走的东西：磁盘 KV cache 的设计样本、不对称 MoE 量化的实操路径、一个 Redis 之父认为「本地推理应该长什么样」的具体回答。

https://github.com/antirez/ds4

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：独眼情报 🅼🅰🆈 🅼🅰🆈《Redis 之父为 deepseek v4 flash写一台推理引擎》