企业官网建设流程全解析

如果你过去一年里在 Arm 设备上部署过哪怕一个像样的 AI 模型，大概率会有一种共同感觉：能跑，但每一步都在跟"碎片化"搏斗。模型要自己找，格式要对得上，算子要能落到对应的加速库上，编译器版本稍微差点意思，性能就能砍掉一大截。很多团队最后干脆放弃在 Arm 上做推理优化，直接回退到 CPU 通用路径，或者干脆把计算挪到 x86 服务器上。但移动端、嵌入式、边缘盒子的需求就摆在那里，绕不过去。这次 Arm 推出的 AI Portal，表面上看是一个模型仓库加目录导航，但往深了说，它试图把 Arm 生态里从模型获取到落地的整条链路理顺。这篇我就从实际开发者的角度，把 AI Portal 能做什么、怎么用、有哪些坑、以及它到底在 Arm 的 AI 版图里占什么位置，一次说清楚。

1. 为什么在 Arm 上跑 AI 模型这么"闹心"：先还原真实痛点

在聊 AI Portal 之前，得先搞清楚它要解决的是什么问题。很多从 x86 迁移过来的开发者第一次在 Arm 设备上跑模型，最容易低估的其实是碎片化的杀伤力。这跟架构本身的计算能力关系不大，纯粹是软件生态的问题。

1.1 x86 上的"默认能跑"到 Arm 上的"处处要调"

x86 平台发展了几十年，AI 推理栈已经高度收敛。装好 Python 环境，pip install 一个推理框架，再下个模型权重，大多数情况下能直接跑起来。底层算子库、指令集适配、内存布局这些细节，几乎不用你操心。

Arm 的状况完全不同。它不是一个单一架构，而是一整族架构的统称。手机上的 Cortex-A 系列、服务器上的 Neoverse 系列、嵌入式里的 Cortex-R/M 系列，指令集上虽然有重叠，但微架构、缓存层级、内存带宽、支持的 SIMD 扩展（NEON、SVE、SVE2）差距非常大。你在 MacBook 的 Apple Silicon 上编译好的二进制，放到树莓派上报错是非常常见的事；在树莓派上调通的算子优化，挪到高通 8cx 上又可能性能回退。

更麻烦的是推理框架的碎片化。同一个 ONNX 模型，在 x86 上可以靠 ONNX Runtime 的默认 CPU EP 获得不错的性能；在 Arm 上，你可能要面对 TFLite、ONNX Runtime、ExecuTorch、llama.cpp、Arm Compute Library（ACL）等一堆选择。每个框架支持算子的效率不同，对硬件特性的利用程度也不同，选错了就是数量级的性能差距。

1.2 模型获取与硬件适配之间存在严重的"信息断层"

过去一年里，我见过不少团队在 Arm 设备上做模型选型时，基本靠"试"。去 Hugging Face 上搜一个看起来参数合适的模型，下载权重，转成 ONNX 或 GGUF，上传到设备上跑 benchmark。结果模型在设备上跑不动、算子不支持、内存爆掉，然后又换一个模型再来一遍。整个流程极其依赖个人经验，也没什么系统性的信息可以参考。

AI Portal 的切入点就在这个"信息断层"上。它试图把模型、工具链、硬件能力绑定在一起，让开发者不再需要自己去做大量的可行性验证。你可以把 AI Portal 理解成 Arm 官方对"这个模型在 Arm 上怎么跑、用什么工具链跑、性能大概什么样"的整合回答。这正好击中了过去 Arm AI 生态里长期缺失的一块拼图。

2. AI Portal 的核心能力拆解：它到底给了开发者什么

Arm AI Portal 不是一个单纯堆放模型链接的网页，它是一个面向 Arm 生态的模型发现与部署辅助平台。从实际使用的角度，我把它拆成四个能力层来说明。

2.1 可筛选的模型目录：按场景、框架、硬件路径快速定位

Portal 首页提供的是一个可过滤的模型目录，里面的模型都经过筛选和整理，覆盖了视觉、语音、自然语言处理、生成式 AI 等主流任务类型。比较实用的是它的筛选维度不是按参数量一刀切，而是结合了运行方式、目标硬件范围、配套框架来分类。

