自动驾驶SoC：行泊一体提速，存算一体与Chiplet技术变革-北京尧图网络

自动驾驶SoC研究行泊一体带动产业提速存算一体、Chiplet带来技术变革这两年聊自动驾驶大家手里都离不开一张“soc天梯图”手机圈那套跑分逻辑在智驾域控上重演了一遍算力从几TOPS一路飙到几百TOPS甚至上千TOPS工艺从16nm追到5nm接口从PCIe 3.0换到PCIe 5.0。但你真把一颗车规级SoC拆开看会发现这它和手机SoC完全是两个物种芯片启动流程、功能安全设计、数据流路径都差着十万八千里。今天我想顺着“行泊一体带动产业提速、存算一体与Chiplet带来技术变革”这条主线聊聊我自己调研和项目落地中的一些判断。这篇文章主要面向做域控制器、算法部署、电子架构预研的朋友也会给刚入行的人补充一些基础背景目标是让你看完能明白“一颗智驾SoC到底在解决什么、为什么传统路径开始走不通、新路径能带来什么价值”。行泊一体是个绝佳的切入点。过去行车和泊车各用各的盒子行车要跑高速领航、城区NCA泊车要搞低速环视、记忆泊车两套系统硬件重、成本高、体验还割裂。行泊一体用一颗SoC同时承接高速、城区、低速泊车全场景直接把单车成本拉下来也让SoC的算力调度、功耗控制和软件迁移成了真问题。与此同时数据量越来越夸张传统冯·诺依曼架构里算力和存储之间的“搬数据”开销压不住了存算一体开始从学术论文走向芯片量产而先进制程费用暴涨、研发周期拖不起Chiplet模式也被提上桌面。这三个词拼在一起其实指向同一件事智驾SoC要从“单芯片堆料”转向“架构效率优先供应链协同优先”。1. 行泊一体自动驾驶SoC的产业催化器1.1 行泊一体的真实需求在哪行泊一体这个词听起来像产品经理造的概念但背后是真实的商业算账逻辑。原来一台车如果要同时支持高速NOA、城区记忆行车、自动泊车、遥控泊车常见方案是一颗大算力行泊主芯片加一颗低算力泊车芯片或者干脆用两颗中算力芯片各管各的。问题是两颗芯片要两套电源、两套存储、两套散热、两套软件BSP硬件BOM成本高不说软件的维护成本更高算法模型在两个芯片之间迁移还容易有精度一致性问题。我见过一个具体项目最初用一颗30TOPS的SoC做行车另一颗8TOPS的MCU级芯片做泊车。行车和泊车各自demo都没问题一到量产联调就崩泊车场景要求360度环视实时拼接而环视摄像头数据在总线上的带宽和行车前视摄像头抢资源行车要的是高速上稳定跟车变道泊车要的是低速下厘米级控制两套控制策略在同一个车辆接口上打架最后只能变成“行车时把泊车进程杀掉”体验自然割裂。换到行泊一体SoC后所有算力池统一调度一个进程里按场景切换任务优先级问题就顺多了。行泊一体要解决的不是把两个功能“硬塞进一颗芯片”而是让一套传感器、一套计算平台、一套软件框架去覆盖泊车到行车的连续体验区间。1.2 为什么SoC是行泊一体的核心行泊一体的技术重心不在算法本身而在于SoC是否具备实时多任务能力。行车任务通常需要前视800万像素摄像头、毫米波雷达、激光雷达可选的融合感知时延要求100ms以内泊车任务需要4-6路环视摄像头时延要求更苛刻因为车辆在低速靠近障碍物误差就是剐蹭。一颗合格的SoC要同时跑起来必须在硬件架构上有几件套第一是异构计算单元。CPU负责调度和逻辑控制NPU负责神经网络推理GPU负责图形渲染和部分并行计算DSP负责信号处理ISP负责图像信号处理MCU核负责功能安全和执行控制。第二是大带宽片内互联。NPU要从内存里疯狂读权重和特征图带宽不够就是算力黑洞很多号称200TOPS的芯片实际利用率不到30%根子就在带宽。第三是硬件虚拟化与隔离行车和泊车任务要跑在同一个物理芯片上但不能相互干扰需要ARM虚拟化或自研TEE支持。第四是安全岛设计功能安全要保证意外出现时芯片能自己兜底而不是全靠外部MCU。行泊一体对SoC的这四个要求其实是整个智驾域控最真实的需求画像。传统单一大算力SoC只拼TOPS的时代结束了多场景多任务的“驾舱融合”“行泊舱一体”正在把芯片推进到系统级效率比拼的阶段。1.3 行泊一体对SoC的四个硬性要求我刚说的四件事展开讲讲就是选型时候的硬指标。算力要求手车泊车一体典型场景需要30-100TOPS。城区行车加360环视加记忆泊车30TOPS是底线50TOPS比较舒适100TOPS能留出OTA迭代余量。注意看算力时一定问一句“稀疏算力还是稠密算力”很多芯片标称算力是INT8稀疏计算跑实际模型时可能直接打六折。功耗要求智能驾驶域控一般散热条件在5-15W风冷到30-50W液冷之间。一颗150TOPS的SoC如果功耗做到85W做液冷是必然的这直接牵连整车成本。行泊一体要求的不是峰值功耗而是“行车工况40W以下、泊车工况15W以下”这种分场景功耗SoC是否能动态关核、动态调频很关键。接口要求8路以上摄像头输入GMSL2/3或者FPD-Link、CAN/CAN-FD、以太网、PCIe或UFS存储扩展、LVDS输出给座舱显示。摄像头接入能力直接决定方案能用多少路环视加前视PCIe通道数量决定能否外接独立NPU加速卡或激光雷达数据处理芯片。软件生态要求工具链是否好用的优先级在很多时候比算力还高。算子是否齐全、编译器编译出的模型效率如何、是否支持量化后精度对齐、有没有完整的MCU安全软件包这些直接决定了算法团队半年还是两周能部署一版模型。提示行泊一体不是“功能叠加”是“从芯片到OS到应用的全栈重构”。选SoC之前先把你未来两年的功能边界想清楚再对着算力和接口表挑芯片否则后面不是加芯片就是砍功能都很难受。2. 存算一体破解“算得动但搬不动”的SoC困局2.1 数据搬移为什么这么要命传统芯片的内部逻辑是NPU算一个乘法先从DRAM里把权重和特征图搬进SRAM/寄存器算完结果再搬出去。自动驾驶大模型动辄上百MB权重连续帧图像数据加上中间特征图每一层推理都要反复搬数据。业界有句老话处理器算一个乘法的时间只要1个单位但从内存取数据可能花掉100个单位数据搬移消耗的能耗可以占到整个AI推理能耗的60%-80%。这也就是行泊一体最头疼的地方。泊车需要四路以上环视输入行车需要前视高清视频和多传感器融合数据每一路都在海量数据搬移算力再高也被存储带宽卡着喉咙。我实测过一个项目NDS领航辅助驾驶系统的模型用了700万像素前视帧率25fps叠加四路500万像素环视、一路后视和一辣椒米波雷达数据光是把所有原始数据搬运到NPU进行计算DDR带宽就已经占掉可用带宽的七成。这就不是软件能优化的硬件架构必须动手术。2.2 存算一体的三种技术路线存算一体Computing-in-MemoryCIM就是冲着这个问题来的把计算塞进存储单元里让数据不用搬出来。目前主流路线分三派第一种是模拟存算一体基于Flash/ReRAM/MRAM这类非易失存储器件直接在存储阵列上完成乘加运算。优点是可以把算力密度做到极高能耗比能达到传统数字SoC的几十倍在边缘场景很有想象空间难点是模拟计算的精度受工艺波动影响大要搞定写噪声、温度漂移、ADC/DAC转换精度问题量产一致性挑战不小。第二种是数字存算一体用标准SRAM单元改进把乘加逻辑嵌入存储阵列旁边做的是数字域计算精度损失小工艺成熟度可控是当前很多创业公司和芯片大厂加速落地的方向。但也因为每个存储单元旁边都堆计算单元面积开销不小不能像模拟方案那样“白拿”算力密度。第三种是近存计算Near-Memory Computing最典型的是三星的HBM-PIM以及台积电的CoWoS封装方案把逻辑芯片和存储芯片封装在一起通过超高密度的微凸点或硅桥连接大幅降低片间带宽瓶颈。严格说它不是存算一体但目标一致让数据和计算挨着。Chiplet时代这项技术和存算一体经常协同出现是争议最少、见效最快的路径。2.3 在自动驾驶场景里能怎么用存算一体不会“替代”NPU它做的是那些数据量最大、重复性最强的操作。自动驾驶里典型的高数据复用场景是环视图像的预处理、BEV鸟瞰视角特征构建、卷积层里的规整乘加、以及车道线检测中的大量小矩阵运算。这些操作共性就是计算模式固定、内存访问密集很适合放到存算一体单元里面。一个比较现实的技术演进是“NPU存算一体核”混合架构主计算还是传统NPU处理复杂动态算子存算一体核做定点的、高占用的算子比如3x3/5x5卷积。靠一个简单的调度器按算子类型分发任务。这种方案的好处是不用推翻现有工具链编译器只需把计算图切分成“走CIM”和“走NPU”两部分对算法团队来说心理负担小很多。我看了不少流片数据数字存算一体在3-5年内的能效比提升大概率能做到2-4倍模拟存算一体更激进但量产风险也更大。存算一体真正要解决的不只是算力墙还有“功耗墙”和“散热墙”——行泊一体的车载环境下功耗降下来液冷降温系统就能省一大笔钱。注意存算一体不是“把内存和计算放一起”就万事大吉。它绕开了DDR带宽瓶颈但引入新瓶颈——控制逻辑、数据串并转换、以及存储密度与计算精度的平衡。选型时重点看算子覆盖率和编译器支持别被单点能效比数字迷惑。3. ChipletSoC供应链与算力扩展的技术变革3.1 为什么要从单芯片转向Chiplet先进制程的升级成本这两年涨得离谱一颗旗舰芯片的开发费用NRE早就是数亿美元级别车规SoC还要加上额外的功能安全认证、长期供货承诺很多厂商出一颗大芯片头几年都在亏钱。Chiplet的基本思路是把一颗大SoC拆成多块较小芯片各自用最合适的制程制造再通过先进封装拼装成一个完整的芯片系统。举个例子一颗行车泊车一体SoC里面CPU、GPU和ISP逻辑复杂但不追求极致逻辑密度可以用相对成熟的7nm或5nm工艺成本可控NPU单元对逻辑密度和功耗敏感可以单独用最新4nm甚至3nm工艺制造两块小芯片放进同一封装里用UCIe或BoW互联。这就像用乐高搭积木分别定制最适合每个单元的“性价比方案”而不是让所有电路挤在一个die里受同一个制程约束。3.2 从SoC到Chiplet的设计变化Chiplet对芯片设计流程的影响是真刀真枪的。首先是设计模式不同传统SoC是一个大团队围绕一个die反复迭代时序收敛一次比一次难Chiplet模式下各个die可以并行开发只要定义好die间接口标准团队之间能解耦大大缩短开发和验证周期。这对应了很多公司“用不起一颗单芯片流片时间”的痛点。其次是先进封装工艺成为关键环节。台积电CoWoS、三星I-Cube、intel的EMIB这些封装技术核心就是把多个die通过硅中介层或硅桥连接带宽可以做到每平方毫米上百甚至上千Gbps而传统PCB走线带宽只有它的零头。对SoC来说存储带宽和die间互联带宽过去是天花板现在用2.5D封装能瞬间拉高几个数量级。再者是UCIe接口标准的作用。UCIe在2022年被正式推进定义了chiplet之间物理层和协议层统一标准目标就是让不同厂商、不同工艺的芯片模块可以像插拔标准件一样组合。自动驾驶行业最需要这种“混搭”国产NPU模块、成熟CPU模块、第三方高速接口模块、自研安全岛模块可以拼在一起它直接改变了车规SoC的供应格局。3.3 对自动驾驶产业的影响Chiplet对自动驾驶产业的影响不只是技术层面还牵动供应和商业模型。过去车厂选SoC就像“买全家桶”芯片厂商提供完整方案一颗芯片绑定制程、功能集、工具链一家独大很容易。Chiplet带来的是“选择权回归”你可以从不同供应商买CPU算力模块、NPU加速模块、存储模块再找一个封装厂整合像选电脑配置一样攒一个最合适的智驾SoC。这种模式对国内创业公司特别友好不用一上来就扛全球顶尖制程的费用先用成熟工艺先进封装做出够用的方案再逐步换更好的NPU模块。另外Chiplet让迭代周期大幅缩短。一颗全定制SoC从设计到量产动辄36个月以上而Chiplet架构下你可以每18个月换一颗新NPU模块适配新一代算法其他模块保持不变软件栈基本不重写。这就回应了行泊一体行业的一个核心矛盾算法每半年就升级一次而芯片开发周期比算法慢三倍以上Chiplet是当前能想到的最好的时间差弥合方案。提示Chiplet不是万能药先进封装的成本和良率风险依然存在die间互联的功耗、信号完整性、热膨胀系数匹配都是硬骨头。中小公司真正能玩转Chiplet的路径是“模块化采购标准接口整合”不要盲目自研全部模块。4. 自动驾驶SoC的整体设计与关键选型4.1 从芯片启动流程到域控软件栈很多入行朋友第一次接触自动驾驶SoC遇见第一个概念就是“soc芯片启动”这个启动流程比手机启动复杂得多。一颗智驾SoC上电后先由固件运行BootROM加载引导程序初始化DDR存储和时钟系统然后启动安全岛MCU完成自检再启动Cortex-A系列的大核CPU加载RTOS或Linux内核最后拉起NPU驱动的推理运行时。整个过程对功能安全等级有明确要求每次启动都要判定芯片的硬件是否正常异常时能否进入安全状态并通知外部看门狗或行车安全控制器。软件栈层面行泊一体域控的典型分层是底层是RTOS或Hypervisor向上提供多个虚拟化环境中间层是通信中间件SOME/IP、DDS、功能安全框架、OTA客户端再上层是感知、融合、规划、控制算法模块其中泊车和行车模型可以共享中间件和数据接口但根据优先级别做动态调度。这块我已经跟不少人说过选SoC时不要只盯着硬件数据手册工具链的编译器是否支持C17、是否支持PyTorch/TensorFlow/ONNX全链路、有没有车规级的安全运行时这些才是算法团队能否按期交付的关键。4.2 CPU、GPGPU、NPU的选型逻辑自动驾驶SoC内部除了NPUCPU和GPU以及DSP都有不同分工。CPU选型一般看ARM的公版授权Cortex-A78AE/A710AE这种带功能安全特色的核心比较常见主频高低影响业务调度流畅度。GPU方面如果做UI拼接、360环视3D渲染、Transformer模型加速的并行操作需要一定GPU算力但这不是行业内卷重点。真正决定智驾SoC性能档位的是NPU和外围数据通路。NPU的选型底线要看四件事峰值算力一般以INT8 TOPS计、典型CNN模型实测帧率、Transformer类模型的时序transformer支持这直接关系到BEV算法能不能跑、以及算力利用率。我见过宣传“100TOPS”的芯片在跑一个轻量backbone时速率还不错一上BEVTransformer模型就崩因为算力在矩阵乘法单元是满的但数据调度和内存访问带宽不够利用率掉到35%。选型时务必用你要跑的模型现场实测别只看天梯图。4.3 工具链、数据集、测试验证一个都不能少芯片选型还有三个软性指标最容易踩坑工具链、数据集和测试验证环境。工具链方面检查三件事编译时间够不够短一版模型能不能在30分钟内完成编译、算子和模型支持全不全ONNX/Runtime里有多少算子能直接跑、精度损失可不可控INT8量化后mAP掉点是否在1%以内。一个真实的项目经验是我们换工具链时才发现某家芯片的编译器不支持5D张量的TransposeReshape融合优化导致一个关键操作只能先拆分再拼接推理延迟多了30%。数据集方面行业常用的是nuScenes、Waymo Open Dataset、KITTI和国内一些路采数据集。行泊一体的数据集要同时覆盖高速、城市道路、园区、地库、夜间、雨天、逆光等场景。规模上感知训练集通常几百万帧起步标注格式要兼容检测、分割、跟踪、轨迹预测、BEV和OCC占用网格。测试验证方面除了仿真测试Carla、LGSVL、VTD等还需要硬件在环HiL和整车在环ViL。HiL环境可以模拟CAN信号、摄像头输入视频流、雷达目标用来验证SoC上运行的感知融合与控制算法ViL则把真实车、真实传感器和仿真场景结合。做行泊一体验收时特别要测一个容易被忽略的边界泊车过程突然切换行车任务比如倒库到一半用户一脚油门想走又立刻回倒挡这个切换的时延和稳定性最能暴露SoC任务调度能力好坏。很多高算力芯片跑单场景测试很流畅拼切换就露出马脚。5. 实操视角SoC选型与量产踩坑5.1 从我经手项目里整理出的SoC选型对照表基于这几年和团队一起做过的多个项目我整理了一个选型对照思路供大家参考不是参数表是需求匹配表。需求维度低配方案中配方案高配方案行泊一体功能高速NOA遥控泊车高速NOA城区记忆行车记忆泊车全场景城区NCA代客泊车驾舱融合所需典型算力15-30 TOPS50-100 TOPS200-500 TOPS传感器接入5-6路摄像头前视环视7-9路摄像头5R雷达11路摄像头5R可选激光雷达芯片形态单SoC集成方案单SoC独立MCU安全冗余多Chiplet/多Die或双SoC冗余工具链要求基础CNN检测模型BEV全栈工具链支持多模态大模型和统一调度典型量产风险泊车功能影响行车稳定性切换时延大、功耗超限系统复杂度高、软件集成难度大我说一下里面几条重要的判断。第一很多厂商把行泊一体low配方案做成“前视一体机环视泊车盒子”的组合严格说不算真行泊一体这导致算力分散、软件割裂如果追求真正的体验统一至少要从中配起步。第二中高配的芯片选择必须同时考虑MCU冗余方案例如用一颗安全MCU跑基础控制SoC主要负责感知和规划两边有硬件握手逻辑这在行泊一体场景里是必须做的因为泊车时人在车外功能安全要求不是开玩笑。第三Chiplet方案的选型目前还处在评估期建议先选择一家能提供成熟UCIe/先进封装方案的厂家做设计验证别拿自己的项目去赌不成熟的封装供应链。5.2 常见问题与排查技巧实录我一直觉得“简化版的解说是没有价值的真实项目中的坑才是最好的教材”。这里给你抄几条我们踩过的坑第一个坑环视摄像头数据带宽把DDR吃到爆系统直接掉帧。排查方法是先用busybox抓/proc/uid_stats和/tools的带宽监控或者在SoC上跑一个内存带宽检测工具逐个关闭摄像头通道确认每条流占用。最终方案是启用SoC自带的多路ISP硬件拼接功能让环视数据在ISP内部生成虚拟摄像头视角不再全部拉到NPU里做拼接带宽瞬间降了40%。第二个坑泊车场景的模型在INT8量化后车位检测精度掉得很厉害。一开始怀疑是量化器算法问题后来发现是SoC NPU对某些激活函数的处理只能走查表法精度损失不算意外。解决方式也简单在模型中用SiLU替换掉精度敏感的激活函数重新训练并量化掉点控制在0.5%以内。第三个坑行车和泊车任务同时跑时CPU核中断风暴导致任务超时。排查时用到了Linux的perf发现大量网络中断集中在一个核上把中断绑到独立核心并开启了网卡的由DMA直接写DDR的功能超时问题就消失了。这提醒了我和团队——行泊一体的真正瓶颈在系统层而不在算法层选SoC时一定要看它有没有硬件中断绑定和DMA通道隔离能力。第四个坑芯片“启动玄学”偶发起不来尤其在低温冷启动。排查发现是DDR初始化参数没适配低温环境下的时序。芯片厂商提供的参考初始化序列通常只在室温环境验证过量产前做全温区的DDR测试非常必要。这个坑在SoC方案落地中最容易被忽略但也最容易让整车厂对你的方案丧失信心。注意以上四个坑是行泊一体SoC项目里最典型的四类问题分别涉及带宽、精度、中断、时序。我自己总结的排查优先级是先看数据流是否合理再看算子映射是否高效再看系统资源是否被个别中断抢占最后才怀疑芯片本身。大部分时候问题不在算力大小而在架构匹配度。5.3 对未来三年行业趋势的个人判断基于这些项目经验我对未来三年的判断是这样的首先行泊一体会从“谈判筹码”变成“行业默认配置”30TOPS以下单独的行车SoC和泊车SoC会被逐渐淘汰至少是朝着一颗SoC集成全场景的方向走。真正的增量竞争会转向“驾舱融合”这里的SoC要同时跑仪表盘、座舱娱乐、行车感知和泊车控制对虚拟化隔离和混合关键性任务调度要求极高。其次存算一体最可能在2026-2027年进入量产级应用。短期内更稳妥的是近存计算和数字存算一体模拟存算一体的精度问题需要更多时间解决。很多车厂已经把存算一体纳入下一轮SoC预研但真正规模上车的窗口应该在2028年左右。再次Chiplet在自动驾驶SoC中的应用会快于很多人的预期。背后的推手不只是先进制程成本还有供应链的确定性需求。当一颗完整的车规SoC依赖一个工厂、一个节点的几年稳定供应时整车厂比谁都着急Chiplet的多源采购是它们最想看到的方案。未来三年的智驾SoC市场会是“自研大芯片”“模块化Chiplet”“成熟中小算力国产SoC”三种路线并存的多极局面。这个行业发展到今天算法已经很多数据也不少唯独算力平台能力距离理想状态还有很远的距离。在可预见的未来芯片层的变革仍然会是整个自动驾驶产业往前走的发动机。6. 我个人的一些体会做了这么多智驾SoC相关项目我最深的一个感受是赛车不是光有发动机就能赢的底盘、传动、配重、轮胎一个都不能少。对自动驾驶SoC而言单说“多少TOPS”已经没有意义真正拉开差距的是数据通路的规划、功耗功耗的调度、以及任务切换时的系统韧性。行泊一体、存算一体、Chiplet——这三个概念指向的其实是同一个方向把芯片做成真正服务于整车的系统而不是炫耀算力参数的玩具。最后再分享一个小技巧评估任何一款自动驾驶SoC前先拿你未来两年最核心的5个功能场景写成一个真实车辆路谱不仅测平均帧率还要测“切换时延”“满载带宽”“极限温度下的跑分稳定性”这三个指标。只看天梯图的走不远真正能落地的是那些在台上台下都扛得住的项目。按照这个思路去选型大概率不会踩大坑。

自动驾驶SoC：行泊一体提速，存算一体与Chiplet技术变革

相关推荐

从射线感知到反向传播：手写神经网络赛车全链路避坑

商城积分系统架构设计：从账本模型到高并发扣减的工程实践

Spring Boot + MyBatis + JSP图书管理系统实战：从搭环境到避坑全攻略

更多资讯

CFileDialog 模板嵌入自定义控件：机制、实现与排查

t3code：本地代码片段管理与模板生成命令行工具实践

t3code 项目实战：T3 技术栈全栈 TypeScript 开发与部署指南

FPGA驱动双目OV5640并通过HDMI显示：DVP接口与TMDS编码实战

ECC三义辨析：纠错码、椭圆曲线密码与SAP系统全解析

t3code 编码实践：先跑通、再组合、后规范的三层演进思路

今日更新

微信个人号API开发案例：图片/语音/视频消息怎么下载解析存到本地？

Python股票自动交易系统源码解析：从行情获取到风控的完整链路

视酷酷信IM源码部署指南：Java 17+MySQL 8.0.33实战配置

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？