当 AI 应用撞上 100ms 延迟天花板，云端大模型的物理限制就成了无法绕开的瓶颈。近日一篇系统梳理 LLM 压缩决策的技术文章引发开发者关注，文章指出量化、蒸馏和端侧部署三条路径虽目标相似，但工程成本、质量表现和适用场景差异显著，团队往往缺乏清晰的决策框架。 量化是最快速的压缩路径。FP16 已成实际基准，INT8 精度损失通常低于 1%，AWQ/GPTQ 等高级方法通过识别敏感权重比朴素 INT4 表现更好。但 INT4 在 Agent 和工具使用工作负载上真实任务成功率下降 10–15%，代码生成和多步推理退化明显。NVIDIA Hopper/Blackwell 架构上 FP8 是务实选择，吞吐量接近 INT8，质量接近 FP16。 蒸馏需要完整训练流程换取任务专项速度。研究表明知识密集型任务（事实召回、实体提取）能在蒸馏中存活，而复杂推理、指令遵循链和多语言任务大幅退化。这意味着蒸馏适合狭窄稳定任务域，而非通用聊天。 压缩顺序研究证实剪枝→蒸馏→量化顺序产生最佳大小缩减与能力保留平衡。先剪枝去除冗余结构，再蒸馏重建专项能力，最后量化提取最终效率收益。在蒸馏之前应用量化会使质量损失叠加。 端侧部署方面，Jetson Orin INT8 量化 8B 模型每 token 达 8–12ms，Apple Silicon 通过 llama.cpp 有竞争力运行 7B 模型。驱动因素通常是硬性延迟要求、数据主权或规模化成本。 文章最核心的建议是：在压缩任何模型之前先构建任务专项评估集。MMLU 和 HumanEval 衡量广泛能力，但你的产品功能有特定任务分布——在 MMLU 上得分低 2% 的模型，如果任务恰好压到压缩退化的能力，可能在实际用户查询上差 15%。赢下通用基准的模型，不一定是最能承受压缩的那个。 对于 AI 工程团队而言，压缩不是一次性判断，而是随模型改进、硬件演进而持续进行的工程权衡。从量化开始、用蒸馏补足、端侧部署兜底，这套组合拳的关键在于评估先行——基准测试套件和蒸馏训练流水线在被需要之前就已构建完毕，而非在截止日期压力下临时添加。