你可以按任务类型（图像分类、目标检测、语义分割、文本生成、语音识别等）、按模型来源（开源社区、厂商贡献、Arm 自家优化版本）、按支持的 runtime（ONNX Runtime、ExecuTorch、llama.cpp、TFLite 等）做交叉筛选。举个例子：我需要找一个大模型可用的 embedding 模型，同时希望能在树莓派 5 上用 llama.cpp 跑，那我就可以同时选"文本嵌入"、"llama.cpp"、"Cortex-A"这几个条件，筛出来的结果大概率是能直接用的，不需要自己做大量兼容性测试。

2.2 模型详情页：把部署依赖前置暴露

点进任何一个模型，详情页提供的不只是 README 和下载链接，而是把部署相关的核心信息直接摆出来：模型架构、输入输出格式、量化支持情况、已验证过的框架版本、推荐的内存配置、目标算力范围、License 类型。这些信息在模型卡越来越完善的今天看似普通，但关键在于"已验证"三个字——意味着列出来的配置至少被 Arm 或其合作伙伴在真实设备上跑通过，而不是社区里某个人说"好像能跑"。

这个设计对工程团队非常友好。选型阶段不需要先下载一个 7B 模型试半天才发现它需要 16GB 内存，而目标设备只有 8GB；也不需要推理框架和模型权重之间因为版本不兼容反复调试。详情页就像一个"预检清单"，把你的试错成本前移到了选型阶段。

2.3 优化工具的引导：Vela、Compute Library、第三方 runtime 的配合

在 AI Portal 里很多模型旁边会给出推荐的优化路线，比如配合 Arm 的 Vela 编译器做 NPU 加速，或者在 Cortex-A CPU 上使用 Compute Library 提供的算子实现。这套引导的价值在于，它把 Arm 过去分散在各个文档站里的工具链串起来了。

具体来说，Vela 针对 Ethos-U NPU 做模型编译优化，Compute Library 提供针对 Arm CPU 和 GPU 的手工优化算子。过去开发者要自己搞清楚"我的模型该用 Vela 还是 Compute Library，还是直接跑一个 runtime 就行"，现在 Portal 会在模型层面给出一个推荐的默认路径。它相当于告诉你：想在这个硬件上跑好这个模型，你该走哪条路。

2.4 上手示例与参考代码：比文档更有替代价值

AI Portal 里很多模型都配套了参考示例代码，覆盖从模型加载、输入预处理到推理调用的完整流程。这些示例不是官方文档里那种只跑通 Demo 的玩具代码，而是会注明关键性能参数和内存布局的细节。比如在跑 LLM 的时候，示例里会明确说明 KV cache 怎么管理、prompt 怎么打包、beam search 的参数设置等。

对于做嵌入式或移动端优化的开发者来说，这些参考代码本身就是很好的学习材料。你不仅知道"怎么跑起来"，还能从 Arm 的代码里看到官方的性能优化是怎么做的，这对后续自己的调优工作很有借鉴意义。

3. 实操视角：在 Arm 设备上把模型跑起来的完整链路

光讲能力不落地没有说服力。我拿一个最常见的场景——在 Arm Linux 设备上（比如树莓派 5，8GB 内存版）部署一个开源对话模型——走一遍完整流程。AI Portal 在里面的作用，你可以对比一下没有它时的差异。

3.1 环境准备阶段

假设是树莓派 5，系统为 Ubuntu 24.04 ARM64。首先把基础编译工具链和依赖装上：

sudo apt update sudo apt install build-essential git cmake python3-pip # 安装 UTF-8 locale，保证 Python 和模型推理库不出现编码问题 sudo apt install locales sudo locale-gen en_US.UTF-8

这里有个常见坑：如果系统里同时有 Python 2 和 Python 3，或者 apt 源里默认 Python 版本和你要用的推理框架版本不一致，大概率会遇到编译时头文件找不到的问题。建议直接用python3 -m venv建一个虚拟环境，然后在虚拟环境里装 ONNX Runtime 或相关的 Python 包。

3.2 从 AI Portal 获取模型和配套代码

过去，你需要在 Hugging Face 上搜索模型，再在 GitHub 上翻代码，再到 Arm 的文档里找优化指南，三个地方来回跳。现在，AI Portal 会把这三个环节压缩在一个页面里。

