AI SoC路线之争：AMD、NVIDIA、高通如何设计端侧智能

如果你同时关注PC、机器人和智能汽车这几个方向这几年会看到一个很有意思的现象各大芯片厂商都在拼命往“AI SoC”上押注但拿出来的方案却五花八门。AMD 的 Ryzen AI 把 NPU 塞进 x86 处理器NVIDIA 的 Jetson Thor 干脆做了一颗独立的机器人“大脑”高通的 Snapdragon X2 则把手机芯片的思路直接搬到了 PC 上。乍一看都是“CPUGPUNPU”的大一统细看之下三家对 AI 计算的理解、对目标场景的判断、甚至对“谁来主导计算”这件事的立场完全不一样。我最早接触这三条产品线是在做边缘推理设备选型的时候。当时手头有一个视觉检测项目需要同时评估 x86 平台和 ARM 平台的能效表现于是把 Ryzen AI、Jetson 和高通的方案都过了一遍。深入研究之后我才意识到所谓“AI SoC 路线分歧”本质上是三个公司对三个问题的不同回答AI 算力应该放在哪里AI 任务应该由谁来调度终端设备到底需要多少算力才够用这篇文章不打算堆参数表而是想从产品定义、架构设计、软件生态和实际落地这几个维度拆一拆这三条路线为什么分道扬镳。顺便也会聊聊我在实际部署中踩过的坑——尤其是 NPU 工具的兼容性问题那个真的能让人怀疑人生。1. 三条路线都在解决什么问题目标场景决定了架构方向1.1 AMD 的选择x86 阵地上的“顺手增援”AMD 做 Ryzen AI 的逻辑其实非常简单直接保住 PC 处理器的基本盘同时给这个基本盘加上 AI 能力。你去看 Ryzen AI 300 系列的结构CPU 还是 Zen 5 那一套GPU 是 RDNA 3.5NPU 则是从 Xilinx 那边继承过来的 XDNA 架构。这个布局的潜台词很明确——AMD 并不想颠覆 PC 的计算模型它只是希望在现有 x86 生态上给 AI 推理任务一个更省电的去处。为什么是“更省电的去处”因为 PC 上的 AI 负载正在从云端向本地转移。比如视频通话的背景虚化、Windows 的 Cocreator 画图、本地大模型的轻度对话这些任务如果全部压在 GPU 上发热和耗电都很难看。放进 NPU 之后CPU 和 GPU 可以腾出来做别的整机续航也能好看一些。说白了Ryzen AI 的核心诉求是“在不对现有计算结构动刀的前提下给 AI 任务安排一个专用的廉价处理器”。这里有个很容易被忽略的点AMD 的 XDNA 架构并不是从零开始做的。收购 Xilinx 之后AMD 直接把 Versal AI Edge 系列里验证过的 AI Engine 阵列搬了过来。这意味着 Ryzen AI 的 NPU 底子其实是一套在嵌入式领域跑了很多年的成熟架构而不是实验室里刚出来的新东西。对于工业级应用来说这种“成熟架构下放”的策略比盲目堆新架构稳妥得多。1.2 NVIDIA 的思路AI SoC 就是“机器人这台电脑”Jetson Thor 的逻辑和 AMD 完全不同。NVIDIA 没有 PC 处理器这个包袱它的目标场景非常聚焦机器人和自动驾驶。这个场景有个特点AI 推理不是“锦上添花”的功能而是“生死攸关”的核心——机器人要实时感知环境、规划路径、执行动作任何一个环节的延迟超标都可能出事故。所以你看 Jetson Thor 的架构它不像 Ryzen AI 那样把 NPU 当作一个“小助手”而是把整个 SoC 都设计成了围绕 AI 计算运转的机器。CPU 仍然是 ARM 核但它的职责更多是调度和管理真正的重头戏是那块基于 Blackwell 架构的 GPU——拥有超过 100 TOPS 的稀疏算力配合 128GB 统一内存和 278 TB/s 的带宽明显是为端侧大模型推理准备的。我打个比方AMD 是把 AI 计算单元当作“办公室里的一个工位”NVIDIA 则是把整个办公室都重新装修成了“AI 专供”。Jetson Thor 的每一个设计决策——内存带宽、互联结构、功耗墙——都在围绕一个问题怎么让大模型在边缘设备上以低延迟跑起来。如果你把它和 Jetson Orin 对比会发现 NVIDIA 的思路在 Thor 上彻底放开了手脚不再只是“给边缘设备加一个 GPU”而是直接造了一台“专为机器人设计的超级计算机”。1.3 高通的野望用手机 SoC 的逻辑重新定义 PCSnapdragon X2 是三条路线里最“跨界”的一个。高通的底子是手机 SoC——也就是把 CPU、GPU、NPU、基带、ISP 全部封装进一颗芯片在严格的功耗预算内实现最大算力。这种设计哲学搬到 PC 上之后最大的优势就是能效比。X2 采用的 Oryon CPU 核心来自 Nuvia 团队这个团队的核心成员原本是给服务器芯片做设计的因此他们的核心在 IPC每时钟周期指令数和能效曲线上都相当激进。但 Snapdragon X2 真正值得关注的不是 CPU而是它的“一体化”思路。手机的 SoC 设计讲究“异构计算”——不同的任务交给不同的计算单元系统调度器统一分配。高通把这套逻辑原封不动搬到了 PC 上再加上它在通信领域的积累X2 从一开始就内置了 5G 基带。这意味着 X2 设备天生就是“始终在线、始终连接”的哪怕在移动场景也能保持低延迟网络。这和传统 PC 那种“偶尔联网”的设计理念是完全不同的。不过这条路也有代价。Windows on ARM 的生态问题始终是悬在高通头上的达摩克利斯之剑。尽管微软和高通在兼容层上下了很多功夫但 x86 应用通过模拟层运行性能折损仍然存在。高通的判断是AI 应用会成为 PC 的新主战场而在这个战场上能效比和集成度比软件生态的存量更重要。这个判断是否成立还需要时间验证。1.4 三个产品的定位差异对照如果非要用一句大白话总结三条路线我会这么说AMD 做的是“让现有 PC 更聪明”NVIDIA 做的是“让机器人拥有自己的大脑”高通做的是“让 PC 变成一台放大版的手机”。维度Ryzen AIJetson ThorSnapdragon X2核心目标PC 本地 AI 推理机器人/自动驾驶端侧推理移动 PC 的 AI连接一体出身架构x86 XDNAARM Blackwell GPUARM Oryon CPU主导计算单元CPU 为中心NPU 辅助GPU 为主导AI 优先异构融合动态调度生态基础Windows/PC 存量生态CUDA/Isaac 机器人生态Windows on ARM 新生态典型功耗区段15-54W15-60W可扩展15-80W算力侧重点平衡型NPU 专用推理极致 GPU 算力与带宽能效比与多模融合这个表格列的只是典型特征实际产品的边界其实有所重叠。比如 Ryzen AI 里面也有 RDNA 3.5 GPU 可以跑 AISnapdragon X2 的 Hexagon NPU 做的推理任务也不少。但路线之间的分歧恰恰就藏在“以谁为主”这件事上。2. 架构设计的分水岭NPU、GPU与CPU之间的权力分配2.1 AMD 的“CPU 主控 NPU 专用化”结构前面提到Ryzen AI 的 NPU 源自 Xilinx 的 AI Engine 阵列。XDNA 架构的本质是一组由上百个 AI Engine 核心构成的二维阵列每个核心都自带指令存储器和数据存储器通过片上网络互连。这种设计的最大特点是它不像 GPU 那样依赖大规模并行线程而是“数据流驱动”——数据从一个核心流向下一个核心每个核心只处理流水线上的一小段。这个设计的好处是对延迟的容忍度极低。GPU 跑推理虽然快但数据要经过显存、调度器、线程块分配等环节延迟会有几十微秒级的波动。XDNA 阵列从设计上就是为固定流水线形状的神经网络准备的数据路径是预先编排好的几乎不存在调度抖动。在实际跑 Stable Diffusion 或者是轻量级 LLM 时Ryzen AI 的 NPU 能做到非常稳定的帧间延迟。但它的局限也很明显灵活度不足。XDNA 阵列擅长处理你能明确画出数据流图的模型但如果模型结构过于复杂、动态分支较多NPU 就有点“力不从心”。AMD 的策略是把这类“复杂但低频”的任务甩给 GPUNPU 只负责“简单但高频”的任务。所以你去看 AMD 官方的推荐负载基本都是背景虚化、语音识别、小模型对话这类场景这就是设计取舍。2.2 NVIDIA 的“GPU 一切 AI 一切”主张Jetson Thor 的路线最激进的地方是它几乎把“AI 算力”直接等同于“GPU 算力”。Blackwell GPU 本身具备 Tensor Core可以执行低精度矩阵运算而 Thor 上的 GPU 核心数量、内存带宽都远超上一代。NVIDIA 在 Jetson 系列上一直坚持一个观点GPU 是最适合 AI 推理的硬件NPU 只是 GPU 能力不足时的妥协方案。这种观点的底气来自于 CUDA 生态。如果你做过边缘部署一定知道 NVIDIA 平台上跑模型有多省心——TensorRT 可以直接把 PyTorch 模型编译成高效的 GPU 引擎算子覆盖率高、优化策略成熟。相比之下NPU 的软件栈远没有这么完善很多算子需要手工适配或者等待厂商更新。对于开发者来说选择 Jetson Thor 意味着你不用重新学习一套依赖 NPU 的推理流程用 CUDA 就能把桌面端的经验直接迁移过去。代价是功耗和成本。GPU 的能效比通常不如专用 NPUJetson Thor 搭载的 128GB 统一内存在 HBM 级别成本上是相当惊人的。但 NVIDIA 的路线判断很明确机器人场景里算力的可靠性和开发效率优先级高于一切功耗反而可以靠系统设计去弥补——比如给机器人配更大的电池或者做异构调度让 GPU 按需启停。2.3 高通的“收敛式异构计算”模型Snapdragon X2 的架构在前面已经提到它最大的特点是“调度器说了算”。X2 内部有 CPUOryon、GPUAdreno、NPUHexagon三大计算单元外加一个系统级别的功耗管理和任务调度器。程序员不是直接指定“这段代码跑在哪个单元上”而是通过 AI 框架的接口把计算图交给高通的后端由后端的图优化器自动决定算子分配到哪个引擎。这套模型的最大优势是灵活性。同一个模型在高负载场景可以由 GPU 跑在低负载场景由 NPU 跑在超级低负载场景甚至可以改由 CPU 跑。高通的调度器会在运行时根据电池电量、发热、任务优先级动态切换。这种思路的本质就是把手机 SoC 成熟的 DVFS动态电压频率调节和多引擎协同策略迁移到 PC 上。但它的劣势也来自“过度自动化”——当调度器做了太多决策开发者就无法精确控制算子的执行路径。我在测试 X2 平台跑开源 Whisper 模型时就遇到过 NPU 后端算子缺失、自动回退到 GPU 但性能利用率只有 60% 的情况。相比之下AMD 和 NVIDIA 的方案至少能给你一个相对确定的执行环境。2.4 三种架构对“AI 任务由谁来算”给出的三个答案用一个生活化的类比来理解AMD 的方案像“用家庭医生处理常规病症”——小病小痛在社区诊所解决只有复杂手术才转去大医院GPUNVIDIA 的方案像“所有检查都去三甲医院”——虽然贵但流程标准化、诊断可靠高通的方案像“智能分诊系统”——先由预检判断你是谁再把患者自动分配给不同科室。架构特征Ryzen AI (XDNA)Jetson Thor (Blackwell GPU)Snapdragon X2 (HexagonGPU)算子执行倾向固定流水线数据流驱动大规模并行可编程性强动态调度按负载迁移延迟稳定性优秀几乎无调度抖动较好受调度策略影响一般受运行状态影响可编程性低到中等高CUDA 生态成熟中等QNN 框架逐步完善能效表现优秀NPU 专攻低功耗场景一般高算力高功耗优秀手机级功耗管理开发者手动控制有限制强几乎完全控制弱依赖自动调度从这张表可以看出三条路线对“谁主导 AI 计算”的立场几乎不可调和。AMD 相信“场景化的专用引擎 CPU 兜底”NVIDIA 相信“GPU 的统一架构能通吃一切”高通相信“调度器比开发者更懂硬件”。三家公司各说各话但每一种选择背后都有真实的市场需求和生态约束在推着它们走。3. 从选型到部署三条路线的实战评测与踩坑记录3.1 环境准备和工具链的差异体验如果你要做真实部署第一步其实是工具链的选择。AMD 的 Ryzen AI 走的是 ONNX Runtime DirectML 这套路径也可以用 AMD 自己的 IPUIntelligent Processing Unit工具链。需要注意AMD 的 NPU 在 Windows 上通过 Windows ML 接口调用在 Linux 上则要通过 Ryzen AI Software 库两套接口的行为并不完全一致。NVIDIA 这边没有太多选择焦虑就是 CUDA TensorRT。即使你用的是 Jetson Thor 这样的嵌入式平台核心流程也和在桌面端几乎一样——PyTorch 训练 → 导出 ONNX → TensorRT 编译 → 推理。这套流程的成熟度是目前端侧 AI 里最高的基本上你在网上能找到的所有模型都有人已经跑通了 TensorRT 版本。高通的工具链相对“年轻”一些主要依靠 AI Hub 和 Qualcomm Neural NetworkQNNSDK。QNN 框架支持 PyTorch、TensorFlow 和 ONNX 的模型转换但算子覆盖率和 TensorRT 还有差距。如果你要部署的模型非常规结构——比如带自定义算子或动态形状的 transformer——在 QNN 上大概率需要做一些图改造工作。3.2 一个图像分类模型的端到端对比我挑一个非常基础的任务来横向对比在三个平台上部署一个 MobileNetV3 图像分类模型输入尺寸 224x224Batch Size 1。这个任务足够简单不会触及各自的极端性能差异但能很好地反映工具链的“顺手程度”。先看 AMD 平台。我在一台 Ryzen AI 9 HX 370 的笔记本上安装了 Ryzen AI Software 1.2模型通过 ONNX Runtime EP执行提供程序加载到 NPU 上。整个流程比较顺利ONNX 模型直接转换即可但有一点要提醒如果你的模型用了自定义算子ONNX Runtime 的 NPU EP 会直接回退到 CPU而且不会给出显式警告只会在日志里留下一行“fallback to CPU”。我在跑一个带有 GeLU 激活函数的视觉模型时就踩过这个坑排查了半小时才发现算子根本没上 NPU。然后是 Jetson Thor。开发环境用的是 JetPack 6.2TensorRT 版本 10.x。流程是把 PyTorch 模型导出为 ONNX然后使用 trtexec 做转换可以选择 FP16 或者 INT8 量化。这一步做得非常顺手trtexec 会对所有算子做兼容性检查如果有不支持的算子会直接给出错误列表不用像 AMD 那样靠猜。实际推理延迟在 TensorRT FP16 下约为 1.1 毫秒考虑到 Thor 的定位这个表现是符合预期的。最后是高通 X2。我用一台搭载 Snapdragon X2 的 Windows 11 ARM 设备安装了 QNN SDK基于 ONNX Runtime QNN EP 部署。我最深的感受是“工具很全但文档很散”——想找到一个针对特定算子的写法往往要翻 GitHub 的 issue 或者官方文档的隐蔽角落。部署后实测延迟约为 2.3 毫秒比 Thor 慢但考虑功耗只有 10W 上下这个能效比其实相当不错。3.3 内存带宽AI SoC 的隐形命门在评测过程中我越来越意识到一个容易被参数表掩盖的因素——内存带宽。跑大模型时算力决定上限但带宽决定实际能到多少。Jetson Thor 之所以敢标榜 278 TB/s 带宽是因为它直接上了 HBM 级别的内存而 AMD 的 Ryzen AI 和骁龙 X2 走的是 LPDDR5X 路线带宽通常在 100 GB/s 上下。这个差距在跑 LLM 时会被放大到非常夸张的程度。举个例子7B 参数的 FP16 模型大小约 14GB要在一个步进内完成一次解码理论最少需要读取 14GB 的数据。如果带宽只有 100 GB/s那么一次 decode 的理论延迟至少是 140 毫秒而在 Thor 的 278 TB/s 带宽下这个数字会被压缩到微秒级当然实际不可能完全打满。所以我在给客户做方案选型时会特别提醒一句如果你的核心场景是跑 7B 以上的大模型Jetson Thor 的带宽优势无可替代如果只是做视觉类的轻量推理Ryzen AI 和 Snapdragon X2 的 LPDDR5X 方案完全够用能效还更好。这个判断基本可以覆盖 80% 的端侧 AI 需求。3.4 一个容易被低估的变量NPU 支持精度还有一个细节在这次评测里给我留下深刻印象——不同平台支持的低精度格式差异。AMD 的 XDNA 2 支持 INT8、FP16、BF16还有自己的 FP8 格式以块浮点形式实现。Jetson Thor 的 Tensor Core 则完整支持 FP8、FP4 等新格式对大规模 LLM 的量化部署相当友好。高通的 Hexagon NPU 目前主打 INT8这也是手机端的主流做法。这个差异看起来简单实际影响很大。INT8 量化对视觉模型是够用的但对 LLM 来说4-bit 和 8-bit 的差距就是“能跑”和“跑不动”的差距。如果你计划在端侧部署一个量化到 4-bit 的 70 亿参数模型这些平台里只有 Jetson Thor 是真正为此做好准备的。AMD 的 FP8 虽然也支持但目前的软件栈对 FP8 模型的支持还不像 INT8 那样成熟。4. 生态才是终局为什么说软件决定了芯片能走多远4.1 CUDA 生态是 NVIDIA 最深的护城河在边缘 AI 的场景里NVIDIA 能被广泛采用除了硬件本身CUDA 生态功不可没。你可以想想一个开发者从 PyTorch 训练模型到部署到嵌入式设备中间涉及到多少工具模型转换ONNX/TensorRT、后量化INT8/FP16、运行时推理TensorRT/Triton、甚至部署后的可视化监控DeepStream/Isaac。这些工具链几乎都有完善的文档和活跃的社区支持问题抛出去基本都能找到答案。这不是一个靠堆工程师就能短期追赶的优势。NPU 的软件栈通常需要芯片厂商自己从零构建每个算子的实现、每个框架的适配、每个平台的测试都需要时间沉淀。AMD 和 高通并非不努力只是 CUDA 生态是一座建了十几年的城NPU 生态还在打地基阶段。4.2 AMD 的“跟随策略”和老实本分的 IPU 生态AMD 其实很聪明地避开了和 CUDA 的正面对抗。它有选择性地把自己的 NPU 生态绑定在 Windows ML、ONNX Runtime 这些开源或行业标准之上。这意味着 AMD 不需要维系一个庞大的专属开发者社区而是借着微软和 ONNX 的势能把 NPU 能力以标准化接口的形式开放出去。这种策略的优点是省力缺点也很明显——过度依赖外部生态会让芯片的特性难以完全发挥。AMD NPU 在跑 ONNX 模型时算子支持度完全取决于 ONNX Runtime 的 EP 实现进度。有时候你会在 ISSUE 列表里看到某个算子已经在“Support”状态但实际跑起来还是回退到 CPU这种滞后是第三方生态合作的常态副产品。4.3 高通的 AI Hub 和一键部署体验高通近两年在软件上的投入非常明显特别是 AI Hub 平台。它提供了一系列预编译好的模型库覆盖了视觉、语音、生成式 AI 等主流应用。你可以在 AI Hub 上选择模型直接下载针对骁龙平台的优化版本配合 QNN 的运行时快速部署。这个体验已经很接近“一键”了对不想折腾底层算子的开发者来说相当友好。但 AI Hub 目前覆盖的模型池仍然有限尤其是一些社区小众模型或者最新发布的架构往往没有预优化版本。我测试过部署 Llama-3.2 3B 模型AI Hub 没有直接提供现成版本需要自己通过 QNN 完成转换和量化整个过程花了大半天其中大部分时间花在解决算子兼容和量化校准上。高通的生态建设方向是对的但离“无脑部署”还有一段距离。4.4 对未来端侧 AI 生态的一点个人判断我个人观察是未来两三年里端侧 AI 的生态会呈现出“分层共融”的格局。重载的、复杂的、需要高可靠性的 AI 任务会继续流向 CUDA/TensorRT 体系轻量的、高频的、与操作系统深度集成的任务会在 NPU 体系里沉淀下来。AMD 和 高通都清楚自己不可能取代 CUDA但它们在努力让 NPU 成为一个值得开发者投入的“第二选择”。在这个过程中谁能提供更“无感”的开发体验谁就能抢占更多的终端生态。AMD 靠的是和微软的深度绑定高通靠的是手机 SoC 时代的调度经验NVIDIA 靠的是从云端一路延伸到边缘的完整工具链。每家的打法和底牌都不一样但目标殊途同归——让 AI 计算在合适的场景里用合适的硬件以合适的成本跑起来。5. 常见问题与选型避坑实录一个实战派的自查清单5.1 我的模型在 NPU 上跑得比 CPU 还慢这正常吗这个现象非常常见通常有两个原因。一是模型太小数据搬运和调度开销超过了 NPU 算力节省的时间这种情况几乎不可能通过优化代码逆转只能接受二是模型算子大量回退到 CPU导致 NPU 实际只执行了部分计算——这时候你需要打开性能剖析工具AMD 可以用 Ryzen AI Profiler高通可以用 QNN ProfilerNVIDIA 自然是用 Nsight看清楚每条算子的实际执行硬件。5.2 三家的 NPU 能否直接复用同一套代码不能。虽然 ONNX Runtime 在三个平台上都提供了对应的 EP但每个 EP 对算子支持度、量化要求、内存布局的要求都不一样。一个模型在 AMD 上跑得好好的直接切到高通可能需要重新量化。如果你有跨平台部署的需求建议在一开始就用 ONNX 作为中间格式不要绑定任何一家专有的 SDK 接口这样迁移成本会低很多。5.3 如何判断我的边缘项目应该选哪条路线我一般会问三个问题。第一你的模型最终规模有多大如果超过 7B 参数Jetson Thor 几乎是唯一适合端侧真实部署的选择。第二你的功耗预算和散热条件怎么样如果是一个无风扇的轻薄设备Snapdragon X2 和 Ryzen AI 显然更现实Thunder 的 60W 级功耗在工业级设备里也需要认真考虑散热方案。第三你的团队更熟悉哪种生态如果你已经熟练使用 CUDA选 NVIDIA 不需要额外学习成本如果你们本来就在 Windows 平台上做 AI那 AMD 或者高通与 Windows ML 的协同会更顺手一些。5.4 量化模型时总掉精度有什么经验可以分享我的经验是不要一上来就追求 4-bit 或者 FP8先用 FP16 跑通基线确计算精度和延迟再逐步降低位宽。而且量化校准数据集一定要贴近真实场景最好是从现场收集的样本——用网上公开数据集做校准部署后常常会遇到精度滑坡这个我在实际项目里吃过不止一次亏。另外对量化敏感的模型比如含有注意力层的建议在关键算子层使用混合精度虽然麻烦一点但效果明显。5.5 NPU 部署需要掌握哪些最低限度的基本功我认为有三项是必须会的一是看懂性能剖析报告知道算子在哪个硬件上执行、耗时多少、带宽利用率多少二是理解量化原理知道 INT8 和 FP16 的差异以及校准数据的意义三是会写模型导出脚本至少能把 PyTorch 或者 TensorFlow 模型正确转成 ONNX。这三项能力在任何 AI SoC 平台上都是通用的学会了就不会被厂商绑定。6. 关于这次横向评测的最后几句心里话写到这里我想把话题从技术稍微拉远一点。这三家厂商选择不同的 AI SoC 路线本质上不是谁比谁更高明而是各自的基因和手里面的牌决定了他们会走出完全不同的路。AMD 手里握着 x86 存量市场和 Xilinx 的 IP 库它的保守和渐进主义非常合理NVIDIA 手里握着强大的 GPU 架构和 CUDA 生态它的激进和高投入也有底气高通手里握着移动端最成熟的异构调度经验和连接技术它的跨界更像是一次顺理成章的升维。对于做实际项目的朋友我的建议是别急着站队。芯片选型这件事没有“最好的架构”只有“最适合你场景的架构”。把模型规模、功耗约束、开发团队技术栈、量产的维护成本这几个维度拉一张表一个维度一个维度地去打分比听厂商讲路线故事靠谱得多。我在做这次横向评测时也重新反思了一下自己以前的选型判断。以前我总觉得 TOPS 数字越大越好带宽越高越好后来真正落到具体项目里才发现工具链的成熟度和团队的学习成本才是决定项目进度的隐性变量。选了一个再强的 NPU如果团队花了两周还跑不通一个 deploy 流程整个项目的节奏都会被拖垮。最后分享一个个人习惯拿到任何新的 AI SoC 开发板我做的第一件事都是在上面完整部署一遍 YOLOv8s 的 INT8 量化模型记录延迟和功耗然后跑一遍 llama.cpp 的 3B 模型测一下内存带宽的实际表现。这两个测试做完这张板子的性格基本就摸透了。以后换平台、做选型的时候我都拿这两组数据做基线对比反而比看官方 PPT 里的宣传数字靠谱得多。