2.52GiB 还是 4.17GiB：量化档位的质量拐点到底在哪

几乎所有关于 Qwen3.5-4B-3D-Coder 的中文文章，都会给出同一句结论：内存紧就选 Q4_K_M（2.52 GiB），追求 3D 生成质量就选 Q8_0（4.17 GiB）。这句话没错，但它把一个本可以量化的问题，压缩成了一句无法验证的经验判断——拐点在哪里？为什么是 Q4 而不是 Q3_K_M？多花的 1.65 GiB 到底买到了什么？

本文不复述下载步骤，而是做三件更硬的事：用仓库里两个 GGUF 文件的真实字节数把体积账算到字节级；用 config.json 的注意力结构算出真正吃掉显存的其实是 KV Cache 而不是权重位宽；再给出一套能把"质量"变成可判定断言的验收脚本。结论会比"看内存选文件"稍微反直觉一点。

一、先把体积账算准：1.65 GiB 的边际，不是 2 倍

仓库里两个文件是 Git LFS 指针，指针里带着权威的字节数：

于是第一个容易踩的坑就出现了："2.52 GiB / 2.7 GB"与"4.17 GiB / 4.5 GB"这两组数字混着用并不矛盾，但如果你按 GB 去规划磁盘和显存，会凭空多算 7% 左右。在 8 GB 显存的机器上，这 7% 恰好是能不能跑起来的分界。

再看位宽。model.safetensors.index.json 的元数据写明total_parameters: 4539265536、total_size: 9078531072，后者除以参数正好是 2.0 字节/参数，与 config.json 里的"dtype": "float16"完全吻合，即 FP16 全量权重合计8.46 GiB（4 个分片，共 723 个张量，其中语言模型 426 个、视觉塔 297 个）。以此为基准算有效位宽：

• Q4_K_M：4.77 bit/参数
• Q8_0：7.90 bit/参数

Q4_K_M 的 4.77 高于 4.5，这个细节很重要：GGUF 的 K-quant 里M（Medium）本身就意味着文件内部是混合精度——并非整份文件都压在 4 bit，注意力输出、嵌入等敏感张量一般被抬到 6 bit 左右，剩下的才留在 4 bit。换句话说，"Q4_K_M 是不是质量跳水"这个问题，llama.cpp 的作者已经替你回答了一半：他们已经把最容易崩的张量单独保护起来了。

Q8_0 的 7.90 低于名义的 8.5 bit（8 bit 权重 + 每 32 个权重一个 FP16 缩放因子），这个差额来自张量精度策略差异与对齐填充。不要凭文件名推断每个张量的真实类型，要判断"这份文件到底混了什么"，唯一可靠的办法是逐张量核对：

# 需要 llama.cpp 的 gguf 读写脚本 python3 gguf-py/scripts/gguf_dump.py --no-tensors ./Qwen3.5-4B-3D-Coder-Q4_K_M.gguf

真正的结论在这里：你花的 1.65 GiB，买到的不是"从 4 bit 到 8 bit"的两倍精度，而是"从 4.77 bit 到 7.90 bit"的 1.66 倍有效位宽。在 4B 量级的模型上，这个增量通常体现在长程结构一致性和数值细节上，而不是在"能不能生成一个场景"上。

二、这个模型的显存主变量不是位宽，是 KV Cache

多数选型文章漏掉了 config.json 里最关键的一行："full_attention_interval": 4。这个模型共 32 层，layer_types数组明确给出了linear_attention与full_attention的 3:1 交替模式——只有 8 层是带完整 KV Cache 的注意力层，其余 24 层是线性注意力，只维持一个与上下文长度无关的常量状态。

这意味着 KV Cache 的算法很干净：每层 K 和 V 各num_key_value_heads(4) × head_dim(256)个 FP16 元素，即 4×256×2×2 = 4096 字节；乘 8 层，正好32 KiB/token。

两件事立刻浮出水面。

第一，1.65 GiB 的权重差额，等价于约 5.4 万 token 的 KV Cache。也就是说，省下 Q8→Q4 的那点空间，只够你把上下文从 32K 推到 86K 左右，或者反过来：如果你只写 16K 上下文，选 Q8 的总占用（4.67 GiB）甚至低于 Q4 开 128K 的总占用（6.52 GiB）。"内存受限就先降位宽"其实是次优解，先砍上下文往往更划算。

