端侧小模型：参数量只是第一道门

“小模型”常被简化成参数规模，但端侧部署是一张多维预算表：

$$M_{\text{total}} = M_w + M_a + M_{\text{kv}} + M_{\text{runtime}} + M_{\text{temp}}$$

任何一项超限，系统都可能无法启动、掉帧或热降频。

结构

MobileLLM 研究了亚十亿参数模型的结构选择，强调深度、宽度、分组查询注意力与嵌入共享等设计对质量的影响。它说明“同参数量的模型”并不等价，层数和宽度会改变计算与内存的访问模式。

Phi-3 展示了高质量小模型的另一条路线：数据筛选、训练配方与模型规模共同作用。模型能力不能只由参数解释。

量化

AWQ 观察激活分布，保护对量化更敏感的权重通道，以降低低比特量化的误差。对硬件来说，低位宽减少权重读取和存储，但反量化、混合精度和算子融合会引入新开销。INT4 不自动等于四倍速度。

运行与热

端侧还要考虑：

• 首 token 的冷启动与前缀填充；
• 连续对话中的 KV 增长；
• NPU 与 CPU 之间的数据搬运；
• 峰值功耗下的降频；
• 模型文件、运行库和固件的总包体。

TinyML 内存预算 可以先把权重、激活、KV 与运行时余量放进同一块 SRAM。它不能替代设备实测，但能尽早排除明显不可行的配置。

结论

选端侧模型时，先写清楚目标设备的可用内存、带宽、算力、功耗和延迟，再用同一套指标比较结构、量化与运行时。榜单分数是起点，不是部署证明。

把“端侧”拆成三种时间尺度

讨论端侧模型时，最容易把三个完全不同的指标混在一起：首 token 延迟、解码吞吐和持续可用时间。Preference 场景关心用户按下发送后多久出现第一个字；批处理或语音唤醒更关心每秒能处理多少 token；可穿戴和车端还要看设备在热约束下能维持多久。

首 token 阶段需要处理系统提示、历史对话和当前输入，计算量随前缀长度增长；解码阶段每生成一个 token 都要读取历史 KV，并反复调用全部层的权重。前者更像一次大矩阵乘，后者更接近对带宽和调度敏感的循环。一个模型在短提示 benchmark 上很快，不代表在长上下文或多轮对话中仍然可用。

可以用一个只估算解码下限的式子建立直觉：

$$T_{\text{decode,token}} \ge \frac{B_w + B_{\text{active}}}{BW_{\text{eff}}}$$

$B_w$ 是本次 token 需要读取的权重字节，$B_{\text{active}}$ 是激活和 KV 的额外访问量，$BW_{\text{eff}}$ 是实际可达到的有效带宽。这个式子忽略了并行、缓存和算子启动，因此只能作为下限。它仍然能解释一个常见现象：权重位宽降低后，模型文件确实变小，但若运行时频繁反量化、在 CPU 与 NPU 之间搬运张量，端到端时间不一定会等比下降。

三个模型工作的共同点和差异

MobileLLM 讨论的是亚十亿参数量级模型的结构选择，重点包括深度与宽度、分组查询注意力、嵌入共享和权重共享。它提醒我们：同样参数量的模型，计算图和数据访问模式可以完全不同。更深的网络增加串行层数，更宽的网络增加单层矩阵规模；在端侧，二者对应的延迟、SRAM 峰值和算子融合机会并不相同。

Phi-3 的技术报告把训练数据、训练配方和模型规模放在一起讨论。高质量小模型并不是“把大模型简单裁小”，而是通过数据课程和训练策略提高每个参数的有效性。这意味着参数数量不能单独解释能力，也不能单独解释部署成本。

AWQ 从激活分布出发，保护对量化更敏感的权重通道，用激活感知的缩放降低低位宽误差。它的部署价值来自减少权重读取，但实际速度取决于硬件是否支持对应的低位宽矩阵乘、是否能在片上完成反量化、以及是否保留了足够大的 batch 以摊薄启动开销。

三篇工作的评价条件和目标不同，不能把它们的准确率、速度或内存数字直接拼成一张排行榜。可比较的是方法暴露的约束：结构改变数据流，训练改变参数质量，量化改变数值格式和 kernel 集合。

量化不是一个旋钮

端侧常见的量化组合至少有三种：

组合	权重	激活	典型收益	主要风险
W4A16	4-bit	16-bit	权重带宽下降，精度相对稳	反量化与混合精度 kernel
W8A8	8-bit	8-bit	更好的整数量化加速	激活离群值与校准误差
动态量化	低比特	运行时量化	实现简单、适用范围广	每次运行有额外转换成本

权重位宽只决定静态存储的一部分。激活峰值通常在注意力或前馈中间层出现，可能比“模型文件大小”更早触碰 SRAM。KV 会随上下文长度和并发增长，在流式对话中持续占用内存。若设备支持内存映射 Flash，权重可以按层加载，但每次加载仍要消耗带宽和能量，且会破坏长时间连续生成的缓存局部性。

量化误差也必须按任务衡量。分类任务可能容忍较小的 logit 偏差，代码生成或工具参数生成却可能因为一个 token 改变整个执行路径。评估时至少同时报告：量化前后的任务准确率、最长上下文、首 token 与解码延迟、峰值内存、功耗与温升。只报告“4-bit 后模型缩小四倍”无法回答能否交付。

