01 什么是 Deltafin？

Deltafin 是一个小型研究项目，它做了一件看起来有点疯狂的事：在一台 64GB 的 M1 Max 笔记本上，跑起了 2.8T 参数的 Kimi K3 模型。

目前的中位推理速度是 0.0687 token/秒——也就是 14.6 秒生成一个 token。换算一下，大概每分钟能吐出 4 个 token，足够你看着文字一个字一个字地往外蹦，顺便泡杯茶。

所有已发布的运行数据都来自同一台第一代 M1 Max，不是更新的 Max 或 Ultra。项目设计上，同一套引擎可以延伸到更新的 Apple Silicon Mac 上，内存越大、带宽越高，效果越好。

02 安装：三条命令，然后等

安装过程本身不复杂。三条命令，然后你就可以开始生成了。

唯一需要真正做决定的是第三步：你要选哪种模式？

python3 -m venv venv
./venv/bin/pip install torch numpy safetensors tiktoken ml_dtypes blobfile \
    "transformers==4.56.2" einops tokenizers


clang -O3 -mcpu=native -shared -DNO_MAIN -o tools/libmxfp4gemv.dylib tools/fused_gemv.c


./venv/bin/python tools/setup_k3.py --full

两种模式对比

	`--full`（推荐）	`--stream`
所需磁盘空间	约 1.7 TB	约 215 GB
下载时间	5–10 小时，可断点续传	约 30 分钟
推理速度	14.6 秒/token	3 分钟以上/token
推理时网络需求	无	持续连接

为什么差这么多？

每个 token 需要读取 16 个专家 × 92 层 = 25.8 GB 的专家数据。从本地磁盘读大约需要 4 秒；通过网络读……那就是几分钟的事了。

如果运行 setup_k3.py 时不加任何标志，它会自动判断：磁盘空间够就选 --full，不够就回退到流式模式，并告诉你需要释放多少空间。

从流式升级到完整模式

流式模式是体验 Deltafin 的好方法，不用提前投入 1.7 TB 磁盘空间。想升级的时候，一条命令就行：

./venv/bin/python tools/fetch_experts_all.py          # 可断点续传，随时可跑
./venv/bin/python tools/fetch_experts_all.py --dry-run   # 先看看需要多少空间
./venv/bin/python tools/fetch_experts_all.py --layers 1-40   # 只下部分层也行

03 使用方式

命令行对话

./venv/bin/python tools/kimi_run.py --chat --prompt "What are the three largest moons of Saturn?"


./venv/bin/python tools/kimi_run.py --prompt "The capital of France is" --max-new 16

Token 会边生成边打印，你能实时看到文字出现。按 Ctrl-C 可随时中断并输出已生成的内容。

一个诚实的提醒：K3 在回答前会进行“思考”，大约每分钟生成 4.1 个 token。一次完整的聊天回答可能需要一段时间——观看流式输出本身就是体验的一部分。

OpenAI 兼容 API 服务器

Deltafin 提供了标准的 OpenAI API 服务，聊天界面、openai SDK、编程智能体都可以直接用，只需要修改 base URL：

./venv/bin/python tools/serve_openai.py --port 8000

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:8000/v1", api_key="none")
r = client.chat.completions.create(
    model="deltafin-kimi-k3",
    messages=[{"role": "user", "content": "Hello!"}])

print(r.choices[0].message.content)            # 回答
print(r.choices[0].message.reasoning_content)  # K3 的思考过程

已实现 /v1/chat/completions、/v1/completions 和 /v1/models 接口，流式传输也正常工作。

几个重要的注意事项

在把自动化工具指向这个服务器之前，有几个现实问题需要先知道：

时间：回答会在准备好时返回。请把客户端的超时时间设为小时级别，别设成秒级。
流式模式慢得多：一个聊天模板提示词至少 60 个 token，预填充阶段会触及每层的多个专家。如果缓存只填充了一部分，一次聊天请求可能需要数小时。完整安装的话，就只是正常的“慢速”推理。
仅支持贪婪解码：temperature 和 top_p 参数会被接收但忽略。一次只处理一个请求，第二个并发请求会收到 429 状态码。

04 实际性能：M1 Max 的真实表现

以下所有数据都来自一台 M1 Max（10 核 CPU、32 核 GPU、64 GB 内存、内置 NVMe），模型完整安装在本地，采用 int8 驻留权重、Metal MoE、精确 fp32 计算、贪婪解码，关闭追踪功能。

指标	首个可用版本	当前 M1 Max 基准测试	提升
预填充 / 首个 token（5 token 提示词）	2,429 秒	28.0 秒中位数（24.9–37.9 秒）	约 87 倍
稳定解码，专家本地化	约 20 分钟/token	0.0687 token/秒（14.6 秒/token）	约 82 倍
解码，专家流式传输	约 20 分钟/token	约 3 分钟/token	受网络限制

中位数约为每分钟 4.1 个 token。一个典型的 M1 Max 性能画像：

环节	耗时
等待驻留主干读取（53 GB）	约 5 秒
读取每层选定的 16 个专家（25.8 GB）	约 4.3 秒
应用主干（传输 + 反量化）	约 3 秒
注意力机制与归一化（93 层）	约 2 秒
MoE 专家矩阵乘法	约 1 秒