第二，max_position_embeddings标注的 262144 是模型能力上限，不是本地可部署上限。满上下文需要 8 GiB 的 KV Cache，单这一项就超过一张 8 GB 卡的全部显存——哪怕权重用 Q4 也不可能。生成一个自包含 HTML 的 3D 场景，输出通常在数千 token 量级，把上下文开到 128K 没有任何收益，只会让显存账单翻倍。

另外注意"partial_rotary_factor": 0.25与mrope_section: [11, 11, 10]：这是一个带多模态 RoPE 的混合结构，rope_theta高达 1e7。这类位置编码对权重量化并不额外敏感，但它解释了为什么社区里关于"长上下文跑不动"的抱怨，通常与量化档位无关，而纯粹是 KV 账算错了。

三、别把 MTP 的锅扣在量化上

这是选型中最危险的一个诊断混淆。

README.md 在生成参数表下面专门写了一条加粗提示：在 LM Studio 中必须关闭 multi-token prediction（MTP），因为 LM Studio 默认开启该选项。社区里流传的"LM Studio 跑不起来"的文章也明确指出了这一点，并强调该现象与 Q4_K_M / Q8_0 的量化格式无关。

从仓库能验证这条结论的底层原因。config.json 的 text_config 里保留了"mtp_num_hidden_layers": 1，"mtp_use_dedicated_embeddings": false——这宣告了架构上存在一个 MTP 头。但 model.safetensors.index.json 的 723 个张量键里，含mtp的键数量为 0。

也就是说：配置文件告诉运行时"我有一个 MTP 头"，权重文件却没有给出这个头的参数。愿意按配置去构建 MTP 路径的推理框架，会拿到一组未初始化/缺失的权重，输出自然表现为乱码、截断或干脆无响应。

这对本文的选题有直接方法论意义：如果你在 Q4_K_M 上看到乱码，并据此断定"4bit 不行"，那你测的其实是 MTP 兼容性，不是量化质量。一条简单的判定规则是——如果两个档位坏得一模一样，问题就不在量化上。同理，generation_config.json里写明的temperature 0.6 / top_k 20 / top_p 0.95 / repetition_penalty 1.0对两档通用，README 也明确"生成参数对两种量化保持不变"；任何"Q4 必须把温度调高"的说法，都是在用随机性掩盖配置错误。

四、把"质量"定义成可判定断言

这是整篇文章最需要较真的地方：对代码生成模型来说，perplexity 或 loss 的差异几乎是无效指标。

原因在于产物的形态。模型要输出的是一个单文件 HTML：一个大<script type="module">、几十个几何体、几百行变量声明。这类输出的失败模式不是"渐变"，而是二值——要么页面打开就是场景，要么白屏 + 控制台红字。首发损失 0.3% 的权重偏差，在长序列自回归里被逐 token 放大，最终集中体现在最容易出错的地方：重复声明的变量名。

README 的 Known issues 恰好证实了这一点：目前观察到的 bug"多为重复变量名，而非结构性问题"。这句话信息量很大——这个模型的失效点是有明确形态的，因此是可以被静态检查出来、并被计数的。

于是我建议把"质量"定义为三层可判定指标：

第一层，结构门（静态，零成本）。对输出做断言检查，不需要跑浏览器：

