第 20 章端侧模型部署¶

开场问题：模型文件 4 GB，8 GB 内存的手机为什么跑不动？

20.1 端侧的约束是"共享"¶

和数据中心最大的区别：端侧的内存、带宽、算力都是和整个系统共享的。应用不能把 8 GB 全用掉——操作系统、其他应用、以及你自己应用的 UI 都要占。可用预算通常只有总内存的一小部分，超了会被系统直接杀掉。

峰值内存比模型文件大小重要得多：权重 + KV + 中间激活 + runtime + 应用本身。开场问题的答案通常就在这里。

INT4 是常态，但格式必须匹配目标 runtime。同样是 4 bit，group size、对称还是非对称、权重的打包布局、scale 的存储方式，各家 runtime 要求都不同。把数据中心的量化文件直接搬到手机上，大概率加载不了，或者加载了走的是慢速回退路径。

选型顺序和第 16.9 节一样：先确认目标芯片的原生指令和 runtime 支持，再谈算法。

端侧 SoC 上有 CPU、GPU、NPU。理想情况是把模型跑在 NPU 上，但 NPU 的算子覆盖有限，遇到不支持的算子会回退到 CPU。

一次回退可能比全程 GPU 还慢，因为跨设备要拷贝数据，而端侧的各计算单元共享内存带宽。划分子图时必须把边界传输的成本算进去，有时"全部跑在 GPU 上"比"大部分 NPU 加几次回退"更快。

判断方法：逐算子 profile，看有没有意外的设备切换。

端侧交付不是给一个权重文件，而是一个自洽的包：固定的计算图、内嵌的权重、tokenizer、采样逻辑、停止条件、以及版本元数据。

第一册的规则在这里同样适用——给端侧的应该是一个文件，而不是一堆需要对方自己拼的零件。任何需要接入方"自己实现一下前后处理"的地方，都是未来 bug 的来源。

手机跑前十个 token 很快，跑十分钟会越来越慢——温控降频是端侧独有的现象。只测短时性能会严重高估实际体验。

端侧的验收必须包含：长时间连续生成的速度曲线、峰值内存、功耗和电池消耗、以及降频后的稳定速度。这几项比首 token 延迟更能决定用户是否愿意持续使用。

现实产品大多是混合的：简单请求本地处理（快、省钱、隐私好），复杂请求上云。端侧模型还可以承担意图识别、草稿生成（给云端做投机解码的草稿）、隐私字段过滤等辅助角色。

系统层面要处理的是：断网时的降级路径、端云两侧模型版本不一致时的行为差异、以及切换决策本身的延迟（判断该走哪边也要花时间）。

Q：4 GB 的模型为什么 8 GB 内存跑不动？ 还要加 KV、激活、runtime 和应用自身，且系统不会让单个应用占满内存。要按峰值内存而非文件大小规划。

Q：同一个 INT4 模型在两台手机上速度差三倍，正常吗？ 正常。低比特只是存储格式，是否有原生指令、高效 kernel 和匹配的布局才决定速度。

Q：NPU 利用率高就说明部署得好吗？ 不一定。如果有频繁的算子回退和设备间拷贝，端到端反而更慢。要看端到端时延，不是单设备利用率。

Q：端侧最该测什么？ 峰值内存、持续生成速度（不是前十个 token）、温控后的稳定速度、功耗，以及真机上的任务质量。