边缘端AI算力选型:从场景反推芯片的方法与实践

发布时间:2026/11/6 1:08:12
边缘端AI算力选型:从场景反推芯片的方法与实践

边缘端 AI 算力选型推荐:从场景反推芯片

干这行越久,越觉得很多人在边缘端 AI 选型上走反了路。拿到一块开发板先看 TOPS,看完算力看价格,觉得“性价比”差不多就定了。结果真把模型部署上去,帧率对不上、内存不够、算子不支持,折腾两周又换方案。我个人的习惯恰恰相反:先盯着场景抠指标,把“到底要干什么、要跑什么模型、每秒要处理多少数据”算清楚,再回头找芯片。这就是“从场景反推芯片”的选型思路,也是这篇想认真聊聊的方法。

这事适合谁看?刚接触边缘端 AI、准备做嵌入式视觉或语音方案的工程师,以及被领导一句“选个芯片吧”砸懵的项目负责人。内容不堆参数,重点讲清楚算力需求怎么估、芯片规格怎么对比、坑在哪里。文中的计算方法和推荐表格,可以直接抄作业,也可以按自己的场景改改再用。

1. 先搞清楚边缘端 AI 芯片有哪些“段位”

选型之前,脑子里得有张地图。我习惯把边缘端 AI 芯片按算力档位粗分成几类,每一类的典型芯片、适用模型复杂度和功耗区间都不同。这张图一旦建立,后面反推选型时定位会快很多。

1.1 按算力档次划分的主流芯片梯队

第一档是 MCU 级芯片,以 STM32N6、ESP32-S3 为代表。STM32N6 内置的 NPU 大概在 1 TOPS 级别,ESP32-S3 主要是向量指令加速,没有真正意义上的 NPU,实测跑轻量级模型也就是几十 GOPS 的水平。这档芯片适合关键词唤醒、传感器振动分析、简单异常分类这类 TinyML 任务,整板功耗通常只有几十毫瓦到几百毫瓦,用电池就能长期跑。

第二档是入门级 AP SoC,典型代表是瑞芯微 RV1126、RV1109,晶晨 A311D,地平线旭日 X3。算力大概在 1.2 TOPS 到 5 TOPS 之间。这类芯片普遍带 ISP 和视频编码能力,适合做单路或两三路的 1080p 视频分析,比如人脸抓拍、客流统计、简单的工业缺陷检测。成本能控制在两三百块以内,是目前边缘端项目里出货量最大的区间。

第三档是中高端边缘 SoC,瑞芯微 RK3588、英伟达 Jetson Orin Nano/NX 是这一档的关注焦点。RK3588 标称 6 TOPS INT8 算力,Orin Nano 8GB 版本标称 40 TOPS。到这档就能跑比较重的模型了,比如 YOLOv8s、姿态估计、多路视频结构化分析。整板功耗从十几瓦到六七十瓦,通常需要主动散热。

第四档是边缘服务器级或车载级的专用平台,英伟达 Jetson AGX Orin、地平线征程系列、黑芝麻智能等。算力动辄上百 TOPS,甚至要用到 RTX 3090 这类桌面级 GPU 做边缘盒子。这档通常处理车规、机器人、工业服务器这种高实时、高并发的场景,系统复杂度和成本都不是前几档能比的。

1.2 真正拉开差距的不是 TOPS,而是“有效算力”

很多人在这一步就踩坑了。芯片宣传页上写 6 TOPS,指的一般是 INT8 精度下的峰值算力,而且是理论峰值。所谓“有效算力”,要打个五六折甚至三四折才贴近实际。原因有几个:一是 NPU 的算力要跟内存带宽匹配,带宽不够,算力再高也是空转;二是模型里的算子不能全部映射到 NPU 上,总有一部分要落到 CPU 上跑,这部分会拖慢整体延迟;三是多路并发时,NPU、CPU、编解码器抢资源,实际吞吐必然低于峰值。

选型时不要盯着“谁 TOPS 高谁就强”。同样标称 6 TOPS 的芯片,一个配 LPDDR4x,一个配 LPDDR5 双通道,实测跑同款 YOLOv5s,帧率能差出三分之一以上。内存带宽才是算力的隐形天花板,后面会专门展开讲。

2. 场景反推法:算力需求到底怎么算

