但量化不是免费午餐。它损失的不只是“分数低一点”，也不只是“回答笨一点”。真实损失会分散在速度、质量、稳定性、长上下文、结构化输出、工具调用、中文术语、数学代码、拒答边界和线上运维中。有些损失肉眼很容易发现，比如开始胡说、循环、漏掉约束；有些损失很隐蔽，比如前十轮对话正常，长上下文到两万 token 后引用位置错乱；普通闲聊正常，遇到 JSON、代码补丁、表格计算、合同条款就退化。

社区里最常见的误判，是把“能跑起来”当成“能上线”。能在本地聊天窗口输出答案，只说明权重格式、推理引擎和显存暂时匹配；能不能服务真实用户，还要看质量回归、延迟分布、并发压力、崩溃恢复、版本兼容、上下文长度和业务风险。量化模型的正确讨论方式，不是问“Q4 能不能用”，而是问“在哪个模型、哪个任务、哪个硬件、哪个推理引擎、哪个上下文长度、哪个并发水平下，Q4 损失是否可接受”。

一、量化到底改变了什么

大模型权重通常以 FP16、BF16 或 FP32 等较高精度格式保存和计算。量化把这些连续数值用更少 bit 表示，例如 INT8、INT4、FP8、NF4 或各种 GGUF 量化类型。权重占用更小，显存和内存带宽压力下降，某些硬件和内核上推理会更快。

这件事听起来像压缩文件，但它不是普通压缩。普通压缩可以无损恢复原文件，量化通常会改变数值。矩阵乘法里的每个权重都略有误差，层层传播后可能影响 token 概率分布。大多数时候误差很小，模型仍能输出流畅回答；但在边界任务上，概率排序的一点变化就可能让模型选错路径。

量化可以发生在不同位置。权重量化最常见，把模型参数压到低精度。激活量化会处理推理过程中的中间激活，对硬件效率更敏感。KV cache 量化压缩长上下文推理时保存的 key 和 value，能显著降低上下文和并发带来的显存压力。训练或微调里的量化还会配合 LoRA、NF4、双重量化和分页优化器，这与纯推理量化目标不同。

不同量化格式的损失也不同。INT8 通常质量损失较小，但节省比例有限。INT4 节省更明显，但更依赖算法、校准数据、分组大小和推理内核。FP8 在新硬件上有很强吸引力，尤其适合服务端吞吐优化和 KV cache。GGUF 的 Q4_K_M、Q5_K_M、Q8_0 等格式服务于 llama.cpp 生态，便于在 CPU、Mac、消费级 GPU 上运行。AWQ 和 GPTQ 更常见于 GPU 推理服务，依赖对应内核和引擎支持。

所以“量化模型损失什么”不能脱离格式。一个 Q8_0 GGUF 和一个 4-bit GPTQ 不是同一种东西；一个只量化权重的模型，和一个同时量化权重与 KV cache 的服务，也不是同一种风险。线上评估必须把模型、格式、推理引擎、硬件、上下文长度和请求模式写清楚。

二、速度提升来自哪里，也会在哪里失效

量化带来的速度提升主要来自三个地方。第一是模型更小，权重从显存或内存读取更快。大模型推理常受内存带宽限制，低 bit 权重能减少搬运数据量。第二是模型能放进单张卡或更少卡，避免跨卡通信。第三是显存空出来后，可以提高 batch、并发或上下文长度，让服务端吞吐更好。

但量化不一定让每个请求更快。如果硬件没有高效低精度内核，量化权重可能需要频繁反量化，计算反而变慢。某些 GPTQ 或 AWQ 模型在不合适的内核上速度并不理想，甚至比 FP16 慢。vLLM 文档里的量化支持矩阵会随着版本、硬件和内核变化，不能拿某个格式名直接推断速度。

CPU 和 GPU 的速度逻辑也不同。llama.cpp 在 CPU、Apple Silicon、部分 GPU 后端上有自己的量化格式和优化路径。Q4_K_M 可能在本地聊天中非常划算，因为显存或统一内存压力低，速度可接受。服务端 GPU 上，AWQ、GPTQ、FP8、Marlin、compressed-tensors 等组合可能更关键，因为吞吐取决于内核、batch、调度和 KV cache。

首 token 延迟和持续生成速度也要分开看。首 token 受提示词长度、prefill、缓存命中、调度排队影响；持续生成速度受 decode 阶段权重读取和 KV cache 影响。量化权重可能明显改善 decode，但长提示词 prefill 仍然慢。KV cache 量化可能让长上下文并发更稳，但对短请求首 token 未必有明显收益。

