文章目录01 什么是 Deltafin02 安装三条命令然后等两种模式对比从流式升级到完整模式03 使用方式命令行对话OpenAI 兼容 API 服务器几个重要的注意事项04 实际性能M1 Max 的真实表现05 为什么新款 Mac 应该更快06 工作原理怎么塞进 64GB 的07 技术亮点08 这不是产品这是存在性证明09 致谢与许可01 什么是 DeltafinDeltafin 是一个小型研究项目它做了一件看起来有点疯狂的事在一台 64GB 的 M1 Max 笔记本上跑起了 2.8T 参数的 Kimi K3 模型。目前的中位推理速度是0.0687 token/秒——也就是14.6 秒生成一个 token。换算一下大概每分钟能吐出 4 个 token足够你看着文字一个字一个字地往外蹦顺便泡杯茶。所有已发布的运行数据都来自同一台第一代 M1 Max不是更新的 Max 或 Ultra。项目设计上同一套引擎可以延伸到更新的 Apple Silicon Mac 上内存越大、带宽越高效果越好。02 安装三条命令然后等安装过程本身不复杂。三条命令然后你就可以开始生成了。唯一需要真正做决定的是第三步你要选哪种模式# 1. 环境 (Python 3.12, 以及 Xcode CLT) python3 -m venv venv ./venv/bin/pip install torch numpy safetensors tiktoken ml_dtypes blobfile \ transformers4.56.2 einops tokenizers # 2. 编译融合的 MXFP4 内核 clang -O3 -mcpunative -shared -DNO_MAIN -o tools/libmxfp4gemv.dylib tools/fused_gemv.c # 3. 下载模型看下面两种模式 ./venv/bin/python tools/setup_k3.py --full两种模式对比--full推荐--stream所需磁盘空间约 1.7 TB约 215 GB下载时间5–10 小时可断点续传约 30 分钟推理速度14.6 秒/token3 分钟以上/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--promptWhat are the three largest moons of Saturn?# 原始补全不带聊天模板跑满 16 个 token 后停止./venv/bin/python tools/kimi_run.py--promptThe capital of France is--max-new16Token 会边生成边打印你能实时看到文字出现。按 Ctrl-C 可随时中断并输出已生成的内容。一个诚实的提醒K3 在回答前会进行“思考”大约每分钟生成 4.1 个 token。一次完整的聊天回答可能需要一段时间——观看流式输出本身就是体验的一部分。OpenAI 兼容 API 服务器Deltafin 提供了标准的 OpenAI API 服务聊天界面、openai SDK、编程智能体都可以直接用只需要修改 base URL./venv/bin/python tools/serve_openai.py--port8000fromopenaiimportOpenAI clientOpenAI(base_urlhttp://127.0.0.1:8000/v1,api_keynone)rclient.chat.completions.create(modeldeltafin-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 Max10 核 CPU、32 核 GPU、64 GB 内存、内置 NVMe模型完整安装在本地采用 int8 驻留权重、Metal MoE、精确 fp32 计算、贪婪解码关闭追踪功能。指标首个可用版本当前 M1 Max 基准测试提升预填充 / 首个 token5 token 提示词2,429 秒28.0 秒中位数24.9–37.9 秒约 87 倍稳定解码专家本地化约 20 分钟/token0.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_PROFILE1的输出和芯片型号即可。06 工作原理怎么塞进 64GB 的K3 的权重总计约 1.56 TB远超这台机器的磁盘空间更不用说内存了。但混合专家模型有个特点每个 token 只触及自身的一小部分。常驻主干约 114 GBint8 后约 60 GB注意力层、共享专家、潜在投影、嵌入向量。一次性下载每个 token 从本地 NVMe 逐层读取在 GPU 上计算。82,432 个路由专家约 1.45 TB每个 tokenK3 的路由器为每层选取 16 个专家只读取这些专家。完整安装则全部存本地流式模式下按需从 Hugging Face 获取——每个专家一个 HTTP 范围请求存入不断增长的磁盘缓存。流程图示意 Hugging Face CDN (1.56 TB) → MacBook M1 Max ↓ 常驻主干 (60 GB int8) 专家缓存 (原始分片) ↓ 路由器: 每层选 16 个专家 ↓ 融合 MXFP4 GEMV 内核 ↓ 输出 token07 技术亮点以下每项技术都在真实权重上经过了测量验证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-attentionKDA 适配层的语义来源。llama.cpp / ggml内核内反量化的先例。Deltafin 自身代码采用 MIT 许可。Kimi K3 的权重和建模代码归月之暗面所有依据其自身许可分发。Deltafin 是独立项目与月之暗面无关联。这不是给普通用户的工具但如果你是个看到“1.7 TB 模型在 64GB 机器上跑起来”会眼睛发亮的硬件爱好者这可能是今年最值得玩的开源项目之一。