模型量化本地部署大模型绕不开量化。社区流传最广的建议是无脑 Q4_K_M但我们在多个项目里实测后发现量化等级的选择应该由业务场景决定Q4_K_M 并非万能答案。本文给出实测数据和选型框架。量化等级速查体积与质量的交换以 Qwen2.5-7B 为例llama.cpp 各量化等级的实测对比等级 文件大小 困惑度变化 主要损失 Q8_0 7.2GB 0.3% 几乎无损 Q6_K 5.5GB 0.8% 接近无损 Q5_K_M 4.8GB 1.5% 轻微 Q4_K_M 4.1GB 3.2% 可感知 Q4_K_S 3.8GB 4.8% 明显 Q3_K_M 3.2GB 9.5% 严重 Q2_K 2.7GB 25% 不可用规律很清晰从 Q8 到 Q4_K_M每降一级体积收益递减、质量损失递增。Q4_K_M 是体积减半、质量还行的甜点但还行不等于没差。三类场景三种选法场景一代码生成、数学推理、Agent 工具调用 → Q6_K 起步这类任务对精度极其敏感。我们实测 Q4_K_M 的 7B 模型做函数调用参数格式错误率比 Q6_K 高出约 3 倍写代码时变量名幻觉、逻辑跳步明显增多。这类场景宁可牺牲体积。场景二闲聊、摘要、文案润色 → Q4_K_M 够用生成式任务有天然的容错空间Q4_K_M 的质量损失用户基本无感。这也是它成为社区默认推荐的原因——大多数人的用法确实在这个范围内。场景三边缘设备、显存极限 → Q4_K_S / IQ4_XS但要做基准测试显存每 100MB 都要计较时才考虑更激进的量化且必须用自己的业务数据跑基准。通用榜单的分数差异在小任务上会被放大。一个容易被忽略的点困惑度不等于下游表现困惑度衡量的是语言建模能力但量化对不同任务的影响不均匀。我们见过困惑度只差 1% 的两个量化版本在结构化输出JSON 格式遵循任务上差了 8 个百分点。所以# 别只看 PPL用自己的任务集测# 例准备 50 条真实业务 prompt对比不同量化的输出llama-perplexity-mmodel-Q4_K_M.gguf-ftest_set.txt llama-cli-mmodel-Q4_K_M.gguf-fbusiness_prompts.txt选型决策树显存 ≥ 模型 Q6_K 体积 → 是用 Q6_K代码/Agent 必选 → 否 ↓ 任务是对话/摘要类 → 是Q4_K_M → 否 ↓ 显存允许 Q5_K_M → 是Q5_K_M 业务集测试 → 否Q4_K_S接受质量风险并持续监控 最后提醒量化是对训练完成的权重做压缩它不能弥补模型本身的能力短板。模型选错了量化等级再精调也救不回来。先选对模型再谈量化。