反推法的核心是四步:定场景、选模型、算 FLOPs、折算成芯片算力需求。每一步都有对应的经验公式和换算逻辑,严谨一点能省掉后面大量调优时间。

2.1 从模型出发:FLOPs、帧率与分辨率的关系

先搞清楚一个概念:FLOPs 是模型做一次前向推理的浮点运算量,单位是 GFLOPs。我们要的是“每秒处理多少帧”,把两者一乘,就是芯片需要提供的峰值吞吐。举个例子,YOLOv5s 在 640x640 输入下大概是 16 GFLOPs,如果要求 30 帧每秒,每秒就是 16×30 = 480 GOPS。这里要把 GOPS 和 TOPS 对齐,1000 GOPS 等于 1 TOPS,所以 480 GOPS 约等于 0.48 TOPS。

但实际不能这么算完就结束。NPU 跑卷积类算子时的利用率很少超过 50%,预处理、后处理也要占 CPU 资源。我做需求评估时有个习惯公式:

芯片 INT8 算力需求 = 模型 GFLOPs × 目标帧率 × 2(折损因子)

2 这个折损因子,相当于默认 NPU 利用率 50%,并且预留了前后处理和多路并发的余量。用这个公式,YOLOv5s@640、30fps 算出来就是 16×30×2 = 960 GOPS,也就是说至少要配 1 TOPS 以上的芯片才稳。

不同模型的 FLOPs 相差很远,我列一个常用模型参考表,方便你快速估算:

模型输入分辨率参数量单次推理 FLOPs30fps 估算需求(含折损)
MobileNetV3-Small224x224约 2.5M约 0.6 GFLOPs约 0.04 TOPS
YOLOv5n640x640约 1.9M约 4.5 GFLOPs约 0.27 TOPS
YOLOv5s640x640约 7.2M约 16 GFLOPs约 0.96 TOPS
YOLOv8n640x640约 3.2M约 8.7 GFLOPs约 0.52 TOPS
YOLOv8s640x640约 11.2M约 28.6 GFLOPs约 1.72 TOPS
RTMDet-S640x640约 8.9M约 14.8 GFLOPs约 0.89 TOPS

要注意,算出来的只是推理部分,还没算编解码和前后处理。如果场景是 N 路视频流,就把结果再乘 N。

2.2 精度选择决定算力缺口:FP32、FP16、INT8 的换算逻辑

选型过程中最容易被忽视的是精度档位。同一个模型跑在三种精度下,芯片要付出的算力完全不是一个量级。这个概念我用生活化类比解释一下:FP32 是每个数字用 32 位浮点表示,像记账时每一位小数都精打细算;FP16 是 16 位,省一半存储但精度损失轻微;INT8 是 8 位整数,像记账时只记到元,忽略角和分,省空间、跑得快,但会有精度代价。

芯片的 TOPS 标称都是跟着精度走的。主流边缘 NPU 通常会给出 INT8 峰值,FP16 一般要打个五折,FP32 很多芯片根本不支持或者效率极低。英伟达 Jetson Orin 系列标称 INT8 算力 40 TOPS,FP16 大概只有 20 TOPS。所以你在对比芯片时,如果不确认 TOPS 对应的精度,很容易把 INT8 的数当成全精度算力,导致选型偏差。

那到底选什么精度?我的建议是:边缘端能上 INT8 就上 INT8。原因有三点。第一,算力需求直接减半或者降到四分之一,芯片成本跟着降。第二,INT8 模型加载到内存里的体积小,带宽压力小。第三,现在的量化工具链成熟度还可以,大多数 CNN 模型在训练后量化下,精度损失能控制在 1% 到 3% 以内,很多场景完全能接受。

但 INT8 也不是万能解药。有些模型对精度极其敏感,比如检测小目标、分割边缘,或者模型里有大量 LayerNorm、Softmax 这类对数值范围敏感的算子。这种情况可以用混合精度,让关键层保持 FP16,其他层走 INT8。代价是部署复杂度上升,这一点要提前接受。

2.3 算力换算与预留余量的经验值

算出一个理论需求后,选型时还要乘一个 1.5 到 3 倍的余量系数。为什么?因为真实场景里有几个不可控因素:模型会迭代,今天用 YOLOv8n,明天可能换更准的 YOLOv8s;实际帧率往往比预期高,高峰时段的数据量会波动;量化后精度不够时,你可能需要跑 FP16 而不是 INT8,算力需求直接翻了倍;NPU 利用率优化是个长期工程,初期实现达不到最终调优后的水平。

