量化省的是显存与带宽，不是算力

端侧推理的核心矛盾是：用户要的是「像云端一样聪明」，硬件给的却是「有限内存 + 有限功耗 + 不可预测的负载」。量化、蒸馏、调度是三条应对路径，但它们并非同向优化。量化把权重从 FP16 压到 INT8 甚至 INT4，直接减小模型体积和内存带宽占用；蒸馏用大模型教小模型，换来的小模型结构更紧凑；调度则决定在什么时机加载哪部分权重、如何切分 prefill 与 decode。

问题在于，三者叠加时会出现「预算挤兑」。量化到 INT4 后精度下降，往往需要蒸馏补偿；蒸馏后的小模型对量化更敏感；而调度策略若为了省内存频繁换入换出，延迟反而上升。端侧部署不是「选一个最优技术」，而是「在三维约束下找可行点」。

输入侧。 端侧输入有两个特征：分布漂移和长度不可控。手机上的用户输入混合了口语、错别字、方言和截图 OCR 文本，与蒸馏时使用的干净语料差异明显。更关键的是 prompt 长度方差极大——一句问候和一份长文档摘要，对 KV Cache 的需求相差两个数量级。量化对输入侧的敏感点在于激活值：权重可以离线校准，激活值必须在线量化，而异常大的激活值会直接拉低 INT8 的有效位宽。实践中常用 per-channel 权重量化加 per-token 激活量化，并对 outlier 通道做保留。

推理/执行侧。 这是预算表最紧张的地方。以 4B 参数模型为例，INT4 权重约 2GB，KV Cache 在 4K 上下文、GQA 下约数百 MB，加上运行时开销，中端手机 8GB 内存里可用的余量并不宽裕。真正的瓶颈是内存带宽：decode 阶段每生成一个 token 都要把权重读一遍，带宽决定了 token/s 的上限，而非算力。蒸馏在这里的作用是双重的——减小参数量直接降带宽需求，同时通过 logits 蒸馏让小模型学到更平滑的输出分布，减少采样时的重复和抖动。调度层面，prefill 是计算密集，decode 是带宽密集，两者混跑会互相拖累；把 prefill 分块、decode 批处理、KV Cache 分页管理，是端侧推理引擎的标配。

输出/评测侧。 端侧评测不能只看 perplexity 或通用榜单。量化后的模型在通用任务上可能只掉 1-2 个点，但在结构化输出、数学步骤、工具调用参数生成上可能掉 10 个点以上，因为低比特量化对数值敏感任务更不友好。评测应分三层：基础能力（困惑度、通用问答）、任务能力（指令遵循、JSON 合法性、函数调用准确率）、端侧体验（首 token 延迟、稳态 token/s、内存峰值、发热降频后的表现）。第三层常被忽略，却直接决定用户是否愿意持续使用。