64GB内存，284B参数，1.71bit。

把这三个数字放到一起的，是上周五冲上HackerNews首页的llama-modchip（442分、196条讨论）：一个建仓11天、单人50次提交的仓库，宣称不要显卡，让64GB内存的普通台式机跑起DeepSeek-V4-Flash284B旗舰——读题44.36tok/s，作答9-14.7tok/s（tok/s：每秒处理的词数），256K上下文，零GPU。

评论区很快出现一条拆台实测。Redis作者antirez看完演示视频算了一笔账：43个token的提示词，光“读题”就花了约4秒，折合10.75tok/s，离宣传差4倍。

这篇文章解决一个问题：CPU跑大模型，物理极限在哪，宣传话术藏在哪。把体积、带宽、信度三笔账算完，下次再刷到“XXGB内存跑XXXB”的爆款仓库，你可以自己判断成色。

一、体积账：省出来的20.31GiB，不是技巧，是刀刃

先把单位摆平。bpw（bitsperweight）指每个参数用几个比特存储：16bit是原装，4.5bpw是常见的Q4_0量化，而64GB的Linux扣掉系统，可用内存约62.5GiB。

社区给这个模型做过1-bit级压缩：Unsloth的UD-IQ1_S检查点76.87GiB。装不下，差14.37GiB（顺带纠偏：GiB和GB差7.4%，76.87GiB折合82.5GB，读这类仓库的数字前先统一单位）。装不下为什么是死路？权重会被挤到NVMe固态盘上，而解码时每个token都要把激活权重从存储里完整读一遍——SSD顺序读约7GB/s，只有内存带宽的十二分之一，速度直接从“慢”跌到“卡死”。所以这类项目的第一仗永远是体积：先把全部权重塞回内存，再谈别的。

modchip的做法不是发明新压缩算法，而是重新分配预算。284B模型里有256个“路由专家”，但每个token只会用到其中6个加1个共享专家；那些几乎每次都会被用到的部件——词嵌入、43个共享专家、注意力的压缩投影——保存在Q4_K/Q5_K甚至F32；被点名频率低的256个路由专家，压到IQ1_S的1.5625bpw；介于两者之间的注意力投影，交给自研的Fractal-64块量化（约3.75bpw）。

Fractal-64这套东西值得多看一眼：传统的Q4_0是每32个权重共享一个缩放系数，它改成64个权重一块、块内再拆8组子尺度——块越大越省空间，子尺度越细越保精度，在“压得狠”和“算得准”之间找了个新平衡点。总账算下来56.56GiB，等效1.71bpw。

这笔账可以自己验算：284.33B参数×1.71bit÷8=56.6GiB，与README报的56.56GiB对上。装进机器后峰值常驻57.61GiB，距62.5GiB的红线还剩4.89GiB余量，零换页。

像装修房子：承重墙必须用钢筋——那是每个token都要路过的注意力通路；一年进不去两次的储藏间，石膏板足够——256选6的冷专家，压狠一点，误差被“没被选中”这件事本身摊薄了。

顺带一笔信度伏笔。HN用户adrian17考证发现，README把76.87GiB基线标注为IQ2_XXS，但Unsloth的IQ2_XXS实际约91GB，76.87GiB恰好是IQ1_S的体积——文档毛边，后面还会遇到更多。

二、带宽账：MoE才是CPU的入场券，modchip只是收票员

CPU推理解码阶段的物理瓶颈不是算力，是内存带宽：模型每生成一个token，就要把这一轮激活的权重从内存完整读一遍。测试机是AMDRyzen99955HX，DDR5-5600双通道，理论上限89.6GB/s。

为什么284B的模型只读得出9tok/s却没把带宽打爆？因为它是MoE（混合专家）架构：每token只激活13.17B参数，占总量的4.63%。在1.71bpw下，每token只需读2.82GB权重。乘一下：9.06tok/s×2.82GB=25.5GB/s，只占带宽上限的28%；开投机解码（小模型先猜、大模型只管验证的加速法，下文细说）的14.7tok/s档，41.4GB/s，占到46%。

