Kimi K3（2.8T 参数 MoE，1.45TB 专家权重）在一台 128GB 内存的 M5 Max MacBook Pro 上运行，专家权重从四块 SSD 流式加载。实测生成 512 个 token 的回答时稳定输出每秒 1.00 个 token；若提示为 512 个 token，首个 token 要约 6.3 分钟才出现，因为预填充要重复读取每层专家 8 次。只接一块盘时，速度约为四块盘同时读取的 52%，两块约 73%，三块约 90%，瓶颈是每层 16 次读取中最慢的一次。

Kimi K3（2.8T 参数 MoE，1.45 TB 专家权重）在一台 128GB 的 M5 Max MacBook Pro 上运行，专家从四块 SSD 流式读取。稳定解码速度：512 token 回答时 1.00 tok/s，128 token 时 1.13，公开 17-token 提示时 0.96（上游报 0.68）。诚实的极限：512-token 提示的首 token 约需 6.3 分钟，原因已找到（预填充每层专家重读 8 次），修复在计划中但未构建。有用发现：单盘速度约为四盘的 52%，双盘 73%，三盘 90%——节奏由每层 16 次读取中最慢的一次决定，而非总带宽。本仓库是 gavamedia/deltafin（MIT）的 fork，引擎由后者构建，存储与基准工具来自 ARGODRIVE。

ARGODRIVE Deltafin 基准测试 —— M5 Max，128 GB，专家从四块 SSD 流式读取

2026-09-08 用本 fork 的记录配置测量；每个数字都是确切提示下的单次冷启动，逐次运行日志见 k3-public-bench/results/。

| 测试 | 无草稿 | 有草稿 | | --- | --- | --- | | 稳定解码，生成 512 token | 0.9232 tok/s | 1.0015 tok/s | | 稳定解码，生成 128 token | 0.9261 | 1.1252 | | 17-token 提示（上游报 0.684），3 次中位数 | — | 0.9631 | | 首 token 时间，512-token 提示 | ≈376 s | ≈375 s |

同提示下的盘数阶梯：一块盘约四盘速度的 52%，双盘镜像约 73%，三盘约 90%。预填充慢的原因与修复见 PREFILL.md，定义与精度声明见 k3-public-bench/README.md。

在消费级硬件上以尽可能“快”的速度运行完整、未剪枝的 2.8 万亿参数 Kimi K3

Deltafin 是运行完整 Kimi K3 的单一原生二进制文件，不剪枝、不跳过，每个 token 都由 K3 决定。全部 16 个专家参与每个 token，没有捷径，与 Moonshot 发布的完全一致。质量规则很简单：K3 自己决定每个 token，别人无权。小型草稿模型可以提前猜测（主要速度来源），但 K3 检查每个猜测，未经它正式签字什么都不会到你手上。

M1 Max 笔记本上的上游基准（gavamedia/deltafin，未改动 —— 非本 fork 数字）

• 0.2901 token/s（3.447 s/token）—— 吞吐量比上次更新高 1.9%

上游历史 M1 基准：

• 0.2847 token/s（2026-08-02）—— 吞吐量高 7.0%
• 0.2660 token/s（2026-07-30）—— 高 102.9%
• 0.1311 token/s（2026-07-28）—— 高 829.8%
• 0.0141 token/s（2026-07-27）

使命声明

纯正原始未删减的 K3 质量，尽可能快。速度绝不可来自降低模型质量。Deltafin 保留所有 16 个路由专家和完整 K3 目标，作为每个 token 的唯一权威。目标是在运行 K3 这类巨模型时榨干每一滴效率，所有选项都考虑……除了降低质量。

可是为什么？！？

Deltafin 不是产品推销，而是消费者硬件能推多远的实验，以及从中能学到什么。Kimi K3 的目标基础设施是 16 节点和约 4.8 TB 聚合 VRAM，即完整 2.8T 参数和 1M token 上下文，专家库不剪枝。任何家用设置都是极端约束，每 1% 提升都很难，但每次增益都能教点东西。

研究和探索才是重点，那才是使命。不是所有东西都得是讨好 VC 的“最小可行产品”。如果 Deltafin 能让前沿模型在 $15,000 家用设置上可用，而非 Kimi 推荐的 $2,000,000 基础设施，这就是自托管 AI 之路上有价值的进步。沿途所学甚至可能意外惠及他处。

