这两年只要打开芯片发布会XX TOPS几乎成了唯一的背景音。40、67、100一个比一个高好像 TOPS 数字就是边缘 AI 的全部。但真正在边缘设备上做过项目的人心里都清楚TOPS 像汽车铭牌上的最大马力好看但决定你实际跑多快的是变速箱、轮胎和路面。Arm 最近在边缘 AI 上换了套叙事不再跟着喊 TOPS而是把为智能体而生agent-native摆上台面。这不是简单的营销动作背后是一整条判断下一波边缘设备的核心负载将从单次推理任务切换成多步骤智能体任务而这类任务对芯片体系结构的要求跟 TOPS 能代表的东西完全是两码事。下面我就把TOPS 为什么不够用、智能体为什么需要新硬件、Arm 凭什么押注、开发者现在该做什么这条线拆开讲清楚也会附上我在 Arm 平台上实际部署智能体的调优记录。如果你想做边缘智能体选型或者只是好奇 AI 硬件圈在争什么应该会有用。1. TOPS 军备竞赛背后的账本错位1.1 TOPS 只是理论峰值离真机体验隔着一层利用率先算一笔账。TOPS 是每秒万亿次操作的缩写它的计算方式公开且简单NPU 里 MAC乘加阵列规模 × 工作频率 × 2。因为一次乘加指令在硬件里同时完成了乘法和加法业界默认按两次操作统计。以 INT8 精度为基准一颗芯片标称多少 TOPS意味着它的 MAC 阵列理论上每秒钟能完成多少次 8bit 乘加。举个例子一个 512 MAC 单元、跑 1GHz 的 NPU理论就是 512 × 1G × 2 ≈ 1 TOPS。问题几乎都出在理论上三个字上。我做实测时绝大多数开发板的 NPU 利用率只在 30%~50% 之间能稳定跑到 60% 以上已经算得上调教得相当到位。剩下那部分性能去哪了第一是 PE 阵列填充率卷积和 Transformer 里到处是不规则的 shape很多 MAC 单元只能空转第二是数据搬运片内 SRAM 装不下权重和中间激活就得频繁访问外部 DDR总线一忙算力只能等数据第三是算子融合度每多一个未融合算子就多一次中间结果的写出读入等于在带宽上重复烧钱。所以看到一块芯片标称 40 TOPS真正能拿到的聪明可能只有一半这还只是乐观估计。1.2 标称相同算子覆盖不同实际是两台完全不同的机器比利用率更隐蔽的是架构代差。同样标称 40 TOPS老一代偏向 CNN 的 NPU 和新一代Transformer 原生NPU 跑同一个 7B 模型结果可能是数量级的差距。原因在于LLM 推理链路里除了 GEMM还有大量 softmax、RMSNorm、RoPE、GELU 这类算子。老架构要么不支持要么拆成若干小算子搬到 CPU 上兜底要么在 SRAM 和 DDR 之间来回导数据。而新一代 NPU 把这些算子直接做进硬件有的还支持 2:4 结构化稀疏可以跳过一半权重读取省下的带宽直接转化成速度。这里我给一张对比表同为标称不错的 NPU差的不是性能而是工作负载适应度特性老一代 CNN 特化 NPU新一代 Transformer 原生 NPU主要优化对象卷积、池化、激活GEMM attention 相关算子softmax / LayerNorm通常不支持CPU 兜底硬件算子或融合进 GEMMKV cache 缓存策略不感知反复搬运可驻留片内减少访存跑 7B 模型体验低效、工具链折腾可直接部署、效果可用所以40 TOPS 的 A 和 40 TOPS 的 B 差不多是一个完全不成立的推断。现在做选型我把算子覆盖清单放在 TOPS 数字前面看后者最多当宣传语。1.3 为什么 Arm 要在这个时间点讲为智能体而生Arm 当然知道 TOPS 是考核指标但它的商业逻辑决定了它必须讲一个更大的故事。Arm 做的是 IP 授权一层是芯片设计客户一层是庞大的开源软件生态。它想让下一波边缘芯片卖得动就得先定义边缘的下一个工作负载是什么再倒推整个 IP 组合怎么设计而不是让客户自己拼出一堆算力不错但跑不动场景的芯片。为智能体而生就是这个定义。言下之意是别拿 TOPS 当 KPI 了真正的 KPI 是一台设备能不能在本地流畅跑完一条完整的智能体链路——感知、推理、工具调用、多轮决策。这种话 NVIDIA 也讲过它让你别看算力看 tokens/s。Arm 的不同在于位置更底层它要从指令集、NPU 到编译器、推理框架做全栈影响。话术能不能成取决于它的 IP 是不是真的让开发者更好用而不是 PPT 更好看。2. 智能体上了边缘喂养数据比计算速度快更致命2.1 拆一条典型的智能体链路智能体Agent这个词这两年被用滥了但落到工程上其实很具体一个模型在循环里反复决策调用外部工具再根据结果继续推理。我拿一个最常见的语音指令 → 本地理解 → 调用视觉工具识别物体 → 生成回答链路举例它至少包含四步先用小模型把语音转成指令再让大模型做意图识别与任务规划接着把视觉模型的输出作为新上下文喂回去最后做一轮文本生成。每一步都是一次推理前一步的输出是后一步的输入整条链路的状态在内存里滚着走。对这个链路来说单次推理快没有决定性意义。真正影响体验的是完成一整条链路要多久以及链路里每一步的 P95 延迟。如果某一步把总线占满后面所有步骤都得排队。这时候你会明显感觉到瓶颈根本不在 NPU 有多能算而在数据怎么在 CPU、NPU、内存之间流动。2.2 decode 阶段是 memory-bound权重和 KV cache 都是吞带宽大户这里有个必须建立的体感LLM 生成阶段decode是内存带宽限制的不是算力限制的。每生成一个 token都要把整个模型的权重从头到尾读一遍再叠加读取 KV cache。假设一个 7B 模型量化到 INT4权重约 3.5GB。如果这块板子的内存带宽只有 17GB/s理论极限就是 17 / 3.5 ≈ 4.8 token/s带宽到 51.2GB/s理论极限能拉到 14.6 token/s。再打个折扣实际体验大概是理论值的一半左右。内存类型与位宽理论带宽7B INT4 模型理论 token 上限LPDDR4X 32-bit4266MT/s≈17 GB/s≈4.8 token/sLPDDR5 64-bit6400MT/s≈51.2 GB/s≈14.6 token/sLPDDR5X 64-bit8533MT/s≈68 GB/s≈19.5 token/s这个带宽 ÷ 模型体积 token 速度上限的换算公式建议所有做边缘大模型的同学记熟。它解释了为什么很多标称高 TOPS 的芯片跑大模型反而会被低 TOPS 芯片按在地上摩擦——带宽不够算力饿死了。prefill 阶段还算 compute-bound到了 decode 阶段完全变成 memory-bound谁的内存带宽大谁才笑得出来。2.3 KV cache 与多轮记忆智能体比普通推理多出来的隐性成本普通单次推理是无状态的输一个问题出一个答案完事。智能体是有状态的对话历史、工具调用记录、中间结果都要存下来。这部分存在哪绝大部分在 KV cache 里。序列长度每翻一倍KV cache 内存占用就线性翻一倍带宽压力跟着一起翻。拿 7B 模型举例开 8k 上下文FP16 的 KV cache 可能占 1~2GB换成 INT8 能省一半但也绝不算小。如果链路里再混入视觉工具的 token上下文长度轻松破万板子内存很快就 OOM。智能体就像一个一边做口算一边疯狂记笔记的人笔记越记越厚算得快不能解决记得住的问题。这也就是 Arm 反复强调内存带宽和异构调度的底层原因——它的切入点给的是有状态的持续工作负载不是跑完一个 benchmark 就下班的静态任务。3. Arm 的为智能体而生到底押了什么3.1 指令集层面SME2 让 CPU 也能接住矩阵计算第一个押注在指令集。Armv9 引入的 SVE2 和 SME可扩展矩阵扩展到 SME2 这代已经能比较完整地支撑 CPU 侧的矩阵运算。很多人不理解为什么要用 CPU 跑矩阵——NPU 不是更专业吗问题在于智能体链路里大量运算是低批量、动态 shape 的反复把数据搬进 NPU、再从 NPU 搬回来的开销有时候比直接在 CPU 上算完更大。SME2 的价值就是给 CPU 一个灵活的 tile 计算能力把这类边角料运算就地消化掉。别小看这个设计。智能体在板子上是持续运行的状态机小算子高频出现。CPU 能接住一部分NPU 才能专心跑真正吃算力的重负载。这个分工是为智能体而生在指令集层面最实在的体现也是 Arm 和过去那种CPU 只管调度、NPU 干所有脏活的老思路最大的区别。3.2 NPU 层面从 CNN 专用走向 Transformer 原生第二个押注在 Ethos NPU 的演进上。从 Ethos-U55 到 U65 再到 U85路径写得非常清楚从支持 CNN 为主转向原生支持 Transformer 算子。U85 这一代的 MAC 阵列规模到了 128 MAC/cycle官方口径是相对 U65 有最高 4 倍的机器学习性能提升同时把 softmax、LayerNorm 这类算子做进硬件而不是丢给 CPU 兜底。根据公开资料U85 在增强配置下能接近 4 TOPS 量级——但这个数字本身不重要重要的是它证明了 Arm 开始按Transformer 语义设计微架构。配合 Cortex 的异构调度整颗 SoC 的分工会变成NPU 跑持续重负载推理GPU 管通用计算与图形CPU 负责智能体的决策循环和工具调度。这个三角结构本质上已经把智能体需要在本地循环决策当成默认设计目标而不再只是跑一个大模型 demo。做边缘算力选型时可以拿这个分工逻辑去倒推芯片公司的设计意图如果一颗芯片还在把 Transformer 算子拆得七零八落那它大概率还是上一代思路。3.3 软件栈层面Kleidi、Corstone 与开源生态的连接第三个押注最容易被忽略但我觉得才是真正的胜负手——软件。Arm 开源了 KleidiAI 和 KleidiCV目标是在 Cortex CPU 上提供深度优化的算子库让 llama.cpp、ExecuTorch、ONNX Runtime 这类推理框架在 Arm 上尽量接近硬件极限。例如 KleidiAI 能让纯 CPU 场景也能跑出相当可观的 token 速度这对低端设备意义很大——很多智能体的工具决策根本不需要大模型CPU 上跑一个小模型就够用没必要为了它把 NPU 拉起来。同时 Arm 用 Corstone 参考子系统把 Cortex、Ethos、存储与外设打包成标准化方案降低芯片公司做设计的门槛。Arm 的商业模式决定了它没法像 CUDA 生态那样画一个闭环它必须服务整个开源世界的兼容矩阵。所以为智能体而生不只是芯片 IP 的事也是软件栈的事。开发者能不能用熟悉的框架直接编译到 aarch64能不能一条命令拉起推理引擎这些体验层面的东西最后会变成芯片公司跟不跟 Arm 走的理由。4. 在 Arm 边缘平台上跑通一个智能体我的实操记录4.1 选板子先看带宽和 SDK别只看 TOPS先交代背景我用的是一块 RK3588 平台的板子标称 6 TOPS NPU内存带宽在 51.2GB/s 左右64-bit LPDDR5板载 8GB 内存。很多朋友一听 6 TOPS 就摇头觉得太小。但拿它跑 7B INT4 模型token 速度上限算出来是 51.2 / 3.5 ≈ 14.6 token/s实际稳定在 8~10 token/s 问题不大对一个智能体链路来说已经能用了。这步选型我有三个硬指标第一内存带宽至少 40GB/s优先 LPDDR5 以上第二NPU 的 SDK 必须覆盖你要跑的模型格式和算子不能只支持自家 demo 模型第三板载内存至少 8GB因为你还要跑 Python 运行时、工具进程和 KV cache。这三个指标都过了再回头看 TOPS。TOPS 高但 SDK 封闭的板子基本上买回来就是吃灰。4.2 交叉编译与运行环境踩坑智能体框架通常依赖一堆动态库直接在板子上编译会让人崩溃——RK3588 那点 CPU 编译一个 llama.cpp 都得半小时起步。我的做法是在 x86 开发机上做交叉编译再把产物扔到板子上。基本流程# x86 开发机上安装 aarch64 交叉工具链 sudo apt update sudo apt install gcc-aarch64-linux-gnu g-aarch64-linux-gnu # 用 CMake toolchain 指定目标平台 cmake -B build \ -DCMAKE_SYSTEM_NAMELinux \ -DCMAKE_SYSTEM_PROCESSORaarch64 \ -DCMAKE_C_COMPILERaarch64-linux-gnu-gcc \ -DCMAKE_CXX_COMPILERaarch64-linux-gnu-g改完依赖后最常见的问题是 glibc 版本不匹配在开发机上链接的 glibc 如果比板子系统新跑起来就是经典的 version GLIBC_2.xx not found。我吃过几次亏之后学乖了直接用板子官方提供的镜像作为 sysroot常见的 arm 版 Debian、CentOS aarch64 镜像都可以。如果智能体调度服务里混着 Java 组件也别在 x86 上想当然老老实实拉 aarch64 版 JDK比如 JDK 11 的 arm 版本并核对板子的 glibc 版本。调试阶段可以用 QEMU user-mode或者现成的 aarch64 镜像先做冒烟测试但千万别拿模拟器数据当性能依据模拟环境的内存带宽和真机差距太大。4.3 量化的关键混合量化与 KV cache 策略模型量化是绕不开的关。我的体感是别做全 INT4 崇拜智能体链路里经常有视觉工具返回的图像 token 或数字信号这些输入侧特征张量走 FP16 更稳。权重层可以 INT4/INT8 混合KV cache 用 INT8attention 输出保持 FP16这是目前边缘端最实用的折中。量化完一定要做人工抽测用几条真实的工具调用链路验一遍光看 benchmark 分数容易被骗——量化误差在单次推理上不明显但在多轮决策时会累积模型越用越笨就是这个原因。另外提醒一个隐蔽的坑NPU SDK 升级之后之前量化好的模型经常要重新编译。像 RKNN 这类工具链驱动版本一旦从 1.x 跳到 2.x算子映射和量化策略全变整个量化管线要重跑一遍。搞过 Cortex-M 的同学应该还记得 ARM Compiler 5 老工程迁移到 AC6 的工具链版本债这种债在 NPU SDK 世界里只会更狠。所以做项目时量化脚本必须固化下来别用一锤子买卖的 Notebook。4.4 智能体框架在板端的瘦身与分层Dify、LangGraph、CrewAI 这些框架在云端跑得很开心搬上 Arm 开发板就完全不是一回事了。Python 运行时本身就吃内存框架再带一堆依赖8GB 的板子跑 7B 模型加长上下文直接就 OOM。我最后采取的办法是指挥逻辑跟推理分开推理进程常驻用 NPU 跑模型智能体调度逻辑放在另一个进程两者之间走共享内存或消息队列。这样既能绕开 Python GIL 的坑也能把内存预算控得更细。框架选型上我的优先级是裸 llama.cpp 加自写脚内存最省ExecuTorch适合 PyTorch 生态GGML 系列C/Rust 绑定适合嵌入式最后才是 Dify 这种重量级编排平台——它更适合做云端的智能体应用层而不是板端推理单元。实测下来一条语音指令 → 意图规划 → 调用视觉工具 → 生成回答的四步链路在 6 TOPS NPU 上完整跑一次体感在 5~8 秒。瓶颈基本不在 NPU而在中间结果进出共享内存的拷贝、工具进程的启动开销以及 Python 对象序列化。把这些非推理的 overhead 优化完比换一块标称 20 TOPS 的板子见效快得多。5. 抛开 TOPS我评估边缘智能体硬件的五个维度5.1 一张表看懂每 TOPS 带宽这个比值我习惯把每 TOPS 对应的内存带宽作为第一个筛选指标它代表算力会不会被饿死平台标称算力内存带宽约每 TOPS 带宽某中端 Arm 板RK35886 TOPS NPU51.2 GB/s≈8.5 GB/s某旗舰移动 SoC45 TOPS NPU68 GB/s≈1.5 GB/sJetson Orin Nano Super67 TOPS68 GB/s≈1.0 GB/s单看 TOPS旗舰 45 TOPS 吊打 RK3588但跑 7B 级别模型时低 TOPS、高带宽的 RK3588 反而不容易卡在 decode 上。智能体链路是多轮 decode 主导这个比值尤其重要。我的经验值选型先卡每 TOPS 带宽不低于 1.5GB/s再看别的。5.2 峰值 TOPS 与可持续 TOPS功耗墙下的真实水平第二个维度是可持续 TOPS。很多板子的峰值数字只能短时间跑出来NPU 全速运行时芯片发热几分钟后撞上功耗墙降频。建议拿到板子先做 30 分钟持续推理烤机记录 token 速度曲线。如果前 10 分钟稳定 13~14 token/s后面掉到 8 token/s说明散热撑不住选型时必须按后半段的数字做预算。对做移动设备或电池设备的人这个往往比峰值更影响体验。5.3 生态成熟度才是最大的隐性成本第三个维度是软件生态成熟度具体看三点算子覆盖清单有没有公开、SDK 文档与样例的更新频率、社区活跃度。算力是硬件给的好用是软件给的。一块标称 40 TOPS 的 NPU 如果算子支持不全为了跑一个 Transformer 算子你要花两周绕路那这 40 TOPS 就是负资产。还有个简便判断法把你常用的推理框架拉到目标平台交叉编译一遍看卡在哪个环节。能顺利过编译、跑得起来、算子大多能映射生态就算过关。最近各家开始公开智能体训练方法论比如 DeepSeek 放出的多步推理 工具使用训练思路很多团队顺势把这类负载做成标准评测不再拿单模型 benchmark 冒充边缘 AI 能力。我觉得这正好把行业往一个更务实的方向推大家终于开始用智能体链路测硬件了。5.4 智能体链路要求的是确定性延迟最后加一个容易被忽略的维度确定性延迟。智能体的工具调用通常有等待窗口如果某一次推理抖动 10 秒整个用户体验直接崩。边缘 NPU 的时延稳定性、驱动是否偶发卡顿都需要用长循环压测来找。我用一条五步工具链路连续压 100 轮看 P95 与 P50 的差距差距越大说明确定性越差。峰值跑得快不算本事跑得稳定才算。6. 分水岭在即开发者现在应该做的三件事今年多场行业会议上有共识2026 年会成为工业智能体从概念演示走向工程化落地的分水岭。这个判断对边缘计算从业者来说意味着能跑 demo很快就不值钱了接下来客户要的是能稳定运行几个月、断电重启不挂、延迟可控的工程化系统。我自己的建议是三件事。第一把选型基准从单模型换成智能体链路定一条五步以内的工具调用链路测全链路耗时和 P95 延迟而不是只报告某模型跑了多少 token/s。第二把 KV cache 预算写进需求文档算清上下文长度、量化精度和内存余量8GB 以下的内存真没法认真做长上下文智能体。第三优先考察软件栈兼容性llama.cpp、ExecuTorch、ONNX Runtime 在 aarch64 上是否一键可用比 TOPS 数字实在得多。最后分享一个真实体感。这些年我见过太多选型会上为 67 和 45 两个数字争得面红耳赤的场面等板子到了手跑完真实链路才发现瓶颈在内存带宽和软件适配。Arm 这波把为智能体而生摆上桌面本质上是在重新定义行业的考核标准——从你的 NPU 多能算转向你的系统能不能让智能体长时间稳定地思考。作为开发者与其纠结数字不如先把手头那条智能体链路在目标板上跑通。跑通了你就知道该买什么了。
边缘AI的TOPS迷思：Arm“为智能体而生”如何重构芯片评估标准
这两年只要打开芯片发布会XX TOPS几乎成了唯一的背景音。40、67、100一个比一个高好像 TOPS 数字就是边缘 AI 的全部。但真正在边缘设备上做过项目的人心里都清楚TOPS 像汽车铭牌上的最大马力好看但决定你实际跑多快的是变速箱、轮胎和路面。Arm 最近在边缘 AI 上换了套叙事不再跟着喊 TOPS而是把为智能体而生agent-native摆上台面。这不是简单的营销动作背后是一整条判断下一波边缘设备的核心负载将从单次推理任务切换成多步骤智能体任务而这类任务对芯片体系结构的要求跟 TOPS 能代表的东西完全是两码事。下面我就把TOPS 为什么不够用、智能体为什么需要新硬件、Arm 凭什么押注、开发者现在该做什么这条线拆开讲清楚也会附上我在 Arm 平台上实际部署智能体的调优记录。如果你想做边缘智能体选型或者只是好奇 AI 硬件圈在争什么应该会有用。1. TOPS 军备竞赛背后的账本错位1.1 TOPS 只是理论峰值离真机体验隔着一层利用率先算一笔账。TOPS 是每秒万亿次操作的缩写它的计算方式公开且简单NPU 里 MAC乘加阵列规模 × 工作频率 × 2。因为一次乘加指令在硬件里同时完成了乘法和加法业界默认按两次操作统计。以 INT8 精度为基准一颗芯片标称多少 TOPS意味着它的 MAC 阵列理论上每秒钟能完成多少次 8bit 乘加。举个例子一个 512 MAC 单元、跑 1GHz 的 NPU理论就是 512 × 1G × 2 ≈ 1 TOPS。问题几乎都出在理论上三个字上。我做实测时绝大多数开发板的 NPU 利用率只在 30%~50% 之间能稳定跑到 60% 以上已经算得上调教得相当到位。剩下那部分性能去哪了第一是 PE 阵列填充率卷积和 Transformer 里到处是不规则的 shape很多 MAC 单元只能空转第二是数据搬运片内 SRAM 装不下权重和中间激活就得频繁访问外部 DDR总线一忙算力只能等数据第三是算子融合度每多一个未融合算子就多一次中间结果的写出读入等于在带宽上重复烧钱。所以看到一块芯片标称 40 TOPS真正能拿到的聪明可能只有一半这还只是乐观估计。1.2 标称相同算子覆盖不同实际是两台完全不同的机器比利用率更隐蔽的是架构代差。同样标称 40 TOPS老一代偏向 CNN 的 NPU 和新一代Transformer 原生NPU 跑同一个 7B 模型结果可能是数量级的差距。原因在于LLM 推理链路里除了 GEMM还有大量 softmax、RMSNorm、RoPE、GELU 这类算子。老架构要么不支持要么拆成若干小算子搬到 CPU 上兜底要么在 SRAM 和 DDR 之间来回导数据。而新一代 NPU 把这些算子直接做进硬件有的还支持 2:4 结构化稀疏可以跳过一半权重读取省下的带宽直接转化成速度。这里我给一张对比表同为标称不错的 NPU差的不是性能而是工作负载适应度特性老一代 CNN 特化 NPU新一代 Transformer 原生 NPU主要优化对象卷积、池化、激活GEMM attention 相关算子softmax / LayerNorm通常不支持CPU 兜底硬件算子或融合进 GEMMKV cache 缓存策略不感知反复搬运可驻留片内减少访存跑 7B 模型体验低效、工具链折腾可直接部署、效果可用所以40 TOPS 的 A 和 40 TOPS 的 B 差不多是一个完全不成立的推断。现在做选型我把算子覆盖清单放在 TOPS 数字前面看后者最多当宣传语。1.3 为什么 Arm 要在这个时间点讲为智能体而生Arm 当然知道 TOPS 是考核指标但它的商业逻辑决定了它必须讲一个更大的故事。Arm 做的是 IP 授权一层是芯片设计客户一层是庞大的开源软件生态。它想让下一波边缘芯片卖得动就得先定义边缘的下一个工作负载是什么再倒推整个 IP 组合怎么设计而不是让客户自己拼出一堆算力不错但跑不动场景的芯片。为智能体而生就是这个定义。言下之意是别拿 TOPS 当 KPI 了真正的 KPI 是一台设备能不能在本地流畅跑完一条完整的智能体链路——感知、推理、工具调用、多轮决策。这种话 NVIDIA 也讲过它让你别看算力看 tokens/s。Arm 的不同在于位置更底层它要从指令集、NPU 到编译器、推理框架做全栈影响。话术能不能成取决于它的 IP 是不是真的让开发者更好用而不是 PPT 更好看。2. 智能体上了边缘喂养数据比计算速度快更致命2.1 拆一条典型的智能体链路智能体Agent这个词这两年被用滥了但落到工程上其实很具体一个模型在循环里反复决策调用外部工具再根据结果继续推理。我拿一个最常见的语音指令 → 本地理解 → 调用视觉工具识别物体 → 生成回答链路举例它至少包含四步先用小模型把语音转成指令再让大模型做意图识别与任务规划接着把视觉模型的输出作为新上下文喂回去最后做一轮文本生成。每一步都是一次推理前一步的输出是后一步的输入整条链路的状态在内存里滚着走。对这个链路来说单次推理快没有决定性意义。真正影响体验的是完成一整条链路要多久以及链路里每一步的 P95 延迟。如果某一步把总线占满后面所有步骤都得排队。这时候你会明显感觉到瓶颈根本不在 NPU 有多能算而在数据怎么在 CPU、NPU、内存之间流动。2.2 decode 阶段是 memory-bound权重和 KV cache 都是吞带宽大户这里有个必须建立的体感LLM 生成阶段decode是内存带宽限制的不是算力限制的。每生成一个 token都要把整个模型的权重从头到尾读一遍再叠加读取 KV cache。假设一个 7B 模型量化到 INT4权重约 3.5GB。如果这块板子的内存带宽只有 17GB/s理论极限就是 17 / 3.5 ≈ 4.8 token/s带宽到 51.2GB/s理论极限能拉到 14.6 token/s。再打个折扣实际体验大概是理论值的一半左右。内存类型与位宽理论带宽7B INT4 模型理论 token 上限LPDDR4X 32-bit4266MT/s≈17 GB/s≈4.8 token/sLPDDR5 64-bit6400MT/s≈51.2 GB/s≈14.6 token/sLPDDR5X 64-bit8533MT/s≈68 GB/s≈19.5 token/s这个带宽 ÷ 模型体积 token 速度上限的换算公式建议所有做边缘大模型的同学记熟。它解释了为什么很多标称高 TOPS 的芯片跑大模型反而会被低 TOPS 芯片按在地上摩擦——带宽不够算力饿死了。prefill 阶段还算 compute-bound到了 decode 阶段完全变成 memory-bound谁的内存带宽大谁才笑得出来。2.3 KV cache 与多轮记忆智能体比普通推理多出来的隐性成本普通单次推理是无状态的输一个问题出一个答案完事。智能体是有状态的对话历史、工具调用记录、中间结果都要存下来。这部分存在哪绝大部分在 KV cache 里。序列长度每翻一倍KV cache 内存占用就线性翻一倍带宽压力跟着一起翻。拿 7B 模型举例开 8k 上下文FP16 的 KV cache 可能占 1~2GB换成 INT8 能省一半但也绝不算小。如果链路里再混入视觉工具的 token上下文长度轻松破万板子内存很快就 OOM。智能体就像一个一边做口算一边疯狂记笔记的人笔记越记越厚算得快不能解决记得住的问题。这也就是 Arm 反复强调内存带宽和异构调度的底层原因——它的切入点给的是有状态的持续工作负载不是跑完一个 benchmark 就下班的静态任务。3. Arm 的为智能体而生到底押了什么3.1 指令集层面SME2 让 CPU 也能接住矩阵计算第一个押注在指令集。Armv9 引入的 SVE2 和 SME可扩展矩阵扩展到 SME2 这代已经能比较完整地支撑 CPU 侧的矩阵运算。很多人不理解为什么要用 CPU 跑矩阵——NPU 不是更专业吗问题在于智能体链路里大量运算是低批量、动态 shape 的反复把数据搬进 NPU、再从 NPU 搬回来的开销有时候比直接在 CPU 上算完更大。SME2 的价值就是给 CPU 一个灵活的 tile 计算能力把这类边角料运算就地消化掉。别小看这个设计。智能体在板子上是持续运行的状态机小算子高频出现。CPU 能接住一部分NPU 才能专心跑真正吃算力的重负载。这个分工是为智能体而生在指令集层面最实在的体现也是 Arm 和过去那种CPU 只管调度、NPU 干所有脏活的老思路最大的区别。3.2 NPU 层面从 CNN 专用走向 Transformer 原生第二个押注在 Ethos NPU 的演进上。从 Ethos-U55 到 U65 再到 U85路径写得非常清楚从支持 CNN 为主转向原生支持 Transformer 算子。U85 这一代的 MAC 阵列规模到了 128 MAC/cycle官方口径是相对 U65 有最高 4 倍的机器学习性能提升同时把 softmax、LayerNorm 这类算子做进硬件而不是丢给 CPU 兜底。根据公开资料U85 在增强配置下能接近 4 TOPS 量级——但这个数字本身不重要重要的是它证明了 Arm 开始按Transformer 语义设计微架构。配合 Cortex 的异构调度整颗 SoC 的分工会变成NPU 跑持续重负载推理GPU 管通用计算与图形CPU 负责智能体的决策循环和工具调度。这个三角结构本质上已经把智能体需要在本地循环决策当成默认设计目标而不再只是跑一个大模型 demo。做边缘算力选型时可以拿这个分工逻辑去倒推芯片公司的设计意图如果一颗芯片还在把 Transformer 算子拆得七零八落那它大概率还是上一代思路。3.3 软件栈层面Kleidi、Corstone 与开源生态的连接第三个押注最容易被忽略但我觉得才是真正的胜负手——软件。Arm 开源了 KleidiAI 和 KleidiCV目标是在 Cortex CPU 上提供深度优化的算子库让 llama.cpp、ExecuTorch、ONNX Runtime 这类推理框架在 Arm 上尽量接近硬件极限。例如 KleidiAI 能让纯 CPU 场景也能跑出相当可观的 token 速度这对低端设备意义很大——很多智能体的工具决策根本不需要大模型CPU 上跑一个小模型就够用没必要为了它把 NPU 拉起来。同时 Arm 用 Corstone 参考子系统把 Cortex、Ethos、存储与外设打包成标准化方案降低芯片公司做设计的门槛。Arm 的商业模式决定了它没法像 CUDA 生态那样画一个闭环它必须服务整个开源世界的兼容矩阵。所以为智能体而生不只是芯片 IP 的事也是软件栈的事。开发者能不能用熟悉的框架直接编译到 aarch64能不能一条命令拉起推理引擎这些体验层面的东西最后会变成芯片公司跟不跟 Arm 走的理由。4. 在 Arm 边缘平台上跑通一个智能体我的实操记录4.1 选板子先看带宽和 SDK别只看 TOPS先交代背景我用的是一块 RK3588 平台的板子标称 6 TOPS NPU内存带宽在 51.2GB/s 左右64-bit LPDDR5板载 8GB 内存。很多朋友一听 6 TOPS 就摇头觉得太小。但拿它跑 7B INT4 模型token 速度上限算出来是 51.2 / 3.5 ≈ 14.6 token/s实际稳定在 8~10 token/s 问题不大对一个智能体链路来说已经能用了。这步选型我有三个硬指标第一内存带宽至少 40GB/s优先 LPDDR5 以上第二NPU 的 SDK 必须覆盖你要跑的模型格式和算子不能只支持自家 demo 模型第三板载内存至少 8GB因为你还要跑 Python 运行时、工具进程和 KV cache。这三个指标都过了再回头看 TOPS。TOPS 高但 SDK 封闭的板子基本上买回来就是吃灰。4.2 交叉编译与运行环境踩坑智能体框架通常依赖一堆动态库直接在板子上编译会让人崩溃——RK3588 那点 CPU 编译一个 llama.cpp 都得半小时起步。我的做法是在 x86 开发机上做交叉编译再把产物扔到板子上。基本流程# x86 开发机上安装 aarch64 交叉工具链 sudo apt update sudo apt install gcc-aarch64-linux-gnu g-aarch64-linux-gnu # 用 CMake toolchain 指定目标平台 cmake -B build \ -DCMAKE_SYSTEM_NAMELinux \ -DCMAKE_SYSTEM_PROCESSORaarch64 \ -DCMAKE_C_COMPILERaarch64-linux-gnu-gcc \ -DCMAKE_CXX_COMPILERaarch64-linux-gnu-g改完依赖后最常见的问题是 glibc 版本不匹配在开发机上链接的 glibc 如果比板子系统新跑起来就是经典的 version GLIBC_2.xx not found。我吃过几次亏之后学乖了直接用板子官方提供的镜像作为 sysroot常见的 arm 版 Debian、CentOS aarch64 镜像都可以。如果智能体调度服务里混着 Java 组件也别在 x86 上想当然老老实实拉 aarch64 版 JDK比如 JDK 11 的 arm 版本并核对板子的 glibc 版本。调试阶段可以用 QEMU user-mode或者现成的 aarch64 镜像先做冒烟测试但千万别拿模拟器数据当性能依据模拟环境的内存带宽和真机差距太大。4.3 量化的关键混合量化与 KV cache 策略模型量化是绕不开的关。我的体感是别做全 INT4 崇拜智能体链路里经常有视觉工具返回的图像 token 或数字信号这些输入侧特征张量走 FP16 更稳。权重层可以 INT4/INT8 混合KV cache 用 INT8attention 输出保持 FP16这是目前边缘端最实用的折中。量化完一定要做人工抽测用几条真实的工具调用链路验一遍光看 benchmark 分数容易被骗——量化误差在单次推理上不明显但在多轮决策时会累积模型越用越笨就是这个原因。另外提醒一个隐蔽的坑NPU SDK 升级之后之前量化好的模型经常要重新编译。像 RKNN 这类工具链驱动版本一旦从 1.x 跳到 2.x算子映射和量化策略全变整个量化管线要重跑一遍。搞过 Cortex-M 的同学应该还记得 ARM Compiler 5 老工程迁移到 AC6 的工具链版本债这种债在 NPU SDK 世界里只会更狠。所以做项目时量化脚本必须固化下来别用一锤子买卖的 Notebook。4.4 智能体框架在板端的瘦身与分层Dify、LangGraph、CrewAI 这些框架在云端跑得很开心搬上 Arm 开发板就完全不是一回事了。Python 运行时本身就吃内存框架再带一堆依赖8GB 的板子跑 7B 模型加长上下文直接就 OOM。我最后采取的办法是指挥逻辑跟推理分开推理进程常驻用 NPU 跑模型智能体调度逻辑放在另一个进程两者之间走共享内存或消息队列。这样既能绕开 Python GIL 的坑也能把内存预算控得更细。框架选型上我的优先级是裸 llama.cpp 加自写脚内存最省ExecuTorch适合 PyTorch 生态GGML 系列C/Rust 绑定适合嵌入式最后才是 Dify 这种重量级编排平台——它更适合做云端的智能体应用层而不是板端推理单元。实测下来一条语音指令 → 意图规划 → 调用视觉工具 → 生成回答的四步链路在 6 TOPS NPU 上完整跑一次体感在 5~8 秒。瓶颈基本不在 NPU而在中间结果进出共享内存的拷贝、工具进程的启动开销以及 Python 对象序列化。把这些非推理的 overhead 优化完比换一块标称 20 TOPS 的板子见效快得多。5. 抛开 TOPS我评估边缘智能体硬件的五个维度5.1 一张表看懂每 TOPS 带宽这个比值我习惯把每 TOPS 对应的内存带宽作为第一个筛选指标它代表算力会不会被饿死平台标称算力内存带宽约每 TOPS 带宽某中端 Arm 板RK35886 TOPS NPU51.2 GB/s≈8.5 GB/s某旗舰移动 SoC45 TOPS NPU68 GB/s≈1.5 GB/sJetson Orin Nano Super67 TOPS68 GB/s≈1.0 GB/s单看 TOPS旗舰 45 TOPS 吊打 RK3588但跑 7B 级别模型时低 TOPS、高带宽的 RK3588 反而不容易卡在 decode 上。智能体链路是多轮 decode 主导这个比值尤其重要。我的经验值选型先卡每 TOPS 带宽不低于 1.5GB/s再看别的。5.2 峰值 TOPS 与可持续 TOPS功耗墙下的真实水平第二个维度是可持续 TOPS。很多板子的峰值数字只能短时间跑出来NPU 全速运行时芯片发热几分钟后撞上功耗墙降频。建议拿到板子先做 30 分钟持续推理烤机记录 token 速度曲线。如果前 10 分钟稳定 13~14 token/s后面掉到 8 token/s说明散热撑不住选型时必须按后半段的数字做预算。对做移动设备或电池设备的人这个往往比峰值更影响体验。5.3 生态成熟度才是最大的隐性成本第三个维度是软件生态成熟度具体看三点算子覆盖清单有没有公开、SDK 文档与样例的更新频率、社区活跃度。算力是硬件给的好用是软件给的。一块标称 40 TOPS 的 NPU 如果算子支持不全为了跑一个 Transformer 算子你要花两周绕路那这 40 TOPS 就是负资产。还有个简便判断法把你常用的推理框架拉到目标平台交叉编译一遍看卡在哪个环节。能顺利过编译、跑得起来、算子大多能映射生态就算过关。最近各家开始公开智能体训练方法论比如 DeepSeek 放出的多步推理 工具使用训练思路很多团队顺势把这类负载做成标准评测不再拿单模型 benchmark 冒充边缘 AI 能力。我觉得这正好把行业往一个更务实的方向推大家终于开始用智能体链路测硬件了。5.4 智能体链路要求的是确定性延迟最后加一个容易被忽略的维度确定性延迟。智能体的工具调用通常有等待窗口如果某一次推理抖动 10 秒整个用户体验直接崩。边缘 NPU 的时延稳定性、驱动是否偶发卡顿都需要用长循环压测来找。我用一条五步工具链路连续压 100 轮看 P95 与 P50 的差距差距越大说明确定性越差。峰值跑得快不算本事跑得稳定才算。6. 分水岭在即开发者现在应该做的三件事今年多场行业会议上有共识2026 年会成为工业智能体从概念演示走向工程化落地的分水岭。这个判断对边缘计算从业者来说意味着能跑 demo很快就不值钱了接下来客户要的是能稳定运行几个月、断电重启不挂、延迟可控的工程化系统。我自己的建议是三件事。第一把选型基准从单模型换成智能体链路定一条五步以内的工具调用链路测全链路耗时和 P95 延迟而不是只报告某模型跑了多少 token/s。第二把 KV cache 预算写进需求文档算清上下文长度、量化精度和内存余量8GB 以下的内存真没法认真做长上下文智能体。第三优先考察软件栈兼容性llama.cpp、ExecuTorch、ONNX Runtime 在 aarch64 上是否一键可用比 TOPS 数字实在得多。最后分享一个真实体感。这些年我见过太多选型会上为 67 和 45 两个数字争得面红耳赤的场面等板子到了手跑完真实链路才发现瓶颈在内存带宽和软件适配。Arm 这波把为智能体而生摆上桌面本质上是在重新定义行业的考核标准——从你的 NPU 多能算转向你的系统能不能让智能体长时间稳定地思考。作为开发者与其纠结数字不如先把手头那条智能体链路在目标板上跑通。跑通了你就知道该买什么了。
