llama-modchip v2.4.0：在仅 64GB CPU 机器上运行 284B DeepSeek MoE

llama-modchip v2.4.0 是一个打过补丁的 llama.cpp 分支，声称可以在 64 GB 仅 CPU 机器上，以 256K 上下文和大约 9–15 tokens/秒的速度，完全在 RAM 中运行 284.33B 参数的 DeepSeek-V4-Flash 混合专家模型，且无需任何 GPU。该项目的主要宣称是，一个标准 IQ2_XXS GGUF 格式为 76.87 GiB（在 64 GB Linux 机器上会因内存不足而崩溃）的模型，已被压缩到磁盘上 56.56 GiB，常驻内存约 57.61–58.9 GiB。Hacker News 上的讨论（387 分，172 条评论）明显分为两派：一派为工程成就所折服，另一派则怀疑这种 2-bit 级别的模型是否值得运行。

llama-modchip v2.4.0 声称能做什么

llama-modchip 以统一 CLI（./modchip）加一组针对 llama.cpp 的补丁形式分发。其宣传的三大支柱是：在 64 GB CPU 机器上运行 284B 前沿 MoE、在纯 CPU 上以接近 GPU 速度运行 30B MoE，以及零 API 的 Claude Code 集成。

项目自己的摘要表将硬件与推荐模型对应起来：

机器	内存	推荐模型	声称速度（0 GPU）
开发者笔记本 / 迷你 PC	16–32 GB	Nemotron-3.5-30B-A3B (14.35 GiB)	25.0–60.4 tok/s
64 GB 台式机 / 服务器	64 GB	DeepSeek-V4-Flash 284B (56.56 GiB)	44.4 tok/s 预填充，9.1–14.7 tok/s 解码
混合台式机（CPU + 16 GB GPU）	32–64 GB	Nemotron-30B / Qwen3-30B	80.80 tok/s
8 通道工作站（Threadripper）	128 GB+	DeepSeek-284B / Nemotron-30B	111.62 tok/s (30B)

所有这些数字均由项目自行报告，并发布在其 README 和基准测试表中。

284B 模型如何装进 64 GB 内存

核心机制是激进量化与自定义张量格式的结合。llama-modchip 引入了一种 block-64、BF16 缩放、格雷编码的张量类型，称为 Fractal-64，每权重 3.75 位，外加一种 Fractal-MXFP4 变体，每权重 4.25 位。项目还描述了一种“解析式 SwiGLU-H2 二阶 Hessian 压缩”步骤和一种“wo_b * wo_a 的精确 SVD”降维，声称在 25% 秩缩减下保留了 99.82% 的余弦相似度。

DeepSeek-V4-Flash 构建版本报告为磁盘上 56.56 GiB，比 76.87 GiB 的 IQ2_XXS 基线减少了约 20.31 GiB。在完整 256K 上下文下，项目报告峰值 VmRSS 为 57.61 GiB，同一 README 中其他地方引用为 58.9 GiB。

一个关键的兼容性警告：Fractal-64 模型使用自定义 GGML 类型 ID（GGML_TYPE_Q2_0 = 40）和自定义 deepseek4 / Stockfish-PVS 内核。README 明确说明，在未打补丁的 llama.cpp、Ollama 或 LM Studio 中打开这些文件将失败，并显示 unknown tensor type 40。用户必须运行项目自己的二进制文件或打过补丁的构建。

投机解码层：Stockfish-PVS 和 RouteCrack

llama-modchip 的解码速度提升很大程度上依赖于一个小型草稿模型。项目捆绑了一个 1.64 MB 的 Stockfish-PVS v2 草稿器，带有 RouteCrack 组件，描述为 L2/L3 Zobrist 置换表，并报告在 Nemotron-30B 模型上接受率为 96.4%，在 DeepSeek-284B 上为 94.5%。

在 DeepSeek-V4-Flash 上，项目报告纯 CPU 解码为 9.06–10.74 tok/s，启用 PVS 草稿器后升至 11.5–14.7 tok/s。在 Nemotron-30B 上，报告基础解码为 25.02 tok/s，启用草稿器后平均 48.39 / 峰值 60.40 tok/s。

Claude Code 集成和热 KV 恢复

项目附带一个 ./modchip claude 命令，将 Claude Code CLI（所有 40 个工具均激活）连接到本地引擎。它解决的问题是 CPU 代理每次交互时大约 45 秒的提示重新评估。llama-modchip 通过 /dev/shm Slot-0 KV 热恢复来解决这个问题，在 Nemotron-30B 上报告为 18.9 ms，在 DeepSeek-284B 上为 13.1–32.6 ms。

支持的硬件

README 列出了针对特定架构的内核：AMD Zen 5（AVX-512，带 VPDPBUSD、VPRORVQ、VBMI、BF16）、Zen 4 多 CCD Threadripper 和 EPYC（动态 L3 CCD 拓扑发现，项目称确定性 4 核/CCD 步长比 -t 64 快 54%）、AMD 3D V-Cache 加 Radeon Vulkan 混合、Intel/NVIDIA Windows 混合、Apple Silicon（通过 Metal）、ARM64 云（AWS Graviton3，带 SDOT 和 256 位 SVE），以及 Fedora 迷你 PC 配置。

README 中社区提交的排行榜条目包括：Threadripper PRO 7985WX 在 Nemotron-30B 上热解码 111.62 tok/s、Apple M4 Pro 47–48 tok/s、AWS Graviton3 m7g.2xlarge 44.97 tok/s，以及仅 AVX2 的 EPYC 7402P 27.29 tok/s。

核心反对意见：2-bit 量化在质量上代价几何？