吞吐和单请求延迟也经常冲突。量化后显存变小，系统能塞进更大 batch，总 tokens/s 上升；但单个请求在高并发下排队更久，用户感知延迟可能不降反升。生产服务要同时看 p50、p95、p99 延迟、首 token 时间、输出 token/s、吞吐、显存水位和失败率。

因此，速度实测不能只贴一行“每秒多少 token”。至少要区分模型加载时间、首 token、prefill、decode、批处理吞吐、并发下延迟、长上下文延迟、显存占用和异常重试。社区里很多速度结论只适合个人机器，不能直接搬到生产服务。

三、质量损失最先出现在边界任务

量化后，普通闲聊通常最不容易暴露问题。用户问“帮我写一段介绍”“总结这段文字”“解释什么是量化”，大多数 4-bit 模型仍能给出流畅答案。真正的质量损失更容易出现在高约束、高精度、高推理深度任务里。

数学推理是常见受损点。模型需要多步保持中间变量，某些 token 概率的细微变化会让推理分支偏离。量化后不一定每道题都错，但难题、长链路题、符号推导、单位换算、边界条件更容易出问题。若产品依赖财务计算、数据分析或严格逻辑判断，必须单独评测。

代码任务也容易退化。代码生成要求语法、API、变量名、依赖关系和边界条件都对。量化模型可能仍能写出看似合理的代码，但更容易漏 import、写错函数签名、破坏已有接口、忽略测试失败、生成不完整补丁。对代码助手来说，能聊天不够，必须跑真实仓库任务和测试回归。

结构化输出是另一个敏感点。很多 AI 产品要求模型输出 JSON、SQL、表格、函数调用参数或固定字段。量化后，模型可能更容易漏字段、多逗号、破坏引号、把解释文字混入结构、重复键名，或者在长上下文下忘记 schema。若系统把模型输出直接交给业务接口，结构化稳定性比自然语言观感更重要。

中文和行业术语也要单测。量化可能让模型对少见词、相近词、数字、缩写、繁简体和中英混写更不稳。比如“数电票”“红冲”“销项”“进项”“Q4_K_M”“AWQ”“租户隔离”“等保测评”这些词，通用闲聊测不出来。生产业务越垂直，越不能只用通用 benchmark 判断量化损失。

安全和拒答边界也可能变化。量化改变概率分布后，模型的拒答、遵循系统约束、处理敏感问题的行为可能产生漂移。有时表现为更容易答不该答的内容，有时表现为过度拒答。面向企业内部系统时，这会影响权限、合规和用户信任。

四、稳定性损失比质量分更难处理

社区讨论量化时，常把注意力放在 benchmark 分数。但生产系统更怕稳定性问题：偶发循环、输出截断、无法停止、长上下文错乱、并发下崩溃、显存碎片、模型加载失败、模板不匹配、特殊 token 错误、不同版本引擎行为不一致。

GGUF 模型在 llama.cpp 生态里很方便，但也依赖模型架构、tokenizer、chat template、special tokens、rope 配置和运行时版本。新模型刚发布时，旧版本推理引擎可能不能正确处理模板或终止符。模型能加载不代表对话格式完全正确。格式细节不对，表现可能是回答跑题、停不下来、函数调用格式异常或多轮对话状态混乱。

AWQ、GPTQ、FP8 在服务端也有兼容问题。推理引擎支持某种量化方法，不等于支持所有模型架构、所有分组大小、所有 MoE 结构、所有硬件。vLLM 的量化支持表一直在演进，某个版本能跑的组合，换驱动、换 GPU、换模型分支后可能表现不同。生产部署必须固定版本，并保留回滚路径。

长上下文会放大稳定性问题。短问答只走几千 token，KV cache 压力小；长文档问答、代码仓库分析、会议纪要、多轮客服会话会把上下文拉长。权重量化的误差加上 KV cache 量化的误差，可能让后半段注意力质量下降。用户看到的不是“量化误差”，而是引用错段、忘记前文、重复输出、答非所问。

并发也会暴露问题。单用户本地测试时显存充足，生产并发下 KV cache、batch 调度、prefix cache、显存预分配、请求取消都会影响稳定性。某些量化组合在空载时正常，高并发下出现 OOM、请求超时或吞吐抖动。上线前必须做并发压测，而不是只跑单条 prompt。

