主讲 | 蒋沁宏

编辑 | Amy

编者注： 

本文是HiEV出品的系列直播「硬核拆解BEV」第三期问答环节内容整理。商汤绝影量产行车智能驾驶研发负责人 蒋沁宏，与连线嘉宾寒武纪行歌自动驾驶总监李想、宏景智驾高级工程经理柴可宁、主持嘉宾周琳展开深度交流，并进行了答疑。 

本期商汤科技的分享内容《BEV三大关键：数据、迁移和芯片部署》，可前往#视频号：HiEV观看直播回放。 

关于「硬核拆解BEV」系列直播的更多内容，可在公众号后台回复「回放」查阅。 

一、BEV对芯片的核心诉求

Q：近两年自动驾驶落地并上车，与此同时，涌现多个芯片玩家，例如地平线、寒武纪和黑芝麻，大家共同为自动驾驶行业努力。那么像商汤绝影这样的智驾解决方案供应商，对国产芯片有何核心诉求？ 

蒋：过去一年多，我们在芯片使用上存在一些痛点，主要是两方面。 

首先，是整个芯片对 硬件设计，包括对 算子的 支持， 我们希望能考虑到目前一些算法的发展趋势。大家有目共睹，整个模型趋势是向 All-in-One 方向发展的，新模型必然带来新需求。 

例如早先的 AI 芯片，更多会考虑对 CNN、Pooling 等的优化。而现阶段可能要更往前一步，例如考虑到引入Transformer 算法后，可能对芯片的带宽要求更高，并需要能够支持 BEV 算法的相关算子。这也是算法供应商对国产芯片的强需求。 

其次，是 生态支持。新芯片需要建立新生态，而打磨是长周期的过程。 

而且新芯片必然会碰到多个新问题，这些问题不止与模型推理相关，还有量化的对齐、传感器的接入和预处理等。我认为在工具链和文档不完备的情况下，很需要一些完善的售后服务和快速响应。 

Q：深有体会，所以我们在芯片设计阶段，会尽可能前瞻性地考虑这些。那像商汤绝影这样综合的解决方案公司已经做过很多项目，使用了国内外不同的芯片方案，能点评一下 使用体验或优缺点吗？ 

蒋：从芯片本身来讲，大家风格不同。有的芯片不管是在算力、CPU还是带宽上，都比较均衡，但没那么突出；而有的芯片某一方面可能会很优秀，例如AI算力，但其他方面少许偏科。这都是芯片公司根据趋势做的设计。 

所以我认为， 第一，没有完美的 芯片，不管什么芯片都有一些对应的算法、方案能够完成部署，其部署难度也取决于芯片本身。 

第二，芯片差异可能在于 文档的可完善性 ，以及从生态角度来看，国内外芯片还是存在差距的，毕竟人家深耕已久。 

而国内芯片团队则能给予较大支持力度， 能够共同做 优化、团队 响应快，这也是国产芯片的优势。 

二、算法供应商如何支持主机厂的自研需求？

Q：自动驾驶技术趋势发生了变化，前两年都在堆算力，要上1000Tops，要配置5个激光雷达。但今年大家逐渐趋于理性，不再讲堆料，而是降本，同时继续做技术方案的探索、迭代甚至升级，比如城市NOA开始探索无地图的方案。 

自动驾驶趋势变化快，您作为自动驾驶老兵，认为自动驾驶技术方案终局如何？对于芯片公司以及算法供应商，可能需要提前做哪些 准备和规划？ 

李：我先讲个人感受，再讲宏观方法论。 

比如 硬件算力和传感器。这好比当年一起做L4的Robotaxi，最开始不管是从安全性，还是项目风险的角度出发，先把算力和传感器埋进去。虽然当时讲硬件预埋，是给大家留下更多功能想象，但更多是为了保证项目稳定和车辆安全。而这本质上是先摸清算力的底线。 

因为乘用车最终 讲究 性价比和 客户买单，那么就要： 

• 理清性价比的临界点

• 保证方案和功能实现时最具性价比的算力

确定最终预算

这是市场所关注且过去两年落地时堆料多的原因之一。 

另一原因是， OEM有 同辈压力。如果硬件预埋能保证功能交付时间节点，那肯定要做。但长期看，OEM也要摸清性价比的界线。这也是芯片公司和解决方案公司要努力的方向。 

第二个问题，技术创新的角度， 整个行业在前进，今年很多玩家在讲 mapfree，例如元戎启行、华为。 

全国的高速高精地图花个小几千万就可以买到，但是城市的高精地图有以下特点： 

本身成本高昂

