第4章 · 端侧AI推理与模型压缩
文档摘要
第 4 章 · 端侧AI推理与模型压缩 章节摘要：不是所有 AI 都能跑在云端。隐私要求（医疗、金融数据不能上传）、网络约束（离线场景、弱网环境）、延迟要求（AR/VR 需要几毫秒响应）、成本考虑（海量请求的带宽和算力费）都推动 AI 往端侧走——手机、IoT 设备、摄像头、汽车里直接跑模型。但端侧资源极其有限：算力弱、内存小、功耗要控（不能发烫掉电快）。这就需要模型压缩三板斧——量化、剪枝、蒸馏——把云端大模型压到端侧能跑的尺寸，再用 ONNX Runtime、TFLite、Core ML 这些端侧框架配合硬件加速落地。这一章讲压缩技术和端侧部署的工程实践。
第 4 章 · 端侧AI推理与模型压缩
章节摘要：不是所有 AI 都能跑在云端。隐私要求（医疗、金融数据不能上传）、网络约束（离线场景、弱网环境）、延迟要求（AR/VR 需要几毫秒响应）、成本考虑（海量请求的带宽和算力费）都推动 AI 往端侧走——手机、IoT 设备、摄像头、汽车里直接跑模型。但端侧资源极其有限：算力弱、内存小、功耗要控（不能发烫掉电快）。这就需要模型压缩三板斧——量化、剪枝、蒸馏——把云端大模型压到端侧能跑的尺寸，再用 ONNX Runtime、TFLite、Core ML 这些端侧框架配合硬件加速落地。这一章讲压缩技术和端侧部署的工程实践。
学习目标
阅读完本章，你应当能够：
- 说清量化、剪枝、蒸馏三种压缩技术各自的原理和适用场景
- 区分 INT8、INT4 量化对模型精度和体积的影响
- 对比 ONNX Runtime、TFLite、Core ML、NNAPI 的定位和适用平台
- 理解端侧部署如何利用 NPU、GPU、DSP 等硬件加速
- 针对手机、IoT、汽车等不同端侧设备给出部署方案
核心概念速览
端侧 AI 的核心矛盾：要在极有限的算力、内存、功耗下，跑出可接受的精度。压缩不是越狠越好，要在体积、速度、精度三者间找平衡。
子章节导航
4.1 量化剪枝蒸馏三板斧
分别讲三种压缩技术：量化降低数值精度（FP32→INT8→INT4），剪枝去掉不重要的权重，蒸馏用大模型教小模型。三者原理不同、代价不同，常组合使用。
4.2 移动端部署框架与硬件加速
讲压缩后的模型怎么在端侧跑起来：ONNX Runtime 跨平台、TFLite 主打 Android、Core ML 主打 iOS，配合 NNAPI、NPU 等硬件加速。重点讲框架选型和性能调优。
子章节之间的逻辑关系
先讲怎么把模型压小（4.1 的三板斧），这是端侧能跑的前提；再讲压小后怎么在端侧设备上高效运行（4.2 的框架和硬件加速）。先压缩后部署。
4.1 模型压缩 ──► 4.2 端侧部署 （怎么变小） （怎么跑起来）
前置知识与后续延伸
- 前置知识：对神经网络的基本结构（层、权重、前向传播）有概念即可，不要求懂训练细节。
- 后续延伸：本章聚焦通用端侧推理。前面章节的流式 LLM 优化方法论，在端侧大模型（如手机上跑小 LLM）场景同样适用，只是资源约束更紧。
端侧 AI 的两波浪潮
端侧推理不是新事物，它经历的两波浪潮值得区分。第一波从 2016 年前后开始，标志是手机 SoC 集成 NPU（苹果 A11 的 Neural Engine、麒麟 970）和 TFLite、Core ML 等框架成熟，主要负载是计算机视觉：人脸解锁、相册分类、扫码识别。这一波的特点是模型小（几 MB 到几十 MB）、任务单一、延迟要求毫秒级，催生了本章要讲的整套压缩和部署工具链。第二波从 2023 年底开始，端侧大模型登场：量化到 4 比特的 1B-3B 参数 LLM 能在旗舰手机上以每秒十几个 token 的速度离线对话，操作系统厂商直接下场把小模型做进系统层（输入法补全、通知摘要、通话翻译）。两波的工程逻辑一脉相承——内存带宽而非算力是第一瓶颈、量化是第一杠杆——但第二波多了 KV Cache 的显存压力和逐 token 生成的热积累问题，手机上跑大模型最常见的故障不是算不动，而是跑两分钟后降频。
另一个持续演化的变量是端侧算力本身。NPU 从最早的几 TOPS 涨到如今的几十 TOPS，且对 INT4/FP8 支持越来越好，这改变了压缩策略的甜点位：五年前 INT8 是精度和速度的稳妥平衡，今天面向 NPU 的模型直接按 W4A16（权重 4 比特、激活 16 比特）设计已属常规。端侧工程师要养成的一个习惯是跟踪目标硬件的年度白皮书，压缩方案的"最优解"每年都在移动。
怎么判断业务该不该上端侧
四个判据按优先级排：一看数据敏感性——医疗影像、金融凭证、未成年人语音这类数据，合规成本可能高于端侧开发成本，直接一票决定；二看网络现实——工厂巡检、车载、户外运动场景天然离线或弱网，端侧是唯一选项；三看延迟量级——云端往返 100 毫秒打底，AR 眼镜的姿势追踪、耳机的降噪要 10 毫秒级响应，只能端侧；四看成本结构——日活千万的产品，云端推理月账单可能到百万级，端侧把这些成本转嫁给用户硬件，但要确认低端机占比可接受（通常要为低端机保留云端回退路径）。四条都不沾的业务，别为了"技术先进"上端侧，云端迭代快一个数量级。
端侧项目还有一个云端没有的隐形约束值得写进章首页：交付物是"跑在千差万别设备上的二进制"，而不是"云端一个服务版本"。这意味着发布节奏被应用商店审核、用户升级意愿（总有百分之几的用户停在旧版本几年不升）和机型长尾（三年前的中低端机要保底能跑）三重钳制，回滚也远比云端慢。所以端侧团队的标准做法是模型能力与 app 版本解耦——模型文件走自有的静默更新通道、按机型分级下发、保留云端回退开关，出问题时能用配置秒级摘掉端侧路径。这套"发布工程"的复杂度常常超过压缩算法本身，也是评估端侧方案时最容易漏算的一笔成本，本章两节会反复回到这个现实约束上。