稳定性问题最麻烦的地方，是它常常不是每次复现。质量评测可以用固定样本算分，稳定性还需要长时间运行、不同上下文长度、不同输出长度、不同并发、异常取消和热重载场景。量化模型用于生产时，监控和回滚比单次 benchmark 更重要。

五、GGUF、AWQ、GPTQ、FP8 分别适合什么讨论

GGUF 是 llama.cpp 和 GGML 生态常用的模型文件格式，目标是把权重、元数据、tokenizer 等信息放在易加载的二进制文件中。它适合本地运行、离线分发、Mac、CPU、消费级硬件和轻量服务。Q8_0 常被视为接近高精度的保守选择，Q5_K_M、Q4_K_M 常用于质量和体积折中，更低 bit 格式适合极限内存场景，但质量风险更高。

GGUF 的优点是部署简单、硬件覆盖广、社区模型多。缺点是不同量化类型、不同架构支持和不同 llama.cpp 版本会影响结果。生产使用时，不要只写“用了 GGUF”，还要写清具体量化类型、模型来源、运行时版本、上下文长度、KV cache 设置和是否启用 GPU offload。

GPTQ 是经典的训练后权重量化方法，使用近似二阶信息降低量化误差，常见于 3-bit、4-bit 低精度权重。它的优势是压缩明显，很多模型已有现成权重。风险是格式、分组、act-order、内核和推理引擎支持会影响速度和质量。没有合适内核时，低 bit 不一定快。

AWQ 关注激活感知的权重量化，核心思想是保护对激活更敏感的权重通道，常用于 4-bit 权重量化。它在许多指令模型和多模态模型上有不错泛化，服务端 GPU 推理中也很常见。但 AWQ 不是天然适合所有架构，MoE、特殊 attention、国内新模型分支仍要看引擎支持。

FP8 更偏向现代 GPU 服务端优化。它可以用于权重、激活或 KV cache，具体收益取决于硬件是否原生支持、引擎实现是否成熟、scale 是否合适。vLLM 已支持多种 FP8 和 KV cache 量化路径，适合追求吞吐和长上下文并发的服务。但 FP8 也需要评测质量，不能因为 bit 数比 INT4 高就默认无损。

INT8 和 SmoothQuant、LLM.int8 这类方法适合保守压缩。LLM.int8 强调处理大模型中的离群特征，SmoothQuant 把激活量化困难迁移到权重侧，目标是让 W8A8 在硬件上更高效。它们通常比 4-bit 更稳，但节省比例和部署复杂度要结合实际硬件看。

QLoRA 和 NF4 更常用于高效微调讨论。QLoRA 把预训练模型量化到 4-bit，并通过 LoRA 训练低秩适配器，显著降低微调显存。它不是“直接拿 4-bit 推理一定最好”的证据，而是说明量化可以成为训练和适配流程的一部分。推理上线仍要单独评估。

六、怎么做一套靠谱的实测

实测第一步是确定基线。至少需要一个 FP16 或 BF16 基线模型，和一个或多个量化版本。所有版本使用同一模型家族、同一聊天模板、同一上下文长度、同一采样参数、同一系统提示、同一硬件和同一推理引擎。若基线不同，结果无法解释。

第二步是固定任务集。不要只用十条聊天问题。任务集应包含真实产品场景：中文问答、企业知识库 RAG、长文档摘要、结构化 JSON、函数调用参数、代码修改、数学计算、多轮对话、拒答边界、行业术语、低频专名、长上下文引用。每类任务至少几十条样本，关键业务最好上百条。

第三步是同时记录速度和质量。速度指标包括模型加载时间、首 token 延迟、prefill 时间、decode tokens/s、端到端耗时、显存峰值、并发吞吐、p95 和 p99 延迟。质量指标包括人工评分、自动判分、结构化解析成功率、测试通过率、引用命中率、事实错误率、拒答正确率、重复率和截断率。

第四步是重复运行。量化模型在采样模式下可能有随机性。即使温度设为零，不同后端、不同 batch、不同浮点实现也可能有细微差异。关键样本要跑多次，观察是否稳定。一个版本平均分不错，但偶发输出不可解析，也可能不适合生产。

第五步是压测上下文。很多量化模型在 2K、4K 上表现正常，拉到 16K、32K 后开始退化。测试要覆盖短提示词、中等提示词、长提示词和极长提示词，并记录 KV cache 占用、首 token 延迟、引用准确性和后半段指令遵循。若业务主要是长文档，短聊天分数参考价值有限。

