大模型量化到 4-bit 值不值？同题比较显存、质量与速度

把权重改为 4-bit，可能让原本无法考虑的显卡进入候选，但“文件变小”还不是部署决定。量化文件可能带有比例等元数据，也可能保留更高精度的层；KV Cache、服务缓冲和请求队列也没有随文件名一起缩小。模型即便成功加载，在指定任务上仍可能更容易犯关键错误，或在所选推理后端上变慢。本页要完成的是一次可复核的 BF16 与指定 4-bit 文件对照试验。

先用单卡显存预算排除原始载荷已经超限的方案，再用相同任务案例比较未量化 BF16 参照与 4-bit 候选。只有两种文件在同硬件、同负载下都能运行时，才直接比较服务速度。模型选型评分表用于不同模型的通用取舍；这里要问的是某个具体量化文件能否替代 BF16 参照。

先写“值得”的门槛，不从文件大小倒推结论

试验前先写不可让步的条件：例如支付指令里的金额不能错、制度条款的否定条件不能丢、目标显卡必须完整驻留、计划负载不能出现 OOM、P95 响应时间必须落在约定范围。然后再列可以权衡的项目：显存余量、首 token 时间、完成请求吞吐、设备租赁或用电成本，以及维护复杂度。关键质量条件失败时，文件再小也不能抵消。

“4-bit”不是完整配置。对照表要写明基础模型和修订版、具体的 AWQ／GPTQ 等文件及其修订版、tokenizer 与聊天模板、已公开的分组和校准信息，以及服务框架、内核、GPU 和驱动。后端是否支持该格式，要按目标版本和硬件核对。如果 BF16 参照与发布的量化文件来自不同基础修订版，只能称为两个部署文件的比较，不能把全部差异归因于位数。

案例一：24 GiB 单卡上的 Qwen 14B 候选筛选

假设目标是设备报告可用物理显存为 24 GiB 的单卡，同时驻留四个请求，每请求峰值占 8192 个缓存 token。显存计算器给出的 BF16 权重加常规 16-bit KV 原始载荷为 33.38 GiB；把权重改按 4-bit 计算、保留相同 KV 后为 12.85 GiB。这排除了上述条件下 BF16 在目标卡上的完整驻留，却只让官方 Qwen2.5-14B-Instruct-AWQ 进入下一轮候选。量化比例、其他张量、框架分配和缓存策略都会影响峰值，12.85 GiB 不是 AWQ 的运行实测值。

真实任务是一项要引用当前制度条款的中英双语内部问答。冻结一组普通提问、必须排除的旧版制度、会改变答案的尾部例外条款，以及根本没有授权资料的问题。在能够完整驻留 BF16 的硬件上建立任务质量参照，再在目标 24 GiB 卡上测试 AWQ。若候选漏掉阻断性例外或编造无依据答案，就拒绝；质量通过后再验证完整 GPU 驻留、OOM、目标四请求负载下的 P95 延迟和完成请求吞吐。只有所有门槛通过，才有理由为这项服务采用 AWQ。

这是可行性和验收试验，不是公平的速度竞赛。BF16 在更大显卡上的延迟，不能直接与 24 GiB 上的 AWQ 比快慢；CPU 卸载或增加设备同样会改变部署问题。若要比较运行性能，应换到两种文件都能完整驻留的同一硬件，并保持服务设置一致。

案例二：高精度字段与长文例外条款

设想一个合同助手要抽取金额、币种、生效日期，以及限制付款的原文条款。案例集包含短的普通条款、尾部附件修改日期、带脚注的表格、“在满足条件前不付款”这样的否定句，以及没有可用答案的文件。复核者事先为每条案例写好预期字段和窄范围证据位置。写得流畅，不等于抽取正确。

在 BF16 和 AWQ 都能完整驻留的 GPU 上，把这组冻结案例分别送入两种文件。保持 Prompt、聊天模板、检索证据、上下文长度、输出上限、采样设置、后端版本和计划并发一致。试验前就宣布：金额错误、否定词丢失、引用不支持结论、无答案却编造，任何一项都是阻断性失败。每条案例重复运行并保存所有输出，包括失败。如果 AWQ 在某条关键案例中漏掉“不”，即便显存节省，也应拒绝或修订这一部署。这是说明判定规则的假设分支，不是声称 Qwen AWQ 已经出现这个错误。

两种文件都通过关键质量门槛后，再按相同到达模式比较设备峰值、完整驻留、OOM、P95 首 token 时间、P95 完整响应时间和已完成请求吞吐。4-bit 可能通过显存门槛，却在某种内核或批量下达不到延迟目标；也可能在质量合格的前提下提供实测容量收益。下面的工作台应填写自己的结果，不能把没有执行过的基准数字当作事实。

让对照试验能被另一位同事复核

在运行前冻结案例集版本和严重度规则。把关键案例与普通案例分开，另留一组没有参与提示词调整或量化配方选择的保留案例。逐次记录实际输入和输出 token、生成内容、评审结论和每条失败原因。两种候选使用同一批问题；条件允许时让复核者不知道输出来自哪个文件，避免因文件较小而放宽要求。

负载测试还要记录请求到达形状、目标并发、批处理和 KV 设置、冷启动与预热、GPU 设备峰值、卸载、排队时间、首 token、端到端延迟和持续完成请求量。vLLM 提供请求、等待、KV 占用与延迟指标，也有基准测试命令；具体指标名称和量化支持要按部署版本核对。在同一服务上重复相同 Prompt，可能因前缀缓存命中而虚高吞吐；应固定缓存策略、记录命中情况，不把偶然的热缓存当成容量。比较分布与失败次数，不只看最快一次或平均每秒 token。

下方空白对照表把 BF16 参照和 4-bit 候选放在一起。填入目标硬件上的实测结果，复制或导出时带上两个模型修订版和全部试验条件。任一硬门槛不通过，就标为拒绝并写明下一项试验；两者都通过时，按这项负载真正需要的运行目标作决定，并约定模型、量化文件、内核、驱动、Prompt 或流量变化后的复测条件。

常见问题

4-bit 会让整个 GPU 占用减半吗？ 不会。这只描述具体文件中的一种权重表示。比例数据、未量化部分、KV Cache、激活、缓冲和碎片仍会占显存。要测运行进程与设备峰值。

AWQ、GPTQ、bitsandbytes 可以混成同一条“4-bit”结果吗？ 不可以。它们的配方和运行路径不同；逐行记录具体文件与后端支持，不能合并质量或速度结果。

公开榜单能替代这个试验吗？ 榜单能帮助挑候选，不能代表本任务的阻断案例、上下文长度、GPU、请求形状和服务时间限制。

不适用边界

这张表比较指定模型、任务、服务栈和负载下的推理文件，不负责训练或微调显存，也不能证明所有 4-bit 方法质量一样，或把某块 GPU 的结果搬到另一种内核。初筛显存值使用所链接显存页的常规缓存假设；特殊注意力和缓存布局需另算。原始载荷有正余量，只表示值得进入实测，不证明装得下、质量合格或速度更快。