压缩决策：延迟敏感型 AI 功能的量化、蒸馏与端侧推理

模型路由是大多数团队首先采用的优化手段：将简单查询路由到小型廉价模型，复杂查询路由到大型强力模型。它在控制成本和吞吐量方面效果良好。但当云端推理的物理限制与 100ms 以内的延迟需求发生碰撞时，路由便无能为力了。从中间层数据中心发出的一次网络往返，在生成第一个 token 之前就已消耗 30–80ms。此时路由毫无意义——你要么需要将模型运行得更靠近用户，要么需要运行一个规模大幅缩减的模型。这两条路都需要压缩决策，而大多数团队对此并没有清晰的框架。

本文是一份做出这些决策的指南。量化、知识蒸馏和端侧部署这三种技术解决的问题有所重叠，但它们的成本结构、质量表现和运营影响各不相同。

100ms 天花板及其为何改变一切

100ms 以下这个阈值并非任意设定。用户感知研究一致表明，100ms 是交互感觉"即时"而非"响应"的边界。超过这个界限，用户就会感知到明显的停顿。对于自动补全、语音界面、实时文档分析和制造业质检系统而言，超过该阈值会显著降低产品体验。

一个运行在过载 GPU 集群上的 700 亿参数云端模型，生成中等长度内容轻松需要 200–400ms。7B 模型在专用 GPU 上可以达到 50–80ms。INT4 量化的 7B 模型可以达到 30–50ms。在端侧设备上运行的 1–3B 蒸馏模型，无需网络开销，每 token 可以达到 8–15ms。

压缩路径的一端是"对现有模型进行量化"，另一端是"在边缘设备上构建并部署专用的更小模型"。每往下一阶，工程复杂度增加，但能解锁新的延迟目标。

量化：通往更小模型的最快路径

量化通过降低权重的数值精度来压缩模型——从 32 位浮点数（FP32）降至 16 位（FP16）、8 位整数（INT8）或 4 位整数（INT4）。模型架构保持不变，操作基本可逆，无需重新训练。

实际权衡如下：

• FP16/BF16 现已成为生产推理的实际基准。相对于 FP32，内存占用减半，几乎在所有任务上无可测量的质量损失。如果你仍在以 FP32 提供服务，从这里开始。
• INT8 相对于 FP16 内存再减半，精度损失通常低于 1%。对于大多数聊天、摘要和检索增强生成任务，与 FP16 无法区分。LLM.int8() 和 SmoothQuant 等工具处理校准工作。这是内存受限部署的安全默认选项。
• INT4 是权衡开始因任务而异的地方。AWQ 和 GPTQ 等高级方法通过识别哪些权重对精度敏感并保持其更高精度，比朴素 INT4 好得多。即便如此，实地基准测试显示，在 Agent 和工具使用工作负载上，真实任务成功率下降 10–15%。代码生成和多步推理明显退化。INT4 适用于事实召回、摘要和短文本生成；对于推理密集型任务则存在风险。

一个常被忽视的决策：校准数据集很重要。量化精度取决于用于计算缩放因子的校准集统计特性。如果校准数据无法代表你的生产查询分布，你将看到标准基准测试套件无法捕捉到的精度下降。务必在真实生产流量的样本上进行校准。

在硬件方面，如果你的部署目标是 NVIDIA Hopper 或 Blackwell 架构，FP8 已成为务实的最佳选择——硬件原生支持，吞吐量接近 INT8，质量接近 FP16，且比 INT4 需要更少的细心校准。

蒸馏：以训练成本换取任务专项速度

知识蒸馏创建一个新的更小模型（学生），训练它模仿更大模型（教师）的行为。与量化不同，这不是事后变换——它需要完整的训练运行。回报是一个架构上更小的模型，而不仅仅是数值压缩，意味着每个 token 执行更少的运算，能够达到本质上更低的延迟目标。

DeepSeek R1 是一个被广泛研究的案例：从 641B 参数蒸馏到 1.5B 至 70B 不等的变体，使部署硬件从单个 CPU 到多 GPU 工作站都成为可能。具有任务专项微调的蒸馏 8B Llama 模型，在目标任务上可以保留 70B 模型 90–95% 的精度，同时运行速度快 3–4 倍。

蒸馏的决策标准：

• 你的任务域狭窄且稳定。 蒸馏使模型专业化。学生在教师的分布上表现出色，但在范围外的查询上会退化。如果你的功能处理单一类别的用户请求，这是优势；如果用户提问多样，这是劣势。
• 你有训练基础设施。 蒸馏运行需要 GPU 时间、精心策划的训练数据，以及能够衡量输出质量（而非仅仅是困惑度）的评估流水线。与运行量化脚本相比，这是非平凡的投入。
• 目标延迟需要真正更小的架构。 如果你需要在移动设备上实现 20ms 端到端，量化 7B 模型无法做到，而 1B 蒸馏模型可能可以。

研究一致表明，知识密集型任务（事实召回、实体提取）能在蒸馏中存活，而复杂推理、指令遵循链和多语言任务则大幅退化。这与 INT4 量化的脆弱性相同，但原因不同：更少的参数意味着更少的容量用于推理任务所需的泛化能力。

压缩顺序：同时应用两者时

