把 7B 模型塞进手机：量化实战指南

移动端的核心战场是量化

移动端的瓶颈不是算力，而是字节。一个 7B 参数的 fp16 模型有 14 GB；手机一共只有 4–8 GB 内存，其中真正能借给 AI 负载的也就 1.5–3 GB——再多，操作系统就会把前台应用换出。不用激进量化，账算不平。

我们真正在发的东西

• Q4_K_M（k-quants，混合分组）用于一般 LLM 负载——我们测过的、4 bit 以下质量比最高的方案，在长尾 token 上还有意外柔和的失效模式。
• AWQ-int4（激活感知权重量化）用于代码和数学推理，这两类负载激活离群值很关键，朴素 RTN 量化会肉眼可见地退化。
• fp16 热权重保留给嵌入表和最后的 lm_head 投影——这两层只占总权重一小部分，但对感知质量贡献不成比例。
• int8 K/V cache配上 per-token scale，把缓存预算压住，又不会像 int4 KV 那样灾难性掉点。
• 磁盘上用 GGUF做容器，方便我们换量化方案不重写加载器。

困惑度不是对的指标

用户不关心 next-token 的交叉熵。他们关心摘要对不对、翻译读起来顺不顺、commit 描述准不准。我们做了一个小的内部 eval harness，在真实会议转写、真实菜单翻译、真实 commit diff 上评估端任务质量。它和困惑度大约在 18% 的时候不一致。有时候，丢掉 0.3 bit 困惑度的方案，反而能赢 4 分摘要质量，因为失效模式从"下个 token 微差"变成了"野跑次数更少"。

让我们意外的发现

• 某些层，group size 比位宽更重要。 FFN 把 group size 从 128 降到 64，比把 attention 从 4 bit 升到 5 bit 救回更多质量。
• 离群值是聚集的。 每个 transformer 块里都有少量通道扛着不成比例的大激活值。给它们一个高精度分支（SmoothQuant、per-channel scale 那一路）比把整体位宽抬上来更高效。
• 校准数据是杠杆。 从实际产品负载里挑出 256 条校准样本，每次都赢 C4 上 8K 样本。

结论

别按论文挑量化方案。按你的 eval 挑——而你的 eval 必须长得跟你的产品一模一样。