WASTE是一个用C语言编写的嵌入式推理引擎，无需第三方依赖。它通过将模型主干保留在内存中，直接从NVMe流式传输选定的专家权重，并使用剩余RAM作为缓存，成功在仅64GB内存的消费级笔记本上运行了2.78万亿参数的Kimi K3模型，速度约0.5 token/秒。

好的，这是根据您的要求，对原文主要内容进行的中文重述，保留了关键细节，并删减了与核心主题无关的冗余信息。

项目概述：WASTE —— 在消费级电脑上运行万亿参数大模型

WASTE 是一个用 C 语言编写的、无外部依赖的推理引擎。它的核心创新在于，通过直接从 NVMe 固态硬盘流式读取模型权重，使得在内存有限的消费级电脑上运行超大规模模型成为可能。其当前的验证案例是 Kimi K3 模型（2.78万亿参数），该模型在仅配备 64GB 内存的 MacBook Pro 上，以约 0.5 token/秒的速度成功运行，且并非经过蒸馏或剪枝的简化版本。

核心原理

• 混合专家模型 (MoE) 的机遇：K3 模型每次推理仅激活约 4% 的参数。WASTE 利用这一点，将模型主体（Trunk）常驻内存，而将大部分专家权重（Experts）存放在磁盘上。
• 按需流式读取：引擎为每个 token 精确计算需要哪些专家，然后直接从磁盘读取，每次读取一个专家仅需一次 pread 操作，效率极高。
• 智能缓存：剩余的内存被用作专家缓存。缓存策略的关键在于，其容量必须至少能容纳一个 token 所需的全部专家数据（约 17GB），否则缓存命中率为零，性能会急剧下降。

性能与资源需求

• 模型大小：Kimi K3 模型转换后的容器文件为 982 GiB。
• 内存需求：最低 29.05 GB 可启动，但推荐 64 GB 以获得可用性能（约 0.5 tok/s）。内存预算的微小变化会显著影响性能，因为系统内存不足会导致操作系统将缓存数据换出到磁盘，反而拖慢速度。
• 存储速度：至关重要。模型容器必须放置在内部 NVMe 固态硬盘上，其读取速度（约 12.78 GB/s）是保证流式读取不卡顿的关键。使用外置 USB 硬盘（约 0.94 GB/s）会导致性能严重下降。
• 小型模型示例：对于较小的 Kimi-Linear 48B 模型（19 GB 容器），在 8 GB 内存预算下即可达到 10.7 tok/s 的速度。

技术特点

• 零依赖：推理时仅依赖 libc 和 pthreads，无 Python、BLAS 等运行时依赖。
• 可嵌入：提供简洁的 C 语言 API，仅 26 个公开函数，方便集成到其他应用中。
• 高效量化：专家权重采用 3 比特残差向量量化（RVQ）存储，模型主体则使用 4 或 8 比特量化。
• 线性注意力机制：K3 模型采用 Kimi Delta Attention，其 KV 缓存大小固定，而非随序列长度增长。这使得长上下文推理成为可能，例如 128K 上下文仅需 7.2 GB 缓存，而传统方式需要 360 GB。
• 跨平台：支持 macOS (ARM)、Linux (ARM/x86) 和 Windows (x86)，并会根据 CPU 特性自动选择最优的 SIMD 指令集（如 NEON、AVX2）。

当前状态与局限

• 正确性已验证：引擎的每一层都经过 PyTorch 参考实现的验证，最终输出 logits 的误差在 3.6e-06 以内。
• 速度是主要瓶颈：当前约 0.5 tok/s 的速度确实很慢。项目团队认为，进一步优化的空间在于增加内存（以提升缓存命中率）或使用更快的磁盘，而非修改核心算法。
• 项目定位：该项目旨在证明，在单台消费级电脑上运行万亿参数模型是可行的，而非追求极致速度。它开启了一种可能性：在本地运行前沿模型，无需网络、无需为每次推理付费，且数据完全不出设备。

如何开始

1. 获取代码：git clone 项目并执行 make 即可编译。
2. 转换模型：使用 Python 工具 tools/convert.py 将 Hugging Face 上的原始 Kimi K3 权重（1.42 TB）转换为 WASTE 容器格式（982 GB）。此过程耗时约 4.7 小时，且支持断点续传。
3. 运行：使用 waste run 命令即可开始推理。引擎会自动根据可用内存调整缓存大小，无需用户手动配置。

总结

WASTE 是一个具有里程碑意义的项目。它通过巧妙的工程手段，打破了“运行大模型必须依赖昂贵服务器”的固有认知，为在个人电脑上部署和使用前沿 AI 模型开辟了新的道路。尽管当前速度较慢，但其证明了技术可行性，并将未来的挑战从“能否实现”转向了“如何优化”。

根据评论内容，总结如下：

主要观点与论据：

1. 技术性能质疑：多位评论者关注项目在Mac上的性能表现。cjbprime询问是否使用Metal框架（"Does it not use Metal, on macOS?"），herf指出功耗效率低下（"30-50W...vs maybe 80k for a modern GPU cluster"），bgirard估算成本约每百万token 5美元（"~$5 per million tokens"）。

2. 实用性存疑：logicallee质疑低速率下的实用性（"generate only a total of 1.8k tokens in 1 hour"），Catloafdev直接问"what do you do with a 0.5tk/s LLM?"。

3. 代码与文档质量：pja怀疑README由LLM生成（"hits all my 'this is authored by an LLM' instincts"），cadamsdotcom批评文档草率（"you didn't ship the first draft of your code - why did you ship the first draft of your README?"）。

4. 项目对比与命名争议：SSilver2k2提到类似项目colibri（"sounds a lot like what the colibri project did"），righthand质疑公司名称是否侵犯SQLite商标（"riding on the name of an open source tool"）。

平衡性总结：评论整体偏向质疑与批评，主要围绕性能效率、实用价值、文档质量及命名合规性。正面评价较少，仅SSilver2k2表示"keep at it!"。