第六步是做并发测试。单用户 tokens/s 不能代表服务能力。生产服务要模拟真实请求分布，包括短问答、长文档、取消请求、超时、并发峰值和批处理混合。观察显存水位、队列等待、失败率、重启恢复和日志中的异常类型。

第七步是保留样本和输出。每次测试都要保存模型版本、量化格式、命令参数、硬件、驱动、推理引擎版本、输入、输出、评分和失败原因。否则团队无法判断下次升级是变好还是变坏。社区经验可以参考，自己的回归数据才是上线依据。

七、KV cache 量化和长上下文风险

很多人讨论量化时只看权重大小，却忽略 KV cache。大模型生成时，每一层都会保存历史 token 的 key 和 value，后续 token 继续注意这些缓存。上下文越长、并发越高，KV cache 占用越大。权重量化把模型本体压小后，系统常常又被 KV cache 卡住。

KV cache 量化的价值很明确：降低长上下文和高并发的显存压力。一个服务如果要同时处理几十个长文档请求，FP16 KV cache 可能比权重本身更快吃满显存。把 KV cache 压到 FP8 或更低精度，能让同一张卡承载更多请求，或者把上下文长度开得更高。

风险也很明确：KV cache 保存的是注意力计算所依赖的历史信息。它被量化后，模型“回看前文”的精度会下降。短问答里影响可能很小，长文档、长代码、多轮对话和跨段引用里影响会被放大。用户看到的不是“KV cache 精度下降”，而是模型忘记前文条件、引用错段、把旧约束当新约束、后半段开始重复。

因此，KV cache 量化不能只用短 benchmark 判断。至少要测三类样本：长输入短输出，例如合同审查和长文档问答；短输入长输出，例如报告生成和代码生成；长输入长输出，例如会议纪要整理和复杂分析。每类都要观察引用准确性、约束保持、输出重复和结尾质量。

KV cache 量化还和 batch 调度有关。并发场景下，多个请求长度不同，缓存分配和释放会影响显存碎片与延迟。单请求能跑 64K，不代表十个并发都稳。生产测试要模拟真实请求长度分布，而不是只拿一条最长 prompt 证明能加载。

更稳的做法是分层使用。短请求不一定启用激进 KV cache 量化；长上下文低风险任务可以启用；高风险长文档任务使用更保守精度，或通过检索、摘要、分段处理减少上下文压力。长上下文不是越长越好，尤其在量化系统里，控制上下文质量往往比盲目扩大窗口更重要。

八、采样参数会放大量化差异

量化评测还要固定采样参数。温度、top_p、top_k、重复惩罚、最大输出长度、停止词都会影响结果。量化改变 token 概率分布后，采样参数会放大或掩盖差异。温度较高时，模型本来就更发散，量化损失可能表现为更明显跑题；温度为零时，差异可能集中在少数关键 token 的排序变化。

结构化输出建议先用低温或贪心解码测试。若在严格参数下仍然频繁破坏 JSON 或函数参数，说明模型或量化格式不适合该任务。创意写作可以用较高温度，但也要比较重复率、跑题率和约束遵循。不要拿创意写作参数去评估工具调用，也不要拿代码参数去评估闲聊体验。

最大输出长度也是稳定性变量。某些量化模型在短输出内正常，长输出后开始重复、绕圈或忘记格式。测试摘要、报告、代码和文案时，不能只看开头几百字。需要检查完整输出是否保持结构，结尾是否自然停止，是否出现重复段落和无意义延长。

停止词和聊天模板同样关键。模型训练时依赖特定 role 标记、起止符和工具调用格式。量化文件如果元数据、模板或运行时适配不正确，模型可能把用户、助手、系统标记混在正文里，或者无法在正确位置停止。这类问题常被误判为量化质量差，实际可能是模板不匹配。

公平对比的方式，是基线模型和量化模型使用完全相同采样参数，并额外测试生产真实参数。若量化模型只有在把温度降得很低、输出长度压得很短时才稳定，就要把这种限制写入上线策略，而不是假装它和基线等价。

九、RAG 和智能体场景里的特殊损失

RAG 系统里，量化模型通常不独自负责事实来源，前面还有检索和引用。这让很多团队以为量化风险较低。实际情况更复杂：RAG 降低了知识幻觉，但没有消除指令遵循、引用整合、条件判断和拒答风险。模型需要从多个片段中选择依据、处理冲突、承认没有答案、按引用回答。量化后，这些能力都可能轻微下降。

