Kimi K3 (2.8T) at 1 token/s on a MacBook Pro, streamed from four SSDs（Kimi K3 在 MacBook Pro 上以 1 token/s 从四块 SSD 流式推理）

📅 2026-09-08 | 🏷️ 工程 & Agent | ⭐ HN 276 分/152 评论
🔗 原文：https://github.com/argonautlabsai/deltafin
💬 HN 讨论：https://news.ycombinator.com/item?id=49616257

是什么

HN 276 分的推理工程实验：在 MacBook Pro 上运行总参数量 2.8T 的 Kimi K3，模型权重不驻留内存，而是从四块 SSD 组成的阵列实时流式读取，取得约 1 token/s 的生成速度。配套代码开源于 GitHub 仓库 argonautlabsai/deltafin，讨论区 152 条评论围绕这种"存储带宽换内存"路线的可行性与实用边界展开。

🔍 小白解读

先说几个词

• 参数量 2.8T：模型里可学习的"旋钮"有 2.8 万亿个。参数通常要全部装进内存/显存才能参与计算，2.8T 意味着光权重就可能需要数 TB 存储空间。
• 流式推理（Streaming Inference）：不把整个模型装进内存，用到哪部分权重就从硬盘读哪部分——像做菜时不把整个冰箱搬进厨房，而是要什么食材拿什么。
• SSD 阵列：多块固态硬盘并行工作，叠加读取带宽。瓶颈不再是"内存够不够"，而是"硬盘读得够不够快"。
• 1 token/s：每秒生成一个词元。作为参照，流畅对话一般需要每秒十几个 token 以上——所以这个速度能跑，但只适合不着急的场景。

这篇到底在说什么

打个比方：传统跑大模型像"先把整头象装进冰箱"，装不下就跑不了；这个实验改成"象站在门外，需要哪个部位就从门递哪个部位"。由于超大模型采用 MoE（混合专家）结构，每生成一个词元实际只激活很小一部分参数，理论上确实只需要读取被激活的那部分权重——这正是 SSD 流式路线成立的数学基础。代价是速度：受限于硬盘读取速度，本实验只达到 1 token/s。HN 评论区（152 条评论）的关注点集中在：这种玩法对硬件的要求（四块高速 SSD）、以及"速度慢但能本地跑超大模型"到底在什么场景有用。它的价值不在于替代云端 API，而在于证明了"跑得动超大模型"的最低硬件门槛又降了一档。

这跟普通人有什么关系

短期看这是极客玩具：没人愿意等一秒一个字。但它预示的方向是——未来高端笔记本/台式机可能不需要大显存，也能本地运行今天必须调用云端 API 的超大模型，对隐私敏感、网络受限的场景是实质性利好。

为什么值得架构师关注

• 推理资源模型刷新：MoE 架构下，"模型太大所以必须上 GPU 集群"的假设出现第三条路——NVMe 带宽成为新的容量规划维度，成本结构从"显存租金"部分转为"一次性存储硬件"。
• 适用边界清晰：1 token/s 决定了它只适合离线批处理、夜间任务、单文档深度分析等延迟不敏感场景；交互式场景仍需云端或量化小模型，选型时不要混淆。
• 数据安全架构选项：权重与推理全程本地，配合私有化部署，为"数据不出域"的强合规客户提供了一条新的部署形态。
• 观察信号：当 SSD 带宽增速持续快于内存容量增速，这类方案的经济性拐点值得纳入年度硬件采购评估。

核心内容

• 实验结果：Kimi K3（2.8T 参数）在 MacBook Pro 上以约 1 token/s 流式推理，权重从四块 SSD 实时读取、不常驻内存。
• 代码开源：GitHub 仓库 argonautlabsai/deltafin（原文链接即仓库地址）。
• 社区热度：HN 276 分/152 评论，是近 48h 推理工程方向讨论度最高的话题之一。
• 技术背景（公认常识）：MoE 模型每步只激活少量参数，使"按需从磁盘读取权重"在数学上可行；同类思路此前在 DeepSeek 本地部署实验中已被社区验证过。

行动建议

• 有边缘推理需求的团队：克隆 deltafin 仓库，用自有 SSD 配置复测吞吐，评估"离线批处理上本地超大模型"是否比 API 更划算。
• 基础设施团队：把 NVMe 读写带宽列入推理主机的采购指标，而不只看内存和显存。
• 交互式产品团队：了解即可——1 token/s 距离对话级体验有数量级差距，当前勿做生产选型。