我常用的完整公式是:

最终选型算力 = 模型 FLOPs × 目标总帧率 × 折损因子 × 余量系数

折损因子取 2,余量系数取 1.5 到 2。举个例子,一个工业检测项目,计划跑 YOLOv8s@640,3 路相机,每路 25fps,那模型 FLOPs 是 28.6G,总帧率是 75。算一下:28.6×75×2×1.5,约 6.4 TOPS。看到这个结果,基本就得往 RK3588 或者 Jetson Orin Nano 这个级别去看了。这就是反推法最有价值的地方,它能让你在动手之前就知道该选哪个档位的芯片,而不是等到测试不过再推翻重来。

3. 典型场景的芯片推荐矩阵

光讲公式太抽象,直接给场景和芯片的对应关系,这也是我平时给人推荐时最常被问到的东西。以下按典型负载和功耗预算拆成三档,供做方案时参考。

3.1 轻量级场景:语音唤醒、关键词识别、传感器分类

这类场景的特点是模型极小、常电运行、功耗敏感。典型模型包括 KWS 语音关键词识别、人员摔倒检测的加速度计特征分类、电机振动异常检测。模型 FLOPs 普遍在几十到几百 MFLOPs,推理帧率要求也很低,每秒几次到十几次就够了。

推荐芯片是 ESP32-S3、STM32N6、MAX78000。这类芯片不需要跑视频,对内存带宽要求极低,整板功耗可以压到百毫瓦级。实测 ESP32-S3 跑 20 类关键词识别,单次推理大概是几十毫秒,功耗在几十毫安量级,用 18650 电池就能跑好几天。STM32N6 的优势是内置 NPU 和成熟的 ST 工具链,适合有实时性要求、算力需求稍高一点的传感器融合场景。

这类项目的重点不在算力,而在部署流程。TinyML 的模型通常先在 PC 上训练,再通过转换工具生成 C 数组,最后烧录到芯片里。踩坑点集中在量化校准上,很多小模型训练时没用过量化感知,转换后精度波动明显。我建议这类项目一开始就用 QAT(量化感知训练),比事后补救省事得多。

3.2 中量级场景:单路视频分析、人脸检测、客流统计

这是目前边缘端项目的主力区间。典型模型是轻量化的人脸检测、YOLOv5n/v8n 目标检测、人体关键点检测,输入分辨率通常 640x640 以下,帧率要求 15 到 30fps。

推荐芯片是瑞芯微 RV1126、晶晨 A311D、地平线旭日 X3。RV1126 标称 2 TOPS INT8 算力,实测跑 YOLOv5n@640 到 30fps 问题不大,但想上 YOLOv5s 就有点吃力,除非降低帧率或用更小的输入分辨率。A311D 的 5 TOPS 算力要宽裕一些,可以跑 YOLOv5s@640 的单路实时推理。旭日 X3 的计算是 5 TOPS,开发和部署工具链做得比较完整,对有算法团队、想快速落地的项目很友好。

这个档位的核心关注点有三个:ISP 图像质量、视频编码能力和 CPU 算力余量。AI 推理只是整个链路的一部分,摄像头进来的是 RAW 图,要经过 ISP 处理成 RGB,再缩放、归一化,最后才进 NPU。这些操作吃的是 CPU 和 ISP 资源。项目里经常出现 NPU 占用率只有 60%、CPU 已经满载的情况,导致整体帧率上不去。选型时不能只看 NPU,还要把 SoC 的 CPU 核数和 ISP 能力纳入评估。

3.3 重量级场景:多路视频结构化、自动驾驶、复杂模型部署

这类场景对算力的需求到了几十 TOPS 量级。典型任务是 16 路以上 1080p 视频流同时做人脸/人体/车辆结构化分析,或者车载环境下的多传感器融合感知,或者跑 Transformer 架构的新一代检测模型。