更新成本高，为保鲜度要定期更新

如果城市NOA通过验证 发现不需要 高精地图，那有将有助于产品落地。 

方法论角度，通过与OEM的合作，我发现 （整个产业）是一个 To B、To C的产业，不单纯是To B的。所有人要思考OEM怎样让用户买单，这才符合大家共同的商业模式。 

第一，长期来看， 研发费会逐步 降低，营收要靠订阅收取，但订阅率如何提高，是我们和OEM共同要面对的。 

第二，科创和技术创新讲究 「人无我有」。但从近几年自动驾驶的发展看，各家功能级的差异还未能跨出一代。而创新能否真正解决用户需求或痛点，则和订阅率挂钩 

第三， 性价比。中国产业的发展路线都是从创新到卷性价比，去年大家开卷行泊一体，未来可能会有舱驾一体。而我比较好奇，未来舱驾一体能否在中国实现，哪家车厂会第一个有魄力做出来并量产？ 

而大方向上，算力也有下降趋势，技术侧终要为产品侧服务。因此，产品侧的预判和方向，技术侧仍要拆解， 芯片和解决方案方皆要提前做 预埋和准备。

Q：BEV落地过程中，BEV跟传统的单目2D算法，是 共存还是彻底 替换的关系？ 

蒋：问题很好，这也是我们目前在做技术迭代或算法迭代时遇到的问题。我认为，这要分任务类型抉择。 

首先，对于同一类感知任务且下游依赖相对统一，比如PVB目标感知它的下游只有融合，肯定是 替代关系。没必要出了BEV的PVB，还要出2D的PVB，最后可能只有一个下游在用。 

其次，还有一些任务，受到下游的算法影响。众所周知模型、方案的迭代很快，而下游算法例如标定，它的更替相对要慢。比如车道线，现在BEV直接检测出车道线，给到规划控制用。但车道线还有另一种用法，比如在线标定时它其实用的是一些2D车道线，对于这些任务来说，因为下游还未完成算法的更替，我出这套BEV方案时，还要额外做一些2D任务。 

还有一些任务，出于技术或是真值的局限性，在任务没重要到用BEV 3D做时，还是用2D做。例如交通灯标志牌，我们获得其 3D 的真值还是较为困难，而2D方案也可以通过多帧联合优化来解算3D位置。 

另外一点，要考虑 如何迭代 高效。因为做多任务学习，必然会有一些任务更新迭代很快，而另一些则相对较慢，例如PVB和TSR的迭代节奏就不同，此时就需要解决不同研发人员之间版本更新的冲突。要保证更新不影响部署，研发资源就需要协调和妥协。 

所以，从总体上来看，（BEV算法与传统算法）在部分任务上是 共存关系，部分任务上可能是 替换关系。 

Q：很多OEM有自研BEV的需求，作为算法供应商，或者像我们这样的系统供应商/域控供应商，应该 扮演怎样的 角色去满足车厂BEV自研需求？ 

蒋：这并不冲突，从当前的商业模式下，很多人认为，我们跟主机厂自研的需求之间的关系看起来是可替代的。 

从技术演进的角度来看，这两者之间并不是 零和博弈的。从商业模式角度来说，我们在项目研发过程中，会衍生出一些新的商业模式。 

另外，作为解决方案供应商的角度，我们在 算法上的领先和探索是核心优势。我刚刚有提到，我们在端到端和大模型上做的一些布局和思考，不局限于智驾这一个领域。而在这些方面的领先性，让我们可以跟主机厂探索进一步合作，从而可以带给C端用户一些用户价值。 

商业的成功是 利他，利他最后可能才是 利我。

三、未来域控向单SOC集中式发展

Q：域控形态非常多样，有的域控是单SOC的，有的是多个SOC的，可能需要外挂一颗MCU解决功能安全等问题，有的直接是一体化的，那无论是从行泊一体，还是驾舱一体角度出发，您认为， 域控最终的理想形态是怎样的？ 

柴：首先从算法升级和技术角度来考虑，我们认为，未来域控肯定是更倾向于 单SOC这种 芯片式集中域控方式发展的。 

因为无论是像这种感知端的BEV，包括前融合技术，还是接下来决策规划一体式的后端架构，往往需要在 独立的 中高算力芯片上高效运行。如果是比较小的、多个的ASOC或多个芯片，那么效率就没那么高。 

还有就是，之前泊车和驾舱一体的芯片去年又开始火起来了，未来我们非常看好 驾舱一体。驾舱一体其实相当于把驾舱泊车和行泊一体进一步整合，随着以后座舱或者驾舱一体芯片的升级，和整个功能安全架构设计的升级，舱驾一体化肯定能进一步 降低成本，提升客户体验。 

