量化：服务栈与硬件选择

量化的最终价值不在论文表格里，而在服务栈中是否真能省钱、提速、稳住质量。很多团队做完 INT4 或 INT8 实验后发现：模型文件是变小了，但线上吞吐没有明显提升，尾延迟反而更差，甚至运维复杂度更高。原因在于量化不是孤立技术，它与 kernel、硬件架构、KV cache、batching、并行方式和多租户调度强耦合。本页聚焦“量化落地到服务栈”时的真实权衡。

初学者先抓住

量化是否值得做，要看端到端服务目标：放不放得下、快不快、尾延迟稳不稳、质量掉不掉、维护成本高不高。不同硬件和 runtime 对同一种量化格式的收益可能完全不同。

有趣例子：省油车不一定省时间

一辆车油耗更低，但如果只能走慢车道、维修更麻烦、装货方式不合适，整体运输效率未必更高。量化也是：bit 更低只是条件之一，服务栈是否顺畅才决定收益兑现。

1. 量化收益的三种来源

量化理论上能带来三类收益：减少显存占用、降低内存带宽压力、提高算子吞吐。

但只有当服务栈和硬件真正支持对应 kernel 时，这三类收益才能兑现。否则你得到的可能只是“权重文件更小”，而不是“请求更快”。

2. 一个简化的线上收益模型

设单次请求成本近似为

$T_{\text{req}} = T_{\text{compute}} + T_{\text{memory}} + T_{\text{dequant}} + T_{\text{schedule}}.$

量化若减少了 $T_{\text{memory}}$，但增加了 $T_{\text{dequant}}$，总收益未必为正。实际决策关心的是：

$\Delta T = T_{\text{fp}} - T_{\text{quant}}.$

只有当 $\Delta T > 0$ 且质量损失可接受，量化才算成功。

3. 不同硬件对量化的支持差异

3.1 高端 GPU

新一代 GPU 通常对 FP16/BF16、FP8、INT8 甚至更低比特有专门张量核心支持，但支持深度并不一致。某些硬件对 INT8 GEMM 很强，对 INT4 支持有限；某些架构对 FP8 生态更成熟。

3.2 消费级 GPU

显存有限时，量化首先解决的是“放得下”，其次才是“跑得快”。如果低比特 kernel 不成熟，用户常常接受“能部署就行”的收益，而不是追求极致吞吐。

3.3 CPU 与边缘设备

CPU 更受内存带宽和 cache 层次影响，INT8 往往比更低比特更实用，因为指令集、向量化和库支持更成熟。边缘 NPU / DSP 则常有固定精度偏好，模型要适配硬件而不是反过来。

4. 量化与服务目标的关系

4.1 低延迟交互式服务

这类服务更关注 TTFT、TPOT 和尾延迟。量化若引入复杂 dequant 或调度开销，收益可能没有离线吞吐实验里那么明显。

4.2 高吞吐离线批处理

离线场景更容易把 GPU 吃满，量化降低带宽和显存后，往往更容易兑现吞吐收益。

4.3 长上下文服务

这里除权重外，KV cache 占用巨大。若只量化权重不处理 KV，整体收益可能有限。因此服务目标不同，量化重点也不同。

5. 服务栈中的关键位置

量化会穿过整个服务栈，包括模型加载格式、图编译或 runtime、kernel 实现、batching / continuous batching、cache 管理、多模型路由、监控与回退。

其中任何一层不匹配，都可能吞掉量化收益。

6. 模型格式与 runtime 兼容性

很多量化格式只在特定 runtime 下表现最好，例如某些 GPTQ/AWQ 变体更适合特定推理引擎；某些 FP8 路径依赖专门图编译器。工程上要问的不是“这套量化方法论文精度如何”，而是现有 serving stack 是否支持、支持到什么程度、更新 runtime 会不会影响其他模型、多模型共存时是否会放大维护成本。

7. Kernel 与实际吞吐

一个实用事实是：量化速度往往取决于 kernel，而不是量化论文名。尤其要看矩阵乘是否有 fused dequant kernel，attention 与 KV cache 是否也有相应低比特支持，小 batch、短 decode 下 kernel 利用率如何，混合精度路径是否频繁做格式转换。

