使用 29 GB 内存以 0.50 tok/s 运行 Kimi K3

项目概念与性能

• 该工具通过从 SSD 流式加载大部分权重，在通用硬件上运行完整的 2.78T 参数 Kimi K3，仅为 4k 上下文使用约 29 GB RAM。
• 吞吐量约为 0.5 tokens/second；一些人认为这在今天更多是概念验证，而非实用方案。
• 据称在 macOS 上，这个项目里 ARM NEON 比 Metal 更快。

0.5 tok/s 的 K3 的实际用途

• 许多人认为 0.5 tok/s 对交互式工作不可用，即使是邮件级别的流程也不行。
• 也有人建议用于过夜或数小时的批处理任务：代码审查、项目分析、会议摘要或数周工作的总结。
• 关于这种速度下模型能“思考”多少存在争论；一位评论者指出，模型可能会使用数万内部 tokens 来生成简短答案。

存储、内存与系统设计

• 讨论将自定义流式引擎与类似 llama.cpp 的基于 mmap 的方法进行对比。
• 有人声称，手动预取和缓存可以显著优于通用的操作系统分页。
• 关于 swap 的担忧：几位评论者主张完全禁用 swap，以避免 SSD 磨损和性能下降；也有人澄清，对权重进行只读 mmap 不会损害 SSD 耐久性。

量化与模型保真度

• 该引擎使用的是重新量化的 3-bit residual 变体，而不是“纯”的 K3。
• 另一个项目（deltafin）被提到可运行未经改动的 K3，但每 token 带宽更高（≈25.8 GB 对比 ≈17 GB）。
• 一位评论者认为 README 在模型是否真正“原生精度”方面写得令人困惑，甚至自相矛盾；整体精度和质量影响仍不明确。

成本与能效

• 粗略成本估算：在 42W 和 $0.20/kWh 的条件下，约为每百万 tokens $5。
• 有人将其与现代 GPU 集群相比，认为效率不高得多（每瓦时 tokens 数量高出几个数量级），但也指出 GPU 的前期成本很高。
• 关于太阳能/PV 的讨论集中在：自发自用的能源是否仍应被视为真实的机会成本。

文档质量与 LLM 作者身份

• 一个很长的分支批评了 LLM 生成的 README 过于冗长、晦涩且过于内部导向。
• 也有人为 LLM 辅助文档辩护，认为总比没有文档好，但同意应该经过编辑以提高清晰度。
• 更广泛的争论围绕用 LLM 编写代码、提交和文档：一些人认为这是“lazy slop”，另一些人则认为只要代码经过审查，这就是高效协作。

许可、品牌与信任

• 有人因为该公司过去的非开源许可以及与 SQLite 的名称混淆而对其不信任。
• 该公司回应称他们拥有该名称的权利，而且这个项目会保持宽松许可。

相关工作与展望

• 讨论串列举了多个几乎同时出现的 Kimi K3 自托管尝试：仅 CPU 流式、消费级 GPU，以及压缩后的 GGUF 变体。
• 许多人认为这个项目是朝着最终可行的本地运行超大模型迈出的早期、尚不实用的一步。