上周末Redis 作者 antirez 开源了一个新项目ds4GitHub 地址是https://github.com/antirez/ds4。有意思的是虽然仓库名叫 ds4但 README 里它的名字是DwarfStar 4也就是“矮星 4”。这个名字倒是贴切它不像一个大而全的通用推理框架更像一个小而高密度的专用引擎把 DeepSeek V4 Flash、Metal / CUDA、KV Cache 和 Agent API 这些东西压进了一套实现里。ds4 是什么先解释一下 ds4 到底是什么。简单说它是一个面向DeepSeek V4 Flash的本地推理引擎。但它不是那种“给我一个 GGUF 模型文件我都尽量帮你跑起来”的通用工具。这里先解释下 GGUF 是什么。它是本地大模型生态里常见的一种模型文件格式很多开源模型都会被转换成.gguf文件方便在本地加载、量化和推理。而 GGUF runner就是读取.gguf模型文件并把模型跑起来的运行器llama.cpp 就是这类工具的代表。ds4 在 README 里特别强调自己不是通用 GGUF runner这说明它不打算支持任意 GGUF 模型只是围绕 DeepSeek V4 Flash 做专用实现包括模型加载、prompt 渲染、KV 状态管理以及面向 OpenAI / Anthropic 风格 API 的服务端适配。图注ds4 不是一个通用本地推理框架是针对 DeepSeek V4 Flash 做的专用推理引擎。表面上看它是在做“本地跑大模型”实际上 ds4 有意思的地方在于它把本地推理往 Agent 工作流这一层推进了一步。为什么是 DeepSeek V4 Flashds4 选择 DeepSeek V4 Flash不只是因为它是最近的热点。按照 antirez 在 README 中的说法DeepSeek V4 Flash 有几个特点MoE 模型推理时激活参数更少thinking 模式相对克制。如果不强行开启 max thinking它不会对所有问题都生成很长的思考内容而是随着问题复杂度调整思考长度这对本地推理很重要因为 thinking token 本身也会带来计算成本模型上下文窗口达到 100 万 tokenKV Cache 压缩程度较高在特殊 2-bit 量化下可以在 128GB RAM 的 MacBook 上运行。这些特点放在一起构成了 ds4 选择 DeepSeek V4 Flash 的原因。毕竟一个模型很大的话每次都要激活大量参数本地机器很难承受如果模型虽然能跑但每次都生成很长的 thinking 内容本地使用体验也会变差如果 KV Cache 占用过高长上下文和多轮 Agent 工作流也很难持续。所以ds4 不是想简单地做个“本地也能跑大模型”更想实现特定的模型结构、量化方式和上下文机制结合起来之后高端个人机器也可以承担一部分原本属于云端推理的工作。被放弃的通用性很多本地推理 Agent 项目会追求通用性支持更多模型、更多格式、更多硬件、更多后端。但 ds4 走的是反方向。它只支持 DeepSeek V4 Flash GGUF 文件不支持加载一个任意 GGUF 文件。README 里明确写到普通 DeepSeek/GGUF 文件不会具备它所期待的 tensor layout、量化组合、元数据和可选的 MTP 状态信息。这是一种很典型的工程取舍。通用框架的优势是覆盖面广生态更大专用引擎的优势是可以围绕一个模型、一类硬件和一种使用方式做更深的优化。ds4 就是后者先让一个模型在本地 Agent 场景里尽量跑得完整并不考虑把所有的模型都接进来。撇开 Redis 作者的明星光环这种取舍也解释了为什么它会引起关注。它不是又一个“模型加载器”只是在试图回答一个更具体的问题如果我们真的想把本地模型接进 coding agent、tool agent 或长期会话系统里推理引擎应该长什么样Agent 场景下的本地推理难点以前讨论本地推理大家最容易只关注几个指标模型能不能跑、速度多少 token/s、显存或内存占用多少、量化后质量掉了多少。这些当然重要但 Agent 场景会把问题变复杂。因为 Agent 客户端通常是无状态的。每次请求它都会把当前任务、系统提示词、历史消息、工具调用结果重新发给模型。对于普通聊天来说只是多传一点上下文但对于 coding agent 来说初始 prompt 可能就很长工具调用也会不断扩展上下文。README 里提到Claude Code 这类客户端初始化可能就会发送 2.5 万 token 左右的大 prompt。如果每一轮都从头 prefill成本会非常高。所以 ds4-server 做了一件很重要的事它会维护一份可变的后端 KV checkpoint。当前端客户端重复发送更长版本的同一段 prompt 时服务端可以复用共享前缀而不是每次都从第一个 token 开始重新处理。这就是 ds4 项目里很值得关注的Disk KV Cache。它不只在内存里保存当前会话还会把有用的前缀写到磁盘。这样即使切换会话或者重启服务后续请求也有机会复用之前保存过的 KV 状态。README 中明确地指出在 DeepSeek V4 Flash 这种压缩 KV Cache 和现代 MacBook 高速 SSD 的条件下KV Cache 不一定只能待在内存里它可以成为“磁盘上的一等公民”。图注ds4-server 会尝试复用请求中的共享 prompt 前缀当前会话依赖内存 checkpoint写入 Disk KV Cache 的前缀则可以在会话切换或服务重启后继续复用。这个点比“本地跑模型”更有工程含量。因为 Agent 真正消耗资源的地方不一定只在回答的生成阶段也在一次又一次长上下文 prefill 里。只要 Agent 还在持续调用工具、读取文件、修改代码、追加历史KV Cache 复用就会直接影响实际体验。工具调用和 KV Cache 复用ds4 另一个细节是它对工具调用格式做了比较细的处理。DeepSeek V4 Flash 生成工具调用时会使用 DSML 文本格式。但 OpenAI / Anthropic 风格的 Agent 客户端下一轮请求通常不会把原始 DSML 文本原样发回来只会发送标准化后的 JSON 工具调用对象。OpenAI / Anthropic 客户端 ↓ JSON 工具定义 / 工具调用历史 ↓ ds4-server 转成 DeepSeek 能理解的 DSML 文本 ↓ DeepSeek V4 Flash 生成 DSML tool call ↓ ds4-server 再转回 OpenAI / Anthropic 风格 tool call这会带来一个问题如果服务端把这些 JSON 对象重新渲染成 DSML 时哪怕只和模型原始生成的文本有一点差别token 前缀就可能对不上已有的 KV checkpoint 也就不能直接复用。ds4 的做法是记录 tool id 到原始 DSML block 的映射。下一轮客户端带着这个 tool id 回来时服务端优先复现模型当时生成过的原始 DSML而不是重新格式化一份“看起来等价”的文本。必要时它再退回到一套确定性的格式重建流程。这类细节很容易被忽略但它恰恰说明了 Agent 推理服务和普通聊天服务的区别。普通聊天里协议适配大多是输入输出格式的问题Agent 工作流里协议格式会进一步影响上下文复用、工具调用稳定性和服务恢复能力。换句话说推理引擎不再只是负责“把 token 算出来”还要理解上层工作流对状态一致性的要求。一套端到端的本地推理系统ds4 README 里有一句话很能概括它的目标本地推理不只要一个 engine还要三件事一起工作带 HTTP API 的推理引擎、按照 ds4 执行路径专门制作的 GGUF 文件以及面向 coding agent 的测试和验证。这其实也是 ds4 和很多本地模型项目的区别。它把重点从“模型文件 命令行运行”继续推进到更接近实际工作流的几个环节支持 OpenAI 风格的/v1/chat/completions支持 Anthropic 风格的/v1/messages处理 streaming、thinking、tool calls为 OpenCode、Pi、Claude Code 这类 Agent 客户端提供接入示例围绕长上下文和工具调用做 KV Cache 复用。README 中列出的 server endpoint 包括/v1/models、/v1/chat/completions、/v1/completions、/v1/messages并说明/v1/chat/completions会把工具 schema 渲染成 DeepSeek 的 DSML tool format生成后的 DSML tool call 也会映射回 OpenAI tool call。ds4 的性能ds4 README 也给出了一组性能数据。在 MacBook Pro M3 Max 128GB 上q2 量化短 prompt 的 prefill 是 58.52 t/s生成速度是 26.68 t/s在 Mac Studio M3 Ultra 512GB 上q4 量化短 prompt 的 prefill 是 78.95 t/s生成速度是 35.50 t/s。需要注意的是这些是 antirez 给出的单次 Metal CLI 测试结果配置是--ctx 32768、--nothink、greedy decoding、-n 256不能简单泛化成所有场景下的稳定性能。当然 ds4 真正有意思的地方并不是某一项 token/s 数字在于它把性能问题放回到了完整工作流里看prefill、生成速度、KV Cache、工具调用、服务重启、客户端协议这些都会影响本地 Agent 的实际可用性。但它还不是一个成熟产品这一点也需要说清楚。ds4 目前仍然是 alpha 状态。项目文档明确提醒代码和 GGUF 文件都应该被视为 alpha quality因为推理和 serving 本身很复杂而项目存在时间还很短要达到更稳定的形态还需要时间。它的硬件门槛也不低。README 中给出的模型下载建议是128GB RAM 机器使用 q2256GB 以上机器使用 q4如果使用完整 100 万 token 上下文还会额外带来明显内存占用。因此在 128GB 机器上更现实的配置是 100K 到 300K 上下文。另外当前优化图执行路径主要面向 macOS 上的 Metal 和 Linux 上的 CUDACPU 路径更多是给正确性检查、模型和 tokenizer 诊断、调试用的不是面向日常推理的主路径。总之它像是一个方向明确的工程实验在高端个人机器上把一个足够大的本地模型做成可以被 Agent 使用的端到端系统。从现阶段看它更适合作为一个观察窗口本地推理如果继续往 Agent 场景走会遇到哪些具体问题又可能形成哪些新的工程取舍。小小地延伸下ds4 会火当然有一些显性原因antirez 本身有很高的开发者关注度DeepSeek V4 Flash 又站在开源模型、本地推理、长上下文和 Agent 的交汇处。但只把它理解成“名人开源 DeepSeek 热度”还是有点浅了。它真正踩中的是开发者对本地 Agent 的一个长期期待当模型能力和个人硬件都继续往前走本地推理能不能不只是试玩还成为一套可工作的基础设施这种关注也已经开始外溢到周边项目。比如 Armin Ronacher 的 pi-ds4就是一个用于把 antirez/ds4 作为本地 DeepSeek V4 Flash 模型接入 Pi 的 provider extension。它会注册ds4/deepseek-v4-flash模型按需启动 ds4-server并维护运行状态目标是观察本地模型在实际 UX 和行为上的表现。这说明社区不是只在围观“能不能跑”也在尝试把它接进真实的 Agent 使用流程。小结ds4 的意义不在于证明“本地模型可以替代云端模型”。它更像是把本地推理的问题往前推了一步当模型开始接入工具、处理长上下文、服务 coding agent并在多轮任务里持续运行时推理引擎要解决的就不只是生成速度还包括状态管理、缓存机制、协议适配、工具调用以及任务中断后的恢复能力。所以ds4 值得关注的地方是它把一个更具体的工程问题摆到了台面上本地 Agent 推理也许需要一套不同于普通聊天模型的工程系统。