端侧模型瘦身之后：体验靠什么补回来

参数变小不等于变快

端侧模型的常见做法是量化与蒸馏。参数量降下来之后，模型体积变小，理论上启动更快。但实际体验的提升往往不如预期，原因多半不在算力，而在内存带宽。

推理过程中权重需要反复搬运，移动端内存带宽有限，搬运时间会盖过计算时间。这就是为什么有些模型跑分不错，实际用起来仍然卡顿。

功耗预算决定调用频率

手机对持续功耗非常敏感。一段几十秒的连续推理就可能让机身发热，随后系统降频，体验反而变差。可行的思路是把推理拆成短时任务，在用户等待的间隙完成，而不是一次性跑完。

调用时机同样关键。输入法联想、相册搜索这类场景可以预判，适合常驻小模型；文档摘要、图片理解这类场景属于按需触发，适合临时加载大一些的模型。

混合推理是现实选择

端云协同并不是过渡方案，而是长期架构。把涉及隐私、需要低延迟的部分放在端侧，把需要世界知识和长上下文的部分交给云端，再由端侧做结果整合。

难点在于一致性。同一份数据在两端可能有不同版本，需要在同步层做冲突合并。工程上通常给端侧数据打时间戳，云端以服务端版本为准，端侧保留待同步队列。

用户体验的最后一公里

端侧模型的价值不在于参数量，而在于它能不能在离线、弱网、隐私敏感的场合派上用场。把这些场景做扎实，比在跑分上争高低更有意义。

对厂商来说，一个务实的判断标准是：关掉网络之后，这个功能还能不能用。能用的部分，才是端侧真正的护城河。

评估端侧价值的方法

比较务实的评估方式是做 A/B 测试：同一功能分别用端侧与云端实现，观察完成率、时延与耗电。只看跑分或演示视频，容易高估收益。

另一个指标是离线可用率。把网络关闭后，功能是否仍能完成核心任务，直接决定了端侧方案的存在意义。