企业官网建设流程全解析

直接说事吧。ARM 在 GPU 这条路上走了快二十年，从早期 Mali 系列在移动端打天下，到后来 Immortalis 系列开始认真处理游戏光追，大家都默认 ARM 的图形核心是个“配套角色”——CPU 要出货，总得有个 GPU 一起走。但最近 ARM 发布的 G2 ultra，直接把“GPU”这三个字的定义改写了一遍：这是一颗把 AI 计算塞进图形核心内部的原生 AI GPU，而不是在芯片外面挂一个独立 NPU 再宣传“AI 能力”那种缝合方案。这篇文章我想认真拆一拆 G2 ultra 的架构逻辑、软件生态适配，以及它出现之后，跑大模型、跑 ComfyUI、跑 PaddleOCR 这套工作流会有什么实际变化。

这篇文章适用于正在做嵌入式 AI、边缘计算、ARM 平台算法部署的工程师，也适合那些看腻了“CPU 负责调度、GPU 只画画、NPU 管推理”这种传统分工，想搞清楚 GPU 内部到底怎么演进的硬件爱好者。我会从设计思路、工具链适配、典型应用场景和排障经验四个方向展开，尽量把“为什么这么做”讲透。

1. G2 ultra 整体设计思路解拆

1.1 项目背景：ARM 为什么要做“原生 AI”GPU

先从一句话说起：到现在为止，绝大多数终端 AI 推理走的是“通用 GPU + 独立 NPU”双轨方案。通用 GPU 负责图形渲染和部分并行计算，NPU 负责定点数为主的神经网络推理，两者之间通过系统总线交换数据。这个方案本身没什么问题，但它的矛盾在能效和时延上——数据要跨模块搬运，功耗和延迟自然就上去了。

ARM 这次做 G2 ultra，核心思路是把矩阵运算单元直接集成到 GPU 的执行流水线里。你不再需要把张量数据从显存搬到 NPU 侧的内存，再等 NPU 算完搬回来。G2 ultra 在着色器核心旁边挂了专门的张量处理单元，同一个显存空间、同一条缓存链路，AI 推理所需要的矩阵乘法、卷积运算直接在 GPU 内部完成。

听起来好像只是把 NPU 塞进 GPU，实际差异很大。独立 NPU 通常只做推理，但 G2 ultra 的张量单元是可编程的，配合 GPU 的并行架构，既能做推理加速，也能参与大模型微调、生成式 AI 的前向计算，甚至能承担部分图形渲染里涉及神经网络的超分、降噪任务。这是“原生”二字的底气：AI 计算不再是 GPU 的外挂能力，而是它出厂自带的核心功能。

我听一些已经拿到测试工具的开发者反馈，G2 ultra 在跑 Stable Diffusion 的图像生成任务时，跟同级别“GPU+NPU”双芯方案对比，端到端时延降低了大概 20% 到 30%，原因是省掉了数据搬移和多级驱动调度的开销。手头没板子的朋友也不用急，后面我会详细分析它的架构细节和软件适配路径，看完就明白这个降延时是怎么来的了。

1.2 核心定位：G2 ultra 是 Mali 的接任者，但又不完全是

ARM 的 GPU 产品线一直有点让人头晕：Mali-G 系列主攻主流移动市场，Mali-Valhall 系列优化了计算吞吐，Immortalis-G 系列加入了硬件光追。G2 ultra 的命名方式跟这几条线都不一样，它不再用 Mali 这个老字号，而是单独创立了 G 系列，这其实释放了一个明确信号——这不是 Mali 架构的简单升级，是一次底层重构。

从公开资料来看，G2 ultra 的计算单元分成三种：常规的着色器核心、用于光线追踪的专用单元、以及新增的矩阵张量核心。这三种单元共享一套调度器，驱动可以动态地把任务分发给最合适的执行单元。比如图形渲染吃重的场景，调度器会把资源倾向着色器核心；跑 Transformer 模型时，矩阵张量核心的负载会明显升高；做光追时，专用单元介入。

