上周末，Redis 作者 antirez 开源了一个新项目：ds4，GitHub 地址是：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 Flash
ds4 选择 DeepSeek V4 Flash，不只是因为它是最近的热点。
按照 antirez 在 README 中的说法，DeepSeek V4 Flash 有几个特点：MoE 模型，推理时激活参数更少；thinking 模式相对克制。如果不强行开启 max thinking，它不会对所有问题都生成很长的思考内容，而是随着问题复杂度调整思考长度，这对本地推理很重要，因为 thinking token 本身也会带来计算成本；模型上下文窗口达到 100 万 token；KV 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 机器使用 q2，256GB 以上机器使用 q4；如果使用完整 100 万 token 上下文，还会额外带来明显内存占用。因此在 128GB 机器上，更现实的配置是 100K 到 300K 上下文。
另外，当前优化图执行路径主要面向 macOS 上的 Metal 和 Linux 上的 CUDA；CPU 路径更多是给正确性检查、模型和 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 推理，也许需要一套不同于普通聊天模型的工程系统。
