端侧推理的能耗账：小模型为何重新受到关注

网络延迟之外的另一本账

把推理放在本地设备上，直观收益是响应更快、数据不出设备。但真正决定可行性的，往往不是延迟，而是能耗。一块手机芯片的持续算力预算，与机房里插着电的加速卡完全不是一个量级。

于是选型逻辑发生变化：不再是单纯追求指标，而是先看单位任务消耗多少能量、热量能否在被动散热条件下散掉。这两个约束一旦成立，大参数量模型即便指标占优，也很难排上日程。

压缩手段的实际边界

常见的做法包括量化、剪枝、蒸馏与低秩分解。量化的收益相对确定，把权重从高精度降到低精度，模型体积和访存量同步下降；问题在于某些层对精度敏感，一刀切会带来可感知的质量损失。

蒸馏的思路是让小模型去拟合大模型的输出分布，效果取决于教师模型的覆盖面。如果教师本身在目标任务上表现不稳，学生学到的也只是不稳定的分布。这类问题在评测集上未必暴露，上线后才浮现。

内存带宽才是瓶颈

很多端侧场景下，算力并非限制因素，内存带宽才是。权重每生成一次输出就要被读一遍，访存量决定了实际速度。这也是为什么同等参数量下，结构更紧凑的模型跑得更快。

对应的优化方向包括算子融合、缓存友好的排布，以及把注意力机制里的键值缓存做分页管理。这些工程细节对最终体验的影响，常常超过换一个更激进的量化方案。

混合执行的现实选择

纯粹的端侧执行并不总是划算。比较务实的方案是分层：隐私敏感与高频短任务在端上完成，复杂长任务交给远端，中间用一套路由规则决定去向。

路由规则本身需要可观测。哪些请求被判为复杂、端侧失败率多少、降级是否顺畅，这些指标缺失时，混合架构会退化成两套系统各自维护、问题互相推诿。

评测口径需要重建

沿用云端的评测方式评价端侧模型容易失真。只看准确率会忽略耗时、耗电与发热；只看速度又会掩盖质量下滑。合理的做法是把能耗与首字延迟纳入同一张表。

此外还要区分冷启动与稳态。首次加载权重的一次性开销，与持续对话时的平稳表现，优化手段并不相同，混在一起汇报会让结论失去指导意义。