码农早餐 · 2026-11-09

llama-modchip 称可在 64GB CPU 内存运行 284B DeepSeek

GitHub 项目 llama-modchip 在 README 里放出了一组很具体的数字：把 DeepSeek-V4-Flash 这个 284.33B 的 MoE checkpoint 压到 56.56 GiB，号称在一台纯 64 GB 内存、0 GPU 的机器上运行，256K context 下峰值 VmRSS 是 57.61 GiB，16 核 Zen 5 的 prefill 速度是 44.36 tok/s，生成阶段是 9.1 到 14.7 tok/s。项目当前 release 标的是 v2.4.0。它不是新模型，也不是 DeepSeek 官方发布，而是一组给 ggml 和 llama.cpp 用的 kernel patch、量化转码器和 runtime 工具，目标是让大参数量的稀疏 MoE 模型尽量完全待在系统内存里。

这件事的前提，其实是 MoE 模型“总参数很大，但每次只激活一小部分”。README 自己给的数字是 284.33B total、13.17B active，并且默认每层都跑 Top-6 routed experts，不做 pruning。它要解决的不是“CPU 比 GPU 快”，而是“64 GB 机器根本塞不下原始 checkpoint”。项目说标准的 UD-IQ1_S 版 DeepSeek-V4-Flash 有 76.87 GiB，已经超过 64 GB Linux 机器大约 62.5 GiB 的可用内存，所以会触发 page-cache thrashing 或 OOM；它把这个体积压到 56.56 GiB，才让模型加上 256K 的 KV cache 一起留在 RAM 里，而且注明是 zero NVMe swap。

把这条和最近几件 DeepSeek 相关的事放一起看，方向其实很清楚。10 月 21 日我们写过，DeepSeek 自己开源的 DeepInfer 只支持 SM100 和昇腾 950，还缺 KV cache 系统，走的是专用加速卡路线；而这个项目反过来，核心卖点正是“不用 GPU”。10 月 20 日我们也写过，DeepSeek V4.1 Flash 的评测页已经出现，但页面同时写着 “No publicly available API”，说明很多人能看到分数，看不到可直接调用的服务。llama-modchip 瞄准的就是另一条路：不是等官方 API，也不是上专门硬件，而是把开放权重的模型尽量挤进通用 CPU 机器。

标题里最容易被忽略的一层，是它靠的不是单一技巧。README 把增益拆得很细：一部分来自更激进的低比特量化，DeepSeek 这一版做到 1.71 bpw；一部分来自 CPU cache 和 SIMD kernel 改造，项目声称 prompt prefill 从 25.0 tok/s 提到 44.36 tok/s，增幅 77%，decode 增幅 53%；还有一部分来自运行时细节，比如用 _MM_HINT_NTA 避免冷 MoE expert 权重把热 KV cache 从 L3 顶出去，以及把 KV slot snapshot 放到 /dev/shm，把 40-tool Claude Code prompt 的恢复时间压到 13.1 到 32.6 ms。这些数字都来自项目自述，还不是第三方复测结果。

现在能确认的现状，就是代码、README、paper 和 release 都已经公开，支持的硬件写到了 x86_64 的 AVX-512/AVX2 和 ARM64 的 NEON/SVE/Apple Metal，也给了 30B MoE 在 16 到 32 GB 机器上的几组速度数字。还没确认的是这些结果在别的 CPU、别的内存带宽和别的 workload 上能否稳定复现；README 里有 leaderboard 提交流程，说明作者也在等社区补更多机器数据。另一个没展开的点是质量损失。项目给了每种量化的 bpw 和体积，但这页展示的重点是能塞进去和跑多快，关于 1.71 bpw 的 DeepSeek-V4-Flash 在实际任务上掉了多少，报道没展开。

来源：

• GitHub - synchopate/llama-modchip

---

本文从过去 24h 的 X / Hacker News / GitHub Trending 共 41 条信息中选出这一件事展开。内容由 LLM 辅助生成并经事实校对，来龙去脉部分参考了本站往期内容，文末附原始来源链接，重要决策请交叉验证。