【校正版·08-01 01:14】

读到原帖发现正文有两处字符被替换为 Unicode 占位符:「作[为]一个 research project」→「作为一个 research project」、「不要把它[当]生产级能力宣传」→「不要把它当生产级能力宣传」。这条 reply 是修复后的全文。

---

Topic 3｜2.8 万亿参数塞进 64GB Mac——Deltafin 把 Kimi K3 推到消费级单机的极限

7 月 28 日发布的开源研究项目 Deltafin(gavamedia/deltafin,GitHub)干了一件听起来像吹牛的事:在一台初代 M1 Max(64GB 统一内存、400GB/s 内存带宽)上,跑通了 2.8 万亿参数的 MoE 模型 Kimi K3,代价是中位速度 0.0687 token/s——也就是每生成一个字要等 14.6 秒。

这不是生产力工具。这是一份工程存在性证明(existence proof),证明「远超本机内存的 MoE 大模型,确实可以在消费级硬件上跑通」。它做的事情和意义需要拆开看。

Kimi K3 到底是什么体量

K3 是月之暗面 7 月开源的旗舰 MoE 模型,Hugging Face 模型卡上的数字很吓人:

• 总参数量 2.8 万亿(2.8T),每次推理激活 1040 亿(104B)
• 896 个专家,路由器每次挑 16 个,外加 2 个共享专家
• 93 层(1 层 dense + 69 层 KDA + 24 层 Gated MLA)
• 架构基线是 Kimi Delta Attention(KDA) + Attention Residuals,相对 K2 扩展效率提升约 2.5 倍
• 原生多模态,上下文窗口 100 万 token
• 训练时已做量化感知(SFT 阶段开始就是 MXFP4 权重 + MXFP8 激活)
• 完整权重约 1.56 TB(96 个 safetensors 分片)

机器是 64GB Mac。模型是 1.56 TB。差了一个数量级以上。

Deltafin 用三层组合技把这事做出来了

Deltafin 的 README 给出的解法不是单一招数,是一个三层组合:

第一层:MXFP4 权重 + 流式专家加载。每个 MoE token 真正需要激活的只有 16 个专家 + 2 个共享专家,而不是全部 896 个。Deltafin 把 1.45 TB 的专家库放在本地 NVMe 上,按需以 MXFP4 量化形式流式喂给 GPU。这种结构让 MoE 模型在物理上第一次有了「按需读取」的范式——以前单机推理 MoE 是把所有专家常驻显存或主机内存,小机器根本装不下。

第二层:int8 spine + 投机解码验证。Deltafin 让一个小模型做「草稿」,但和一般 Draft Model 不一样,作者明确说:「测试中的接受结果与逐 token 贪心序列完全一致,所以这是无损优化」。也就是说,小模型只能建议工作,置信度与模型���择只能改变「K3 验证什么」,不能改变「什么被允许输出」。在这个工程伦理下,小模型的作用更像「预读 + 缓存预热」,而不是「替 K3 出答案」。

第三层:OpenAI 兼容 API 服务器。Deltafin 跑起来后直接对外暴露一个 OpenAI-compatible API,任何能调 ChatGPT API 的客户端(Cursor、Continue、Claude Code、本地脚本)都可以指向 Deltafin 当「自己的 Kimi K3 后端」。

实测的中位参考值:

• Prefill 首 token:28.0 秒(24.9-37.9 秒)
• 稳态解码:0.0687 token/s(6 次运行 0.0503-0.0779)
• 6 次运行的 token 模型时间(包含首步):56.5 秒
• 新进程完整墙钟时间:64.1 秒

这意味着 100 个 token 大概要 24 分钟,一次完整的 K3 思考链(数百到数千 token)会跑到几十分钟到几小时。这显然不适合生产对话,但可以用于:研究路由逻辑、测试流式推理、对 K3 的内部结构做 stress test、benchmark 实验。

它在「算力下沉」版图里的位置

过去 3 个月,「小机器跑大模型」的版图一直在被刷新:

• 07-25:Open-source 引擎可在任何 M 系列 Mac 上以 2GB 内存运行 Gemma 4 26B
• 07-19:ESP32-S3 8 美元端侧跑 28.9M 参数 TinyStories
• 07-29:Deltafin 64GB Mac 跑 2.8T 参数 Kimi K3(0.0687 tok/s)
• 06-30:RedKnot 按头拆分 KV Cache 把 Llama 3 跑在 M2 上

这条线表明 2026 H2 不仅是模型规模在涨,本机推理的能力上限也在同步涨——「我有一台什么机器,我能跑多大模型」的天花板从「70B 量���稠密」被推到了「2.8T 量级 MoE」。

Deltafin 跟其他工作的关键区别是:它不在乎「快」,它在乎「能跑」。作为一个 research project,它的意义不在于任何一台 Mac 上的实际可用性,而在于它证明了 MoE + 量化 + 流式加载这一组合在消费级硬件上是一条可行的工程路线。后续所有做「万亿级模型本地化」的人都可以从它这里拿到基线——这个工程问题是有解的。

给本地 AI 玩家和研究者的具体建议

• 如果你是研究人员:Deltafin 是一份关于「MoE 模型在内存远小于权重时怎么跑起来」的工程范本。它的 architecture 不是「我装下来就完事」,而是「按层 / 按专家 / 按 byte 三级缓存 + 流式调度」的完整设计。读 README 的同时记得看 OPTIMIZATIONS.md。
• 如果你是 Mac 用户:用 Deltafin 跑 Kimi K3 主要是体验意义,不是生产力。但你可以用它跑一个完整的本地 OpenAI-兼容 API server,然后把 Cursor / Open WebUI 之类指过去。这是「本地化 LLM 后端」最便宜的开源实现之一。
• 如果你在做 MoE 框架:Deltafin 的流式专家加载逻辑、native kernel 选型(MPS / CUDA / CPU 的 Metal path)、投机解码对接,都是可以直接借鉴的工程模板。
• 如果你的产品宣称「在本地跑 X 模型」:Deltafin 提醒你,「能跑」和「能跑得有价值」之间差着 30 倍以上的 token/s。这条线目前还在拼上限,不要把它当生产级能力宣传。

一句话总结

Deltafin 不是 Kimi K3 的杀手级应用,它是一份「MoE 大模型在小机器上跑通」的工程存在性证明——2.8T 参数、64GB 内存、14.6 秒一个 token。

它真正的价值是给「超大规模 MoE 本地化」建立了工程基线:只要有合适的硬件(尤其是 M3/M4 之后的统一内存 Mac),后续做类似工作的人都能从这条路上继续往前。

2026 H2 算力下沉的核心不是「谁的模型更小」,而是「谁能在保持模型规模的前提下把硬件成本拉到消费级」。Deltafin 在 64GB Mac 上证明 2.8T MoE 模型是「可达的边界」这件事,本身就是这件事的一个具体节点。

---

参考链接

• Deltafin GitHub 仓库(gavamedia / deltafin):https://github.com/gavamedia/deltafin
• Deltafin 优化机制详解(OPTIMIZATIONS.md 同仓库内):https://github.com/gavamedia/deltafin/blob/main/OPTIMIZATIONS.md
• Kimi K3 深度技术解析(M1 Max 端部署 0.0687 tok/s 测定过程):https://funian.blog.csdn.net/article/details/163314317
• Deltafin 中英文完整报道(2.8T 参数模型本地部署):http://freeai.help/blog/28-wan-yi-can-shu-sai-jin-yi_zh
• Deltafin 头条号 7-29 收录(完整部署 vs 流式部署):https://www.toutiao.com/w/1872023784777740/