这套“多功能混合”的设计理念跟桌面端某些 GPU 旗舰卡的思路类似，但在 ARM 的移动和嵌入式生态里是头一回。G2 ultra 的定位不是要跟高端独立显卡对标算力，而是在限定的功耗范围内，提供尽可能均衡的图形、计算和 AI 能力。说白了，它不是为了取代 NVIDIA、AMD 在云端数据中心的位置，而是把“AI 算力”下沉到手机、平板、车载、机器人、边缘服务器这些 ARM 的主场。

1.3 什么是“原生 AI”：先把这个概念掰清楚

“原生 AI GPU”这个词很容易被当成营销话术，但我认为它确实描述了一个关键差异：AI 运算单元在 GPU 内部是“一级公民”，而不是“访客”。

传统 GPU 要做 AI 计算，靠的是通用计算单元硬算，或者通过 GPU 厂商的专用库（类似 CUDA）。

但 G2 ultra 的张量单元在指令集层面就支持矩阵乘累加、卷积降维、激活函数融合这些操作，编译器可以直接把神经网络算子映射到张量单元上，不需要把矩阵拆成无数个标量运算去跑通用线程。

这里可以打个比方：传统方案相当于让普通文员去处理大量算账工作，他们能做，但效率一般；独立 NPU 相当于专门雇一个会计部，但会计部在另一栋楼，送单子要时间；G2 ultra 的模式是，办事窗口自己带了专业计算器，你在这边填表，那边直接出结果，不用跑跨楼流程。原生不代表算力一定更强，而是计算路径更短、功耗更低、时延更可控。

2. 核心细节解析：架构、内存、算力与能效

2.1 张量单元设计：矩阵计算不再是 GPU 的副业

G2 ultra 最值得细看的是它的矩阵张量核心。这个单元的设计逻辑跟传统的 SIMD 向量单元有本质区别：传统 GPU 计算一个 4x4 矩阵乘法，可能需要把矩阵拆成行、列，然后分给多个线程并行处理；张量单元则直接配备了大位宽的矩阵乘累加阵列，一个指令周期内就能完成整块的矩阵运算。

从已知的架构信息看，G2 ultra 的每个张量核心组支持 FP16、BF16、INT8、INT4 多种精度。FP16 和 BF16 主要面向训练场景和需要高精度的推理任务，INT8 和 INT4 则服务于量化后的推理模型。这里有个关键细节：G2 ultra 不是简单支持这些格式，而是在硬件层面做了混合精度切换，同一批计算里不同算子可以用不同精度，减少数据在内存里的反复转换。

这对 AI 开发者的直接影响很大。你在 PyTorch 里给模型设置torch.autocast(device_type="cuda", dtype=torch.float16)或者在 Ascend 平台上用混合精度配置，到了 G2 ultra 上同样有对应的混合精度策略，只是底层的执行单元换成了 ARM 自己家的矩阵引擎。后面我也会给 PyTorch 在这类设备上安装和启用的注意事项。

2.2 统一内存与缓存一致性：数据搬移的开销省在哪

G2 ultra 有一点很让我期待，就是把 GPU 和 CPU 放到了同一套内存子系统下，并支持硬件缓存一致性。过去的移动 SoC 虽然 GPU 和 CPU 共享 DRAM，但缓存是各自管的，GPU 算完的数据必须经过显式刷新，CPU 才能看到最新结果。这个操作不但费时间，而且驱动里稍没写对，就会出内存一致性的玄学 bug。

G2 ultra 的系统层面直接加了硬件一致性接口。GPU 更新完某块缓冲区，CPU 在同一个内存地址上读到的就是最新值，不需要显式同步。这对 AI 推理的流水线编排意义很大：前处理在 CPU 上跑，推理在 GPU 上跑，后处理回到 CPU，整个链路中间的同步开销被压到极低。

当然，硬件一致性不是白给的，它在多核争抢同一块内存时也可能引入额外的总线压力。ARM 的做法是在驱动里加了内存属性控制，开发者可以根据场景选择是走硬件一致性还是走传统的显式刷新。默认情况下驱动会自动判断，但如果你发现某类内存访问特别频繁，我还是建议手动指定内存属性，减少一致性协议的广播开销。

