这几年如果只让我用一个词来形容汽车行业的变化我会选“重构”。不是换了个动力形式那么简单而是整个产品定义、研发流程、组织架构都在被重写。过去我们做车硬件是主体软件是附属现在反过来了算力、算法、数据成了定义体验的核心硬件变成承载智能的底座。这个转变里最容易被忽略又最要命的就是标题里说的“AI Infra”——AI基础设施。它不像一颗激光雷达或者一块高算力芯片那样能直接写进发布会PPT但整个智能驾驶系统的上限恰恰由它决定。这篇文章我想围绕AI Infra如何支撑“AI定义汽车”这件事聊聊我的理解、我们实践过的一些方案以及在真正落地时踩过的坑。内容会涉及数据闭环、训练平台、车端推理、仿真验证这几个AI Infra的关键组成部分也会穿插一些具体的工程决策和考量过程。准备做智能驾驶研发的工程师或者正在搭建自动驾驶团队的技术负责人看完应该能找到一些可以直接参考的东西。1. 先搞清楚AI Infra到底在解决什么问题1.1 从“软件定义”到“AI定义”研发范式发生了什么变化“软件定义汽车”这个概念大家已经很熟了说的是硬件通用化、功能软件化通过 OTA 持续迭代。但“AI定义汽车”比它又往前走了一步。软件定义时代核心逻辑还是人写规则程序员把判断逻辑一行行敲进去系统按规则执行。AI定义时代规则不再由人直接编写而是从海量数据里自动学习出来。感知模型识别目标、决策模型规划路径这些都不是预先编程的逻辑而是数据训练出来的权重。这一转变带来一个巨大的连锁反应整个研发体系的重心变了。传统的汽车研发流程里硬件开发、软件开发、测试验证是相对串行的一个环节完成再进入下一个。AI研发不一样它是典型的数据飞轮模式——数据采集、标注、训练、评测、部署、回灌形成一个不断旋转的闭环。每个环节都在持续产生新的需求环环相扣任何一个环节效率跟不上整个飞轮就转不起来。这里就是AI Infra登场的时机。它不是某一个单一工具而是支撑整个数据飞轮高效运转的技术栈总和。数据管道是否畅通训练资源是否充足模型上线链路是否自动化仿真评测是否可信这些都是AI Infra要回答的问题。可以说AI Infra的建设水平直接决定了AI定义汽车这件事能做到多快、多稳、多安全。1.2 AI Infra四层架构从芯片到场景的完整链路我在实际规划中习惯把汽车领域的AI Infra拆成四个层次来看。最底层是计算硬件层包括车端的自动驾驶芯片、传感器的ISP/NPU以及云端的训推集群。第二层是平台软件层包括数据管理平台、标注平台、训练调度平台、模型部署服务这一层是工程师日常打交道最多的地方。第三层是算法工具链包括感知训练框架、决策规划仿真环境、模型量化工具、评测体系。最上面一层是场景闭环层也就是针对具体智驾场景的数据采集方案、Corner Case挖掘机制、OTA迭代流程。四层架构每一层都有自己典型的坑。硬件层的问题是算力怎么分配、怎么做到车云协同平台层的问题是数据治理和资源调度工具链层的问题是训练效率和评测可信度闭环层的问题是场景覆盖度和迭代速度。很多团队一开始只关注某一层比如花大力气买了很贵的训练集群但数据管道一塌糊涂模型训练根本喂不饱。或者算法很强但评测体系不可信模型在测试集上指标刷得很高上车一跑就露馅。一个健康的AI Infra四层能力必须均衡发展。就像盖楼地基不牢上面装修得再好也没用。我们内部有个经验评估一个智驾团队的AI Infra水平不要只看他的训练集群有多少张卡而要看他完成一次“数据采集→模型更新→上车验证”的完整闭环需要多久。这个闭环周期才是AI Infra综合能力最真实的体现。2. 数据闭环AI定义汽车的能量来源2.1 数据采集与场景挖掘的工程化取舍数据是AI定义汽车的能量来源没有高质量的数据再强的模型也是无米之炊。但数据采集这件事远不是多装几台路采车、多跑几万公里那么简单。我见过一些团队早期完全依赖随机路采跑了一百万公里回头一看高速巡航场景占了70%城区复杂路口、恶劣天气、稀罕交通参与者的占比低得可怜。模型在高速上表现还行一到城区就被各种长尾场景弄得手足无措。后来我们学乖了做数据采集必须带着“场景地图”去采。在采集任务规划阶段先梳理清楚当前模型在哪些场景下表现最弱把它们列入重点采集清单。比如某个版本的模型在雨夜场景下误检率明显偏高那下一个采集周期就要专门安排雨夜时段的采集任务。再比如某个区域的交通标志样式比较特殊那就派采集车专门跑那个区域。这种场景驱动的定向采集效率比随机路采高出数倍因为每一公里的数据都在解决一个已明确的问题。定向采集会产生另外一个问题数据分布失衡。真实道路上本来就没那么多极端场景你集中采回来的数据会让训练集跟真实分布产生偏差。所以我们的数据管道里专门有一个“分布校准”环节。不同场景的数据入库时打上场景标签训练前做采样策略调整按目标分布对各场景数据做概率采样。不是所有数据都一股脑喂进去而是根据训练目标和场景权重做均衡。2.2 数据治理与标注中那些看不见的成本数据采回来之后真正的麻烦才刚开始。原始数据是传感器流式记录一辆路采车一天的原始数据量就是几个T到几十个T不等。这些数据不能直接进训练管道先要做筛选、清洗、脱敏、抽帧再去标注。如果这些步骤靠人工和脚本零零散散地做数据团队会整天陷在“找数据、导数据、格式转换”这些脏活里根本没有精力去做有价值的分析。我特别想强调数据脱敏这件事很多人不重视但它合规风险极高。人脸、车牌这些个人信息在采集数据里到处都是如果直接用于训练或者外发标注法律风险很大。我们的做法是数据入库后第一步就是跑自动脱敏流水线人脸和车牌统一打码同时保留关键区域的标注参考信息。这活儿看起来不起眼但要是漏了整个数据合规体系就会出问题。标注环节是数据闭环里人力密集的部分也是最容易成为瓶颈的地方。行业里默认的标注链路是“预处理模型自动标注人工审核修正”纯人工标注的成本和速度都扛不住现在的数据量级。我们用一套主动学习的策略来降低标注成本先用已有的模型对新增数据做预标注让标注平台按预标注置信度排序低置信度的优先给人工精标高置信度的做快速抽检。这样一个流程下来人工标注量能压缩一半以上而模型训练效果不受明显影响。数据质量的另一个大头是标注一致性。同一个目标两个标注员的框法可能就不同这会让模型学到不稳定的监督信号。我们的标注平台里内置了质检环节和一致性自动评估抽检比例大概是10%专门看标注框的IoU一致性。不一致的标注会打回重做。虽然这增加了些成本但训练数据的质量是模型性能的天花板这个成本不能省。2.3 真值回灌与数据版本管理数据闭环的最后一个环节是真值回灌。模型完成训练并上车测试后测试中发现的问题场景又会被采集回来经过标注后进入数据集形成新一轮的训练输入。这个环节看似简单但要做得可靠数据版本管理是个关键点。训练数据集的版本管理和代码版本管理本质上是一个逻辑——必须能精确追踪“这个模型是用哪一批数据训练出来的”。我们的数据平台采用快照机制每次训练数据集创建时会生成一个不可变的版本快照记录数据来源、预处理参数、标注版本、采样策略等全套元信息。模型出问题时可以通过这个快照溯源到具体是哪条数据、哪个标注环节引入的问题。没有这套机制模型评测一出现波动排查起来就是大海捞针。3. 训练平台大模型训练的工程体系和成本账3.1 训练集群的硬件选型与算力规划训练平台是AI Infra里花钱最多的部分也是最容易决策失误的部分。在规划训练集群时第一个问题是买什么卡。市面上的主流选择无非是那么几类我自己的判断标准很简单就是看生态成熟度和集群规模扩展能力。生态不成熟再强的算力都是摆设驱动都够你调试几个月。第二个问题是集群规模怎么定。很多团队喜欢一次规划很大的集群但真实利用率往往惨不忍睹。GPU利用率不达标折算下来每张卡的成本就变得非常高。我更建议的做法是分阶段规划起步阶段按当前需求和未来半年的增长预期来配置半年后根据实际使用情况再扩容。超大规模集群带来的分布式训练复杂度并不适合所有阶段的团队。这里有一笔很实在的成本账可以算一下。假设单卡售价折算到三年生命周期加上机房、电力、运维摊销一张高算力训练卡每个月成本大概在数千到上万元。如果你的训练集群平均利用率只有30%那意味着你花三分之二的钱在养闲卡。反过来说利用率提升到70%等于同等成本下算力效能翻倍还多。这笔账算清楚之后就知道为什么我一直强调先优化利用率再谈规模扩容。3.2 大规模分布式训练的并行策略选择模型规模上了百亿甚至千亿参数之后单卡甚至单机都装不下了分布式训练是绕不开的。数据并行是最容易想到的方案每个GPU存一份完整的模型副本吃不同的数据分片。但它有个瓶颈当模型太大时单卡显存放不下完整模型数据并行就不够用了。这时就要引入模型并行把网络的不同层切分到不同GPU上。张量并行则更进一步把每一层内部的矩阵运算也切分到多卡上。这三种并行方式各有适用场景实际工程中我们通常组合使用。我自己在实践中最常用的策略是“数据并行模型并行张量并行”的三维混合并行。具体怎么配比跟模型大小、集群拓扑、显存容量都有关系没有一套通用的最优配置得通过针对性的调试验证来确定。并行策略确定后的通信开销往往又是新的瓶颈。卡间通信是 AllReduce 操作如果集群的互联带宽不够计算再快也得等数据。我们早期的集群踩过这个坑计算密集度上去了但互联还是老架构结果训练效率上不去加了卡也没用。后来的做法是在选型阶段就把卡间互联带宽作为硬性指标来考核宁可计算性能低一点也要保证通信不成为瓶颈。3.3 训练稳定性与断点续训的求生指南分布式训练跑起来只是开始让它稳定地跑完才是真正的考验。大模型训练动辄几天甚至几周期间任何一个节点故障、网络抖动、显存溢出都可能导致训练中断。如果没有完善的容错机制中断之后从头再来那消耗的时间和成本是无法接受的。断点续训是分布式训练的标配能力。每隔一段时间自动保存训练状态包括模型权重、优化器状态、数据加载位置、随机数种子。出问题后从最近的检查点恢复而不是从头开始。检查点保存频率有讲究太频繁会挤占训练时间太稀疏会丢失过多进度。我们早期是一小时一次后来调成按实际训练阶段动态调整一般在训练损失下降比较快的阶段加密保存在损失平台期降低保存频率算是平衡了安全性和训练开销。训练过程中还有很多“看不见的杀手”。比如数据读取比GPU计算慢导致GPU一直等数据利用率直线下滑。我们专门做过排查发现数据加载管线里的一个小瓶颈居然白白浪费了两成的算力。修好之后同样的集群训练速度直接提升25%。这种问题就是典型的AI Infra价值体现——不是算法改进了是基础设施优化了。4. 从云端到车端模型部署与推理优化4.1 车端算力约束下的模型压缩与量化模型在云端训练好了最终要放到车端去跑。车端的芯片算力、内存带宽、功耗限制比云端严格得多一通压缩和优化是免不了的。模型量化是目前最主流的压缩手段把浮点权重压缩成低比特整数表示。以INT8为例模型体积可以压缩到FP32的四分之一推理速度通常能提升2到4倍。量化的挑战在于精度损失控制。不加干预的朴素量化在高动态范围的卷积层上精度掉得比较快对于自动驾驶这种安全敏感场景很难接受明显的精度损失。我常用的方案是量化感知训练——在训练阶段就模拟量化的噪声让模型权重适应低比特表示推理时再做正式量化。比训练后直接量化稳得多特别是在感知模型这种对输出精度要求极高的场景。量化之外模型结构优化也很关键。剪枝去掉冗余的通道和连接蒸馏用大模型指导小模型训练。这是一套组合拳通常先结构优化再接量化或者量化之后再做蒸馏来恢复精度。每一步都会带来推理性能的提升但每一步也都会带来精度的细微损失。工程上需要反复迭代找到一个“精度可接受、速度达标”的平衡点。4.2 推理引擎选型与端到端延迟控制模型压缩完了还要有合适的推理引擎来执行。车端的推理引擎选择是个老话题主流方案各有优劣。有的主打通用性算子支持全面但性能优化一般有的主打高性能针对特定芯片做了深度优化但灵活性受限。我们的经验是不同芯片平台要有不同的适配策略没有一套推理引擎通吃所有硬件。推理延迟是端到端系统里最核心的性能指标之一。感知模型的单帧推理延迟会直接限制系统的最高运行帧率而这又关系到车辆对动态环境的感知实时性。我们一般要求感知链路整体延迟控制在几十毫秒量级预留足够余量应对突发场景。为了优化推理延迟我们会从计算图和算子两个层面入手。计算图层面做算子融合把多个连续算子合成一个减少内存访问和内核启动开销。算子层面则是针对芯片的指令集做手写优化尤其是那些被高频调用的核心算子。这是典型的脏活累活但回报也最直接。经过一轮完整的推理优化后端到端延迟通常能降低30%以上有时甚至能到50%。4.3 端云协同的算力调度与持续OTA迭代车端算力再强跟云端比也是有限的。有些场景需要更复杂的模型或更大的算力比如某些极端情况下的融合感知端侧芯片可能不够用。端云协同的架构就是为这类场景准备的——大部分常规场景完全端侧处理少数复杂场景按需请求云侧算力协助。不过车端和云端之间的通信链路状态不稳定尤其是在地下车库、隧道、高速移动这些场景下网络延迟和带宽波动都很大。端云协同方案需要要有严格的“降级”机制一旦网络不稳定系统必须能无缝切换回端侧独立运行保证用户有一个稳定的体验。OTA持续迭代是AI定义汽车另外一个标志性能力。新模型从训练到上车需要一条完善的发布流水线模型评测通过、量化压缩完成、推理引擎适配、灰度发布、监控反馈。任何一个环节出问题都不能放行上车。我们在实践中花了很大力气建设这条流水线现在基本能做到天级甚至小时级的模型更新频率而不是传统整车开发那种半年一更新的节奏。5. 仿真验证与评测AI定义汽车的安全护栏5.1 虚拟仿真场景库的构建与覆盖度评估对自动驾驶来说仿真验证的价值不管怎么强调都不过分。真实的道路测试成本高、风险大、场景不可控虚拟仿真则可以在封闭环境里以极低代价复现各种边缘场景。一个优秀的仿真平台核心资产就是场景库——覆盖各种道路结构、交通参与者行为、天气光照条件的数字化场景集合。构建场景库最怕的就是“自嗨”。团队闭门造车造了一堆看着很炫酷的场景但真正反映路上真实风险的没几个。我们的做法是场景库构建和真实路测数据打通。路测和量产测试中遇到的所有问题场景都会记录并转成仿真场景入库。同时利用场景挖掘算法通过对大量路采数据的自动分析发现那些从未被记录的潜在风险场景主动补进场景库。场景库的覆盖度需要量化评估。我们内部有一套覆盖度指标体系把场景按道路类型、交通参与者类型、环境条件、行为风险四个维度做交叉分类。每个维度的组合都至少要有一定数量的仿真场景覆盖。这套体系虽然粗略但能暴露覆盖盲区。曾经做过一次盘点发现某个特定类型组合的场景数量为零而这个组合在真实道路上并不罕见。要是没做这个盘点这个风险盲区不知道什么时候才会暴露。5.2 仿真评测指标体系与回归门槛仿真评测不能只看“通过率”要有科学、分层、多元的指标体系。我们把它分成三个层次功能层指标是基本的正确性要求比如目标检测准确率、红绿灯识别正确率、跟车距离保持。行为层指标关注驾驶行为质量包括变道频率、加速度舒适度、体感激进程度。安全层指标则是在危险场景中的避险能力比如紧急制动触发及时性、避障路径安全性。这三个层次缺一不可安全和行为都要兼顾。模型每轮更新后都要在仿真场景库上做完整的回归评测通过不了设定的门槛就不能上车。门槛怎么定很有讲究——定得太严一个模型迭代要好几个月研发速度被拖垮定得太松风险场景漏过去那仿真就变成形式主义。我们在实践中采用的是分层门槛核心安全场景要求零失败高频场景要求高通过率长尾场景要求不恶化。既有硬性底线也留了迭代空间。仿真评测和实车测试之间还有一道衔接。仿真做得再好也只是对真实世界的近似模拟。传感器模型、物理引擎、交通参与者行为模型都有做不准的地方。我们的做法是仿真评测和封闭场地测试交叉验证每轮主要升级先在仿真场景库上筛选出表现最差的若干场景带到封闭场地做针对性实测看仿真评测结论和实际结果有多大偏差。这套机制能有效校正仿真平台的“失真”问题让仿真的价值真正发挥出来。6. 平台化建设与AI Infra的工程化落地6.1 AI开发平台的统一抽象与自助化服务AI Infra团队最容易犯的错是把内部工具平台做成一堆破碎的脚本和孤立的服务。数据一套流程训练一套流程评测又一套流程工程师大量时间花在工具切换和格式转换上效率低得可怜。平台化的核心目标就是统一抽象把数据、训练、评测、部署这些能力封装成统一的服务接口让算法工程师能自助完成大部分工作。我们在平台化建设中遵循“默认自助”原则。算法工程师从提交训练任务到获取评测结果整个链路在统一平台上自助完成。训练资源按项目和优先级自动分配不需要人为审批。数据集的注册、版本管理、读取权限也都在平台上自助操作。这套机制落地后交付效率有了显著提升工程师等待资源、等待数据、等待评测的时间大幅缩短。平台化建设最大的挑战是“组织适配”。工具平台的建设一定要垂直于业务团队实际的使用方式而不是从抽象理想出发造一个谁都不顺手的系统。我们的做法是让一部分算法工程师深度参与整个平台建设过程他们既是平台的使用者又是建设者。平台功能不是由AI Infra团队凭空想象而是来自一线研发团队的实际需求反馈。6.2 资源利用率治理与成本优化实践AI Infra的投入是很大一块成本资源利用率治理是硬性任务。训练集群利用率从30%到70%的优化能带来多少实际收益前面算过账这里说怎么实现。第一阶段是资源调度优化。统一的调度器根据任务优先级、资源需求、集群拓扑自动分配合适的节点。片小块调度和优先级抢占机制提高了整体吞吐。我们早期经常出现一种情况一个大任务占着上百张卡小任务排队排到天荒地老而大任务的GPU利用率又不高。统一调度器上线后这个问题大幅改善。第二阶段是任务生命周期管理。长期挂起的任务自动释放资源空闲资源回收给高优任务使用。这个“自动回收”机制我们反复打磨过最大难点是判断任务到底是真空闲还是假空闲。误杀一个正在跑的长期任务损失很大。最终方案是结合心跳检测、训练日志活跃度、历史运行模式三个维度做综合判断误杀率控制在很低的水平。成本治理还有一个精益手段预算透明化。每个项目组按月能看到自己的算力消耗账单、GPU利用率曲线、数据存储成本。让大家知道算力不是免费的资源使用行为自然开始讲究起来。这比任何行政命令都管用。6.3 端云链路观测与根因分析体系AI Infra的最后一环是端云链路的可观测性。智驾系统是典型的端云一体系统数据从车端采集、上传云端、训练迭代、评测验证、发布回灌整个链路任何一个环节出问题都会影响迭代效率。我们建设了一套覆盖全链路的观测体系从采集任务执行状态、数据管道处理进度、训练集群利用率、模型发布状态到车端OTA的成功率和运行反馈所有环节都有可量化的监控指标。这套观测体系最大的价值在于根因定位。某个版本的模型上车后在特定场景下出现了性能异常。如果没有全链路监控排查这个问题要跨数据、训练、仿真、部署多个团队反复确认信息效率很低。有了全链路观测直接把车端反馈的场景数据和对应版本模型的训练数据、评测结果拉通对比很快就能把问题收敛到具体环节。根因分析我们沉淀了一套结构化流程。出现性能异常时第一步定位影响范围确定是单个场景还是系统性问题第二步回溯数据链路检查训练数据和评测数据的版本是否匹配第三步复现验证在仿真环境重建问题场景确认根因第四步制定修复方案。这套流程现在已经成为我们每次模型迭代的固定动作。7. 一些实操经验分享7.1 搭建AI Infra要避开的几个坑第一别一开始就追求大而全。AI Infra建设是个长期演进的过程不是一次性交付的项目。起步阶段应该聚焦最核心的痛点先把数据管道和训练流程打通跑顺再逐步扩展评测、仿真、部署链路。我见过不少团队总想一步到位搭一个大平台结果平台建成了业务需求早就变了平台反而成了负担。第二不要让AI Infra团队变成“外包团队”。如果业务团队的需求都是零散的单点请求AI Infra团队会陷入无穷无尽的“救火”中永远做不出有体系的事。应该引导业务团队在统一平台上自助解决大部分问题AI Infra团队更多投入在基础能力建设和技术预研上。第三不要忽视非技术因素。AI Infra建设涉及到组织协作和数据共享不同团队之间的信任关系、责任划分、流程规范对落地效果的影响非常大。很多技术方案设计得很好最终却因为组织协同问题推进不下去。技术和管理要双线并行。7.2 关键指标建议与持续迭代方向如果要我给AI Infra定几个关键指标我会选这四个数据闭环周期从数据采集到模型更新上车的完整时间训练集群平均利用率直接反映算力成本效率仿真场景覆盖度反映对安全风险的掌握程度模型上车后的运行反馈率反映系统的持续迭代能力。这四个指标不是孤立的它们像仪表盘一样共同反映AI Infra的健康度。建议团队每隔一段时间就拉出这些指标看趋势——数据闭环周期变长了大概率是某些环节出现瓶颈集群利用率下降了可能是调度策略或者任务结构出了问题场景覆盖度增长停滞意味着场景挖掘的能力需要加强反馈率低数据的流通链路可能出了卡点。及时识别这些信号是AI Infra持续健康运转的关键。回到“AI定义汽车”这个命题。真正定义汽车的不只是算法和模型更是让算法和数据高效运转的那一整套基础设施。AI Infra建设的深度决定了AI定义汽车能走多远。我自己的体会是这件事没有终点它随着业务发展和技术演进而持续演进。但有一点可以确定在AI定义汽车这条赛道上AI Infra的投入回报周期可能很长但它的价值会渗透到产品体验的每一个细节里。