我先说我为什么想写这篇东西。过去一年我陆续参与了几个具身智能相关的项目有轮式底盘加机械臂的复合机器人有做电力巡检的四旋翼还有一个在研的室内服务机器人原型。这些项目有个共同点——算法在PC上跑得好好的一搬到端侧帧率崩了、内存爆了、芯片烫得能煎蛋。最离谱的一次我们买了一块标称 100TOPS 的板子结果部署一个轻量级的语义分割模型跑起来只有 9fps。后来查了一圈问题出在硬件选型阶段——我们压根没搞清楚“标称算力”和“实际可用算力”之间的差距。这篇文章就是把这一年多来在端侧 AI 算力选型上踩过的坑、实测过的数据、以及最后沉淀下来的一套选型思路完整记录下来。目标读者是正在做具身智能车载/机载或者说一切端侧移动设备部署的工程师、项目负责人。内容覆盖芯片标定参数的解读、真实负载的算力换算、主流几款端侧算力平台的实测对比、内存带宽与工具链的隐性坑以及最后给出两个典型项目的可直接参考的配置方案。如果你正卡在“不知道怎么选芯片”或者“买了板子跑不动模型”这个阶段这篇文章应该能帮你省下至少一两个月的试错时间。1. 为什么标称 TOPS 和实际可用算力是两回事——算力标定的三个隐藏前提先说一个反直觉的事实芯片厂商标称的 TOPS几乎都不是你部署模型时能跑出来的算力。拿我们在项目中用过的几款芯片来说标称 100TOPS 的中高端板子实际跑我们自己的模型能达到 25-40TOPS 的等效吞吐就算不错了。这不是厂商虚标而是 TOPS 这个指标本身有一堆隐藏前提。第一个前提是精度假设。绝大多数芯片标称的 TOPS指的是 INT8 精度下的峰值算力。但很多团队在起步阶段模型都是 FP16 甚至 FP32 训练的搬到端侧直接跑 FP16算力直接腰斩再腰斩。以某款主流芯片为例INT8 标称 100TOPSFP16 理论上只有 50TOPS 左右FP32 更是只有 12.5TOPS 左右。要是你部署的是一个没有做过量化、还是 FP32 的 PyTorch 模型那你实际能用的算力只有标称值的八分之一。第二个前提是稀疏性假设。很多芯片标称的 TOPS 是“稀疏算力”也就是说他们认为模型权重里有 50% 是零计算时可以跳过。但问题在于稀疏推理需要模型结构本身支持剪枝和稀疏化且推理框架要能真正利用上这种稀疏性。我实测过绝大多数开源模型和框架根本没有做稀疏化适配这块算力在日常部署中就是纸面数字。第三个前提是时钟频率与散热条件。标称算力是在理想散热、满血时钟频率下测出来的。端侧设备一装进机箱、塞进无人机外壳散热一受限芯片立即降频算力跟着缩水。我们在 30 度室温、无风道条件下实测某芯片持续满载跑 10 分钟后性能衰减到峰值的 73%。这里还要注意一个特别容易踩的坑带 DLA深度学习加速器或 NPU 的芯片标称 TOPS 往往包含这些专用加速单元的算力。但你的模型能不能真正跑进这些专用加速单元取决于工具链支持和算子覆盖。跑不进去这部分算力就是摆设。我们在某国产平台上就遇到这个问题官方标称 32TOPS 的 NPU 算力实际部署一个带自定义算子的模型全部算子只能回退到 CPU 跑NPU 利用率几乎为零。所以选型第一步先把标称 TOPS 打个三到五折当成 FP16 模型部署的“心理预期算力”。如果你要用 FP32那就按标称值的五分之一到八分之一去预估。这个折损系数是我实测了多款芯片之后得到的经验值虽然粗暴但比看着 PPT 上的数字做决策靠谱得多。2. 端侧 AI 的真实负载画像与算力换算公式光有折损系数还不够。要真正做好选型你得先搞清楚一件事你的机器人/无人车/无人机在真实运行时端侧到底要跑哪些 AI 负载每种负载对算力和内存带宽的需求完全不同。2.1 具身智能端侧负载的四大类型我把这一年多接触的具身智能项目里的端侧 AI 负载归成四大类感知类负载目标检测YOLO 系列、语义分割、实例分割、深度估计。这类模型结构相对成熟算力消耗中等但往往是视频流处理对持续吞吐有要求。三维理解类负载BEV 感知、3D 目标检测、点云处理PointPillars、VoxelNet 等。这类模型计算量大、显存占用高尤其吃内存带宽。多模态大模型负载视觉语言模型VLM、具身基础模型、VLAVision-Language-Action模型。输入不只是图像还有文本指令和推理上下文权重动辄 4-8GB对内存容量和带宽要求极为苛刻。规划决策类负载路径规划、强化学习推理、运动控制策略网络。这类模型一般不大但对延迟极其敏感往往需要和实时控制系统紧密耦合。2.2 一个简便的端侧算力估算公式我曾经被同事问过一个问题“我们要上一个 YOLOv8l 做检测再加一个 7B 的 VLM 做场景理解到底需要多大的算力”这个问题没法直接回答但可以通过一个简化公式做初步估算所需等效算力TOPS Σ模型单次推理算力需求GFLOPs × 帧率/频率需求fps ÷ 目标利用率关键参数是模型单次推理的 FLOPs。以 YOLOv8l 为例输入 640×640 分辨率单次前向推理大约需要 120 GFLOPs要以 30fps 跑那就是 3.6 TOPS 的纯计算需求。再考虑 FP16 部署时计算单元的实际利用率一般在 30%-50% 之间所以实际需要的“标称 TOPS”就是 3.6 ÷ 0.3 ≈ 12 TOPS。也就是说光跑一个 YOLOv8l 30fps你就需要一块标称 12TOPS 以上的芯片。但别忘了芯片还要同时跑别的模型。我们通常还会加一个轻量级分割模型比如 SegFormer-B0单次约 5GFLOPs30fps 需要 0.15TOPS和一个深度估计模型MiDaS 轻量版单次约 30GFLOPs30fps 需要 0.9TOPS。如果三个模型串行跑在同一块芯片上纯计算需求合计约 4.65TOPS按 30% 利用率折算标称算力至少得 15TOPS 以上。如果还要再塞一个 7B VLM情况就完全不一样了。7B 模型在端侧做 INT8 量化后单次推理约需要 15-20 TOPS视序列长度和图像 token 数而定而且这不是按帧算的是一轮对话就要消耗一次。这类模型入场会瞬间把算力需求从“十几 TOPS”拉到“几十甚至上百 TOPS”。我把这些实测换算经验整理成一张速查表方便你直接参考注意这是 INT8 量化后的预估FP16 需要再乘 1.5-2 倍负载类型典型模型与输入单次推理算力需求30fps/轮所需算力备注轻量检测YOLOv8s640×640~50 GFLOPs1.5 TOPS量产级方案常见基线中重检测YOLOv8l640×640~120 GFLOPs3.6 TOPS精度要求高时使用实时分割SegFormer-B0512×512~5 GFLOPs0.15 TOPS算力消耗不大但带宽敏感深度估计MiDaS 轻量版384×384~30 GFLOPs0.9 TOPS多传感器融合常用3D 检测PointPillars中等配置~70 GFLOPs2.1 TOPS点云体素化耗内存带宽VLM 推理7B INT8图像文本15-20 TOPS/轮非帧率需求端侧部署的“算力黑洞”VLA 推理2B-7B INT8实时控制5-15 TOPS/步延迟敏感对内存带宽和时延要求极高这张表的核心结论是如果你的项目只需要常规感知10-30TOPS 的芯片绰绰有余但只要你碰 VLM/VLA算力需求直接上一个数量级。3. 实测五款主流端侧芯片平台——从开发板到量产模组接下来是硬货。我在项目里实际用过的五款芯片/平台把实测感受和踩坑记录整理如下表格能说明的先看表格。平台标称算力INT8实测可用FP16等效内存带宽功耗区间生态成熟度适合场景NVIDIA Jetson Orin NX 16GB100 TOPS25-35 TOPS102.4 GB/s10-25W极高中型机器人主控、复合机器人NVIDIA Jetson AGX Orin 64GB275 TOPS60-80 TOPS205 GB/s15-60W极高预研开发、重负载多模态Rockchip RK35886 TOPSNPU2-4 TOPSNPU跑得了的部分64 GB/s5-15W中等低成本轻量感知、无人机地平线征程6系列10-560 TOPS 视型号实测中端型号与标称差距较大视型号视型号中等到良好依赖官方库车规量产、特定网路优化好高通 SA8295PSA8540P 对应模组综合 AI 算力较强需区分 GPU/NPU 路径较高较高车规级工具链偏 Android 生态智能座舱与智驾融合量产车规3.1 NVIDIA Jetson Orin NX 16GB综合体验最好的“六边形战士”这是我们目前主力平台。16GB 内存版本标称 100TOPSINT8 稀疏我们实测在 FP16、非稀疏条件下跑我们自己的多模型管线YOLOv8l 检测 SegFormer 分割 MiDaS 深度估计三路 30fps整机负载约 72%帧率稳定在 28-30fps。这个表现基本能覆盖大多数具身智能中端项目的感知需求。关键优点只有一个生态太成熟了。TensorRT、DeepStream、Isaac ROS、vPI随便一个常用框架都有官方优化过的现成方案。算子覆盖率高95% 以上的常用模型结构能直接编译通过。这对于团队快速迭代太重要了其他平台光算子适配就能拖你两周。代价就是贵。而且 Orin NX 对功耗和散热极其敏感我们实测 25W 模式下的性能只有 40W 模式的 68% 左右。要在 25W 下同时跑三路模型算力分配得精细调。3.2 NVIDIA Jetson AGX Orin 64GB预研利器但不是所有机器都装得下AGX Orin 64GB 版本我们用了大概三个月。它是做算法验证和整机预研的绝佳平台跑 7B VLM 的 INT8 量化版勉强能到 2-3 token/s 的生成速度用于验证交互逻辑没问题。内存带宽 205GB/s跑点云和视觉融合的大模型明显比 Orin NX 从容。但它的体型、功耗和散热需求基本告别了小型移动机器人。我们在服务机器人原型上试过60W 满载时即使有风扇机身表面温度也能到 55 度以上对锂电池续航和整机安全都是压力。所以我们的结论是AGX Orin 适合放实验室和开发台架上量产原型阶段一般都要迁移到 Orin NX 或更轻的平台。3.3 Rockchip RK3588便宜但 NPU 是“能跑”和“好用”的分水岭RK3588 是很多人做低成本方案的第一个选择毕竟板子便宜、资料多、社区活跃。我们在一台巡检无人车上试过它。说实话CPU 性能放到现在依然够用8 核 A76A55 跑常规 Linux 控制和传感器通信很流畅。但 NPU 部分我只能说官方工具链对常用模型的转换能力和 NVIDIA 的 TensorRT 相比大概还有三到五年的距离。我们跑 YOLOv8sRKNN 工具链转换后能跑到约 25fps算力扩展性也还不错。但一旦模型里出现某些特定算子比如部分注意力机制或动态形状转换就会报错官方支持要等版本更新。整个团队为此手写了不少算子的 CPU 回退版本维护成本不低。如果你团队里有专门的算法工程师愿意做算子适配RK3588 是性价比之选。但如果你希望“模型丢进去就能跑”千万别选它。3.4 地平线征程6 系列车规量产场景下的强势候选我们在一个车载项目上评估过地平线的征程6系列特别是面向智能驾驶和机器人场景的型号。这家公司的核心优势是从芯片到工具链再到参考算法栈闭环做得比较完整。部署流程是将模型转换为官方指定的中间格式再通过工具链进行量化与编译整体流程比 RK 更顺畅。我们拿一个特定优化过的检测网络测试INT8 部署后的吞吐表现不错算力利用率能接近五成。但有几个注意点。首先是算子覆盖依赖于官方近期更新的版本如果你用的是学术界刚出的新结构可能要等适配。其次是工具链的调试信息不如 TensorRT 直观定位问题要靠经验。最后是车规场景下的量产导入周期比想象中长需要提前锁定方案。我的评价是如果做车规量产、算力需求明确、网络结构固定征程6是强力选项。如果是科研探索、快速原型迭代生态上还是略吃亏。3.5 高通 SA8295P / SA8540P座舱与机器人融合的另一种思路高通这两颗芯片在智能座舱里用得很多。我们发现它们做具身智能机器人主控有个独特优势CPU 和 GPU 性能出色Android/Linux 生态都可以用且原生支持多路摄像头输入。我们在一台概念验证的配送机器人上跑过常规感知模型YOLOv5s 语义分割丢给 GPU 跑性能盈余不少比 RK3588 的体验好很多。但它的 AI 加速单元NPU的部署门槛比 NVIDIA 高不少。如果走高通的上车工具链要花不少时间阅读文档和调试量化。而且高通的工具链社区资料远不如 Jetson 丰富网上能搜到的实战案例少。非高通生态背景的团队建议先做好心理准备。4. 内存带宽与计算单元匹配——最容易翻车的隐性指标很多人在选型时只看 TOPS忽略了一个同样致命的参数内存带宽。我在项目里被这个坑过一次必须专门讲清楚。4.1 为什么跑视觉模型时带宽比算力更容易成为瓶颈算力决定了芯片“每秒能算多少次”内存带宽决定了“每秒能搬运多少数据”。如果一个模型在一帧内需要读取的权重和中间特征图总量超过了内存带宽的承载能力那计算单元就只能干等数据利用率直线下降。以跑 YOLOv8l 为例模型权重约 90MB每次推理要读取一遍权重可能会做缓存优化但复杂模型很难完全缓存。在 1080p 分辨率下中间特征图的读写量是权重的数倍。粗略估算单次推理的内存数据搬运量在 500MB 到 1GB 级别。要跑到 30fps内存带宽需求大约是 15-30GB/s。乍一看这个数字对大多数芯片都构不成瓶颈。但注意这是单模型单路。如果你的系统同时跑三个模型、五路摄像头输入数据搬运总量瞬间翻倍。再加上 VLM 这种动辄读取几 GB 权重的负载内存带宽会立刻成为第一瓶颈。4.2 “计算-带宽比”一个被忽视的选型指标我建议你选型时额外算一个指标计算-带宽比公式是“标称 TOPS × 1024 ÷ 内存带宽GB/s”。这个比值代表“每搬运 1 字节数据有多少次运算可以完成”。不同负载对这个比值的要求差别很大。图像分类这种密集计算型模型比值高说明算力富余没问题但像点云处理、多模态模型这种数据密集型负载比值过高反而说明带宽不足计算单元会被“饿死”。以我们实测为例Jetson Orin NX 的计算-带宽比约 1000100TOPS × 1024 ÷ 102.4GB/s我们跑纯视觉检测模型时这个比例够用但跑 PointPillars 点云模型时明显能感觉到带宽吃紧——块利用率上不去GPU 有大量时间在等数据。而 AGX Orin 的 205GB/s 带宽处理类似负载就从容得多。所以给大家一个实操建议如果你的负载里有三维点云、高分辨率多路视频、或者大模型优先保证内存带宽而不是只看算力。相同 TOPS 下带宽差一倍的芯片在数据密集型场景下体验会差出一个档次。这块目前国产芯片做得普遍偏保守也是一个性价比突破的潜在点。5. 散热、功耗与供电设计在实车/实机部署中的连锁反应选型时很多人只看芯片规格书忽略了“这块芯片装进你的机器人之后会引发一连串连锁反应”。我在实机部署上吃过亏这里专门说说。5.1 功耗墙和温度墙实际可用算力将大幅缩水以 Jetson Orin NX 为例它在规格书里标称 100TOPS但那是在允许跑到 40W 且散热良好的条件下。很多移动机器人设计时为了控制整机功耗和发热把功率限制在 15W 或 25W 模式。我们实测过三个功率模式的性能差异功率模式标称可用算力理论三路视觉模型实测帧率备注15W约 30TOPS18-20fps性能太弱不推荐25W约 50TOPS25-27fps均衡选择40W约 100TOPS29-30fps需要强散热注意一个细节从 25W 到 40W功耗翻了 60%但帧率只提升了约 15%收益并不线性。而且 40W 模式下如果散热跟不上芯片温度一过墙会立刻降频到比 25W 模式还低的性能。做过一次对比实验同一块板子分别用被动散热片、5V 风扇主动散热、以及带风道的风扇在 40W 满载模式下跑 20 分钟。被动散热片组在第 7 分钟开始大幅掉帧到第 12 分钟温度冲到 85 度帧率掉到 40W 模式的 40% 左右主动散热组全程稳定温度保持在 65 度上下。所以在系统的结构设计阶段就要把散热方案定下来。不要指望芯片能靠“体质”扛过散热差带来的性能衰减。5.2 供电设计端侧 AI 算力的隐形天敌性能越高的芯片瞬时电流变化越剧烈。Orin NX 在负载突增时比如从待机切到多路模型推理瞬时电流可能从 1A 跳到 6A 以上。如果供电模块响应速度不够电压跌落超过阈值系统直接重启。我们最早用一块 3A 输出的降压模块给 Orin NX 供电跑单模型没问题多模型一上就神秘重启查了三天才发现是电压跌落。后来换了带大电容储能和 6A 以上持续输出的车载宽压模块问题才解决。供电这个环节对你的移动机器人特别重要。锂电池供电时电芯内阻和线材压降共同作用到板端的电压可能已经不足。我的建议是选型阶段就把电源预算做足至少留 50% 的电流余量并且选用支持限流保护的模块避免瞬间短路烧板。5.3 震动环境对接口和存储的影响车载和机载还有一个共同点震动。我们在一台巡检车上用的是 NVMe SSD 插槽结果两个月后系统偶发卡死最后定位是 SSD 与主板接触不良导致的数据错误。后来全部换成带锁扣的接口并用胶固定问题解决。这条经验看起来和选型无关但你选的芯片平台决定了板卡形态和接口类型进而决定你能用什么存储。无人机上我更推荐 eMMC 或焊接式存储NVMe 的可靠性在强震动环境里确实更差。6. 工具链与算子支持度决定项目是否“烂尾”的隐形因素算力、功耗、散热这些硬指标看得见摸得着但工具链好不好用算子支持度够不够往往要等你把模型搬上去部署才发现。而这时候船已经开了一半换平台的成本高得惊人。6.1 主流工具链的实战体验对比我们在这几款平台上都实际部署过模型工具链对比直接说结论TensorRTNVIDIA目前综合体验最好的。C 和 Python 接口都有量化做得好INT8 精度损失能在 1%-3% 以内。就算遇到不支持的算子也能写 plugin 插件绕过去社区案例一搜一大把。我们团队一个不太熟悉底层优化的算法工程师也能在两周内把 YOLOv8s 跑到满意的帧率。RKNNRockchip转换工具界面友好但算子覆盖限制较多。我们在 RKNN 上转换一个包含 Transformer 模块的轻量检测模型直接报“不支持的 layer”。开发人员查 issue、翻源码折腾了两个星期最后只能选择把模型结构简化。如果模型里的新算子较多慎选。地平线工具链对常见视觉模型的适配较好文档和工具链在快速迭代中。我们与地平线的 FAE 沟通时响应速度和支持力度都不错。这是国产工具链里比较明显的优势。不过社区案例少遇到冷门问题只能找原厂。高通 SNPE 工具链文档量庞大且有各种版本坑对非高通平台的跨平台编译支持一般。我们团队算是平均水平偏上也耗了将近一周才跑通一个 YOLOv5s 的量化部署。如果你团队没有底层优化经验把高通平台当作快速验证的首选不太现实。6.2 算子替换与手写代价实测一个简单算子要多少工时工具链之外算子支持度是最容易拖垮项目进度的隐形杀手。我们统计过在 RK3588 上遇到一个不支持的注意力算子softmax 和 matmul 的组合开发人员手动实现 CPU 回退版本并验证精度总共花了约 20 个工时。而同一个算子在 TensorRT 上只需要写一个简单的 plugin约 4 个工时就搞定。这个差距对选型的影响是如果团队只有一两个算法工程师且项目排期紧张优先选算子支持最成熟的平台而不是参数最漂亮的平台。否则你会发现自己 60% 的时间都在跟工具链搏斗而不是做算法。6.3 如何提前验证工具链是否适合你——一个 3 天快速评估法这里分享我们内部的一个快速评估流程可以帮你判断一个新平台是否适合你的项目耗时大约三天把你项目中最具代表性的 2-3 个模型结构最好是含不同算子类型的整理出来包括自定义结构。用官方工具链做一次转换和部署记录三个指标转换成功率、首次跑通时间、精度损失。实测一次 INT8 量化后的 mAP/准确率对比判断精度损失是否能接受。看编译时间。一个中等复杂度模型如果编译时间超过 30 分钟迭代效率会很低。跑一个多模型并发测试看资源冲突和延迟抖动是否在可接受范围。这套流程我们用下来基本能在一周内判断一个平台适不适合团队。强烈建议选型前先做这个测试而不是只看官网的 benchmark。7. 给两个典型项目的选型建议与配置参考最后是拿来即用的部分。基于以上所有踩坑经验我给两个典型的具身智能场景给出具体的选型配置参考都是我们在项目中验证过可行性的方案。7.1 场景一轮式底盘 机械臂的复合机器人典型任务室内巡检、物品抓取、人机协作演示。核心负载双路 RGB 摄像头实时目标检测YOLOv8m机械臂抓取位姿估计轻量级 keypoint 模型室内导航VSLAM需要 CPU 资源和 IMU 融合可选一个 2B 左右的 VLM 做场景理解但不要求实时只在静态时推理配置参考项目推荐配置备选配置主控芯片Jetson Orin NX 16GB25W 模式地平线征程6中端型号需确认工具链适配内存16GB必须8GB 跑不了多路模型12GB若只跑感知不跑 VLM散热主动风扇 风道确保 25W 满载温度低于 70 度被动散热仅适用于 15W 以下模式供电宽压 9-36V 输入6A 以上输出带储能电容11.1V 3S 锂电池直供需加稳压加持电容存储128GB NVMe做好固定eMMC 128GB震动环境更稳感知算力占比约 25 TOPSINT8 标称预留 30% 余量给算法迭代这个方案实测双路 30fps 检测 位姿估计 VSLAM整机功耗约 32W含主控和传感器板等外设算力占用约 70%有足够的余量做升级。7.2 场景二四旋翼无人机机载部署典型任务电力巡检、地面目标跟踪、避障。核心负载单路或双路高清图传实时目标检测YOLOv8s追求帧率光流或 VIO 视觉里程计对内存带宽和 CPU 实时性有要求避障深度估计或障碍物检测轻量级这里有一颗巨坑必须强调无人机对重量和功耗极其敏感一旦芯片重量或功耗超标飞控、续航、任务载荷全得重新设计。所以选型顺序应该是“先定功耗预算再选芯片”。配置参考项目推荐配置备选配置主控芯片Jetson Orin NX 8GB15W 模式RK3588S若团队能接受算子适配成本内存8GB无人机负载较轻够用16GB要跑 VLM 才需要整机功耗预算建议 25W-35W主控 摄像头 飞控等超过 40W 需重新评估续航与散热散热被动散热 机身结构导热微型风扇需做防水防尘存储eMMC 128GBNVMe 需做震动固定实测数据是15W 模式下的 Jetson Orin NX 跑 YOLOv8s 30fps VIO 光流性能依然存在明显余量但无法同时再跑一个重负载分割模型。如果你要在无人机上做多模型融合10W 级功耗预算上这个平台基本就是极限了。RK3588S 的 NPU 在轻量感知上有性价比但你要有心理准备一次性适配好固定模型结构后不要再随意换模型。7.3 换算经验从你自己的项目需求出发所有推荐配置只能做参考。我建议你选型前一定要做一次“需求数字换算”列出你所有必须同时跑的模型估算每个模型的单帧 FLOPs 和内存占用。确定帧率或频率要求计算出纯计算需求总 TOPS。根据部署精度FP16 还是 INT8套用折损系数。加上你的 VSLAM、控制逻辑、通信等 CPU 负载需求内存至少留 30% 余量。最后根据整机功耗预算反向筛选芯片。这套流程走一遍我心里基本就有数了。8. 写在最后几个我这次复盘后想强调的事情这一年多时间从最初看着 PPT 参数选型被坑到后来形成自己的评估体系我认为最大的教训是在端侧 AI 的选型里没有“最好的芯片”只有“最适合你项目约束的芯片”。所谓约束不只是算力还有功耗、散热、工具链、团队能力、量产周期等一系列因素它们共同决定了项目的成败。做选型决策前我建议你列一个类似下面的清单逐项自检我的模型结构是否都能被目标平台的工具链支持如果不支持我有多少人力去做算子适配整机的功耗预算能分给主控芯片多少这决定了芯片最高能工作在什么功率模式。我的散热方案能在高负载下让芯片稳定不掉帧吗别忘了实测环境温度和机器内部空气流动。内存容量是否足够同时装载多个模型尤其运行 VLM 时8GB 和 16GB 完全是两个世界。在外场或移动环境中供电和存储是否可靠做过震动和电源跌落测试吗我需要跑 INT8 还是 FP16精度损失与算力提升之间我的任务更在意哪一头如果这些问题的答案你都能清晰给出选型基本就不会翻车。如果再让我从所有经验里提炼一条最值得记住的标称 TOPS 要打三折但工具链的成熟度一分都不能打折。硬件参数不够可以降模型复杂度、调精度、减小输入分辨率但如果工具链卡住你连部署都部署不起来其他一切都白搭。最后的最后分享一个我们的“土办法”。每次选型评估时我们会提前把算法团队确定要用的两三个模型整理成清单发给芯片原厂的 FAE。一般技术底子够硬的团队会很快给出适配建议和样例工程如果回复是“应该可以”甚至不回那这个平台就基本可以放弃了。用这个办法筛选平台比你自己翻一个月的文档还管用。就这样希望这些实测记录能帮你少走一些弯路。