Hacker News 讨论中最实质性的批评是关于量化质量，而非速度。评论者 @armcat 认为，位宽与模型质量之间的关系是非线性的，最佳点通常大约在 4 位：

“对于激进量化，需要记住的是，经验证明（1）量化具有非线性性能行为，（2）通常峰值大小-性能比出现在 4 位；任何更低都会导致显著的性能下降。”

@armcat 引用了“量化大语言模型的可靠性缩放定律”（TUM），并补充说，在两年语音模型工作中，任何低于 8 位都会导致大幅质量下降——并指出量化行为在不同模态间并不相同。

@walrus01 更直接，认为将模型缩小到这种程度违背了目的：

“他们为了缩小它所做的任何事都会让它比 unsloth Q2XS 量化或等效版本更差。那种大小的模型需要大约 150GB 内存才能以完整未量化 KV 缓存正常运行……运行一个被‘脑叶切除’的模型只是为了说你在做这件事，真的没什么特别的成就。”

@throw10920 简洁地概括了这一类型：“‘2-bit 量化’之于‘看我能在这硬件上装多大的模型’，就像‘在小鼠中’之于医学研究。” @GypsyKing716 提出了类似观点：“仅仅因为你能加载它，并不意味着你应该加载它。”

几位评论者表示，量化级别在 README 中根本不明显。@akie 写道：“在什么量化级别？这是我只想知道的。” @boredatoms：“量化可能是最重要的事情，但在那堆密集的文字沙拉中完全不清楚。”

第二个反对意见：它真的比普通 llama.cpp 更快吗？

@aappleby 在 Ryzen 7945HX（16 核 Zen 4，96 GB DDR5）上测试了该项目，并报告在 Nemotron 上性能与 CPU 上的普通 llama.cpp 大致相同，除了预填充：

“愚蠢的问题，但这个 AI 生成的仓库真的_做_了什么吗？在 Nemotron 上比较，它在 CPU 上运行得和普通 llama.cpp 差不多（除了预填充似乎快得多）。我在‘modchip setup’中看不到设置 DeepSeek 的选项，所以还没测试那个。”

一个反驳来自 @sparse-Matrix，他报告项目在更弱的硬件上工作：“在我的 Ryzen 7 5700U/64GB DDR4 上运行得很好，稳定 12 到 14 TPS……足够快来完成有意义的个人工作，功耗 15w。”

@robotswantdata 提出了另一个性能担忧：“这种方法的预填充（提示处理）太慢了。”

README 可读性问题

评论中反复出现的主题是文档本身。多位读者将 README 描述为 AI 生成且难以解析。@superkickstart：“我希望人们能清理 GitHub README 中 AI 刷屏的 emoji。可读性太糟糕了。” @intoXbox 称其为“相当令人讨厌的 Readme.md，满是 AI 垃圾”，并指出它“包裹着 llama.cpp，但看不到它做了哪些平台假设，其他读者不清楚这是否值得测试。” @gtirloni 问道：“人们还记得 README.md 也是给人读的吗，还是我们都默认从 AI 垃圾中要 TL;DR？”

llama.cpp 中的分支生态系统问题

@SillyUsername 将 llama-modchip 置于更广泛的专门 llama.cpp 分支模式中——点名 Bonsai Qwen 3.8 27B、Strata 和 Pulsar——并认为上游审查过程是瓶颈：

“我只是希望上游 Llama.cpp 能更快接受 PR——他们每天构建多次，但上次我检查时 PR 积压有 1.7K，这对几个志愿者来说是一个极其不切实际的审查数量。我看了 Qwen 3.8 Bonsai 功能，从创建到审查花了 3 周多，即便如此也不包含他们下游修复的 bug 补丁，他们最终放弃推送到上游，因为过程太费力了。”

讨论对本地推理方向的启示

几位评论者将该项目视为本地推理硬件门槛不断降低的证据。@kennywinker 描述了一个低于 800 美元的构建：“一台多线程的 E5 工作站，300 美元内存和至少 100 美元 GPU，就能得到 >100tok/s+ 提示处理，以及 Qwen3.8-flash-next:IQ3_S 约 20tok/s 输出。再加 500 美元 GPU，就从勉强可用变成令人愉悦的高性能。”

@antirez 提供了一个高端数据点：128 GB 统一内存下，模型“甚至可以跑得很快……比如，编码代理可接受地快”，引用预填充约 300 tok/s。

@nickdothutton 画了一个历史类比：“20 世纪 80 年代很多 demoscene 玩家来自硬件稀缺且昂贵的国家，这推动了很多技术创造力。” @aussiegreenie 将经济性大致定为“每人每月约 10 美元，就能获得足够处理能力进行有用的工作，并拥有数据主权。”

尝试前的实际注意事项

284B DeepSeek 的数字由项目作者自行报告，尚未在讨论中被独立复现。
Fractal-64 GGUF 文件需要项目的补丁二进制；普通 llama.cpp、Ollama 和 LM Studio 会以 unknown tensor type 40 拒绝它们。
每权重 3.75 位的质量是悬而未决的问题。README 报告 Nemotron 上“100/100 质量门”，DeepSeek 配置文件余弦相似度 0.99126–1.00000，但独立评论者仍怀疑这些指标是否捕捉到真实世界的退化。
至少一位测试者（@aappleby）发现 Nemotron 上除预填充外没有比普通 llama.cpp 有意义的加速，而另一位（@sparse-Matrix）报告在旧硬件上有可用吞吐量。
项目采用 Apache 2.0 许可证，并在 paper/ 目录中包含一份 arXiv 风格的预印本 PDF。