从 Distillation、Pruning、Quantization、Sparsity、LoRA 合并、小模型路由到 NPU / CPU / 浏览器 / 本地私有化，理解模型怎样从“能跑”变成“跑得起、跑得近、跑得稳”
| 变量 | 它控制什么 | 常见取舍 | 相邻页面 |
|---|---|---|---|
| 参数量 | 模型可表达的容量和显存占用 | 越小越便宜，但复杂推理、长尾知识和鲁棒性更容易掉 | 模型架构族谱 |
| 数值精度 | 权重和激活用多少 bit 表示 | 低 bit 省内存、提吞吐，但可能伤害分布、校准和格式稳定性 | 推理计算 |
| 目标硬件 | 模型真正在哪里运行 | GPU 强但贵；CPU 普遍但慢；NPU 省电但算子和格式受限 | AI Infra |
| 任务分布 | 模型要服务哪些真实请求 | 小模型适合高频、窄域、可验证任务；开放式复杂任务仍常要大模型 | 模型评测 |
| 质量闸门 | 压缩后能否上线 | 不能只看平均分，要看结构化输出、工具调用、安全边界和长尾退化 | LLMOps / 评测 |
模型压缩不是把模型“无损缩小”，而是把能力、成本、延迟、内存、功耗和隐私放到同一张账本里重新分配。
| 量化类型 | 怎么理解 | 适合场景 | 主要风险 |
|---|---|---|---|
| PTQ | 训练后直接把已有模型权重量化 | 快速部署、离线试验、本地模型压缩 | 校准数据不足时，长尾任务和格式稳定性掉得明显 |
| QAT | 训练时模拟低精度，让模型适应量化误差 | 高质量低 bit 模型、端侧长期产品 | 训练成本更高，流程更复杂 |
| Weight-only | 主要压权重，不压或少压激活 | LLM 显存压力大、希望保留较好质量 | 吞吐收益受硬件和 kernel 支持影响 |
| KV Cache 量化 | 压缩长上下文推理时缓存的 K/V 张量 | 长上下文、多并发、显存受限场景 | 上下文召回、长距离引用和细节保真可能受损 |
| 混合精度 | 关键层高精度，其他层低精度 | 质量敏感但仍要降本的生产系统 | 需要评测找到真正敏感的层和任务 |
量化会把连续权重映射到更粗的离散刻度。模型不是每个参数都同等敏感，某些层、某些激活离群值、某些多语言或长上下文模式更容易被低精度误差放大。
| 蒸馏方式 | 训练信号 | 适合什么 | 注意点 |
|---|---|---|---|
| Response Distillation | 教师模型最终回答 | 客服、分类、固定模板、领域问答 | 容易学到结论，学不到过程 |
| Preference Distillation | chosen / rejected 或排序偏好 | 风格、拒答、安全边界、产品口径 | 偏好口径漂移会直接传给学生模型 |
| Reasoning Distillation | 中间步骤、验证轨迹、工具运行结果 | 数学、代码、可验证任务、Agent 流程 | 思路数据必须可审计，避免蒸馏错误推理模板 |
| Data Distillation | 合成数据、坏例改写、场景扩增 | 窄域任务冷启动、评测集扩展 | 合成数据会带来模型自我强化偏差 |
| Specialist Distillation | 某个垂直场景的数据闭环 | 企业内部流程、端侧助手、低成本高频任务 | 边界必须清楚，别让专才小模型冒充通用大模型 |
如果任务高频、窄域、可评测、失败成本可控，蒸馏小模型很值得；如果任务开放、风险高、需要跨领域推理，小模型更适合做初筛、草稿或路由，而不是最终裁判。
| 运行位置 | 优势 | 硬约束 | 典型任务 |
|---|---|---|---|
| 云端 GPU | 模型大、吞吐高、更新快、集中治理 | 成本、延迟、隐私、网络依赖 | 复杂问答、推理模型、企业 Agent、大规模服务 |
| 本地 CPU | 门槛低、私有、离线可用 | 慢、内存有限、并发差 | 个人助手、文档摘要、离线草稿、本地检索 |
| 移动 / PC NPU | 低功耗、低延迟、适合常驻能力 | 模型格式、算子支持、内存、系统权限 | 输入法、语音、图片理解、隐私敏感任务 |
| 浏览器 / WASM | 免安装、靠近用户、数据不出端 | 模型大小、加载时间、性能差异、兼容性 | 轻量分类、嵌入、局部改写、边缘交互 |
| 边缘设备 | 靠近现场、低网络依赖、实时性好 | 散热、功耗、升级、观测和远程治理 | 摄像头、工业质检、机器人前端感知 |
端侧 AI 的价值不只是省钱。它还能降低网络延迟、保护本地数据、支持离线能力，并让高频轻任务不必穿过完整云端链路。但它会把模型更新、质量观测、设备碎片化和安全治理变成新问题。
| 评测维度 | 为什么压缩后容易出问题 | 检查方法 |
|---|---|---|
| 核心任务正确率 | 平均分可能变化不大，但关键业务场景掉点 | 按真实请求分桶，看高频、长尾、高价值任务 |
| 结构化输出 | 低精度可能让格式、括号、字段和工具参数更不稳定 | Schema 校验、工具参数回放、格式失败率 |
| 长上下文能力 | KV Cache 量化和小模型容量不足会伤远距离引用 | 长文召回、跨段一致性、引用位置检查 |
| 多语言与代码 | 词表、稀有 token 和语法细节更容易受损 | 中文、英文、代码、混合文本分别评测 |
| 安全边界 | 拒答、越权、敏感内容判断可能被压缩破坏 | 安全红队集、越狱样本、权限场景回放 |
| 置信与路由 | 小模型可能不知道自己不知道 | 低置信升级、大模型复核、人工抽检 |
| 设备体验 | 端侧要同时看加载、发热、电量、内存和冷启动 | 真实设备矩阵、长时间运行、离线压力测试 |
只用一个通用 Benchmark 判断压缩是否成功。生产里真正伤人的，往往是格式失败、安全边界变松、长上下文丢细节、某类用户设备卡死，或者小模型在低置信任务上硬答。
压缩的目标不是让模型“能跑起来”，而是在明确设备、任务、质量和兜底策略下证明它值得上线。
| 证据节点 | 必须记录字段 | 用来判断什么 |
|---|---|---|
| compression_run | compression_run_id、source_model_hash、teacher_model、student_model、recipe_version | 这次压缩从哪个模型、哪套配方和哪次实验来 |
| calibration | calibration_set_id、task_slice、language_slice、device_matrix、kernel_matrix | 校准数据和目标设备是否覆盖真实使用分布 |
| quality_delta | baseline_eval_id、compressed_eval_id、degradation_slice、format_fail_rate、safety_regression | 质量退化发生在哪些任务、语言、格式或安全边界上 |
| release_gate | fallback_model、routing_rule_version、rollback_policy、release_gate_id | 小模型或量化模型上线后如何升级、兜底和回滚 |
| 页面 | 关注问题 | 本页提供的补位 |
|---|---|---|
| 推理计算 / KV Cache | 一次请求在 Prefill、Decode、KV Cache 和 batching 上为什么慢、为什么贵 | 解释模型低精度、小型化和端侧运行后，质量与硬件约束怎样改变 |
| 模型服务 / 网关 | 多模型接入、路由、限流、Fallback、SLA 和成本归因 | 提供“小模型先跑、大模型兜底”的模型选择依据 |
| 开源 LLM 部署 | 开源权重怎样选型、打包、上线和治理供应链 | 解释 GGUF、ONNX、量化模型、端侧模型为什么会出现质量差异 |
| AI 成本与性能工程 | token 成本、缓存、路由、预算和单位价值 | 把压缩看成降本策略的一种，但要求用评测和路由防止省错钱 |
| AI 治理 / 隐私 / 合规 | 数据、授权、审计、责任和监管边界 | 解释为什么端侧和本地模型能缓解部分隐私问题，但不能自动解决治理问题 |
如果说训练页回答能力怎样被训练出来，推理计算页回答一次调用怎样消耗显存和算力，那么本页回答能力怎样被压缩到更小、更低精度、更靠近用户的运行形态里。它是理解小模型、端侧 AI、本地模型、低成本路由和私有化部署之间共同机制的一层底座。