我认为，从市场和消费者的角度来说，其实这个东西做了以后，消费者能否感知到实际的提升比较重要。 

蔚来汽车发布了Banyan车机系统2.0.0版本，它整合了Orin X和8155的算力，它把很多的8155上的一些AI语言模型都迁到了Orin X上，整个算力通过异构的方式集合起来，在往驾舱一体方向发力。 

升级以后，从消费者体验来说，我感觉车机更丝滑，语音交互更智能，其实消费者是会在这个地方买单的。 

Q：驾舱一体使用了8155芯片和传统的自动驾驶芯片，如果打通的话， 难点在哪里？ 

柴：一个难点是，从芯片公司角度考虑，驾舱和智驾是两拨公司，可以看到很多芯片公司在 AI芯片上下一代的布局 ，例如英伟达、高通，国内的地平线、芯驰、寒武纪和安霸等。 

应用方面，从自身经验来看，这对软件能力、工程要求较高，比如在一个单J3芯片上做行车和泊车一体，其实行车和泊车的感知算法没办法同时跑的，肯定存在 切换的过程，而如何通过高效的软件设计，让切换在用户端是 无感的，这就比较考验各家实际落地能力。我觉得，主要在 芯片端和使用端的这两点上。 

Q：我想问下宏景智驾，BEV带来大量感知数据，从供应商的角度来讲，解决方案供应商如何与主机厂一同把这些数据处理好？包括数据隐私问题， 应该怎样去做 数据处理，作为供应商应该怎样去配合车厂？ 

柴：BEV需要大量 真值数据，获取原始数据很容易，但如何用好很困难，无论是算法供应商，还是主机厂都要有很强的 数据利用和闭环能力。 

比如，如何用原始数据去做大规模的无监督的预训练，自动化的云端标注系统，需要做好数据的埋点和回灌。 

举个例子，我认为在开发阶段可以用LiDAR提供真值，装一个真值系统去生成大量数据。但在量产之后，我们还需要给车厂提供OTA，他发现反馈的图像在目标检测和车道线3D地图检测方面做得并不好，那我们也需要对相关数据进行优化。 

纯视觉的3D场景重建加标注的难题是量产BEV的公司必须修炼的内功，还有就是数据合规和数据使用权肯定属于车厂的财产。 

作为供应商或者合作伙伴，如何基于车厂的大量数据帮他们通过OTA提升性能，然后在 客户端体现 ，这是我们要思考的问题。 

四、BEV落地后，有哪些预判？

以下是商汤绝影量产行车智能驾驶研发负责人蒋沁宏回答观众问题的内容整理。 

Q1: 继BEV之后，我们预判感知会有一些 新趋势，不知道蒋老师怎么看？ 

A：我刚刚也有提及在BEV方面上，大家还是以往 DL方案上发展。趋势来看，还是要向 端到端的方向发展。越来越多的算法会加到模型里，包括预测和算法，我们现在就在做这部分工作。 

而作为算法供应商，跟（学术界）做研究不同的点在于，我们需要额外考虑，不能单纯追求效果。比如在所谓的端到端的框架下，我们还是要 追求 控制和规划的确定性 ，这也是作为真正的行业从业者需要考虑的。 

Q2: 主机厂从研发BEV到量产上车，部分系统开放功能周期通常要多久？ 

A：因为我们不是主机厂而是供应商，我们给主机厂做BEV，从整个算法来讲，我们的算法预研肯定不是这个时期开始的。 

从开始做，到算法在项目上的开发，再到最后上车，按照之前的节奏来看 大概需要 半年。 

这里面涉及到的不仅是方案上线和部署，历史的case、数据、性能等都需要重新做，而且整个行业都很在意的主动安全、AEB等很严肃的东西都需要做大量的验证，我认为， 整个周期至少要 半年。 

Q3：蒋总，您提到会把激光雷达作为真值，而BEV很大程度上强化了视觉算法，视觉在整个感知里重要性增强，那么你怎么看 后续系统对激光雷达和高精地图的 依赖程度？

A：这其实是两个东西。 

首先，像商汤最早做智驾开发系统设计的时候，就把在线建图的输出跟高精地图的输出格式做了统一。从我们的角度来说，高精地图其实是不保鲜的，需要 逐渐把 高精地图拿掉 。 

