SuperAPI AI 工具集

quantized-export

智能体与模型

查看项目

更新于 10-16 07:31

技能介绍

Quantized Export 是一个部署前导出技能,处于检查点晋级(checkpoint-promotion)之后。它只在检查点获得 PROMOTE 判定后启动;REJECT 的检查点不会进入此流程。它的目标是:让已晋级的检查点以适合目标运行时环境的格式导出,并证明导出后仍然可用。

输入与输出

输入为一个已晋级的检查点(或 LoRA 适配器),加上目标部署条件——GPU 级别、服务栈,以及是否涉及长上下文、代码或数学类工作负载。输出为选定格式的导出产物,外加一份冒烟测试差异报告,对比导出前与导出后 3–5 条黄金输出的结果。

格式选择(Format Map)

格式应按硬件与部署形态选择,而非凭习惯。

FP8:Hopper 级及更新 GPU 上的默认选择。它在约一半内存占用下保持接近 bf16 的质量,只要目标 GPU 支持且不受边缘设备约束,就是安全的首选。

AWQ INT4:面向早于 FP8 硬件支持的旧 GPU。新部署中 GPTQ 已被取代——同等位宽下 AWQ 精度保留更好,且当前工具支持更广。

带 imatrix 构建的 GGUF Q4_K_M:边缘/llama.cpp 格式,适合本地或 CPU 相邻部署,不适合 GPU 服务吞吐——它优化的是体积而非数据中心 GPU 上的 token/秒。

NVFP4:仅面向 Blackwell 规模的部署,且明确不适用于 GB10。在 SM121(GB10)上 NVFP4 比 FP8 慢约 32%,因为硬件缺少原生 cvt.e2m1x2 路径,除非内核按 sm_121a 编译。在 GB10 目标上选 NVFP4 是性能回退而非升级,应改用 FP8。

合并式与仅 LoRA 是独立于量化格式的另一维度。合并式导出把适配器折入基础权重:产物更大,但服务时无基础模型依赖。仅 LoRA 保持适配器独立:产物小得多,但服务栈必须同时加载完全相同的基座模型——基座不匹配或版本错误会静默改变输出。产物可移植性比存储更重要时选合并式;磁盘占用或多适配器服务更重要时选仅 LoRA。

常见场景选择

数据中心 GPU + 通用对话:FP8。数据中心 GPU + 长上下文/代码/数学:FP8 或 W8A8,绝不用 INT4。旧 GPU 世代 + 通用:AWQ INT4。边缘设备/笔记本 llama.cpp 服务:GGUF Q4_K_M + imatrix。GB10 + 任意工作负载:通过 vLLM nightly 的 FP8,或本地 llama.cpp 的 GGUF,跳过 NVFP4。

决策片段(保留原文): hopper_or_newer: fp8 older_gpu: awq-int4 edge_llama_cpp: gguf-q4_k_m+imatrix gb10_any_workload: fp8-vllm-nightly # never nvfp4 on GB10

工作负载例外(Workload Overrides)

上述格式映射是默认值,并非对所有工作负载都成立。长上下文、代码与数学类工作负载在 INT4 下会失效——量化误差会在长序列与精确的 token 级推理中累积,这些在短而通用的提示上不会显现。对这三类工作负载,即使目标硬件在成本上支持 INT4,也应停留在 FP8 或 W8A8。

不要用 MMLU 等宽泛知识基准验证这一例外——它们压不到该失效模式。应使用实际任务评测:来自 eval-harness-first 的黄金样例与评分器,跑在导出产物上。因为长上下文、代码或数学上的 INT4 退化会先表现为任务级失败(上下文丢失、语法错误、算术错误),而后才会体现在知识基准上。

若在这三类工作负载上,INT4 导出后任务评测出现回退,解决办法是换格式,而不是重调量化配方——同等位宽下 AWQ 与 GPTQ 变体共享相同的累积误差失效模式。

冒烟测试(The Smoke Test)

导出缺陷在文件层面是静默的——损坏的导出仍会产生可加载的产物,因此只检查文件是否存在没有意义。所有导出都必须执行冒烟测试,没有例外:

在实际目标运行时中加载导出产物——FP8/AWQ 用 vLLM,GGUF 用 llama.cpp,不要在与生产服务不同的框架里做快速验证加载。

通过它运行 3–5 条黄金提示——取自 eval-harness-first 维护的 eval/goldens.jsonl,而不是临时新造的一组。

将每条输出与导出前同提示的生成结果对比,使用相同的确定性采样设置——贪心解码(temperature 0)与固定种子,并在导出前后两次运行间持久复用,而不仅是名义上相同的配置。对于无损导出,字节级一致是门槛——任何差异都是缺陷。对于有损(量化)导出,字节级一致预期会失败;门槛改为任务评分器判定一致——参见 references/export-commands.md 的冒烟测试脚本骨架。

以门禁而非手工检查运行:

python smoke_test.py "$EXPORT_PATH"
eval/goldens.jsonl pre-export-outputs.jsonl

non-zero exit on any pre/post mismatch

失败特征(Failure Signatures)

导出缺陷的真实表现,而非干净的通过/失败标志:

模板不匹配表现为输出乱码或连成一串——导出中固化的聊天模板与检查点训练和评测时所用的不一致,导致轮次边界或特殊 token 落在错误位置。

对 lm_head 施加错误量化表现为偏离模板或语义无意义但仍显流畅的输出——输出头丢失了它需要的精度,即便网络其余部分量化正常。

不要发布跳过此步骤的导出——检查点的 PROMOTE 判定只说明未导出的检查点是好的,对导出流水线没有任何保证。任何量化方法或运行时版本升级后都要重跑,而不只在首次导出后。每种格式的可运行命令序列及冒烟测试脚本骨架见 references/export-commands.md。

相关技能(Related Skills)

checkpoint-promotion:本技能唯一有效的上游来源。没有 PROMOTE 判定的检查点不会进入导出。

eval-harness-first:拥有本技能冒烟测试取用 3–5 条提示的 eval/goldens.jsonl,以及工作负载例外部分对长上下文/代码/数学验证所需的任务评测。

finetuning-method-selection:其 references/model-catalog.md 是在从上述格式映射挑选格式前核实硬件级别假设(基础模型面向哪些 GPU 世代)的地方。

Spark 用户:在 GB10 上,通过 llama.cpp 的 GGUF 适合本地服务,通过 vLLM nightly 构建的 FP8 服务是另一条已验证路径——NVFP4 是那里唯一应避免的格式。安装 dgx-spark-ops 插件后,Spark 相关的服务与散热问题交由该插件的技能处理,不必在此重新推导。