早高峰的地铁里，手机信号掉到一格，语音助手沉默了几秒，屏幕上转着圈。这几秒很能说明问题：所谓智能，很多时候并不在手上这台设备里，而在几百公里外某个机房的机架上。端侧AI想做的，是把这段距离取消掉。
听起来像一句口号。真把它落到设备上，问题就具体起来了——功耗、内存、散热、模型怎么更新、出了问题谁负责。这些琐碎的事，决定了体验是“能用”还是“只是演示过”。
先算一笔电费
云端推理时，算力不够就加机器；端侧不行。一台设备的电池容量摆在那儿，散热也摆在那儿。模型每多跑一次，都要从电量里扣。于是量化和剪枝成了常规操作：把参数从高精度压到低精度，砍掉对结果影响小的部分，用一点点精度换可观的能耗下降。
这中间没有免费的午餐。压缩到某个程度，识别会开始出错，而错误往往出现在口音重、光线暗、背景吵这些真实场景里——恰恰是最需要它可靠的时候。所以工程上的常见做法不是“一个模型打天下”，而是分级：轻量的常驻，负责唤醒和初筛；复杂些的按需加载，用完就退。用户感知不到这两层，但电量条能感知到。
模型变小之后的新麻烦
设备上的模型是“冻”在固件里的。云端可以随时换版本，端侧要考虑怎么把新模型推到数量庞大的设备上，还要考虑推坏了怎么办。灰度、回滚、版本兼容，这些词原来属于后端工程师，现在得挪到硬件团队的白板上。
还有一个容易被忽略的点：隐私优势经常被说成端侧AI的天然好处，但“数据不出设备”只是把风险换了个位置。设备丢失、本地存储被读、模型本身被逆向，都是新的问题。把计算搬到本地，不等于把安全也搬过去了。
不是所有事都该搬到设备上
有些任务确实适合本地：延迟敏感的唤醒词、相机里的实时降噪、输入法的联想、车载的语音指令。这些场景的共同点是——等一次网络往返，体验就断了。
反过来，需要大知识库、需要频繁更新、需要长上下文推理的任务，放在设备上并不划算。硬塞进去的后果，通常是设备发烫、风扇狂转，用户关掉功能，然后这个功能再也没被打开过。判断标准其实很朴素：这件事对延迟有多敏感，对离线有多依赖，出错代价有多大。三个问题问完，答案往往自己就出来了。
我倾向于把端侧AI看成一次基础设施的下沉，而不是一个卖点。它不会在某一天突然改变什么，而是慢慢渗透——某个功能悄悄不再需要网络，某个响应快了半拍，某次断网时你发现它还在工作。这些变化单看都不起眼。
真正的难点也许不在模型，而在耐心：能不能接受第一版不够聪明，能不能把更新通道修好，能不能在演示和日常之间选择后者。毕竟用户不关心推理发生在哪里，他们只关心按下之后，有没有立刻回应。