移动端模型性能水土不服？真实场景压力测试揭秘

　　去年一月，凌晨三点十七分，我盯着测试机屏幕里那个卡在“加载中…”的圆圈——第八次重试，iOS端模型推理耗时从标称的一百二十毫秒跳到两千三百毫秒，Android那边倒还稳着，二百零六毫秒。我原以为是热更新脚本没清缓存，结果把整套离线包全删了重装，它还是卡在第三帧输出上。

　　王工蹲在我工位边啃包子，油纸袋摊在键盘上，说：“你别动了，我刚连adb看日志——它在等一个GPU fence信号，可Metal驱动根本没发。”我抬头看了他一眼，他嘴边沾着芝麻，左手无名指指甲盖裂了一道缝，是我上周开会时注意到的。他说话时包子馅掉进USB-C口，我也没掏。

文章配图，仅供参考

　　后台监控里那条绿色的CPU占用曲线，平得像被尺子压过，但内存里堆着二十三个未释放的TensorBuffer实例——这事跟GPU没关系，跟Metal没关系，跟我们写的任何一行kernel code都没关系。它卡在系统级的TextureCache预热环节，而这个环节在iOS 16.2以后，只在前台活跃超四秒才触发。我们那个“快速启动”按钮，点击后三秒就切到了模型页，刚好差一秒。

　　（隔壁工位老张突然推门进来问WiFi密码，我说“three—seven—dash—nine”，他点点头走了，我忘了问他要干嘛）

　　所以后来我们把启动延迟硬加了一千二百毫秒，用户点下去得等一拍半再动——页面居然顺了。不是模型快了，是系统终于肯给纹理分配资源了。这不叫优化，这叫蹲点卡位。厂商文档里压根没提这个阈值，连“TextureCache”四个字母都没出现过一次。我翻了七版Xcode Release Notes，只有第十六页脚注里写了一句：“texture residency behavior may vary”。反正，就是这么个事。

　　那台测iPhone 13 Pro真机屏幕右下角有道细划痕，是去年十一月跌过一次留下的，每次模型卡住时，划痕反光会跳一下。安卓机没这道痕，也没这问题。客服小林昨天在钉钉回我：“亲，这个属于系统级兼容现象呢～”，她用了波浪号。我截图发群里，没人接话。她不知道那晚我抓着Logcat和Instruments来回切了四十一次，手指头僵了，但划痕反光跳得更勤。

　　我原以为是模型量化出了岔子，结果发现是苹果把预热逻辑悄悄塞进了UIApplicationStateActive的判定里；我以为要改模型结构，结果只加了段sleep；我以为得等厂商修复，结果他们连这事都懒得记进Bug Report。优胜劣汰？对。淘汰的不是模型，是那些相信文档比实机更靠谱的人。

　　有谁碰到过这个吗

（编辑：航空爱好网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!