1. 为什么“AI定义汽车”的成败先卡在AI Infra上前阵子有位做算法的朋友跟我抱怨模型在云端的评测集上刷到第一一上实车就被测试同事打回原形白天晚上表现差异大偶尔还会碰到几个完全没见过的场景整个团队都在忙着“修模型”。我当时直接问他一句话你们的数据回传链路一天能进多少有效场景你们的车端推理跑的是量化前的模型还是量化后的模型你们的仿真回归有没有把上个月的所有badcase都跑一遍他愣了半天。这个朋友遇到的问题其实是大量做智能汽车团队的通病——算法、算力、模型大家都舍得投入但真正决定一辆车“AI能力”能多快迭代的恰恰是那条看不见的AI Infra链路。AI Infra这个说法这两年越来越高频。它不是什么新算法也不是某一个具体芯片而是从数据采集、回传、存储、标注、训练、仿真、评测、部署、OTA到车端运行时监控的一整套基础设施。放到整车语境里它承担的就是“AI定义汽车”的全域智能底座这个角色没有底座模型再强也只是实验室里的demo底座扎实新模型才能在几天内完成训练、验证、上车、灰度、放量。传统汽车定义功能靠的是硬件平台和ECU软件功能出厂即冻结最多通过4S店升级一下固件。但现在一辆智能汽车的核心竞争力取决于AI模型能否持续进化感知模型要覆盖更多长尾场景规控策略要更像老司机座舱模型要能理解更复杂的自然语言指令。这些能力没有一个是一锤子买卖它们依赖高频的数据闭环和模型迭代。而迭代速度完全被AI Infra的工程化程度锁死。我常喜欢用一个比喻如果把整车当成一个人AI算法是大脑芯片是心脏那AI Infra就是遍布全身的神经和血管。大脑再聪明神经传导慢、供血不足这个人照样跑不起来。所谓“全域”指的就是它不止管云端的大规模训练集群还管车端的推理算力、传感器数据链路、远程升级通道甚至包括车辆运行一年之后的数据回流。这个底座覆盖了车辆完整生命周期少了任何一环AI迭代就会卡壳。这里需要先给AI Infra划个范围避免聊到最后变成“服务器运维”的另一种说法。我理解的智能汽车AI Infra至少包含以下五层层次职责整车场景举例数据层采集策略、车端过滤、回传、脱敏、存储、索引、场景挖掘从海量路采数据里捞长尾corner case训练层大规模算力集群、分布式训练、断点续训、资源调度千卡并行训练感知大模型仿真评测层场景库、离线指标、闭环仿真、实车路测回归新版本规控策略在仿真环境跑完上万个场景部署层模型转换、量化、推理引擎、车端运行时、OTA把云端训练好的模型安全高效地跑到车规芯片上运营层影子模式、灰度发布、在线监控、数据回流新车模型在影子模式跑几周对比决策一致性这五层叠在一起才是完整的“全域智能底座”。很多团队一开始只把注意力放在训练集群上觉得买个几十张卡、搭个训练框架就是做了AI Infra但没过半年就发现算法在云端跑得飞起上车和迭代却处处是瓶颈。做AI Infra本质上是在做一套端到端的“模型迭代流水线”让数据、模型、算力、车端在一条高效的闭环里运转。这一篇我就把自己在这些层里实战趟过的经验摊开从数据链路讲到底座落地希望对正在做智能汽车基础架构的人有点帮助。2. 从数据回传开始先把数据闭环这条链路打通2.1 车端数据采集不是把传感器数据导出来就行我见过不少团队做数据采集策略很粗放定义一批触发规则比如急刹车、疲劳驾驶、车道偏离规则一触发就把前后几路摄像头和雷达数据全存下来回传云端。这种方式不能说错但它会带来两个严重问题。第一个问题是数据偏差。靠简单规则触发采回来的数据永远集中在规则覆盖的场景里真正算法需要的长尾场景——比如异形车辆、遮挡物、施工改道、极端天气——反而漏掉了。第二个问题是数据质量差。车端采集如果只是为了“把数据存下来”往往没有保存好传感器时间戳、标定参数、车辆底盘状态这些元数据。等数据回到云端要训练模型时才发现不知道这条数据对应的车速、转向角、自车位置信息也没法把激光雷达点云和相机画面在时间上对齐这批数据基本就废了。正确做法是先定义“这条数据将来要用来解决什么问题”再倒推采集策略。比如目标是提升夜间感知那采集规则里就必须包含光照强度、时间、天气这些条件目标是提升路口场景就要结合地图信息和车辆转向动作来判断车辆是否在路口。采集策略本身就是要用数据驱动的方式来做让算法团队和数据平台团队共同维护一套场景触发配置而不是靠几个固定阈值打天下。在车辆端采集模块的职责还包含一层“过滤”。不要把所有触发数据都回传带宽和存储都是成本。车端可以先做初步的场景分类低价值数据只保留索引不保留原始数据高价值数据做小体积压缩后回传。这个工作做得越细云端存储和后续处理压力越小。很多团队前期贪多总担心漏数据最后数据堆了一屋子真正能被用进训练的不到十分之一。2.2 回传链路与存储过滤、脱敏、压缩缺一不可数据要回到云端中间要过无线网络。无论是走4G/5G还是Wi-Fi热点回传策略都得考虑流量成本、带宽峰值和网络不稳定问题。我的经验是回传必须设计成“多优先级、可断点续传”的异步任务紧急场景数据用高优先级通道尽快传回常规数据在夜间或者车辆驻车有稳定网络时慢慢传。车端本地还要预留可靠的缓存空间防止网络不佳时数据丢失。还有一个不能被忽视的处理是脱敏。道路采集数据里经常包含行人脸部、车牌号有些还可能涉及小区内部环境等隐私信息。数据一旦落地云端合规风险是逃不掉的。我见过有团队在数据回传之后再做脱敏结果等发现人脸没遮干净大半批数据都要返工重处理浪费大量算力和人力。正确的做法是在车端完成检测、打码、模糊化之后再进入回传链路。车端脱敏会增加一些前向计算压力但这笔成本必须花。云端存储这块大多数人以为建一个对象存储桶就行了实际上制约数据使用效率的是“索引”和“目录”。没有元数据索引的数据湖就是数据沼泽。数据回传之后至少要自动建立以下维度的标签采集时间、天气、光照、道路类型、城市、场景事件类型、传感器配置版本、车辆型号、算法版本。这些字段会被后续的场景挖掘、训练集构建、仿真场景生成反复用到。到这一步数据链路才勉强算“通”了。我经常说数据平台建设最忌讳一步到位一开始不要想着把所有采集数据都完美组织起来先保证元数据从源头就规范后续补历史数据会痛苦得多。很多团队后面花几个月去清洗前期的脏数据根子就是当时没在采集端把元数据格式定好。2.3 数据挖掘与标注决定模型迭代的上限数据回传之后场景挖掘是接下来最关键的一环。别把所有数据都送去人工标注成本会立刻爆炸。比较靠谱的流程是先让云端用已上线的模型对海量回传数据做一轮“预识别”把模型表现不稳定的、置信度偏低的、预测结果和真值偏差大的样本自动捞出来再结合人工抽检确认。这个过程能快速产出高质量的难例数据集。难例数据的标注也需要工具和流程支撑。纯人工框框效率太低纯自动标注又容易带着模型自身的错误偏好。我的做法是先由自动标注模型给出预标注结果再由人员做校正同时标注平台上要有“质检抽检”和“多人一致性校验”机制避免个人标注风格影响标签质量。标注质量直接影响模型上限一个标签错位的训练集比没有这个数据更可怕因为它会让模型学到错误映射。这里还要强调一下数据版本管理。训练数据集是会持续演化的今天加了1000个夜间场景明天加了500个异形车场景如果对数据集没有版本概念模型训练完就说不清自己见过了哪些数据评测结果也没有办法溯源。建议把数据集像代码一样管理每次变更都有记录训练任务里记录数据集commit号这样模型、数据、代码三者之间才能做到可追溯。这个习惯越早建立越好团队到后期一定会感谢当初坚持做了这件事。3. 训练侧基础设施算力集群、分布式训练与评测体系3.1 训练集群的软硬配置怎么做才算及格训练侧是多数人理解中“AI Infra”的全部因为它最早被感知到。确实模型训练是最吃算力的环节车端感知、规控、座舱大模型的训练量都很大。但我的判断是训练集群建设硬件先放一边先把软件和流程想清楚。集群硬件层面无非是几件套GPU服务器、高速互联网络、共享存储。这三样缺哪样都白搭。很多人只盯着GPU卡的数量却忽略了高速网络和存储带宽结果就是卡一多分布式训练通信就变成了瓶颈几千张卡只能跑出几百张卡的效率。互联网络至少要做到计算节点间无损低延迟存储要能支撑大文件高吞吐读写和大量小文件的元数据访问。软件层面反而才是真正拉开差距的地方。一个合格的训练平台至少要有统一的资源调度、任务排队、镜像管理、日志采集、监控告警、分布式训练框架适配这些能力。不要一上来就搞很重的自助平台可以先用脚本加调度器把流程跑通再逐步完善。但有一件事必须一开始就做——统一GPU资源申请和配额管理。没有配额制度的集群最后一定会被少数几个“算力黑洞”任务占用其他团队排不上队。我在一个项目里还遇到过这种情况同一个训练任务跑在不同节点上结果出现微小差异导致模型指标不稳定。排查了很久才发现是有两台机器硬件驱动版本不一致。所以训练集群的镜像和驱动管理必须统一最好能做到环境可复现。这些都是看不见但特别磨人的坑。3.2 分布式训练的工程细节断点续训与数据管道当模型大到单卡放不下或者训练数据量大到单卡跑不完分布式训练就不可避免。在智能驾驶场景里感知大模型的训练数据动辄几百万帧模型参数量从几亿到上百亿不等多机多卡并行是常态。但分布式训练不是把训练框架参数一改就能稳定跑起来的真正花时间的往往是稳定性问题。我最看重的三个细节第一断点续训。一个训练任务跑三五天甚至几周中途断电、机器故障、显存溢出都可能导致任务中断。不接受断点续训的集群会让团队不敢跑大规模任务因为失败一次的成本太高。训练框架要周期性地保存checkpoint平台要有故障自动重启任务的机制哪怕最坏情况下多损失半小时的算力也比从头再来强。第二数据管道和计算的重叠。训练框架启动时如果数据加载跟不上GPU计算速度再强的算力也会在那干等。数据读取、预处理、增强这些最好都放在CPU侧并行流水线里做到“边读边训”。这个优化效果立竿见影往往比多申请几十张卡还实在。第三实验追踪。训练过程中的每个配置、每个超参数、每个数据版本都要能被记录和回溯。不然两个模型指标对比出来负责训练的同事却说“我不记得当时batch size用的多少”项目迭代立刻乱套。实验追踪系统是训练平台里投入产出比最高的一个组件。3.3 仿真与评测把“训练得好”变成“真能跑”模型在训练集上指标好不意味着在真实场景里表现好。所以训练侧的最后一步不是“模型收敛”而是“通过评测”。评测体系分三层递进第一层是离线数据集评测。固定一批不参与训练的高质量测试集包含各种场景类型每次模型迭代都要在同样条件下跑一遍保证指标曲线可比。这一层最容易做但只靠它远远不够。第二层是闭环仿真。自动驾驶的规控模型尤其需要这种评测。把感知识别结果放进仿真环境里让虚拟车辆在场景库中行驶观察它能否安全完成各种交通交互。场景库的构建本身也是AI Infra的一部分从真实路采数据中提取关键场景生成参数化变体再放到仿真环境里做闭环测试。第三层是实车路测。实车测试成本最高、周期最长但无法完全替代。一个好的AI Infra会把路测中发现的失败场景自动沉淀回场景库成为下一轮训练和评测的回归用例。我特别强调这个“回归闭环”因为它保证了问题被解决后不会复发。很多团队在评测环节最常犯的错误是把“离线评测指标涨了”当成“模型可以上车了”。实际上离线指标和真实体验之间有巨大的gap必须要靠仿真和实车评测两层来做缓冲。AI Infra做得好的标志不是说模型训练得有多快而是模型从训练完成到完成全部评测、确认可以上车这个过程越来越自动化、越来越短。4. 车端AI Infra模型上车不是把模型文件塞进芯片4.1 车端推理的软硬协同设计训练侧的模型通常跑在高精度GPU上但车端算力芯片资源有限、功耗敏感不可能直接拿训练时的模型格式去跑。这里就需要AI Infra里非常重要的一环——模型部署优化。车端推理首先要做模型转换把训练框架的模型格式转换到车端推理引擎支持的格式过程中要处理算子映射。然后是量化最常见的做法是把FP32模型转成FP16或者INT8精度会有轻微损失但推理速度大幅提升、内存占用减少。很多人以为量化是一个开关开了就行实际上量化后的模型在边界场景容易出现精度崩坏。稳妥的做法是准备一个覆盖关键场景的校准数据集量化后用这个数据集对比量化前后的输出差异发现异常就针对性做算子回退或者混合精度。车端推理引擎还要面对多传感器融合的调度问题。摄像头、激光雷达、毫米波雷达、超声波传感器都在以不同频率产生数据AI模型需要在一个严格的时间窗口内完成融合推理。如果推理任务的调度设计得不好传感器数据等待时间不一致模型输入的就是“错位”的数据推理结果自然不靠谱。还有一点是车端的资源隔离。在同一颗车规芯片上可能同时要跑自动驾驶感知、规控、座舱语音、驾驶员监控等多个AI任务。AI Infra必须提供任务级的算力分配和优先级管理紧急的安全相关推理要保证低延迟非紧急的座舱功能可以在资源空闲时再跑。底层操作系统、中间件、AI推理框架之间要配合好这绝对不是把网络模型文件打包丢进芯片就能完成的。4.2 安全机制下的冗余与降级车端AI和云端AI一个本质区别就是车端AI的错误会直接影响物理世界安全。所以AI Infra在车端必须考虑安全兜底机制。我不建议把系统全部押注在单个大模型上尤其是在涉及车辆控制的核心链路上。工程上常用“主导模型加降级策略”主模型失效时系统迅速切换到一个保守但可靠的规则模型保证车辆进入安全状态比如减速靠边停车。这种设计对基础设施提出的要求是主模型和降级模型必须在同一运行时环境里被管理切换逻辑要有严格的状态机而且切换动作本身要被埋点记录、回传云端分析。很多团队把降级策略写在应用代码里却没有统一的切换框架出了问题很难排查。车端推理还需要非常重视确定性。同一份模型、同一份输入车端推理引擎最好每次都给出相同输出否则测试和验证都无从谈起。为了提高确定性需要排除非必要的并行扰动、固定算子执行顺序、对浮点数累加顺序做约束。这里面的细节很多但都是车端AI Infra绕不开的硬功。安全认证和功能安全标准也是车端AI Infra的一部分虽然有些团队觉得这属于“合规工作”但它实际会影响整个技术架构。比如功能安全要求越高的模块越倾向于简单、可证明、可解释的算法这在AI模型设计早期就要考虑进去。等到模型都训练完了再补功能安全设计成本会非常高。4.3 车内通信与中间层为什么也算Infra很多人以为AI Infra只涉及“AI相关”的软硬件但我做过几个项目后发现车内通信链路和中间件才是车端AI运行质量的隐形命门。传感器数据从物理接口进入计算平台要经过一条完整的数据通路。如果中间某个环节的带宽设计不足或者某个通信模块出现偶发超时AI模型拿到的数据就会出现卡顿和丢帧。在实车调试中我遇到过一次“幽灵问题”推理模型在测试台上一切正常上车后发现偶发延迟。查到最后根因是车内一条总线的仲裁优先级配置不合理导致视频流被其他周期报文挤占。所以车端AI Infra团队必须懂“车”。除了推理引擎、量化、算子优化还要知道传感器接入、信号同步、总线通信、电源管理这些底层细节。一个合格的车端AI架构师通常要能看懂网络拓扑和通信矩阵知道不同信号的实时性要求。如果只懂云端那套部署方式到车端会非常被动。5. 面向整车生命周期的模型管理与OTA运营5.1 模型仓库与版本追踪当模型数量多起来之后最害怕的事情就是“不知道哪个版本在跑”。训练侧有几十个实验版本测试侧验证了十几个候选版本上线后又因为有badcase迭代了好几个版本如果没有系统性的模型仓库管理很快会陷入混乱。模型仓库不只是存模型文件还要存关联的元数据模型结构、训练数据版本、训练配置、测试集指标、仿真通过率、路测报告、量化参数、已知边界案例。我建议每个模型版本都生成一个全局唯一的版本号并且让这个版本号贯穿整个发布流程。从计划发布到最终OTA每一步都引用这个版本号形成完整的追溯链。模型仓库还有一个容易被忽略的作用线上问题回溯。车端反馈回来一个case说这个场景表现不好这时候模型管理平台能快速回答“线上跑的是哪个模型版本、训练数据是什么、评测报告怎么说”排查效率会大幅提升。没有这套能力问题定位基本靠猜。5.2 影子模式、灰度发布与回滚模型上车不是“一次切换”而是“渐进式放量”。这背后需要AI Infra提供一套完整的发布机制。第一步是影子模式。新模型先以影子身份在车辆上运行但它不参与实际控制只把推理结果和当前线上模型的推理结果做对比。这个阶段可以积累大量真实道路数据验证新模型在真实环境下的稳定性又不会因为模型错误带来安全风险。影子模式的比对结果要回传云端做统计分析和badcase挖掘。第二步是灰度发布。在影子模式验证通过后先让小批量车辆切换到新模型继续监控关键指标比如接管率、感知置信度、决策一致性。如果指标稳定再逐步扩大灰度范围。这个过程必须配合远程监控和告警一旦发现问题能立刻干预。第三步才是全量发布。但即使全量发布了也需要保留快速回滚的能力。OTA系统要支持差分升级和版本回退模型文件最好可以独立于业务程序升级这样回滚时不影响其他功能。很多团队一开始只做了“升上去”没做“退回来”后来被线上问题逼着补课非常被动。另外模型OTA升级方案要充分考虑下载失败、安装失败、断电等异常情况车端必须有可靠的恢复机制。车规级别的OTA可靠性设计比互联网App的版本更新要严格得多因为车上出问题会直接影响用户安全和品牌口碑。5.3 建立车辆侧的可观测性模型发布出去只是开始AI Infra的运营层还要回答一个问题模型在真实用户车辆上到底跑得怎么样。这个问题的答案依赖车辆侧的可观测性建设。车端AI运行时要持续上报轻量化指标推理耗时、CPU/GPU占用、内存占用、温度、模型输出置信度分布、识别异常次数、降级事件等。这些指标不是把所有原始数据都传回来而是在车端做聚合统计只传有价值的概要数据控制流量成本。一旦线上指标出现异常比如某个车型版本的推理耗时突然上涨或者某个天气条件下的感知置信度明显下降运营平台要能快速从“指标异常”定位到“车辆范围”、“软件版本”、“数据特征”。这些能力都需要提前设计好等到问题来了再补报表就来不及了。可观测性本质上是在为模型的下一次迭代提供输入它把线上运营和离线研发真正打通让“全域底座”形成了闭环。6. 算力与成本买卡、租卡还是混合调度6.1 算力需求估算的粗粒度公式做AI Infra绕不开预算而预算的核心是算力规模。经常有团队来找我第一句话就问“我们该买多少卡”。这个问题没有标准答案但我可以给一个非常实用的粗粒度估算思路。先算训练需求一次完整训练需要的总算力约等于模型参数浮点运算次数×训练tokens数×训练轮数/芯片总算力×GPU利用率。比如一个体量适中的自动驾驶感知模型训练集有500万帧数据跑20轮假设单卡每秒能处理一定数量的样本单卡训练一轮需要若干小时那20轮就要乘以20再留出实验和调参的倍率通常是3到5倍。还要考虑评测和仿真推理的算力需求。很多人只算训练算力忽略了评测和仿真也需要GPU。尤其闭环仿真跑起来瞬间算力需求甚至比训练还猛。仿真集群和训练集群可以在低峰期复用但资源规划时要统一考虑。最后要考虑峰值和平均值的差异。模型每天的训练任务不是匀速产生的发版前集中训练、数据增长导致的重新训练都会产生峰值需求。我的建议是核心基础算力自建或者长租峰值弹性用短期资源或者云端资源补齐不要按峰值采购硬件否则平时利用率会很难看。6.2 混合算力调度与利用率优化自有算力和云端算力各有千秋但管理混合算力是很多团队头疼的事情。我的经验是不要为了混合而混合关键是建立统一的调度入口。不管底层算力在哪里用户提交训练任务的体验应该是一致的平台层面再根据任务特点和资源价格把任务路由到最合适的算力池。调度策略上可以把训练任务按照优先级和可中断性分类。优先级高、不能中断的正式训练任务跑在稳定的自有集群上探索性实验、调参测试、数据预处理这类可中断任务可以调度到更便宜或者弹性的资源上随时会被抢占也不心疼。这种“混部抢占”的模式能明显提升整体算力利用率。利用率优化还有一个常见抓手是数据缓存。训练任务每次启动都要从存储系统读取大量数据如果不做缓存存储带宽会成为瓶颈。把高频使用的训练数据预加载到计算节点的本地缓存里能大幅减少任务启动开销让更多时间花在真正的计算上。我见过一个团队通过数据缓存和更合理的调度策略在不增加GPU的情况下把集群有效产出提高了百分之三四十。6.3 成本治理从分账开始AI算力成本治理的第一原则不是省钱而是“知道谁在花、花在哪、值不值”。没有分账机制的算力平台用不了几个月就会出现大量重复实验和浪费。每个团队、每个项目、每个任务组的算力消费都要被记录并且定期复盘。复盘的时候不能只看GPU卡占用小时数更要看“有效训练产出”。有的任务在集群上挂了一周实际checkpoint只出了两个版本有的任务一天跑完产出了十几次有效实验。算力成本要和模型指标提升挂钩这样才能判断投入的产出效率。我个人的原则是在算力成本上既不要抠门到影响迭代速度也不要漫无目的地囤卡。算力扩张永远跟着数据规模和模型规模走按需扩容、弹性伸缩。这里的平衡点需要持续调整但不管怎么调成本数据和实验数据都要透明这是AI Infra团队必须守住的一条底线。7. 落地AI Infra的几条实用经验7.1 先捞最痛的一条链路不要一开始就追求大而全我见过太多团队拿着“全域智能底座”的宏大规划第一版就上几十个模块结果半年过去了大部分功能处在“看起来有用不起来”的状态。这里我要给出一个非常反共识的建议AI Infra起步阶段千万别做全平台。正确的做法是先找一条对业务影响最大的链路把它打穿。比如团队现在最大的痛点是“数据不能高效变成训练集”那就先做数据采集、回传、脱敏、存储、索引、挖掘这条链路做到让算法同学每天都能拿到新鲜的高质量数据。只要这条链路通了模型的迭代速度立刻就有感知团队信心也会建立起来。第二条再打通训练评测链第三条再做车端部署和OTA。每一条链路都要做到“真的能用”而不是“功能存在但没人用”。AI Infra的价值永远体现在使用频率上一个只有PPT上好看、研发日常不用的平台再精细也没有意义。7.2 平台化是结果不是起点很多团队在建设过程中容易陷入“工具崇拜”总觉得买了某套开源系统或者商业工具AI Infra就自动建成了。但实际的智能汽车场景非常复杂不是装一个标准软件就能覆盖的。真正好用的基础设施一定是从解决具体问题出发逐步打磨出来的内部平台。我比较推荐“工具先行、平台后置”的路径初期让各团队用脚本、命令行、可执行工具把流程跑起来等流程稳定了再把这些工具封装成平台服务把最佳实践沉淀到系统里。这样做的好处是平台里的每一步都是被实践验证过的而不是架构师拍脑袋想出来的。平台化应该是过程的结果而不是从一开始就追求的一个壳。7.3 一点个人体会如果只让我总结一条最值得投入的AI Infra能力我会选“元数据治理”。从车端采集的第一秒开始到数据回传、标注、训练、评测、上车、运营所有环节都围绕元数据在协作。一个场景数据有没有清晰的场景标签直接决定它能不能被挖掘一个模型能不能追踪到训练数据和评测版本直接决定线上问题能不能高效定位。做了这么多年AI Infra我最大的感受是这个岗位不追求炫技追求的是把每一件“基础的事”做到极致。数据不丢、链路稳定、版本可控、成本清晰这些看起来都很朴素但在整车智能的长期竞争中恰恰是这些朴素的能力决定了AI定义汽车这件事到底是停留在口号里还是真正跑在路上。如果你现在正要开始搭建这套底座不要怕慢先把数据闭环走通后面每一步都会顺起来。
