端侧小模型不是云端的缩水版:把3B放进设备后,你要重构整条链路

“把模型放到端上”听起来像一个部署问题,实际是一个架构问题。

云端模型的所有假设,在设备上都不成立:内存无限→受限、电力稳定→电池供电、延迟可控→受热降频影响、随时可换→需要灰度更新、可以并行→单用户串行。

约束一:内存不是“能不能放下”,而是“放多久不被打扰”

一个3B模型,int4量化后约1.8GB。看起来手机内存足够了。

但真实问题是:系统需要在任意时刻回收你的内存。切到相机、来电话、后台被清,模型都得重新加载。

所以端侧设计的第一个问题是冷启动时间。1.8GB权重从闪存读入并初始化,在中端机上是3~8秒。这个数字直接决定了什么功能只能用、什么功能不能用:

• 秒级响应需求(实时翻译、语音唤起)→ 必须常驻,代价是占用系统内存
• 非实时需求(图片处理、文档总结)→ 可以按需加载,但要在UI上给出明确等待提示

正确的做法是混合:一个极小模型(200M级)常驻,负责意图判断和即时响应;一个大一点的模型按需加载,负责重任务。 用“双模型”替代“一个大模型”。

约束二:能耗与热,比算力更早成为瓶颈

手机上跑3B模型,连续生成会让机身升温,系统随后降频,吞吐掉30%~50%。

这意味着最坏情况下的延迟可能比基准测试慢一倍。所以端侧功能必须给出可中断的流式输出,而不是“转圈3秒后一次性显示”。用户看到字在出来,容忍度完全不同。

实操上还有两条:

• 把长任务切片,每生成一段主动让出CPU给系统,避免触发热管理;
• 提供“轻量模式”开关,用户可主动选择更低质量换更长续航。

约束三:更新机制要按App更新的方式设计

云端模型更新是一个API版本号的事。端侧模型更新是一次几十MB到1GB的下载。

常见的坑:

• 模型和App版本耦合,导致老版本App请求新接口失败;
• 更新中断后权重损坏,启动崩溃;
• 用户流量有限,静默下载1GB被投诉。

对策:模型独立于App版本管理。给每个模型打版本号和能力清单,App启动时拉清单,按需下载增量;不具备新能力的旧模型自动走降级路径(调用云端)。文件下载做完整性校验和原子替换。

约束四:评测必须在真机上做

在笔记本上测出来的token/s,和在中端安卓机上测出来的,差距常常是5倍以上。而且不同厂商的NPU支持程度差异极大,同一份模型文件在A手机上走NPU加速,在B手机上退化为CPU推理。

所以端侧评测至少要覆盖:

• 三档设备的启动时间与首token延迟;
• 连续生成5分钟后的吞吐衰减;
• 内存峰值(是否触发系统杀进程);
• 断电/切换App后的恢复行为。

那端侧到底值不值

判断标准很简单,看下面三条中你能占几条:

1. 隐私是硬需求——数据不能出设备(健康、金融、企业内网);
2. 离线可用是卖点——弱网环境、飞机上、车载;
3. 边际成本——单用户日调用上千次时,云端的token账单会超过设备侧的固定成本。

一条都不占,端侧部署大概率是自找麻烦。云端模型每半年能力翻一档,端侧模型受体积限制,演进速度慢得多。

真正适合端侧的,不是“所有功能都本地跑”,而是“高频简单的本地跑,低频复杂的走云”。这个切分点怎么定,才是端侧架构的核心决策。