import re def audit(src): imports = re.findall(r"""from\s+'"['"]""", src) banned = [u for u in imports # 是否违反系统提示词的模块约束 if "examples/js" in u or "three/addons" in u or "unpkg" in u or "jsdelivr" in u] decls = re.findall(r"^(?:const|let|var)\s+([A-Za-z_$][\w$]*)", src, re.M) seen, dup = set(), [] for d in decls: # 顶层重复声明：README 点名的失效模式 dup.append(d) if d in seen else seen.add(d) bal = {p: src.count(p[0]) - src.count(p[1]) for p in ("{}", "()", "[]")} return { "bytes": len(src.encode()), "lines": src.count("\n") + 1, "banned_import": banned, # 必须为空 "module_ok": 'type="module"' in src, # 必须为 True "loop_ok": ("setAnimationLoop" in src) or ("requestAnimationFrame" in src), "three_syms": sorted(set(re.findall(r"new\s+THREE\.(\w+)", src))), # 复杂度代理 "dup_decl": dup, # 必须为空 "unbalanced": {k: v for k, v in bal.items() if v != 0}, # 必须为空 } def passed(r): return all([r["module_ok"], r["loop_ok"], not r["banned_import"], not r["dup_decl"], not r["unbalanced"]])

配合 README.md 给出的系统提示词（只允许从 cdnjs 引入three.module.min.js的 core ES module、不许引 addons、相机控制自己写），这套断言是完全可自动化的。注意three_syms这个字段——它统计new THREE.Xxx(...)里出现过的类名数量，是一个便宜的"场景构件丰富度"代理指标。同一提示词下，Q8_0 若稳定产出比 Q4_K_M 多 20% 的构件类型，那才是"质量更好"的可量化证据，而不是"看起来更精致"。

第二层，运行门。把 HTML 丢进无头浏览器，采集console.error数量、WebGL 警告、首帧耗时、以及renderer.info.render.calls（draw call 数）。白屏是可判定的；draw call 为 0 就是没渲染出来。

第三层，观感门。这一层才需要人。仓库里的画廊截图正是为此存在的——images/gallery 下有 10 张 SVG 封装的原始截图，覆盖园林、幻想、家具、机械四类。它们不能当质量指标用（截图字节数反映的是像素细节，不是代码质量），但适合作为"同一提示词换档位后"的人眼对照。

一个诚实的提醒：项目本身并未发布 Q4_K_M 与 Q8_0 的逐档质量对比数据。README 只说了 10 月 27 日检查点让两档的"一次成功率与整体场景质量都有明显提升"，并强调生成参数不变。任何声称"Q4 比 Q8 差 X%"的说法，都需要你自己按上面的协议测出来才算数：固定 20 条提示词 × 3 个种子 × 2 个档位，只改变量化文件，其余（温度 0.6、top-p 0.95、top-k 20、上下文长度）全部锁死。

五、显存受限时，折中方案应该怎么排

把权重、KV、运行时开销（计算缓冲、图优化、驱动）合起来估算，实用决策大致如下（开销按 0.7–1.2 GiB 估，含上下文与批处理波动）：

优先级的正确顺序是：先根据任务的输出长度定上下文，再用剩余的显存去选位宽。单文件 3D 场景的输出长度有限，把上下文从 128K 砍到 16K 能省 3.5 GiB，比 Q8→Q4 省下的 1.65 GiB 多了整整一倍。

在统一内存架构（核显、Apple Silicon）上，判断依据又会变：瓶颈从显存容量变成内存带宽，Q8_0 的每 token 权重读取量是 Q4 的 1.65 倍，解码吞吐会按大致相同的比例下降。这类机器上，先跑llama-bench把两组数测出来，比读任何选型文章都准：

llama-bench \ -m ./Qwen3.5-4B-3D-Coder-Q4_K_M.gguf \ -m ./Qwen3.5-4B-3D-Coder-Q8_0.gguf \ -p 512 -n 512 -fa 1

-p测的是预填充（受算力约束），-n测的是逐 token 解码（受带宽约束）。如果-n的差距明显大于 1.65 倍，说明你的平台已经进入带宽瓶颈，此时 Q8 的代价就不是"多 1.65 GiB 磁盘"，而是"生成时间多一倍"。

实际调用的完整参数可以这样固化下来（与 README.md 的参数表一致）：

llama-cli -m ./Qwen3.5-4B-3D-Coder-Q8_0.gguf \ -c 16384 -n 8192 \ --temp 0.6 --top-p 0.95 --top-k 20 --repeat-penalty 1.0 \ -sys "Use only the Three.js core ES module from https://cdnjs.cloudflare.com/ajax/libs/three.js/0.160.0/three.module.min.js. Do not import addons or legacy examples/js paths; implement any camera controls directly inside the HTML." \ -p "Make a standalone HTML scene with Three.js from cdnjs depicting an animated air traffic control tower with rotating radar and light signals."

六、分题材混合量化：从"选文件"到"选张量"

既然 Q4_K_M 的M已经证明"混合精度"是可行的工程手段，那么下一步就不是在两个文件之间二选一，而是按题材决定每个场景该走哪一档。

先看失效机理的差异。仓库画廊的 10 个场景大致可以分成两类：

• 结构重复型：体素发射场、日落村落、樱花庭院。代码主体是循环 + 参数化摆放，量化误差表现为个别方块位置偏差，人眼几乎不可见。
• 细节密集型：LGA 3647 插槽、鹈鹕自行车、书binding工作台。这类场景要靠大量独立数值去描述针脚阵列、辐条、装订线，误差会直接变成几何错位或索引错配。

这个分类是基于代码结构的推断，不是实测结论——但它给出一个可证伪的假设：在同一提示词下，Q4_K_M 相对 Q8_0 的一次通过率跌幅，在细节密集型题材上应显著大于结构重复型。验证方法就是上一节的三层指标，按题材分组统计。

要真正做"分题材混合量化"，仓库给了你完整的原料：FP16 全量权重（4 个 safetensors 分片）加上公开数据集 CCORE Three.js 3D Scenes（4,146 条，3,933 训练 / 213 验证，MIT 协议）。那 213 条验证集就是天然的校准语料，用它跑 imatrix，比用通用文本校准更贴合这个模型的真实 token 分布：

# 1) FP16 -> GGUF python3 convert_hf_to_gguf.py ./ --outfile fp16.gguf --outtype f16 # 2) 用本任务的真实提示词+代码做校准 llama-imatrix -m fp16.gguf -f ./calib-threejs.txt -o threejs.imatrix # 3) 带校准矩阵量化 llama-quantize --imatrix threejs.imatrix fp16.gguf Q4_K_M-imat.gguf Q4_K_M llama-quantize --imatrix threejs.imatrix fp16.gguf Q6_K-imat.gguf Q6_K

这里有两点必须说清楚，避免过度承诺。其一，imatrix 校准的收益主要落在低比特（Q4 及以下），在 Q8_0 上几乎没有空间——别忘了 Q8_0 已经是 7.90 bit/参数。其二，Q6_K 是一个被严重低估的中间档：它对标称 8.5 bit 的 Q8_0 只有约 20% 的体积削减，但在 4B 模型上，从 Q4 到 Q6 的这一步往往能跨过大部分"细节崩溃"的坎。如果你的显存在 8–12 GB 之间，Q6_K常常比"Q4 + 更小上下文"更优——这才是真正的质量拐点候选区间，而它恰好不在仓库现成的两个文件里。

混合部署在工程上也很轻：不改模型、不改提示词，只在调用侧按题材路由。

ROUTE = ("socket", "bike", "desk", "workbench", "mechanical") # 细节密集型关键词 def pick(prompt: str) -> str: hit = any(k in prompt.lower() for k in ROUTE) return "./Qwen3.5-4B-3D-Coder-Q8_0.gguf" if hit else "./Qwen3.5-4B-3D-Coder-Q4_K_M.gguf"

前提是两档必须来自同一个检查点——README.md 明确说明两个文件都含 10 月 27 日更新，并提醒早期下载过的用户重新拉取。混用不同检查点的权重做"分题材路由"，会让你测到的差异全部变成噪声。

结论：拐点的三条判定

把上面所有账合起来，"2.52 GiB 还是 4.17 GiB"这个问题有一个比"看内存"更可靠的答案：

第一，1.65 GiB 买到的是 1.66 倍有效位宽，不是 2 倍精度。而 Q4_K_M 内部已经是混合精度（4.77 bit > 4.5 bit），llama.cpp 已经替你把最脆弱的张量保护起来了，所以 Q4 的真实位置比"4bit"听起来要靠上得多。

第二，显存的主变量是上下文，不是位宽。只有 8 层全注意力的结构让 KV 成本低到 32 KiB/token，但 128K 上下文依然要 4 GiB——比两档权重差额的 2.4 倍还多。任何在 8 GB 卡上纠结 Q4/Q8 的人，先确认自己真的要开多长的上下文。

第三，真正的质量拐点大概率不在现有的两个文件之间，而在 Q4_K_M 与 Q6_K 之间。因为在这个模型上，失败不是"画面略糙"，而是"变量重名导致白屏"这种二值事件；能决定成败的是长程结构一致性，而这正是 4 bit 与 6 bit 之间的跨度最敏感、6 bit 与 8 bit 之间边际收益递减的区间。要找到你自己机器上的那个点，靠的不是别人写的对比表，而是固定提示词、固定参数、只换量化文件，用可判定断言跑出来的那一组通过率。

顺带一提，如果你在 Q4_K_M 上看到了乱码，先去 LM Studio 里把 MTP 关掉，再回来谈量化。