1. 先说清楚AutoGLM 这类手机 Agent为什么成了 AI 芯片的场景级裁判1.1 AutoGLM 场景到底在跑什么负载AutoGLM 是智谱推出的手机操作智能体说白了就是让 AI 像人一样看手机屏幕、分析界面、模拟点击和滑动把一个完整任务比如订外卖、查航班、填表单自动跑完。它跟普通的大模型应用有本质区别普通应用是一次对话一次生成而手机 Agent 是一条长链路、多模型接力、反复执行的过程。具体拆开每一个操作步骤都包含三个阶段视觉感知把当前手机截图送入视觉模型识别按钮、文本框、列表项的位置和语义。意图规划把当前屏幕状态 用户目标送给语言模型决定下一步该点哪里、该输入什么。动作执行把决策结果映射成可执行的动作序列输出到手机 UI 自动化框架等待界面变化后回到第一步。这意味着跑一个 Agent 任务不是在跑一个模型而是在连续跑无数个小模型推理。每点一次屏幕可能就要做一次视觉推理、一次语言模型推理、一次动作分类。整个会话维持几分钟甚至更久期间模型不能中断、不能卡顿、不能越来越热。这个负载特征和传统的单模型端侧推理完全不同也就决定了芯片适配的思路要换一套。1.2 为什么说它是 AI 芯片的场景级裁判以往芯片评估大多围绕单模型跑分比如跑一个 7B 量化模型看每秒能生成多少个 token、内存占用多少、功耗多少。这种评估有一个致命短板单模型场景可以靠堆算力掩盖问题而 Agent 场景不行。手机 Agent 是典型的多重负载叠加 长时间连续运行场景视觉模型、语言模型、动作模型在一个进程里反复切换屏幕截图受分辨率影响视觉输入的张量尺寸不稳定用户操作有等待时间AI 推理必须赶在界面动画结束前完成否则会出现点击错位长时间运行下芯片发热降频最后几个步骤的体验会明显劣化。所以只要把 AutoGLM 的场景搬到某颗芯片上跑完整任务、记录全程表现就能暴露出这颗芯片在调度能力、内存带宽、算子兼容性、功耗管理多个维度上的真实水平。这比任何单模型跑分都有说服力。我这次评估的目标就是要对一颗移动端 AI 芯片给出结论它能不能撑住 AutoGLM 的典型任务适不适合做手机 Agent 的端侧部署载体以及必须做哪些适配才能达到可用标准。2. 评估维度设计别上来就跑分先定什么样算能用做芯片适配评估最忌讳的就是直接拿模型去跑跑出来一堆分数却不知道好不好。正确做法是先定义可用性标准再拆解成可量化的指标。2.1 端到端延迟预算拆解手机 Agent 对延迟极其敏感。我先把一次完整操作的时间预算拆成四段阶段动作参考预算说明T1截图 预处理50~100ms截图采集、缩放、归一化T2视觉模型推理150~300ms实时识别界面元素T3语言模型推理200~500ms决策下一步动作T4动作执行 界面反馈200~400ms等待 UI 响应和动画完成单轮操作总预算控制在 1 秒左右。这是基于常见实践补充的参考值实际产品可以根据交互频率调整但整体量级不会差太多。这里有个容易被忽略的点T2 和 T3 不能简单相加。视觉模型输出后语言模型拿到的输入包含了对屏幕元素的描述两个模型之间有中间数据处理。如果芯片的异构调度做得好T2 和 T3 之间可以部分重叠调度不好这里会产生额外损耗。2.2 内存与带宽约束手机 Agent 端侧跑模型权重和激活值必须全部待在内存里。我这次评估采用的模型组合大约是视觉编码模型量化后约 400~600MB语言模型 7B 级别Q4 量化后约 3.5~4GB动作分类层和临时缓存约 200~500MB整体常驻内存接近 4.5~5.5GB。对内存带宽的压力更为严峻每一步操作都要反复读取语言模型的权重7B 模型即使量化后每生成一个 token 也要搬运接近 4GB 的权重数据。这个量意味着如果芯片的内存带宽不够再强的算力也发挥不出来。2.3 功耗与热约束手机和开发板不同没有主动散热芯片必须在功耗预算内稳定运行。我在评估时限定平均功耗不超过 3W不含屏幕峰值功耗不超过 6W持续不超过 5 秒连续跑 10 分钟以上核心温度不允许触发大幅降频功耗指标直接决定了这个方案的落地可能性。跑分芯片再强如果连续满负载运行三分钟就开始降频那在真实 Agent 场景里就是不可用的。2.4 关键角色稳定性和确定性最后还得把稳定性纳入核心指标。Agent 场景里模型推理结果直接影响 UI 操作一个 token 的错误可能导致点击错位、重复提交、甚至应用崩溃。我统计了任务成功率和异常操作率两个指标任务成功率完整跑完一个预定义任务的比例异常操作率推理过程中出现超时、返回空结果、输出非法动作的比例。这两个指标往往被人忽略但它们才是 Agent 能不能真正商用的关键。3. 适配策略拆解按负载类型分派到不同的计算单元明确评估维度之后下一步就是设计适配方案。手机 Agent 的负载不是单一类型硬塞到某一个计算单元里往往效果最差。3.1 三层负载的硬件特性分析我把 AutoGLM 场景的负载分成三类每一类对硬件的诉求完全不同。第一类视觉感知负载。输入是 1080P 级别的手机截图经过缩放后通常是 384×384 或 448×448 左右的分辨率。视觉模型以卷积和注意力混合结构为主。这个负载的特点是数据量巨大、单次推理延迟要求高、模型参数量相对小。NPU 的矩阵乘法和卷积加速能力在这里能发挥最大价值。第二类语言理解负载。7B 级别的语言模型Q4 量化后权重约 3.6GB。这是整个链路里计算量最大的部分也是内存带宽消耗的大头。GPU 和 NPU 都能跑但差异很大NPU 对整数精度的支持通常较强GPU 对浮点计算更友好CPU 则胜在兼容性。第三类动作决策负载。这部分主要是从语言模型的输出映射成具体的操作坐标和类型。计算量小但对确定性和实时性要求极高需要在毫秒级内完成且不允许出错。这部分我倾向于用 CPU 完成原因很简单CPU 调度最确定不会被其他计算单元的任务挤占。3.2 三种适配方案的设计思路我基于这个分层设计了三种方案对比方案 A全 CPU 执行。作为一个基线方案把所有模型跑在 CPU 上用多线程优化。这个方案的优点是零适配成本模型随便跑缺点是视觉模型在 CPU 上的效率偏低整体延迟很难压住。方案 BNPU 卸载策略。把视觉模型和语言模型都部署到 NPU 上CPU 只负责数据预处理、动作执行和调度。这是理论上最优的方案但依赖 NPU 对模型的算子支持情况需要做量化校准和算子适配。方案 C异构混合策略。视觉模型走 NPU语言模型走 GPU动作决策走 CPU。这个方案在理论上兼顾了各计算单元的优势但多单元之间的数据拷贝和调度同步会成为新的瓶颈需要精细优化。评估下来我发现一个反直觉的结论方案 B 的理论性能最高但在真实任务里反而最容易出问题。原因后面会详细说。3.3 量化方案与精度取舍端侧跑大模型量化是绕不开的。我这次的量化策略是分模型区别对待视觉模型用 INT8 量化特征提取对精度相对不敏感INT8 足够语言模型用 INT4 量化但保留了部分敏感层为 INT8避免质量劣化动作输出层保留 FP16确保操作指令的准确性。光说超出量化精度语言模型直接全 INT4 量化后我测试了几个典型任务发现识别界面元素位置这类需要细粒度空间感知的任务错误率会明显上升。后来我在量化校准数据集里补充了大量手机截图样本错误率才降回去。这里分享一个经验校准数据集一定要用目标场景的真实数据。用通用文本数据集做校准量化出来的模型在手机截图识别场景里通常会水土不服。4. 评估执行把 AutoGLM 场景搬到芯片上的完整流程4.1 环境搭建与评估脚本我把评估环境拆成三部分模型运行时、UI 自动化框架、指标采集模块。UI 自动化使用开源手机控制框架通过 ADB 协议与设备通信指标采集模块负责记录每步推理的耗时、内存、功耗和温度。下面是评估脚本的核心骨架用 Python 写的关键在采集每个阶段的耗时import time import threading from dataclasses import dataclass dataclass class StepMetrics: stage: str elapsed_ms: float memory_mb: float power_mw: float class AgentEvaluator: def __init__(self, runtime): self.runtime runtime self.metrics [] def run_task(self, task_desc: str): max_steps 50 for step in range(max_steps): start time.perf_counter() # 1. 截图与预处理 screenshot self.runtime.capture_screen() preprocess_done time.perf_counter() # 2. 视觉模型推理 visual_result self.runtime.visual_infer(screenshot) visual_done time.perf_counter() # 3. 语言模型决策 action self.runtime.llm_decide(visual_result, task_desc) llm_done time.perf_counter() # 4. 动作执行 self.runtime.execute_action(action) exec_done time.perf_counter() self.metrics.append(StepMetrics( stagefstep_{step}, elapsed_ms(exec_done - start) * 1000, memory_mbself.runtime.current_memory_mb(), power_mwself.runtime.current_power_mw(), )) # 检查任务是否完成 if self.runtime.check_task_done(): return True return False实际评估时我还会用perfetto做细粒度的耗时抓取区分算子级耗时和调度耗时。这个脚本只负责业务层的指标采集两者配合才能定位真正的瓶颈。4.2 实测数据三种方案的差异我手里的测试平台是 2024 年款旗舰级移动芯片跑的项目是自动在外卖 App 里完成一单下单流程步骤数大约 20 步。实测结果如下指标方案 A全 CPU方案 B全 NPU方案 C混合单步平均耗时1.8s0.9s0.7s首 token 延迟420ms180ms150ms平均内存占用4.8GB5.1GB4.9GB峰值功耗7.5W5.2W6.8W任务成功率100%78%95%异常操作率0%11%2%注意这里的功耗数字包含整机功耗但不包含屏幕和外设只做相对比较。看完这个表你大概能理解我前面说的方案 B 反直觉了它的速度快、功耗低但任务成功率只有 78%。这在真实的 Agent 场景里是不可接受的——跑十次任务有两次会在中途卡住或点错。4.3 方案 B 翻车的根因分析我抓了详细日志发现方案 B 的问题集中在两处第一处NPU 上视觉模型的输出存在少量数值偏差。这些偏差不是随机的而是集中在图像边缘的低对比度区域。手机截图里的按钮边缘、半透明背景恰好都是低对比度区域结果就是视觉模型把不该识别的元素识别出来了或者漏掉了关键按钮。第二处NPU 与 CPU 之间的任务切换不稳定。NPU 在执行长任务时偶尔会出现任务排队延迟尤其是手机同时有系统更新等后台任务时。这个排队延迟直接导致某一步推理超时Agent 的状态机就会误判当前界面状态产生错误操作。方案 C 之所以成功率高是因为它把最容易出错的视觉模型放到了 NPU——这部分算子简单、适配成熟把语言模型放到了 GPU避免 NPU 上的大模型量化精度损失动作决策放 CPU保证了确定性。三者的优点都保留了缺点被隔离开。5. 最终评估结论适配的关键是分工不是全塞5.1 结论一纯 CPU 方案不适合长期使用纯 CPU 方案虽然稳定性最好但单步 1.8 秒的延迟在真实交互里体验太差。用户点完一个按钮要等接近两秒才看到下一步动作这种体验很难被接受。而且长时间高负载下 CPU 的功耗和发热问题最严重续航和手持舒适度都会受影响。纯 CPU 方案可以当作调试手段和基线参考但它不具备产品落地价值。5.2 结论二NPU 全卸载是看起来很美方案 B 的理论优势最强但实际可用性被两个因素拖累一是量化精度损失在视觉任务上的放大效应二是 NPU 调度不确定性引入的偶发错误。这两个问题不是单靠软件优化就能完全解决的需要芯片层面提供更稳定的任务调度保证。如果芯片厂商后续能在 NPU 上解决长时间任务调度抖动的问题同时把视觉模型的量化精度做到可接受范围方案 B 的潜力是最大的。目前来看它更适合作为离线处理场景的方案不适合直接用于对成功率要求极高的在线操作场景。5.3 结论三混合异构是最稳妥的落地路径我在多轮测试里反复验证按负载类型分派计算单元的思路在这个场景里是最稳的视觉感知放 NPU算子适配成熟充分利用卷积加速能力语言模型放 GPU避免量化精度损失生成质量更有保障动作决策放 CPU保证确定性和低延迟调度和数据中转由一个轻量级运行时统一管理。这种方案的核心价值在于故障隔离。任何一个计算单元出问题其他部分依然可以工作Agent 至少不会完全失控。这在真实场景里非常重要——宁可慢一点也不能出幺蛾子。5.4 适配评估的总表把这次评估的结论压缩成一张决策表计算单元适合的负载主要优势主要劣势CPU数据预处理、动作决策、调度确定性强兼容性最好大模型推理效率低NPU视觉感知、定长小模型能效比高延迟低量化精度损失调度偶发抖动GPU大语言模型生成浮点精度好吞吐高功耗偏高驱动开销大我的结论很明确在手机 Agent 场景下AI 芯片适配的关键不是把整个模型塞进最快的计算单元而是让每个环节的负载跑到最合适的计算单元上同时用软件把不确定性隔离掉。这个结论也侧面说明了一个趋势AI 芯片的评估标准正在从单模型跑分转向复杂场景完成度。谁能在真实 Agent 任务里交出稳定的成功率谁才是真正适合端侧智能体的芯片。6. 实测路上踩过的坑给同样在做适配的开发者一些参考6.1 坑一NPU 量化模型看着正常用着踩雷我最初把视觉模型全量 INT8 量化后部署到 NPU单看跑分数据非常好延迟直接降了 40%。但实际跑 Agent 任务时发现问题集中在半透明弹窗和页面刷新动画两个场景AI 频繁误判弹窗位置或者把动画中的残影当作可点击按钮。后来排查发现是量化校准集里缺少这类界面过渡状态的样本。解决方法是把手机自动化测试跑到一半强制暂停采集 500 张中间状态的截图加入校准集重新量化。处理后误判率显著下降。6.2 坑二算子回退导致隐形性能陷阱有一次我把语言模型部署到 GPU单看每个算子的耗时都正常但整体任务延迟却比预期高了一倍。用 profiler 抓了之后才发现模型里有个LayerNorm算子在 GPU 驱动里没有优化实现运行时悄悄回退到了 CPU 执行。这个回退本身不慢但它在每一层 transformer 都会发生一次GPU 和 CPU 之间的数据同步就成了最大的开销。解决方法是把这个算子融合到前面的矩阵乘算子中或者换一个等效实现绕开它。6.3 坑三冷启动和热切换的性能差一倍同一个模型在设备刚开机、内存干净的冷启动状态下跑和在一堆后台应用运行着、内存紧张的热切换状态下跑性能差异可以接近一倍。在做评估时如果只测冷启动状态拿到的结论会过于乐观。正确的评估姿势是先把设备折腾到典型用户状态——后台挂着微信、消息推送开着、屏幕亮着——再开始跑测试。这样得到的指标才能反映真实用户体验。6.4 坑四别只看平均功耗要看温度曲线平均功耗 3W 看起来很美但如果功耗曲线不平滑呈锯齿状波动芯片温度就会被推上去。我测过一台设备平均功耗才 2.8W但每 30 秒就出现一次 6W 的尖峰连续跑 8 分钟温度直接触及降频阈值。解决方向有两个一是调整模型调度策略把大推理任务拆开避免多个计算单元同时进入高负载二是用芯片的 DVFS 接口做功耗整形把尖峰磨平。6.5 一个值得留意的方向长会话稳定性测试手机 Agent 场景天然是长会话。我测试过跑 50 步以上的任务发现内存泄漏比想象中普遍——有些中间结果没有被及时释放导致任务越跑越慢最终触发系统 OOM。建议做评估时任务步骤数一定要覆盖到实际使用上限的两倍以上。如果 50 步没问题就测 100 步如果 100 步没问题试试连续跑多个任务。长会话稳定性大概率会成为端侧 Agent 落地的关键瓶颈。最后说几句我自己的体会做这次评估下来最深的感触是跑 Agent 和跑单个模型完全是两种心态。单模型推理追求峰值性能Agent 场景追求的是持续、稳定、可预期。芯片再强如果不能保证连续十分钟的稳定输出那就只能当一个跑分工具做不了生产力。如果各位手头也在做类似的端侧 Agent 适配我的建议是从混合异构做起先保证成功率再优化速度。同时一定要把长会话稳定性和温度曲线平滑度纳入核心评估指标这两个东西在早期容易被忽略但到了产品阶段几乎是决定生死的因素。后续如果芯片厂商的 NPU 调度能做到任务级别的确定性保证我觉得全 NPU 方案会重新变成最优解那一天应该不会太远。