DeepSeek V4推理引擎深度测评：Redis之父为何亲自操刀？

DeepSeek V4发布仅两周，开源社区便迎来了第一批为其深度优化的原生基础设施。

这并非在现有框架上进行的简单适配。它既非通用的GGUF加载器，也非llama.cpp的包装器，并且明确不支持其他任何模型。

其目标纯粹且极致：让DeepSeek V4 Flash在Mac设备上释放全部性能潜力。

这条“专属高速通道”，名为ds4.c。其缔造者的分量，足以让整个技术社区侧目——

Salvatore Sanfilippo，开发者们更熟知他的ID：antirez。这位创造了Redis（GitHub 7.4万Star）并主导这一全球主流内存数据库长达十一年的传奇程序员，如今的新项目，是一个专为DeepSeek V4 Flash设计的本地推理引擎。

项目时间线上，已有开发者在配备128GB内存的Mac上成功部署并运行。

看来，Mac的高内存配置需求，将再次被DeepSeek模型推高。但为了驾驭这条“性能巨鲸”，这样的投入似乎物有所值。

专为V4 Flash优化的本地推理方案

4月24日，DeepSeek V4系列正式亮相。其中的V4 Flash作为效率型号，拥有2840亿总参数、130亿激活参数以及100万token的上下文长度。如此庞大的模型规模，在过去通常被视为云端计算的专属领域。

而antirez的目标，是将其完整部署到一台Mac之中。ds4.c由此应运而生。

这是一个完全使用C语言与Metal API从头构建的推理引擎。项目结构极其精简：C代码占55.4%，Objective-C占30.2%，Metal Shader占13.8%。其核心设计哲学是仅依赖Metal——无需运行时环境，没有框架依赖，彻底摒弃多余的抽象层。

Metal是苹果生态中调用GPU进行图形与通用计算的底层API，可视为苹果版的CUDA。ds4.c对Metal的独占性依赖，意味着该引擎专为Apple Silicon芯片架构深度优化，不兼容NVIDIA或AMD的显卡。

整个项目的唯一目标：让V4 Flash在本地苹果设备上，不仅“能够运行”，更要达到“生产可用”的性能水准。

目前的基准测试结果已颇具说服力：在128GB内存的MacBook Pro M3 Max上，采用2-bit量化、32K上下文长度时，短提示词的预填充速度达到58.52 token/s，生成速度为26.68 token/s。在512GB内存的Mac Studio M3 Ultra上，处理长提示词（11709 token）时，预填充速度可飙升至468.03 token/s，生成速度稳定在27.39 token/s。对于一个2840亿参数的MoE模型而言，这样的本地推理速度已具备实际应用价值。

核心技术实现解析

其高性能源于三个关键设计。

第一，非对称量化策略。 ds4.c并未将所有参数统一压缩至2-bit，而是选择性量化MoE模型中的路由专家层（up/gate层使用IQ2_XXS，down层使用Q2_K），这些层占据了模型存储的绝大部分。至于其他核心组件，如共享专家层、投影层及路由层，则全部保留完整的Q8精度。antirez在项目README中明确写道：“这里的2-bit量化是严肃的，它们在代码助手场景下表现可靠，能够稳定地调用工具。”

第二，将KV缓存持久化至硬盘。 当前多数LLM Agent客户端是无状态的，每次请求都需要重新发送完整对话历史。通用引擎的做法是每次都重新执行预填充。ds4.c的创新在于将KV状态写入磁盘，后续请求通过匹配token前缀的SHA1哈希值来识别。若命中缓存，则直接从磁盘加载状态，完全跳过预填充阶段。这对于像Claude Code这类每次启动会发送高达25K token初始化提示的Agent场景尤为关键，首次预填充后，后续会话可瞬间恢复。

第三，内置OpenAI与Anthropic双协议兼容层。 它同时提供遵循OpenAI协议的/v1/chat/completions端点，以及遵循Anthropic协议的/v1/messages端点。工具调用功能也完成了适配。README中直接给出了opencode、Pi、Claude Code三种主流Agent客户端的配置示例。

关于项目初衷，antirez解释道，本地推理领域虽不乏优秀项目，但社区注意力常被层出不穷的新模型分散。通用引擎为兼容性引入的抽象层，往往以性能妥协为代价。他选择了一条截然不同的路径：一次只押注一个模型，用官方logits验证输出准确性，进行长上下文压力测试，并集成足够的Agent来确保其真正可用。

