地铁里信号只剩一格，对着手机说一句话，屏幕上转了两秒圈才出结果。这两秒里，语音先被压缩上传，等服务器返回，再被播放出来。端侧AI想砍掉的，正是这段往返。
但把模型搬进设备，并不等于问题解决。它换了一组约束条件。
动机不全是隐私
谈到本地推理，常见的说法是隐私和延迟。实际推动它的，还有更朴素的一笔账：持续的云端调用要付带宽和算力费用，用户量一大，这笔开销就难以忽略。再加上弱网、断网、跨地区服务不稳定的场景，本地兜底成了一种工程上的必需，而不是宣传点。
隐私确实成立，但要说得更准确些：数据不出设备，减少的是传输环节的暴露面，不是所有风险。本地存储、日志、权限仍然要管。
压缩之后剩下什么
设备的内存、功耗、散热都有限，模型通常要经过量化、剪枝、蒸馏这类处理。它们有效，但不是无损的。量化把权重从高精度压到低精度，省下空间和带宽，代价常出现在对细节敏感的任务上——长文本里的细微语气、含糊指令的理解、少见词的识别。这些退化在演示里看不出来，在真实使用中会以“怎么又听不懂了”的形式冒出来。
所以端侧AI的选型逻辑和云端不同：先问这个任务能不能容忍退化，再问模型有多大。一个能稳定完成窄任务的模型往往就够了，硬塞一个通才模型进去，收益不一定抵得上代价。
瓶颈常在内存带宽
讨论端侧性能时容易盯着算力数字，但不少实际部署里，卡住速度的是内存带宽——权重每次推理都要从内存搬到计算单元，搬得慢，算得再快也得等。这也解释了为什么模型小一点、访问模式规整一点，体验反而稳定。
功耗是另一条暗线。持续推理会让设备发热，热量一上来，频率就降。用户感受到的不是参数，而是手机变烫、掉电变快。
该留在本地的任务
把功能全放到本地既不现实也没必要。比较务实的划分依据有这么几条：调用频次高、单次输入短、对响应时间敏感、离线也要能用、数据敏感度高。语音唤醒、输入法联想、照片里的文字识别、通话降噪，都属于这类；需要长上下文、复杂推理、依赖大知识库的请求，交给云端更省事。
麻烦在于这条界线会移动。同一个功能，今天在云端，明年可能下放到本地；用户不会关心它在哪里运行，只会在意它有没有掉链子。
被忽略的运维问题
模型一旦分发到设备上，更新就成了难题。设备型号、系统版本、可用存储各不相同，同一份模型在不同机器上的表现会有差异。云端可以灰度、可以回滚，端侧要面对的是碎片化的现实。
评测也跟着变难。实验室里的结果和用户手里的体验之间，隔着发热、电量、网络和后台进程。要判断一次更新是否真的有用，往往得靠设备上的埋点和长期观察，而不是一次离线测试。
回到地铁那一幕。端侧AI真正要交付的，不是“设备上也有一个大模型”这件事，而是那两秒变成半秒，并且在没信号的时候依然答得上来。它是一场关于约束的工程，而不是一次模型发布。