电梯里没有信号，手机上的录音转写却还在一个字一个字往外蹦。放在几年前，这类功能几乎默认要联网，网络一断，进度条就停在那里。现在，一部分判断被留在了设备本地，用户感知到的不是“模型有多大”，而是“它有没有立刻响应”。端侧AI被反复提起，原因大概就在这里。
先问一句：为什么非要在本地做
语音唤醒、相机降噪、输入法联想、相册里的本地搜索，这些任务有一个共同点：等不起。请求发到云端再回来，哪怕只多出几百毫秒，交互也会显得迟钝；网络抖动时，体验干脆断掉。把推理放在设备上，延迟变得可预期，离线也能用。
隐私是另一层考虑。照片、录音、聊天记录这类数据，用户未必愿意每次都被上传。本地处理减少传输环节，也减轻了厂商的服务器压力。但这不是免费午餐：设备要承担算力开销，软件要适配不同硬件，体验边界也随之出现。
算力账本不只在芯片上
谈端侧AI，容易盯着处理器参数。实际约束往往在内存带宽、功耗和散热上。模型量化、剪枝、蒸馏这些工程手段，目的都是让模型在有限资源里跑得动，但压缩会带来精度损失，任务和模型需要匹配。人脸解锁和文档摘要对能力的要求并不一样，不能拿一套方案到处套。
更麻烦的是碎片化。不同芯片、不同系统版本、不同内存规格，意味着同一个功能要在多种设备上分别验证。模型更新也不像云端那样随时替换，端侧要推包、灰度、回滚，还要考虑旧设备能不能承受。很多演示看起来流畅，真正上线后卡在功耗预算和异常降级上。端侧AI的难点，经常不在模型本身，而在这些不显眼的工程环节。
它更像一种分工，而不是搬家
把端侧AI理解成“把云端模型搬到设备上”，容易走偏。复杂生成、跨设备知识整理仍然适合放在云端；实时响应、隐私敏感、轻量判断则适合留在本地。混合推理是更现实的路径：设备先做一层过滤和预处理，必要时再请求云端。用户不关心计算发生在哪里，只关心功能是否稳定、是否耗电、断网时还能不能用。
因此，判断一个功能要不要端侧化，可以回到几个具体问题：断网时它是否必须可用？数据是否敏感？延迟是否关键？如果答案是否定的，放在云端往往省事。反过来，如果体验依赖即时反馈，本地推理就值得投入，但前提是接受它的资源约束和运维成本。
端侧AI真正改变的不是参数规模，而是产品对“网络一定在”的假设。这个假设一旦松动，功能设计、功耗策略和隐私边界都要跟着重写。它不会替代云端，但会让设备在断网时少一点手足无措。