地铁进隧道，手机信号掉到一格，语音助手转了两圈，弹出一句“网络连接失败”。这个瞬间大概最能让人理解，为什么有人坚持要在设备本地跑模型。
从“等云端回话”到“当场给结果”
端侧AI字面上说的是把推理放在手机、PC、车机、摄像头、耳机这些设备上完成，而不是把数据打包发到机房再等回来。听起来只是部署位置换了，实际牵动的东西更多：芯片要留出算力，内存要留出带宽，系统要留出调度空间，模型本身还得改一改才塞得进去。
推动力并不神秘。有些场景等不起一个来回的网络延迟，比如实时翻译、手势识别；有些数据不适合离开设备，比如相册里的人脸、家里摄像头拍到的画面；还有些设备干脆长期没有稳定网络，现场检测的终端就是这样。这些需求叠在一起，端侧AI就从“能不能做”变成了“值不值得做”。
卡住的往往不是参数量
讨论端侧模型时，人们最爱问多少亿参数。这个数字好记，但对体验的解释力有限。设备跑模型时，真正吃紧的是内存带宽和功耗预算。权重每被读一次都要走一遍内存，带宽不够，算力再高也只能干等；功耗和散热有限，短时间跑分好看，连续跑十几分钟就开始降频。
所以工程上常见的选择是量化和剪枝：把权重压到更低位宽，砍掉不重要的连接。代价是精度会掉，而且掉在哪里不好预测——通用测试集上几乎无损的模型，可能在某个具体任务上突然出错。这也是部署里最需要耐心的一段工作，压缩、试跑、找坏例、再调，如此往复。
设备卖出十万台之后
单机跑通一个演示，和十万台设备上稳定运行，是两件事。设备型号杂、芯片代际不同、系统版本参差，同一个模型要适配的分支比想象中多。模型更新也是麻烦事：云端改一版就生效，端上要考虑包体大小、下载时机、回滚方案，还要确认旧设备能否承担新模型。
评测同样棘手。云端可以集中采样、对比日志，端上的数据散在各处，隐私又不允许随便上传。于是团队常常只能依赖少量本地埋点和小规模用户反馈来判断效果，在这种信息密度下做调优，靠的是经验，不是报表。
它该待在哪里
一个比较务实的判断是：端侧AI更适合承担“必须立刻发生”和“数据不宜外流”的那部分工作，唤醒词检测、输入法联想、照片分拣、离线字幕都属于这一类。需要广博知识、复杂推理、长上下文的任务，放在云端更合适，设备没必要硬扛。
真正值得琢磨的是两者的接缝。什么情况下本地先给一个粗略结果，什么时候把问题交给云端，切换时用户要不要知道——这些设计决定体验，比模型参数更能说明一个产品有没有想清楚。端侧AI不必占满每一块阵地，它更像一片需要划清边界的场地。