如果这些都不理想，量化可能只是在离线基准上快，在真实请求分布下不明显。

8. 混合精度是常态而不是妥协

线上系统很少全模型完全同一比特。更常见的是权重 INT4 / INT8，激活 INT8 或 FP16，归一化、softmax、输出头保留高精度，部分敏感层保留 BF16，KV cache 采用另一种比特方案。

这种“按部件分配精度预算”的方式，比追求纯粹统一低比特更符合工程现实。

9. 多租户与多模型场景

若同一集群上同时跑基础模型、LoRA 适配器和多种量化版本，问题会更复杂：不同模型格式会造成加载和显存碎片，不同 runtime 版本同步更新更困难，调度器需要知道不同模型的吞吐画像，观测与报警也要区分不同精度路径。

一个团队如果只在单模型压测里验证量化，很容易低估多租户复杂度。

10. 长上下文下的权衡

若请求序列长度为 $T$，权重显存为 $M_w$，KV 显存为 $M_{kv}(T)$，则总显存为

$M_{\text{total}} = M_w + M_{kv}(T) + M_{\text{workspace}}.$

当 $T$ 足够大时，$M_{kv}(T)$ 可能主导。此时只压权重收益有限，更值得关注 KV cache 量化、paged cache、prefix reuse 和检索裁剪上下文。

这解释了为什么有些团队做了权重量化却没看到预期收益，因为他们真正的瓶颈在长上下文内存。

11. 成本模型与机型选择

设某机型单小时成本为 $C_h$，每秒可服务 token 数为 $\Theta$，则单位 token 成本近似为

$\text{Cost/token} \approx \frac{C_h}{3600 \cdot \Theta}.$

量化的目标，是在可接受质量下提高 $\Theta$ 或降低所需机型 $C_h$。有时最优方案不是把现有高端 GPU 再压到 INT4，而是把模型量化到能稳定跑在更便宜的机型上。

12. 质量退化的运营成本

别只看算力成本。若量化让用户满意度下降、重试增多、人工复核上升，那么省下的 GPU 钱可能被业务损失抵消。可把净收益近似写为

$\text{Net Gain} = \text{Infra Saving} - \text{Quality Loss Cost} - \text{Ops Complexity Cost}.$

这比单纯看“吞吐提升了 20%”更接近真实决策。

13. 一个企业助手的例子

某企业问答助手把模型从 BF16 改成 INT4，单卡能容纳更多并发，但复杂财务问题正确率下降，导致大量用户二次追问和人工复核。最终算下来，GPU 节省的成本不如人工支持增加的成本高。后来团队改成“主干 INT4 + 关键层 BF16 + 复杂请求路由到高精模型”的混合策略，整体收益反而更好。

14. 一个边缘部署的例子

某工厂需要在本地终端上部署设备巡检模型，网络不稳定，无法总连云。这里量化的主要价值不是极限吞吐，而是让模型在有限显存或 NPU 上稳定运行。此时更看重内存占用、功耗、部署稳定性和 runtime 可维护性。

而不是离线 benchmark 上多快 5%。

15. 设计建议

先明确目标是放得下、跑得快还是降本；用真实 serving stack 和真实请求分布评估量化，不要只看单算子基准；混合精度通常比“全模型统一低比特”更可靠；长上下文系统要把 KV cache 纳入收益分析；运维复杂度和业务质量损失也要一起计入成本模型。

16. 小结

量化的落地，不是一个数值精度问题，而是一个服务栈与硬件协同问题。真正该问的不是“这套量化能不能把模型压到 4bit”，而是“在具体硬件、runtime、请求分布和业务目标下，它是否真正降低了成本并维持了可接受质量”。只有把这些问题一起回答，量化才从方法变成能力。

工程收束

量化服务栈要把硬件特性、kernel 支持、部署链路、单位成本和混合精度策略一起看。最容易踩坑的是理论压缩率无法落地、硬件/软件支持不匹配、只看单机不看集群；更稳的做法是把硬件约束前置，同时评估构建成本与运行收益，并为不同机型准备分档方案。