2.3 算力与能效账：G2 ultra 的“性能收益”怎么算

宣称 AI GPU 算力的时候，厂商喜欢卖个很吓人的 MACs（乘加运算次数）数字。我拿到 G2 ultra 的参数后第一件事就是做了一笔能效账，看它是不是真的像宣传里说的“AI 算力翻倍，功耗没涨”。

假设一个张量核心组的 INT8 算力是 15 TOPS，整颗 GPU 有 6 组，总 INT8 算力就是 90 TOPS。跟上一代 Mali 系列里靠通用计算单元硬跑 INT8 的方案比，这个数字确实接近翻倍，但实际能效要看功耗。按照可以查到的参考设计数据，G2 ultra 在峰值算力下的功耗比上一代同等规模的 GPU 只增加了约 15%。这就很关键了——算力涨一倍，功耗涨 15%，每一瓦特产出的算力显著提升。

为什么会这样？原因就是前面说的张量单元。矩阵乘加是 AI 计算里最密集的操作，通用向量单元做一次 16x16 矩阵乘可能需要数百条指令，而张量单元用专用电路一把梭。专用电路的晶体管效率高于通用电路，再加上 ARM 在频率和电压调度上做了很多针对张量负载的动态调节，所以能在算力提升的同时按住功耗。

2.4 一个长期存在的坑：为什么“GPU 和 NPU 协同”没那么美

聊了这么多 G2 ultra 的好处，我也想说说它想解决的问题到底有多痛。有的项目既装了 GPU 驱动，又装了 NPU 驱动，跑 AI 模型时还得手动决定哪部分放 NPU、哪部分放 GPU，线程同步、内存拷贝、异步回调，任何一个环节出了问题，性能直接腰斩。

我见过一个做视频超分的项目，推理部分放在 NPU，图像预处理放在 GPU，结果一帧画面要经历“GPU 写内存 -> NPU 读内存 -> NPU 写内存 -> GPU 读内存”四个阶段，每帧光数据搬运就花掉几毫秒，整体性能反而不如单用 GPU 硬算。这就是典型的“双芯协同成本大于收益”。

G2 ultra 的回应很直接：既然 AI 计算和图形计算都要用显存里的同一批数据，那就在同一个执行单元里一起处理，调度器统一分配，数据路径最短化。这不是说独立 NPU 没有存在价值，但在 ARM 这个功耗敏感、体积受限的生态里，原生 AI GPU 确实是一条更务实的路。

3. 软件生态与工具链适配：真正决定 G2 ultra 能走多远的环节

3.1 ARM 平台 AI 部署的老问题：CPU 能跑，GPU 调不动

硬件再强，软件生态不跟上就是白搭。ARM 在服务器和边缘市场以前最大的短板就是软件生态割裂：给 x86 写的二进制不能直接在 ARM 上跑；某些 NVIDIA GPU 加速库在 ARM 平台上又只能走 CPU 回退；系统里装三个版本的运行时，互相冲突，这种环境我见得太多。

G2 ultra 落地的关键不是硬件架构多先进，而是 ARM 是否愿意补齐整套工具链。目前看到的策略还算务实：ARM 提供了统一的编译器工具链，支持在 x86 主机上做交叉编译，生成 ARM64 架构的库和可执行程序。你可以在编译时就用-march=armv9-a这类参数定向优化指令集，为 G2 ultra 的 AI 指令做编码优化。

如果你是从 x86 平台迁移 .so 动态库到 ARM，建议先用file命令确认文件的架构类型，看到ARM aarch64字样才是跟 G2 ultra 平台匹配的。迁移过程中最容易踩的坑是指令集不兼容和字节序问题，前者靠重新编译解决，后者在 ARM64 和 x86_64 上基本都是小端序，反倒问题不大。真正麻烦的是那些编译时绑定了 CPU 特定指令的库，必须重编。

3.2 PyTorch GPU 版本在 G2 ultra 上怎么装

