一张用了些年头的 3090，单卡、物理显存 24G，运行时刻把显存上限锁在 12G，功耗墙压到 300W，就这点家底，里面塞进去的是一个 270 亿参数的模型，还要给它开 12.8 万字的上下文窗口。

这事最近在圈子里被反复提起，起因是这样一条推文：一家叫 Mirai Labs 的团队把 Qwen 3.8-27B 压到了 2.4 bit，有人把这份权重搬进了 llama.cpp，于是同一颗模型就在一张消费级显卡上跑起来了。

推文里那组数字，第一眼看是"能跑"，第二眼看才是真东西：解码大约 40 token/s，上下文深到 6.2 万字时还能维持 34 到 35 token/s，预填大约 1000 token/s。

2.4bit 是个什么量级

先把尺子摆出来。按原生 16 bit 存权重，一颗 270 亿参数的模型要五十多 GB 打底，24G 的卡连边都摸不上。量化的活儿就是给每个权重换个更瘦的盒子：4 bit 装 16 个档位，2 bit 装 4 个，1 bit 只剩正负两档，中间没有退路。

2.4 bit 的意思是每个权重平均占 2.4 个 bit。算出来权重大概 8 GB 出头。拿这颗模型常见的 4 bit 档对照，16.8 GB 左右的文件压到这里，等于又砍掉一大截。

不过压缩从来不是换个盒子就完事。常规路子是先把权重算成低精度，再打包成 GGUF，中间那一趟早就把原表示改写掉了。Mirai 这套走的是另一条：他们那个格式用格点编码（trellis），每权重 2 到 3 bit，码本是运行时按哈希现算的，压缩后的编码整个原样搬进 GGUF，一个 bit 都没动。做移植的人也挑明了讲，这里没有二次量化，不是"先解压、再套一套新量化方案"，原始表示保住了。

这就是这条和普通量化帖子的分水岭。模型没换，权重一个字节没重算，动的是承载权重的那个格式。换了汤，药还是那味药。

12G 的账本要这么算

显存这笔账，得拆成三块：权重、KV 缓存、计算缓冲。

权重那块，按这份转换件仓库的数据，模型本体加上 MTP 模块一共 11.2 GB，其中词嵌入那 2.5 GB 放在系统内存里，真进 GPU 的是 7.8 GB。剩下两块才是拼 12G 预算的地方。

KV 缓存是随上下文线性长起来的那份状态，每来一个 token 就记一笔，上下文拉到 12.8 万字，这笔账就很可观了。于是同样的 12G 里，装多长的上下文全看 KV 用几档：

• KV 用 Q4：12.8 万字上下文，总峰值显存 11.3 GB
• KV 换成更准的 Q8：只能放到 7.4 万字，总峰值 11.1 GB
• 同样的卡，换成 vLLM 加 BF16 的 KV：只能撑到 3.76 万字
• vLLM 加 FP8 的 KV：7.44 万字

四行摆一起，意思很清楚：KV 从 BF16 换到 Q4，等于凭空多出三万多字的上下文余量。这也解释了为什么大家这两年揪着 KV 缓存量化不放：同一个池子里挤出来的水，攒下来的就是上下文余量。

还有个小陷阱。服务端开的服务槽位，每个槽都有自己的一份状态，默认槽位数会平白吃掉 450 MB 上下（同样 12.8 万字会涨到 11.7 GB）。对 12G 的卡来说，这几百 MB 就是“还能不能开得动”的区别。

所以那句“128K 上下文吃掉 11.3 GB”要这么读：这 11.3 GB 里不全是 KV 缓存的份额，7.8 GB 是权重，剩下才是 KV 缓存和计算缓冲，几块加起来峰值 11.3 GB，刚好卡在 12G 的边界上。分寸拿捏到这个程度，才是这篇真正值钱的地方。增之一分则太长，减之一分则太短。

把非标准格式塞进 llama.cpp，难在哪

llama.cpp 认的是一套固定类型的权重。Mirai 这个格式不是它的原生菜，移植的人得给它补四类新的 ggml 类型、补新的算子，还得接上 Mirai 自己的 CUDA kernel，主线版本和主流的桌面工具根本加载不了这份文件。

三条计算通路是分开做的：

• 单 token 解码走 DP4A 的 GEMV
• 大批量走 INT8 的张量核心 MMA
• 预填走 cuBLASLt 的 INT8 GEMM