项目发布后，迅速有大量开发者反馈已在各自的Mac设备上成功运行。

一个模型对应一个推理框架的未来？

这一项目也引发了开发者社区的更深层讨论：未来是否会走向“一个模型，一个专用推理框架”的格局？

Hacker News上的一条高赞评论提出了一个方向：如果针对特定的“GPU硬件+模型”组合构建极度优化的推理引擎呢？在GPU成本日益高昂的背景下，若能剥离所有抽象层，直接为特定硬件和模型编写代码，或许能压榨出显著的性能提升。

当然，这条路径的代价同样明显。正如另一条评论所指出的，一旦模型迭代换代，所有工作都可能需要推倒重来。

antirez本人也承认了这一挑战。他表示ds4.c当前押注于DeepSeek V4 Flash，但模型总会更新。不变的前提是，要在高端个人电脑或Mac Studio上实现可靠的本地推理，128GB内存已成为起步门槛。

未来规划如何？README中埋下了一个伏笔。当前版本是Metal专属，未来或许会加入CUDA支持。但他的表述极为谨慎：“可能会支持，但也仅此而已。”这个项目将始终保持小巧、快速与高度专注的特性。

更值得关注的是他在README中阐述的一个核心理念：真正的本地推理解决方案，必须将三件事作为一个完整产品来打造：一个提供HTTP API的推理引擎、一份为该引擎特别优化的GGUF模型文件、一套与编码Agent无缝对接的测试验证流程。

这是一种全栈式本地推理的产品思维，而非简单的组件堆砌。

若此路可行，它可能重塑本地推理的生态。未来，模型厂商发布新模型时，社区中或许会同步涌现为其量身定制的专属引擎、量化方案与Agent接入套件。每一代明星模型都可能拥有自己的「antirez」。

ds4.c还有一个坦诚的细节。README中包含一段声明：该软件是在GPT-4的“强力辅助”下开发的，人类负责提供核心想法、进行测试与调试。antirez甚至直白地写道：“如果你无法接受由AI辅助开发的代码，那么这个软件不适合你。”

从最初fork llama.cpp进行适配，到最终决定从头编写专用引擎，两周的开发周期离不开AI的辅助。这件事本身，或许比ds4.c这个项目更具启示意义。

关于缔造者

最后，让我们聚焦于antirez本人。

本名Salvatore Sanfilippo，1977年出生于意大利西西里岛。2009年创造Redis，并主导这一项目长达十一年，直至2020年离开。

离开时他曾写道，自己编写代码是为了自我表达，代码是一种“创作产物”而不仅仅是实用工具。他宁愿被记住为一个蹩脚的艺术家，也不愿被记住为一个优秀的程序员。

2024年底，他以布道师的身份回归Redis。

除了Redis，他还创作了Kilo（一个不足千行的C语言文本编辑器）、dump1090（航空ADS-B信号解码器）、linenoise（readline的微型替代品）。他热衷于Flipper Zero，编写了RF协议分析工具，甚至将经典游戏《Asteroids》移植到该设备上。2022年，他出版了一本科幻小说《WOHPE》，探讨AI、气候变化、程序员以及人机交互等主题。

他个人主页的首行写道：“我将大部分专业时间用于编写代码和创作小说。”

关于Redis的起源，他在个人主页分享了一段轶事：“我妻子说，Redis头几年的代码，我大部分是坐在马桶上用一台11寸的MacBook Air完成的。我真希望她说错了，但不幸的是，她完全说对了。”

这种独特的个人风格贯穿了他的所有项目：精巧、精准、自成一格。ds4.c同样继承了这一血脉。

阅读ds4.c的README中关于macOS一个内核bug的备注，便能立刻感受到他的风格。ds4.c包含一条用于正确性验证的CPU推理路径，但当前版本的macOS在虚拟内存实现上存在一个bug，运行CPU推理会导致内核崩溃。他写道：“记住了吗？软件都很烂。我没法修复CPU推理路径来避免崩溃，因为每次崩溃都得重启电脑，这太无趣了。”随后补充道：“如果你有胆量，欢迎来帮忙解决。”

他在个人主页中的另一句话，或许能解释他对ds4.c这类项目的执着：“现代编程正变得复杂、乏味，充满了需要粘合的层次。它正在失去大部分美感。大多数程序员既未触及编程的艺术层面，也未触及高级工程层面。”

从Redis到ds4.c，十五年过去了，antirez似乎依然是那个antirez。

只是这一次，他开始为AI时代铺设基础设施的轨道。