“我们选择本地运行完整 2.8 万亿参数模型，并做其他事，不是因为容易，而是因为难。”—— 大概是约翰·F·肯尼迪说的

其他项目似乎跑着完整 K3 且更快，但细看：他们把专家库重编码到约 3 bit。那是聪明工程但目标不同：最小且“足够接近”的 K3。那些权重已不是 Moonshot 发布的，也没人测过妥协的代价。Deltafin 是另一场实验：每个专家字节完全如 Moonshot 所发，以物理允许的极限加速。

1. 新安装

Deltafin 几乎安装所有需要的东西，缺啥见 Requirements。

1. 获取：git clone https://github.com/gavamedia/deltafin.git 然后 cd deltafin
2. 构建：cargo build --locked --release
3. 下载完整 1.7 TB K3 模型到磁盘（可选但最快）：./target/release/deltafin setup --full

若磁盘空间不足：

3. 流式使用 K3（较慢，但起步仅 215 GB）：./target/release/deltafin setup --stream

setup --stream 安装常驻模型并按需抓取精确专家，初始路由无本地缓存时极慢；随缓存积累可省空间，只存用到的部分，全从磁盘缓存跑。

默认 DSpark（与可选 Qwen）

正常设置包含 Inferact 的 Kimi-K3-DSpark，磁盘占 6.635 GiB，运行时约 4.49 GiB。Deltafin 避免具体化 DSpark 冗余的 K3 嵌入副本。Chat 和 server 请求在有利时自动用 DSpark；任何失败、余量不足或经济性差就退回完整 K3 独跑。

Qwen 是加速原始文本延续的单独插件：

4. 后续可选装 Qwen：./target/release/deltafin setup-qwen

Qwen 只加速原始 completion：小模型猜后继，K3 检查，相同输出更省时，利于代码补全和其他 /v1/completions 流量及 deltafin run --prompt ...——某次测过的 17-token completion 快了 2.7× 且输出 ID 相同。这加 4.337 GiB 磁盘，因 Qwen 不改善 chat 速度故设为可选，可在全新安装加 --include-qwen 或日后用上述命令补。

2. 升级

在 Deltafin 文件夹内：

./target/release/deltafin upgrade

upgrade 获取所需并重建二进制，模型、转换权重和缓存不动，绝不重跑 setup 或重下 K3。

注意：从旧 Python 版升级？先检查：

1. git status --short （仅当返回空时继续）
2. git pull --ff-only
3. cargo build --locked --release
4. ./target/release/deltafin upgrade

仅当 git status --short 为空时继续；若列了文件，自己保留或提交，别让升级程序乱猜。现有模型数据留在同仓库根目录。upgrade 需干净未分叉分支，且记得二进制原构建方式，故 NVIDIA/CUDA 构建会保持 CUDA 而非悄悄退回 CPU，任何意外都安全停止。upgrade 忽略构建环境变量，复用既建好的；要换配置（如 CPU 到 CUDA）需自己用新变量跑一次 cargo build --locked --release（见 Requirements），那会成为记录设置，日后升级延续。

3. 命令行使用

• Chat：套用 K3 审计过的聊天模板并在模型结束标记停。./target/release/deltafin run --chat --prompt "What are the three largest moons of Saturn?"
• 原始延续：因无聊天结束界需限长。./target/release/deltafin run --prompt "The capital of France is" --max-new 17
• 加累计吞吐和原生事务统计：./target/release/deltafin run --prompt "The largest planet in our solar system is" --max-new 17 --stats

无 --stats 时文本正常流出而非每 token 打印诊断行。--max-new N 限新 token 数，不改提示或上下文。Chat 输出在 K3 控制边界停，raw completion 通常需设界。长对话远慢于短 completion——预填充和缓存随历史增长，启动会打印实际可用上下文界限。

4. 通过 OpenAI 兼容服务器使用

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

curl http://127.0.0.1:8000/v1/chat/completions \ -H 'Content-Type: application/json' \ -d '{"model":"deltafin-kimi-k3","stream":true,"messages":[{"role":"user","content":"Hello!"}]}'

