跳到正文
ChatGPT Pro 俱乐部
自营中转站
博客

llama-modchip：284B 塞进 64GB，平均只有 1.71 bit

19 阅读约 12 分钟读完

11 月 8 日，一个叫 llama-modchip 的项目在 Hacker News 上拿到 221 分、65 条评论，标题很直接：「284B DeepSeek，64GB 内存，无 GPU」。

它没有造新模型，做的事是把 DeepSeek-V4-Flash-0731 压到 56.56 GiB，然后在一台 16 核、64GB DDR5、完全没有显卡的 AMD 笔记本上跑起来：预填充 44.36 tok/s，生成 9.06–10.74 tok/s，开投机解码后 11.5–14.7 tok/s。仓库 10 月 29 日建，到现在 334 星、Apache-2.0，最新版 v2.4.0（11 月 4 日）。

这件事值得写，不是因为「本地大模型又行了」这类话——而是因为它的数字经得起核对，但必须按正确的读法核对。评论区一半人在问「到底几 bit」，另一半人说「低于 4 bit 全是废的」，两边都没说错，只是说的不是同一件事。

一句话结论

  • 它跑的是真的全量模型，不是剪枝成小模型的「仿制品」。DeepSeek 官方 config 里 43 层、256 个路由专家、每 token 取 6 个，权重文件一个都不少。284.33B 总参数 / 13.17B 激活这个数字和官方结构对得上。
  • 「3.75 bpw」是标签，不是全文件的平均值。那个标签指的是注意力那部分张量；占体积大头的专家权重压到了 1.56 bpw。按整个文件算，平均只有 1.71 bit/权重——比 2 bit 还低。这是全篇最该记住的数字。
  • 速度是真的，但机器挑得很死。44 tok/s 预填充靠的是 AVX-512BW 加四层缓存分块，那个 16 核 Zen 5 平台有 64MB L3。同样 64GB 内存的老机器拿不到这个数——仓库里唯一一台老 U（Ryzen 7 5700U）跑 30B 小模型只有 14.35 tok/s。
  • 284B 这一档还没被第三方复现。我翻了仓库里全部 5 个社区跑分 issue（Graviton3、9950X、EPYC 7402P、8745H、5700U），用的全是 30B 的 Nemotron，没有一个跑 284B。56.56 GiB 这个成果目前只有作者自己的机器有数据。
  • 更适合当「技术样本」看，不要当「省显卡方案」用。它证明的是「大 MoE 的激活稀疏性能被极端量化 + 缓存工程吃回来多少」，不是「你可以拿家用机替代 GPU 集群」。
一台小型透明机箱里塞着完整的服务器主板与散热器
把原本要一整个机柜的东西塞进一个小盒子，是这个项目想做的事——代价是每一层都得重新算一遍。

1）先核对：它跑的到底是什么

这类「XXB 模型塞进 YYGB 内存」的项目，第一件要查的从来不是跑分，是模型结构对不对得上。因为最容易的做法是拿一个小模型换个名字。

对照 deepseek-ai/DeepSeek-V4-Flash-0731 的官方 config.json：43 层、hidden_size 4096、moe_intermediate_size 2048、256 个路由专家、每 token 激活 6 个，外加 1 个共享专家，MLA 注意力、max_position_embeddings 1048576。按这个结构算专家权重：单个专家 3 × 4096 × 2048 ≈ 25.16M 参数，乘以 256 专家 × 43 层 ≈ 277B，加上注意力、嵌入、共享专家，284.33B 是对得上的。

激活参数同理：每 token 走 6 个路由专家加 1 个共享专家，专家侧约 7.6B，算上 MLA 那套 q_lora/rq_b/kv 的低秩投影，落到仓库说的 13.17B 是合理量级。官方模型卡没直接登出总参数，只写了「比 V4-Pro 的激活参数少得多」。

所以第一层结论：这是货真价实的 284B MoE，不是缩小版。它的盘上体积我直接查了 Hugging Face 上的三个分片，加起来 60,729,886,080 字节 = 56.56 GiB，和仓库自称的一致。

2）56.56 GiB 是怎么挤出来的：三刀，切在不同地方

这里就是评论区吵架的地方。先说清楚：这个项目没有用一个统一的量化等级，它对不同张量下了三刀，力度完全不同。

