自动驾驶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-Memory，CIM）就是冲着这个问题来的，把计算塞进存储单元里，让数据不用搬出来。目前主流路线分三派：
第一种是模拟存算一体，基于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. Chiplet：SoC供应链与算力扩展的技术变革
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时不要只盯着硬件数据手册，工具链的编译器是否支持C++17、是否支持PyTorch/TensorFlow/ONNX全链路、有没有车规级的安全运行时，这些才是算法团队能否按期交付的关键。
4.2 CPU、GPGPU、NPU的选型逻辑
自动驾驶SoC内部除了NPU，CPU和GPU以及DSP都有不同分工。CPU选型一般看ARM的公版授权，Cortex-A78AE/A710AE这种带功能安全特色的核心比较常见，主频高低影响业务调度流畅度。GPU方面，如果做UI拼接、360环视3D渲染、Transformer模型加速的并行操作，需要一定GPU算力，但这不是行业内卷重点。真正决定智驾SoC性能档位的是NPU和外围数据通路。
NPU的选型底线要看四件事：峰值算力（一般以INT8 TOPS计）、典型CNN模型实测帧率、Transformer类模型的时序transformer支持（这直接关系到BEV算法能不能跑）、以及算力利用率。我见过宣传“100TOPS”的芯片在跑一个轻量backbone时速率还不错，一上BEV+Transformer模型就崩，因为算力在矩阵乘法单元是满的，但数据调度和内存访问带宽不够，利用率掉到35%。选型时务必用你要跑的模型现场实测，别只看天梯图。
4.3 工具链、数据集、测试验证一个都不能少
芯片选型还有三个软性指标最容易踩坑：工具链、数据集和测试验证环境。
工具链方面，检查三件事：编译时间够不够短（一版模型能不能在30分钟内完成编译）、算子和模型支持全不全（ONNX/Runtime里有多少算子能直接跑）、精度损失可不可控（INT8量化后mAP掉点是否在1%以内）。一个真实的项目经验是，我们换工具链时才发现某家芯片的编译器不支持5D张量的Transpose+Reshape融合优化，导致一个关键操作只能先拆分再拼接，推理延迟多了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 TOPS | 50-100 TOPS | 200-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个功能场景，写成一个真实车辆路谱，不仅测平均帧率，还要测“切换时延”“满载带宽”“极限温度下的跑分稳定性”这三个指标。只看天梯图的走不远，真正能落地的是那些在台上台下都扛得住的项目。按照这个思路去选型，大概率不会踩大坑。