这笔带宽账还牵出一条资源兑换。显卡快，快在带宽：一张RTX5090的GDDR7有1792GB/s，是双通道DDR5的20倍；但容量贵——消费级旗舰的32GB显存装不下60GB的检查点，装得下的H100（80GBHBM，3.35TB/s）又不是货架商品。CPU方案正相反：带宽穷，容量富，64GB内存早就是主流主机标配。

极限量化的本质，就是把便宜的容量折算成够用的速度。1.71bpw就是这轮兑换的汇率。

做个反事实：假设同样是284B、同样压到1.71bpw的稠密模型，每token要读全部60.8GB权重，带宽上限直接把解码摁死在1.47tok/s。没有MoE的稀疏性，就没有“CPU跑大模型”这整个故事——modchip没有黑魔法，它只是把这条物理红利吃到了牙缝里不剩。

那读题阶段的44.36tok/s、比原版快77%又是哪来的？prefill（读题）是你发出提示词后、模型作答前的准备阶段：把整段输入一次性算完缓存，之后每生成一个字都靠它查上文。像图书馆给新书编目——编目慢，之后每次借阅就慢，值得专门花力气去抠。

读题一次处理一批token，权重读一遍可以摊给整批，瓶颈从带宽切换成算力。modchip把原来“一列一列算”的量化矩阵乘法，改成四级分块：先塞满512-bit的AVX-512寄存器，放不下下沉L1（32KB）、再L2（1MB）、最后L3（64MB），热数据尽量不回内存，25.0提到44.36tok/s。

带宽账还有个旁证。把官方社区榜单的三个平台摆在一起，跑30B模型的解码速度几乎跟着内存带宽走：M4Max统一内存238.9GB/s，实测49-57.7tok/s；八通道DDR5的Threadripper（256GB），73.8-80.1tok/s；双通道的9955HX，25-34.5tok/s。带宽翻几倍，速度就翻几倍——瓶颈写在物理上，不写在宣传页上。

另外那个“Stockfish-PVS”草稿器，思路借自国际象棋引擎的置换表：一个1.64MB的n-gram小模型先连猜七个词，284B大模型一次性验证，猜中的直接采纳。妙处在于成本结构——专家权重反正要读，一次读出来验证七个候选，带宽开销几乎不变，猜中就是白赚。官方报94.5%接受率，解码从9档抬到11.5-14.7tok/s。这也是为什么投机解码在GPU上只是锦上添花，在CPU上却是救命稻草：带宽省一次，就是几十毫秒。

三、信度账：三个数字，三种水分

数字算完了，该审数字了。

水分一，读题速度的口径差。44.36tok/s是pp512口径——一次喂512个token的批量吞吐。antirez实测的43个token短输入，只有10.75tok/s。口径本身没作弊，但宣传页从不解释：批量越小，权重读取越摊不平，短输入的读题速度天然向解码速度看齐——而你日常的短问答，恰恰落在慢档。换算成体感，3万token的长文档，实测档要47分钟才能读完，宣传档也要11分钟。

水分二，“Bit-Exact无损”的话术。README里最亮眼的数字是“logit余弦相似度1.00000、KL散度0”。看仔细：对比对象是同一个1.71bpw检查点跑在未打补丁的llama.cpp上。它证明的是内核改造没引入额外损失，不证明1.71bpw相对16bit原模型无损。至于相对原模型掉多少分？README一个字没给。

水分三，自家出题自家打分。质量门的“100/100”来自仓库自带脚本（8.5K长文寻针+工具调用），不是公开基准。第三方参照只有间接证据：Unsloth社区数据显示IQ1_M档（1.75bpw，比这里的1.56还高）“保留约98%性能”；而提速档Top-4剪枝README自己也写了KL散度0.028-0.069。能用的下限大概在这附近，再往下没有公开数据兜底。

还有一个常被忽略的物理事实帮了它：模型越大越耐压。同样的1.71bpw，压在284B上比压在30B上伤得轻——参数冗余本身就是缓冲，量化噪声被摊在更大的分母上。评论区两位用户的总结很准：大模型的低量化，常常好过小模型的高量化。

先补一个细节：antirez的4秒和kgeist的116秒出自同一段演示视频——前者逐帧核对了后者发布的录像，两个数字互相印证。