切在哪用了什么等效位宽省下多少
路由专家 ffn_gate_exps / ffn_up_exps（占体积绝对大头）IQ1_S 超级块，但按 SwiGLU 的二阶 Hessian 交叉投影行范数重新加权误差1.56 bpw-15.49 GiB
MLA 的 attn_k_b 与稀疏 indexer自定义 Q2_0 块：64 个权重一个块，FP16 缩放 + FP16 零点，Lloyd-Max 迭代 24 次3.75 bpw-4.82 GiB
所有密集层：attn_q_a/q_b、attn_v_b、attn_wo、共享专家 shexp、前 3 层、嵌入不动，保留 Q5_K / Q6_K / F32≈5–6 bpw0
数据来源：项目 Hugging Face 模型卡「How 56.56 GiB Was Achieved」一节。

三刀合起来，整个文件 60,729,886,080 字节除以 284.33B 参数——平均 1.71 bit/权重。这就是为什么有人问「到底几 bit」时，作者答「3.75」，HN 上立刻有人算出来不对：3.75 bpw 摊到 284B 参数应该是 124 GiB，不可能装进 56 GiB。两边都没错，标签写的是局部，读者看的是整体。

这三个数字里，真正决定能不能用的是一个没写在标题上的：密集层一点没动。所有注意力投影、共享专家、嵌入都留在 5–6 bit。这也解释了为什么质量没有立刻崩——被压到 1.56 bit 的只有专家，而 MoE 的专家本来就是稀疏激活的，单个 token 只碰 7 个。

3）质量到底掉了多少：它有给数据，但要看清是哪种口径

仓库给了一张消融表，用「概率余弦相似度 / top-10 KL / 困惑度变化 / top-1 命中率」四个指标，对比全精度（Top-6 那档）。节选三档：

运行时档位生成速度概率余弦KL（nats）困惑度变化Top-1 命中
Top-6 无损（默认）9.06 tok/s1.000000.00000.00%（逐位一致）100%
Top-5 甜点档9.68 tok/s0.997140.0042+0.42%95.8%
Top-4 涡轮档10.12 tok/s0.991260.0281+2.85%95.8%
数据来源：仓库 docs/DEEPSEEK_V4_OPTIMIZATIONS.md 第 3.2 节。

两个要点。第一，Top-6 那档号称「逐位一致」——意思是量化本身用浮点模拟算出来的概率完全一样，所以默认配置下你拿到的是全精度输出，只是慢一点。第二，Top-4 只快 11%，困惑度多 2.85%，性价比很差。想提速度，正确的做法是开投机解码（PVS），别砍专家。

不过这张表的性质要说清：它是项目自己写脚本量出来的，不是独立第三方跑的标准 benchmark（MMLU、Terminal Bench 那类）。仓库里有个 eval_quality_and_tools.py，647 行，测的是工具调用格式、代码题、长文检索这类「能不能干活」的东西，满分 100。这些数字说明自洽，不能等同于「在标准评测上不掉分」。

4）llama-modchip 的 README 与官方数字对不上的几处

HN 上最毒的那条评论说「README 是 AI 味的糊，读不明白」，而且举了几个具体矛盾。我把这些逐条查了，有对的，也有他查错方向的：

  • 「76.87 GiB 到底是哪个量化」——这条质疑站得住，答案也查到了。我去量了 unsloth/DeepSeek-V4-Flash-0731-GGUF 的分片：UD-IQ1_S 正好 76.87 GiB，UD-IQ2_XXS 是 84.62 GiB（≈90.9 GB）。所以「76.87 GiB」这个基线是 IQ1_S 的量，README 把它写成「IQ1_S / IQ2_XXS 都是 76.87」是错的；评论里说「unsloth 的 IQ2_XXS 有 91GB」也是对的。两边各说对一半，项目这句话该改。
  • 「61 层、top-8 激活」和官方 config 不符。项目模型卡写的是 61 层、256 专家 top-8，而 DeepSeek 官方 config 是 43 层、top-6。这类描述性数字不影响文件能不能跑（结构从权重里读），但会让读者对不齐表格，也算 README 该修的地方。
  • 自定义张量类型的编号撞车了。项目声明用的是 GGML_TYPE_Q2_0 = 40。我去看了 llama.cpp 上游现版本的 ggml.h：40 是 NVFP4，41 是 Q1_0，42 才是 Q2_0。而且上游 block_q2_0 的结构是 64 权重 + 一个 FP16 缩放（18 字节/64），项目的块是 30 字节/64（缩放 + 零点）。名字一样、编号冲突、块布局还不同——所以必须用它的补丁二进制这一点是真的，而且新版上游二进制遇到这个文件更可能当成 NVFP4 去解析，而不是老老实实报错。
  • 那个「13 毫秒恢复」也有前提。它指的是把 Claude Code 一次请求的 KV 缓存放在 /dev/shm 里预热复用，省掉 45 秒的冷启动 prefill。这对「同一个仓库连续问十几轮」的 agent 场景有效，对单次对话没用。注意这是复用缓存，不是让模型变快。

