Arm发了个“挑模型神器”，针对硬件优化，能直观对比延迟和内存占用

智东西

作者 | ZeR0

编辑 | 漠影

智东西9月9日报道，今日，在Arm Create开发者大会上，Arm推出Arm AI Portal，提供针对Arm优化的模型、代码、工作流和学习路径，让开发者与智能体都能便捷地在Arm计算平台范围内完成AI软件的发现、优化及部署。

无论是构建游戏、普通应用、智能体还是其他AI系统，开发者都能从中获得具体指导和可直接使用的开发资源。

开发者可以查找面向特定任务的预优化模型，获取性能与准确率数据，对比延迟、内存占用和模型规模，并访问代码示例及部署工作流。

这些数据能帮助开发者更快判断应该使用哪一种模型及对应的模型表现。

首批预优化模型包括阿里巴巴通义千问、谷歌Gemma、Ultralytics YOLO，支持的runtimes涵盖ExecuTorch、LiteRT、ONNX-RT。生态合作伙伴包括阿里巴巴、树莓派及Ultralytics。

经Arm优化的模型已实现显著性能提升：

采用单线程执行与混合量化配置，搭载Q8_0 talker与code predictor组合方案，Qwen3-TTS在vivo X300手机上通过第二代Arm可伸缩矩阵扩展（SME2）的加速，实现了超过4倍的速度提升。

Ultralytics YOLO26在vivo X300手机上依托SME2技术，单线程FP16相较FP32实现超40%性能提升；在树莓派5平台依托NEON技术，采用FP16与INT8混合量化方案，相比FP32同样实现超40%的性能提升。

AI Portal现已正式上线。面向智能体AI的资源已开放预先体验，正式版本将于后续推出。

后续，Arm AI Portal计划提供相关工具，支持开发者导入包括专有模型在内的自有模型，并在Arm平台上开展性能分析与优化。

Arm还在与火山引擎等合作伙伴合作，推动基于Arm AGI CPU的智能体沙箱。沙箱可以为智能体提供安全、隔离且能够弹性扩展的执行环境。

Arm开发者关系副总裁Shantu Roy建议开发者在构建AI应用重点考虑4项决策：

为每项任务选择合适的模型。

根据延迟、隐私、规模和成本确定计算位置。

把模型、工具、数据、状态和运行时编排成完整系统。

在真实目标设备和生产环境中验证应用。

只有将先进技术正确组合起来，并在真实目标设备上测试验证其性能和用户体验，才能让用户真正感受到它们的价值。

一、Arm AI Portal：各种预优化模型按需选，可对比延迟、内存占用等数据

Shantu Roy谈道，Arm长期参与中国技术生态的发展。中国企业和开发者正在快速推动AI从研究进入实际应用。

在模型领域，有阿里巴巴通义千问等模型；在云计算领域，有阿里云、火山引擎等云平台；在终端设备领域，vivo、OPPO等厂商正在推进端侧AI；在物理AI领域，中国的机器人产业飞速发展。

这些市场看起来截然不同，但开发者面对的底层问题高度一致：如何选择模型，如何决定计算任务的部署位置，如何把不同的软件和硬件组合成系统，以及如何验证产品在真实设备上的表现？

Arm能够做的，是把这些能力组织在一套共同平台之上，降低开发者采用技术和构建应用的摩擦。

Arm AI Portal覆盖云AI、边缘AI和物理AI领域的Arm计算平台，可帮助开发者快速定位适配目标场景的优化模型，提高开发速度，缩短寻找模型、测试性能和研究硬件特性的时间。

该平台将SVE、SME及神经网络加速能力等Arm技术，与优化软件生态连接起来，把针对Arm优化的模型、软件工具、性能数据、示例代码和部署工作流集中在一起。

以第二代移动终端计算子系统（Arm CSS for Mobile 2）为例，其模型可借助SME2和集成神经加速器的GPU实现加速，并可通过AI Portal获得支持。

面向基于Arm架构的计算平台，Arm AI Portal支持语言、语音、视觉及神经图形等多类AI工作负载，可提供针对特定Arm硬件完成优化的模型，并给出相应的性能和精度信息。

无论是机器人视觉模型、智能手机端的生成式AI，还是运行于云CPU的任务专属大语言模型，开发者均可通过该平台获取。

Arm模型、工具及技术资源，也需要能够被智能体理解和调用。

Arm AI Portal适配开发者与智能体的现有开发环境，经Arm优化的模型可通过Hugging Face获取，Portal相关资源则可通过模型上下文协议（MCP）供编程智能体访问，使智能体了解应该怎样使用Arm特定技术。

