晚上回家，门口摄像头亮起，屏幕上弹出一句提示：有人停留。这个动作看似简单，背后可能有两种路径：把画面传回云端识别，或在设备本地完成一次推理。端侧AI讨论的，正是后一种路径——让模型在离数据产生位置近的硬件上做判断。
先问模型能不能住下
云端有弹性算力和集中运维，长上下文理解、复杂生成这类任务常放在那里。端侧AI不是把云端模型原样塞进小盒子。模型压缩、量化、剪枝，甚至为单一任务重做小模型，都是常见做法。参数少了，内存占用和功耗压力会下降，泛化能力也可能收窄。工程团队要在识别率、延迟、发热和成本之间做取舍。与其说这是一次模型移植，不如说是重新设计产品。
电量、散热和更新，都是日常账
摄像头、路由器、耳机、门锁，这些设备的工作环境并不理想。它们可能长期插电，也可能靠电池；可能放在通风处，也可能塞进墙角。这类功能落地时，场景往往先被拆小：唤醒词、简单图像检测、本地语音指令、异常声音判断。任务短、频率高、数据敏感，是常见的切入口。
- 电量与散热：常驻模型会带来待机功耗，推理峰值又会推高温度，产品形态因此受限。
- 内存与存储：模型、运行时和缓存都要占空间，留给系统更新的余量并不宽裕。
- 更新与维护：端侧模型分散在设备上，版本验证、回滚和故障定位都琐碎。
数据留在本地，风险不会自动消失
本地推理能减少数据外传，也让一些判断不必等待网络往返。但设备丢失、固件漏洞、模型被提取，仍是现实问题。它需要把安全当成产品的一部分，而不是一句隐私口号。哪些数据只留在设备、哪些摘要可以上传、日志保留多久，都应在设计阶段写清楚。
边界处，混合架构常被采用
端侧AI适合高频、短时、对本地数据敏感的任务；复杂生成、长上下文理解仍常依赖云端。混合架构因此常见：设备先做初筛，云端再做补充。对产品团队来说，先问几个朴素问题：用户是否愿意为本地判断等待，设备热预算够不够，模型更新如何验证，失败时怎样退回可用状态。
回到门口那声提示。用户不关心计算发生在哪，只关心它是否可靠、是否打扰、是否守住数据。端侧AI的慢热，可能就藏在这些不显眼的日常里。