训练与合并解决的是「模型变强」。真正进业务，还经常要面对 llama.cpp 生态、更小体积与更高吞吐——愿意用一点精度换部署成本。于是进入：导出 GGUF → 量化 → 用同一评测集验收。

这是「多模态微调实战」的第 08 篇。这一步决定模型能否装进内存紧张的本地 / 边缘环境。

说明：多模态 VLM 的 GGUF 导出链路比纯文本更挑版本与转换脚本。本文按「你已能把合并后的模型转到 GGUF」来写验收与取舍；具体转换命令请对齐你使用的 llama.cpp / 转换工具版本。

一、为什么还要 GGUF

诉求 GGUF 的价值
本地推理 llama.cpp / 各类绑定成熟
量化灵活 Q8 / Q4 / IQ 等一堆档位
分发 单文件或少量文件，运维简单
边缘 INT4 可明显降带宽与内存

代价是：多模态支持要确认工具链版本；量化必然有精度损失；评测必须用同一套验证集与同一套指标脚本。

二、推荐对比矩阵

至少做三档（能做几档做几档）：

版本 目的
HF 合并模型（bf16/fp16） 精度上限参考
GGUF F16（或接近） 看「格式转换」有没有伤任务
GGUF INT4（如 Q4_K_M） 看量化代价

关键问题：

  1. 转 GGUF（F16）相对 HF，任务指标掉多少？
  2. INT4 相对 F16，再掉多少？

三、一次实践中的观察（脱敏）

在相同评测集、相同指标口径下，实践结论可以概括为：

  1. GGUF F16：相对合并后的高精度权重，验证集任务表现没有明显下滑——说明转换链路基本可信，问题不在「导出把模型弄坏了」。
  2. GGUF INT4：相对 F16，综合精度大约下降 6.5 个百分点——属于可预期的量化损失，需要业务决定是否可接受。

解读建议：

  • 若你的业务 Exact Match 从 98% → 91.5%，可能仍可用；
  • 若从 90% → 83.5%，也许就得改用 Q5/Q8，或保留 GPU 上的 HF/vLLM 路径；
  • 「掉 6.5 个点」要写进发布说明，避免线上只看体积不看指标。

精确数字会随量化算法、校准数据、解码参数变化。发布时请附上你自己的评测表，不要只抄别人的百分点。

四、量化后验收清单

对每个候选 GGUF 文件：

  1. 可加载：llama-cli / llama-server 能启动；
  2. 格式正确：输出仍是规范车牌字符串，而不是聊天废话；
  3. 批量指标：跑与 HF 相同的验证集脚本；
  4. 坏例分析：抽 20～50 个错误样本，看是「量化糊了」还是「本来就会错」；
  5. 延迟与显存/内存：记下 p50/p95，作为选型依据。

建议输出一张表：

模型 Exact Match Char Acc 体积 备注
HF merged … … … 上限
GGUF F16 … … … 转换无损？
GGUF INT4 … … … 掉点是否可接受

五、工程注意

  1. Chat template：SFT 后模型往往依赖特定模板；GGUF 侧要配置一致，否则「模型没坏，提示包装坏了」。
  2. 随机性：评测时关掉采样，保证可复现。
  3. 不要在量化后再做一次「悄悄改提示词」，否则对比失效。
  4. 备份 HF 合并目录：GGUF 出问题还能回退。

六、选型建议

场景 更稳妥选择
在线服务、GPU 充足 HF / 加速引擎，尽量不量化或轻度量化
本地工具、内存紧张 INT4，接受约数个百分点损失
要归档「官方精度」 保留 F16 GGUF + HF merged 双备份
争议样本多 先别上 INT4，或提高量化档位

七、小结

到这里，一条完整链路是：

1
数据 → LoRA SFT → 选 checkpoint → merge →（可选）GGUF →（可选）INT4 → 评测验收

你已经具备「可训练、可合并、可部署、可量化对比」的闭环。

多模态微调实战第 08 篇完。下一篇：把这次实践里真正耗时间的坑集中列出来备查。