比如我想找一个能在树莓派 5 上实时运行的 OCR 模型，用 ONNX Runtime 推理。在 Portal 里选"OCR" + "Cortex-A" + "ONNX Runtime" 三个筛选条件，出来的结果里会有 PaddleOCR 的优化版本，也会有若干社区贡献的 OCR 模型。每个结果页里直接给出了下载链接和已验证的设备类型，甚至还标注了fp32、fp16、int8 量化的推理耗时参考值。这一步省掉的不仅是时间，更是大量的枚举试错。

3.3 推理框架的选型与编译

模型确定之后，推理框架的选择直接影响性能和稳定性。如果选 ONNX Runtime，直接安装 ARM64 版即可：

pip install onnxruntime

但要注意，onnxruntime的 PyPI 默认包是为 x86 架构编译的。在 Arm 设备上，你必须显式安装onnxruntime的 ARM64 版本。检查的方法很简单：

import onnxruntime as ort print(ort.get_available_providers())

如果输出的列表中缺少CPUExecutionProvider或者 import 阶段就报 illegal instruction，说明安装的是不对的包。在树莓派 5 上，推荐从 arm64 的 wheel 安装，或者用pip install onnxruntime==1.18.0这类指定版本，因为新版本对 aarch64 的支持通常更好。

如果走 llama.cpp 路线部署 LLM，编译时的 flag 非常关键。树莓派 5 的 Cortex-A76 支持 NEON，但不支持 SVE，所以编译时启用 NEON 优化即可：

git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build && cd build cmake .. -DCMAKE_BUILD_TYPE=Release -DLLAMA_NEON=ON -DCMAKE_C_FLAGS="-march=armv8.2-a+fp16+dotprod" make -j4

这里的-march=armv8.2-a+fp16+dotprod尤其关键。树莓派 5 的 Cortex-A76 支持 dotprod 指令，这会让量化模型的推理速度有肉眼可见的提升。很多人直接在树莓派上编译 llama.cpp，用的是默认参数，结果跑大模型时速度只有每秒两三个 token，然后误以为是硬件不行。实际上就是没启用 dotprod 扩展。

3.4 在设备上完成推理验证

用一个 7B 量化模型举例，8GB 内存版的树莓派 5 在 int4 量化下运行，大约能跑出每秒 4~6 个 token 的速度，内存占用在 5GB 左右。这个表现虽然比不上桌面 GPU，但对于原型验证和一些边缘场景已经够用。

把这套流程和没有 AI Portal 的旧流程对比，核心区别在哪？旧流程里你可能要花半天确认"这个模型在 Arm 上能不能跑"，再花半天抠算子兼容问题。有了 Portal 的预筛选和已验证配置，你可以直接从模型的推荐组合入手，把时间花在业务逻辑和产品调优上，而不是底层的试错上。

4. 理解 Arm 的软件牌：AI Portal 背后的生态逻辑

AI Portal 发布的时间点很有意思。Arm 近几年在硬件端动作频繁：Cortex-X 系列性能一路拉升，Neoverse 平台在云原生和 AI 推理服务器上不断拿下订单，Cortex-A 系列在移动端卷视频生成和端侧智能，Ethos NPU 也在 AIoT 设备里铺量。但硬件出得再多，软件跟不上的话，落地始终会推进得很慢。

4.1 从"卖 IP"到"做生态"的关键拼图

过去 Arm 给人留下的印象主要是 IP 授权方，它把 CPU、GPU、NPU 的设计授权给芯片厂商，芯片厂商自己做 SoC，然后软件生态很大程度上依赖芯片厂商和开源社区自生自灭。这就导致一个局面：芯片的 AI 算力参数很好看，但开发者拿到板子之后没有一个统一的软件入口，每个硬件平台的模型适配水平参差不齐。

AI Portal 的做法相当于把"如何在这个 Arm 芯片上跑 AI"这件事，从硬件厂商的单独文档和开源社区的零散讨论中抽离出来，变成一个官方主导的、相对统一的入口。它的导流价值很明确：你在这个 Portal 里查模型、看示例、用工具，最后跑得顺，自然会增加对 Arm 平台的信任。这本质上是通过软件体验来拉动 IP 授权生意。

4.2 Portal、Compute Library、runtime 各自扮演什么角色

