这两年做边缘AI的同行聚在一起话题绕不开两个词TOPS和智能体。前两年大家还在比谁的开发板跑分高、谁的NPU算力强今年画风突然变了——Arm把“为智能体而生”写进了自己的技术叙事里行业里也开始流传“2026年是工业智能体工程化落地分水岭”的说法。边缘AI的衡量标准正在从“每秒多少万亿次运算”转向“能不能把一个智能体完整地跑在设备端”。这篇文章想聊聊我看到的这次转向TOPS为什么不再是终点Arm到底在押注什么以及作为开发者选型思路和调试手段该怎么跟着变。1. TOPS军备竞赛停下来了但算力焦虑还没结束1.1 先搞清楚TOPS到底在衡量什么TOPS是Tera Operations Per Second的缩写每秒万亿次运算。这个指标本身没有问题问题出在它被当成“AI性能”的代名词摆上了发布会PPT。你去看各家芯片的规格页同样一颗芯片用INT8精度算一个数字用INT4算一个数字再用稀疏化算一个更大的数字同一个型号可以报出三个完全不同的TOPS。商用场景里最常引用的是INT8稠密算力但很多消费级产品对外宣传时倾向挑好看的那个口径这导致数字之间的横向对比没有太大意义。严格来说TOPS衡量的是“计算单元在单位时间内最多能做多少次运算”它描述的是峰值能力不是实际效果。就像一台发动机的铭牌马力和它装到车上后真实跑出来的百公里加速是两回事。变速箱、轮胎、风阻、路面每一个环节都能让最终成绩和铭牌数字拉开差距。边缘AI芯片同理NPU的MAC阵列、缓存容量、内存带宽、总线拓扑、软件栈成熟度这些因素都会决定实际推理表现。只看TOPS就像只看发动机马力就下单买车大概率会踩坑。这两年行业里对TOPS的迷信其实已经开始松动。一个直接原因是大模型带来的工作负载和传统CNN完全不同。以前跑个图像分类、目标检测计算密集度高TOPS高确实占优势现在跑LLM、跑智能体推理过程变成访存密集型的自回归生成内存带宽的重要性迅速压过峰值算力。你会发现很多芯片厂商开始强调“端侧能跑多少token每秒”“首token延迟多少”而不是继续堆TOPS数字——因为用户已经学聪明了他们更关心模型跑起来快不快而不是宣传页上的极限值好看不好看。1.2 算一笔账为什么100 TOPS跑7B模型还是很吃力我做过一个很简单的估算可以帮助大家直观理解为什么TOPS不是万能钥匙。假设有一颗100 TOPS的端侧NPU要跑一个7B参数的LLM4-bit量化后权重大概是4GB。7B模型每生成一个token大约需要2×70亿次运算也就是140亿次运算。用100 TOPS的算力去算理论上每秒可以生成大约7000个token——这个速度非常吓人比云端都夸张。但别高兴太早。自回归生成每次都要把整个模型权重从内存里读一遍假设设备用LPDDR5-6400内存理论带宽51.2GB/s权重4GB那么每秒最多只能读出12.8轮权重换算过来就是每秒最多生成12.8个token。这还是理想状态真实场景里还要算上KV Cache读写、上下文拼接、系统进程占用带宽实际跑到8到10个token每秒就已经算不错了。算力能撑到7000 token/s带宽只喂得动10个token/s左右中间差了差不多500倍。这组数字说明一个核心道理在LLM和智能体场景里边缘推理是memory-bound的内存带宽和访存效率决定了实际性能NPU峰值算力只是天花板不是门把手。你花大价钱堆TOPS很可能根本用不满因为数据从内存到计算单元的运输通道早就堵死了。这也是我这两年选型时越来越关注内存子系统、缓存层级、NPU和CPU共享带宽的原因。1.3 从“峰值算力”到“有效算力利用率”既然TOPS被带宽卡住行业就开始聊“有效算力利用率”。这个概念说白了就是宣称的TOPS里实际能发挥出多少。我实测过几款不同价位的边缘设备跑LLM时NPU的利用率经常在10%到30%之间有些甚至是个位数。算力利用率这么低不是芯片不行而是工作负载的属性决定的——每个token的矩阵乘法虽然大但数据搬运成本太高计算单元大部分时间在等数据。衡量有效算力利用率常见做法是算“实际吞吐÷理论峰值”。比如设备实测能跑10 token/s7B Q4模型每token需要140亿次运算那实际算力就是1400亿次每秒除以100 TOPS利用率只有1.4%。极端到可以忽略不计。这不是说NPU没用了而是说在纯LLM场景下瓶颈压根不在算力。如果换一个图像分类任务同样的算力利用率可能能到60%以上。所以现在的边缘AI评估框架已经变了。ChatQA这类跑LLM的看token/s跑视觉基础模型的看不同输入分辨率下的FPS跑智能体这类复合工作负载的要看端到端延迟和并发稳定性。TOPS还会被提及但它已经从“核心卖点”降级成“基础规格参数”真正的竞技场转向了系统级性能。Arm在其中押注的方向也恰恰和这个转变吻合不再单纯强调算力而是强调智能体在端侧能不能活得下去。2. 智能体比大模型更吃资源边缘推理的五个真实开销2.1 上下文变长KV Cache开销暴涨传统的大模型推理一次只处理一条短文本输入几百个token输出几百个token内存压力有限。但智能体的工作方式不同它要读工具说明、回忆历史对话、理解用户背景还要把工具返回的结果拼回上下文里继续推理。上下文长度从几千涨到几万甚至几十万token时KV Cache的开销会大到让边缘设备直接投降。我来算一笔具体账LLaMA-2 7B这类模型每层每token的KV Cache大约16KB32层就是0.5MB。也就是说模型每多处理一个token的上下文就要额外占用0.5MB内存。8K上下文需要4GB32K上下文就要16GB。边缘设备总共才多大内存很多开发板16GB都未必有还要同时住模型权重和系统进程。KV Cache暴涨的直接后果是内存容量被快速吃光紧接着内存带宽被翻倍的Cache读写拖垮推理速度断崖式下跌。在智能体场景里这个问题会更明显因为智能体倾向于保留更多历史信息来做决策。长上下文既是智能体的“智商来源”也是端侧的“资源黑洞”。目前业界的应对思路是做KV Cache量化、滑窗压缩、上下文裁剪但我认为真正要解决的是让边缘推理框架从设计上就为长上下文预留资源而不是靠临时优化硬扛。2.2 工具调用把“单次推理”变成“多轮往返”智能体和普通聊天机器人最大的区别是它会用工具。查天气、调API、操作数据库、控制设备每走一步都涉及一次完整的“思考-行动-观察”循环也就是ReAct模式。第一轮模型读用户指令决定调用工具第二轮把工具返回的数据塞进上下文重新推理下一步动作第三轮再观察结果继续推演。一个稍微复杂的任务可能需要五轮、十轮甚至更多轮往返。每一轮往返都要重新处理截至当前的全部上下文。这就好比你跟一个人说话说一句他把你们之前聊过的所有内容从头到尾重读一遍再说下一句。轮次越多计算量和延迟增长得越快。边缘设备本来算力就有限智能体的多轮特性让“跑一个智能体”的实际开销变成了“跑几十次单次推理”的总和而且上下文还在增长开销是超线性的。这也意味着评价边缘设备能不能跑智能体不能只看单次推理延迟。我倾向于用“完整任务完成时间”来衡量比如“从用户提问到最终给出答案中间调用了五个工具总共耗时多少秒”。这个指标比单纯看某个阶段的token/s有价值得多因为它把多轮往返的累计开销都算进来了。2.3 多模型并发与编排压力很多人以为端侧智能体就是一个大模型跑到底真做过项目的都知道实际是一个模型组合一个7B或更小的主语言模型负责推理决策一个embedding模型处理向量检索一个视觉模型做图像理解一个小分类器做意图识别可能还要一个语音模型做ASR/TTS。不同的模型有不同的输入输出格式、不同的精度要求、不同的资源占用特性。这在边缘设备上会带来一个严峻的调度问题。NPU在同一时间通常只能高效处理一个任务多个模型并发推理时要么排队要么频繁切换上下文每次切换都有状态保存和加载的开销。我见过一个智能体Demo主模型跑得很流畅一开语音交互ASR模型和主模型抢NPU整个系统的延迟直接翻了两倍多。多模型编排不是简单的“依次调用”它考验的是芯片对资源分时复用的支持程度以及运行时是否具备智能的任务插队和优先级调度能力。2.4 状态持久化与安全边界智能体需要“记忆”。用户上次聊了什么、设备当前处于什么状态、任务做到哪一步这些信息必须持久化保存否则每轮对话都是失忆式开局。可是边缘设备的数据存储和云端不同开发板可能随时掉电智能体正在运行的时候断电状态写入一半就崩了重启后是恢复上次进度还是回到初始状态这类问题在工程化落地时非常致命。还有安全边界问题。智能体在端侧会拿到用户的真实数据、设备的控制权限、系统的API凭证。如果智能体的运行环境没有隔离机制一个写得不严谨的工具调用就可能让恶意指令读取用户隐私、修改系统配置。Arm在Armv9架构上推进CCA机密计算本质上就是在为这类场景铺路——让智能体的数据在独立的可信执行环境里处理即使系统其他部分被攻破智能体持有的密钥和敏感数据也有兜底保护。2.5 能耗墙往往比算力墙更先到来边缘设备不是数据中心服务器大多数场景是电池供电或者被动散热。手机、真无线耳机、工业传感器、机器人每一个都对功耗极其敏感。芯片标称的TOPS通常是在理想散热、短时间峰值状态下测出来的真实长期运行会被温度墙和功耗墙按在地板上摩擦。举个例子一颗标称50 TOPS的NPU峰值功耗可能要10W以上但手机里的持续功耗预算往往只有3到5W。为了不烧毁芯片、不烫伤用户SoC必须降频NPU实际能拿到的算力可能只有标称的一半都不到。这就是我前面说的“可持续性能”有些芯片能做到15W稳定跑4小时不降频有些芯片标称功耗很低但跑五分钟就撞温度墙性能跌得一塌糊涂。在智能体场景里多轮推理意味着长时间工作负载对持续性能的要求比单次突发推理更高能耗表现几乎直接决定了产品能不能上市。3. Arm的牌桌变了三条主线看懂“为智能体而生”3.1 硬件侧NPU从CNN专用走向Transformer原生Arm本质上是一家IP公司它不做整机但几乎所有边缘设备的CPU都基于它的架构。过去几年Arm在AI方面最标志性的动作是Ethos系列NPU从U55、U65到最新的Ethos-U85能看出一个清晰的演进路径早期NPU主要针对CNN网络做了大量定制图像分类、目标检测这类任务加速效果很好但一跑Transformer就力不从心。Ethos-U85发布的时候Arm明确把“Transformer支持”写进了特性表支持注意力机制、RMSNorm这类大模型常用算子配合Cortex-M85这类MCU使用目标是让嵌入式设备也能跑一定规模的语言模型。虽然这类MCU级NPU目前还撑不起完整的智能体但它代表了一个重要的方向判断哪怕是最微小的边缘设备Arm也希望它能承载AI推理而AI推理的形态正在从CNN变成TransformerNPU必须跟着变。真正承载智能体的主力还是应用处理器也就是Cortex-A系列。Arm在AI PC和手机芯片上推进CSS for Client平台把Cortex-X925大核、Cortex-A725中核和系统级缓存整合起来同时预留NPU GPU的协同接口。在Arm的规划里CPU不再是单纯的“控制中枢”而是智能体运行时的“主调度器”——既要跑推理也要跑工具调用逻辑、状态管理、安全隔离任务比以前复杂得多。3.2 软件侧Kleidi和“不绑定框架”的底层优化硬件只是地基软件才是智能体能不能跑起来的关键。Arm这两年最值得关注的软件动作是Kleidi系列包括聚焦AI推理内核的KleidiAI和聚焦计算机视觉的KleidiCV。它的思路很有意思不做一个封闭的AI推理框架而是把矩阵乘法、Softmax、LayerNorm这些底层算子优化到极致再让PyTorch、ExecuTorch、ONNX Runtime、llama.cpp这些主流框架直接调用一层层把性能红利传导到上层。这种“做水电煤”的打法非常务实。你去看现在边缘AI的软件生态框架层百花齐放今天冒出一个新运行时明天又有人把某个模型量化工具包装成新平台。但如果底层算子在Arm CPU上都有充分优化那不管上层怎么变开发者手里的模型都能吃到Arm架构的性能红利。我自己在Arm开发板上跑Llama类模型时对比过KleidiAI优化前后的GEMM实现某些场景下吞吐量能差出百分之三四十这是实打实的体验差距。对开发者来说Kleidi带来的另一个好处是降低了底层优化门槛。很多人做嵌入式AI时最头疼的就是交叉编译工具链和内核优化自己去翻汇编、调内存布局费时费力还容易搞错。Arm通过Kleidi把这一层“低级优化”标准化了开发者不用再跟每个算子死磕只要把框架和Kleidi连接好性能就有保底。我自己实际体会是跑在Cortex-A上的智能体推理CPU侧能用上Kleidi优化NPU侧也对接好驱动整体效果会靠谱很多。3.3 生态侧虚拟硬件把开发门槛拉下来做嵌入式开发的人应该都对“硬件还没到代码先写好”的愿望深有共鸣。过去Arm开发板的调试流程是等硬件、接串口、烧系统、跑代码、看日志一个循环下来大半天就没了。Arm虚拟硬件AVH改变的是这个流程——在云上提供Arm处理器和子系统的虚拟模型开发者可以在没有实体开发板的情况下先把代码、系统镜像、推理流程在虚拟环境里跑起来。对智能体开发来说这个价值被放大了。因为智能体是软件逻辑驱动的它的工具调用、状态流转、多轮对话逻辑完全可以在虚拟硬件上做单元测试和集成测试。我在CI流程里用AVH跑过针对不同Arm平台版本的部署脚本不用买一堆开发板就能验证兼容性比传统方式省太多。而且虚拟硬件还能模拟一些极端的硬件行为比如断点、异常、外设故障这些在真实板上很难故意触发在虚拟环境里却能系统性测试。当然虚拟硬件不能完全替代真机验证散热、功耗、外设时序这些物理特性是仿真不出来的。但作为开发流程的前半段它已经能把“能不能跑”这个问题的验证成本压到极低。Arm押注虚拟硬件本质上是在降低Arm平台的试错成本让更多开发者愿意进来做边缘智能体实验。3.4 叙事转向从“跑模型”到“承载智能体服务”Arm最近十几场发布会和公开文档的措辞变化非常明显。早期讲AI是“intelligent vision”“object detection”后来讲“on-device AI”“LLM inference”现在讲的是“agent-ready”“built for AI agents”。这不仅仅是营销话术的更新而是底层技术栈的定位在变芯片不再只是为了跑一个神经网络而是为了承载一个完整的、能自主决策的软件实体。“为智能体而生”体现在几个具体方向上。一是计算架构的多实体协同CPU、NPU、GPU、互连总线要能同时支撑推理、逻辑控制和数据搬运二是系统IP层面的安全管理CCA这类机制确保智能体的数据边界三是CPU指令集本身的扩展Armv9的SVE2和SME2为AI工作负载提供了更高效的向量计算能力。这些加在一起Arm押注的不再是某一颗芯片的浮点性能而是整个生态是否准备好迎接智能体时代。短期来看完整的端侧智能体还处于“能跑但还不够好”的阶段但Arm的方向判断我认为是对的智能体会成为边缘AI的主要负载形态谁先把承载智能体的全套底座做好谁就能在新一轮竞争里占住身位。4. 开发者要做的三个转变选型、工具链、性能分析4.1 选型清单除了TOPS还该看什么过去的边缘AI选型可以简单粗暴看TOPS加价格现在智能体时代这套方法行不通了。我总结了一份自己常用的选型观察清单不一定全面但至少能帮你避开一些明显的坑观察维度具体指标说明内存带宽DRAM带宽、总线位宽LLM和智能体场景最关键直接决定token吞吐缓存容量各级缓存、NPU内部SRAM缓存越大访存压力越小小模型甚至能驻留SRAMNPU MAC阵列单周期MAC数、支持的精度组合判断CNN和Transformer的处理效率精度支持INT4/INT8/FP16/FP32量化灵活性决定模型部署方案的余地可持续性能持续功耗、降频曲线用满载压力测试看实际长期表现软件栈成熟度是否支持主流推理框架、驱动质量硬件再强软件拉胯就等于不存在如果你主要做LLM和智能体我建议优先关注内存带宽和软件栈成熟度。很多时候芯片标称带宽很高但实际是CPU和NPU共享同一份带宽跑起混合负载来还是会互相挤占。最好的办法是拿到开发板后先做一个纯带宽基准测试比如连续读大块内存的耗时再跑一个真实的7B量化模型看看实测token/s和理论带宽支撑的上限差多少。4.2 工具链的四个落地坑边缘AI开发里交叉编译和工具链问题是最消耗时间的隐形杀手。网上关于arm交叉编译工具链、arm版镜像、智能体框架的搜索热度特别高说明这不是少数人的困扰。我把自己踩过的坑整理成四个最常见的情况第一个坑是工具链版本不匹配。交叉编译用的gcc版本、glibc版本、sysroot和目标的系统环境不一致会出现“编译过了但跑起来报错”的情况。这种问题排查起来非常费劲因为报错信息往往让人摸不着头脑。我现在会在CI流水线里固定工具链版本用Docker镜像把编译环境锁死避免“在我机器上是好的”这种尴尬。第二个坑是模型转换的算子兼容问题。同一个模型在PyTorch里能跑导出成ONNX再转成某个NPU支持的格式中间可能出现某个算子不支持、某一层精度异常。智能体的模型栈比单模型复杂embedding模型、视觉模型、语言模型各有各的转换链路每一步都要验证中间结果。第三个坑是NPU驱动和运行时版本与内核绑定太紧。很多芯片的NPU驱动要求特定版本的内核、特定版本的firmware升级系统镜像可能就导致NPU不可用。我吃过这个亏之后养成了一个习惯搭建完环境后第一时间做系统快照记录内核版本、驱动版本、推理运行时版本方便出问题时快速回退或复现。第四个坑是虚拟硬件和真机行为存在差异。在Arm虚拟硬件上跑得好好的程序烧到真机上可能因为外设时序不同、内存布局不同而出现异常。我的处理方式是虚拟硬件用来做逻辑验证和CI冒烟测试真机用来做性能验证和长期稳定性测试两条线都要走不能省。一个简单的工具链固定示例类似这样在CI里预先拉取固定版本# 示例固定交叉编译工具链版本 export TOOLCHAIN_VERSION13.2.rel1 export SYSROOT_PLATFORMarm64-linux-gnu # 拉取并安装指定版本的交叉编译工具链 wget -qO- https://example.org/arm-gnu-toolchain-${TOOLCHAIN_VERSION}-x86_64-aarch64.tar.xz | tar xJ -C /opt固定的目的不是限制灵活性而是保证可复现性。智能体项目的迭代周期长、参与角色多模型、代码、系统环境任何一个变量飘了都可能导致线上问题工具链锁定是成本最低的稳定性手段。4.3 性能分析的正确姿势很多开发者拿到板子后习惯性用AI Benchmark跑个分看个总分就觉得性能心里有数了。智能体场景下这种做法参考价值很有限。我更建议针对你的实际任务做端到端性能观测至少记录这几个指标单个token生成时间或p95延迟、完整任务耗时、内存峰值占用、持续功耗和温度曲线。以跑一个带RAG和工具调用的智能体为例如果只测模型裸推理可能得出“很流畅”的结论但把向量检索、上下文拼接、工具调用、多轮推理全部串起来以后延迟可能翻了五倍。我会做一次“全链路性能画像”从用户输入开始到最终响应结束记录每个环节的耗时占比和资源占用量。这个画像能直接告诉你系统的瓶颈在哪里是模型推理、数据搬运还是任务调度。还有一个小经验不要只看平均值要看分布。智能体任务的token生成速度往往不是均匀的上下文长的时候每个token会变慢工具调用后第一次生成首token时有明显的延迟尖峰。观察p95和p99延迟才能准确评估用户体验平均值在智能体这种多轮交互场景里太容易被稀释了。5. 哪些场景会先跑起来工业、终端和谨慎乐观5.1 工业智能体2026年的工程化分水岭这两年行业里流传一个共识2026年是工业智能体从概念演示走向工程化落地的分水岭。我比较认同这个判断。工业场景对边缘AI一直有刚需工厂的网络环境不稳定数据不能随便上云实时控制要求毫秒级响应这些约束天然指向边缘部署。而工业智能体比传统工业AI更进一步它不只是做质检或预测而是能根据实时状态做调度决策、调用设备控制接口、协调多台机器的动作。举个具体的例子一条产线上的质检智能体如果发现良率异常它会先定位到可能的工艺参数偏移然后调用设备控制接口调整参数再持续监控后续产品的质量。整个过程在本地完成不需要依赖云端。传统AI只能“报异常”智能体能“处理异常”这就是从工具到协作者的转变。当然工业场景的工程化难度也最高设备协议五花八门、老系统兼容性差、安全标准严苛这些都是智能体落地要啃的硬骨头。说“2026是分水岭”意思不是到时候所有工厂都有智能体而是第一批可复制的工程样板会出来后续的规模化才真正开始。5.2 消费终端AI手机、AI PC与机器人消费端是所有厂商最看重的智能体试验场。手机上的个人助理智能体可以帮用户订日程、查信息、操作AppPC上的办公智能体能写文档、整理文件、跨应用调度机器人领域的任务规划智能体能把“把桌上的杯子拿过来”拆解成导航、识别、抓取、避障等一系列动作。三者共同的基座都是Arm架构的应用处理器。我观察到的现象是Arm平台在消费端的普及速度比大多数人预期的更快。除了手机市场本来就在Arm手里Windows on Arm的生态也在快速追赶越来越多开发者开始接触arm版系统镜像、交叉编译工具链。这种生态扩张对智能体开发者是双刃剑好处是目标设备更多了坏处是碎片化更严重了适配成本上升。所以Arm推虚拟硬件、推标准化工具链某种程度上也是为了解决自己的碎片化问题。消费端智能体能不能真正成为“杀手级应用”我持谨慎乐观态度。技术层面7B量化模型在旗舰手机上的推理速度已经能到每秒十几个token加上工具调用框架逐渐成熟基础条件是够的。但用户体验层面智能体的“聪明程度”还达不到让人离不开的水平尤其在国内App生态高度割裂的情况下跨应用调度受限很多。可以肯定的是这条路方向是对的比拼的大幕已经拉开。5.3 现阶段不建议硬扛的场景不是所有智能体都应该往边缘塞。我现在对三类场景持保守态度需要超大容量长期记忆的智能体、需要复杂全局规划的智能体、需要频繁联网获取实时外部数据的智能体。第一类的问题在内存容量几十万token的上下文在边缘设备上根本住不下第二类的问题在算力和可靠性复杂的全局规划往往需要更强的模型和更高的成功率端侧小模型容易在长链条任务里跑偏第三类的问题在能力边界智能体如果每一步都要联网那边缘部署的意义就小了很多不如直接放云端。我的建议是“边缘云端协同”智能体在端侧负责低延迟、隐私敏感、需要实时响应的部分云端负责重计算、大记忆、全局推理的部分。这不是退而求其次而是目前工程上最可靠的架构。Arm押注的“为智能体而生”也不是说所有智能体都要跑在端侧而是让端侧变成智能体的一个重要承载点。6. 写在最后一点个人体会这几年做边缘AI我最大的感受是行业正在从“拼参数”走向“拼系统”。前两年大家习惯用TOPS和跑分来衡量芯片真到了部署智能体的那一天还是内存带宽、工具链成熟度、功耗表现这些东西决定了项目能不能成。我踩过很多坑也慢慢整理出一套自己的选型方法先做基准测试再谈模型先跑通端到端再优化局部先锁定工具链再谈扩展性。最后分享一个我觉得特别实用的小习惯拿到任何一块新开发板别急着跑模型先做一个内存带宽基准测试和持续功耗压力测试。这两个数据测完你能大概预判这块板子跑LLM的天花板也会对后续模型选型和量化方案有更清晰的判断。很多时候问题不是“算力不够”而是“数据搬不过来”。Arm把赌注压在“为智能体而生”上方向我觉得很清晰但路还长。智能体的工程化落地拼的不只是芯片更是系统、工具链和整个生态的成熟度。对做边缘AI的开发者来说现在正是把思路从“找个能跑模型的板子”升级为“搭一套能承载智能体的系统”的好时候。