最常见问题是引用和结论不一致。引用片段写的是“试用期不符合录用条件可以解除”，模型结论却泛化成“试用期可以随时解除”；引用里有时间范围，答案省略了范围；引用 A 说旧规则，引用 B 说新规则，模型没有识别版本。RAG 产品要评估的是“带依据的正确回答”，不是“看起来像有依据”。

智能体场景更敏感。智能体需要规划、调用工具、观察结果、修正步骤。量化后，单步回答可能没问题，但多步执行中更容易漏掉约束、重复调用、提前结束、错误解释工具返回、把失败当成功。代码代理、浏览器代理、运维代理、数据分析代理都需要真实任务评测。

工具调用参数是高风险点。量化模型可能把字段名写错，把字符串数字混用，把可选参数当必填，把用户未确认的信息填进去。外层系统必须做 schema 校验、权限校验、幂等控制和人工确认。不能因为模型是本地运行，就降低工具安全边界。

RAG 和智能体还会使用长上下文。检索片段、历史消息、工具结果、系统指令堆在一起，量化误差更容易表现为“注意力分配不稳”。因此，这类产品的量化评测不能只测裸模型问答，要跑真实链路：检索真实资料、调用真实或沙箱工具、使用真实提示模板、验证最终任务结果。

十、一个实测矩阵应该长什么样

一个实用的测试矩阵可以按模型精度横向展开，按任务纵向展开。横向包括 BF16、Q8、Q5、Q4、AWQ-INT4、GPTQ-INT4、FP8、FP8 KV cache。纵向包括中文闲聊、知识库问答、长文档摘要、代码修复、数学推理、结构化输出、工具参数、敏感拒答、长上下文引用和并发压测。

每个格子不只填“好”或“不好”，而是填四类结果：能否完成、质量分、速度指标、失败类型。例如某个 Q4_K_M 模型在闲聊上质量接近 Q8，但在代码修复上测试通过率明显下降；某个 AWQ 模型吞吐高，但 JSON 解析成功率低；某个 FP8 KV cache 让 32K 上下文并发稳定，却在长文档引用上有小幅退化。

测试矩阵还要区分可接受损失和不可接受损失。闲聊措辞略差通常可接受；客服退款政策答错不可接受。摘要少一个形容词可接受；合同条款适用条件弄反不可接受。代码注释不够优雅可接受；生成破坏生产接口的补丁不可接受。量化评估必须绑定业务风险。

社区常见结论可以作为初始假设：Q8 通常保守，Q5 常是质量和资源的平衡点，Q4 很有吸引力但要测边界，更低 bit 适合资源极限或低风险任务。AWQ 和 GPTQ 在合适 GPU 内核上可带来很好的压缩和吞吐，FP8 在新硬件上适合服务端优化。可是这些只是经验，不是免测许可。

真正可用的矩阵，应该能回答上线问题：这个量化版本能不能替代原模型；能节省多少显存；吞吐提升是否抵消质量损失；失败是否集中在某类任务；是否需要为高风险任务路由到高精度模型；是否能在异常时自动降级或回滚。

十一、质量损失的几种具体表现

第一种是事实边界变松。模型仍然回答得很自信，但引用、日期、数字、条件更容易错。知识库问答里，这会表现为把相邻政策混在一起，把过期资料当成当前资料，把“可申请”说成“必须申请”。

第二种是约束遵循变弱。用户要求只输出 JSON，模型加了一段解释；要求不超过三条，模型写了五条；要求按给定字段输出，模型改了字段名。低风险聊天里这只是烦人，接入系统后就会导致解析失败或业务动作错误。

第三种是长链路推理断裂。前几步正确，后面突然跳步、重复、忘记变量或改变条件。数学、代码、排班、财务、合规审查都容易暴露这种问题。量化不一定让模型“不会推理”，但会降低复杂路径的稳定余量。

第四种是语言和术语漂移。中文专有词被替换成近义但不准确的词，中英缩写被误解，少见产品名被当普通词。垂直行业越强，这类损失越危险。

第五种是多轮记忆变差。模型在单轮能答对，多轮后忘记用户最初约束，或者把上一轮的候选方案当成已确认事实。客服、办公助手和代码代理类产品都要特别测试多轮。

