Arm 在 Arm Create 开发者大会上海站期间正式发布 Arm AI Portal，这是一个面向开发者和智能体的统一入口，帮助在 Arm 计算平台上发现、优化和部署 AI 软件，覆盖云、边缘和物理 AI 场景。首批支持语言、语音、视觉和神经图形工作负载，预优化模型包括通义千问、Google Gemma 和 Ultralytics YOLO，支持 ExecuTorch、LiteRT 和 ONNX Runtime 等运行时。Arm 表示该平台旨在降低开发者在模型选择、目标平台选择和部署优化上的门槛，相关资源已通过 Hugging Face 和 developer.arm.com 提供，后续将登陆魔搭社区 ModelScope。
SynthePulse Insight · AI 深度解读
版本 1 · 1 个来源
Arm 在上海 Create 开发者大会发布 AI Portal，把预优化模型、运行时、性能数据和部署指引收进同一个入口，并宣布支持 MCP 供编程智能体访问。它要解决的不是模型稀缺，而是多平台、多模型、多运行时下的决策成本——但首批范围、上线节奏与性能数字的验证条件，报道均未给出。
Arm 在 Arm Create 开发者大会上海站期间正式发布 Arm AI Portal。按照 Arm 的定义，这是一个面向开发者和智能体的统一入口，帮助其在 Arm 计算平台上发现、优化和部署 AI 软件，覆盖云、边缘和物理 AI 场景。
Arm 开发者关系副总裁 Shantu Roy 在媒体沟通会上表示，打造 AI Portal 的核心目标是降低开发者在 Arm 平台上开发和部署 AI 应用的门槛，减少他们在模型选择、目标平台选择、部署方式和模型优化上投入的时间。他提到的主要目标是加快开发者工作流程，减少研究不同模型及目标部署平台所需的时间。
这一目标指向的背景是：当 AI 应用从云端 API 调用延伸到手机、PC、汽车、机器人、IoT 设备和企业云环境，硬件约束重新回到开发者面前。不同场景的计算资源、内存条件、功耗预算和延迟要求都不一样。Shantu Roy 在采访中也提到，认为单一模型能够适用于从云端到边缘端所有环境，这种看法并不完全准确，不同任务往往需要不同模型。
因此，AI Portal 并不是单纯提供一个模型列表，而是试图把模型、运行时、性能数据、代码示例和部署工作流组织起来，让开发者更快判断一个模型是否适合自己的目标设备。从报道描述看，它更接近 Arm 面向 AI 时代的软件生态入口，而非单一开发工具，其价值在于降低开发者的决策成本。
Arm 表示，AI Portal 首批支持语言、语音、视觉和神经图形等 AI 工作负载。预优化模型包括阿里巴巴通义千问、Google Gemma 和 Ultralytics YOLO；支持的运行时包括 ExecuTorch、LiteRT 和 ONNX Runtime；生态合作伙伴包括阿里巴巴、树莓派和 Ultralytics。
渠道方面，Arm 表示相关资源目前已通过 Hugging Face 和 developer.arm.com 提供，后续也将登陆魔搭社区 ModelScope。也就是说，ModelScope 属于计划中的后续渠道，而非当前已上线渠道。
这份清单同时划出了边界：首批工作负载、模型与运行时都是有限集合，报道未说明这些组合的覆盖范围是否会持续扩充，也未披露生态合作伙伴的具体合作形式与深度。
另一个需要区分层次的对象是 KleidiAI。Shantu Roy 解释称，KleidiAI 偏底层性能优化，帮助开发者调用 CPU 中的特定能力（如矩阵计算）；而 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 新闻稿，报道未提供第三方验证，也未给出测试条件、基线细节与独立复现路径。因此它们应被读作 Arm 的单方说法，而不是已被外部确认的结论。
报道同样没有说明这些性能数据在 AI Portal 中如何呈现、是否与具体模型和运行时组合绑定，以及开发者能否据此复现同类结果。
Arm AI Portal 相关资源将支持通过模型上下文协议 MCP 供编程智能体访问。这意味着未来开发者可能不再手动浏览文档，而是让智能体直接查找适合某个平台的模型和优化路径。
报道认为，随着开发越来越多由 Coding Agent 或自动化工具辅助完成，开发者门户需同时服务“人找资源”和“智能体找资源”，这是 Arm 强调“智能体可发现”的原因之一。
不过，MCP 支持的实际可用程度和落地时间尚不明确。报道未说明智能体访问资源时的权限、调用粒度与结果可信度如何界定，也未给出开发者侧实测证据证明这一路径能真正缩短决策流程。
可以确定的是方向：Arm 把“机器可发现、可调用”写进了门户的设计目标，而不只是把它当作文档站点的附加功能。
从行业视角看，Arm AI Portal 的价值不在于“又多了一个模型入口”，而在于它试图降低开发者的决策成本。今天开发者并不缺模型：Hugging Face、ModelScope 等平台已积累大量开源模型，云厂商、芯片厂商和框架社区也在不断发布适配方案。但模型越多，选择成本反而越高。
对一个开发者来说，真正耗时的往往不是找到模型，而是验证模型是否适合自己的应用场景：延迟是否足够低，内存占用是否可控，精度损失是否可接受，能否在目标芯片上稳定运行，运行时和框架是否兼容，后续维护成本如何。
Shantu Roy 表示，Arm 希望缩短开发者在选择部署哪种模型、部署到何处时所需的实验和决策过程，AI Portal 的目标是融入开发者现有工作流，而不是增加额外负担。
这里存在一个尚未被回答的问题：AI Portal 能否真正缩短决策流程，报道未给出开发者侧实测证据。在缺少独立验证的情况下，其价值主张目前仍停留在 Arm 的自我描述层面。
本文事实基础来自 InfoQ 对 Arm Create 开发者大会上海站及 Arm 媒体沟通会的报道。Arm AI Portal 的发布、Shantu Roy 的身份与表态、首批工作负载/模型/运行时/合作伙伴清单、渠道安排、MCP 支持计划，均属 Arm 方面的说法，报道未提供独立核实。Qwen3-TTS 超过 4 倍、YOLO26 超过 40% 等性能数字明确来自 Arm 新闻稿，报道未提供第三方验证、测试条件与基线细节，应视为单方数据。关于 AI Portal 是“软件生态入口”而非单一工具、以及门户需同时服务人与智能体的判断，属于基于报道描述的推断，不是 Arm 的官方定性。报道未说明 AI Portal 的具体上线时间、版本节奏、完整功能范围，也未披露合作伙伴的具体合作形式。
Arm AI Portal 的看点不在“多了一个模型入口”，而在于它把模型、运行时、性能数据与部署指引收进同一入口，并试图让这套资源同时被人和编程智能体发现。它回应的是端侧 AI 真实存在的决策成本问题；但在首批范围有限、性能数字仅有 Arm 单方来源、MCP 落地程度未明的情况下，它能否真正缩短开发者的验证路径，仍待开发者侧证据。
主报道
主报道来源