你想在自己的电脑上运行大模型，通常会先找一套“什么都能跑”的软件。它像一把功能齐全的瑞士军刀，兼容许多模型和机器，但也要背着大量你根本用不到的代码。DwarfStar（ds4）反过来做：只挑少数模型和硬件认真优化，用较窄的适用范围换取本地推理效率。项目单日新增 211 星，更值得注意的是，社区很快又做出了一个只服务 Qwen 的精简版本。
这里的推理引擎，是负责加载模型、安排硬件计算并生成回答的软件层。本文涉及的性能与兼容性数据，大多来自项目作者或第三方分支作者的自测，尚缺少统一的独立复现。
它主动不做万能工具
DwarfStar 明确说自己不是通用 GGUF runner。GGUF 是本地运行大模型时常见的权重文件格式；但 ds4 只接受项目自己制作和提供的 GGUF 文件。它重点覆盖 DeepSeek、GLM 和 Qwen 的若干型号，包括 DeepSeek V4 Flash、DeepSeek V4.1 Flash、DeepSeek V4 PRO、GLM 5.2/5.3、GLM 5.3 Flash，以及 Qwen3.8 Flash Next。
硬件路线却横跨三套生态：Metal、CUDA 和 ROCm——分别让程序调用 Apple、NVIDIA 和 AMD 的 GPU。官方以 Metal 为主要目标，建议使用内存不少于 96 GB 的 Mac；内存较小或模型更大时，可以借助 SSD streaming，把暂时不用的数据放在固态硬盘，需要时再读入。
项目也支持多 GPU CUDA。官方称，八张 L40S、同时运行 16 个会话时，DeepSeek V4 Flash 的总生成速度约为 126 token/s。这个数字是所有会话相加的吞吐量，不能理解成单个聊天窗口也有同样速度。两台 128 GB Mac 还可通过 RDMA 和 tensor parallelism 协作：前者是机器间高速传输数据的方式，后者把同一次模型计算拆到多台机器上。官方称，这套配置可运行 4-bit DeepSeek Flash 或 GLM 5.3 Flash。另一种 pipeline parallelism 则像流水线一样分段计算，并汇集多台系统的内存来容纳更大的模型。
专用之后，还能再专用
一位社区开发者把 ds4 进一步裁成只面向 Qwen3.8 Flash Next 和 Metal 的分支，将约 8.5 万行的 ds4.c 缩到约 4.5 万行。动机不只是让人更容易阅读：coding agent——能自行阅读和修改代码的编程模型——每次也不必先消化与当前机器无关的 CUDA、ROCm、DeepSeek 和 GLM 路径。
据该分支作者在 Reddit 公布的自测，M5 Max 128 GB 上，Q2 配置的 decode（逐个生成新 token）快了 9%至13%，启用 MTP 后从 75.8 升至 86.7 token/s；Q4 的 prefill（先处理整段输入）提高 2%至11%，MTP 从 77.8 升至 85.9 token/s。Q2、Q4 是不同压缩程度的量化配置；MTP 则是一种加速生成的设置。
作者还称，优化前后保持逐步 bit-exact output，也就是每一步输出在比特层面完全一致。他用指定 GGUF、贪心解码得到的相同 token，以及交错 A/B 测试检查回归。这只能证明其指定模型、量化和测试路径，不能外推到 ds4 的全部模型与后端。
真正有意思的是开发方式
我们 10 月 5 日报道过 Kyojin、gufo 等专用引擎。DwarfStar 延续了“少支持一些，集中优化”的路线，又把范围铺到三套 GPU 软件栈；社区分支则继续缩窄到单一模型和主要后端。
这种结构也呼应了作者 Salvatore Sanfilippo 对开源协作的设想。据 DwarfStar 项目说明，代码由人负责想法、测试和调试，coding agent 大量参与实现；上游提供常见硬件的可用“轨道”，特殊配置则交给用户和 agent 现场修改。第三方 Qwen 分支正是一次早期演示：通用性不再只由主项目承担，派生版本可以围绕一台机器和一个模型继续削减。
局限与未知
- DwarfStar 仍是快速变化的 beta 项目，官方明确提醒可能出现不稳定和性能回退。
- 模型支持是机会式的，较好的替代品出现后，旧模型可能被移除，因此当前清单不是长期兼容承诺。
- 第三方分支的提速和模拟 48 GB 环境结果均为作者自测；后者不是一台真实 48 GB 机器上的实测，也不能代表官方 ds4 的整体性能。