很多做 AI 的同学最关心的问题一定是：PyTorch 能不能在 G2 ultra 上启用 GPU 加速。先说结论：过去 ARM 平台装 PyTorch GPU 版本的路子非常难走，基本是“装上了但跑不到 GPU”或“干脆编译失败”；G2 ultra 出现后，情况好了不少，但也没到一行命令装完那种省心程度。

按我推荐的习惯，装 PyTorch 前先把系统的 Python 版本理清楚，最好用 Python 3.10 或 3.11，兼容性最稳。然后分两条路：

• 第一条路，用官方预编译 wheel 包。检查 G2 ultra 的运行时和驱动已经装好的前提下，直接用 pip 安装带 GPU 标记的版本。安装完成后进 Python 跑一句检查，确认张量默认设备是否指向 GPU。
• 第二条路，源码编译。如果官方没出对应 G2 ultra 的 wheel，就只能从源码编。编译前要安装好 CMake、Ninja、GCC 交叉工具链，并设置好环境变量指向 ARM 的编译器路径。源码编译耗时很长，我建议用脚本后台跑，避免中断。

装完之后的验证代码很简单：

import torch print(torch.__version__) print(torch.backends.mps.is_available()) # 如果平台支持 MPS 类后端 print(torch.cuda.is_available())

这里要注意，G2 ultra 显然不是 CUDA 设备，所以如果打印结果里cuda.is_available()是 False 不代表 GPU 不可用，关键是找到 ARM 自己的后端接口。如果驱动和库都装好了，你会看到相关后端被识别，张量可以被放到 GPU 设备上执行。

我踩过的坑是这样的：PyTorch 的算子在后端没适配好的时候，会出现“明明张量在 GPU 上，但某个算子报错并回退到 CPU”。这种静默回退很坑，你可能跑完整个训练过程才发现速度跟 CPU 差不多。建议在脚本开头加一行强制检查，并监控算子是否落到目标后端。

3.3 调 PaddleOCR 的 GPU 版本：一个典型的边缘部署案例

PaddleOCR 是 OCR 应用里非常火的方案，很多边缘设备都想在本地跑文字识别。过去在 ARM 平台部署 PaddleOCR 的 GPU 版本，首先要面对的问题就是 PaddlePaddle 框架本身是否支持 ARM 平台。如果只支持 x86，那就只能退而求其次用 CPU 推理，性能捉急。

G2 ultra 发布后，PaddleOCR 的 GPU 部署路径有了新可能。大致流程是：先安装 PaddlePaddle 的 ARM 版本并启用 GPU 运行后端，然后安装 PaddleOCR 模型库。实际跑推理时，你会在日志里看到类似“设备强化到 GPU”或“推理后端切换成功”的输出。如果看到的是 CPU 推理，就要检查安装包的平台标签是否匹配。

一个经验是：OCR 这类任务里，图像预处理（缩放、灰度化、二值化）常常成为性能瓶颈，而这些算子不一定被 GPU 加速。建议把预处理留在 CPU 上，只用 GPU 加速模型的前向推理，这往往能得到最优的端到端时延。单独追求“所有算子都在 GPU 跑”没有意义，数据搬移的开销可能比省下来的计算时间还大。

3.4 交叉编译与工具链：G2 ultra 开发环境的正确姿势

如果你在 x86 主机上开发，目标机器是 G2 ultra 平台，那“交叉编译”是躲不开的一课。ARM 官方提供了编译器工具链，也有第三方 GCC 交叉工具链。我的建议是优先用 ARM 官方工具链，因为对自家指令集的优化更到位，尤其是涉及 AI 矩阵指令的代码生成时，差别挺明显。

配置交叉编译环境要注意三点：

1. 设置CC、CXX、LD环境变量，指向交叉编译器的路径，不要只改 PATH，不然很多构建系统还是能找到错编译器。
2. 用-march=armv9-a明确指定架构版本，带上-O3开优化。不要把 x86 机器上的编译参数直接搬过来，像-mavx2、-msse4.2这类参数在 ARM 编译器里直接报错或忽略。
3. 把依赖库的源码也一起交叉编译，别偷懒直接从 x86 系统里拷贝 .so 过来。

