64GB 内存、无显卡跑 284B DeepSeek：llama-modchip 是怎么做到的

synchopate/llama-modchip（gh API 11 月 8 日实测：203 星、18 fork，Apache-2.0，Go/Python，2026-10-29 创建、11-08 仍在推送，41 个 commit、4 个 release，当前 v2.4.0；11 月 8 日登 HN 首页）。先定性：很早期的十天仓库——但作者声称的数字足够扎眼：在纯 64GB CPU、0 GPU 的机器上跑 284B 的 DeepSeek-V4-Flash。

llama-modchip GitHub 仓库页面

作者声称的数字（全部为作者自述，未经第三方复现）

据 README：284B DeepSeek-V4-Flash 压到 56.56 GiB（磁盘），在 64GB 机器上跑出 44.4 tok/s 预填充、9.1–14.7 tok/s 解码，256K 上下文；30B MoE（Nemotron-3.5-30B-A3B）在 14.35 GiB 内跑 25–60.4 tok/s，Threadripper 上 111.6 tok/s。另带 ./modchip claude：把 Claude Code 接到本地引擎，Slot-0 KV 热恢复 13.1–32.6ms（作者称 vs 冷启动 65.8 秒）。

先说清这条数字的边界：9–14 tok/s 的解码只是“能跑”，不是“好用”——这个速度读一段长回复都要等，别把“284B 在 64GB 上跑”读成“流畅可用”。数字的测试机型均为作者单机数据，无其他硬件复现。

手段：三层组合拳（README 口径）

量化转码：标准 IQ1_S/IQ2_XXS 量化为 76.87 GiB（64GB 机器会 OOM），经 Fractal-64（Q2_0，3.75 bpw）转码压到 56.56 GiB——配合 SwiGLU-H2 二阶 Hessian 压缩；
推测解码：Stockfish-PVS v2 起家的 L3 草稿模型（作者称 96.4% 接受率），把解码速度抬到 9.1–14.7；
缓存工程：多级 tiling 与 L3 cache 隔离（HARPCache）。

关键限制（README 原文口径，必须写）：模型用自定义 GGML_TYPE_Q2_0（type 40）与自定义 deepseek4 内核——未打补丁的 llama.cpp / Ollama / LM Studio 会报 unknown tensor type 40 无法打开，必须用作者自带预编译二进制或 ./modchip。也就是说这不是“给 llama.cpp 提个 PR”的优化，是一套私有格式与内核。

名字要核实着写

"DeepSeek-V4-Flash" 与 DeepSeek 官方的关系须核实着说：GGUF 挂在作者个人 HF 账号（Synchopate）下，非 deepseek-ai 官方发布；HF 页面标注 base_model 为 deepseek-ai/DeepSeek-V4-Flash-0731（即对官方权重的再量化）、MIT 许可、234 次下载。README 自称 100/100 Quality Gate、99.82% CosSim、arXiv 预印本——均为作者口径；Q2_0 级 3.75 bpw 的极低比特量化必然有精度损失，作者自己的 99.82% 余弦相似度也印证了“有损但作者称可控”，两个口径一起看。

判断

三点校准：① 与第五十批 project-maya 区分：那是“多模型本地推理引擎”（专家分级放置 GPU/内存/SSD），这篇是 CPU 推理优化工程（llama.cpp 补丁 + 自定义量化 + 推测解码）——一个解决“放得下”，一个解决“纯 CPU 也转得动”；② 它的真实价值不在“人人都能 64GB 跑 284B”，而在展示了三个可移植的方向：超低比特转码、L3 草稿模型、KV 热恢复——这些思路对 llamacpp 社区是有用的源代码；③ 203 星、十天、私有格式、单机数据——把它当“作者的极限工程演示”读，等第三方在别的机器上复现了再当工具用。