ADAS 这个词这两年从主机厂一路卷到方案商再卷到芯片选型会上几乎每个做域控、做前视一体机、做行泊一体的团队都绕不开一个问题入门级 ADAS 到底该用哪颗芯片我前后参与过几个量产前视和环视项目从最早用通用 SoC 硬扛到后来专门挑带 NPU 的专用芯片踩过的坑不算少。这篇就把入门 ADAS 选型这件事拆开讲清楚重点围绕爱芯元智 M55H 这类带 NPU 的智能汽车芯片聊聊算力怎么算、接口怎么配、算法怎么落、量产怎么稳。不管你是刚接手 ADAS 项目的硬件工程师还是正在做方案评估的算法同学看完应该能对入门 ADAS 选哪颗有个能落地的判断。1. 入门 ADAS 的真实需求边界在哪里1.1 先搞清楚入门两个字到底指什么很多人一上来就问算力多少 TOPS其实这个问题在入门 ADAS 场景里问早了。入门 ADAS 的核心特征不是算力低而是功能边界清晰、成本敏感、功耗受限、量产节奏快。典型形态就是前视一体机一颗摄像头加一颗芯片跑车道线检测、前车识别、行人检测、交通标志识别这几样输出给整车做预警或者轻控制。再往上一点是行泊一体前视加几路环视同时跑行车和泊车算法但依然属于入门到中阶的过渡形态。我见过不少团队一开始就按高阶域控的思路选芯片结果发现算法根本用不上那么大算力反而被功耗和散热拖死。入门 ADAS 的芯片选型第一件事是把功能清单列死你要跑几个模型、模型输入分辨率多少、帧率要求多少、有没有多路摄像头同时接入、需不需要做后处理融合。这几项定下来算力需求基本就浮出水面了而不是反过来先买一颗大芯片再想怎么用。1.2 功能清单决定算力下限而不是上限举个具体的例子。一个典型的前视 ADAS 功能集包含车道线检测、车辆检测、行人检测、交通标志识别模型输入一般是 1280x720 或者 1920x1080帧率 30fps。这类模型如果是轻量级的检测网络单帧推理的算力需求大概在 0.5 到 2 TOPS 之间四五个模型叠加再留一点余量给后处理和调度整体有效算力需求落在 4 到 8 TOPS 这个区间。注意我说的是有效算力不是标称算力。标称算力和有效算力之间的差距是入门 ADAS 选型里最容易翻车的地方。芯片手册上写的 TOPS 通常是 NPU 在理想条件下的峰值实际跑模型的时候受限于内存带宽、算子支持度、量化精度、调度开销能发挥出六成就算不错了。所以看到一颗芯片标称 8 TOPS你要按 4 到 5 TOPS 的有效算力去规划功能这样才不会在量产前发现跑不动。1.3 成本、功耗、接口这三座大山入门 ADAS 的成本压力非常直接。前视一体机这个品类整机 BOM 成本卡得很死芯片作为大头价格区间基本决定了方案能不能成立。功耗方面前视一体机通常没有主动散热靠金属外壳自然散热芯片功耗一般要控制在 3 到 5 瓦以内超过这个数就得加散热片甚至风扇整机形态和成本都会变。接口这块最容易被忽视。入门 ADAS 芯片要接摄像头MIPI CSI 接口的数量和速率直接决定你能接几路、接多高分辨率的摄像头。还要考虑 CAN 接口做整车通信UART、SPI、I2C 做外设扩展有些方案还要以太网做数据回传。这些接口不是有就行而是要匹配你的系统架构。比如你要做行泊一体前视加四路环视至少需要 5 路 MIPI 输入很多入门芯片在这个数量上就卡住了。2. M55H 这类 NPU 芯片的算力账怎么算2.1 NPU 不是万能加速器先看算子支持爱芯元智 M55H 这类芯片的核心卖点是内置 NPU但 NPU 能不能用好第一关是算子支持。你训练的模型里用到的卷积、池化、激活、归一化这些算子NPU 是不是都支持支持到什么程度直接决定模型能不能高效跑起来。我遇到过模型里用了某种特殊的激活函数NPU 不支持结果这部分回退到 CPU 跑整个推理时间翻倍。所以选型阶段一定要做一件事拿你实际要部署的模型在目标芯片的 NPU 上跑一遍看算子覆盖率。M55H 这类面向 ADAS 的 NPU通常对主流检测、分割网络的算子支持比较完整但如果你用的是比较新的网络结构或者自定义算子就要提前验证。这个验证工作不能省省下来的时间后面会加倍还回去。2.2 量化精度对算力和精度的影响NPU 跑模型一般要做量化从 FP32 降到 INT8算力能提升好几倍但精度会掉。入门 ADAS 场景对精度的容忍度其实不低车道线检测偏一点、行人框松一点可能就影响功能体验。量化策略就变得很关键是全局 INT8还是混合精度敏感层保留 FP16这些都要在选型阶段和算法团队对齐。我的经验是入门 ADAS 的模型量化到 INT8 之后mAP 掉 1 到 2 个点是可以接受的但如果掉超过 3 个点就要考虑混合精度或者换量化方案。M55H 这类芯片一般会提供量化工具链支持逐层精度分析你要用好这个工具把敏感层找出来单独处理。这个过程比较磨人但比量产之后发现精度不达标再回头改要划算得多。2.3 内存带宽才是隐藏的算力瓶颈算力标称再高内存带宽跟不上也是白搭。NPU 跑推理的时候权重和特征图都要在内存和 NPU 之间搬运带宽不够NPU 就处于等数据的状态利用率上不去。入门 ADAS 芯片一般用 LPDDR4 或者 LPDDR4X带宽在 10 到 20 GB/s 这个量级规划的时候要算清楚模型权重占多少、特征图占多少、多模型并行的时候峰值带宽是多少。我一般会做一个简单的带宽估算模型权重总量加上单帧特征图峰值乘以帧率再留 30% 余量看是否超过内存带宽的 70%。超过这个线就要考虑模型裁剪、特征图复用或者降低分辨率。这个账不算清楚后面调优的时候会发现怎么调都上不去因为瓶颈根本不在 NPU 算力上。3. 从模型到量产M55H 上的部署链路3.1 训练框架到芯片工具链的转换模型在 PyTorch 或者 TensorFlow 上训练完要转到芯片能跑的格式中间要过工具链。M55H 这类芯片一般提供自己的模型转换工具把 ONNX 或者框架原生格式转成芯片的离线模型。这一步的坑在于算子映射和版本兼容训练框架的某个算子版本和工具链支持的不一致转换就会报错或者生成错误的计算图。我的做法是训练阶段就尽量用工具链明确支持的算子集别用太新的算子。训练完先导出 ONNX用 ONNX Runtime 验证一遍推理结果确认和训练框架一致再进芯片工具链转换。转换完还要在芯片上跑一遍和 ONNX 的结果做数值对比误差在可接受范围内才算通过。这个链路听起来繁琐但每一步都是在提前暴露问题。3.2 多模型并行的调度策略入门 ADAS 往往要同时跑多个模型车道线一个、检测一个、标志识别一个。这些模型怎么调度是串行还是并行直接影响帧率和功耗。串行跑简单但延迟叠加30fps 可能跑不到。并行跑要看 NPU 能不能同时承载多个模型以及内存够不够。M55H 这类芯片一般支持多模型分时复用 NPU你可以把不同模型按优先级排布高优先级的检测模型先跑低优先级的标志识别可以降帧率跑。我实际项目里会把检测和车道线放在同一帧内跑完标志识别两帧跑一次这样整体延迟可控算力也不会浪费。调度策略要在选型阶段就考虑因为不同芯片的调度能力和工具链支持差别很大。3.3 后处理放在哪里跑模型输出的是原始的张量要做解码、NMS、坐标变换这些后处理才能变成可用的检测结果。后处理放 NPU 还是 CPU是个需要权衡的问题。放 NPU 可以减轻 CPU 负担但 NPU 对后处理这种非规则计算的支持往往一般。放 CPU 灵活但 CPU 本来就要跑系统调度和通信负担重。我的经验是NMS 这种计算密集但逻辑简单的后处理尽量用 NPU 或者 DSP 加速坐标变换、结果融合这种逻辑复杂的放 CPU 跑。M55H 这类芯片一般有 CPU 和 NPU 的协同机制你要在工具链里配置好哪些算子跑在哪个单元上。这个配置不是一劳永逸的要根据实际 profiling 结果反复调。4. 选型对比M55H 和同类入门芯片怎么挑4.1 算力、功耗、接口的三角平衡入门 ADAS 芯片选型本质是在算力、功耗、接口三个维度上找平衡点。M55H 的定位是入门到中阶算力覆盖前视和轻量行泊一体功耗控制在自然散热范围内接口上 MIPI 路数和 CAN 接口能满足主流需求。和它同档位的芯片有的算力更高但功耗也高有的接口更丰富但算力偏弱没有一颗是全面占优的。选型的时候我会做一个加权打分表把算力、功耗、接口、工具链成熟度、量产案例、价格这几个维度列出来按项目实际需求给权重。比如前视一体机项目功耗和价格权重高算力够用就行行泊一体项目接口和算力权重高功耗可以适当放宽。这个表不是走形式而是逼着团队把需求优先级理清楚。维度权重前视一体机权重行泊一体说明有效算力中高按实际模型需求评估不看标称功耗高中自然散热场景下 3-5W 是红线MIPI 接口中高行泊一体至少 5 路工具链成熟度高高直接影响部署周期量产案例高中有案例意味着坑被踩过价格高中入门场景成本敏感4.2 工具链成熟度比算力更影响项目进度这一点我要单独强调。很多团队选型的时候盯着算力参数忽略了工具链。结果芯片算力够但模型转换各种报错量化精度调不好profiling 工具不好用项目进度一拖再拖。工具链成熟度包括模型转换的算子覆盖率、量化工具的易用性、profiling 和调试工具是否完善、文档和社区支持是否到位。M55H 这类有实际量产案例的芯片工具链一般经过项目打磨常见问题都有解。选型阶段可以要求供应商提供工具链试用拿自己的模型跑一遍完整链路从转换到量化到上板推理看整个流程顺不顺。这个试用比看参数表有用得多能提前暴露大部分集成风险。4.3 量产案例和供应链稳定性入门 ADAS 是要上车的量产案例和供应链稳定性是硬指标。一颗芯片有没有在量产项目上跑过跑了多久出货量多少这些信息直接反映芯片的成熟度和可靠性。供应链方面芯片的供货周期、封装形式、温度等级、是否符合车规都要确认清楚。我一般会问供应商几个具体问题这颗芯片在哪些量产车型或者项目上用过出货量级是多少车规认证做到哪一级供货周期多长有没有替代料方案。这些问题问下来芯片能不能用于量产项目基本就有数了。参数再漂亮没有量产验证和稳定供货也不敢往车上放。5. 实操中容易踩的坑和应对经验5.1 算力估算过于乐观导致帧率不达标这是最常见的坑。选型的时候按标称算力估算觉得 8 TOPS 跑四五个模型绰绰有余实际部署发现帧率只有 15fps离 30fps 差一半。原因就是前面说的有效算力打折加上多模型调度开销、内存带宽瓶颈、后处理占用实际可用算力远低于标称。应对办法是在选型阶段就做端到端 profiling不要只看 NPU 的算力。拿实际模型在目标芯片上跑测单模型推理时间、多模型并行时间、加上后处理的完整链路时间按最坏情况估算。如果供应商能提供开发板一定要自己跑一遍别信纸面数据。我现在的习惯是算力需求按标称的 50% 到 60% 去规划留足余量。5.2 量化后精度掉太多功能不达标量化精度问题是入门 ADAS 的另一个高频坑。INT8 量化之后小目标检测、远距离车道线这些本来就难的任务精度掉得更明显。有的团队量化完发现行人检测漏检率上升车道线在弯道处断裂功能体验直接受影响。解决办法是分层量化加敏感层保护。用工具链的逐层精度分析功能找出对精度影响大的层这些层保留 FP16 或者用更高精度的量化策略其他层用 INT8。这样整体算力损失不大精度能保住。另外量化校准集要覆盖实际场景白天黑夜、晴天雨天、不同道路类型都要有校准集偏了量化后的模型在实际场景就会偏。5.3 接口配置和整车通信对不上接口问题往往在集成阶段才暴露。芯片的 MIPI 路数够但摄像头模组的输出格式和芯片输入不匹配CAN 接口有了但整车 CAN 矩阵和芯片的 CAN 控制器配置对不上以太网要做数据回传但芯片的以太网 MAC 和 PHY 选型有讲究。这些问题单个看都不大凑在一起就是集成周期拉长。我的经验是选型阶段就把系统架构图画出来把摄像头、芯片、外设、整车通信的接口一一对应确认每一路都能接上。MIPI 要注意 lane 数和速率匹配CAN 要注意控制器数量和收发器选型以太网要注意 MAC 和 PHY 的接口类型。这些确认工作做在前面集成阶段就顺很多。5.4 散热设计预留不足入门 ADAS 前视一体机通常靠自然散热芯片功耗估算不准或者散热设计预留不足夏天高温环境下芯片降频帧率掉、功能异常。我见过项目在实验室跑得好好的装车之后夏天暴晒下出问题回头查是芯片结温超了。散热设计要按最坏情况算环境温度按整车舱内最高温考虑芯片功耗按峰值算热阻按实际散热路径算留够余量。M55H 这类芯片一般会提供热阻参数和参考散热方案你要结合自己的整机结构做热仿真或者实测。别等到装车才发现散热不够那时候改结构成本就大了。6. 入门 ADAS 选型的决策清单6.1 需求侧要确认的几件事选型之前需求侧要把这几件事定死功能清单跑哪些模型、什么分辨率、什么帧率、系统形态前视一体机还是行泊一体、几路摄像头、成本目标芯片价格区间、功耗约束散热方式决定功耗上限、通信需求CAN、以太网、其他外设。这几项定下来选型范围就缩小了。我一般会把这些整理成一页纸的需求规格和算法、硬件、系统几个团队一起过一遍确认没有遗漏和矛盾。比如算法说要跑五个模型硬件说功耗只能 3 瓦系统说成本要压到某个数这几个约束放在一起可能就排除了大部分芯片剩下的再细看。需求不明确就开始选型后面返工的概率很高。6.2 芯片侧要验证的几件事芯片侧要验证的核心是实际算力能不能满足需求、工具链能不能跑通、接口能不能接上、功耗和散热能不能达标、有没有量产案例和稳定供货。这几件事里算力和工具链要拿实际模型验证接口要拿系统架构图核对功耗要拿开发板实测量产和供货要找供应商确认。我建议做一个选型验证计划把这几项验证工作列出来每项定好验证方法和通过标准逐个过。比如算力验证方法是拿实际模型在开发板上跑端到端 profiling通过标准是完整链路帧率不低于 30fps 且 CPU 占用不超过 70%。这样验证下来选型决策就有依据不是拍脑袋。6.3 供应商侧要问清楚的几个问题供应商这边除了价格和交期还要问清楚技术支持能力、工具链更新频率、问题响应机制、有没有参考设计和量产经验分享。入门 ADAS 项目周期紧供应商的技术支持能不能跟上直接影响项目进度。有的供应商芯片不错但技术支持响应慢遇到问题卡住项目就拖了。我会在选型阶段就和供应商的技术团队建立联系问几个实际的技术问题看响应速度和专业程度。同时要一份参考设计或者量产案例的技术资料看看他们的方案成熟度。这些信息比参数表更能反映芯片能不能用在项目上。M55H 这类有量产背景的芯片供应商一般能提供比较完整的支持这也是选型时的加分项。7. 关于 NPU 部署的几个实操细节7.1 模型输入输出的内存布局要对齐NPU 对输入输出的内存布局有要求比如 NHWC 还是 NCHW通道对齐到多少这些在模型转换的时候就要配好。布局不对齐NPU 要么跑不了要么效率大打折扣。我遇到过模型转换时没注意布局上板之后推理时间比预期多了一倍查了半天才发现是布局转换占了时间。处理办法是在模型导出和转换阶段就确认布局要求训练框架的输出布局和芯片工具链的输入要求对齐。如果对不齐在转换工具里配置布局转换或者在前处理阶段做调整。这个细节看起来小但对推理效率影响很大值得在部署初期就处理好。7.2 多线程和异步推理的坑入门 ADAS 芯片一般是多核 CPU 加 NPU 的架构推理可以做成异步CPU 在 NPU 跑推理的时候处理其他任务。异步推理能提升整体吞吐但线程同步和数据竞争的问题也随之而来。我见过项目里异步推理没做好同步导致推理结果错帧检测框和图像对不上。异步推理要做好几件事推理任务的队列管理、输入输出的缓冲区管理、推理完成的通知机制、多线程访问共享资源的保护。这些在芯片的 SDK 里一般有示例但示例往往简化了实际项目要按自己的场景完善。我的建议是先用同步推理跑通功能再逐步改成异步每步都做压力测试确保不出错帧和数据竞争。7.3 profiling 工具要用起来芯片工具链里的 profiling 工具是调优的关键。它能告诉你每个算子在 NPU 上跑了多久、内存带宽用了多少、NPU 利用率多少、瓶颈在哪里。不用 profiling 工具调优就是盲调改了半天不知道有没有效果。我一般会在部署初期就跑一遍 profiling看整体链路的时间分布找出耗时最长的环节。如果 NPU 利用率低看是内存带宽瓶颈还是算子不支持如果某个算子特别慢看能不能换等效算子或者调整模型结构。M55H 这类芯片的 profiling 工具一般能到算子级别用好它能省很多调优时间。这个工具的使用方法要在项目早期就掌握别等到性能不达标才想起来用。入门 ADAS 选型这件事说到底是在明确的约束下找最合适的芯片而不是找参数最漂亮的芯片。M55H 这类带 NPU 的智能汽车芯片在入门到中阶 ADAS 场景里有它的位置但具体适不适合你的项目还是要拿需求去对、拿模型去验、拿系统去核。我个人在实际项目里的体会是选型阶段多花一周做验证量产阶段能省一个月填坑这笔账怎么算都划算。