Redis作者Salvatore Sanfilippo（antirez）展示了DwarfStar最新的本地推理进展：一台配备128GB统一内存的Mac，可以通过SSD流式读取运行DeepSeek V4.1 Flash，而不必让整套341GiB模型常驻内存。其核心做法是只在内存中缓存频繁使用的混合专家权重，缺失专家再从本地SSD读取；模型中的189GiB Engram查找表也按需访问。官方已有测试显示，M5 Max在缓存预热后约可生成13.4 Token／秒，但速度高度依赖SSD、专家缓存命中率、提示长度及思考模式。Sanfilippo同时指出，V4.1容易陷入不必要的长推理，近期更新只部分缓解；DwarfStar因此允许用户直接调整或关闭思考强度。这是一项很有实际价值的本地推理工程，但并不意味着普通128GB电脑已经能够无代价地运行完整前沿模型：下载量超过300GiB、冷启动和缓存失配仍会显著拖慢速度，量化后的能力也缺少覆盖真实任务的独立对比。
文章作者、来源：antirez
341GiB模型，为什么能在128GB内存中启动
DwarfStar此次运行的是DeepSeek V4.1 Flash的Q2量化版本。完整GGUF文件约341GiB，其中真正意义上的主模型权重约152GiB，另外约189GiB来自Engram表。
即使只计算152GiB主权重，它也超过了一台128GB Mac能够留给应用程序的可用内存。DwarfStar没有尝试把所有内容硬塞进内存，而是将稀疏混合专家模型的结构利用到了极致。
DeepSeek每生成一个Token时，只会调用全部专家中的一小部分。DwarfStar把常用专家保留在内存缓存中；路由器选中一个尚未缓存的专家时，再从GGUF文件读取相应权重。Engram表同样不会整体加载，而是根据当前输入读取所需行。官方因此要求使用高速本地SSD，并建议首次运行时让程序自动决定专家缓存大小。
这不是把341GiB“压缩成128GB”，而是把模型拆成常驻部分、缓存部分和按需读取部分。注意力权重、共享专家、运行图、激活值和KV Cache仍会占用内存；上下文越长，留给专家缓存的空间就越少。
SSD为什么没有慢到完全不可用
逐Token从SSD读取大量权重通常会非常慢，但混合专家模型具有一定的局部性：相近输入可能重复激活部分专家，缓存命中后便不需要再次读取。
在处理长提示词时，运行时还可以把多个Token对同一批权重的访问合并起来。相比每产生一个Token便随机读取一次，批量预填充更容易摊薄SSD延迟。因此，长提示词的预填充速度和逐Token生成速度不能混为一个数字。
官方历史测试中，一台128GB M5 Max运行DeepSeek V4.1 Flash Q2、在SSD流式缓存已经预热的情况下，生成速度约为13.4 Token／秒。另一项40.8 Token／秒的成绩来自512GB M3 Ultra、MXFP4权重全量驻留内存和2K提示词，不能拿来代表128GB流式运行。
Sanfilippo在新帖中将更新后的表现描述为“相当快”，但原帖没有附上可复现的完整硬件配置、SSD型号、缓存命中率和标准化测试表。因此，不能把“相当快”转换成一个适用于所有128GB Mac的固定速度。
DwarfStar自己的文档也明确提醒：模型能够启动，并不意味着它适合交互使用。生成阶段往往比提示词预填充更容易受缓存失配影响，正式下载数百GiB权重前，应该先用短生成任务验证实际速度。
“过度思考”是模型问题，不是SSD问题
Sanfilippo在原帖中专门提到，DeepSeek V4.1 Flash会出现过度思考：模型在不需要复杂推理的问题上仍生成很长的内部推理过程。这会增加首个正式答案前的等待时间，并消耗更多上下文。
他认为此前V4 Flash没有同样明显的问题，而V4.1的近期更新只进行了部分修复。
DwarfStar为此提供了显式思考强度控制。用户可以通过`--think-level`在1至100之间设置推理力度，设为0或使用`--nothink`则关闭思考；交互过程中也能调整。这比把所有等待都归咎于SSD更准确：一次响应缓慢，可能来自专家缓存失配，也可能只是模型自行生成了过长推理。
它不是另一个通用版Ollama
DwarfStar刻意没有追求兼容所有GGUF模型。它只支持少数经过专门适配的模型，包括DeepSeek V4／V4.1 Flash、部分DeepSeek Pro、GLM和Qwen版本。
每种模型都有自己的推理图、权重布局和下载文件；普通GGUF不一定能够直接加载。项目把模型加载、提示词模板、工具调用、KV状态、HTTP服务器和编程Agent放在一起测试，用较窄的兼容范围换取针对具体架构的优化。
目前Metal是主要目标；CUDA侧重点是DGX Spark，ROCm则支持Strix Halo等设备。DeepSeek V4.1的视觉输入仍主要限于Metal，其他后端及多机推理的成熟度也不完全一致。
这意味着安装体验不像下载一个模型后在Ollama中点击运行那么简单。Q2版本需要约341GiB磁盘空间；Q4约483GiB；MXFP4约467GiB，而且MXFP4下载与合并期间可能需要约935GiB可用空间。不同版本的文件、分词器和推理代码也不能随意互换。
真正的意义是扩大本地推理的硬件边界
DwarfStar展示的不是一种新的模型能力，而是一种更灵活的内存层级：统一内存保存核心权重和热点专家，SSD承担容量扩展，缓存策略把经常访问的数据留在更快的介质中。
这种路线尤其适合数据不能上传云端、模型使用频率不高，或者愿意以延迟换取本地控制权的场景。它也可能让多个本地Agent共享同一套大模型权重，而不必购买多张高端GPU。
但当前结果仍有三项重要限制。
第一，约13 Token／秒是特定硬件和缓存状态下的官方测试，不是所有128GB设备的保底性能。第二，Q2属于非常激进的低比特量化，项目尚未公布足够完整的BF16／FP8能力对比和真实编程任务成功率。第三，长上下文、多个并发Agent和频繁变化的工具输出都会挤占内存或降低缓存命中率，演示中的顺畅体验未必能直接延伸到持续数小时的代码任务。