第六种是停止条件异常。输出重复、无法结束、提前结束、把特殊 token 当普通文本、在函数调用后继续闲聊，都是线上常见风险。它们未必体现在 benchmark 分数里，却会直接影响用户体验和服务成本。

第七种是安全边界漂移。模型可能更容易接受危险请求，也可能过度拒绝正常问题。企业场景里，权限和合规不能只靠模型拒答，但模型行为漂移会增加系统治理压力。

十二、成本账不能只算显存

量化最直接的收益是显存下降，但生产成本不只显存。还要算评测成本、适配成本、监控成本、故障成本和人工修正成本。一个低 bit 模型如果让 GPU 成本下降三成，却让人工审核量翻倍，整体未必更便宜。

单位 token 成本也不等于单位有效答案成本。量化模型输出更长、更绕、重复率更高时，表面 tokens/s 提升，实际每个可用答案消耗的 token 可能上升。结构化输出失败需要重试，知识库问答失败需要换强模型复核，代码生成失败需要开发者返工，这些都应该进入成本账。

服务端还要看利用率。FP16 模型占显存大，但如果请求量不高，显卡本来就空闲，量化带来的吞吐收益不一定转化为成本下降。高并发服务则不同，量化可能让同样硬件承载更多租户和任务。成本结论必须结合请求量、峰值、上下文长度和 SLA。

运维复杂度也是成本。多维护几个量化版本，就要多做模型仓库管理、兼容测试、镜像构建、灰度发布和回滚。若团队规模小，过多格式会拖慢迭代。实用策略是保留少数稳定档位，例如一个高精度基线、一个保守量化版本、一个低成本版本，而不是每个模型都收集十种量化格式。

还有数据治理成本。若量化模型用于知识库或智能体，必须记录它处理过哪些任务、失败过哪些样本、是否触发回退。没有这些记录，团队无法证明量化省钱，也无法复盘质量事故。成本优化要可度量，不能只靠体感。

十三、上线风险怎么控制

第一条原则是分任务路由。不要强迫所有请求都走同一个量化模型。低风险闲聊、草稿生成、摘要初稿可以走更低成本模型；财务、法律、代码变更、客户承诺、权限动作、外发内容可以走高精度模型或强模型复核。量化是资源策略，不是统一信仰。

第二条原则是保留高精度回退。上线初期至少保留一个质量更高的基线模型，用于高风险请求、低置信请求、解析失败重试、用户投诉复核和夜间回归。若量化版本出现稳定性问题，系统要能快速切回，而不是现场重新找模型。

第三条原则是输出结构要验证。JSON 要 schema 校验，函数调用要参数校验，SQL 要权限和只读限制，代码补丁要测试，知识库回答要引用核验。不要让量化模型的自由输出直接进入业务系统。越低 bit，越要加强外部验证。

第四条原则是控制上下文长度。不要因为量化省显存，就盲目把上下文拉满。长上下文成本高、错误隐蔽、延迟大。能检索就检索，能压缩就压缩，能分阶段处理就分阶段处理。长上下文能力要通过长文档评测证明。

第五条原则是固定运行环境。模型文件、量化格式、推理引擎版本、驱动、CUDA、ROCm、Metal、启动参数、聊天模板都要进入版本管理。线上问题很多来自环境漂移，而不是模型本身突然变差。

第六条原则是监控失败类型。除了 QPS、延迟、显存，还要监控解析失败、重复输出、超长输出、拒答率、用户重试、人工接管、引用缺失、工具调用失败和异常退出。量化风险如果只看服务健康，很难及时发现质量退化。

第七条原则是定期回归。每次换量化版本、换推理引擎、换模型模板、换上下文长度、换显卡，都跑同一套质量和性能样本。生产经验里，最危险的不是第一次上线，而是一次看似无关的升级悄悄改变输出行为。

十四、灰度发布和事故复盘

量化模型上线不适合一次性全量替换。更稳的方式是灰度发布：先选择低风险流量，例如内部用户、非关键任务、草稿生成、只读问答；再逐步扩大到更多用户和业务。灰度阶段要同时保存基线模型和量化模型的输出，用同一批真实请求做旁路对比。旁路对比不一定把两个答案都展示给用户，但可以让团队看到质量差异和失败类型。

灰度指标不能只看服务是否报错。要看用户重试率、人工接管率、结构化解析失败率、引用缺失率、回答被撤回率、工具调用失败率、输出超长率、投诉率和高风险拦截次数。量化模型最怕“服务健康但答案变差”。如果监控只有 QPS、延迟和显存，很多质量事故会被用户先发现。