这里有必要把 AI Portal 和 Arm 已有的软件组件之间的关系梳理清楚。Compute Library（ACL）是 Arm 提供的一套手工优化过的底层算子库，直接面向 Cortex-A CPU 和 Mali GPU。ONNX Runtime 和 ExecuTorch 这类框架则是更高一层的推理引擎，它们的算子实现一部分会通过 ACL 做硬件加速。

AI Portal 本身不是一个 runtime，也不是一个编译器。它是把这些层连接起来的"导航员"——告诉你某个模型在某个硬件上，推荐用哪个 runtime，需要配合哪个版本的 ACL 或 Vela，大概能达到什么性能。它做的是"分流"和"组合"的工作，降低的是开发者的决策成本。

我用一个表来说明这三个层次的关系：

这个整合的体验确实是对 Arm 生态开发者的一剂补药。过去你需要自己从海量的模型库里去筛、去试、去调，而现在你至少有一个起点，而且是官方维护的起点。

4.3 开源策略：为什么 Arm 选择"开放式目录"而不是"封闭商店"

一个值得留意的设计是，AI Portal 并没有做成一个 Arm 独占模型的封闭商店，而是兼容了多种来源的模型，包括开源社区的、厂商贡献的、以及 Arm 自己优化的。这个思路是对的——如果 Portal 里只有 Arm 的模型，那它就成了一个营销展示页面，不会有真正的生态价值。

Arm 的选择是做一个"生态连接器"而不是"模型生产商"。它和开源社区的模型共存，只负责在 Arm 平台上做验证、优化和导流。这样既拉拢了社区力量，又强化了自身平台的话语权。对于开发者来说，好处是模型选择范围没有被限制，坏处是——筛选条件再精准，也得自己花时间看细节，不能指望全自动。

5. 实测中值得留意的坑：别被模型目录"已实测"迷了眼

AI Portal 确实能减少不少试错成本，但如果你完全依赖它，把"已验证"当作"一定能跑通"，那还是会踩坑。我基于自己在 Arm 设备上的实际部署经验，把最容易出问题的几个点列出来。

5.1 "已验证"不等于"在你设备上已验证"

AI Portal 的已验证信息，更多是基于 Arm 参考平台或特定开发板测出来的。但实际项目里的 SoC 千差万别，同样是 Cortex-A76，不同厂商的 cache 大小、内存带宽、电源管理策略完全不一样。A 厂在参考板卡上能跑到 30 帧的目标检测，到了 B 厂的工控板上可能只有 15 帧。

所以正确的做法是把 Portal 提供的信息当作"可行性参考"而不是"性能保证"。它最大的作用是帮你把范围从 100 个模型缩小到 5 个，但最后选哪个、在自己的设备上性能如何，还是得自己跑一遍 benchmark。

5.2 算子兼容性：模型结构变化才是最大变量

模型卡上写的是"已验证"，但如果你对模型做了任何结构上的修改，比如去掉某些后处理层、修改输入分辨率、改注意力实现，那"已验证"状态立刻失效。尤其是 Transformer 类模型，你改一个 attention 的 mask 实现，就可能触发某个未优化的算子路径，导致性能断崖式下降。

这个坑在现有大模型时代尤其突出。因为很多研发踩在模型版本很新的状态下——比如刚发布的 Llama 3.2、Qwen 2.5 的变体——官方验证大概率还跟不上社区的迭代速度。这种时候不能指望 Portal 帮你兜底，还是得会看 profiling 工具，找到热点算子。

5.3 内存带宽：Arm 设备最容易被低估的瓶颈

很多人在 Arm 设备上量化模型，第一个观察是"内存占用降下来了"，但推理速度并没有按比例变快。原因很简单，内存带宽没变。尤其是 LLM 推理，逐 token 生成阶段完全被显存/内存带宽卡死。你在树莓派 5 上跑一个 int4 量化版的 7B 模型，内存占用 5GB 左右，但带宽就那么多，量化的收益主要在内存容量和功耗上，延迟收益远没有想象中大。

这一点 AI Portal 上的注释其实有提及，但很容易被忽略。我的建议是：如果目标场景是低延迟交互，优先关注算子的计算密度和编译优化；如果是高吞吐离线，再关注内存带宽。

5.4 好用的工具链版本和文档版本要配套

