地铁进隧道，信号断了。有人打开相册搜索“上个月的合同照片”，几秒后结果出来——模型就在这台设备上跑，没有发出任何请求。类似的事情还发生在录音笔的离线转写、车机在无网络地库里的语音指令、相机快门按下去那一刻的降噪与合成。这些场景拼在一起，就是端侧AI正在发生的地方。
装得下，和跑得动，是两件事
把模型放进设备，第一步只是存储：参数按精度换算成字节，占用的是闪存和内存空间。但推理是另一回事。每生成一个词、每处理一帧画面，权重都要从内存搬到计算单元走一遍，限制速度的往往不是峰值算力，而是这条搬运通道的宽度。计算单元空转等数据，是端侧推理里常见的状态。
还有热和电。手机没有风扇，持续推理十几秒后机身发热，系统会降频；车机和录音笔的电池容量有限，一个常驻后台的模型可能悄悄吃掉待机时间。实验室里跑通一个 demo，和让它在真实设备上连续工作半小时，中间隔着的正是这类物理约束。
做减法是件细活
端侧模型的常规做法是量化：把权重从高精度压到低精度，体积变小，带宽压力随之下降。此外还有剪枝、蒸馏、算子融合，以及对话场景里对缓存的管理——把重复计算的部分留下来，避免每一轮都从头再来。
减法不是免费的。精度掉多少，要看具体任务：图像降噪容忍度相对宽，文本理解和多步推理则敏感得多。同一套压缩策略，换个任务就得重新验证一遍。工程上常见的做法是针对场景做小模型，而不是把一个通用大模型硬塞进去——这句话听起来简单，实际落地时意味着数据、训练和评估都要重来一轮。
碎片化是隐形成本
同样一个模型，要在不同厂商的芯片、不同内存规格、不同系统版本上运行。算子库是否支持某个层，驱动版本是否匹配，工具链转换后精度是否漂移，这些琐碎的事项占据的工时，往往超过模型本身的设计。
从“在一台机器上能跑”到“在一批设备上稳定跑”，中间是一条长坡。这也是端侧AI至今没有形成统一交付节奏的原因之一：它天生是分散的，跟着硬件走，而不是跟着一个中心化的服务走。
哪些事值得留在本地
从已有实践看，留在本地的任务大致有几类：
- 涉及私人内容的处理，比如相册检索、语音转写、通讯录整理，数据不出设备本身就能降低暴露面；
- 对时延敏感、需要即时反馈的交互，比如输入法联想、语音唤醒、相机成像；
- 网络条件不稳定或按流量计费成本高的场合，比如车载、户外设备、工业手持终端；
- 需要长期在线但请求量巨大的轻量任务，把调用挪到本地可以省下可观的服务端开销。
反过来，长文档理解、多轮复杂规划、需要频繁更新知识的任务，仍然更适合放在设备之外。端侧AI不是要把所有能力搬进口袋，它更多是在重新分配延迟、带宽和隐私的边界。
一个偏保守的判断
关于端侧AI，容易被忽略的一点是：它的进展大概率不会是某个模型发布带来的跃迁，而是一连串不起眼的适配、压缩和调优累积出来的。用户感知到的也不是参数规模，而是搜索相册时那两三秒的等待，是隧道里语音助手仍然应了一声。
所以评估一件事该不该下沉到设备，与其问模型有多大，不如先问三个问题：这个任务对延迟的容忍度是多少，数据离开设备是否可接受，以及设备在发热和耗电之后还能维持多久的稳定输出。答案往往比算力数字更能决定成败。