5）HN 上的分歧：快是真的，能不能用是另一件事

评论区值得看，因为两边吵的其实是两个层面的问题。

反方主要是「位宽不可信」这条线。置顶的几条都在问量化等级，然后立刻自答：低于 4 bit 基本不能用。有人贴了经验结论：量化的性能不是线性的，性价比峰值在 4 bit，再往下掉得很快。这条对通用模型是对的，但这个项目的特殊之处在于被压到 1.56 bit 的只有稀疏激活的专家层，密集层保持在 5–6 bit——所以「2 bit 一定废」这个经验在这里不能直接套。

正方最强的一票来自 Redis 作者 antirez：他说如果是 128GB 统一内存的机器，这东西不只是能跑，还能跑得挺快，附了自己的实测视频，预填充约 300 tok/s，并说作为 coding agent「可以接受」。但也有人当场拆：视频里 43 个输入 token 花了约 4 秒，按 coding agent 每轮几千 token 的消耗算，探索一个文件就一分钟起步，谈不上「可以接受」。

这个争执的落点其实很清楚：9 tok/s 的生成速度，是人读得比它写得快的速度。一位在 5700U 上跑社区跑分的人说「它的输出比我能读的速度稍快一点」——这句夸奖同时也就是它的上限：你能等，但 agent 那种几百次往返的用法等不了。

6）适合谁，以及自己动手前该看哪三个数

不给笼统建议，给判据。想试这个方向，先看三个数：

  • 内存带宽，不是内存容量。CPU 上跑 MoE，瓶颈几乎全在 DRAM 带宽上，生成速度大致和「每 token 要读多少权重 / 带宽」成正比。这是为什么同一份文件在 Threadripper 上能到 80 tok/s、在 5700U 上只有 14（而且那是 30B 那个小的）。容量只决定装不装得下。
  • 有没有 AVX-512BW 和足够大的 L3。44 tok/s 的预填充是「寄存器 + L1 + L2 + L3 四级分块」硬怼出来的，Zen 5 桌面/笔记本平台才有这条件。老平台或者 Apple Silicon 走的是完全不同的一套路径，别人贴的跑分对你没有参考价值。
  • 你的用法是单轮还是多轮。单轮问答：9 tok/s 够呛但能忍。连续 coding agent：必须靠 KV 缓存预热才能用，而且只在 Linux（/dev/shm）上有完整实现。

另外提一件和安全有关的事：这个项目附带一个 sse_gateway.py（1935 行），做的事是把模型的工具调用解析出来在本机执行，用来接 Claude Code。11 月 3 日有人提了一个安全 PR，指出这里两个风险：解析工具调用时没有按客户端注册的 schemas 做白名单校验（模型从外部文件里抄一段 XML 就能调任意工具），以及把 Write 悄悄改写成 base64 编码的 Bash 命令落盘。

那个 PR 被关掉了（未合并），但仓库 main 上确实落了同名的加固 commit（00fbdc2f，11 月 3 日 14:31），现在的 try_parse_tool_call() 里已经有 schemas 白名单判断，base64 那条路径也改成了必须显式设 MODCHIP_EXPERIMENTAL_BASH_WRITE=1 才开。结论：现在的版本比最初安全，但这个组件本质上是「让模型输出在你机器上执行命令」，跑之前自己心里要清楚。

小结

llama-modchip 是这半年里少见的、值得认真读一遍 README 的项目。它的核心贡献不是「又一个本地量化」，而是把三件通常分开讨论的事叠在一起：按 SwiGLU 二阶矩重加权的一比特专家量化、按缓存层级和线程绑核重新排的预填充分块、把 KV 缓存放进共享内存让 agent 轮次几乎零启动。每一项都有可复现的取舍数据，这是它比同类「我 3 tok/s 也能跑」的帖子高一个档次的地方。

但也别把它当结论消费。三个必须带着的限定：全文件平均 1.71 bit/权重（不是 3.75）；284B 这一档还没有第三方复现，社区跑分清一色是 30B；速度数字强绑定 Zen 5 + AVX-512BW + 64MB L3，换平台就换一套数。

如果你正在攒一台「不买显卡、本地跑大 MoE」的机器，这个项目的价值是给你一个参照系：在 64GB DDR5 这一档，全量 284B 的下限大概是 9 tok/s 生成、44 tok/s 预填充，能不能接受这个速度，是你自己的判断题，不是它的宣传语能替你答的。

参考来源

文中所有体积、速度、评分数字均来自上列来源，未经独立复现。项目自述的 284B 各项数据目前只有作者本人的机器有公开记录。

相关文章

发表评论

邮箱不会公开，带 * 的是必填项。