第六章：端侧部署——把大模型塞进手机

通俗版

量化：把参数"降分辨率"

把模型从 FP16 量化到 INT4，字节数缩小 4 倍，但问题不只是体积。

FP16 表示的是一个浮点数，范围覆盖极大，精度在大数和小数之间自动调节。INT4 只有 16 个可能的值（-8 到 7），把原来连续的权重强行映射到这 16 个离散值上，必然有信息损失。

类比是把一张 16 位灰度图压缩成 4 色灰度图——你把所有中间灰色都强制映射到"深灰、中灰、浅灰、白"四种颜色，精细纹理全部丢失。

量化损失的感知因任务而异：对于简单问答，几乎感知不到；对于精确数值计算或长上下文，INT4 的误差可能累积放大，导致明显质量下降。

LoRA：轻量补丁，按需切换

不需要在手机上存一整个专用模型。手机里放一个通用基础模型，每个应用场景（写代码/翻译/总结）只需要下载一个几十 MB 的"补丁文件"（LoRA）。打开代码 App，加载代码 LoRA；切换到翻译 App，换上翻译 LoRA。基础模型不动，按需切换能力。

LoRA 的核心想法是：大模型的全量微调太贵，但如果相信"微调只需要在原始权重上做一个低秩的更新"，可以用两个小矩阵的乘积来近似这个更新。

原始权重矩阵是 4096×4096 = 16M 个参数。LoRA 加了两个旁路矩阵：A 是 4096×8，B 是 8×4096，总共约 65K 个参数。推理时把 BA 加到原始权重上，效果接近全量微调但参数量缩小了 200 多倍。

这和 iOS 里的 Category Extension 很像——原始类不动，给它打一个 patch 扩展功能，可以独立分发、热切换。

TTFT vs TPS：两个不同的瓶颈

从发送请求到第一个字出现的时间叫 TTFT（Time to First Token，首字延迟）；之后字弹出来的速度叫 TPS（Tokens Per Second，吐字速度）。

这两个指标背后是两个不同的瓶颈：

• TTFT 取决于 Prefill 阶段：一次性并行处理整个输入 prompt，受限于计算能力（GPU 算力）

• TPS 取决于 Decode 阶段：逐个生成 token，每步都要读一遍 KV Cache，受限于内存带宽

Decode 为什么经常卡在带宽上？ 每吐一个 token，推理引擎都要读取大量模型权重，并访问不断增长的 KV Cache。batch 较小时，矩阵运算很难把 GPU 算力完全吃满，数据搬运往往先成为瓶颈。具体 TPS 仍取决于量化、batch、并行方式、内核实现和硬件，不能只用显存带宽除一次数据量得到固定答案。量化和 MoE 会减少每步实际读取的权重，投机解码则尝试让一次大模型验证确认多个候选 token，它们都在改善每个输出 token 的有效成本。

优化方向完全不同：想降 TTFT 要优化计算并行度，想提 TPS 要优化内存带宽利用率。

投机解码：小模型猜，大模型验

用一个轻量小模型（1B）先快速猜 5 个候选 token，大模型（70B）一次性验证这 5 个 token 对不对。验对的全部接受，第一个不对的回退，从那个位置重新采样。

关键是：大模型可以并行验证一段候选 token，比自己逐个 Decode 更容易利用硬件。最终能加速多少，取决于草稿长度、接受率、batch、模型大小和推理内核；候选大量被拒绝时，草稿成本反而会抵消收益。

进阶版

几种量化方案的工程特点

GPTQ：逐层量化，每量化一个权重，就用 Hessian 矩阵的信息补偿其他权重，把误差分散出去。质量比简单四舍五入好很多，但量化过程本身需要 GPU 跑几个小时。适合"量化一次，反复推理"的离线场景。

AWQ（Activation-aware Weight Quantization）：重要的权重（乘以激活后影响大的那些）更精细地量化，不重要的更粗。通过对重要权重做缩放，让它们在量化时损失更小。

GGUF：llama.cpp 的格式，支持从 Q2 到 Q8 的各种精度，面向 Mac/PC 端侧部署。在 M 系列 Mac 上利用统一内存架构，CPU 和 GPU 共享内存，GGUF 模型可以非常高效地运行。

投机解码的精确性保证

target model 在第 k 个位置不接受 draft token 时，会从 (target_prob - draft_prob) 的校正分布里采样一个新 token。这确保最终生成的 token 序列的概率分布，和完全由 target model 逐 token 生成完全一样——投机解码是精确等价的，不是近似。这也是它区别于别的加速方案的地方。

主流端侧推理引擎选型