6.1 导出与量化：GGUF 与量化档位
6.1 导出与量化：GGUF 与量化档位
本节摘要：PyTorch checkpoint 离"能用的产品"还有一步格式转换。本节先讲 GGUF——llama.cpp 生态的单文件模型格式：权重、词表、聊天模板等元数据打包进一个文件，拷走即用，CPU 与 GPU 混合推理都吃这个格式。然后是两步导出：convert 把 HF 权重转成 f16 GGUF（此步必须带上模板与终止符——4.3"一份模板、三处消费"的第三处），quantize 从 f16 源压出各量化档位。档位选择的三个常识：Q8_0 近无损、Q4_K_M 是大小与质量的常用平衡点、越小的档位伤得越重——且参数越少的模型对同一档位越敏感，124M 模型慎用重档。最后用 5.2 的回归题库做量化前后的验收入账。
学习目标
阅读完本节，你应当能够：
- 说出 GGUF 格式解决的两个问题（单文件交付、量化容器）。
- 完成两步导出并解释每步携带了什么。
- 按大小/速度/质量三角为场景选档位，说明小模型为何更怕量化。
- 用回归题库对量化前后打分，把损失记进台账。
一、GGUF：模型的行李箱
部署环境与训练环境最大的差异：目标机器可能没有 PyTorch、没有 GPU、甚至只想拷一个文件走人。GGUF（llama.cpp 的模型文件格式）为此而生：
| 需求 | GGUF 的回应 |
|---|---|
| 单文件交付 | 权重 + 词表 + 模板等元数据打进一个 .gguf，无伴生目录 |
| 脱离训练框架 | llama.cpp 自带推理引擎，不需要 Python/PyTorch 环境 |
| 量化容器 | 同一格式内支持从 f16 到低比特的各档位 |
| CPU 友好 | 量化后可在纯 CPU 上跑出可用速度，GPU 只是可选加速 |
⚠️ 行李箱里装的模板与终止符，就是 4.3 节"一份模板、三处消费"的第三处消费点。转换完成后必须做回环校验（本节第四节）：部署侧渲染出的 token 序列，要与训练侧 tokenizer 渲染的逐位一致——错位三的部署版（永不停/腰斩）在这里批量发生。
二、两步导出
# export_gguf.sh —— HF 权重转 GGUF 并量化（写法示意，以 llama.cpp 官方仓库 README 为准） # 前置：克隆 llama.cpp 仓库；工具名与参数随版本演进，动手前先对 README # 第一步：转换——把 HF 目录（权重+词表+模板）转成 f16 GGUF 单文件 python convert_hf_to_gguf.py runs/sft_124m/final \ --outfile chat_model/sft_124m_f16.gguf --outtype f16 # 第二步：量化——从 f16 源压出两档常用位 ./llama-quantize chat_model/sft_124m_f16.gguf chat_model/sft_124m_q8_0.gguf Q8_0 ./llama-quantize chat_model/sft_124m_f16.gguf chat_model/sft_124m_q4_k_m.gguf Q4_K_M
三个工程纪律：
- 量化永远从 f16 源压，不要"量化套量化"——误差会叠加；
- 转换前确认
runs/sft_124m/final/里权重、词表、模板同目录同源（3.3/4.3 的存档纪律此时兑现——目录错了，行李箱装错东西）； - 导出后立即冒烟：用 llama.cpp 自带的命令行推理工具问一句话，确认会停、身份正常（工具用法以官方 README 为准）。
三、量化档位：大小、速度、质量三角
量化的本质：把 fp16 的权重压成低比特整数（K-quants 系列还会按权重重要性分组，重要的层保更高的比特）。124M 模型的体积对照（示意估算，实际以转换工具输出为准）：
| 档位 | 每权重比特 | 124M 体积 | 速度（相对 f16，示意） | 质量损失 |
|---|---|---|---|---|
| f16 基线 | 16 | ~248 MB | 1× | 无 |
| Q8_0 | ~8.5 | ~132 MB | 持平或略快 | 近无损，常规困惑度测试几乎不可辨 |
| Q6_K | ~6.6 | ~102 MB | 更快 | 轻微 |
| Q5_K_M | ~5.7 | ~89 MB | 快 | 小 |
| Q4_K_M | ~4.8 | ~75 MB | 快 | 常用平衡点：偶见措辞变化，主体行为保持 |
| Q3_K_M | ~3.9 | ~61 MB | 更快 | 明显，小模型不推荐 |
| Q2_K | ~2.6 | ~47 MB | 最快档之一 | 大，叙事开始破绽 |
选档三规则：
- Q8_0 起步：磁盘不是瓶颈就先近无损，把变量留给自己；
- 空间紧再降 Q4_K_M：约一半体积、常规可用；要再往下，先过第四节的验收；
- 模型越小越怕量化：124M 的每个权重承载的信息密度比 7B 高得多，同样的低比特档位在小模型上伤得更重——"越小越伤"是铁律，重档留给大模型。
💡 为什么大模型敢压狠：参数冗余度高，单权重信息密度低，低比特丢掉的多是冗余。这与 8.2 节的规模实验互为注脚——模型规模改变一切下游决策，包括你敢压到哪一档。
💡 想要更客观的量化损失度量，llama.cpp 自带困惑度测评工具（对一段留出文本逐档计算，用法以官方 README 为准）——它比"人眼读几条"严格，但比不过 5.2 题库贴近你的真实场景：两个都跑，台账里各记一列。
四、部署前回环校验与量化验收
两道验收，缺一不可：
校验一：模板回环（4.3 的部署版）。 用同一段 messages 分别经训练侧 tokenizer 与部署侧引擎渲染，token 序列应逐位一致；终止符 id 以 4.3 诊断脚本的输出为准配进部署配置，不手填数字。十条消息、一次比对，拦掉部署阶段的大半事故。
校验二：量化回归（5.2 的台账入账）。 用冻结题库 + 贪心解码分别对 f16 与量化档各评一轮：六维均分差与致命零分率变化记进台账。经验阈值（示意参考）：Q8_0 分差应约等于 0；Q4_K_M 允许小分差，但致命零分率不得上升——升了就回退上一档，不带病上线。台账示例行（一行电子表格）：
模型 | 档位 | 题库版本 | 解码 | 六维均分差 | 致命零分率变化 | 结论 sft_124m | Q4_K_M | v1 | 贪心 | -0.05 | +0 | 通过，交付此档
本节要点回顾
- GGUF = 单文件交付 + 量化容器；转换携带词表与模板——4.3 的第三处消费点，回环校验必做。
- 两步导出：convert 出 f16 源，quantize 从源压档；量化不套量化；导出即冒烟。
- 选档：Q8_0 近无损起步，Q4_K_M 平衡点，越小越伤——124M 慎用 Q3 以下；量化损失用 5.2 题库入账。
文件备好了，6.2 节把它变成一个能被脚本、浏览器与语音回路调用的本地服务。