灰度还要控制样本偏差。内部测试用户通常更懂模型边界，问法也更像工程师；真实用户会用口语、省略、错别字、截图文字、长文档和情绪化表达。若只用内部技术样本灰度，模型上线到客服、销售、人事、法务后可能暴露完全不同的问题。灰度样本要覆盖真实角色和真实资料。

事故复盘时，不要只写“模型幻觉”。量化相关事故可以拆成多类：权重量化导致推理能力下降，KV cache 量化导致长上下文引用错误，聊天模板不匹配导致停止异常，推理引擎升级导致内核行为变化，采样参数不当导致输出发散，路由策略错误导致高风险任务走了低精度模型。拆清原因，后续才能修。

复盘还要保留原始输入、检索片段、模型输出、采样参数、模型版本、量化格式、推理引擎日志和用户后续动作。没有这些证据，团队很容易在会议上争论“是不是量化导致的”，最后既不敢继续用，也不知道该怎么改。生产系统要让每次失败可回放，至少能在相同环境下复现主要输出行为。

回滚要提前演练。模型文件很大，服务启动慢，缓存预热也需要时间。如果事故发生后才找高精度模型、改配置、重启服务，恢复时间会很长。灰度前就应该准备好切流开关、健康检查、旧模型镜像、索引和模板版本。量化上线的底线不是永不出错，而是出错后能快速隔离。

十五、模型路由比单模型优化更重要

社区里喜欢比较某个量化格式是否“够用”，但生产系统更实用的问题是路由。不同任务对质量、速度和成本的要求不同，用一个模型覆盖所有请求往往不划算。低风险任务可以用便宜量化模型，高风险任务使用高精度模型，复杂任务先用小模型分类，再由强模型执行。

模型路由可以按任务类型做。闲聊、草稿、摘要初稿、标题生成走低成本量化模型；知识库问答根据资料密级和问题风险选择模型；代码修改、财务分析、法律判断、客户承诺走高精度模型或双模型复核；工具调用先由量化模型生成候选参数，再由规则和强模型检查。这样可以把量化收益吃到，同时不让它承担所有风险。

路由也可以按置信度做。若检索引用充分、问题简单、输出结构通过校验，就接受量化结果；若引用不足、模型输出自相矛盾、JSON 校验失败、用户追问多次或触发敏感策略，就升级到强模型。这个策略比固定“所有请求 Q4”更稳，也更符合成本优化目标。

路由还可以按用户和场景做。内部个人助手可以更激进，外部客户服务更保守；试验环境可以快速换格式，生产环境必须固定版本；普通用户可使用低成本模型，专家审核和对外发布走高质量模型。量化不是降级所有体验，而是让资源分配更细。

路由系统本身也要评测。错误路由会把难题交给弱模型，或把简单问题交给贵模型。前者伤质量，后者伤成本。每次调整路由阈值，都要看任务分布、升级比例、用户满意度、成本变化和失败样本。成熟的本地 AI 栈，不是拥有最多量化模型，而是能把合适任务送到合适模型。

十六、不同场景的选择建议

个人本地聊天可以更激进。资源有限时，Q4_K_M、Q5_K_M 这类 GGUF 格式很实用。只要用户知道结果需要核验，低 bit 带来的轻微质量损失可以换来可运行和响应速度。若机器内存足够，Q5 或 Q8 往往更省心。

团队内部知识库建议保守一些。知识库回答需要引用准确、术语稳定、长文档可靠。可以用 Q4 或 AWQ 做低风险问答，但对制度、合同、财务、客户承诺类问题，应使用更高精度模型或加入强重排、引用校验和人工确认。

代码助手要重点测真实仓库。量化模型在通用代码题上表现好，不代表能在你的仓库里安全改代码。建议用真实 issue、真实测试、真实 lint、真实代码审查样本评估。若 Q4 版本测试通过率下降明显，不要为省显存牺牲开发链路可信度。

客服和运营场景要关注稳定格式。客服系统常要求固定话术、政策边界和工单字段，运营系统常要求结构化内容和外发质量。量化模型可以用于草稿，但正式对客输出需要规则校验、知识引用和风险分级。

高并发服务端要看总成本。FP16 模型质量高，但显存贵；INT4/AWQ/GPTQ/FP8 可以提高吞吐，但可能增加评测、运维和回退复杂度。真正要比较的是单位合格答案成本，而不是单位 token 成本。若便宜模型导致更多人工修正和投诉，账未必划算。

