地铁隧道里没有信号，语音助手仍能听懂“下一站提醒我”并完成设置；会议室网络拥塞，录音转写没有把音频上传，而是在本机生成摘要。这些场景让人看到端侧AI的吸引力：响应更直接，数据少离开设备，离线也能工作。但真正把它做成稳定功能，难点并不在演示，而在日复一日的资源约束。
把模型放进设备，先要面对体积与能耗。模型参数、内存占用、发热和续航彼此牵制，产品团队常要在识别精度、响应速度和电量之间取舍。量化、剪枝、蒸馏等压缩手段能减小模型，却可能改变输出风格和边界表现；同一套压缩策略，在不同设备上未必有相同结果。设备上的芯片能力差异很大，功能若只面向少数新机型，覆盖面就会受限。
不是云端搬家的游戏
端侧AI常被描述为“把云端能力搬到本地”，这说法省事，却容易误导。云端可以集中调度算力，按请求扩容；设备则要同时服务拍照、通信、显示等任务，模型只能分到有限预算。更现实的做法是混合推理：简单、时延敏感、涉及隐私的步骤放在本地，复杂生成或需要外部知识的环节交给云端。任务怎么切，取决于场景，而不是一句技术口号。
更新维护也是容易被低估的部分。设备型号多、系统版本杂，模型下发、回滚和兼容性验证都需要工程投入。模型在实验室表现正常，到了真实环境，可能遇到口音、噪声、弱光或异常输入。若缺少本地日志与可解释的失败反馈，问题很难复现。对用户而言，功能是否可用是底线；对企业而言，长期维护一套可用的端侧AI，投入往往被低估。
边界感决定可用性
端侧AI适合什么？大致是那些对时延敏感、数据不宜外传、网络条件不稳定，且任务边界相对清晰的功能，例如离线转写、设备内图像整理、简单指令理解。它不适合被无限承诺：需要大量外部知识、复杂推理或持续学习的能力，仍要依赖云端协作。把不适合的任务硬塞进设备，用户感受到的不是技术进步，而是发热、卡顿和功能缩水。
我更愿意把端侧AI看作产品设计的一次重新分工。它逼着团队回答：哪些数据必须留在本地，哪些计算可以延后，哪些体验值得占用电量。回答清楚，功能才会自然；回答含糊，模型再小也像一块塞错位置的积木。