每秒 0.5 个 token——点一杯咖啡的时间，它刚读完一个词。但这是 2.78 万亿参数、982GB 的完整模型，跑在一台 64GB 内存的笔记本上，没有蒸馏、没有剪枝、没有阉割。
上周 Kimi K3 权重开源时，1.56TB 的体积让所有人默认了一件事：这种怪物是数据中心的玩具。结果一周不到，一个叫 WASTE 的开源引擎就把这个前提掀了——它把 K3 转成 982GB 的容器，用 29.05GB 内存就能打开模型，在 64GB MacBook 上跑出 0.49–0.54 tok/s。
HN 上 155 分、61 条评论，一半人在算电费，一半人在问"每秒半个字能干嘛"。但真正值得看的不是速度，而是这件事背后的三个事实：
- 经验一：MoE 模型的重量不在内存里，在磁盘上。 K3 每生成一个 token 只激活约 4% 的专家权重，其余 96% 是"闲置重量"——不需要在内存里，只需要"来得及读取"。
- 经验二：存储速度不是细节，它就是性能本身。 一个 token 要读 17GB 的专家数据：内部 NVMe 上 12.78 GB/s 流畅运行，换 USB 硬盘盒变 0.94 GB/s，同一个 token 要 13 秒。
- 经验三：“跑得起来"和"用得上"之间，隔着一条工程鸿沟。 29GB 只是打开模型的下限，真实流畅运行需要 64GB 和一块 TB 级 NVMe——这不是魔法，是一系列精确到字节的工程决策。
〇、元问题：万亿参数模型的"可及性”，到底卡在哪？
过去三年，大模型本地运行有一个默认心智模型：模型多大，就要多大的内存。 70B 模型要 140GB 显存，405B 要 800GB，2.78T 的 K3 按这个逻辑需要 5.6TB——消费级硬件想都别想。
这个心智模型把"能不能跑"变成了一个纯粹的钱的问题：你买不起内存，就买不起模型。云端 API 因此成了唯一通道，而云端意味着数据出境、按 token 计费、离线不可用。
WASTE 的价值在于它拆掉了这个心智模型的核心假设。MoE（混合专家）模型的绝大多数权重，在任何一个瞬间都是闲置的。 K3 有 92 层、每层 16 个专家被激活，总共约 4% 的参数参与单个 token 的计算。那么问题就变了：
不是"内存里能不能装下全部权重"，而是"磁盘上的权重能不能在需要时及时读进来"。
这就是 WASTE 名字的由来——“Weight-Aware Streaming Tensor Engine”。它把万亿参数模型的运行问题，从内存容量问题重构成了存储带宽问题。 后者是工程问题，而工程问题是可以被解决的。
一、背景：K3 开源的第二天，就有人想把它搬下云
Kimi K3 的发布本身就带着矛盾：2.78 万亿参数、1.56TB 原始权重、1M 上下文，开源了，但"大企业"不能商用。这个体量注定它与消费级硬件无缘——至少在 WASTE 出现之前是这样。
WASTE 的作者是 marcobambini（Gravity 编程语言的作者）。他在 HN 上解释动机时说得很直白：云上生成的每个 token 都被付了两次钱——一次在账单上，一次在数据中心的电费里。 而一台 64GB 的笔记本，其实"勉强但真实地"装得下这个模型。WASTE 就是终结这种浪费的第一步。
项目的要求清单相当硬核：
| 资源 | 要求 |
|---|---|
| 模型磁盘 | 982GB 转换后容器（原始 1.42TB，转换后释放） |
| 内存下限 | 29.05GB（4K 上下文，低于此拒绝启动） |
| 实测内存 | 64GB（46GB 预算 + 17.56GB 专家缓存） |
| 存储 | 必须内部 NVMe（USB 外接 = 每个 token 13 秒） |
| 运行时依赖 | 零——纯 C，无 BLAS、无 CUDA、无 Python |
注意那个"内存下限"：29GB 只是打开模型的门槛，不是流畅运行的门槛。 32GB 机器能打开但会疯狂换页，作者明说"把 64GB 当成真实需求"。这跟标题里那个抓眼的 29GB 之间，是工程诚实和营销话术的距离。
二、怎么做到的：把"读得够快"变成"装得下"
决策一：专家按需流式读取，一次 pread 一个专家
模型被转换成 .waste 容器：一个 JSON 清单 + 常驻内存的 trunk（27.28GB，4/8bit 量化）+ 每层一个专家库（expert bank）。
关键布局：每个专家记录按 4KiB 对齐，gate、up、down 矩阵物理相邻——路由到一个专家恰好需要一次 pread 系统调用，不是三次、不是每次矩阵一次寻址。作者原话：“算术从来不是瓶颈。”
读取还故意绕过了页缓存（macOS 用 F_NOCACHE，Linux 用 O_DIRECT）：容器小于内存时内核会缓存一切，但 982GB 的模型没法缓存，用页缓存测出的命中率是假象，一接触真实模型就崩。
决策二：专家权重压到 3bit，且只有专家压
专家权重用残差向量量化（RVQ）：3 级 256 码本、8 维向量，每个权重仅 3.00 bit，矩阵从不物化。每个 token，引擎先构建一张"部分点积表"（每个码本条目 × 每个向量位置），之后每个专家行就是三次查表加两次加法。
trunk 保持 4/8bit——因为 K3 训练时就只对专家做了量化感知训练，trunk 没有压缩容错。作者真做了一版 3bit trunk 实测：缓存预测成立、吞吐没涨、输出直接崩了。这个"试了才知道不行"的细节，比结果本身更值钱。
决策三：缓存下限 = 一个 token 的工作集
这是全项目"最能预测的数字"：K3 每个 token 在 92 层里触碰 16 个专家，合计 17.0GB。 缓存低于这个数，一个专家刚缓存进来、下个 token 就用不上它了——命中率不是低，是零。
高于这个阈值后曲线急剧拐弯，但有个反直觉陷阱：
| 内存预算 | 专家缓存 | 命中率 | 解码速度 |
|---|---|---|---|
| 32GB | 3.32GB | 0% | 0.31 tok/s |
| 46GB | 17.32GB | 13% | 0.32 tok/s* |
| 52GB | 23.32GB | 27% | 0.11–0.14 tok/s |
| 58GB | 29.32GB | 37% | 0.04 tok/s |
*46GB 行加上预读优化后现在实测 0.51 tok/s。
52GB 和 58GB 反而更慢？ 因为这两个配置把机器打进了换页地狱，而且"机器不会完全恢复"——按 46→52→58 顺序扫完后，再跑 46GB 只剩 0.22–0.25 tok/s，尽管命中率数字一模一样。引擎是确定性的，机器不是。 作者的建议：从低往高扫（sweep upward）。
三、结果与数据：它到底有多"真"？
这是最容易怀疑的部分——一个把 2.78T 模型塞进笔记本的引擎，正确性靠谱吗？作者给出的验证：
- 每一层都对照 PyTorch 参考实现验证
- 最终 logits 与参考一致到 3.6e-06
- 视觉塔（vision tower）与自身 oracle 一致到 2.3e-06
- 转换格式和引擎不绑定 K3：“能在 2.78T 上流式运行的东西，在 48B 上跑得毫不费力”
配套还给了个试玩路径：Kimi-Linear-48B-A3B 只要 19GB 容器、1.87GB 内存下限、10.7 tok/s——想体验 WASTE 不用先捐一个 TB 硬盘。
至于成本账，评论区有人算过了：按 42W 持续功耗、20¢/kWh，大约 $5/百万 token，不含硬件。对比 GPU 集群约 80k tok/Wh 的能效，这台笔记本的能耗比差 1000–2000 倍——这就是把模型搬下云的物理代价，没有任何工程能消除它。
四、评论区的两场争论：有用吗？谁写的？
争论一：每秒半个字，能干嘛？
大部分质疑都指向实用性。最诚实的计算：按这个速度，1M token 的输出要跑 23 天；就算异步用，出一个答案也要等 30 秒到半小时。有人建议"用邮件方式跟它沟通"——把问题发过去，过一阵子回来收答案。这确实不是给实时交互用的。
但换个角度：有些场景从来不需要实时。 数据不能出境的公司（医疗、金融、政务）、需要在自己机器上跑完整模型的合规场景、“不联网也能有前沿模型"的离线环境——对它们来说，0.5 tok/s 的完整 K3 比 100 tok/s 的阉割版有价值得多。WASTE 的卖点不是速度，是**“你不得把这些数据发给 API"和"就在这儿跑"之间的那道分界线被抹掉了。**
争论二：README 是 AI 写的？
HN 顶楼评论直言"这 README 全是 LLM 写作的味道”，连 git 提交都署着 claude 的名。作者大方承认在用 agent 写代码：“我用技能编排 LLM 和 agent，写得更快更好。“评论区吵成一团：有人觉得欺骗，有人觉得诚实（simonw：“Claude 写的提交信息比大多数人好”），有人只求"至少自己读一遍 README”。
这件事本身就是一个时代注脚：一个由 AI 写的项目，在跑一个由 AI 写的推理引擎，而这个引擎让 AI 模型能在你的笔记本上运行。 工具链的自我指涉，快得让人来不及反应。
五、总结：它改变的不是速度，是可能性
| 决策 | 回答的根本问题 |
|---|---|
| 专家按需流式读取 | 闲置权重需要待在内存里吗？→ 不需要，只需要来得及读 |
| 一次 pread 一个专家 | 如何让磁盘读取不成为瓶颈？→ 布局决定速度 |
| 3bit RVQ 只压专家 | 哪些权重能压？→ 只有训练时压过的能压 |
| 绕过页缓存 | 怎么让测量结果在 982GB 模型上依然成立？→ 拒绝假象 |
| 缓存下限 17GB | 缓存该多大？→ 至少一个 token 的工作集 |
WASTE 真正改变的是"万亿参数模型"这个词的默认联想。 以前它等于数据中心、等于按 token 计费的 API、等于数据必须出境；现在它多了一个选项——一台 64GB 的笔记本、一块 TB 级 NVMe、每秒半个字，但模型是你的、数据是你的、电费单也是你的。
每秒 0.5 个 token 当然不是终点。但**“在消费级硬件上跑前沿模型"从不可能变成了慢**——而"慢"是比"不可能"好得多的起点。
🤖 如果你在关注大模型本地部署——
- 你的业务里有没有"数据不能出机器"的场景？WASTE 证明了这条路不是死路。
- 0.5 tok/s 的完整模型 vs 100 tok/s 的量化小模型，你的场景选哪个？
- 云 API 的账单，是不是已经在悄悄吃掉你的毛利？
📬 关注梦兽编程，获取更多 AI 模型格局与本地部署分析。
参考来源：