没有任何大模型能够孤立运转，Arm为开发者提供了一个AI Portal

作者 | 周雅

Agentic AI时代正在重新定义开发。

9月9日，在“Arm Everywhere China”大会定调了Arm全场景算力布局的次日，“Arm Create”大会把目光投向了一线的软件工程实践。面对横跨边缘AI、物理AI、云端基础设施的庞大计算体系，开发者究竟该如何把模型和代码组装成可稳定运行的应用？

Arm 开发者关系副总裁 Shantu Roy上台，抛出了一个直击痛点的产业判断：“AI应用的构建，正在从‘以模型为中心（model-centric）’转向‘以系统为中心（system-centric）’。”

究其背后原因，是在真实的生产环境里，没有任何一个大模型能够孤立运转，它必须与设备内存、数据流转、工具调用、硬件安全机制、实时任务状态深度交织，共同组成一个完整协同的工程系统。尤其是在Agent自主决策的环境下，大量行为并非事先写好的硬编码，而是在运行时根据任务环境动态衍生的。因此Shantu强调，开发者最终要交付的，是支撑AI应用运转的一整套系统。

硬件性能如果缺乏足够成熟的软件层，就如同空中楼阁，无法转化为实际体验。Shantu在现场坦言：“硬件能力只有包裹在一套易于消费的软件体系中时，其价值才真正成立。”

为此，Arm 正式推出了一站式AI和Agent开发平台：Arm AI Portal。

“我们打造AI Portal 的初衷，是为开发者提供便捷的统一入口，大幅缩短他们在模型选型、位置适配、系统编排、到真机验证全流程中的时间成本。” Shantu在会后采访中如是说。

通过与开发者并肩同行，Arm持续投入软件生态建设超过15年，参与了1800多个项目，并与12万生态合作伙伴开展协作。Shantu形容，“一个足够好的软件平台，开发者甚至不应该明显感觉到它的存在；只有底层能力缺失时，开发者才会被迫停下来重新造轮子。”

开发者必须迈过的“四个决策”

在介绍AI Portal之前，我们有必要先了解目前开发范式正在发生的变革。

Shantu将生产级 AI 系统落地前必须解决的工程链路拆成了四步：

· Model Choice（模型选择）

· Placement（算力匹配）

· System（系统编排）

· Proof（目标设备验证）

这分别对应到开发者，就意味着四个决策：选什么模型，如何让合适的任务跑在合适的算力上，如何编排模型、工具和任务，以及最终如何让它在目标设备上稳定工作。

第一步是选模型。

行业过去常陷入“大模型 vs 小模型”的二元对立，Shantu认为，这本身就是一个错误框架。真正的框架应该是，这个具体任务需要什么样的智能。

比如，“总结一条通知”和“分析六份文档并给出策略建议”，这是两个完全不同的负载，对模型能力、延迟、内存乃至运行位置的要求完全不同。更何况，一款应用也不必绑定在一个模型上，而可以针对不同任务调用不同大小、不同能力甚至不同类型的模型。所以，模型选择正在从“谁最强”变成“谁最合适”。

第二步是算力匹配。

这也是过去AI行业反复争论的问题，究竟应该把AI放在端侧，还是放在云端？

Shantu的答案同样很明确，AI应用天然是在跨越整个计算连续体，一部分任务运行在边缘，一部分运行在本地，一部分运行在云端，并不矛盾，反而会成为常态。随后Shantu用了一个区分：硬件能力决定“能不能跑”，产品架构决定“能不能在那里跑”。

如果一个任务要求即时响应、低延迟、或者涉及用户不希望上传云端的私人上下文，设备本地通常更合适；如果需要协调一个现场里的多台设备，边缘可能更合适；如果面对大模型、弹性算力、或大规模集中处理，云端仍然有优势。

他举了两个具体例子。一个是机器人：即时安全和感知可以发生在机器人本体，现场协调交给边缘，而长期学习和更重的优化则放到云端。另一个是带动作检测的摄像头：本地先完成检测，再把真正需要处理的告警和复杂任务交给云端。

此处插入Shantu在会后采访中提到的另一个视角。当被问及“如果未来不同厂商都有自己的CPU、GPU、NPU和软件生态，开发者岂不是又要针对每个平台重复优化？” Shantu认为，完全消除平台差异并不现实，仍然会有开发者需要针对多个平台做优化，但框架、库以及Agentic系统的发展，会逐渐把这一层复杂性抽象掉一部分。Arm希望AI Portal也承担类似角色，让开发者尽量不必直接面对每一种底层差异。所以Arm此次同时强调Edge AI、Cloud AI和Physical AI，并不是要把它们切成三个孤立市场，而是在强调一个计算连续体：未来一个AI应用很可能天然跨越多个计算位置。