无论开发者使用哪种IDE或者编程智能体，都能在现有工作流程中访问Arm的模型、工具和优化知识。

应用构建完成之后，开发者还需要了解它在真实运行环境中的性能表现。

Arm Performix是一个性能分析工具包，可在应用运行时采集性能数据，识别代码热点以及CPU、缓存、内存带宽和资源利用率等方面的瓶颈。

它相当于为开发者提供一个观察应用运行状态的窗口，帮助开发者找到性能损失发生在哪里，并确定应该优先优化哪些部分。

Performix能接入自动化和智能体开发流程，让AI编程助手直接读取性能分析结果，并结合代码提出优化建议。

二、只有软件足够成熟，硬件才能真正发挥价值

开发者使用一项硬件技术时，高度依赖其背后的软件、工具、框架和社区支持。

过去15年，Arm持续参与软件生态建设。Arm积极向超过1800个开源项目贡献代码，并与约12万家合作伙伴共同建设软硬件生态。

一个成熟的平台，往往会让底层软件变得近乎“不可见”。开发者不必时刻意识到它的存在，就能顺利使用相关能力。

Arm对开源项目和上游社区的投入，可减少企业维护软件分支以及从头重复开发的工作。

Shantu Roy说，Arm的目标是让开发者把更多时间用于应用创新，最终以尽可能短的路径，把源代码转化为真正运行在生产环境中的工作负载。

昨日，在Arm Everywhere China大会上，Arm发布多项新成果。

在边缘和移动计算方面，Arm发布了CSS for Mobile 2，其中包括新的C2 CPU集群，以及集成专用神经网络加速器的Mali G2-Ultra NX GPU。这意味着，开发者不仅可以在边缘设备上运行AI，也可以把AI用于图形渲染，在设备端实现AI原生图形体验。

在云计算方面，Arm发布了新一代Neoverse CSS N4，并披露Arm AGI CPU生态合作新进展。这些产品为云基础设施提供了更高的能效和计算密度，用于应对越来越多样化的智能体AI工作负载。

在物理AI方面，Arm把全面设计生态项目（Total Design）生态扩展到物理AI领域，并联合生态伙伴发展机器人能力框架，希望构建一套共同语言，让行业能够更清楚地描述机器人的能力、行为、输出以及系统要求。

这些技术并非彼此独立，它们共同构成了一套贯穿云端、边缘设备和物理世界的计算平台。开发者可以在这套平台上构建跨越不同计算位置的完整应用。

对于开发者来说，这套共同平台意味着可以让AI更接近用户。

面对要求低延迟和隐私保护的应用，开发者可以利用SME2以及GPU端的神经网络加速能力，在设备上运行部分AI任务，减少数据传输，改善响应速度，并保留用户的私有上下文。

进入物理AI领域后，开发者需将云端推理能力与真实设备连接起来。机器人、摄像头和各种智能设备，需要同时利用本地计算、边缘节点和云计算。

在云端，开发者则需要高效运行和优化大规模智能体工作负载。Arm Performix等工具可以识别应用的性能热点，帮助开发者提升云端工作负载的速度和效率。

因此，Shantu Roy认为，不应该把云端、边缘和物理AI理解成三个彼此分离的领域。

它们是一条计算连续体。一个应用可以同时利用云边端的能力，并共享底层架构、软件生态、性能优化方法和开发文档。

以手机上的个人助手为例，为了保护隐私，用户的个人上下文可以保留在设备上，语音、图像等交互也可以优先在本地处理，以降低延迟；当任务需要更复杂的推理时，应用可将部分工作转移到云端的大型推理模型。

所以，一项硬件能力只有在软件足够成熟、开发者能方便使用时，才真正具有价值。

三、构建系统需要4类核心决策：从模型选择到生产验证

我们正在从以模型为中心的世界，转向以智能体系统为中心的世界。

一套真正用于生产环境的AI系统，通常同时包含模型、记忆、工具、数据访问、隐私与安全机制、运行时环境等多个组成部分。

在智能体应用中，系统属性更加明显，因为很多决策需要由智能体在运行过程中动态完成。因此，开发者最终交付的不是一个孤立的模型，而是一套作为完整应用运行的系统。

构建这类系统时，开发者通常需要处理4类核心决策：模型选择、计算位置、系统集成与编排、生产验证。

1、模型选择

