华为MDC 610/810双域控方案：CCA架构与200 TOPS算力部署实战

1. 从CCA架构说起华为为什么要做“计算与通信”的融合平台我第一次接触华为CCA架构是在一个智能驾驶域控选型的项目里当时团队在讨论到底用传统分布式ECU方案还是上集中式域控有人甩出了一份MDC 610和MDC 810的对比资料里面反复提到一个词——CCA。后来花了不少时间把这条技术线捋清楚才发现它不只是一个硬件平台的命名而是华为在智能汽车计算平台上的一整套设计哲学。CCA全称是Computing and Communication Architecture直译过来就是“计算与通信架构”。这个名字本身就点明了它的核心思路把“算”和“连”这两件事从底层就绑在一起设计而不是先做一块算力板再外挂几个通信模块。传统做法里计算平台和通信网络往往是两拨人分别设计的算力板负责跑算法网关负责转发数据中间靠一堆线束和协议对接。这种模式在分布式ECU时代还能凑合但到了L3以上的智能驾驶场景传感器数量暴增、数据带宽需求飙升算力和通信割裂带来的延迟、带宽瓶颈、同步问题就会集中爆发。华为CCA架构要解决的就是这个矛盾。它把计算单元、通信单元、供电、散热、安全模块在架构层面统一规划形成一个“硬件平台软件框架工具链”的完整底座。MDC 610和MDC 810就是基于CCA架构落地的两款代表性域控制器产品前者面向中低算力场景后者面向高算力场景两者可以组成“双域控”方案覆盖从L2到L4的智能驾驶需求。这里有个关键点需要说清楚CCA架构不是单纯堆算力而是强调“算力效率”。什么意思同样标称200 TOPS的平台有的方案实际跑起来只能发挥出60%的算力因为数据搬运、内存带宽、任务调度拖了后腿。CCA架构通过计算与通信的协同设计让算力能更高效地转化为实际推理性能。这也是为什么华为在宣传MDC平台时总喜欢强调“有效算力”而不是“峰值算力”。适合谁来参考这篇内容如果你是做智能驾驶域控选型的系统工程师、负责自动驾驶软件部署的算法工程师或者是对车载计算平台感兴趣的技术管理者这篇内容应该能帮你把MDC 610/810和CCA架构的关系、双域控方案的设计逻辑、200 TOPS算力的实现路径理清楚。我会尽量用实际项目中的视角来讲而不是照搬产品手册。2. MDC 610与MDC 810的核心差异不只是算力数字的区别2.1 算力配置与芯片架构解析MDC 610和MDC 810最直观的差异当然是算力。MDC 610的典型配置在48 TOPS到100 TOPS之间根据具体版本和散热条件有浮动而MDC 810可以做到200 TOPS以上部分高配版本甚至能到400 TOPS。但这个数字背后芯片架构的差异才是真正决定适用场景的因素。MDC 610通常搭载的是华为自研的昇腾310系列AI芯片采用达芬奇架构主打能效比。它的设计思路是“够用就好”面向的是L2到L3级别的智能驾驶功能比如高速领航辅助、自动泊车、城区拥堵跟车这些场景。这些场景的特点是传感器数量相对可控比如5个摄像头3个毫米波雷达12个超声波雷达算法模型以中等规模的CNN和部分Transformer为主对算力的需求不是无底洞但对功耗和成本非常敏感。MDC 810则搭载昇腾610芯片算力密度大幅提升。它的目标场景是L3到L4传感器配置可能是11个摄像头5个毫米波雷达3个激光雷达数据吞吐量是MDC 610的数倍。昇腾610在架构上做了几件关键的事一是增加了矩阵计算单元的数量和位宽二是优化了片上缓存和内存带宽三是强化了多芯片互联能力。这些改动让MDC 810在处理大规模点云、多路高分辨率视频流、复杂BEVTransformer模型时能保持较低的延迟。我整理了一个对比表格方便你快速看清两者的定位差异对比维度MDC 610MDC 810典型算力48-100 TOPS200-400 TOPS核心芯片昇腾310系列昇腾610目标场景L2到L3L3到L4传感器配置5V3R12U左右11V5R3L左右功耗范围约50-100W约150-300W散热方式风冷为主液冷为主典型车型中端智能电动车高端旗舰智能车型这个表格里的数字不是绝对的因为华为给OEM厂商的是一套可配置的方案具体参数会根据车型的散热条件、传感器配置、功能定义做调整。但大致的定位区间是清晰的。2.2 接口与扩展能力对比接口这块是很多人在选型时容易忽略的地方但实际项目中它往往决定了一个平台能不能“撑到”车型生命周期结束。MDC 610的接口配置相对精简通常有4-8路摄像头输入GMSL或FPD-Link、4路CAN/CAN-FD、1-2路千兆以太网、若干路LIN和FlexRay。这个配置对于L2场景是够用的但如果你后续想加激光雷达或者升级到更高分辨率的摄像头接口数量可能就会成为瓶颈。MDC 810在接口上明显更“富裕”摄像头输入可以做到12-16路以太网接口支持万兆级别CAN/CAN-FD通道数量翻倍还预留了PCIe扩展槽用于加装额外的加速卡或存储模块。更重要的是MDC 810支持多芯片级联两颗昇腾610可以通过高速互联总线组成一个更大的计算池算力叠加的同时保持内存一致性。这个特性在双域控方案里非常关键后面会详细讲。注意接口数量不是越多越好每增加一路高速接口PCB布线难度、EMC风险、散热压力都会上升。选型时要根据“当前功能需求未来2年OTA规划”来定不要为了“留余量”而过度设计否则成本和开发周期都会失控。2.3 软件栈与工具链的兼容性MDC 610和MDC 810在软件层面是高度兼容的都跑华为的MDC软件平台支持AUTOSAR Adaptive、ROS2、以及华为自研的MindSpore推理框架。这意味着如果你先在MDC 610上开发了算法后续迁移到MDC 810时大部分代码不需要重写只需要针对算力提升做模型量化和并行化优化。但这里有个坑MDC 610和MDC 810的算子库版本可能不同。昇腾310和昇腾610支持的算子集有差异某些在310上能高效运行的算子在610上可能需要替换成等效实现。我遇到过的情况是一个基于Depthwise Convolution的轻量级分割模型在MDC 610上跑得很好迁移到MDC 810后反而变慢了原因是610的硬件架构对Depthwise算子的优化不如310激进。后来换成普通Convolution加通道剪枝性能才恢复正常。所以如果你打算用双域控方案软件团队需要提前做算子兼容性测试不能假设“高算力平台一定能跑得更快”。3. 双域控方案的设计逻辑为什么要用两个域控而不是一个3.1 单域控方案的瓶颈在哪里在讨论双域控之前先说说为什么单域控方案在某些场景下不够用。一个MDC 810理论上可以搞定L3级别的所有功能但实际项目中会遇到几个问题第一是功能安全隔离。智能驾驶系统里不同功能的安全等级要求不同。比如自动紧急制动AEB要求ASIL-D而舒适性跟车功能可能只需要ASIL-B。如果所有功能跑在同一个域控上一旦高安全等级的功能出现故障可能会影响低安全等级功能的运行反之亦然。虽然可以通过Hypervisor做虚拟机隔离但硬件层面的隔离更彻底。第二是散热和功耗的物理限制。MDC 810满载功耗可以到300W如果再加上传感器融合、规划控制、座舱交互等所有任务功耗和发热会非常可观。单域控方案需要更复杂的散热设计而双域控可以把负载分散每个域控的散热压力更小。第三是OTA升级的灵活性。双域控方案可以做到“一个域控升级另一个域控继续运行”实现不停车升级。单域控方案在升级时通常需要停车等待用户体验会打折扣。3.2 双域控的典型分工模式华为MDC 610/810双域控方案常见的分工模式有两种模式一按功能安全等级分工。MDC 810负责高安全等级的核心驾驶功能AEB、车道保持、自适应巡航MDC 610负责舒适性功能和座舱交互导航、娱乐、语音助手。两个域控之间通过高速以太网交换必要的数据比如MDC 610把导航目的地的路径信息发给MDC 810MDC 810把车辆状态和感知结果发给MDC 610用于显示。模式二按传感器域分工。MDC 810处理前向主摄像头、激光雷达、前向毫米波雷达的数据负责前向感知和决策MDC 610处理侧后向摄像头、超声波雷达的数据负责泊车、盲区监测、变道辅助。这种分工模式下两个域控各自有独立的感知 pipeline最后在决策层做融合。我参与过的一个项目用的是模式一实际跑下来发现几个经验点两个域控之间的数据同步非常关键如果时间戳对不齐融合结果会出现“鬼影”或者目标跳变。我们当时的做法是用PTP精确时间协议做时钟同步同步精度控制在1毫秒以内同时在应用层做时间戳对齐和插值补偿。3.3 双域控的通信与同步机制双域控之间的通信通常走千兆或万兆以太网协议上可以用SOME/IP、DDS或者华为自研的通信中间件。选择哪种协议取决于你的软件架构如果用的是AUTOSAR AdaptiveSOME/IP是自然选择如果用的是ROS2DDS更顺手。同步机制方面除了前面提到的PTP时钟同步还需要考虑数据缓冲和丢包处理。以太网通信在车载环境下可能受到电磁干扰出现偶发丢包。我们的做法是在应用层加一个滑动窗口缓冲收到乱序或延迟的数据包时先缓存等齐了再处理。窗口大小根据实际网络抖动情况调整一般设50-100毫秒。提示双域控方案的通信带宽规划要留足余量。我们当时按峰值数据量的1.5倍来设计带宽实际跑下来在极端场景比如隧道内多目标强电磁干扰下网络利用率会冲到80%以上如果没有余量就会出现延迟飙升。4. 200 TOPS算力的实现路径从芯片到系统的全链路优化4.1 昇腾610的算力构成200 TOPS这个数字是怎么来的昇腾610芯片内部有多个计算核心包括矩阵计算单元、向量计算单元、标量计算单元。TOPSTera Operations Per Second通常指的是INT8精度下的理论峰值算力。昇腾610在INT8下的峰值算力可以到200 TOPS以上但这是理论值实际能跑出多少取决于模型结构、内存带宽、任务调度等多个因素。我实测过几个典型模型在MDC 810上的表现ResNet-50在INT8下可以跑到每秒数千帧YOLOv5s可以跑到几百帧BEVTransformer模型比如BEVFormer的简化版可以跑到30-50帧。这些数字和理论峰值有差距但考虑到车载场景对延迟和功耗的约束这个表现已经相当不错了。4.2 算力效率的关键影响因素内存带宽是第一个瓶颈。昇腾610的片上缓存有限大部分模型参数和中间激活值需要存在DDR里。如果模型的内存访问模式不友好比如频繁的随机访问或者大跨度的卷积内存带宽就会成为瓶颈算力利用率可能掉到30%以下。优化方法是做内存布局优化把卷积的输入输出按NHWC格式排列减少跨通道访问。算子融合是第二个关键。昇腾610支持算子融合可以把ConvBNReLU这样的组合融合成一个算子减少中间结果的写回和读取。我们在部署一个分割模型时通过算子融合把推理延迟从45毫秒降到了28毫秒效果非常明显。多核并行是第三个手段。昇腾610有多个AI Core可以把一个大模型的不同层分配到不同核心上并行计算也可以把多个小模型分配到不同核心上同时推理。但并行不是免费的核心之间的数据同步和任务调度有开销。我们的经验是当模型的计算量足够大比如单层计算超过1毫秒时并行收益才明显小模型并行反而可能变慢。4.3 从芯片算力到系统算力的转化200 TOPS是芯片的算力但系统层面的有效算力还要打折扣。折扣来自几个方面一是散热限制如果温度过高芯片会降频算力直接下降二是供电限制瞬态大电流可能导致电压跌落触发保护三是软件开销操作系统、通信中间件、安全监控都会占用一部分CPU和内存资源。我们在一个项目里做过测试MDC 810在25度室温、液冷正常工作的条件下持续跑满载推理任务芯片温度稳定在65度左右算力输出稳定在标称值的85%以上。但在45度高温环境下如果散热系统不给力温度冲到85度以上算力会掉到60%以下。所以散热设计不是“配角”它直接决定你能不能用满200 TOPS。影响因素典型影响幅度优化手段内存带宽瓶颈算力利用率降至30-50%内存布局优化、算子融合散热降频算力下降15-40%液冷设计、导热材料优化供电波动瞬态算力下降10-20%增加去耦电容、优化电源树软件开销占用5-15% CPU资源实时性调优、资源隔离5. 实操落地MDC 610/810双域控方案的部署要点5.1 硬件集成与散热设计硬件集成阶段最容易出问题的是散热和供电。MDC 810的功耗高如果用车载风冷需要保证风道设计合理进风口不能有遮挡出风口的熱空气不能回流。我们当时用红外热像仪扫过一遍发现靠近出风口的线束温度比预期高15度后来加了隔热套管才解决。供电方面MDC 810的瞬态电流可能达到几十安培电源线径要足够粗接插件要选车规级的高电流型号。我们踩过的坑是一开始用了普通接插件结果在低温启动时出现接触电阻过大导致域控反复重启。换成镀金车规接插件后问题消失。液冷方案的话冷却液的流量和温度要匹配域控的发热量。一个经验公式是每100W功耗需要至少0.5L/min的冷却液流量冷却液入口温度建议控制在25-35度之间。如果入口温度过高芯片结温会逼近上限触发降频。5.2 软件部署与算力分配软件部署的第一步是确定哪些任务跑在MDC 810上哪些跑在MDC 610上。我们的原则是安全关键、延迟敏感的任务放810舒适性、非实时任务放610。具体来说AEB、LKA、ACC的感知和决策跑在810上导航渲染、语音交互、OTA管理跑在610上。算力分配要用工具来量化不能拍脑袋。华为的MDC工具链里有算力评估工具可以输入模型结构估算在目标芯片上的算力占用和延迟。我们当时把每个模型的算力需求列出来加总后发现810的算力占用到了75%610到了60%留了25%-40%的余量给后续OTA。这个余量是必要的因为新功能往往会增加算力需求。注意算力分配不是一劳永逸的。每次OTA增加新功能后都要重新评估算力占用。我们遇到过OTA后某个模型版本更新算力占用突然增加了20%导致810的余量被吃光后来不得不把部分非关键任务迁移到610上。5.3 通信中间件配置与调优双域控之间的通信中间件配置直接影响系统延迟和稳定性。我们用的是DDS配置了几个关键参数一是QoS策略可靠性设为RELIABLE确保关键数据不丢二是历史深度设为10允许缓存最近10个数据包三是心跳间隔设为100毫秒用于检测通信链路是否正常。调优过程中发现DDS的默认配置在车载网络环境下不够用。默认的发送缓冲区太小高带宽数据比如点云发送时会丢包。后来把发送缓冲区从64KB调到1MB丢包问题解决。另外DDS的发现协议在系统启动时会广播大量数据如果两个域控同时启动网络会短暂拥塞。我们的做法是让610延迟5秒启动错开发现阶段。6. 常见问题与排查技巧实录6.1 算力不达预期的排查思路问题现象MDC 810上跑一个标称需要100 TOPS的模型实际推理延迟比预期高出一倍。排查步骤先用华为的profiling工具看算力利用率如果低于50%说明瓶颈不在算力本身。检查内存带宽占用如果接近峰值说明是内存瓶颈。优化方法是做算子融合和内存布局调整。检查芯片温度如果超过80度说明在降频。改善散热后重新测试。检查是否有其他任务在抢占AI Core资源。用资源隔离工具把关键任务绑定到专用核心上。我们当时遇到的情况是内存带宽瓶颈优化后算力利用率从45%提升到了78%延迟降到了预期范围内。6.2 双域控通信延迟过高的处理问题现象MDC 610和MDC 810之间的数据同步延迟超过10毫秒导致融合感知出现目标跳变。排查步骤用网络抓包工具看两个域控之间的实际通信延迟。如果网络延迟本身很低比如1毫秒问题出在应用层。检查应用层的时间戳对齐逻辑。如果两个域控的时钟不同步时间戳会对不齐。用PTP同步时钟精度控制在1毫秒以内。检查数据缓冲窗口大小。如果窗口太小乱序数据包会被丢弃如果太大延迟会增加。根据实际网络抖动调整窗口大小。我们的问题是时钟同步精度不够PTP配置有误。修正后延迟降到了3毫秒以内目标跳变消失。6.3 常见问题速查表问题现象可能原因排查手段解决措施算力利用率低内存瓶颈、算子不兼容profiling工具、内存带宽监控算子融合、内存布局优化芯片降频散热不足、温度过高温度传感器读数、热像仪改善散热、降低环境温度通信丢包缓冲区太小、网络拥塞网络抓包、缓冲区监控增大缓冲区、错开启动时间域控重启供电不足、接触不良电压监控、接插件检查更换高电流接插件、增加去耦电容模型迁移后变慢算子集差异、量化策略不当算子兼容性测试、量化对比替换等效算子、重新量化6.4 独家避坑技巧技巧一提前做算子兼容性矩阵。如果你打算在610和810之间迁移模型提前把两个平台支持的算子列表拉出来做对比标记出差异项。我们当时没做这一步迁移时才发现某个自定义算子只在310上有优化实现610上只能用通用实现性能差了三倍。技巧二散热设计要按峰值功耗的1.3倍来留余量。很多团队按典型功耗设计散热结果夏天高温或者长时间满载时就会降频。按峰值功耗的1.3倍设计虽然成本高一点但能保证全工况下的算力稳定性。技巧三双域控的启动顺序要错开。两个域控同时启动时网络发现协议会产生广播风暴导致启动时间变长甚至失败。让一个域控延迟5-10秒启动可以避开这个问题。技巧四OTA升级前先做算力预算。每次OTA增加新功能前用工具估算新增的算力需求确保不会超出域控的算力余量。我们吃过亏OTA后算力超了只能紧急回滚。7. 双域控方案的扩展方向与个人体会双域控方案不是终点它更像是一个过渡形态。从技术趋势看未来可能会走向“中央计算区域控制”的架构把算力进一步集中同时用区域控制器管理传感器和执行器。但在当前阶段MDC 610/810双域控方案是一个务实的选择它平衡了算力、成本、散热、功能安全等多个约束能覆盖从L2到L4的广泛场景。我在实际项目中的体会是双域控方案的成功与否硬件选型只占三成剩下七成靠软件集成和调优。算力分配、通信同步、散热管理、OTA策略这些“软”的东西往往比“硬”的参数更能决定最终体验。如果你正在做类似的项目我的建议是尽早搭建原型系统用真实数据跑通全链路不要等到硬件定型了才开始调软件。另外华为的MDC工具链更新比较频繁建议定期关注版本更新日志新版本往往会优化算子性能或者增加新的调试功能。我们有一次升级工具链后同一个模型的推理延迟直接降了15%算是意外之喜。最后分享一个小技巧在双域控方案里给两个域控各留一个“应急降级”模式。当810出现故障时610可以接管部分核心功能比如把AEB降级为简单的碰撞预警保证车辆能安全靠边停车。这个降级逻辑要在设计阶段就规划好不要等到出了问题再临时加。