第三步是系统协作。

模型选好了，运行位置也决定了，事情仍然没有结束。一个Agent应用还需要在多个模型、工具和服务之间维护状态、管理调用，并根据任务变化动态决定下一步做什么。Shantu把这一层归到“System”：也就是怎样让这些组件真正协同起来。

Shantu拿两个例子对照：一个 Agent 应用，要在运行时协调工具、模型推理和状态；一个游戏，要生成图形、维护玩家状态和游戏逻辑。两者的组件类似，但被编织的方式完全不同。他把这一步叫“编排”，认为编排方式直接决定应用是否真的可用。这也是Agent相比传统AI应用真正增加的一层复杂度。

第四步是目标设备验证。这是Shantu花时间最长、也认为最容易被开发者忽略的一步。他直言：“The prototype on your laptop is not your product. （在笔记本上跑通的原型，不等于最终产品）”。

这是AI开发今天一个很容易制造错觉的地方。模型可以在开发环境里表现很好，但一旦进入真实设备，马上会面对内存、功耗、温度和电池续航等限制。比如游戏，某个Demo可以短时间跑到60帧，但如果设备进入热平衡之后开始降频，那么这个数字并不能代表用户真正玩半小时之后的体验。云端同样如此，本地模拟出来的工作负载，也不等于真实云环境里的流量和负载变化。

所以Shantu强调，开发者最后必须把应用放到真正的目标设备和目标系统上反复验证，并形成运行、测量、发现问题、优化，再运行的闭环。这也让他对传统Benchmark提出了一个很直接的判断：“Benchmark告诉你一个组件能做到什么，Production才告诉你整个系统能不能工作。”

Shantu反复强调：开发者不应该在这四个决策之间反复切换，Arm 想做的事情是降低这四步的复杂性。

AI Portal：全栈算力能力的开箱封装

为了避免开发者在这四个决策环节中频繁受阻，Arm AI Portal应运而生。

Arm AI Portal本质上是一个面向开发者和智能体的AI开发平台，把经过Arm优化的模型、性能数据、开发工具和部署资源集中到一个入口里。开发者可以直接查找针对不同任务优化过的模型，查看性能和准确率数据，并获取代码示例与部署流程；未来还可以导入自己的模型，在Arm平台上进行分析和优化。

目前，AI Portal覆盖语言、语音、视觉和神经图形等多类AI工作负载，首批预优化模型包括通义千问、Google Gemma和Ultralytics YOLO，并支持ExecuTorch、LiteRT、ONNX Runtime等主流运行时。经过Arm优化的模型也可以通过Hugging Face获取。

Shantu在会后采访中进一步解释AI Portal的初衷。“我们正在努力做的，是压缩开发者决定‘将哪种模型部署在哪个层级’时的试错周期与评估决策时间。” Shantu判断，“在实际应用中，不同任务往往需要不同模型，开发者需要花费大量时间判断模型如何选择、部署在哪里，以及如何针对目标硬件优化。AI Portal希望通过预先优化过的模型和性能数据，把这部分工作尽量提前做好。”

现场，Shantu也给出了几个具体例子。比如，Qwen3-TTS在vivo X300上经过量化，并利用SME2加速后，相比FP32版本性能提升超过4倍；Ultralytics YOLO26在同一台手机上切换到FP16后，性能提升超过40%。在Raspberry Pi 5上，YOLO26通过NEON配合FP16和INT8混合量化，相比FP32也获得了超过40%的提升。

不过，AI Portal并不是一套孤立的软件服务，它背后连接的是Arm近年来逐步补齐的一整套开发者能力。

譬如SME2，它让支持这一指令扩展的CPU更高效处理AI中常见的矩阵计算，一些任务因此可以直接在CPU上完成，减少数据在不同计算单元之间来回搬运，更适合对响应速度和本地数据处理要求较高的端侧AI场景。还有Mali G2-Ultra NX，把专用神经网络加速器集成进GPU，用于神经超级采样 NSS、神经帧率提升 NFRU和神经超级采样与降噪 NSSD等神经图形任务。Device Connect解决的是不同设备之间如何连接和协作的问题，让机器人、传感器、摄像头等不同设备更容易彼此发现和交换信息，也方便AI Agent调用这些设备。Arm Performix则负责分析应用真正跑起来之后的性能，帮助开发者找到瓶颈，再进一步优化。