模型选择不应该被简化成“小模型和大模型谁更好”。更合理的做法，是先确定需要完成的任务，再分析任务需要哪些能力，以及运行环境有哪些限制。

开发者需要判断：这项任务是否应该使用小模型？是否需要高度专业化的模型？是否需要把多个模型组合在一起？

真实应用通常会同时使用多个模型。开发者应该先分解任务，再为每一项任务选择合适的模型。

例如，“总结手机上的一条通知”和“分析六份文件并提出战略建议”，是两种完全不同的任务，前者可以由端侧小模型快速完成，后者可能需要更大的推理模型、更长的上下文和更多计算资源。

如果模型需要运行在手机等设备上，还必须考虑内存、功耗和散热等限制。模型选择必须与目标设备和用户体验一起考虑。

2、计算位置

明确需要完成什么任务之后，下一个问题是：这些工作应该在哪里运行？

关键问题不是“选择本地还是云端”，而是每种计算位置能够为应用带来什么价值，以及怎样把这些能力组合。

AI应用通常会同时使用多种计算资源。硬件能力决定一项任务能够在哪里运行，而产品架构决定它应该在哪里运行。这两者需要结合起来。

设备端更适合运行要求立即响应、极低延迟、隐私保护、访问本地数据的任务，边缘端更适合运行需要在同一场所协调多台设备的任务，云端更适合承载需要弹性扩展、大模型或大规模计算资源的任务。

一项应用把工作拆分到多个位置，是正常且常见的系统架构。

对于一支机器人集群，与安全和环境感知直接相关的任务需在机器人本体上完成，多台机器人之间的协调可以放在边缘节点执行，训练、长期学习以及整个机器人集群的优化则可以放在云端完成。

一台配备视觉语言模型的摄像头，可以在本地完成运动检测和初步识别；摄像头随后可以把警报、通知或者需要进一步分析的任务上传到云端。

通过这种分工，开发者能同时获得本地响应速度和云端算力。

3、系统集成与编排

在一款智能体应用中，开发者需选择模型和推理方式，但应用能否正常工作，还取决于运行时能否协调工具、技能和数据，并持续维护状态。

模型、工具、数据、状态和运行时之间的编排，会直接影响应用怎样运行，也会决定用户最终获得怎样的体验。

以游戏为例，一款AI原生游戏可能同时包含生成式图形、玩家状态和游戏逻辑。这些组件需要由同一套运行系统进行协调。

4、生产验证

最后一个问题是：这套应用能否在真实产品上正常运行？

开发者需要证明，在笔记本电脑或者模拟环境中构建的应用，能够在目标设备和目标系统上达到预期效果。

笔记本电脑上的原型不是最终产品。应用进入生产环境之前，必须在目标设备上进行测试，并根据设备返回的实际数据反复测量、分析和优化。

在移动设备上，一个模型单独测试时可能表现很好，但进入手机之后，它会受到内存容量、散热和电池续航的限制。因此，只在原型环境中测试是不够的，开发者必须把模型放到目标手机上运行。

在云端，开发者可以通过批处理模拟云工作负载，但真实云流量通常具有并发、突发和持续变化等特征，只在简化的模拟负载下得到的结果，不一定能够反映应用进入真实云环境后的表现。

在玩游戏时，一款游戏可能在30秒测试窗口内保持每秒60帧，但如果设备升温之后出现降频，帧率就可能下降。这意味着系统可以完成短期演示，却未必具备可持续运行能力。

因此，单个基准测试只能说明单个组件理论上能够做什么，生产环境测试才能说明整套系统是否真正有效。

结语：长期投入跨端软件优化，帮开发者改善最终用户体验

Shantu Roy总结说，Arm平台的基础能力包括三个方面：

1、开发者可针对Arm架构进行优化，部署范围可从云端延伸到边缘设备。

2、强调每瓦性能。无论端侧还是云端，AI工作负载都受到散热、能耗和经济成本的约束，因此性能不能脱离功耗和系统成本单独讨论。

3、拥有超过2200万名开发者。庞大的开发者和合作伙伴生态，可以推动更多软件、模型和工具在整个平台上得到优化。

该公司长期投入底层软件优化，目的始终是帮助开发者更快构建应用。

一套系统可能使用了最好的模型、运行时和硬件，但只要存在严重延迟、网络异常、模型错误或者不稳定行为，最终用户体验就会受到影响。

Arm希望建立一层贯穿整个计算平台的软件与优化能力，使开发者在平台一端获得的性能优化和开发经验，可以随着应用延伸到其他Arm平台。