推荐芯片是瑞芯微 RK3588、英伟达 Jetson Orin 系列,对车规有硬性要求的可以看地平线征程系列。RK3588 的 6 TOPS 虽然数字上不如 Orin,但胜在内存带宽和外围接口丰富,8K 编解码、多路摄像头接入能力都很强,适合做中小规模的项目。我自己实测 RK3588 跑 16 路 1080p 轻量模型是可行的,但跑 YOLOv8s 这种重量模型,单路 10fps 以下就比较难看了。Jetson Orin 的优势是 CUDA 生态完善,TensorRT 对算子的支持覆盖面广,跑 Transformer 或在多场景切换时的适应性远好于大多数 NPU 方案。

到重量级场景,散热和供电就变成主要矛盾了。Orin Nano 满载 15W 到 25W,AGX Orin 可以到 60W 甚至更高。做嵌入式产品的朋友要提前算好整机散热方案,无风扇密闭环境会直接导致降频,算力再高也发挥不出来。这个坑我见过太多次,方案评审时算力都够,样机测试一跑就掉帧,一查温度 90 度,芯片自己锁频了。

3.4 芯片选型快速索引表

场景类型典型模型估算算力需求推荐芯片关键选型理由
语音唤醒/传感分类KWS、异常检测小模型低于 0.1 TOPSESP32-S3、STM32N6、MAX78000功耗极低,电池供电,工具链成熟
单路 1080p 视频分析YOLOv5n、YOLOv8n0.5 ~ 1 TOPSRV1126、旭日 X3、A311D集成 ISP 与编码器,成本可控
多人脸/轻量检测多路RetinaFace、YOLOv5s2 ~ 6 TOPS瑞芯微 RK3588、A311D接口丰富,多路并行能力强
多路复杂模型/机器人YOLOv8s、姿态估计、分割6 ~ 40 TOPSJetson Orin Nano/NX、RK3588生态完善,适合复杂模型迭代
车载/高实时性Transformer 检测、多传感器融合50 TOPS 以上Jetson AGX Orin、征程系列车规认证,强大并行处理能力

这张表只能作为选型的起点,真正的决策还要看开发成本和供货情况,这是下一节的重点。

4. 选型背后的隐性成本与常见坑

很多项目失败不是芯片算力不够,而是没算清楚隐性成本。这节聊几个最容易被忽略的点,每一个都是我在实际项目中踩过的。

4.1 开发者生态与工具链,往往比芯片本身更卡脖子

芯片的算力只是个数字,真正决定开发效率的是工具链。英伟达走的是 CUDA + TensorRT 路线,生态最成熟,网上教程多,报错信息好查,遇到算子不支持也有大量的社区解决方案。国产芯片厂商这些年进步明显,瑞芯微的 RKNN-Toolkit 已经能覆盖主流检测模型,地平线的工具链在文档完善度和调试体验上也在持续升级。

但 NPU 有个共同问题:对动态形状、复杂 Attention 结构的支持普遍不好。比如一些新出的 Transformer 检测头,在 TensorRT 上能跑,换到某国产 NPU 上就得算子映射,映射不了就只能落回 CPU 跑。一落 CPU,整体时延立刻翻倍。所以选型前一定先做一个算子兼容性清单,把目标模型的每一类算子过一遍,确认有没有替代方案。这一步能筛掉大量看起来合适、实际上跑不动的芯片。

有个省时间的技巧:去芯片厂商的官方模型仓库找参考实现。比如瑞芯微提供的预转模型列表里有 YOLO 系列、RetinaFace、PP-系列等常见模型,地平线也有 model zoo。如果你的模型不在列表里,先看看结构上是不是和列表里的模型相近。相近意味着算子大概率被覆盖。差得远就要谨慎评估。

4.2 内存带宽与内存容量:算力的隐形天花板

算力再高,数据喂不进去也是白搭。边缘端 SoC 的内存带宽差异极大,差的芯片只有单通道 DDR4,带宽可能不到 6GB/s,好的芯片上了 LPDDR5 双通道,带宽能超过 50GB/s。这个差异直接决定了多路视频场景下能不能撑住。

举个例子,1080p 图像经过预处理后,输入到 NPU 的每帧数据量就在几 MB 到十几 MB 量级,模型推理过程中还要反复读写中间特征图。YOLOv8s 在 640x640 输入下的特征图总量有好几百 MB 的读写量(这里的“总量”是累加值,不是同时占用)。如果内存带宽不够,NPU 只能等数据搬运,算力利用率直接掉一半以上。选型时一定要看芯片平台搭配的内存规格,尤其是当你想用最低配置的 DDR 来省成本时,必须重新核算带宽余量。