Shantu在采访中花了一些篇幅介绍AI Portal与另一个容易混淆的项目：KleidiAI。

KleidiAI是Arm推出的一套开源AI加速软件库，作用是让AI模型在Arm CPU上跑得更快。它已经被接入PyTorch、ONNX Runtime、Google MediaPipe、阿里MNN等主流AI框架，通过把Neon、SVE2、SME/SME2等CPU底层能力封装成经过优化的微内核，让框架能够直接调用这些计算能力。对于应用开发者来说，只要使用已经集成KleidiAI的框架，就能获得相应的性能优化，无需自己再针对CPU底层指令做大量适配。

比如微软将KleidiAI集成进ONNX Runtime后，在Android旗舰手机上运行Phi-3 Mini时，提示词处理速度最高提升到原来的2.6倍；在Windows on Arm平台上，同一模型的提示词处理速度提升2.4倍，Token生成性能提升约12%。在阿里MNN中，KleidiAI针对多模态模型Qwen2-VL 2B进行了优化，prefill阶段性能提升57%，decode阶段提升28%。Google MediaPipe也已经通过XNNPACK接入KleidiAI，使Gemma等模型能够直接利用Arm CPU的底层加速能力。

谈及AI Portal和KleidiAI的关系，Shantu解释说，“可以把 KleidiAI理解为底层的一项优化能力；而 AI Portal 则是整合AI与智能体系统的一站式平台，为开发者交付一套端到端的完整体验。”简单来说，KleidiAI负责把Arm底层算力“用好”，AI Portal负责让开发者更容易“找到并用上”这些能力。

AI Portal所面向的群体，除了人类开发者之外还有另一类全新使用者：AI Agent。

伴随行业迈入“AI 协助编写代码”的阶段，Arm 正在通过 MCP（Model Context Protocol）协议，将 AI Portal 沉淀的模型库、接口文档与微架构优化指南直接注入 Claude Code、Codex 以及 GitHub Copilot 等自动化开发环境中。

这意味着，过去专门写给人类开发者研读的架构手册，如今能够被编程 Agent 原生理解与直接调用。换言之，Arm 的开发工具链正在被重构：既要让人类开发者在 Arm 平台上得心应手，也要让自动化 Agent 毫无阻碍地调动全栈算力。

为进一步贴合中国本土开发者，Arm 在现场宣布与火山引擎达成合作，依托火山引擎 Sandbox 沙箱环境为国内开发者提供 Arm 后端算力的免部署 API 体验通道，进一步拉近底层芯片与应用创新的距离。此外，AI Portal 将在 Hugging Face推出，很快也将在阿里“魔搭社区”上线。

从芯片IP公司走向统一计算底座的必然演进

从传统认知中的底层 IP 授权商，到如今全方位下沉至云端、边缘及物理AI场景，Arm 频频在软件平台与工具链上重注发力，这是否意味着其正在背离原有的商业基底？

Shantu对此给出了克制且切中本质的回应：“Arm业务边界的延伸，根本驱动力在于客户需求的升级。”无论终端品牌、ODM 厂商还是算法团队，都在要求与 Arm 展开深入的全链路协同。Arm 在继续提供IP产品的基础上，提供了计算子系统、芯片等更多的产品组合，而在其之上叠加平台化软件与生产级工具，为企业提供更灵活的选择空间。

这一逻辑补齐了Arm开发者生态叙事的最后一环：不仅要保持硬件层面的广泛覆盖，更要将这种“硬件兼容性”升维为跨场景的“开发连续性”。

尽管云端、边缘和物理AI的载体形态各异，承载的模型与功耗约束也各不相同，但只要开发者能够遵循相似的决策框架、工具和开发路径，他们就不必为了每一次硬件迁移而从零开始。

Shantu将这场变革归结为极其纯粹的词：“Less Friction”（更少摩擦）。减少开发者从源码走到真实产品之间的路径，也是这场Arm Create最完整的一条线。

这种路径优化也在向教育与学术土壤延展。Shantu在采访中透露，其团队正规划将欧美成熟的高校科研合作与开源共建模式引入国内，进一步加深与中国大学和开源社区的连接。在他看来，尽管技术生态日新月异，全球开发者的终极目标始终高度一致，那就是以最快的速度交付高可靠、高质量的实际应用。

而 Arm 所做的，就是更深入参与本地开发者社区，为每一个穿行在代码与物理世界之间的开发者，铺平通往生产级系统的坦途。