前段我把一个在 x86 服务器上跑得好好的 AI 模型迁移到 Arm 板子上推理速度直接掉到原来的八分之一。折腾了一周后我意识到真正的问题不是模型本身而是整个 Arm 生态太碎缺一个把模型、工具链、性能基线圈在一起的模型基地。所以看到 Arm 发布 AI Portal 的消息时我第一时间去翻了一遍。这个入口不只是一个下载页更像是一张 Arm 平台的 AI 模型部署地图目标是让 Cortex-A 应用处理器、Ethos NPU、Mali GPU、Neoverse 服务器这些不同算力单元都能找到匹配的模型和落地方案。如果你正在做端侧 AI、嵌入式部署或者在 Arm 云主机上跑大模型推理这篇文章可以帮你理解 AI Portal 到底能解决什么问题以及哪些事情它依然解决不了。我下面聊的内容大多来自我在各种 Arm 设备上部署模型时踩过的坑不一定每条都直接写在官方文档里但方向上会比“看一遍 README”更接近实际作战。1. AI Portal 解决的是移植模型的“最后一公里”1.1 从 x86 到 Arm问题从来不在“能不能跑”先说一个被很多人低估的事实模型权重本身是通用的。PyTorch 导出的 ONNX 模型、Hugging Face 上下载的 safetensors 权重在 x86 上能做推理换到 Arm 板子上也一样能加载。真正出问题的是算子执行层面的优化路径。x86 处理器的 AI 推理编译器默认会走 AVX、AVX2 这类指令集路径。Arm 这边要靠 NEON、dotprod、SVE/SVE2 来提速。这些扩展不是默认开启的。以 llama.cpp 为例它在 x86 上会检查__AVX2__这类宏在 Arm 上则看__ARM_NEON、__ARM_FEATURE_DOTPROD。如果你交叉编译时用的工具链太老或者 cmake 配置没有把指令集选项传进去代码就会悄悄走回标量实现同一个算子慢五倍十倍都不奇怪。另一个坑是二进制兼容。x86 上编译好的 llama.cpp 可执行文件拷到 aarch64 板子上直接报Exec format error。重新编译完又在另一块板子上报Illegal instruction原因是你这块板子的 CPU 比较老不支持二进制里已经启用的指令扩展。x86 的指令集相对统一Arm 这边从 Cortex-A53 到 Cortex-A76 再到 Neoverse N2微架构差异极大同一份模型在不同板子上的表现经常是天上地下。AI Portal 想解决的就是这“最后一公里”的混乱。它给模型打上了硬件标签告诉你哪个模型跑在什么设备上、需要什么指令集、内存在什么档位让你在选型阶段就开始避坑而不是等部署到一半才发现走错了路。1.2 AI Portal 到底聚合了哪些东西我翻下来的感觉是AI Portal 不是简单把 Hugging Face 的热门模型榜搬过来。它更像一个“模型 硬件适配档案 部署配方”的组合体。里面大致有几类内容模型集合针对 Arm 平台验证过的视觉、语音、文本生成模型不是所有热门模型都无脑收录。性能基线同一个模型在不同 CPU、不同量化档位下的延迟、内存占用、吞吐数据。部署示例针对每个模型的转换脚本、推理引擎配置、前后处理代码。工具链跳转Arm NN、Arm Compute Library、KleidiAI、llama.cpp、ONNX Runtime 等官方给了入口和推荐组合。这跟传统模型下载站有本质区别。传统站点的逻辑是“模型给你环境自己搞定”。AI Portal 的逻辑是“模型和环境版本都给你对好尽量让你少折腾”。维度传统模型下载站Arm AI Portal内容主体模型权重 README模型 硬件适配档案 性能基线硬件标签基本没有指令集、内存档位、NPU/GPU 支持情况部署工具自己找量化脚本、推理引擎示例、工具链推荐性能数据零散在各 Issue 帖子里统一基线按设备/量化档位给出对独立开发者来说最值钱的是“硬件标签”和“性能基线”这两个东西。以前你选模型基本靠猜现在至少有了一个相对可靠的参考系。2. 选模型之前先把 Arm 的算力结构搞清楚2.1 CPU、GPU、NPU 各管一摊别指望一个模型通吃Arm 芯片不是一个“CPU 抽象”而是一个异构系统。Cortex-A 系列 CPU 负责通用计算Mali GPU 适合并行度高的卷积、矩阵运算Ethos 系列 NPU 则是专用固定流水线对算子类型和内存布局都有严格限制。同一个模型在不同算力单元上的瓶颈完全不同。很多朋友一上来就问这个模型能不能塞进 NPU其实应该反过来问这块 NPU 支持哪几个算子我见过不少项目模型文件确实编译进 NPU 了但算子映射不完整一部分算子被放回 CPU 执行。表面上你在用 NPU实际上关键路径还是 CPU 在跑性能自然拉胯。AI Portal 的筛选器如果能把这个边界条件标清楚就已经解决了一半问题。还有一个容易被忽略的点老 CPU 的 IPC 已经跟不上新的 AI 算子库要求。比如 Cortex-A57 是 ARMv8.0 架构不支持 dotprod 扩展很多新的 AI 算子库默认要求 ARMv8.2 及以上跑在 A57 上只能走标量回退。这就是为什么同一份模型在 A57 上慢得离谱在 A76 上却能跑得流畅。选型时不能只看主频还要看指令集版本。2.2 Neoverse 服务器同一套 Arm 主线不同的板卡Arm 服务器走的是 Neoverse 这条线N2、V2 这些核支持 SVE/SVE2面向的是数据中心推理场景。它和手机、嵌入式设备用同一条指令集主线但部署逻辑完全不一样嵌入式设备要考虑内存带宽、功耗墙、散热服务器则更关注吞吐量、多路并发、批量推理。我之前在一台 4 核 Arm 云主机上部署过一套 RAG 知识库。Embedding 模型用的是 bge-small-zh量化后只有几十到一百多 MB在 Arm CPU 上跑完全没问题。真正需要调的是并发客户端查询多起来后CPU 会被 embedding 和向量检索同时占满需要限制最大并发连接数否则延迟直接飙起来。AI Portal 如果能把服务器侧的部署配置也收纳进来对用 Arm 云主机做推理的人会非常实用。现在的问题是很多开发者对 Arm 服务器的认知还停留在“能跑编译、跑跑 Web 服务”的层面。实际上 Arm 服务器跑 LLM、embedding、Whisper 都是可以的只要你对指令集和内存带宽有概念部署难度并不比 x86 高多少。3. Portal 上的模型筛选逻辑从视觉模型到 LLM3.1 先选设备再选模型别只看热门榜大多数人在模型选型上的第一反应是去热门榜单上挑一个精度最高的模型。这个思路在云端 GPU 上没问题但放到 Arm 板子上就会踩坑。端侧设备的内存、算力、算子支持范围都是硬约束热门的大模型往往一上来就超内存后面越调越偏。正确顺序是先看清楚目标设备的边界条件可用内存是多少CPU 支持什么指令集有没有 NPUNPU 支持什么量化格式然后带着这些条件去筛模型。我举一个实际例子一个 1GB 内存的 IoT 盒子要做人体检测。热门榜单里的 YOLOv8n 看着不大但部署时加上运行时、图像预处理缓冲、前后处理1GB 内存很快就吃紧。更稳的路线是先筛 MobileNetV3-SSD、EfficientDet-Lite 这类小模型先在板子上跑通再根据实测精度决定要不要剪枝或蒸馏。AI Portal 这类平台如果按“目标设备”筛选而不是按“热门程度”排序对工程化的帮助会非常明显。我理想的筛选维度是这样的目标设备系列Cortex-A 具体型号、Neoverse 系列、带不带 NPU。可用内存档位512MB、1GB、2GB、4GB、8GB 以上。量化格式INT8、INT4、FP16、混合量化。模型任务图像分类、目标检测、语义分割、语音识别、文本生成、embedding。最低工具链版本有些模型需要更新的编译器或推理库提前标明能省很多编译报错的排查时间。3.2 三类典型任务在 Arm 上的选型参考拿我现在经常做的几类任务举例。第一类是知识库系统需要 embedding 模型生成向量。bge-small-zh、multilingual-e5-small 这类模型量级小在 Arm CPU 上跑完全没问题非常适合端侧本地知识库。选型时主要看模型尺寸和向量维度而不是追求最大最强的 embedding 模型。第二类是语音转文字。Whisper 系列的 whisper.cpp 实现有 Arm NEON 优化tiny 和 base 模型在 Cortex-A76 级别可以跑到接近实时的速度。faster-whisper 在 Arm 上也能编译但要处理 CTranslate2 的依赖踩坑成本高一些。如果没有特殊需求whisper.cpp 是更省心的路线。第三类是本地 LLM。0.5B 到 1.5B 的模型用 Q4_K_M 量化后2GB 到 4GB 内存的设备就能跑3B 到 8B 的模型需要更多内存而且速度基本由内存带宽决定CPU 主频再高也救不回来。任务建议模型路线内存档位适合场景人体检测MobileNetV3-SSD / EfficientDet-Lite1GB 左右IoT 摄像头盒子向量检索bge-small-zh / e5-small几百 MB 内端侧知识库语音转文字whisper.cpp tiny/base1-2GB录音笔、会议终端对话生成Qwen2.5-1.5B / Llama-3.2-1B Q4_K_M2-4GB离线语音助手这些任务在 AI Portal 选型时几乎都能找到对应模型和部署示例。这比自己在 GitHub 上大海捞针要靠谱得多。4. 模型上板的完整流程转换、量化、算子验证4.1 三步通用流程格式转换、量化、编译运行把模型从训练平台搬到 Arm 设备核心就是三步格式转换、量化、编译运行。每一步都有各自的坑。格式转换是把 PyTorch、TensorFlow 的权重转成目标推理引擎能吃的格式。通用型中间格式是 ONNXllama.cpp 系列统一走 GGUF移动端和 NPU 场景经常用 TFLite。NPU 厂商往往还有私有格式比如把模型编译成 NPU 专用的二进制。我的建议是不要一开始就追求私有格式先在 CPU 上跑通再通过 profile 判断瓶颈最后才考虑要不要把关键算子迁到 NPU 上。量化是端侧部署的常规动作。常见选择是 INT8 和 INT4 家族。INT8 精度损失相对小但内存占用还是偏高INT4 家族里的 Q4_K_M 在 LLM 场景里是甜点体积小、速度好、质量损失可控。量化的坑在于校准数据集用错了校准数据模型精度会掉得莫名其妙而且很难排查。最好用和目标场景接近的数据来校准。编译运行是最后一步。这里最容易出的问题是某些算子不支持量化推理引擎会悄悄把它放回 CPU。你要在日志里确认所有算子都走了硬件加速而不是想当然地以为“编译成功 部署成功”。4.2 动手跑一遍llama.cpp 在 Arm Linux 上部署小模型我拿 llama.cpp 举例这是一条非常成熟的路线。模型用 Qwen2.5-1.5B-Instruct目标板子是 4GB 内存的 aarch64 Linux 设备。在 x86 开发机上先做模型转换和量化# 下载模型权重Hugging Face 或 ModelScope 均可 huggingface-cli download Qwen/Qwen2.5-1.5B-Instruct --local-dir ./qwen # 转成 GGUF 格式 python llama.cpp/convert_hf_to_gguf.py ./qwen --outfile qwen2.5-1.5b-f16.gguf # 量化为 Q4_K_M llama.cpp/build-arm/bin/llama-quantize \ qwen2.5-1.5b-f16.gguf \ qwen2.5-1.5b-q4_k_m.gguf \ Q4_K_M交叉编译 llama.cpp 时最重要的是把工具链指对同时打开 OpenMP 支持。给一份通用示意# 安装 aarch64 交叉编译工具链以 Ubuntu 为例 sudo apt install gcc-aarch64-linux-gnu g-aarch64-linux-gnu # 交叉编译 git clone https://github.com/ggml-org/llama.cpp cd llama.cpp cmake -B build-arm -DCMAKE_BUILD_TYPERelease \ -DCMAKE_C_COMPILERaarch64-linux-gnu-gcc \ -DCMAKE_CXX_COMPILERaarch64-linux-gnu-g \ -DGGML_OPENMPON cmake --build build-arm -j$(nproc)把编译好的llama-cli和量化后的 GGUF 文件拷到板子上直接跑./build-arm/bin/llama-cli \ -m qwen2.5-1.5b-q4_k_m.gguf \ -p 介绍一下 Arm 平台的 AI 部署 \ -n 64 \ -t 4-t 4是线程数。不是越大越好如果板子只有小核或者内存带宽不足线程数开太高反而会变慢这个下面会专门讲。如果板子上的 CPU 支持 dotprod并且你想用 Arm Compute Library 加速可以在 cmake 时加-DGGML_ACLON但前提是你要先编译好对应版本的 ACL。ACL 版本和 llama.cpp 版本不匹配是常见编译报错来源新手不建议一上来就开。4.3 验证算子是否全部“硬件加速”跑通不等于跑好。ONNX Runtime 这类推理引擎有一个特点如果某个算子没有对应执行单元的加速实现它会静默 fallback 到 CPU。你以为用了 NPU结果关键算子还在 CPU 上跑性能自然不对。我自己的检查习惯是两件事。第一打开推理引擎的 verbose 日志看每个算子和执行单元的分配关系。ONNX Runtime 可以通过 session options 打印每个节点 assigned 到哪个 provider。第二用perf看实际 CPU 占用率和访存情况。如果某个算子频繁导致 cache miss说明数据布局不对而不是计算量本身的问题。在 AI Portal 上选模型时优先看有没有“已验证”状态的模型。这类模型通常已经跑过完整的算子映射测试拿到手之后不用再自己排查算子 fallback。如果没有验证状态那就按上面说的流程自检一遍千万别省。5. 性能调优与踩坑记录为什么理论算力那么高实际跑不满5.1 瓶颈定位用 profiler 替代拍脑袋模型跑得慢第一反应往往是“这个模型太重了换个小模型吧”。但很多时候模型本身没问题问题出在瓶颈没有定位清楚。我见过太多人一上来就换轻量化模型结果新模型的精度不达标开始了无穷无尽的调参死循环。正确的做法是先量。time只能告诉你一个粗略的耗时perf能给你更细的数据perf stat -e task-clock,cycles,instructions,cache-misses \ ./build-arm/bin/llama-cli -m qwen2.5-1.5b-q4_k_m.gguf -p test -n 32 -t 4同时要关注 CPU 频率变化。板子经常一跑推理就降频这不是计算不够是散热和功耗墙的问题# 实时查看每个 CPU 核心的当前频率 watch -n 0.5 cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq我自己整理过一个排查表遇到性能问题先对号入座现象常见原因先查什么多线程后性能不升反降内存带宽瓶颈减少线程数用-t 2或-t 4对比设备发烫后明显变慢频率被功耗墙限制scaling_cur_freq和 thermal 日志同一模型不同板子差异巨大指令集不支持走了 fallbacklscpu看 flags检查编译参数prefill 尚可生成 token 很慢生成阶段访存密集换更低 bit 量化或换内存带宽更高的设备5.2 共享内存与数据搬运才是隐藏的大头很多 Arm 板子的 NPU 和 CPU 共用一块 DRAM理论带宽看着不小但实际搬运效率很受内存布局和格式影响。我实测过不少场景推理本身只占三成时间剩下七成都花在数据搬运和格式转换上。最典型的例子是图像模型。OpenCV 读进来的图像是 HWC 布局很多 NPU 要求的是 NHWC 且通道顺序固定有时还需要连续内存对齐。如果你每次推理前都在 CPU 上做cv::cvtColor、resize、permute再拷贝到 NPU buffer前处理耗时经常比 NPU 推理还高。我之前在 RK3588 上调一个 YOLO 模型NPU 理论算力看起来绰绰有余实际延迟却比 CPU 还高。排查半天发现是输入格式来回转换导致。后来把模型输入改成直接接受板子输出的原始格式省掉冗余转换延迟立刻下来一大截。这个经验是能用零拷贝机制尽量用零拷贝至少也要复用 buffer不要每次推理都重新 malloc 和 free 大块内存。数据搬运的优化往往比算子本身的优化更立竿见影。5.3 Arm 编译器不是“GCC 换个壳”参数差别很大交叉编译时很多人随便选一个-mcpu参数就开始了但编译器对微架构的调优能力直接影响最终性能。Arm Compiler for Embedded 6 是基于 LLVM 的自动向量化能力比老一代的 Arm Compiler 5 强不少。新 AI 推理代码建议直接用 AC6 或者 Clang不要守着 AC5 的老工程不放。Linux 侧也同理。-mcpuneoverse-n2这样的参数不只是告诉你“目标 CPU 是 N2”还会让编译器选对流水线、调度模型、SVE 宽度。盲目用-marcharmv8.4-a反而不如-mcpu精准。但这里有一个很关键的坑-mcpu用得太激进编译出来的二进制在老 CPU 上会直接Illegal instruction。比如 Cortex-A57 是 ARMv8.0不支持 dotprod如果你给编译器传了-marcharmv8.2-adotprod哪怕编译器没报错运行时也一定会崩。所以交叉编译时一定要先确认目标设备的实际指令集# 在目标设备上执行查看 CPU Features lscpu | grep Features如果应用要在多种 Arm 设备上跑最好做运行时特性检测。比如在 C 代码里用__ARM_FEATURE_DOTPROD宏做编译期判断或者在运行时通过getauxval(AT_HWCAP)做动态分发。一套二进制要通吃所有 Arm 设备靠的是这种检测机制不能指望编译器凭空变出通用优化。6. AI Portal 对 Arm 生态带来的变化以及我的判断6.1 给独立开发者省下最贵的试错成本独立开发者和小型团队最贵的时间成本不在写代码而在试错。以前我拿到一块新开发板要做的事情是先花两天刷系统装环境再花一天编译推理引擎再花一天测模型最后发现板子的内存带宽根本撑不住目标模型一切都得推倒重来。AI Portal 把“硬件边界条件”和“性能基线”前置了。你在选型阶段就能看到某个模型在某个设备上的延迟、内存占用、量化档位。也许这些数据不完全等于你自己板子的实测结果但至少能帮你把候选模型缩小到两三个再去实测验证。这个信息差在以前要靠真金白银买板子、花大量时间才能换来。我观察到的另一个变化是部署示例会成为新的“API 文档”。现在模型部署领域最大的痛点不是模型不够好而是文档碎片化。模型仓库只给权重推理引擎只给用法工具链只给 API 手册中间的巨大空隙全靠开发者自己填。AI Portal 如果能持续维护端到端的部署示例就相当于把这条路铺好了。6.2 还不够的地方和后续期待当然AI Portal 也不可能解决所有问题。我自己的期待有三点。第一更新频率要跟得上社区。AI 模型迭代速度太快今天热门的大模型过两个月可能就被替代了。如果模型库更新滞后它的参考价值会快速下降。第二社区贡献和基准复核机制。最好的状态是允许开发者上传自己的板子实测数据同时又要有官方复核否则数据噪音会把平台变成另一个众说纷纭的论坛。第三与 NPU 工具链的深度集成。目前 Arm CPU 这条线已经相对完善但各家芯片的 NPU 工具链差异极大。如果后续能做到“从 AI Portal 选一个模型直接生成适配这块板子 NPU 的部署包”那对嵌入式开发者的效率提升将是质的改变。我个人最期待的功能是“模型 × 设备 × 量化方式”的性能表。不需要花哨只需要三列数据延迟、内存峰值、吞吐量。有了这张表端侧模型选型就不用靠猜了。我自己现在的工作流已经变成了这样先在 AI Portal 上以目标板子的内存和指令集为条件把候选模型缩小到两三个然后再去量化、部署、压测。顺序反过来的话很容易在一个模型上折腾一个月最后发现是设备内存带宽顶不住。这大概就是这种模型基地最大的价值——把“先看硬件再选模型”变成了一个可以执行的动作。