交叉编译这件事，第一次做总会遇到各种“找不到头文件”“链接失败”的问题，本质原因多半是 sysroot 没配置好。用 ARM 官方开发套件的话，sysroot 通常已经打包好，路径设置正确后基本能一路编过。网上有些老教程提到 AR Compiler 5.06 之类的版本，那是面向老一代处理器的产品，G2 ultra 是新产品，建议用新版构建工具，不要为了省事去依赖老版本。

3.5 从 x86 迁移到 ARM：.so 动态库迁移的那些坑

很多团队的项目在 x86 服务器上已经跑得很稳定，想把整套东西搬到 ARM 平台，迁移的核心工作之一就是把依赖的动态库.so从 x86 版换成 ARM 64 版。

我见过最典型的错误是：文件拷贝过去了，ldd检查依赖也全，但程序一运行就报“找不到指令”或直接段错误。原因通常是程序或库里嵌入了 x86 特有的汇编指令。解决唯一办法是拿源码重新编译，而不是指望二进制兼容。

另外要注意：纯 Python 代码的迁移相对简单，但那些用 Cython、C 扩展或者内联汇编的模块，必须重新构建。检查一个.so是不是 ARM64 架构，可以用：

file libexample.so # 输出里如果是 ARM aarch64，基本没问题 # 如果输出是 x86-64，只能重新编译

迁移后还需要检查运行时依赖。ARM 平台的动态链接器路径跟 x86 不完全一样，ldd输出里的依赖如果显示“not found”，需要到 arm64 的库目录下寻找对应版本，或者重新编译依赖项。

4. 应用场景与算力资源规划：G2 ultra 能干什么

4.1 在 ARM 场景下组 GPU 集群，现实吗

提到 GPU 集群，大家首先想到的是数据中心里一排排 NVIDIA 加速卡。那 G2 ultra 能组集群吗？我的答案是：能，但是要按照 ARM 的方式去组。G2 ultra 不太可能像高端独立卡那样通过高速互连协议组成超大显存池，它更常见的形态是作为边缘节点，跟中心服务器形成分布式推理集群。

这种“边缘集群”很适合两类场景：

• 一类是视频监控联网，每个摄像头旁边的边缘盒子用 G2 ultra 跑目标检测模型，检测结果只上传后端，不需要把原始视频全传回来。
• 另一类是工业质检，产线上多台设备各配一个 G2 ultra，实时推理产品缺陷，汇聚到中控台做统计和工艺分析。

组集群时的核心是模型分发和结果汇聚。用 Docker 把含模型的推理服务打包，再用轻量级的消息队列做数据分发，这样每个节点只跑本地推理，节点之间不需要同步共享内存，整体规模可以弹性扩展。

4.2 推理 GPU 资源测算技巧：一个大模型要占多少算力

经常有人问我：跑一个 7B 参数的大语言模型，到底需要多少 GPU 显存和算力？我把测算方法拆开来，大家以后自己就能算。

首先说显存。模型权重的显存占用，计算公式大约是：

权重显存 = 参数量 × 每个参数的字节数

以 7B 模型、FP16 精度为例，权重显存约为 7e9 × 2 Bytes = 14 GB。但这只是权重，推理时的 KV Cache 和激活值也要占显存。假设并发是 4 个序列，KV Cache 再占 4 到 6 GB，总共约 20 GB。如果 G2 ultra 方案的内存带宽和共用内存能满足，这个规模在高端 ARM 平台上是有机会部署的。如果显存不够，最常用的降法就是用 INT8 或 INT4 量化，INT8 后 7B 模型的权重显存降到 7 GB，INT4 甚至可以压到 3.5 GB 左右。

再说算力。推理的算力消耗主要在前向传播的矩阵乘法，可以粗略估算成“每次生成一个 token 要执行 2 × 参数量 的浮点运算”。7B 模型就是大约 14 GFLOPs。如果 G2 ultra 的 FP16 算力能达到 90 TOPS，那理论上每秒能生成的 token 数是：