反面证据也要摆足。用户sparse-Matrix在一块15W的Ryzen75700U（Zen2老U）+64GBDDR4上实测12-14tok/s，落在宣传区间内——解码与能效数字大体可信。kgeist那个“116秒才回一句话”的视频拆开看：约4秒读题+112秒作答，若输出生成约千token，折合8.9tok/s，同样贴着宣传下限。能跑是真的；“能用”和“好用”之间，隔着两个数量级的体验。

还有用户walrus01质疑缓存的账：按完整键值缓存（KVcache，模型为查上文存的中场记录）算，256K上下文需要约150GB——而README报的峰值常驻57.61GiB，意味着缓存被MLA（DeepSeek那套把缓存大幅压缩的注意力变体）压到了1GiB量级。这笔账同样没有第三方复核过。

还有更硬的：ar-nelson报告加载DeepSeek直接报张量形状错误，自带编译的llama.cpp吃到Illegalinstruction崩溃；aappleby实测30B模型上与原版llama.cpp性能基本持平。而196条讨论里，作者synchopate一条回复都没有。我的判断：工程是真的，极限是真的，营销按七折听。

四、对比与边界：装得下，不等于该装

想亲手试的话，两条命令（来自官方Quickstart，Linux/macOS，30B模型仅需16-32GB内存）：

#一键脚本：自动拉模型并进入交互聊天（Nemotron30B档，14.35GiB）

gitclonehttps://github.com/synchopate/llama-modchip.git&&cdllama-modchip&&./modchipchat#不下载模型，先体检CPU指令集与内存是否达标

curl-sLhttps://raw.githubusercontent.com/synchopate/llama-modchip/main/scripts/check_cpu_readiness.py|python3

顺带一提，./modchipbench跑30秒会生成一张可提交的测速卡，官方靠社区提交攒出了覆盖12类硬件的公开榜单——一个人维护的仓库，把验证工作外包给了社区，这算是它最聪明的工程决策。

对多数人，正确的打开方式其实不是284B那个头条数字，而是30B档：Nemotron-3.5-30B-A3B用Fractal-64压到14.35GiB，16GB笔记本就能25-60tok/s，一台15W的老机器全程12-14tok/s——每瓦性能是显卡方案给不了的数字。官方榜单里甚至有2012年产的双路XeonE5-2670跑出10.69tok/s，以及按小时租的AWSGraviton3虚拟机跑到44.97tok/s：一台云上ARM小机器常驻一个30B模型，这条路是通的。

给agent开发者留个彩蛋：它能把带40个工具的编程助手提示词状态快照进共享内存，热恢复只要13-32毫秒——全仓库最不夸张、也最实用的数字。而284B档，当前更像一张“物理极限演示卡”：它证明的是1.71bpw+MoE+四级缓存分块这条路能走通，不是让你拿它写代码。

结尾：三问识爆款

下一个“XXGB跑XXXB”的仓库出现时（一定还会出现），先问三个问题：每token激活多少参数（带宽账）？检查点到底多大、什么精度分配（体积账）？跑分对比的是谁、谁复现过（信度账）？三问答完，成色八成清楚。

留个问题给你：你手上的主力机内存多大？如果正好64GB，你会装这个284B的“演示级旗舰”过过瘾，还是老老实实跑30B的“日用级”？评论区聊聊你的选择。

明天同一时间，把LLM工程框架的整张地图铺开——从训练、微调到推理部署，每个环节的主流工具怎么选。CPU推理，只是那张地图的最末一环。

参考资料

llama-modchipGitHub仓库README（v2.4.0，量化与内存分配表、基准表、Quickstart）：https://github.com/synchopate/llama-modchip

HackerNews帖50411961（442分/196评论，antirez、adrian17、kgeist、sparse-Matrix、ar-nelson等实测与讨论）：https://news.ycombinator.com/item?id=50411961

GitHubAPI仓库数据（截至发文：685star/36fork/建仓2026-10-29/50commits/12openissues）：https://api.github.com/repos/synchopate/llama-modchip

DeepSeek-V4优化文档（四级分块推导与算子级剖析）：https://github.com/synchopate/llama-modchip/blob/main/docs/DEEPSEEK_V4_OPTIMIZATIONS.md

社区CPU榜单（Threadripper/M4Max/Graviton3等12类硬件实测）：https://github.com/synchopate/llama-modchip#community-cpu--hybrid-leaderboard