解码阶段现在受限于驻留主干的磁盘带宽。这 53 GB 数据每个 token 都要重新读取，在约 7 GB/s 的速率下，这就占掉了 14.6 秒中的 7.5 秒。

除非有更多 RAM（足以容纳主干而不挤占专家读取所需的页缓存），或者采用更小的主干，否则这个瓶颈无法消除。

05 为什么新款 Mac 应该更快

M1 Max 只是一个保守的参考点。后续 Mac 机型在多个维度上都更强：

内存带宽：M1 Max 为 400 GB/s。M3/M4 Max 显著更高，Ultra 型号大致翻倍。
GPU：更多核心能更快执行 Metal 内核。
SSD：专家读取是最大的单一环节，后续机型配备更快的 NVMe。
内存容量：这是最重要的因素。53GB 的主干模型无法放入 64GB 机器，每个 token 都要从磁盘重新读取。在 128GB 机器上，它可以留在页面缓存中，这部分开销基本消失。

如果你在 M3、M4、M5 或 Ultra 芯片、128GB 及以上内存的机器上尝试，项目非常希望看到你的数据——提交一个 issue，附上 K3_PROFILE=1 的输出和芯片型号即可。

06 工作原理：怎么塞进 64GB 的？

K3 的权重总计约 1.56 TB，远超这台机器的磁盘空间，更不用说内存了。

但混合专家模型有个特点：每个 token 只触及自身的一小部分。

常驻主干（约 114 GB，int8 后约 60 GB）：注意力层、共享专家、潜在投影、嵌入向量。一次性下载，每个 token 从本地 NVMe 逐层读取，在 GPU 上计算。
82,432 个路由专家（约 1.45 TB）：每个 token，K3 的路由器为每层选取 16 个专家，只读取这些专家。完整安装则全部存本地；流式模式下按需从 Hugging Face 获取——每个专家一个 HTTP 范围请求，存入不断增长的磁盘缓存。

流程图示意：

Hugging Face CDN (1.56 TB)  →  MacBook M1 Max
                                    ↓
                            常驻主干 (60 GB int8)
                            专家缓存 (原始分片)
                                    ↓
                            路由器：每层选 16 个专家
                                    ↓
                            融合 MXFP4 GEMV 内核
                                    ↓
                            输出 token

07 技术亮点

以下每项技术都在真实权重上经过了测量验证：

I/O 与流式处理

合并专家数据获取：每个专家六个张量在分片文件中恰好连续，一次 17.55 MB 的范围请求搞定，比逐个获取快约 6.4 倍。
原始字节磁盘缓存：直接存分片的原始字节，无容器格式，无解析开销。
并行专家读取：16 个专家用线程池并行读取，实测从缺页中断的 0.87 GB/s 提升到 6.85 GB/s。
双层缓冲加载：当前层计算时，后台同时读取下一层主干数据。
前序 token 预取：连续 token 约有 31% 的专家选择会重复，后台预先获取。

计算

融合 MXFP4 反量化与 GEMV：一个 NEON 内核，一次性完成反量化与乘法，取代了原先慢得多的“先反量化再矩阵乘”路径。
模板层缓冲区复用：69 个 KDA 层共享张量形状，24 个 MLA 层共享另一组，避免频繁内存分配。
int8 驻留主干：每 token 驻留 I/O 减半，质量无明显变化。
自定义 Metal 反量化内核：融合 int8→fp32 转换、行缩放和拷贝，每层加载从 118 毫秒降至 21 毫秒。

解码

N-gram 推测：草稿通过对已生成文本的后缀匹配获得，在双位置批次中验证。被接受的草稿精确复现参考序列，回滚操作在常数时间内恢复状态，无需克隆约 475 MB 数据。

08 这不是产品，这是存在性证明

需要明确：这是一个研究原型，不是实用的聊天配置。

14.6 秒一个 token 的速度距离交互式体验还很遥远，长提示词成本高昂——预填充阶段会触及许多专家。

它的价值在于存在性证明：一台笔记本理论上可以跑通 2.8T 参数的模型。它也是流式推理技术的一个有趣的测试平台。

输出是贪婪且可复现的——相同的提示词每次运行都产生相同的 token。

比如：

“法国的首都是 → 巴黎。埃菲尔铁塔位于巴黎。卢浮宫博物馆也在巴黎……”

09 致谢与许可

Deltafin 大量借鉴了公开发布的研究成果：

colibri：展示了 744B MoE 模型可在 25GB 内存中运行，贡献了路由器预取、专家固定、F_NOCACHE 策略等关键技术。
ds4 / DwarfStar：最清晰的专家流式传输设计，零拷贝专家缓冲区、掩码分发、质量评估方法。
月之暗面：公开了 K3 的权重和可读的建模代码。
flash-linear-attention：KDA 适配层的语义来源。
llama.cpp / ggml：内核内反量化的先例。

Deltafin 自身代码采用 MIT 许可。Kimi K3 的权重和建模代码归月之暗面所有，依据其自身许可分发。Deltafin 是独立项目，与月之暗面无关联。

这不是给普通用户的工具，但如果你是个看到“1.7 TB 模型在 64GB 机器上跑起来”会眼睛发亮的硬件爱好者，这可能是今年最值得玩的开源项目之一。

在 M1 Max 上跑 2.8T 参数的 Kimi K3:14.6 秒一个 token，但真的能跑