和激光雷达不太一样，视觉算法对障碍物（如 PVB 等）的检测和还原过程，本质是 对数据的 拟合，见过的可以拟合，没见到的就没办法。从安全性的角度来考虑，激光雷达从原理上就保障了对障碍物的识别精度。另外，城区NOA场景其实很复杂，例如广州的城中村，有的地方到处都是石墩子、人车混行的复杂场景， 现阶段的视觉算法对于障碍物的感知精度，与激光雷达对比还是比较 有限的 。 

个人认为，从精度上来讲，视觉算法肯定还是达不到激光雷达的水平的， 激光雷达还是有天然的 碾压性优势。 

Q4：以大模型、大数据为驱动的算法团队，对于原来智驾团队的研发架构有怎样的影响？ 

A：研发架构是为算法架构 服务的，这一直是我的观点。我们需要思考怎么高效地把算法落地，然后去搭 对应的 架构。 

我觉得，对研发架构可能会有几个影响，一个是因为深度学习的引入，在不同的模块，可能都需要引入一些具备 相关背景的人员。 

另外，可以类比一下以前手机的领域，大家所谓的算法模型研究员和工程分工就比较清晰。因为整个算法就是一个黑盒，工程人员需要做的就是把对应模型部署，然后做对应的嵌入式芯片优化、性能优化。我觉得，整个 智驾演变的方案可能也是这样。 

从研发架构上来讲， 研发和工程的切分可能会越来越明显。 

研发团队会去做算法的研发、模型的产出，工程团队可能会做模型的部署、嵌入式的优化等，以团队分工的架构模式，可能会逐渐替代按模块划分感知、地图、规控的架构模式。 

Q5：刚刚您有提到贵公司在低、中、高配算力芯片上不同的部署，那能聊聊 8Tops和100Tops芯片部署BEV的差异吗？8Tops的芯片可以做BEV吗？ 

A：8Tops的芯片上可以实现BEV感知，而且已经做了。 

首先，8Tops算力的芯片，它的感知精度必然是比不上100Tops的芯片。然后，我们在 算法方案上的选择也会有一些差别。 

高算力平台基本都是基于 Transformer这种carrier-based方案来做；在低算力平台，我们还是选类似 BEVDepth、BEVDet这种2D转3D的方式去实现。 

当然，哪怕是BEVDet也塞不进8Tops芯片，所以我们做了优化。通过模型结构的精简、提高BEV检测距离等算法层面的优化，去提升性能。 

Q6：BEV对数据和算力要求较高，而主流车型价位区间基本在 10万-20万，您判断，BEV适合上车这个价位的车型吗？ 

A：这样说吧，比8Tops高一点的16或者32Tops（的芯片）上都能够实现BEV算法，而这个算力的芯片配置（ 16Tops、32Tops）大概对应10万-20万价位的车型。 

只是难点在于，城区NOA以及我们做的map-less的方案，确实需耗费更多算力资源，这可能有难度。但目前 该价位车型上是 能够部署 BEV方案的，并且也能够实现车道线、目标感知的能力。 

Q7：如果有激光雷达，还有必要做Occupancy（占用网络）吗？Occupancy是不是为脱离激光雷达做的准备？ 

A：不完全算。首先， 3D的Occupancy做不到 激光雷达的 精度的。因为Occupancy本质上是对FreeSpace 往高度层面的扩展。从技术上来说，它确实可以帮规控更好地处理问题。 

但这带来的，不只是对 感知的挑战，对 规控也是一种挑战。因为规控需要接入地图、Free Space、目标障碍物等，同时还需要去算占位图（Occupancy）。 

大家之前都没这样用过。要在结合 3D视觉感知算法下做好确定性的规划，也涉及到各个模块的 联调，同时也需要把感知结果做得更准，最终不再需要通过规控做后处理，直接去构建所谓的「 可通行区域」。 

Q8：如果采用BEV，雷达和相机的布局会发生怎样的变化和影响？比方 传感器的 数量、位置会不会为BEV提供更好的配置？ 

A：在视觉BEV的布置上，我们会尽可能让不同的摄像头之间能有一个 更大的 重叠区域，这样整个的 BEV空间或者特征空间是全的，不太存在漏洞。因为相机去畸变后并不能达到它实际的 视场角（FOV），比如：FOV120度的摄像头，去完畸变，其FOV可能只剩100度或者100多度。 

激光雷达的话，量产车如果要做 成本下探、同时要提升视觉感知精度 ，激光雷达更多的作用就是补盲，能够在城区场景、关键障碍物的感知上实现更好的感知效果。因此激光雷达要装得 稍微 低一点，例如装在车前保险杠等。如果激光雷达装上面，侧边的激光雷达就需要尽量下探一些。 

返回第一电动网首页 >