原生服务器实现 /v1/chat/completions、/v1/completions 和 /v1/models，含 SSE 流。将 OpenAI 兼容客户端指向 http://127.0.0.1:8000/v1 并用客户端要求的任意非空本地 API key。

服务器刻意实现小而严检的 OpenAI API 子集——纯文本、一次一代、总贪婪可复现——拒绝无法精确遵守的请求并返正常 OpenAI 形错误而非静默忽略。增长的聊天自动受益精确对话状态复用、草稿验证 DSpark 加速和精确响应 memo，细节见 SERVER.md。默认响应上限一百万 token，集成客户端时用 --max-tokens N 调低并升高客户端超时（因完整 K3 响应慢）。请求 JSON 受 --max-request-bytes 限（默认 128 MiB）。服务器留 loopback 除非自加认证和网络边界。

文档

• 原生运行时如何工作：单二进制进程内设计（Rust 核心、C-ABI 提供者、路由追踪、专家预取、原生分词）。
• OpenAI 兼容服务器参考：接受/拒绝的字段、自动聊天加速、精确响应 memo。
• 健康检查：只读无网审计，安装/升级/问题后验证运行时与各组件。
• 原生存储准备：默认 row-int8 常驻脊柱，显选原 BF16，打包进连续 DFSP 文件，无损 scale4 专家 sidecar。
• 性能参考：用基准工具复现测量及既定 M1 Max 参考结果。
• 配置：少量标志和环境变量及其质量守护。
• 支持平台：各主机类运行什么（MPS/Metal、CUDA、原生 CPU）及每平台证据状态。
• 开发参考材料：历史 tools/*.py 为何留作冻结参考（原生运行时从不执行）。

致谢

Deltafin 因他人发布的惊人工作而存在：

• Moonshot AI 发布 K3 权重、架构与可读模型语义。
• Inferact 发布不变的 K3 特定 DSpark 检查点；TorchSpec 文档其训练框架，vLLM 团队发 K3 集成与缓存研究。Deltafin 原生运行时、验证器、调度和状态事务是自己的。
• GigaToken（Marcel Rød）启发了自动稳定序并行分词路径。
• Maurice Brown (trumb) 在 PR #2 贡献 Linux、aarch64、x86 SIMD、NVIDIA 发现和 DGX Spark 测量，Deltafin 在审查能力和 ABI 门后保留。
• colibri 展示激进 MoE 流和路由前瞻；ds4 / DwarfStar 提供精确专家流、缓存所有权和正确优先测量的清晰先验。
• Qwen 提供可选 0.6B/1.7B 仅提议原始 completion 模型。
• flash-linear-attention、PyTorch、llama.cpp/ggml、tiktoken 及广泛本地模型社区提供必要语义与先验。 精确溯源与分发边界见第三方溯源与通知文档。

许可证

Deltafin 跟踪的项目代码为 MIT。Kimi K3 权重、DSpark 检查点、可选 Qwen 检查点及其他第三方材料保留上游条款。Deltafin 是独立项目，与 Moonshot AI 无关联。

有人把这台慢速巨兽比作《银河系漫游指南》里的 Deep Thought，也有人直接说这是“顶配自虐”：用三块 Thunderbolt 5 外置盘加内置 SSD，从磁盘流式读取约 1.45TB 专家权重，在一台 128GB MacBook Pro 上跑 2.78T 参数的 Kimi K3，稳定输出约 1 tok/s。讨论很快分成两个阵营：一边认为这是昂贵而无实用价值的工程奇观，另一边觉得“本地跑 2.8T”这件事本身就足以成为起点。作者自己也说重点不是数字，而是用埋点从读路径里挖出的四个缺陷——接不接受这句话，基本就是两派的分水岭。

单看速度，这只是昂贵又无用的自虐

• 这类评论不质疑工程是否真实，而是直接问“为什么”：1 tok/s 意味着一条像样的请求要以分钟、小时计，还要为这种“慢”付出昂贵的存储与调试成本，用途接近于零。（较多人） > 可为什么要做这个？不可能有用，还花了那么大代价把性能做到这么差。（@voidnullvalue）
• 有评论形容这是“顶级受虐”，也有人拿“跑个中等长度的输出差不多要用天来等”调侃；这些吐槽更多是表达对目标的困惑，不针对结果的真伪。

能在本地跑起 2.78T，本身就是从“不可能”到“可能”

• 反驳者强调：此前没有任何本地方案能装下 2.8T 模型，哪怕只是把专家权重按层从磁盘换入、每层仅激活 16/896 个专家，这条路也是第一次以可复现的数字跑通。（少数人，但作者自述明显是整帖主心骨） > 你本来就没法在本地跑 2.8T，没有任何别的办法。所以这是一个很好的开始。（@mandeepj）
• 这个视角下，1 tok/s 不是产品指标，而是锚点：它证明“模型大于内存”不一定等于“必须上云”，也给了后续优化一个可比较的起点。

这套手艺的真正适用对象，是 GLM Flash 这类小一号的 MoE

• 有评论提出一个反直觉的落点：与其让 Kimi K3 这种巨兽在磁盘上挣扎，不如把作者踩过的坑、写好的读路径工具搬到更轻量的开源 MoE 上；同样的磁盘流式方案在小模型上可能直接从“行为艺术”变成可用的本地推理。（少数人） > 这有意思的地方不在 Kimi，而在于把它用到 GLM Flash 这个级别的模型上。（@alex7o）

上下文一旦填到 200k 以上，这点吞吐会崩得更难看

• 有评论认为当前演示刻意避开真正的压力测试：17、128、512 token 的窗口都太短，一旦 prefill 拉长到几十万 token，首 token 延迟和后续衰减会把整个方案拖入不可用区间。（少数人，但和作者自认的最大瓶颈吻合） > 现在再想象一下，上下文填到 20 万以后，每秒 token 数会衰落到什么程度。（@walrus01）
• 作者自己给出的数字其实支持这种担忧：512 token 的 prompt 要等约 6.3 分钟才出第一个 token，prefill 读放大高达 6.2 倍——这正是他列出的头号待解问题。

README 写得再厚，也还是低信噪比的 slop

• 另一条战线不在技术层面，而在表达层面：有评论抱怨这类 README 读起来痛苦、信息密度低，甚至上升到对整个发布文化的批评——“不懂自己发布内容的项目，堆在另一个同样不懂自己发布内容的项目上面”。（较多人） > 我们正在加速进入二次方级的 slop：底层项目不知道自己在发什么，上层也不知道。（@nxtfari）
• 这类批评并不否认实验本身扎实，而是认为“发布了大量细节”不等于“交付了可理解的边界”；高信息量反而被低信噪比的包装淹没了。

有价值的补充

• 四个真正的提速都来自读路径缺陷，而不是模型压缩或缓存：把需求池与预取池从同一个 16 线程上限中拆开后，需求排队占阻塞时间的比例从 70% 降到 7.5%，性能 +14%；预取路径原本没有负载均衡，按固定目录序把所有流量压到同一台外置盘上，改为带在途计数的最小期望完成时间调度后 +11%；热门专家在两个设备上放双副本再切分读取是 +10%，而同一个开关在“每个专家只有一个家、无副本可切”的布局上曾连续六次测得负收益；还有一条被记成“定律”的结论，其实是针对某个已不存在的 drafter 测出来的，重测后 +8%。
• 作者特意保留了一份约千次失败实验的计时目录，包括 8–40GB 的 RAM 专家缓存（-4% 到 -48%）、单副本条带化（-7% 到 -25%）、两盘共享一条 Thunderbolt 链路（-11%）、注意力主干从 SSD 流式读取（-60%）、Metal 的文件加载 API（-19% 到 -22%）。他判断这部分“没有用的记录”对后来者最有价值。
• 盘数梯度很直观：同一布局在 1、2、3、4 块盘下，分别达到四盘解码率的 57%/78%/92%/100%。有评论追问更快存储（如二手 Optane）能否把这条曲线继续推高，目前仍是开放问题。
• 作者不声称与 BF16 版本位级一致：专家权重保持 MXFP4，注意力主干降到 int8，他只保证在记录用的 prompt 上与自己参考实现逐 token 一致，且在每次推进时都复检。
• 作者明确请求两类外部帮助：一是面向 MoE 的 expert-major prefill 调度——每层只把专家读一次，再对路由到它的所有行跑 kernel，理论上能把 prefill 读放大从 6.2x 降到约 1x；二是请人在其他硬件上复现他的盘数梯度结果。