长上下文还有个有意思的坑。这颗模型是混合结构，注意力层里 KV 头按 6 比 1 分组，解码的时候同一批 K 头会被反复读。把六份头打包成一个块以后，6.4 万字上下文的解码从 27.9 token/s 提到 35.2 token/s；DeltaNet 那几层再补一个分块 kernel，预填又多出 11%。

不难看出，40 token/s 这个数不是白捡的，是一层一层抠出来的。耳闻之不如目见之，目见之不如足践之。同一份权重换个引擎跑，脾气完全不一样。

质量到底掉了没有

2 bit 这个档位一直有争议，所以 Mirai 自己贴出来的那组评测才有看头。他们在 AppWorld 上给的对照：2.4 bit 版 57.9%，BF16 老师版 55.8%；最难的那 34 道题，2.4 bit 52.9%，BF16 41.2%。按这组数，压到 2.4 bit 不但没塌，在最难的活儿上还反超了。

但另一半也要写清楚：状态检查这一项 2.4 bit 是 74.6%，BF16 是 83.3%，这块确实掉了近九个点。同档位里另外两个 2 bit 方案更低，Bonsai 2（2.1 bit/权重）42.5%，GSQ-RCO 的 IQ2_XS（2.5 bit/权重）33.3%。这些都出自 Mirai 自测，不是独立第三方跑的，题量只有 80 道，几个点的差要小心解读。

第三方这边，有团队对这一代模型做过一轮量化横评，被行业站转述的结论是：4 bit 档基本贴住全精度，掉到 1 bit 档会整体崩。也就是说 2 bit 这个区间本身就是刀尖上跳舞，能在这区间把最难的任务保住，含金量比分数本身高。

各方怎么看

Mirai Labs 是 2024 年成立的一家公司，做端侧模型、推理运行时和量化栈，思路是把模型、运行时、硬件当三件事一起管。他们之前给小尺寸模型出过 4 bit 和 8 bit 的自家量化版本，官方博客的说法是同等质量下比 llama.cpp 和 MLX 快 40% 到 60%。这次这颗 2.4 bit 的格点格式，是这套路子往大号模型上的一次外推。

放到更大的背景里看，Qwen 3.8-27B 是今年 8 月放出来的开源权重，参数量 270 亿，一出来社区量化就跟上了，Unsloth 这类团队几天内就出了几个档位，Q5_K_M 大约 22 GB 的档位已经能在 3090、4090 这类卡上跑。也就是说，正常情况下一颗 27B 的模型，门槛在 24G 这个档。

现在这个版本把门槛往下拽了一大截：Hugging Face 上那份社区转换件用的是 Apache 2.0 协议，README 自己也写明了，这不是 Mirai 的官方发布版本，是社区转换出来的。跑起来得用配套的 llama.cpp 分支，主线版本和主流的桌面软件装不上。

有意思的细节是验证方式。做移植的人在贪心解码下拿 llama.cpp 的输出和 Mirai 自家 vLLM 插件的输出对了一遍，两边一致。这一步看着不起眼，其实很关键：一个跑得很快的本地移植，如果悄悄把模型行为改了，那跑得再快也没意义。自己动手跑一遍、拿输出对一遍，比看谁的速度数字漂亮靠谱得多。

真正变的是什么

视频里那些东西，是同一颗模型当智能体做出来的：11 个工程，每个都从一句话起步，少数几个要追加一句指令，其中一个彻底跑歪。原先这套跑在 vLLM 加 3090 的组合上，现在同一份权重可以走 llama.cpp。

推文结尾那句我觉得说到了点子上：模型没变，权重没变，变的是压缩格式、KV 缓存策略和推理引擎。一只 27B 的模型压到 2.4 bit 听着夸张，可换个问法就没那么玄：我手上这块卡，到底塞得下多少能力？

答案是：12G 显存预算、Q4 的 KV 缓存、12.8 万字上下文、解码 40 token/s 上下、预填 1000 token/s 上下。数字不好看，但它是能天天开着的那种机器。

所以激进量化这几年味道变了。目标早就换了方向：早先只想着把 27B 做小一点，如今琢磨的是怎么把一个原本不方便跑的模型，变成你敢在自己那张卡上让它长开着的东西。旧时王谢堂前燕，飞入寻常百姓家：从前要整机级别的预算才够用的 270 亿参数，现在一张二手卡就能把它支起来干活。

原文链接：
https://x.com/Oluwaphilemon1/status/2105845916389220714