把模型文件装进手机，通常只是最容易的一步。Redmi Note 12 Pro+（天玑1080）尝试 Qwen2.5-3B-Instruct，iPhone 13（A15 Bionic）尝试 Llama-3.1-8B，都会碰到几件现实问题：权重能否装下、算子究竟跑在 CPU、GPU 还是 NPU、连续对话后是否降频。
旧机型要看持续可用，不能只看是否吐出了第一个 Token。
先算权重，再谈能不能跑
阿里云开发者社区的 INT4、INT8 说明给出了一组直观差异：INT8 有 256 个离散值，INT4 只有 16 个。按 FP32 权重位宽粗算，转成 INT8 和 INT4 后，权重存储量理论上分别减少 75% 和 87.5%。
这组数字只对应权重位宽，不等于整机内存会按相同比例下降。《小米大模型端侧部署落地探索》把量化带来的收益分为存储、内存到 SRAM 的带宽和计算开销，同时单独讨论了 KV cache。也就是说，模型文件缩小以后，上下文和运行时缓存仍然要占内存。
SmoothQuant、AWQ 可以用来减轻低位宽量化带来的精度波动，但损失不能套用一个固定百分比。模型、校准数据和任务不同，结果也会变。部署前至少要用自己的提示词和任务集复测。
| 格式 | 在旧设备上的位置 | 需要先确认 |
|---|---|---|
| INT8 | 适合作为兼容性和速度基线 | 峰值内存、后端是否有可用算子 |
| INT4 | 内存吃紧或尝试 8B 模型时再用 | 精度回退、解量化开销、内核支持 |
| FP8 | 硬件与推理后端明确原生支持时再测 | 是否发生格式转换或 CPU 回退 |
低位宽可能更省内存，也可能更慢
量化文件变小，不代表每个算子都能直接用低位宽执行。旧 SoC 如果缺少匹配的 INT4 内核，推理过程中可能频繁解量化，甚至回退到 CPU。此时，INT4 的内存优势还在，速度却未必胜过 INT8。
所以，在天玑1080上看到 INT8 比 INT4 更快并不反常；在 A15 上用 llama.cpp 加载 INT4 后，首 Token 仍然偏慢、机身持续升温，也需要先查后端路径。GGUF 方便分发和加载，但它只是模型格式，不会自动带来 NPU 加速。
比较两种量化格式时，测试条件要固定：
- 使用同一模型、上下文、提示词和生成参数；
- 分别记录首 Token 延迟、稳定输出速度和峰值内存；
- 连续对话 10 分钟，观察速度是否随温度下降；
- 手机壳、充电状态和室温保持一致。
缺少这些条件，单次跑分很难迁移到另一台手机，也不足以证明某种位宽更适合所有旧设备。
别把 NPU 当成万能开关
手机里有 NPU，不代表当前推理引擎就能把主要算子送进去。算子支持不完整时，一部分计算仍会落回 CPU，调度和数据搬运反而可能拖慢推理。
iOS 可以测试 Metal 路径，Android 可以测试 Vulkan 路径。使用 MLC LLM 或 llama.cpp 时，配置项会随项目和版本变化，不宜直接照搬 num_compute_units、use_npu 一类字段。更稳妥的做法是先跑 CPU 基线，再开启 Metal 或 Vulkan，逐步调整 GPU 卸载层数，同时查看日志里是否存在大量算子回退。
NPU 也应按同样的方法验证：确认推理后端明确支持目标芯片，并从执行日志判断主要计算是否真的落在 NPU 上。只切换一个开关，没有太大参考价值。
两台旧设备，起点要分开
Redmi Note 12 Pro+（天玑1080）
Qwen2.5-3B-Instruct 可以先用 INT8 建立基线。若模型和运行时能够装入内存，就先测持续速度，再决定是否转 INT4。只有在峰值内存已经成为瓶颈时，INT4 的价值才足够明确。如果切到 INT4 后反而变慢，优先排查内核和后端，不要急着归因于模型。
iPhone 13（A15 Bionic）
Llama-3.1-8B 更适合作为边界测试。日常离线问答可以先用 3B 级纯文本模型确认 Metal 路径和发热情况；确实需要保留 8B 时，再用 INT4 压低权重占用，并控制上下文长度。能成功加载，不代表能够长时间稳定输出。
对这类设备，3B—7B 纯文本模型更适合作为目标区间。13B 多模态模型对内存、带宽和散热的要求更高，不宜当作旧手机的默认方案。
FP8 先查支持表
FP8 的动态范围对混合精度训练和部分推理负载有价值，但旧手机是否受益，取决于芯片和推理后端有没有原生支持。如果加载后仍要转成其他精度，或者关键算子回退到 CPU，FP8 就失去了选用理由。
测试前先确认模型格式能否直接导入、关键算子有没有对应内核，并查看执行日志。任何一项说不清，回到 INT8 或 INT4 通常更省时间。
发热按十分钟后的状态算
手机壳和充电状态都值得单独测试。取下手机壳可以减少一层热阻；避免边充电边推理，则能减少电池和芯片同时发热。具体能降多少温、延长多少续航，要以设备实测为准，不能预设固定结果。
用同一段提示词连续运行 10 分钟，记录开始和结束时的输出速度与机身温度。如果前几轮很快，随后明显降速，瓶颈已经从算力转到热管理。这样的配置适合短任务，未必适合长对话。
一套更稳的部署顺序
- 先用 3B 级纯文本模型跑通完整链路；
- 用 INT8 建立速度和精度基线；
- 内存不足时切到 INT4，再检查速度与任务效果；
- 基线稳定后测试 Metal 或 Vulkan 卸载；
- 只有硬件和后端明确原生支持时才尝试 FP8；
- 最后做 10 分钟连续推理，排查降频和充电发热。
一张成功运行的截图证明不了可用性。速度和温度能够保持稳定的连续对话，才是旧机型部署端侧大模型的及格线。