内存容量是另一个隐形约束。4GB 内存听起来不小,跑起来就不是那么回事了。系统占一部分,推理框架占一部分,多路视频的缓冲队列占一部分,模型权重和预处理图像又占一部分。用 RK3588 跑 8 路视频时,4GB 版本内存就有点紧张,建议直接选 8GB 版本。Jetson Orin Nano 同理,它同时有 8GB 和 16GB 版本,如果计划跑 Transformer 类模型,16GB 会从容很多。

4.3 功耗、散热、部署环境的现实约束

芯片标称功耗通常是“典型值”,满负载运行时功耗会显著更高。比如 Jetson Orin NX 标称功耗 10W 到 25W,实际满载可以到 40W 上下。工业现场的密闭电控箱、户外的太阳能供电场景、车载的蓄电池系统,对功耗的容忍度完全不同。

我的建议是选型阶段就把功耗预算表做出来:芯片理论满载功耗、外围电路功耗、散热风扇功耗、整机待机功耗,加总后乘 1.2 的降额系数。如果算出来超过场景允许的功耗上限,就该考虑降一档算力,或者转向更轻量的模型。不要想着“满载只是偶尔”,边缘端设备 7x24 小时运行,满载状态持续出现是常态,散热方案必须按满载来设计。

还有环境温度。工业级芯片通常能在零下 40 度到 85 度工作,但消费级芯片只保证 0 到 70 度。很多国产 SoC 标称是工业级,实际测试时温度余量并不大。有次我们做户外设备,夏天的密闭机箱内部温度能到 65 度,芯片表面温度更高,结果 3 台样机都出现推理卡顿。后来换了导热垫加金属外壳才压住。这类问题在实验室里很难复现,必须做高温老化测试。

4.4 供应链生命周期与长期供货

工业产品和消费电子产品不一样,项目生命周期动辄五到八年,期间芯片不能停产,不能出现批次性供应问题。选型时尽可能选产品生命周期明确的芯片,查看厂商的产品路线图,确认该型号处于量产稳定阶段而不是即将 EOL(停产)。

还要关注一点:交期。部分国产边缘芯片前两年缺货严重,交期拉到 20 周以上。如果你的产品要小批量快速上市,可以考虑备选方案,比如选两颗管脚兼容、算力相近的芯片,在 PCB 设计时预留第二种物料的位置。这属于选型里的“BOM 冗余”思维,经验不足的团队很容易忽略。

5. 实操案例:一个 3 路工业缺陷检测项目的完整选型过程

前面讲的是方法论,这节用一个真实的选型案例把整个反推流程串起来。项目是做一个 3 路相机的工业外观缺陷检测设备,要检测金属件表面的划痕、凹坑和焊点异常。

5.1 场景需求与约束条件

先定指标。检测目标是 200 万像素的灰度相机,为了找细小划痕,输入分辨率定为 1280x1280。算法团队初步选择 YOLOv8s,因为它在检测小目标上的效果比 YOLOv5s 好些。单路实时帧率要求 25fps,三路同时工作。整机功耗限制在 30W 以内(无风扇密闭机箱),整机 BOM 成本预算在 2500 元以内。工业现场要求 7x24 小时运行,芯片要具备工业级温度范围。

把需求列清楚之后,我直接开始算算力。

5.2 算力计算与芯片初筛

YOLOv8s 在 640x640 输入下是 28.6 GFLOPs,但输入分辨率升到 1280x1280 后,FLOPs 会按面积比例增长约 4 倍,达到 110 GFLOPs 左右。这是很多新人容易漏掉的关键点,FLOPs 不是固定值,它会随输入分辨率显著变化。

单路算力需求 = 110 GFLOPs × 25fps × 2(折损因子) ≈ 5.5 TOPS。三路合计 16.5 TOPS。再乘一个 1.5 的余量系数,最终需求在 25 TOPS 左右。

这个数字意味着什么?RV1126 的 2 TOPS、A311D 的 5 TOPS,想都不用想,直接排除。RK3588 的 6 TOPS 看起来也不够,但如果把模型降到 YOLOv8n,FLOPs 会低很多。算法团队后来提供了一版经过剪枝的 YOLOv8n@1280,FLOPs 约 28 GFLOPs,单路需求约 1.4 TOPS,三路 4.2 TOPS,加余量后约 8.5 TOPS。RK3588 勉强够得上,但需要对 NPU 利用率做精细化调优。预算充足的话,Jetson Orin NX 16GB 版本(标称 100 TOPS INT8)完全无压力,但单价会高出一块,得看项目得承受能力。

