📌 项目地址：antirez/ds4 | ⭐ 19,922 颗星 | 🔧 C | 📜 未标注
antirez（Redis 作者）的 GitHub 上出现了一个叫 ds4 的仓库，19,922 颗星，C 语言写的。项目名 DwarfStar，一个本地推理引擎。
先说清楚它不是什么：不是通用 GGUF 运行器。README 原话说它”deliberately narrow”——刻意做窄。只服务三个模型：DeepSeek V4 Flash（首要优化目标）、GLM 5.2，以及在大内存机器上的 DeepSeek V4 PRO。模型加载、prompt 渲染、工具调用、KV 状态、HTTP 服务器、编码代理，这些组件放在一起开发和测试。仓库里还带 GGUF、imatrix、质量和速度相关的工具与数据。
模型选择策略：随时换人
README 用了一个不太常见的词描述模型支持：”opportunistic”。项目跟随当前最适合本地机器尺寸的开源权重，主要瞄准 128 GB 笔记本和 512 GB 工作站。更好的模型出现，旧的直接移除。
这个策略对框架党来说很难接受——通用性被主动放弃，换来的是对少数模型的深度优化。但反过来看，llama.cpp 那类通用运行器要在几百种模型间保持兼容，很多优化做不了。
三个硬件后端
- Metal：主要目标，96 GB 以上内存的 Mac。内存不够的机器走 SSD 流式。
- NVIDIA CUDA：含多 GPU 系统和 DGX Spark。
- ROCm：Strix Halo 平台，比如 Framework Desktop。
清单里全是买得到的桌面设备，没有数据中心。
四个用法，其中一个商业价值很直接
第一，消费级硬件跑强模型。 MacBook、DGX Spark、Strix Halo 都在支持范围内。RAM 不够时 SSD 流式兜底，README 对速度的描述是”decent”。
第二，复活被 vLLM 淘汰的旧 GPU。 这是我认为最值钱的一条。vLLM 已不再支持 Ada Lovelace 架构跑新模型，ds4 支持。实测配置：8 张 L40S，多会话并发，聚合生成 120 t/s，prefill 2000 t/s。配合 ds4-server 对解码和生成的微批处理，一屋子旧卡可以变成公司内部的多用户 LLM 服务器。手里有闲置 L40S 的团队，这两个数字比 star 数有用得多。
第三，两台 Mac 做张量并行。 两台 MacBook M5 Max 或 M3 Ultra，通过 RDMA 互联，跑 4 bit 的 DeepSeek Flash 或 GLM 5.2。
第四，流水线并行堆内存。 多台系统串联，把内存加起来，跑更大的模型。
为什么现在做得成
README 的 Motivations 部分列了几条：
- 有能力的开源权重模型，现在高端个人机器装得下。
- DeepSeek V4 Flash/PRO 和 GLM 5.2 对激进的路由专家量化容忍度高。
- 压缩 KV 缓存加上快速本地 SSD，让长上下文变得实际。
第 3 条值得多说一句。长上下文最吃内存的就是 KV cache，缓存能压缩，直接决定 128 GB 机器能跑多长的上下文。SSD 流式则是内存不够时的另一层保险。
两份坦白
README 有一节叫”AI full disclosure”：开发过程有 GPT 5.5、5.6 和 Claude Fable 的深度辅助，人类负责想法、测试和调试。原话很直接——如果你不接受 AI 开发的代码，这个软件不适合你。开源项目把话说到这个程度的不多。
另一份坦白给了 llama.cpp 和 GGML。ds4.c 不链接 GGML，但 README 承认：它的存在依赖 llama.cpp 开辟的路径——内核、量化格式、GGUF 生态和积累下来的工程经验。antirez 向 Georgi Gerganov 和所有贡献者致谢。
换句话说，这不是在 GGML 上包一层，是重写的引擎，上游的知识被明确认账了。
我的判断
ds4 回答的问题很具体：当前最强的几个开源模型，怎么在桌上跑起来。答案不是通用框架，是只服务两三个模型的窄引擎，配上针对性量化、SSD 流式和多机并行。
两条参考依据。一是 19,922 颗星。二是 8×L40S 上 120 t/s 聚合生成、2000 t/s prefill 的实测数字。
不适合谁：想拿任意 GGUF 模型往里塞的人，这条路 README 已经堵死了。适合谁：有大内存 Mac、有闲置 L40S、或者正好在 Strix Halo 平台上的开发者。