作者 | 周雅
来源 | 科技行者
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 所做的，就是更深入参与本地开发者社区，为每一个穿行在代码与物理世界之间的开发者，铺平通往生产级系统的坦途。
科技行者团队出品