运行时决定模型是否真的落地

在同一颗 SoC 上，运行时可以做算子融合、常量折叠、内存池复用、异步 DMA、NPU 图切分和 CPU fallback。不同选择会改变三个关键数字：峰值工作区、kernel 启动次数和设备间数据搬运。

一个实用的容量检查应该从目标工具链导出，而不是从参数量心算：

1. 用最终量化格式编译模型，记录权重、激活、KV 和临时缓冲的 arena 峰值。
2. 用最长输入、最大并发和目标上下文长度运行，观察是否发生动态分配。
3. 检查算子覆盖率。任何回退到 CPU 的算子都可能插入同步点。
4. 在低温与热稳定状态下各测一次首 token 和解码吞吐。
5. 关闭调试日志、性能计数和未使用后端，重新确认包体与内存。

在 MCU 上，这些数字还要映射到链接脚本的 Flash、SRAM、TCM 和 DMA 可访问区域。栈、中断服务程序、RTOS 对象和通信缓冲不能因为“模型很小”就被忽略。对 Linux 或 Android 设备，页缓存、共享内存和 GPU/NPU 驱动也会改变实际占用。

失败边界比平均值更有用

端侧模型最常见的失败不是跑分低，而是在边界条件下失效：

• 提示长度从 512 增加到 4K 后，KV 把 SRAM 推过上限；
• 温度升高触发降频，持续吞吐下降；
• 某一层使用了不支持的量化算子，运行时插入反量化并回退到 CPU；
• 多任务并发时，模型工作区与摄像头、DMA 缓冲争抢内存；
• 模型更新后固件包体增大，OTA 分区无法容纳双镜像；
• 量化校准集与真实用户输入分布不一致，长尾任务质量下降。

因此，端侧验收不应只看一张平均延迟表。应把配置写成“模型版本 + 量化方案 + 运行时版本 + 目标设备 + 最大上下文 + 并发数 + 温度状态”，并保留失败样本。只有这样，后续替换模型时才能知道性能变化来自算法、工具链还是硬件。

一个可审计的选择流程

先判断任务是否真的需要本地推理。若网络稳定、隐私要求低，云端大模型可能更便宜；端侧的价值通常来自离线可用、低延迟、数据不出设备或带宽受限。确认必要性后，再按以下顺序缩小候选：

1. 用任务质量门槛筛选模型和量化方案；
2. 用目标运行时的 arena 报告检查 Flash/SRAM；
3. 用有效带宽估算解码下限；
4. 在热稳定状态下测首 token、持续吞吐和功耗；
5. 对最长上下文、最低电量、最高温度做故障注入；
6. 保留可回退的小模型或云端降级路径。

端侧 AI 的工程目标不是把一个云端模型“塞进去”，而是在设备约束下提供可预测的质量和延迟。参数量是第一道门，后面的每一道门都需要测量。

从论文结论到设备结论

论文中的模型大小、训练数据和评测集，通常无法直接映射到产品。一个在通用问答上表现好的小模型，可能在领域术语、结构化输出或工具参数上失效。量化后的任务准确率也不能只看整体平均，需要按输入长度、语言、业务类别和风险等级拆分。

部署团队应建立一张“模型契约”：输入格式与最大长度、输出格式与容错策略、目标设备、精度容忍度、内存上限、最大功耗、热稳定条件、回退模型和监控指标。任何模型或运行时升级，都要重新跑这套契约。这样，端侧模型不是一次选型，而是持续验证的系统组件。

能量也需要单独报告。推理期间的平均功耗决定电池寿命，峰值功耗决定电源和热设计，待机漏电决定长期可用性。一次 benchmark 只测几十毫秒，无法反映设备在温升后的频率变化。持续对话、间歇唤醒和低电量状态应分别测量。

最后，端侧模型应提供可观测的失败路径。当上下文超限、内存不足、算子不支持或温度过高时，系统要有明确的降级：缩短上下文、切换更小模型、延迟请求或转到云端。静默截断输入或返回格式错误的结果，比显式失败更危险。

部署前建议固定一个最小回归集：短语指令、长上下文、结构化输出、低电量与高温场景。每个场景记录内存峰值、首 token 时间、输出质量和降级动作。模型参数再小，只要在真实设备上不能稳定复现这些行为，就不能称为端侧可用。

最终的端侧报告应把权重、激活、KV、运行时和热预算放在同一张表里。只写“4-bit 量化”或“2B 参数”无法说明能否上线，完整的可部署证据才值得相信。

这份预算表应该随着每个模型版本重新跑一遍，而不是沿用上一次的估算。

对每一次模型升级，还应保留旧版本作为回退基线。新模型只有在质量、内存和热行为都稳定后，才应替换旧版本，而不是只看离线 benchmark。

版本回退也应自动可用：本地保留小模型、配置和 tokenizer 的兼容版本，避免网络或云端故障让设备完全没有能力。端侧部署的可靠性来自完整的运行闭环，而不是单个模型的离线指标。

这条闭环应被产品验收覆盖，而不是只存在于工程说明里。

能够让用户明确看到降级原因，比静默返回一个看似正常的错误答案更负责任。