64GB内存跑284B DeepSeek，无需GPU
Llama-modchip: 284B DeepSeek on 64GB RAM, no GPU
llama-modchip项目打破了硬件限制，让284B参数的DeepSeek-V4-Flash模型在仅64GB内存的纯CPU环境下流畅运行，完全不需要GPU。通过SwiGLU-H2压缩、Fractal-64量化及Stockfish-PVS推测解码等创新技术，该项目在普通CPU上实现了44.4 tok/s的预填速度和9.1-14.7 tok/s的生成速度。无论是开发者笔记本还是Threadripper工作站，用户都能利用现有硬件运行前沿的MoE模型，甚至实现零API调用的Claude Code本地化体验。
在你已有的CPU工作站上实现实时前沿与代理MoE推理——100%驻留内存，零NVMe交换。
HN 评论区
204- kennywinker
尽管内存和 GPU 价格持续上涨，构建功能性本地 AI 系统的门槛却不断降低。一台拥有众多线程的 E5 工作站，配上 300 美元的内存和至少 100 美元的 GPU，就能实现超过 100 词/秒的提示词处理速度，以及使用 Qwen3.8-flash-next:IQ3_S 模型时约 20 词/秒的生成速度。如果再塞进一块 500 美元的 GPU，性能就从勉强能用变得令人愉悦。花不到 800 美元，你就能拥有一台性能足以与不到一年前的最先进（SOTA）系统相抗衡的设备。
我实在看不出有人如何能证明订阅 Claude 是合理的。难道你想从那些试图用自动化取代你工作的人那里，租用你赖以谋生的工具吗？
- armcat
关于激进量化（aggressive quantisation），有一点需要牢记：经验数据已经证明 [1]，(1) 量化的性能表现是非线性的，(2) 通常 4-bit 是性能与模型大小比的最佳平衡点；低于这个位宽，你会看到性能显著下降。
此外，过去两年我一直在玩语音模型，对我来说，低于 8-bit 的量化会导致质量大幅下降；所以，LLM 的量化与其他定制模态模型的量化并不是一回事。
[1] "Reliability Scaling Laws for Quantized Large Language Models", TUM, https://arxiv.org/pdf/2607.10855
- antirez
为了让你有个概念，考虑到使用 128GB 统一内存，它的运行速度甚至可以很快：https://x.com/antirez/status/2119392658661749175
就像，作为编码代理（coding-agent）的速度已经相当可观了。回复后面有提到预填充（prefill）速度约为 300 t/s，但对于更大的预填充任务，速度甚至更快。
- aappleby
问个傻问题，但这个 AI 生成的仓库实际上能 _做_ 什么吗？
在 Nemotron 上对比了一下，它在 CPU 上的运行表现和普通的 llama.cpp 差不多（除了预填充似乎快得多）。我没看到在 "modchip setup" 中设置 DeepSeek 的选项，所以还没测试那个。
编辑：这是在 Ryzen 7945hx 16 核 Zen 4 + 96 GB DDR5 上运行的。
- boredatoms
量化（quantization）可能是最需要了解的关键点，但那段密密麻麻的文字堆砌（dense word salad）完全没把这事说清楚。
- akie
是在哪种量化精度下？这是我只想知道的唯一一件事。
编辑：我猜是 2 bit？如果是的话，我很想知道输出质量如何。我猜应该不太好吧。
- SillyUsername
挺有意思的。llama.cpp 有不少分支在流式传输权重（streaming weights）方面取得了成功，或者采用了特殊的量化/处理前解压技术。
- Bonsai Qwen 3.8 27B
- Strata
- Pulsar
- 这个...
我只希望上游 Llama.cpp 能更快地接受 PR——他们每天构建多次，但我上次查看时，他们的 PR 积压量已达 1.7K，对于几个志愿者来说，这是一个荒谬且无法处理的数字。
我关注了 Qwen 3.8 Bonsai 这个功能，从创建到被审查花了超过 3 周，而且即便如此，它还不包含那些在下游修复了但上游因为流程太繁琐而放弃推送的补丁。
结果就是模型支持延迟或缺失，像 Bonsai 的 Hadamard Folding 这样半成品的实现，以及新模型无法获得这类优化。
如果你打算把你的项目作为分支的参考项目并鼓励这种专业化，那倒也无可厚非，但我认为这并非有意为之。
至少我可以用 llamaswap 来动态切换推理引擎和模型，从而抽象掉需要安装 3 或 4 个不同版本的事实。
- superkickstart
真希望有人能把 GitHub README 里那些被 AI 刷屏的 emoji 清理一下。可读性简直惨不忍睹。