近期， Arm 上线 AI Portal。这个网站服务的对象，除了开发者，还有帮开发者写代码的 AI。

人在这里找模型、看性能数据、获取部署资源；编程智能体也能通过 MCP 调用相关资料。不过，面向智能体的资源目前仍处于预先体验阶段。

代码交给 AI 之后，应用选用哪套技术、最后运行在哪里，依然需要作决定。编程智能体正开始参与这些选择。对 Arm 来说，争取开发者的工作也随之延伸到了 AI 查阅什么资料、调用哪些工具的环节。

Arm 主要向芯片公司授权技术，却需要提前接近应用团队。等一款软件已经写完，它能选用哪些硬件，往往也受到了代码和依赖的约束。

Arm AI Portal 提供模型性能数据与部署资源软件先替硬件做了一轮筛选

今年 4 月，Docker 公布过一次颇有代表性的失败。团队想在 Arm64 MacBook 上运行音乐生成模型 ACE-Step v1.5，结果连容器都没构建出来。

Docker 披露的原因藏在一条下载链接里：依赖文件把 flash-attn 安装包的地址写死为 x86 版本。机器已经换了架构，安装程序还在下载不兼容的文件。模型有 35 亿参数，卡住它的却是安装环节。

失败发生在性能比较之前。

开发者很少直接找 Arm 购买 CPU 设计，但会决定项目采用什么模型、调用什么框架、装哪些依赖。如果这些软件只在一种架构上验证过，其他硬件就要先补一笔适配费用，才有资格参加接下来的比较。

比如，一款应用决定把语音识别放在设备上，团队就得评估本地模型、运行库与内存；如果改用云端 API，这些工作会转交给服务提供方，硬件选择也随之转移。算力需求并不会消失，只是在不同的产品选择之后，落到了不同的设备和企业账上。

对急着交付的团队来说，这笔费用往往比参数表更有分量。一个方案今天就能运行，另一个方案得先查清楚为什么装不上，后者再便宜、能效再高，也可能被暂时搁置。软件里的默认设置，有时就这样替团队完成了一次硬件筛选。

当然，使用某个框架，并不意味着从此只能选择一种芯片。开放框架本来就在努力跨越架构差异。问题是，理论上可移植，与一个普通团队能否在交付期限内完成迁移，距离不小。

Arm 争取开发者，要改变的正是这段距离。它得让应用团队知道，Arm 平台上有可用的方案，而且值得花时间验证。等基础设施团队开始比较服务器时，如果应用已围绕另一种架构完成部署，迁移和重新验证的成本就会进入采购账本。越早降低这些成本，Arm 越容易参与后续的硬件比较。

Arm 得让这套方案用得起来

这也是 AI Portal 不能只做成模型目录的原因。

同一个任务，可以选大模型，也可以选小模型；可以保持较高精度，也可以用量化换取速度和更低的内存占用。开发者需要知道，每种取舍到了自己的目标设备上，究竟还剩多少效果、要花多少资源。

AI Portal首批提供千问、Gemma 和 YOLO 等预优化模型，列出延迟、内存、规模与准确率数据，并附上代码示例和部署流程。上传自有模型进行分析和优化，则仍是后续功能。

这些资料不能替代业务测试，却能帮助团队先剔除明显不合适的选项。一个模型在榜单上成绩不错，装进设备后占满内存，仍然无法交付。把这种判断提前，Arm 平台才更容易进入认真比较的范围。

进入候选名单还不够。开发者也不愿为了发挥一种芯片的性能，另养一支底层优化团队。Arm 此前把KleidiAI 集成进 XNNPACK 推理库，就在处理这个问题：应用走相应的运行路径，便可以利用 Arm CPU 的底层优化，无需逐段重写业务代码。具体收益仍取决于硬件、库版本和所用算子。

而当程序已经运行，却达不到预期速度时，团队又需要回答一个更棘手的问题：究竟哪里慢？4 月 28 日发布的免费工具Performix，面向 Arm 云基础设施分析内存带宽、缓存效率、CPU 利用率等运行数据，帮助定位性能瓶颈。它通过 Arm MCP Server 接入 Codex、GitHub Copilot 等开发工具，分析结果可以直接出现在代码旁边。

Performix 通过调用栈和采样数据帮助定位性能问题

在前面的 Docker 案例中，团队把 Arm 迁移工具接入编程智能体，让它检查镜像、扫描依赖、查找修复资料。案例披露的约 15 分钟，指向适配分析及相关修复建议，不能据此认定整个模型已经迁移成功。

Docker 案例使用的 MCP 工具链，连接模型发现、架构检查、代码扫描与迁移判断

但这个流程已经说明，AI 在开发中的作用，可以延伸到检查一套方案能否运行。它得到什么资料、能调用哪些诊断工具，会影响它提出怎样的修改建议。Arm 做 MCP 接口，就是想把自己对架构、迁移和性能的了解，送进这个过程。

文档过去主要等待人来阅读。如今，开发者未必打开 Arm 网站，编程智能体也可能替他获取模型资料、调用分析工具。平台需要争取的位置，开始从浏览器里的收藏夹，延伸到 AI 可调用的工具列表。

开发者不买芯片也能影响芯片生意

这条路径与模型公司、云厂商争取开发者，有相似的商业考虑：应用尚未成形时，技术方案比较容易调整。等部署流程、测试环境和维护经验积累起来，换个平台就需要重新核算成本。越早成为一个可行选项，越有机会跟着项目长大。

Arm 的回报则要经过更多环节。在它主要的IP 授权业务中，芯片客户支付许可费，相关芯片出货后再按约定支付版税。一个开发者使用 AI Portal，并不会直接产生一笔芯片收入。

中间要经过应用采用、硬件需求和客户出货。对芯片客户而言，软件是否好用，也会影响他们对产品能否卖出去的判断。Arm 投入这些工具，是在为客户的芯片增加被应用采用的理由。

开发者的影响力，就藏在这种传导中。他可能从未读过一份芯片授权合同，但他选择的技术方案，会成为下游评估硬件时必须考虑的条件。

所以，判断 AI Portal 的价值，不能只看上线了多少模型、吸引了多少人访问。更有意义的是，原本因为适配困难而被搁置的项目，有多少因此愿意测试 Arm；测试之后，又有多少能够进入实际部署。这些结果目前还需要观察。

AI 参与开发也不会让 Arm 自然获胜。智能体能调用 Arm 工具，同样可以帮助团队检查其他平台、改写部署脚本、降低迁移成本。人仍然要验证它的建议，对效果、账单和交付负责。工具接进去了，只能说明 Arm 获得了参与比较的机会。

等团队开始比较算力价格，代码里可能已经写下了倾向。Arm 需要做的是，让开发者和编程 AI 在写下这些选择之前，就知道还有一套可用的 Arm 方案。