一次产品评审上，原型机里的语音助手响应很快，断网也能用，会议室里的人都点头。散会后有人把样机揣进口袋，十分钟后掏出来，机身温热，唤醒开始变慢。这类场景在硬件团队里不算新鲜，它说明的问题也很朴素：端侧AI 在演示环境里跑通，和在用户手里跑稳，是两件不同的事。
算力表上看不见的那部分
芯片参数里通常只写算力，但真正决定体验的往往是内存带宽和功耗预算。模型权重在内存与计算单元之间搬运一次，消耗的能量常常超过一次乘加运算本身。于是量化、算子融合、按层调度这些手段被反复使用，目的不是让跑分更好看，而是让设备在电池和散热的允许范围内把活干完。
内存也是硬约束。端侧设备的运行内存要和系统、相机、通信模块共享，模型常驻会挤压其他功能。工程上常见的折中是分段加载，代价是首帧延迟变长，用户感受到的是「点了之后要等一下」。
断网可用，也意味着更新变难
把数据留在本地是端侧AI 最实在的理由之一，但它同时带来一个反向问题：模型怎么更新。云端可以按周迭代，端上却要过应用商店审核、固件升级、用户是否愿意点「更新」这几道关，节奏被拉长到以月计。版本落差会直接体现在体验一致性上——同一款产品，老用户和新用户看到的可能是两种表现。
碎片化落在具体设备上
- 不同芯片对算子的支持不一致，某些层只能回落到通用处理器执行
- 内存带宽差异让同一套量化方案在不同机型上的速度差出一截
- 系统对后台进程的限制，决定模型能否常驻、多久会被回收
所以这个方向的工程重点，常常不是训练一个更强的模型，而是让同一个模型在几十种设备上都不出岔子。这部分工作量很少被写进宣传材料，却占了团队大部分时间。
哪些事该留在端上
判断标准其实不复杂：延迟敏感、隐私敏感、需要离线可用，三者占其一，才值得把模型搬到本地。语音唤醒、实时字幕、相机降噪属于第一类；本地相册检索、人脸解锁属于第二类。而依赖大知识库、长上下文推理的任务，放在端上既吃力，收益也有限。混合方案更常见——端上做唤醒和粗筛，复杂请求交给云端，用户感知到的是「快」，工程上的现实是分工。
一点判断
端侧AI 接下来能走多远，短期恐怕不由某个参数指标决定，而由内存、散热、功耗这些老问题决定。厂商愿意给神经网络加速单元留多少芯片面积和电量，压缩工具链能否稳定覆盖主流芯片，升级通道是否顺畅——这些不上台面的细节，决定了用户手里那台设备是「能用」还是「好用」。
演示和日常之间的距离，往往就藏在这些地方。