这两年做AI推理和边缘计算的人应该都明显感觉到一个趋势x86和NVIDIA组合不再是唯一答案。尤其在端侧、边缘侧以及一些特定云场景里能效比和总拥有成本TCO成为更关键的决策因素。本周Arm发布了新一代AI原生计算平台并且专门强调了与中国生态的协同这个消息在我看来的分量比单纯发几颗CPU核心要重得多。这篇文章不打算复述发布会参数而是想从从业者的角度把这个平台到底意味着什么、对做AI系统的人有什么实际影响、以及开发者上手时该关注哪些细节一次讲透。先说结论Arm这次做的事情本质上是把“AI加速能力”从外挂式的独立NPU变成了计算平台的原生属性并且为了支撑这个属性把软件栈、工具链、IP组合全部重新捋了一遍。这件事对你手头的项目有没有影响取决于你是在做芯片选型、系统迁移还是在做具体的模型部署——下面我会分场景拆开讲。1. AI原生计算平台到底在革谁的命先捋清楚概念1.1 “AI原生”不是营销词而是硬件设计逻辑的转向别听到“原生”就觉得是PPT话术。过去几年我们做嵌入式AI最常见的方案是主CPU加一颗独立NPU再外挂DDR跑模型时数据在CPU、NPU、内存之间来回倒腾。这种做法的问题在于数据搬运的功耗和延迟往往比计算本身还高。所谓AI原生本质上是把这个搬运过程尽量消灭掉。Arm这次提的AI原生计算平台我理解有几个层面的含义。第一是异构计算单元之间不再是“拼装”关系而是共享统一的内存一致性和调度框架CPU、GPU、NPU可以在同一个数据视图下协同工作第二是AI能力成为安全域、虚拟化、系统管理的基础能力而不是后加的功能模块第三是软件接口的统一化开发者不用再为不同IP单独适配推理框架。其中最容易忽略的是统一软件接口这件事。之前我们做过一个项目NPU用一套自定义算子接口GPU是OpenCLCPU上又是另一套NEON优化代码同一个模型要写三份预处理逻辑。这种割裂感在AI原生的框架下应该被大幅收敛。1.2 从“能跑AI”到“为AI设计”与生态的合作逻辑再看与中国生态携手这块。我注意到这次发布里特别强调了与本地伙伴的合作涵盖从芯片设计到模型适配再到行业解决方案的落地。这个逻辑其实很好理解AI原生平台要想真正落地不能只靠Arm自己。边缘侧有大量的国产SoC厂商在用Arm IP做定制芯片云端有基于Arm架构的服务器方案但这些芯片要真正发挥AI能力需要模型供应商、框架团队、行业ISV一起把工具链打磨顺。Arm在中国的生态合作本质上是在做“最后一公里”的适配工作。对我们做系统的人来说这意味着后续选择Arm平台时“中文文档、本地技术支持、已经适配好的模型仓库”这些东西会越来越齐全不用再像几年前那样碰到问题翻遍英文社区也找不到答案。2. 平台技术底座解析CPU、NPU与软件工具链2.1 新一代CPU核心的IPC提升与AI能力的下沉这次发布中C1-Ultra这颗面向云和数据中心的CPU值得单独关注。很多人看到“云CPU”首先问的是和x86比性能怎么样这里我建议大家换个角度去看。从工程角度说C1-Ultra这种设计主打的是高能效密度和AI工作负载的混合部署。在云数据中心里真正的瓶颈往往不是单核峰值性能而是单位功耗下能跑的并发任务数。Arm架构在这个维度上的优势是结构性的核多了、功耗分摊下来了、内存带宽利用率反而上去了。另外一个容易忽略的点是IPC。熟悉CPU架构的都知道IPC每时钟周期指令数是衡量核心微架构效率的关键指标。Arm这几年几乎每一代新核心都在稳步提升IPC这意味着在不拉高主频的前提下单线程性能也在逐步逼近甚至反超一些传统架构。对AI推理场景来说IPC提升带来的好处是把很多小算子直接从NPU卸载到CPU上执行时你不会觉得性能缩水严重。2.2 为什么说Arm已经在用“平台”逻辑做AI了Arm这次强调计算平台而不是单纯推某个AI加速IP这个转变很关键。以前Arm的AI布局更多体现在Ethos系列NPU上那是作为一个IP选项存在的客户可以选也可以不选。但现在把AI能力从IP层面上升到平台层面意味着什么意味着从内核线程调度、虚拟化隔离、安全启动链到存储控制器、总线互连设计所有模块都以“高效跑AI算子”为设计出发点。举个例子当你在跑Transformer模型时内存访问模式是高度非线性的这非常考验总线和缓存的一致性设计。传统CPU架构在这种访存模式下会有大量缓存未命中导致加速单元空转。平台级设计会把Cache策略、预取策略和NPU的DMA路径统一考虑实测下来这类模型推理的能效比可以提升一倍以上。2.3 软件工具链与“新手友好”之间的平衡聊完硬件聊聊工具链。Arm的软件栈这些年演变很大从早期的RDSArm Development Studio到现在面向AI的Arm NN、TFLite Delegates、以及Kleidi库之类的中间层目标只有一个让开发者在不同的Arm Rom上跑模型时不用重写代码。尤其值得关注的是中间表示层的策略。Arm提供了一套算子的映射框架模型进来以后先被翻译成中间表示再针对当前平台的CPU特性比如SVE2向量指令还是NEON和后端的NPU做分发。但这里也要说句公道话Arm这块工具链目前的上手成本相比成熟的CUDA生态还是有差距的。尤其遇到自定义算子的情况你可能得自己写逐算子适配。好消息是社区在快速补齐很多常见模型如YOLO系列、Transformer系列已经有了开箱即用的demo。3. 中国生态落地的实际路径从芯片到应用层3.1 Arm平台在中国市场的现状不只是嵌入式提到Arm和中国的联系很多人的第一反应是手机芯片或者MCU。但这两年情况变了。在服务器和云市场Arm架构的份额在稳步增长很大一部分原因是AI推理负载的推动。你在国内云厂商的控制台里已经能看到基于Arm架构的云服务器实例。这些实例的性价比在CPU推理场景下很能打。我拿一个实际测试结果做对比跑一次ResNet-50的在线推理服务Arm实例在保证同样P99延迟的前提下单位成本通常能做到x86方案的一半左右。再者中国市场上做Arm架构定制芯片的公司数量非常多从端侧到数据中心都有覆盖。这为Arm平台的AI能力落地提供了最好的土壤——芯片种类多、应用场景多、愿意踩坑的工程师也足够多。3.2 为什么说生态适配是当下最关键的战役芯片做出来了模型跑不通这是Arm架构在AI时代最容易被人诟病的地方。好在Arm自己也明白这一点。这次强调与中国生态的协同我认为核心是在解决几类问题GCC对ARMv9架构新指令的优化不够激进TensorFlow/PyTorch等主流框架在Arm CPU上的默认算子内核性能不佳以及异构设备的内存统一管理尚未标准化。Arm的解决思路是提供一个参考软件栈同时跟中国的硬件合作伙伴、云厂商、独立软件开发商ISV一起完善代码。比如针对算子库的优化KleidiAI这类库就是直接对标AVX-512版本基础算子库的存在专门为Arm CPU重写一遍矩阵乘法和卷积运算。单看这些基础算子的优化里边的SIMD指令调度细节密密麻麻优化的空间比很多人想象中大得多。4. 开发者实操视角用Arm平台跑AI项目的真实体验4.1 环境准备硬件选型、SDK安装和系统部署我在自己的项目里尝试过在Arm平台上部署AI推理服务走的是一套比较典型的路径。硬件选择了基于Ampere架构的Arm服务器厂商比较多阿里、亚马逊都有对应产品线系统装的是CentOS 7的Arm64版本。这里有个小细节网上有很多针对x86的教程实际部署时你会发现依赖包全要换Arm64架构的镜像源否则交叉编译会出一堆问题。SDK方面我使用的是Arm开发的工具链包括编译器、调试器等。安装过程不复杂但有个坑是环境变量要配好尤其是编译器默认搜索路径不然编译时找不到头文件。如果你是做嵌入式方向的Arm Development Studio带来的Trace和调试功能更推荐能直接看代码在CPU流水线里是怎么跑的对排查性能问题帮助很大。4.2 一个简单的AI推理部署示例下面是一个更贴近大众开发者的实践过程用Python在Arm平台上部署一个PyTorch模型推理服务初始化部分我的习惯是先调整CPU的调度策略把性能核与能效核分开。比如引脚绑到性能核上中断尽量分散到能效核这个小动作能让推理延迟波动下降不少。import os import torch import torch.nn as nn import numpy as np os.environ[OMP_NUM_THREADS] 8 os.environ[KMP_AFFINITY] granularityfine,compact,1,0 import psutil def pin_to_performance_cores(): # 获取所有逻辑核前N个为性能核 # 具体编号因处理器而异 p psutil.Process() p.cpu_affinity([0, 1, 2, 3, 4, 5, 6, 7]) # 一个简单的2D卷积模型 class SimpleModel(nn.Module): def __init__(self): super().__init__() self.conv1 nn.Conv2d(3, 32, 3, padding1) self.relu nn.ReLU() self.pool nn.AdaptiveAvgPool2d((1, 1)) self.fc nn.Linear(32, 10) def forward(self, x): x self.relu(self.conv1(x)) x self.pool(x) x torch.flatten(x, 1) x self.fc(x) return x if __name__ __main__: model SimpleModel() model.eval() dummy torch.randn(1, 3, 224, 224) with torch.no_grad(): for _ in range(5): y model(dummy) print(inference output shape:, y.shape)直接用CPU跑虽然简单但你会发现Arm CPU上PyTorch默认并不一定启用了最优的算子实现。这时候需要打开Torch的Inductor后端import torch model SimpleModel() model.eval() compiled_model torch.compile(model, backendinductor) compiled_model(torch.randn(1, 3, 224, 224)) # 第一次运行会触发JIT编译后续调用速度会显著提升一个比较耗时的核心环节是调整数据加载的Pipeline。在Arm平台上如果把数据增强、解码和归一化全部放在主线程里耗时占比可能达到总推理时长的40%以上。解决办法是多进程预处理CPU核数够多完全可以让一个核负责摄像头取流另外四个核负责预处理剩下八个核跑推理。4.3 性能瓶颈分析最值得优化的三个维度跑通了不等于跑得好。在Arm平台上做性能调优我最看重的三个维度分别是内存带宽、线程调度和指令集利用。内存带宽在Arm服务器上很容易被忽略因为CPU的计算指标太好看了但大批量模型推理特别吃内存带宽带宽不够的时候核心使用率上不去整体吞吐上不来。线程调度的问题前面说过可以用taskset或numactl手动绑核。如果平台支持持续性能控制器可以顺便把能效核处理中断、性能核处理计算任务这种分工固定下来。指令集利用就要看代码编译时有没有启用ARMv9对应的SVE2向量指令了。默认编译选项通常比较保守只开NEONSVE2带来自动向量化的收益就享受不到。用GCC编译时加上-mcpuneoverse-v3 -O3 -marcharmv9-asve2这个参数矩阵乘法的内核运算能拉上来接近一倍的性能。g -mcpuneoverse-v3 -O3 -marcharmv9-asve2 -o app app.cpp5. 干活常见问题避坑指南5.1 编译阶段最扎心的三个坑Arm工具链版本多很多人第一次用Arm编译器时都会在版本选择上翻车。这里我总结了一下常见问题。实测中老项目迁移到新平台最常报的是error: std::char_traitschar 未定义这类C标准库相关错误多是因为编译器默认C标准太老。加上-stdc17一般能解决。有些时候是老编译器对ARMv9的新指令支持不完整这时候换用新版GCC或者Arm编译器新版就好。另一个高频问题是交叉编译时头文件抓取不到目标平台的系统头文件这个要检查交叉工具链安装路径里的sysroot是否会传给GCC如果没传编译时会默认抓宿主机的/usr/include。之前遇到过一个排查了很久的问题程序在x86平台跑正常换到Arm上处理浮点计算时结果总是差点意思。查了很久才发现是编译时缺了-lm参数Arm平台上不链接数学库不影响编译但数学函数的精度和性能都会受影响。5.2 运行阶段性能问题的三个排查方法跑起来之后如果性能不符合预期我的经验是先不要急着改代码而是按顺序跑三个排查动作。先确认CPU频率。查看系统最高频率和当前频率如果两者差距较大可能是功耗策略在捣鬼。使用性能模式的调速器之后运行效果改变会很明显。再看缓存亲和性。使用perf统计缓存未命中率如果能观察到异常高的L2缓存未命中大概率是数据布局不合理或者核心调度太散导致缓存被冲掉。这个场景下给线程设定CPU亲和性是最有效的解法。最后看内存带宽。使用stream等基准工具测一下当前平台的实际带宽如果在推理过程中观察到带宽已接近上限那就只能下调batch size或者考虑换更高带宽的内存。Arm服务器普遍八通道起步理论带宽很充裕但多实例并发时会争抢内存控制器资源这个要提前预估。6. 一些后续可以持续关注的方向这次Arm发布的新一代AI原生计算平台给我的整体感受是方向终于对了。不再是为了单一跑分而堆硬件而是花了很多功夫在“怎么让AI应用在异构环境里顺畅跑起来”这个最实际的问题上。对我们开发者和系统架构师来说我个人的建议是不用急着把现有所有业务都迁移到Arm平台但值得在非核心链路、成本敏感的场景里先做小规模验证。尤其是一些长期运行的在线推理任务换成Arm平台后电费和硬件采购成本上的节省是非常可观的。另外想说一下工具链。我实际用下来Arm官方工具链和GCC在AI计算库上的兼容性已经很好了但第三方依赖还是会有一些小坑。建议做几个基础镜像把常用的SDK和依赖提前封装好方便开发人员基于镜像快速验证。这点在逻辑上跟Docker的跨平台迁移策略很像基础镜像锁定好了后面的事情会顺畅很多。最后再分享一个经验即便同一个平台云上实例和本地板卡的性能表现往往差很多做容量规划时建议用实测数据不要直接用云厂商标称的算力值。把Arm平台当做一个长期存在、并且会持续演进的计算选择来研究从长远看绝对是值得的花时间。
