Deltafin 在配备四个 SSD 的 MacBook Pro 上以每秒 1 个 token 的速度运行 Kimi K3（2.8T）

快速要点

Deltafin 从四个 SSD 流式传输未剪枝的 2.8 万亿参数 Kimi K3 模型，运行在 M1 Max MacBook Pro 上，达到约 每秒 1 个 token（稳态 0.29 个 token/s），同时不牺牲模型的专家路由或输出质量。

Deltafin 的功能

Deltafin 是一个单二进制 Rust 运行时，用于运行 完整且从未剪枝 的 Kimi K3 MoE 模型（2.78T 参数，约 1.45TB 的专家权重）。它按需从磁盘流式加载每个专家权重，同时将注意力主干保留在 int8 状态。该二进制文件强制要求 K3 本身决定每个 token；不允许使用任何草稿模型捷径来改变最终输出。

精确质量 – 与作者参考提示的输出完全一致。
无模型压缩 – 权重以发布的 MXFP4 精度使用；仅注意力主干为 int8，这在上游已被视为非比特精确。
流式架构 – 每个（层，专家）读取一个 17.5 MiB 的文件，通过 pread + F_NOCACHE 在四个 Thunderbolt 5 SSD 外接盒之间进行。

在 M1 Max MacBook Pro 上的基准测试结果

指标	值	解释
稳态解码速度	0.2901 token/s（3.447 s/token）	相比之前 0.2847 token/s 的版本略有提升（约 1.9% 更高）。
短时运行速度（128 token）	1.13 token/s	高于长期平均值，因为缓存已预热。
17 token 基准测试的中位速度	0.96 token/s	接近作者上游报告的参考值 0.684 token/s。
首个 token 生成时间（512 token 提示）	~6.3 分钟	预填充是主要开销；读取放大因子 ≈6.2×。

历史进展显示，通过存储路径优化（例如分离需求队列和预取队列、在设备间平衡读取）实现了快速提升。作者指出，四个特定修复共同贡献了约 43% 的总加速。

存储子系统的运作方式

四个 SSD 通过 Thunderbolt 5 外接盒连接；每个存储专家文件的子集。
读取路径：专用线程池（默认 16 个线程）发出 pread 调用并使用 F_NOCACHE，以避免操作系统页面缓存污染。
预取：原始实现按固定目录顺序遍历，导致所有读取集中在一个外接盒。Deltafin 现在将预取调度到 预计完成时间最晚 的设备，提升了并行性。
复制：热专家可在两个驱动器上复制；在副本间拆分读取可增加约 10% 吞吐量。
监控：配套的 ARGODRIVE 仓库提供每设备 10ms 读取监控和屏障追踪，记录每个专家由哪个驱动器提供。

安装与使用

1. 安装二进制文件

git clone https://github.com/gavamedia/deltafin.git
cd deltafin
cargo build --locked --release

2. 准备模型

完整驻留模型（最快）

./target/release/deltafin setup --full   # 下载约 1.7 TB 的权重

流式模式（更低磁盘占用）

./target/release/deltafin setup --stream   # 从约 215 GB 开始，按需获取专家

3. 运行提示

./target/release/deltafin run --chat \
  --prompt "What are the three largest moons of Saturn?"

添加 --stats 可查看每个 token 的耗时，或使用 --max-new N 限制生成的 token 数量。

4. 通过 OpenAI 兼容 API 提供服务

./target/release/deltafin serve --host 127.0.0.1 --port 8000

服务器实现了 /v1/chat/completions、/v1/completions 和 /v1/models，具备严格的输入验证和流式 SSE 输出。

可选的 Qwen 扩展

Deltafin 可加载一个小型 Qwen 模型（0.6B/1.7B），用于草稿原始续写。K3 随后验证草稿，使 17 token 完成的 速度提升 2.7 倍，同时保留完全相同的输出 ID。安装方式为：

./target/release/deltafin setup-qwen

这会增加约 4.3 GiB 的磁盘占用，但 不会加速聊天模式。

社区洞察（来自 Hacker News 评论）

对实用性持怀疑态度 – 多位评论者指出，6 分钟的预填充使系统不适合大多数实时使用场景。
对硬件的好奇 – 用户询问更快的 SSD（如 Intel Optane）是否能提升吞吐量；作者的测量已显示明显的 驱动器数量阶梯效应（增加驱动器时，吞吐量从 57% → 78% → 92% → 100% 的四驱动器速率）。
潜在扩展 – 有评论建议将该方法用于其他 MoE 模型，如 GLM-Flash，表明流式专家技术具有更广泛的相关性。
对 README 的批评 – 多位用户认为文档信息量低，但作者后来添加了详细的性能说明和失败配置清单，有助于他人复现结果。

作者仍需帮助的事项

专家主导的预填充调度 – 每层仅读取每个专家一次，并一次性处理所有路由行，可将 6.2× 的预填充放大降低至 1×。
跨硬件验证 – 确认观察到的驱动器阶梯缩放在非 Apple Silicon 平台上也成立。

为何这很重要

在消费级硬件上运行 2.8T 参数的 MoE 模型表明，以存储为中心的流式技术可以弥合前沿 AI 研究与个人计算可访问性之间的差距。尽管原始解码速度适中，但该实验揭示了具体的工程瓶颈（读取路径竞争、预取平衡、专家复制），这些对任何大规模 MoE 部署（无论是在服务器还是边缘设备上）都具有适用性。

许可与来源

Deltafin 代码：MIT 许可证。
Kimi K3 权重、DSpark 检查点以及可选的 Qwen 检查点保留其上游许可证。
该项目独立于 Moonshot AI，无任何企业关联。