MacBook Pro 上以每秒 1 个 token 运行 Kimi K3（2.8T），由四块 SSD 流式供给

原文 ↗ Hacker News 讨论 ↗

一位开发者已经设法在 MacBook Pro 上运行 Kimi K3 这一 2.8 万亿参数的 Mixture-of-Experts 模型，通过四块 SSD 流式读取约 1.45 TB 的专家权重，达到大约每秒 1 个 token，但在 512 token 提示词上首 token 需要等待约 6 分钟。该项目深入分析了磁盘带宽、读取调度和 Thunderbolt 限制如何影响性能，并记录了哪些优化有效、哪些会变差（例如 RAID-0 条带化和 RAM 缓存）。评论者则讨论了这种速度慢、受存储限制的方案在实际上的意义，以及它作为在本地、完全离线运行前沿规模模型的概念验证价值。

模型与性能

  • 2.78T 参数的 MoE（Kimi K3），约 1.45 TB 的专家权重，运行在配备 4 块 SSD 的 MacBook Pro M5 Max（128 GB）上。
  • 专家从磁盘流式读取；注意力“干线”（约 50 GB）以 int8 精度常驻统一内存。
  • 报告的解码速度：在 512 个 token 上约 1 token/s，在 128 个 token 上约 1.13 tok/s，且在各项测试中表现一致。
  • 由于沉重的 prefill I/O，512-token 提示词的首 token 时间约为 6.3 分钟。

I/O 架构与扩展性

  • 每个（层，专家）一个 17.5 MB 文件；每层每个 token 读取 16 个专家，并且必须等待最慢的一次读取完成。
  • 通过 Thunderbolt 5 机箱连接四块 SSD；仅使用内置 SSD 时，解码速率大约只有四盘方案的一半。
  • 实测“硬盘阶梯”：1/2/3/4 块盘 ≈ 四盘速度的 52% / 73–78% / 90–92% / 100%；盘数越多，收益递减。
  • 对 RAID0/条带化以及某些缓存策略进行了测量，结果发现它们会拖慢性能，主要因为同步屏障由最慢设备决定。

Prefill、上下文与工作负载匹配

  • Prefill 是主要瓶颈：当前调度会多次重新读取专家，导致对一个 1.4 TB 模型产生约 9 TB 的读取量。
  • 这使得“单 token 分类器”工作负载（长提示词、输出 1 个 token）在当前情况下反而是最差而不是最佳场景。
  • KV cache 每个 token 约增长 2.8 MiB；在 128 GB 内存和其他预留条件下，这套配置的上下文长度上限约为 4.4k tokens。
  • 一种提出的“expert-major” prefill（每层每个专家只读一次，并处理所有被路由到的行）可将放大系数从 6.2x 降至接近 1x。

用途与“为什么要费这个劲？”的争论

  • 怀疑者认为，以每秒 1 个 token、并且前置等待数分钟的方式运行，在交互式使用中既不现实也很昂贵。
  • 支持者则认为其价值在于：
    • 计划好的、无人值守的本地任务（报告、对账），此时延迟并不重要。
    • 证明前沿级模型确实可以在本地运行。
    • “因为它很难”而进行的黑客式实验，并且是走向更高效设计的一块垫脚石。

工具、方法与文档

  • 自定义仪表化（按设备读取监控、屏障追踪、配置断言）暴露了不明显的瓶颈；其中若干项修复带来了超过 8–14% 的收益。
  • 文档中提供了大量负面结果目录（缓存、条带化、干线流式读取、各种 API），作为警示性数据。
  • 一些评论者觉得 README 过于密集且“LLM 味”很重，更偏好简短的 TL;DR；也提到了对长篇、由 LLM 撰写的文档的反感。

硬件未来与模型设计想法

  • 讨论涉及 SSD 带宽限制（Thunderbolt/PCIe）、可能的桌面或基于 GPU 的方案，以及 ASIC 风格的推理芯片。
  • 争论未来模型是否应当更模块化，或在专家路由上更“粘性”，从而只需让少量权重常驻内存；当前 MoE 方法被认为主要是在节省计算，而不是节省内存。