以 ONNX Runtime 为例，Arm 的 Compute Library EP 和 ONNX Runtime 的集成是跟着版本走的。在某些版本中，ACL EP 对某个算子的支持是 disabled 的，换了其他版本却可能打开。如果你照搬 Portal 里的示例代码，但用 pip 安装了不同大版本的 ONNX Runtime，底层加速路径可能完全不一样。

同样，交叉编译工具链的版本也对，但目标板上的 runtime 库版本不一致，也会出现运行时错误。热词里反复出现"arm compiler 5.06 update 7"，倒不如说很多人对编译器版本搭配的困惑其实是生态碎片化的缩影。遇到这类问题，建议先看官方 release notes，再锁定一个经过验证的版本组合，不要追新。

6. AI Portal 对不同开发者的实际价值：三种典型角色分析

AI Portal 对所有人的价值不是均等的。我把它分成三类典型角色，你可以对照自己的身份看它值不值得深入研究。

6.1 嵌入式与物联网开发者：最大受益者

如果你做的是 MCU 级别的 AI（Cortex-M 配合 Ethos-U NPU），过去最头疼的就是命令行工具链、模型转换流程、NPU 编译器的配合。AI Portal 的 Vela 引导和已验证模型能在很大程度上帮你减少"模型能否在 NPU 上跑"这个核心风险。尤其是 int8 量化模型的例程，往往能直接套用到真实产品开发中。

这个领域的开发者建议把 AI Portal 当作工具链文档的"快捷方式"使用。遇到一个新的视觉模型，先查 Portal 看有没有对应的已验证状态和 Vela 参数建议，再动手转换，能省不少时间。

6.2 移动端和 PC 端 App 开发者：值得关注但别急着迁移

对移动端开发者来说，AI Portal 的意义更多在于了解 Arm 平台上的模型优化趋势，而不是立刻迁移。毕竟 Android 和 iOS 的部署链路还受限于各厂商的 runtime 和系统版本，Arm 官方的 Portal 更适合作为技术选型参考。如果你的 App 重度使用端侧 AI，关注 AI Portal 里大模型相关模型卡的更新，对了解端侧 LLM 的能力边界会有帮助。

6.3 服务端与云原生开发者：从边缘视角看待 AI Portal

做云端推理的开发者可能觉得 AI Portal 跟自己没什么关系，毕竟云端跑在 Neoverse 服务器上的模型有更强的算力和内存。但实际这两年 Arm 服务器在云厂商里的部署量快速增长，AI Portal 里针对 Neoverse 平台优化的模型和工具链信息，恰好能帮你在 Arm 服务器上评估 AI 推理的性能。特别是想在成本敏感场景下把推理迁移到 Arm 服务器的团队，通过 Portal 快速验证模型兼容性和工具链成熟度，非常直接。

7. 我的总体看法和一些实际建议

Arm AI Portal 的出现，说明 Arm 开始认真补软件生态的课了。过去很长一段时间，Arm 平台 AI 开发的困境不在于没有好硬件，而在干没有一个相对统一的软件入口把模型、runtime、算子库、硬件能力串起来。AI Portal 作为这个入口，价值是实实在在的，但不是万能的。它更像一个优秀的导航仪，能告诉你路在哪里，但发动机还是你自己的。

我给不同阶段开发者的建议是：

1. 如果你刚进入 Arm AI 开发，直接把它当作第一入口，从模型目录里挑一个与业务场景接近的已验证模型，照官方示例跑一遍，这是最快建立直观感受的方式。
2. 如果你已经有成熟的部署流程，可以把 AI Portal 当作情报站，关注新模型、新工具链和已验证的性能数据，用它来校准自己的选型方向，但别被"已验证"绑架。
3. 如果你在做边缘或嵌入式产品，尤其是有 NPU 的设备，留意 Portal 里 Vela 和 Compute Library 的推荐路径，这些往往能帮助你避免"模型跑不起来"的硬伤。

最后分享一个我个人的小习惯：每在一个新 Arm 设备上落地一个模型，我都会把模型版本、runtime 版本、编译参数、实际性能和 Portal 标注的性能做一次对比，记录在项目的 README 里。这不仅是给团队留记录，也是反向检验 Portal 标注可靠性的好方法。用得越多，你越能摸清哪些信息可信、哪些需要打折扣。这种基于实际数据的判断力，比任何官方文档都更可靠。