描述变体时不能只看比特数
说明方法名称、其实现、版本以及产物的确切修订版。两个四比特变体可能采用不同的表示、分组、元数据和 kernel。请将权重存储格式与计算操作格式分开。还要记录仍保留为其他精度的模块以及任何向 CPU 的卸载。
在 bitsandbytes 中，量化线性层会替换某些普通层；其他模块则遵循其配置的 dtype。因此这一行为本身并不能描述进程峰值。请在加载后读取实际生效的配置，然后确认该变体确实执行了预期的处理，而不是采用了不同的软件回退方案。
| 字段 | 需要保留的内容 | 避免的混淆 |
|---|---|---|
| 来源 | 模型、修订版、tokenizer、方法及版本 | 比较同一名称下的两个不同模型 |
| 权重 | 格式、比特数、分组及排除的模块 | 把四比特当成唯一配方 |
| 计算 | 实际使用的 dtype、kernel 及设备 | 混淆存储与执行 |
| 生成 | 缓存、上下文、输出上限及并发 | 把源自缓存的影响归因于权重 |
| 制作 | 可能的校准及数据修订版 | 忘记该产物是如何生成的 |
将校准与评估分开
某些方法会使用示例来准备量化。Transformers 中记录的 GPTQ 流程特别要求一个校准集和一个 tokenizer。该校准集参与产物的制作：它不构成独立的质量证据。其他方法走的是另一条路径；不要假定同一套校准协议适用于所有格式。
请将校准示例保留在获授权的数据中用于准备模型，然后记录其标识符、来源、长度及所应用的变换。将验证集留作选择设置之用，将最终测试集留作确认之用。如果你在比较得分后选择了多个校准集，这一搜索属于开发的一部分，必须计入总结。
技术来源： Hugging Face Transformers 5.17 — GPTQ 量化的校准 · 按其角色构建划分
计算权重上界，但不要把它当作峰值来卖
假设有一个虚构的三十亿参数模型，所有参数都以相同的比特数存储。原始体积按 参数 × 比特 / 8 计算。按 16 比特算，得到 60 亿字节；按 8 比特，30 亿；按 4 比特，15 亿。这些数字是用于说明的算术，不是某个产物观测到的大小，也不是某个运行中模型的需求。
16 比特与 4 比特之间的原始差值为 4.5 GB，约合 4.191 GiB。它不包含缩放系数、元数据、未量化模块、缓存及临时数据。它有助于提出一个待验证的显存假设，但不能预测峰值会降至四分之一。显存专题说明了如何区分各阶段并解读计数器。
| 假设的格式 | 原始字节 | 十进制 GB | 约合 GiB |
|---|---|---|---|
| 16 比特 | 6 000 000 000 | 6 | 5,588 |
| 8 比特 | 3 000 000 000 | 3 | 2,794 |
| 4 比特 | 1 500 000 000 | 1,5 | 1,397 |
技术来源： NIST — 二进制与十进制前缀 · IteraGPU — 显存估算与峰值
先改权重，再改缓存
请先使用一个你了解其行为的基准。然后在相同缓存、相同长度、相同批次或相同并发下比较各权重变体。如果你同时更改了这些参数，那你比较的就是完整配置：请明确说明，不要把全部差异都归因于权重量化。
当模型和引擎允许时，KV 缓存本身也可以被量化。这是一个独立的选项。Transformers 文档特别指出，在内存充足、上下文较短的情况下，量化缓存反而可能拖累延迟。请把这第二项改动放在单独的一组实验中测试；节省更多内存并不保证更低的延迟。
质量规则示例：小幅下降也可能不可接受
下面是一个决策示例，不涉及实际运行模型。某项目评估 200 份文档，并在试验前就规定：相对基准的最大损失为一个百分点。同时要求这 200 份中纳入的 20 份关键文档至少要有 90% 通过。一份文档只有在所有必填字段都正确时才算通过。
下面这些虚构数值让 A 满足这两条规则：94% 而非 95%，关键组 18/20。B 两条都不满足。但此时还不能宣布 A 胜出：既没有给出内存峰值，也没有给出耗时。此外，总数并不能说明哪些文档发生了变化；请比对配对错误，以发现新出现的重要回归。
| 变体 | 通过的文档数 | 整体通过率 | 通过的关键用例 | 按这些规则得出的结论 |
|---|---|---|---|---|
| 参考 | 190 / 200 | 95 % | 19 / 20 = 95 % | 对照基准 |
| A | 188 / 200 | 94 % | 18 / 20 = 90 % | 质量达标 |
| B | 184 / 200 | 92 % | 16 / 20 = 80 % | 不通过 |
技术来源： 要看错误，而不只是看总数
执行一次差距可解释的对比
先准备好对比方案，再准备结果文件。以下流程要在你自己的负载上执行；前面的数字不能替代它。如果某个变体加载失败，或缺少所需的算子，请把这个失败保留为兼容性信息。
- 固定语料、参考答案、模型、分词器、提示词和输出规则；让长样例和困难样例保持可识别。
- 记录校准过程、导出的产物和实际生效的配置。核实用到的设备，以及可能发生的 CPU/GPU 数据传输。
- 把构建、加载、预热和稳定处理阶段分开。使用相同的测量边界，并保留原始重复数据。
- 按设备和阶段记录峰值；allocated 与 reserved 要分开保留。不要把这些计数器相加，也不要减去它们各自独立的最大值。
- 评估约定的格式、内容和子分组，然后按标识符比对错误。
- 在新的进程中重新加载最终选定的产物，并重跑一个既定的检查项。导出前得到的结果并不能自动证明重新加载后的结果。
把权衡与实际投入的成本挂钩
节省内存可以拓宽可行的配置范围、支持更高的并发，或者只是留下余量。它并不会自动降低开支。如果时长、预留批量和验收的交付物都不变，那么即使某一次运行更快，套餐费用也保持不变。
要把可能的校准、量化、评估、被否决的尝试和重新加载都算进时间表。然后在你满足各项标准的方案之间，比较 3 天、7 天或 30 天的完整套餐。只有真正完成并通过验收的语料才能用来计算单位有效语料成本；用于计时的重复并不会产生新的交付物。
如果只用一次租用来比较多个变体，那么这笔金额属于整次实验的共同支出。不要在心里把整个套餐都算到每个变体头上，再把这些金额相加当作各自独立的实际支出。若要分摊作分析用途，请先声明一种约定；这不会改变实际投入的总额。
技术来源： IteraGPU — 套餐整体与单次实验成本
以一套配置及其局限作结
最终决定要写明：产物、环境、覆盖的负载、达到的质量标准，以及被改善的约束。如果各变体彼此接近，请保留这种不确定性，并优先选择你确定能够重新加载和解释的方案。位数本身并不是偏好排序的依据。
在短文本语料上得出的结论不会自动延伸到长上下文、另一种语言或更多并发请求。为推理选定的量化方案也不能定义微调中可训练的参数。请将这些议题分开考虑，并在留出的测试集上确认所选的变体。
实际问题
四比特占用的内存总是十六比特的四分之一吗？
均匀存储的权重其原始体积确实遵循这一比例。总峰值还包括元数据、其他格式的模块、缓存和临时变量。在宣称整体收益之前，请实测真实运行情况。
我可以用最终测试集来校准量化吗？
那样一来，这个测试集就会参与产物的构建，不再是一次独立评估。请用允许用于开发的数据集来准备校准，然后保留一个单独的留出集用于确认。
更小的变体运行成本一定更低吗？
不一定。预算取决于占用的时长和批次、准备工作以及可接受的可用结果。如果这些要素不变，仅减少内存占用可以提高利润，但不会降低租用金额。