长上下文应用要单独选型。会议记录、合同审查、代码库分析、长文档问答会大量使用 KV cache。权重量化省下来的显存可能被 KV cache 吃掉。此时需要评估 FP8 KV cache、分块检索、摘要压缩和上下文路由，而不是只换一个更小权重文件。

十七、社区实践里的几条硬经验

第一，模型越强，量化余量通常越大，但任务越难，余量越快耗尽。一个强模型 Q4 后可能仍胜过小模型 FP16，但在同模型对比中，难任务损失会更明显。

第二，低 bit 的问题经常不是平均质量，而是尾部失败。平均分只降一点，线上却可能多出一批很难接受的异常回答。生产评估要看最差样本和失败类型。

第三，格式名不能替代实测。同样叫 4-bit，不同算法、分组大小、校准数据、内核、硬件和运行时差别很大。社区截图里的速度和质量，只能作为参考。

第四，长上下文和结构化输出比闲聊更能测出问题。如果测试时间有限，优先测业务中最难、最贵、最不能错的任务。

第五，量化不是最后一步。分块、检索、重排、提示约束、输出校验、模型路由、缓存和监控，都能改变最终效果。一个量化模型能不能上线，取决于整条系统链路。

第六，升级要慢。新模型、新量化格式、新推理引擎、新驱动最好不要同时换。一次只变一个关键因素，才能知道问题来自哪里。

十八、上线前检查清单

• 是否有 FP16 或 BF16 基线，以及同模型量化版本对比。
• 是否写清模型名、量化格式、推理引擎、版本、硬件、上下文长度和启动参数。
• 是否覆盖中文业务样本、长上下文、结构化输出、代码、数学、拒答和行业术语。
• 是否记录首 token、decode、prefill、吞吐、显存、p95、p99 和失败率。
• 是否做多轮重复测试，观察循环、截断、无法停止和格式漂移。
• 是否做并发压测，而不是只做单请求聊天。
• 是否验证 JSON、函数参数、SQL、代码补丁和引用。
• 是否为高风险任务保留高精度模型或人工确认。
• 是否监控解析失败、重复输出、引用缺失、用户重试和异常退出。
• 是否准备模型、引擎和参数的回滚方案。

十九、结论：量化省的是资源，不能省评测

量化模型的价值很大。它让更多团队能在有限硬件上运行大模型，让本地 AI 更容易普及，也让服务端推理成本有下降空间。没有量化，很多 30B、70B 甚至更大的模型根本无法进入普通团队的日常实践。

但量化损失是真实存在的，而且损失形态不只是一行分数。速度可能提升，也可能被内核和并发抵消；质量可能平均接近，也可能在难任务上明显退化；稳定性可能短测正常，也可能在长上下文和高并发下暴露。生产系统要做的不是相信或否定量化，而是把损失测清楚、把风险隔离好、把回退准备好。

最稳的态度是：低风险场景积极用，关键场景谨慎测，高风险动作不裸奔。量化模型可以成为生产栈的一部分，但它必须接受和高精度模型一样严肃的评测、监控和上线治理。

写作日期：2026-05-22

参考资料

• GGUF 格式说明：https://github.com/ggml-org/ggml/blob/master/docs/gguf.md
• llama.cpp 量化工具说明：https://github.com/ggml-org/llama.cpp/blob/master/tools/quantize/README.md
• GPTQ 论文：https://arxiv.org/abs/2210.17323
• GPTQ 官方代码库：https://github.com/IST-DASLab/gptq
• AWQ 论文：https://arxiv.org/abs/2306.00978
• AWQ 官方代码库：https://github.com/mit-han-lab/llm-awq
• vLLM 量化文档：https://docs.vllm.ai/en/v0.15.0/features/quantization/
• vLLM Quantized KV Cache 文档：https://docs.vllm.ai/en/v0.20.0/features/quantization/quantized_kvcache/
• LLM.int8 论文：https://arxiv.org/abs/2208.07339
• SmoothQuant 论文：https://arxiv.org/abs/2211.10438
• QLoRA 论文：https://arxiv.org/abs/2305.14314
• KIVI KV Cache 量化论文：https://arxiv.org/abs/2402.02750
• Hugging Face Transformers 量化文档：https://huggingface.co/docs/transformers/main/en/quantization