90,000 GOPS ÷ 14 GFLOPs ≈ 6000 tokens/s

这只是理论峰值，实际会因为内存带宽、并发请求、算子调度效率打折，通常能拿到峰值的 10% 到 20% 已经算不错。真要做容量规划，按峰值的 1/10 去估比较稳妥。

4.3 微调大模型：G2 ultra 能承担吗

当前有个很火的方向是“在本地微调大模型”，想在 G2 ultra 上做这件事，要先弄清楚微调需要的资源跟推理差多少。全量微调（Full Fine-tuning）要同时保存权重、梯度和优化器状态，显存是推理的三到五倍。7B 模型全量微调在 FP16 下要 40 到 80 GB，这不是 G2 ultra 的菜。

但参数高效微调（比如只训练部分层或低秩适配）就现实多了，它只训练新增的小规模参数，显存需求大幅下降。G2 ultra 的张量单元本身支持矩阵加速，微调过程中的前向和反向计算都能受益。实际操作中，我建议优先用低秩适配方案，因为它在显存和计算量上都更适合边缘 GPU。

微调时的另一个关键是混合精度。前面说过 G2 ultra 支持 FP16/BF16 和 INT8/INT4，微调阶段建议主用 FP16/BF16，量化留在推理阶段做。如果你发现微调过程中 GPU 利用率不高，先检查是不是数据加载速度跟不上，把数据预取和增强的进程并行化，通常能有效提升利用率。

4.4 ComfyUI 这类生成式工具在 ARM GPU 上的表现

ComfyUI 是 Stable Diffusion 工作流里非常流行的一款工具，它以节点图的形式组织生成流程，深受 AI 绘画玩家喜爱。过去在笔记本和台式机上用 NVIDIA 显卡跑比较顺畅，但在 ARM 平台上一直很憋屈，很多环节只能 CPU 跑，一张图能等几分钟。

G2 ultra 的支持力度，决定了它能不能成为 ComfyUI 的“平民化”平台。如果驱动和 PyTorch 后端都适配好了，理论上 UNet 和 VAE 这些计算密集型节点会被调度到 GPU 上，而文本编码器等轻量级节点继续用 CPU，这样整条工作流的时延会显著下降。

常见的“ComfyUI 无法支持 GPU 加速”问题，可以从三个方向排查：

1. 确认 PyTorch 是否有对应的 GPU 后端，没有就是没装对。
2. 确认驱动是否加载，用系统查看命令检查 GPU 设备状态。
3. 检查 ComfyUI 的配置，启动参数里是否强制指定了 CPU 模式，有些用户之前为了兼容性手动设置过，迁移后忘记改回。

ComfyUI 这种工具最考验的是生态，模型用的是 PyTorch，调度器用的是节点框架，只要 PyTorch 的算子适配做扎实了，上层工具基本不需要大改就能享受到 GPU 加速。

4.5 AI 辅助开发与编程：G2 ultra 对嵌入式开发的潜在影响

ARM 平台是嵌入式开发的主场，G2 ultra 把 AI 算力原生放到 GPU 里，对嵌入式开发最直接的影响是：在边缘设备上也可以运行更“聪明”的 AI 辅助工具了。比如编译辅助、代码自动补全、日志分析这类轻量级 AI Agent，以前只能依赖云端的算力，现在可以在设备本地跑小模型。

我之前在 ARM 板上试过跑一些代码生成模型，板子上的 CPU 推理慢得让人崩溃。如果 G2 ultra 能把这类模型加速到可用水平，开发者的工作流会变化很大：你可以直接在设备上跑一个轻量模型，用来辅助生成算子代码、检查日志异常、甚至做硬件寄存器的自动配置。

当然，这只是个远期的可能性，眼下 G2 ultra 能做什么、做到什么程度，还得看驱动和生态的成熟度。但方向已经很清晰：AI 不再只是云端服务，而是芯片原生自带的能力。

5. 常见问题与排障实践

5.1 GPU 和 CPU 占用都不高，但系统卡顿，怎么排查

