过去两年，AI 应用开发的重心正在发生变化。
最早一轮生成式 AI 热潮中，开发者关心的是模型能力本身：模型能不能理解指令，能不能生成文本、图像、代码，能不能在某一类任务上达到可用水平。
但随着 AI 应用开始进入手机、PC、汽车、机器人、IoT 设备和企业云环境，问题很快变得更具体：模型选哪一个？部署在云端还是端侧？延迟、内存、功耗能否接受？同一个应用跨不同硬件平台运行时，要不要重新优化？当开发流程开始被 Coding Agent、自动化工具和智能体工作流接管时，这些问题又如何被机器自动发现和调用？
Arm 最新推出的 Arm AI Portal，正是试图回答这类问题。
在 Arm Create 开发者大会上海站期间，Arm 正式发布 Arm AI Portal。按照 Arm 的定义，这是一个面向开发者和智能体的统一入口，帮助其在 Arm 计算平台上发现、优化和部署 AI 软件，覆盖云、边缘和物理 AI 场景。
Arm 开发者关系副总裁 Shantu Roy 在媒体沟通会上表示，Arm 打造 AI Portal 的核心目标，是降低开发者在 Arm 平台上开发和部署 AI 应用的门槛，减少他们在模型选择、目标平台选择、部署方式和模型优化上投入的时间。
“我们的主要目标是加快开发者的工作流程，减少其研究不同模型及目标部署平台所需的时间。”Shantu Roy 表示，目前相关资源已通过 Hugging Face 和 developer.arm.com 提供，后续也将登陆魔搭社区 ModelScope。
AI 应用开发进入“多平台、多模型、多运行时”阶段
Arm AI Portal 的出现，与 AI 应用开发复杂度上升有关。
在云端大模型时代，开发者更多通过 API 调用能力，硬件差异被云服务商和模型厂商隐藏在后面。但当 AI 应用向边缘侧和物理世界延伸后，开发者必须重新面对硬件约束。
一个语音应用可能需要在手机端实时运行，一个视觉模型可能要部署在树莓派、机器人或工业设备上，一个企业应用可能既调用云端大模型，也需要在本地设备上处理隐私数据。不同场景对应的计算资源、内存条件、功耗预算和延迟要求都不一样，很难再用一个模型覆盖所有环境。
Shantu Roy 在采访中也提到，认为单一模型能够适用于从云端到边缘端所有环境，这种看法并不完全准确。不同任务往往需要不同模型，开发者需要判断哪种模型适合部署在哪个位置。
这也是 Arm AI Portal 的切入点。它并不是单纯提供一个模型列表，而是试图把模型、运行时、性能数据、代码示例和部署工作流组织起来，让开发者更快判断一个模型是否适合自己的目标设备。
Arm 表示，AI Portal 首批支持语言、语音、视觉和神经图形等 AI 工作负载，预优化模型包括阿里巴巴通义千问、Google Gemma 和 Ultralytics YOLO，支持的运行时包括 ExecuTorch、LiteRT 和 ONNX Runtime。生态合作伙伴包括阿里巴巴、树莓派和 Ultralytics。
这意味着，Arm AI Portal 更像是 Arm 面向 AI 时代的软件生态入口，而不是单一开发工具。
从 KleidiAI 到 AI Portal：Arm 想解决的不只是算子优化
在采访中，Shantu Roy 回答了 Arm KleidiAI 与 Arm AI Portal 的关系。
Shantu Roy 解释称，KleidiAI 的定位是帮助开发者调用 CPU 中的特定能力，比如在矩阵计算等场景中发挥硬件能力；而 AI Portal 的覆盖范围更广，不只是一个库或某项能力，而是提供已针对平台优化的模型、学习资源、性能数据和部署指引。
也就是说，KleidiAI 更偏底层性能优化，AI Portal 更偏面向开发者的入口和工作流组织。前者解决“怎么把某类计算跑得更好”，后者解决“开发者该选择什么模型、在哪个平台跑、怎样部署和优化”。
这一点也反映出 Arm 软件生态策略的变化。
过去，Arm 作为 IP 授权公司，更多被理解为芯片架构提供方。但在 AI 时代，仅有硬件能力并不足以降低开发者成本。模型能否高效运行，很大程度取决于编译器、运行时、库、量化工具、性能数据和开发者文档是否完整。
Arm AI Portal 要做的，是把这些分散资源重新组织到一个开发入口中。
新闻稿中提到，经 Arm 优化的模型已经在部分场景中取得性能提升。例如，Qwen3-TTS 在 vivo X300 上通过第二代 Arm 可伸缩矩阵扩展 SME2 加速，实现超过 4 倍速度提升；
Ultralytics YOLO26 在 vivo X300 上依托 SME2，单线程 FP16 相较 FP32 实现超过 40% 性能提升；在树莓派 5 上，依托 NEON 技术，采用 FP16 与 INT8 混合量化方案，相比 FP32 同样实现超过 40% 性能提升。
这些数字说明，端侧 AI 并不是简单把模型放到设备上就能跑。模型压缩、量化、算子适配和硬件特性调用，仍然会显著影响最终体验。
开发者真正缺的是决策效率
从行业视角看，Arm AI Portal 的价值不在于“又多了一个模型入口”，而在于它试图降低开发者的决策成本。
今天开发者并不缺模型。Hugging Face、ModelScope 等平台已经积累了大量开源模型，云厂商、芯片厂商和框架社区也在不断发布适配方案。但模型越多，选择成本反而越高。
对一个开发者来说，真正耗时的往往不是找到模型，而是验证模型是否适合自己的应用场景：延迟是否足够低，内存占用是否可控，精度损失是否可接受，能否在目标芯片上稳定运行，运行时和框架是否兼容，后续维护成本如何。
Shantu Roy 表示，Arm 希望缩短开发者在选择部署哪种模型、部署到何处时所需的实验和决策过程。AI Portal 的目标是融入开发者现有工作流，而不是增加额外负担。
这也是 Arm 特别强调“智能体可发现”的原因之一。随着开发越来越多由 Coding Agent 或自动化工具辅助完成，模型、性能数据和部署资源不仅要对人类开发者可读，也要对机器可发现、可调用。Arm AI Portal 相关资源将支持通过模型上下文协议 MCP 供编程智能体访问，意味着未来开发者可能不再手动浏览文档，而是让智能体直接查找适合某个平台的模型和优化路径。
如果说过去的开发者门户主要服务“人找资源”，那么 AI 时代的开发者门户还要服务“智能体找资源”。