WASTE 推理引擎：在消费级硬件上运行 Kimi K3 2.78T
架构：NVMe 流式传输与权重管理
感知权重的流式传输
由于 Mixture of Experts（专家混合）模型在每个 token 上只激活一小部分参数（K3 大约为 4%），WASTE 只会从磁盘流式读取每个 token 所需的专家。为降低 I/O 开销，模型被转换为 .waste 容器，其中每个专家记录均为 4 KiB 对齐。该布局保证路由到某个专家时只需一次 pread 操作，并通过使用 F_NOCACHE（macOS）、O_DIRECT（Linux）或 FILE_FLAG_NO_BUFFERING（Windows）绕过操作系统页面缓存，以防内核尝试缓存 TB 级别的模型。
残差向量量化（RVQ）
为了降低磁盘占用和 I/O 带宽需求，专家采用三阶段残差向量量化存储，压缩至每个权重 3.00 位。引擎直接在这些量化权重上进行算术运算，而不需要展开完整矩阵，将每个专家行的计算简化为三次表查找和两次加法。
内存预算与“缓存底线”
WASTE 将剩余的 RAM 用作受限的专家缓存。引擎会确定一个“缓存底线”——容纳单个 token 工作集所需的最小 RAM（K3 为 17.0 GB）。
- 低于底线：缓存命中率为 0%，因为专家在下一个 token 请求之前就被驱逐。
- 高于底线：命中率急剧上升，提升吞吐量。
- 分页上限：如果 RAM 预算设得过高（例如在 64 GB 机器上设为 58 GB），操作系统会将专家缓存换页到磁盘，导致性能大幅下降（从 0.32 token/s 降至 0.04 token/s）。
为避免上述情况，WASTE 会自动计算一个不超过物理内存七分之八的预算，并以完整工作集为单位递减，以最大化效率且不触发操作系统换页。
性能基准
基准测试在配备 64 GB RAM 与内部 NVMe SSD 的 MacBook Pro M5 Pro 上进行。
Kimi K3（2.78T 参数）
| Metric | Value |
|---|---|
| 最小内存 | 29.05 GB (at 4K context) |
| 容器大小 | 982 GiB |
| 解码速度 | 0.49–0.54 tok/s |
| 常驻主干 | 27.28 GB |
| 每 Token 读取量 | 17.0 GB |
| 视觉塔 | 15.7 s for 1024-patch image |
Kimi-Linear（48B 参数）
| Metric | Value |
|---|---|
| 最小内存 | 1.87 GB |
| 容器大小 | 19 GB |
| 解码速度 | 10.7 tok/s |
技术实现细节
线性注意力与 KV 缓存优化
K3 使用混合注意力机制（Kimi Delta Attention 与门控多头潜在注意力）。WASTE 将 kv_b_proj 合并到 query 和 output 中，使 KV 缓存大小缩小 53 倍。在 4K 上下文下，缓存需求从 11.25 GB 降至 0.21 GB，从而在受限硬件上实现显著更长的上下文窗口。
引擎规格
- 语言：使用 C11 编写，无第三方运行时依赖（仅
libc与pthreads）。 - 可嵌入性：引擎以库形式提供（
libwaste.a），包含 26 个公共函数，可完整嵌入其他应用。 - 多模态支持：包含一个 401M ViT（27 层）用于图像处理。图像被转换为嵌入后，作为文本 token 通过 MoE 层进行处理。
- 平台支持：支持 macOS（ARM64）、Linux（ARM64/x86_64）以及 Windows（x86_64，via MinGW-w64）。
社区洞察与反驳
虽然在笔记本上运行 2.78T 模型的技术成就值得称道，但社区讨论指出了若干实际权衡：
“每秒 0.5 token 并且每秒从 SSD 读取数十 GB……我在想如果目标是 500 GB 或 250 GB 的模型，这是否真的实用……”
批评者指出，0.5 token/秒的速度对实际使用而言极其缓慢，尤其是像 K3 这种倾向于生成大量文字的“思考”模型。还有人提到，与 GPU 集群相比，每 token 的能耗很高，且 1 TB 的巨量存储需求成为许多消费用户的门槛。