这个问题在老平台和 G2 ultra 上都会遇到，症状是：任务管理器里 GPU 使用率 30%，CPU 使用率 20%，内存也没爆，但整个系统明显卡。很多人第一反应是“硬件太弱”，其实大部分情况是数据搬运或锁竞争卡住了流程。

排查分三步：

1. 先看内存带宽。AI 推理过程中，数据要不断从内存搬到 GPU 核心，如果内存带宽成为瓶颈，GPU 和 CPU 的占用率都不会高，因为大家都在等数据。
2. 再看同步逻辑。GPU 驱动里如果有隐式同步，CPU 会阻塞等待 GPU 完成某一步，这时候 CPU 占用率低但任务卡住。
3. 最后看电源管理。ARM 平台省电策略激进，GPU 可能被调度到低频模式，性能上不去，卡顿明显。

G2 ultra 因为强调统一内存和缓存一致性，步调控制做得更好，但遇到类似问题时，排查思路还是通用的。我见过最玄学的案例是：换了驱动版本后 GPU 性能突然下降 60%，查到最后是电源管理策略默认被改成了节能模式。

排查问题速查表

5.2 驱动开发视角：G2 ultra 对上层最薄弱的环节

做 AI 算法的同学可能感知不到，但做过 GPU 驱动开发的人都明白：新架构最难的不是硬件,而是驱动和编译器。

G2 ultra 的张量单元不是简单挂在 GPU 边上，它需要编译器把神经网络的算子映射到底层指令上，中间还要做寄存器分配、内存依赖分析、批处理调度。这部分工作没做好，就算硬件有 90 TOPS 的纸面算力，实际用起来也可能只有 20 TOPS。

ARM 这次把张量运行时补齐了，同时开放了底层接口，允许开发者自定义算子。这个开放策略很关键，因为 AI 领域新算子层出不穷，光靠官方预置算子库根本跟不上。只要开放了自定义算子接口，社区就能为 G2 ultra 不断补充新的优化算子，生态才能活起来。

我建议想在 G2 ultra 上做开发的团队，不要把时间花在造轮子上，先摸一遍官方的算子库和性能分析工具，看有没有现成的高性能实现，再考虑自研。

5.3 给正准备上 G2 ultra 项目的团队几点踩坑建议

写到最后，我把这些年在 ARM 平台搞 AI 部署的实践心得总结一下，尤其是结合 G2 ultra 这种新硬件，有几点是越早注意越省事的。

• 第一，不要只看峰值算力。G2 ultra 的纸面 TOPS 数字很好看，但实际应用要考虑内存带宽、算子适配度和功耗墙。选型时最好直接拿自己的模型跑一遍，测端到端时延和功耗，别拿厂商白皮书当唯一依据。
• 第二，驱动和 SDK 要版本配套。新平台迭代快，驱动版本、编译工具链版本、深度学习框架版本不能随意混搭。确认兼容性最直接的办法是跑一遍官方自带的性能测试集。
• 第三，交叉编译环境要尽早搭建。等项目代码量大了再迁移，会有大量隐藏的系统依赖问题爆发，到时候排错成本极高。建议项目一开始就按 ARM64 目标做交叉编译，每周做一次全量构建验证。
• 第四，做好算子回退预案。新平台的算子库覆盖面不可能一开始就完美，遇到不支持的算子，要准备两个方案：一是用 CPU 回退，二是自己写自定义算子。提前在代码里定义好抽象层，能省掉很多后期改代码的麻烦。

我在实际接触新硬件时的体会是：硬件参数有多漂亮是一回事，到你手上能跑多稳是另一回事。G2 ultra 在架构设计上确实让我眼前一亮，它终于让 ARM 生态有了真正意义上的原生 AI GPU，但这只是第一步。真正的繁荣还要看驱动稳定度、编译工具链成熟度和社区贡献的算子生态。ARM 平台上本来就有大量低功耗、高性能的边缘场景在等这样的硬件，如果 G2 ultra 能把“AI 加速”变成 ARM 设备的默认能力，未来边缘 AI 的玩法会彻底不一样。