量化和蒸馏并不相互排斥。当你需要最大压缩时，可以同时应用。一项关于压缩顺序的系统研究发现，剪枝 → 蒸馏 → 量化的顺序能产生最佳的大小缩减与能力保留的平衡。直觉上合理：先剪枝去除冗余结构，再蒸馏在更小模型中重建专项能力，最后量化从数值精度降低中提取最终效率收益。

研究清楚表明顺序非常重要。在蒸馏之前应用量化，会迫使学生从一个已经退化的教师信号中学习，质量损失会叠加。

端侧部署：当延迟遇上数据主权

将推理迁移到边缘——移动设备、嵌入式系统、本地服务器——解决的是与云端优化不同的约束集。驱动因素通常是以下三种之一：

1. 硬性延迟要求：以 30fps 进行制造业缺陷检测、实时语音转录，或必须在用户停止输入之前响应的自动补全。无论 GPU 集群有多快，云端往返都会引入 50–200ms 的不可避免开销。
2. 数据主权：医疗、金融和国防工作负载通常不能将原始输入发送到第三方云基础设施。在本地或设备上运行消除了合规风险面。
3. 规模化成本：在每日超过 1 亿次推理请求时，云端定价（每百万 token 0.03–0.60 美元）成为主要成本项。一台 1 万美元的边缘设备摊销三年，在该规模下每百万 token 成本不到 0.10 美元。

硬件选项已大幅成熟。NVIDIA Jetson Orin 以 INT8 量化处理 8B 参数模型，每 token 达到 8–12ms，根据序列长度支持 50–200 个并发请求。Google Edge TPU v3 针对 INT8 量化的较小模型，目标推理块延迟低于 10ms。Apple Silicon（M 系列芯片）通过 llama.cpp 以有竞争力的速度运行 7B 模型，越来越多地用于专业工作站部署。

推理运行时层在这里很重要。llama.cpp 因其可移植性和 GGUF 格式支持，仍是部署最广泛的选项。TensorRT-LLM 在 NVIDIA 硬件上提供最佳吞吐量。带 PagedAttention 的 vLLM 处理高并发边缘服务器部署。运行时决策会将你锁定在某个优化和格式生态系统中；之后切换代价高昂。

混合模式：并非所有请求都相同

大多数生产 AI 功能并不需要每个查询都达到 100ms 以下的延迟。务实的架构按复杂度和延迟需求路由请求：

• 快速路径（端侧或本地）：自动补全、意图分类、表单提取、短文本生成。使用蒸馏 + 量化的 1–3B 模型，目标延迟低于 50ms。
• 标准路径（云端优化）：多轮对话、文档摘要、代码评审评论。在专用推理集群上使用量化 7–14B 模型，目标延迟 100–300ms。
• 深度路径（云端全质量）：复杂分析、长文本生成、质量不能妥协的推理密集型任务。使用全精度或 FP16 模型，接受延迟 500ms 以上。

路由决策本身应该是轻量级的——基于规则的分类器或微小的分类模型，而不是另一个 LLM 调用。路由开销不能消耗快速路径的延迟预算。

向边缘的渐进式发布不可或缺。机群部署应使用金丝雀发布，在全面发布前在生产流量样本上验证精度——因为量化和蒸馏的质量损失往往只会在你的评估集未覆盖的生产查询长尾上出现。

压缩前先构建评估集

团队最常犯的错误是在压缩模型上运行标准基准测试，并将结果视为有意义的数据。MMLU 和 HumanEval 衡量的是广泛能力。你的产品功能有特定的任务分布。在 MMLU 上得分低 2% 的模型，如果你的任务恰好压到压缩退化的能力，可能在你实际用户查询上差 15%。

在压缩任何东西之前，先构建任务专项评估集：

1. 按查询类型分层抽取 500–1000 个真实生产查询。
2. 用未压缩的基线模型生成黄金响应（对关键案例手动生成）。
3. 为你的任务定义适当的自动化指标——摘要用 ROUGE，提取用精确匹配，代码用通过率，开放式质量用 LLM 即评判。
4. 对所有压缩候选运行该评估集，并与基线比较回归情况。

这个集合成为你的压缩回归套件。它在每次部署前的 CI 中运行，告诉你哪个模型版本可以安全上线。

无悔决策

压缩决策不是一次性判断，而是随着模型改进、硬件演进和任务分布变化而持续进行的工程权衡。经得起时间考验的框架很简单：

• 从量化开始。 工程成本低，可逆，能解决大多数延迟和成本问题。默认使用 INT8；仅在 INT8 仍无法满足延迟目标，且你的任务能容忍推理退化时，才转向 AWQ INT4。
• 当量化不够用且任务足够窄时，加入蒸馏。 预算好训练成本，先构建评估套件，将蒸馏模型视为具有独立部署生命周期的独立版本化制品。
• 当延迟或合规要求时，迁移到边缘。 在承诺嵌入式硬件之前，先从在本地运行云端模型开始——每一步的运营复杂度都会显著增加。
• 始终在你的任务分布上做基准测试，而非公共排行榜。 赢得通用基准测试的模型，不一定是在你的特定工作负载上能承受压缩的那个。

做对这件事的团队，将压缩视为模型生产生命周期的一部分，而非部署当天的优化。基准测试套件、蒸馏训练流水线和边缘部署基础设施，都在被需要之前就已构建完毕——因为在截止日期压力下临时添加这些，正是走捷径和质量回归上线的根源。