5.3 实测验证与最终定案

理论计算不能代替实测,但理论计算能帮你缩小实测范围。这项目最终选了两块板子做对比实测:瑞芯微 RK3588 和 Jetson Orin Nano 8GB。

先说 RK3588 平台。用 RKNN-Toolkit 做 INT8 量化后,模型能正常转换部署,但遇到了两个问题。第一是 NMS 后处理在 NPU 上不支持,得用 CPU 实现,三路并发时 CPU 占用率接近 70%,整机帧率掉到 20fps 左右。第二是 1280x1280 的输入对内存带宽压力很大,NPU 利用率和理论值差了将近 30%。

再测 Jetson Orin Nano。TensorRT 的转换过程中,模型里有一个动态形状的算子导致转换报警,最后通过固定输入尺寸绕过去了。INT8 量化后,实测三路 1280x1280 输入稳定跑到 25fps,GPU 利用率在 60% 左右,CPU 还有余量,看起来有不错的扩展空间。功耗在整机 27W 左右,符合约束。

最终定案选了 Jetson Orin Nano,主要原因不是算力数字,而是工具链成熟度和算子覆盖完整度。整个项目从拿到板子到三路稳定运行,只花了两周。这类进度优势在工业项目里就是最实际的成本节约。RK3588 并非不好,只是在这个项目里,CPU 后处理的瓶颈和带宽压力让它的调优周期超出了时间预期。

6. 常见问题与排查技巧实录

最后整理一份选型和部署过程中的高频问题排查表,都是我实际遇到过的,比官方文档更贴近真实场景。

现象排查思路解决方案
TOPS 很高但帧率上不去检查内存带宽与位宽,确认模型输入分辨率偏好换高带宽内存配置,或降低输入分辨率
模型部署时报算子不支持查看厂商算子支持列表,定位不支持的层替换算子、拆成 CPU 子图,或换工具链版本
INT8 量化后精度掉太多检查敏感层,使用混合精度量化用 QAT 重训练,或对关键层保留 FP16
多路视频卡顿,NPU 占用率却不高检查 CPU 是否成为瓶颈,后处理是否串行把 NMS、仿射变换等挪到多线程,异步处理流水线
满载后推理速度下降用日志查芯片温度,确认是否降频改善散热,或在固件中限制功耗墙
模型升级后帧率暴跌对比新旧模型的 FLOPs 和算子构成重做需求计算,确认是否需要换更高算力平台

排查时有个好习惯:先把整条链路拆成“采集 - 预处理 - 推理 - 后处理”四段,按段测耗时。大部分帧率问题都不是推理本身慢,而是前后处理拖后腿。用开发板自带的性能分析工具能快速看出占比,不用靠猜。

再补充一个经验:部署之前一定要做模型的轻量化评估,而不仅仅是 FLOPs 替换。同样的 YOLOv8s,把输入从 1280 降到 640,FLOPs 降 4 倍,精度可能只掉 2 个点,但帧率体验完全不同。很多时候“选型不够”其实是“模型太肥”,先做模型端优化比换芯片更划算。

7. 个人的一些体会

做了这么多边缘端项目,我最大的感受是选型这件事没有一劳永逸的答案。芯片迭代快,模型更新更快,今天的最优解过半年可能就是次优解。但只要养成“从场景反推芯片”的习惯,每次选型都不至于偏得太远。

另外一个习惯是:任何选型结论都要用真实模型、真实数据、真实板卡验证一轮。规格书上的数字只是起点,算子兼容性、内存带宽、散热降频、供电纹波这些东西,只能在一轮一轮的实测中暴露出来。多留一版备选方案,多测一轮高温满载,关键时刻都能救项目一命。

最后提一个后续可以延伸的方向:如果你手头的场景跑传统 CNN 模型已经到头了,可以开始关注端侧 Transformer 相关的部署支持。边缘端的下一波变化大概率来自这类新模型上车和老工具链的更新,提前做算子兼容性摸底,比到时候临时换芯片要主动得多。