自动驾驶算法做到后面，真正卡脖子的往往不是模型结构，而是数据。尤其当你同时要喂摄像头、激光雷达、毫米波雷达这几个完全不同的传感器时，数据稀缺和模态不一致会被放大成一个系统工程问题。OmniGen 这个名字听起来很高端，去掉包装其实就一句话：它想把自动驾驶场景下所有主传感器的数据生成统一到一个系统里，让你只用一份场景描述，就能同时拿到时间同步、空间对齐、语义一致的多模态传感器数据。这东西解决什么问题？传统做感知模型，要么拿真实路测数据，成本高、场景覆盖靠天吃饭；要么分别用不同工具生成图像和点云，再靠人工后处理去对齐时间戳和外参，稍微错个毫秒，训练出来的模型在实车上的表现就会打折。OmniGen 这类系统的核心诉求，是把“单模态生成能力”整合成“多模态联合生成能力”，让生成出来的图像、点云、雷达回波天然具备同一空间坐标系、同一时刻和一致的语义内容。不管你是做模型训练的数据扩充、长尾场景补全，还是做虚拟仿真里的传感器回放，它都能直接产生一个可用的完整数据包，而不是一堆还要你自己拼装的半成品。这段时间我断断续续搭过类似的数据生成管线，真动手之后才发现，所谓“统一”两个字比想象中难得多。传感器之间不是简单的一一对应关系，相机有视野裁剪和畸变，激光雷达有测距衰减和反射率差异，雷达有速度模糊和低角度杂波，任何一个环节不一致，后端感知模型的精度都会受影响。下面我会从系统设计、模态对齐、场景控制、训练部署和调试避坑几个维度拆开讲，尽量给你一条能在实际项目里落地的参考路径。1. 统一多模态生成到底要解决什么1.1 数据缺失不是“少几张图”的事，而是一个系统性问题先看一组很直观的数据。假设你要训练一个包含相机、激光雷达、毫米波雷达的融合感知模型，训练集往往需要几十万帧级别的样本。真实采集一帧带完整标注的数据，包含人工标注、时间同步校验、外参标定，成本差不多是纯图像的几倍。更麻烦的是覆盖度问题，置信度高、场景常规的数据占了绝大多数，真正能暴露系统死角的长尾场景——比如夜间逆光下的白色货车、雨天隧道口的积水反光、被遮挡的行人鬼探头——可能采集一个月都碰不上一回。就算你运气好，刚好采集到了这些场景，不同传感器之间的数据质量也参差不齐。夜间场景下摄像头成像噪声变大，激光雷达点云稀疏，毫米波雷达则容易在雨水衰减下出现错误目标。单一模态的数据增强解决不了这个矛盾，因为融合模型需要的是“每种模态同时变差，但变差的方式符合物理规律”的联合退化样本。OmniGen 这类统一系统要做的，就是把传感器噪声模型、物理遮挡关系和场景语义建模到一个生成框架里。1.2 多模态联合生成和单模态拼装有什么本质区别很多人会想：我分别用图像生成模型生成相机图片，再用点云生成模型生成激光雷达点云，最后按同一份标注文件把它们拼起来不就行了？实测下来你会发现三个绕不开的问题。首先是时间戳对齐，图像是 30 帧每秒曝光，激光雷达是一圈一圈扫描，毫米波雷达的更新频率又不一样，所谓“同一时刻”在不同传感器上天然定义不同。如果每个模态独立生成，物体位置微小的速度差异就可能造成时间的错位。其次是空间对齐，相机外参、激光雷达外参、雷达安装位置都会影响数据在空间上的覆盖范围。独立生成时，一个目标可能在图像里出现在车道右侧，在点云里却出现在对向车道。最后是语义一致性，图像里那辆红色卡车和点云里那堆有棱角的高反射率点，必须来自同一个目标实例，否则生成的数据在感知模型眼里就是矛盾信息，模型学到的根本不是“多模态融合”，而是“多模态吵架”。统一生成系统在架构上就把这些约束内嵌进去了。它不是在每个模态后面各接一个生成器，而是先建立一个共享的场景表示，再从这个表示里分叉出不同传感器的渲染结果。共享场景表示就像拍电影时的“剧本”，图像、点云、雷达都是不同机位对同一个剧本的拍摄结果，剧本一致，机位之间的差异只来自传感器本身的物理特性。2. OmniGen 的整体架构与设计逻辑2.1 “统一”具体指哪些层面的统一拆开看，OmniGen 的统一有三个层次。第一个是输入条件的统一。使用者不需要分别描述“图像应该有什么内容”和“点云应该有什么结构”，只需要给一份全局描述，比如一段文本、一张 High Definition 地图、一组目标框布局或者一个感兴趣区域。系统内部会把这份描述翻译成中间表示。第二个是输出表示的统一。系统不是输出某个单一模态，而是生成一个多模态数据包，通常包括时间同步的相机图像、激光雷达点云、毫米波雷达数据，以及对应的自车运动信息和标注文件。这个数据包直接对接后端训练管线的数据加载器。第三个是空间坐标的统一。所有输出统一在一个以自车为中心的坐标系统里，不同传感器只是从这个坐标系向外看世界的不同“视角”。点云的某个点、图像里的某个像素、雷达回波里的某个目标，都能回溯到同一个世界坐标，这是后面对齐和自动标注的基础。2.2 一个实用的系统结构会怎么组织如果让我画一个合理的系统结构，我会分成四块。最前面是条件编码器，负责把用户给的文本描述、3D 布局框、车道线或高清地图编码成稠密的条件特征。然后是共享场景表示层，它通常是一个鸟瞰视角下的 3D 体素坐标空间，或者一个以自车为中心的隐式神经场，把场景中目标的位置、尺寸、速度、外观特征全部装进去。再往下的多模态分支是不同的渲染器，当前主流做法是每个模态用一个扩散模型变体，图像分支生成 2D 像素图，激光雷达分支生成射线距离映射或者原始点坐标，雷达分支生成距离-速度-角度谱。最后还有一个对齐校验层，负责把各分支输出的结果映射回统一坐标系，检查遮挡关系是否一致、目标框是否匹配。这个分层设计的价值在于，你可以单独升级其中一个传感器分支的生成质量，而不影响其他分支。比如发现相机图像的纹理细节不够好，只需替换图像扩散模型，共享场景表示和其他分支完全不用动。2.3 和纯仿真器方案相比的优势与边界行业里成熟的仿真器方案也很优秀，它们基于物理渲染引擎，几何关系精确，但痛点在于场景资产的构建成本太高。一个写实风格的街景场景要把道路、建筑、植被、车辆模型全部手工雕刻，还要配置光照和材质，一套城市场景的资产制作周期按月计算。生成模型的优势在于不需要显式建模每一个物体，它从大量真实数据里隐式学到了“一条街应该长什么样”，生成一条新街道只需要几十秒。代价是可控性不如仿真器强。你很难精确要求“第三辆车是红色的已停靠在路边的货车”，生成系统更擅长的是“街道两侧停着几辆车，整体是阴天下午的光照”。做训练数据生成时，这种概率式的可控性基本够用，但如果要做需要逐帧精确控制的封闭测试，传统仿真器仍是更稳妥的选择。比较务实的思路，是把 OmniGen 生成的多样场景作为种子，喂给仿真器做后续细化。3. 核心技术拆解：每个模态怎么生成，怎么对齐3.1 相机图像生成：要画质，更要几何可控图像生成是相对成熟的环节，扩散模型已经能生成高真实感的城市街景。难点在于生成图像时要遵守场景布局。如果你给出一个目标框，框里是个人，图像生成模块就不能把这个人画成颜色和背景融为一体的鬼影，也不能把人凭空挪到半个车道外。工程上常用的约束方式是在扩散模型的采样过程中注入几何条件。比较基础的做法是控制条件编码，把目标框的鸟瞰坐标和类别标签喂进 UNet 的条件编码器；更进一步的做法是在生成的每个采样步里加入几何损失约束，每隔几个步长把当前去噪结果投影到鸟瞰视角，和参考目标框计算一次交并比损失，再反向修正隐空间。代价是采样时间变长，但换来的几何精度提升非常可观，特别是在车流密集的十字路口场景。光线和相机内参也需要建模。同一个场景，广角镜头和长焦镜头的生成结果差异很大，扩散模型需要在条件里包含焦距、畸变系数和分辨率。实际项目里我建议至少单独训练一组针对鱼眼镜头的分支，因为鱼眼畸变的边缘拉伸对几何约束模块的稳定性影响很大，共用同一套参数容易翻车。3.2 激光雷达点云生成：从“画得像”到“扫得出来”激光雷达点云的生成比图像更复杂，因为点云不是自然的 2D 网格数据，而是分布不均的 3D 点集。直接用一个 3D 生成模型建模点云，计算量太大，而且很难保证生成的点密度分布符合真实激光雷达的扫描规律。更常见的方法是先把点云转成距离图像，也就是球面投影。这个距离图像和普通图像一样拥有规则的网格结构，可以用 2D 扩散模型生成，再反投影回 3D 空间。这样操作的好处是天然继承了激光雷达球面扫描的几何特性，生成出来的点云不会出现“点跑到扫描盲区”之类的结构性错误。实际操作中要额外处理两个细节。第一是反射强度，不同的物体材质反射率差异很大，新鲜路面、金属车身、行人衣物在点云上的反射强度完全不同。生成距离图像时要把强度图作为第二个通道一起生成，而不是事后根据距离硬套一个公式。第二是遮挡边缘的处理，点云在物体轮廓边界处经常会出现穿透和空洞，如果生成的点云过于干净，感知模型反而学不到真实点云边缘的不规则性。我的做法是在训练时加入一个后处理扰动层，对边界附近的点做小幅度的位置抖动和密度随机衰减。3.3 毫米波雷达和其他模态：容易忽视，但融合模型很需要很多生成系统会把大部分精力花在图像和激光雷达上，毫米波雷达随意生成一下。但实际做融合感知后会发现，毫米波雷达在恶劣天气下的鲁棒性优势恰恰是图像和激光雷达都没有的。如果生成的雷达数据只是“点云的低配版”，融合模型训练出来在雷达上的特征提取能力会很弱。毫米波雷达的输出通常是稀疏目标点或者能量谱，每个点包含距离、方位角、径向速度和反射能量。生成时要注意速度与场景运动的一致性，比如一个横穿马路的行人，他的径向速度随时间变化要符合运动学规律。这事听着简单，但独立生成雷达点的后处理方案很容易把速度和时间关系搞坏。OmniGen 的做法是在共享场景表示里把每个目标的 3D 速度和轨迹显式建模，雷达分支从这个运动信息里计算径向速度，而不是自己再去生成一个速度值。另外，雷达的“多径反射”和“杂波”不好模拟。统一系统如果能在共享场景表示里加入建筑墙面、隧道护栏等强反射面的位置信息，雷达分支再基于这些信息生成一些虚假目标点，融合模型的抗干扰能力会有明显提升。3.4 跨模态一致性：外参标定、遮挡和流形对齐跨模态一致性是整个系统成败的关键。如果图像里的一辆车和点云里的一堆聚类点不是同一个位置，生成数据的价值会断崖式下跌。第一步是外参统一。所有传感器分支在生成前，都要通过统一的传感器标定参数把目标投影到自己的局部坐标系。这意味着生成条件里不仅要包含场景目标，还要包含传感器安装位置、安装角度和视场角。同一场景，你会希望它能够生成“前视相机看到的样子”和“左后视镜附近相机看到的样子”，这两个结果差异只来自外参差异。第二步是遮挡一致性。一个目标在图像里被另一辆车挡住了一部分，在点云里它也必然被同一辆车遮挡了一部分点。共享场景表示需要用射线检测算法统一计算遮挡关系，并把遮挡掩码作为条件传给各分支。如果不这样做，经常会看到图像里有 10 辆车，点云里却只有 5 辆车的完整点簇，另外 5 辆的点完全丢失，训练感知模型时会让模型学会忽略被遮挡目标。第三步是高层语义一致性。各模态分支虽然在训练时是解耦的，但在评价时要计算语义层面的相似度。简单做法是分别用一个预训练模型提取图像和点云的特征，然后计算同一个目标在两个模态特征空间的余弦相似度，定期抽检并调整梯度权重。实测下来这一步能有效防止某一模态生成质量下滑时，其他模态还在傻乎乎地配合它。3.5 时间维度上的连续性：别让小目标抖成“果冻”自动驾驶数据是序列数据，感知模型一般要吃连续帧。很多生成系统单帧效果惊艳，连成视频后小目标就疯狂抖动，车灯在一张图上完好无损，下一张图就开始重影。时间连续性可以在共享场景表示里显式建模。把一个目标的轨迹用一条三次样条曲线表示，各传感器分支在生成不同帧时，从样条上采样目标在那一帧的位置、朝向和速度。图像分支再配合光流信息约束相邻帧之间的像素位移。这样生成 2 秒、3 秒的短片段，连续性问题能压到一个可接受范围内。但这里要命的是计算开销。2 秒 60 帧的图像序列，如果用扩散模型逐帧生成，再强的 GPU 也拉不住。几种工程化的折中方案我都试过，比较好用的是关键帧生成加轻量级帧插值，也就是每 5 帧用完整扩散模型生成一次，中间帧用光流和时序 Transformer 补全。这样视觉质量会有一点下降，但整体吞吐率能提升好几倍。4. 场景控制与配套数据体系4.1 用户条件输入的几种方式OmniGen 的设计目标是让使用者能按需生成，条件输入的友好度决定了它能不能从技术 Demo 变成产线工具。文本输入最灵活，但最不可控。你可以输入“十字路口发生碰撞事故的场景”，系统会根据训练数据里学到的分布生成一个场景，但具体车辆朝向和位置是概率性的。工程师需要的是半可控，于是有了下面几种形式。BEV 语义分割图输入是控制力很强的方案。使用者画一张鸟瞰图，地面车道线、可行驶区域、障碍物轮廓用色块标出来，系统按图生成三维场景。实测下来这种条件输入方式的可控性是最好的，因为它本质上就是激光雷达和相机共同空间的语义压缩。目标框加轨迹输入则是与下游感知模型衔接最顺的方案。使用者定义若干目标 ID 及其随时间变化的轨迹，系统为每个目标分配外观、类型和运动状态。这种做法最接近自动驾驶数据集的原生标注格式，生成后可以直接导出标准标注文件。高清地图加路线输入适合做高速公路和城市快速路场景。系统从地图数据里读取车道拓扑和限速，自动生成符合交通流规则的车流。4.2 面向训练数据扩充的条件显控采样做一个生成系统，最容易踩的坑是生成来生成去都是训练数据里的主流场景。原因很简单，扩散模型本质上是在拟合训练数据分布，主流场景在分布里权重太高，哪怕你输入一个长尾条件，模型也会倾向于输出一个“看起来合理但不够特殊”的场景。解决办法是主动进行条件显控采样。在准备生成任务时，要对目标场景的关键属性做离散化，包括天气、光照方向、道路类型、障碍物类型、遮挡程度、目标密度等，然后用统计工具检查当前生成数据的属性分布，按目标分布逐项采样。想要 10% 的雨天场景，就该在生成请求里把雨天条件按对应采样率抽出，而不是随机生成之后再过滤。另外我的经验是，长尾场景的生成不要一次性把条件拉满。比如你要生成“暴雨夜间弯道被遮挡行人”，分开控制条件会比一次性输入更容易成功。先生成“夜间弯道”，再叠加“暴雨”，再添加“行人遮挡”，每一步条件变化幅度小，生成稳定性会明显好于一步到位，这会大幅减少废样本。4.3 自动标注的复用价值多模态统一生成系统还有一个隐藏价值，标注文件是自然产生的。既然系统在生成时已经知道了每个目标的位置、尺寸、类别和运动轨迹，它天然可以输出图像上的 2D 框、点云里的 3D 框、雷达目标列表和全景分割标签。不需要额外请标注团队，也不存在人工标注跨模态不一致的问题。利用这个特点，可以构建一个“老师模型”框架。先用 OmniGen 生成大量带标准标注的数据，训练一个基础感知模型；再用这个模型去真实路测数据上做预标注，人工只修正小部分错误。第二阶段的标注成本会显著下降。这种生成数据驱动标注的闭环，本质上是用合成数据降低真实数据的标注依赖。5. 训练策略和评估体系5.1 训练前要想清楚：生成器的输入输出到底是什么格式很多人开始搭这种系统时会卡在第一跳：不同模态的生成器用的是完全不同的架构，怎么一起训？比较推荐的路线是主训练阶段各模态分支独立训练，只在共享场景表示层做梯度交互。共享场景表示通过统一条件解码器和各分支连通，分支梯度在反馈到共享层时被加权合并。这样做能避免不同模态之间收敛速度差异过大导致一个分支带崩全局。数据格式上，图像分支输出像素 RGB 图，激光雷达分支输出球面距离图和强度图，雷达分支输出稀疏回波张量。把点云转成距离图再参与训练，能让各分支共享类似的数据结构，分布式训练时减少大量专门为 3D 数据准备的特殊算子。损失函数方面，图像分支用标准的扩散损失，激光雷达分支要额外加上点云几何感知损失，比如点到网格的倒角距离。雷达分支建议使用基于占用网格的损失，因为雷达数据是稀疏的，直接逐点回归容易被大量空白区域主导，导致雷达目标准确率不高。5.2 怎么判断生成数据“够好”建一个能服众的评估体系，这件事比训练模型本身还重要。如果你拿生成数据给感知团队，他们说“看起来有点假”，那是定性感觉，不算数。得把“假”拆成可以量化的维度。真实性和多样性是两个基础维度。真实性可以用预训练特征统计指标来评价，比如 ImageNet 特征统计距离，或者用下游感知模型作为判据，如果生成数据上的检测精度与真实数据接近，说明生成质量在信息层面足够。多样性则通过场景属性分布宽度来衡量，看目标类别分布、光照分布、天气分布是否符合预期覆盖。对齐质量是 OmniGen 这类统一系统独有的评价维度。计算方法是抽取多个模态，找到同一个目标在不同模态中的投影位置，比较它与基准位置的重投影误差。毫米级的误差说明外参统一做得好，几十像素的偏移就说明对齐失效了。另外还要检查时间一致性，计算相邻帧光流的平滑度，越高越好。最后是下游任务收益。这是最实际的一关，用真实数据训练一个基线模型，再用真实数据加生成数据训练一个模型，两者的精度差和学习曲线提升率就是生成数据的最终价值。很多生成系统在这个环节败下阵来，费了大量计算资源生成的数据对模型提升微乎其微，所以要能在闭环中检验。5.3 算力预算到底怎么规划统一多模态生成的算力消耗比想象中高。图像 2048x1024 分辨率、扩散模型单帧，单卡推理带宽很低；激光雷达球面距离图尺寸稍小，但时序注意力依然吃显存。跑一个小规模场景生成任务，单卡几乎不可能同时带起所有模态分支。我不建议一开始就追求同步生成端到端推理。实际路线是离线批量生成，分三个阶段：先基于文本和 BEV 布局生成共享场景表示，这个阶段消耗主要是 Transformer 解码；然后再对每个模态分支分别做扩散采样，顺序执行，把显存压力摊开；最后运行对齐校验。每个阶段单独部署、单独横向扩容。实时生成固然更酷，但对算力的要求完全不是同一个量级。在训练阶段，数据并行加多模态分支张量并行的组合通常最稳。共享场景表示层用模型并行，图像和激光雷达分支各自张量并行，两个分支不共用一批设备，避免互相抢占。实测下来比所有分支都在一个设备上训练更能稳定收敛。6. 常见问题排查与避坑实录先说结论，联合生成系统的大部分调试时间不是花在模型结构上，而是花在“各模态怎么对不齐”这个脏活累活上。6.1 检查单向可视性问题最常见的一个问题是图像分支生成了一张完整的街景，但激光雷达分支生成的点云里，某些目标却缺失或者只有寥寥几个点。排查时先想想是不是遮挡关系没有同步。共享场景里被遮挡目标本来就不该出现在当前传感器的数据里，但如果连未被遮挡的目标都掉了，更大的可能性是目标框位置本身飘了。我一般会固定一个随机种子，先用同一份场景表示分别生成相机和点云各十帧，然后手动在可视化工具里逐帧叠加查看目标位置。位置一致的占比如果低于九成，多半是场景表示里的目标属性预测与分支解码器之间存在分布偏移。6.2 动态目标闪烁和不同步问题如果单帧质量很好，但连续帧之间目标出现明显位移闪跳，问题通常出在时间建模上。先检查共享场景表示中目标的轨迹是否经过平滑，直接用一个带速度约束的卡尔曼滤波或样条拟合处理轨迹。再检查光流模块是否只用了图像输入，没有利用点云或者运动目标框交叉验证。时间一致性的修复要按从粗到精的顺序来，先保证完整轨迹没有断裂，再优化相邻帧微小的位置抖动。6.3 监控里常见的数值异常怎么处理训练时最容易出现的数值异常是损失突然发散，常见原因是雷达分支的稀疏张量将大面积的空白区域计算成负损失贡献，导致梯度爆炸。我的建议是把雷达分支损失设计为掩码加权损失，只对有效回波位置计算回归损失，对空白区域不计算或给予极小的权重。激光雷达分支偶尔也会出现距离图像里出现深度无穷大的点反投影成一堆失效 3D 点的情况，记得在反投影前做深度截断和球面坐标有效性校验。6.4 一套排查工具的搭建思路要维护一个生成系统，三套辅助工具必须提前备好。第一套是多模态可视化工具。支持同一帧的图像、点云球面图、雷达回波图在同一窗口叠加显示，并可以切换外参视角。调试对齐问题时，我会把图像里的目标框和点云投影下来的目标框同时画在图像上，寻找不一致区域，效率很高。第二套是场景属性统计面板。每次生成任务结束后，自动统计天气分布、目标类别分布、遮挡率分布，和请求时的目标分布做差分对比。第三套是下游模型网关。生成数据批量完成后，自动跑一次感知模型推理，输出检测精度。这个值的变化比任何生成指标都更直接地反映数据是否可用。7. 一些个人的深度思考这类统一生成系统，本质上是把自动驾驶的数据管线从“采集 + 标注”的重模式变成“生成 + 校验”的轻模式。但我不觉得它能在短期内完全替代真实数据。真实数据带来的传感器退化模式、场景分布里的微小物理细节，任何生成模型都还有差距。我更愿意把 OmniGen 放在数据管线的一个上游位置，不是终点，而是加速器。真实数据依然是稀缺资源，但生成数据让车企可以在稀有的真实数据上做精准补充，为真实路测中的罕见场景生成横向增强样本。往后看，这个系统的扩展方向大概是两个。一个是条件输入会越来越自然，从文本、标框逐步进化到直接输入自然语言意图加一段粗糙的参考视频，系统自动抽取其中的场景结构并重新变换视角。另一个是向端侧模型压缩方向发展，把统一场景表示蒸馏成一个小模型，部署在车载计算平台上，做实时场景推演和预测。这个方向一旦走通，自动驾驶系统就不只是“感知世界”，而是能够在运行过程中主动生成未来几秒的传感器预期数据，用来做异常检测和规划校验。回到实务，我的建议是，别急着追求一步到位。先把单模态生成质量做到可用，再逐步打通对齐层，最后再做统一输入。很多人一开始就陷入全模态联合训练的正确性泥潭，结果光一个图像和点云的对齐就废了三个月。沿着这条接近真实业务的路径走，OmniGen 这类系统才有机会真正从论文里的架构图变成日常研发流程里的常备工具。
自动驾驶算法做到后面，真正卡脖子的往往不是模型结构，而是数据。尤其当你同时要喂摄像头、激光雷达、毫米波雷达这几个完全不同的传感器时，数据稀缺和模态不一致会被放大成一个系统工程问题。OmniGen 这个名字听起来很高端，去掉包装其实就一句话：它想把自动驾驶场景下所有主传感器的数据生成统一到一个系统里，让你只用一份场景描述，就能同时拿到时间同步、空间对齐、语义一致的多模态传感器数据。这东西解决什么问题？传统做感知模型，要么拿真实路测数据，成本高、场景覆盖靠天吃饭；要么分别用不同工具生成图像和点云，再靠人工后处理去对齐时间戳和外参，稍微错个毫秒，训练出来的模型在实车上的表现就会打折。OmniGen 这类系统的核心诉求，是把“单模态生成能力”整合成“多模态联合生成能力”，让生成出来的图像、点云、雷达回波天然具备同一空间坐标系、同一时刻和一致的语义内容。不管你是做模型训练的数据扩充、长尾场景补全，还是做虚拟仿真里的传感器回放，它都能直接产生一个可用的完整数据包，而不是一堆还要你自己拼装的半成品。这段时间我断断续续搭过类似的数据生成管线，真动手之后才发现，所谓“统一”两个字比想象中难得多。传感器之间不是简单的一一对应关系，相机有视野裁剪和畸变，激光雷达有测距衰减和反射率差异，雷达有速度模糊和低角度杂波，任何一个环节不一致，后端感知模型的精度都会受影响。下面我会从系统设计、模态对齐、场景控制、训练部署和调试避坑几个维度拆开讲，尽量给你一条能在实际项目里落地的参考路径。1. 统一多模态生成到底要解决什么1.1 数据缺失不是“少几张图”的事，而是一个系统性问题先看一组很直观的数据。假设你要训练一个包含相机、激光雷达、毫米波雷达的融合感知模型，训练集往往需要几十万帧级别的样本。真实采集一帧带完整标注的数据，包含人工标注、时间同步校验、外参标定，成本差不多是纯图像的几倍。更麻烦的是覆盖度问题，置信度高、场景常规的数据占了绝大多数，真正能暴露系统死角的长尾场景——比如夜间逆光下的白色货车、雨天隧道口的积水反光、被遮挡的行人鬼探头——可能采集一个月都碰不上一回。就算你运气好，刚好采集到了这些场景，不同传感器之间的数据质量也参差不齐。夜间场景下摄像头成像噪声变大，激光雷达点云稀疏，毫米波雷达则容易在雨水衰减下出现错误目标。单一模态的数据增强解决不了这个矛盾，因为融合模型需要的是“每种模态同时变差，但变差的方式符合物理规律”的联合退化样本。OmniGen 这类统一系统要做的，就是把传感器噪声模型、物理遮挡关系和场景语义建模到一个生成框架里。1.2 多模态联合生成和单模态拼装有什么本质区别很多人会想：我分别用图像生成模型生成相机图片，再用点云生成模型生成激光雷达点云，最后按同一份标注文件把它们拼起来不就行了？实测下来你会发现三个绕不开的问题。首先是时间戳对齐，图像是 30 帧每秒曝光，激光雷达是一圈一圈扫描，毫米波雷达的更新频率又不一样，所谓“同一时刻”在不同传感器上天然定义不同。如果每个模态独立生成，物体位置微小的速度差异就可能造成时间的错位。其次是空间对齐，相机外参、激光雷达外参、雷达安装位置都会影响数据在空间上的覆盖范围。独立生成时，一个目标可能在图像里出现在车道右侧，在点云里却出现在对向车道。最后是语义一致性，图像里那辆红色卡车和点云里那堆有棱角的高反射率点，必须来自同一个目标实例，否则生成的数据在感知模型眼里就是矛盾信息，模型学到的根本不是“多模态融合”，而是“多模态吵架”。统一生成系统在架构上就把这些约束内嵌进去了。它不是在每个模态后面各接一个生成器，而是先建立一个共享的场景表示，再从这个表示里分叉出不同传感器的渲染结果。共享场景表示就像拍电影时的“剧本”，图像、点云、雷达都是不同机位对同一个剧本的拍摄结果，剧本一致，机位之间的差异只来自传感器本身的物理特性。2. OmniGen 的整体架构与设计逻辑2.1 “统一”具体指哪些层面的统一拆开看，OmniGen 的统一有三个层次。第一个是输入条件的统一。使用者不需要分别描述“图像应该有什么内容”和“点云应该有什么结构”，只需要给一份全局描述，比如一段文本、一张 High Definition 地图、一组目标框布局或者一个感兴趣区域。系统内部会把这份描述翻译成中间表示。第二个是输出表示的统一。系统不是输出某个单一模态，而是生成一个多模态数据包，通常包括时间同步的相机图像、激光雷达点云、毫米波雷达数据，以及对应的自车运动信息和标注文件。这个数据包直接对接后端训练管线的数据加载器。第三个是空间坐标的统一。所有输出统一在一个以自车为中心的坐标系统里，不同传感器只是从这个坐标系向外看世界的不同“视角”。点云的某个点、图像里的某个像素、雷达回波里的某个目标，都能回溯到同一个世界坐标，这是后面对齐和自动标注的基础。2.2 一个实用的系统结构会怎么组织如果让我画一个合理的系统结构，我会分成四块。最前面是条件编码器，负责把用户给的文本描述、3D 布局框、车道线或高清地图编码成稠密的条件特征。然后是共享场景表示层，它通常是一个鸟瞰视角下的 3D 体素坐标空间，或者一个以自车为中心的隐式神经场，把场景中目标的位置、尺寸、速度、外观特征全部装进去。再往下的多模态分支是不同的渲染器，当前主流做法是每个模态用一个扩散模型变体，图像分支生成 2D 像素图，激光雷达分支生成射线距离映射或者原始点坐标，雷达分支生成距离-速度-角度谱。最后还有一个对齐校验层，负责把各分支输出的结果映射回统一坐标系，检查遮挡关系是否一致、目标框是否匹配。这个分层设计的价值在于，你可以单独升级其中一个传感器分支的生成质量，而不影响其他分支。比如发现相机图像的纹理细节不够好，只需替换图像扩散模型，共享场景表示和其他分支完全不用动。2.3 和纯仿真器方案相比的优势与边界行业里成熟的仿真器方案也很优秀，它们基于物理渲染引擎，几何关系精确，但痛点在于场景资产的构建成本太高。一个写实风格的街景场景要把道路、建筑、植被、车辆模型全部手工雕刻，还要配置光照和材质，一套城市场景的资产制作周期按月计算。生成模型的优势在于不需要显式建模每一个物体，它从大量真实数据里隐式学到了“一条街应该长什么样”，生成一条新街道只需要几十秒。代价是可控性不如仿真器强。你很难精确要求“第三辆车是红色的已停靠在路边的货车”，生成系统更擅长的是“街道两侧停着几辆车，整体是阴天下午的光照”。做训练数据生成时，这种概率式的可控性基本够用，但如果要做需要逐帧精确控制的封闭测试，传统仿真器仍是更稳妥的选择。比较务实的思路，是把 OmniGen 生成的多样场景作为种子，喂给仿真器做后续细化。3. 核心技术拆解：每个模态怎么生成，怎么对齐3.1 相机图像生成：要画质，更要几何可控图像生成是相对成熟的环节，扩散模型已经能生成高真实感的城市街景。难点在于生成图像时要遵守场景布局。如果你给出一个目标框，框里是个人，图像生成模块就不能把这个人画成颜色和背景融为一体的鬼影，也不能把人凭空挪到半个车道外。工程上常用的约束方式是在扩散模型的采样过程中注入几何条件。比较基础的做法是控制条件编码，把目标框的鸟瞰坐标和类别标签喂进 UNet 的条件编码器；更进一步的做法是在生成的每个采样步里加入几何损失约束，每隔几个步长把当前去噪结果投影到鸟瞰视角，和参考目标框计算一次交并比损失，再反向修正隐空间。代价是采样时间变长，但换来的几何精度提升非常可观，特别是在车流密集的十字路口场景。光线和相机内参也需要建模。同一个场景，广角镜头和长焦镜头的生成结果差异很大，扩散模型需要在条件里包含焦距、畸变系数和分辨率。实际项目里我建议至少单独训练一组针对鱼眼镜头的分支，因为鱼眼畸变的边缘拉伸对几何约束模块的稳定性影响很大，共用同一套参数容易翻车。3.2 激光雷达点云生成：从“画得像”到“扫得出来”激光雷达点云的生成比图像更复杂，因为点云不是自然的 2D 网格数据，而是分布不均的 3D 点集。直接用一个 3D 生成模型建模点云，计算量太大，而且很难保证生成的点密度分布符合真实激光雷达的扫描规律。更常见的方法是先把点云转成距离图像，也就是球面投影。这个距离图像和普通图像一样拥有规则的网格结构，可以用 2D 扩散模型生成，再反投影回 3D 空间。这样操作的好处是天然继承了激光雷达球面扫描的几何特性，生成出来的点云不会出现“点跑到扫描盲区”之类的结构性错误。实际操作中要额外处理两个细节。第一是反射强度，不同的物体材质反射率差异很大，新鲜路面、金属车身、行人衣物在点云上的反射强度完全不同。生成距离图像时要把强度图作为第二个通道一起生成，而不是事后根据距离硬套一个公式。第二是遮挡边缘的处理，点云在物体轮廓边界处经常会出现穿透和空洞，如果生成的点云过于干净，感知模型反而学不到真实点云边缘的不规则性。我的做法是在训练时加入一个后处理扰动层，对边界附近的点做小幅度的位置抖动和密度随机衰减。3.3 毫米波雷达和其他模态：容易忽视，但融合模型很需要很多生成系统会把大部分精力花在图像和激光雷达上，毫米波雷达随意生成一下。但实际做融合感知后会发现，毫米波雷达在恶劣天气下的鲁棒性优势恰恰是图像和激光雷达都没有的。如果生成的雷达数据只是“点云的低配版”，融合模型训练出来在雷达上的特征提取能力会很弱。毫米波雷达的输出通常是稀疏目标点或者能量谱，每个点包含距离、方位角、径向速度和反射能量。生成时要注意速度与场景运动的一致性，比如一个横穿马路的行人，他的径向速度随时间变化要符合运动学规律。这事听着简单，但独立生成雷达点的后处理方案很容易把速度和时间关系搞坏。OmniGen 的做法是在共享场景表示里把每个目标的 3D 速度和轨迹显式建模，雷达分支从这个运动信息里计算径向速度，而不是自己再去生成一个速度值。另外，雷达的“多径反射”和“杂波”不好模拟。统一系统如果能在共享场景表示里加入建筑墙面、隧道护栏等强反射面的位置信息，雷达分支再基于这些信息生成一些虚假目标点，融合模型的抗干扰能力会有明显提升。3.4 跨模态一致性：外参标定、遮挡和流形对齐跨模态一致性是整个系统成败的关键。如果图像里的一辆车和点云里的一堆聚类点不是同一个位置，生成数据的价值会断崖式下跌。第一步是外参统一。所有传感器分支在生成前，都要通过统一的传感器标定参数把目标投影到自己的局部坐标系。这意味着生成条件里不仅要包含场景目标，还要包含传感器安装位置、安装角度和视场角。同一场景，你会希望它能够生成“前视相机看到的样子”和“左后视镜附近相机看到的样子”，这两个结果差异只来自外参差异。第二步是遮挡一致性。一个目标在图像里被另一辆车挡住了一部分，在点云里它也必然被同一辆车遮挡了一部分点。共享场景表示需要用射线检测算法统一计算遮挡关系，并把遮挡掩码作为条件传给各分支。如果不这样做，经常会看到图像里有 10 辆车，点云里却只有 5 辆车的完整点簇，另外 5 辆的点完全丢失，训练感知模型时会让模型学会忽略被遮挡目标。第三步是高层语义一致性。各模态分支虽然在训练时是解耦的，但在评价时要计算语义层面的相似度。简单做法是分别用一个预训练模型提取图像和点云的特征，然后计算同一个目标在两个模态特征空间的余弦相似度，定期抽检并调整梯度权重。实测下来这一步能有效防止某一模态生成质量下滑时，其他模态还在傻乎乎地配合它。3.5 时间维度上的连续性：别让小目标抖成“果冻”自动驾驶数据是序列数据，感知模型一般要吃连续帧。很多生成系统单帧效果惊艳，连成视频后小目标就疯狂抖动，车灯在一张图上完好无损，下一张图就开始重影。时间连续性可以在共享场景表示里显式建模。把一个目标的轨迹用一条三次样条曲线表示，各传感器分支在生成不同帧时，从样条上采样目标在那一帧的位置、朝向和速度。图像分支再配合光流信息约束相邻帧之间的像素位移。这样生成 2 秒、3 秒的短片段，连续性问题能压到一个可接受范围内。但这里要命的是计算开销。2 秒 60 帧的图像序列，如果用扩散模型逐帧生成，再强的 GPU 也拉不住。几种工程化的折中方案我都试过，比较好用的是关键帧生成加轻量级帧插值，也就是每 5 帧用完整扩散模型生成一次，中间帧用光流和时序 Transformer 补全。这样视觉质量会有一点下降，但整体吞吐率能提升好几倍。4. 场景控制与配套数据体系4.1 用户条件输入的几种方式OmniGen 的设计目标是让使用者能按需生成，条件输入的友好度决定了它能不能从技术 Demo 变成产线工具。文本输入最灵活，但最不可控。你可以输入“十字路口发生碰撞事故的场景”，系统会根据训练数据里学到的分布生成一个场景，但具体车辆朝向和位置是概率性的。工程师需要的是半可控，于是有了下面几种形式。BEV 语义分割图输入是控制力很强的方案。使用者画一张鸟瞰图，地面车道线、可行驶区域、障碍物轮廓用色块标出来，系统按图生成三维场景。实测下来这种条件输入方式的可控性是最好的，因为它本质上就是激光雷达和相机共同空间的语义压缩。目标框加轨迹输入则是与下游感知模型衔接最顺的方案。使用者定义若干目标 ID 及其随时间变化的轨迹，系统为每个目标分配外观、类型和运动状态。这种做法最接近自动驾驶数据集的原生标注格式，生成后可以直接导出标准标注文件。高清地图加路线输入适合做高速公路和城市快速路场景。系统从地图数据里读取车道拓扑和限速，自动生成符合交通流规则的车流。4.2 面向训练数据扩充的条件显控采样做一个生成系统，最容易踩的坑是生成来生成去都是训练数据里的主流场景。原因很简单，扩散模型本质上是在拟合训练数据分布，主流场景在分布里权重太高，哪怕你输入一个长尾条件，模型也会倾向于输出一个“看起来合理但不够特殊”的场景。解决办法是主动进行条件显控采样。在准备生成任务时，要对目标场景的关键属性做离散化，包括天气、光照方向、道路类型、障碍物类型、遮挡程度、目标密度等，然后用统计工具检查当前生成数据的属性分布，按目标分布逐项采样。想要 10% 的雨天场景，就该在生成请求里把雨天条件按对应采样率抽出，而不是随机生成之后再过滤。另外我的经验是，长尾场景的生成不要一次性把条件拉满。比如你要生成“暴雨夜间弯道被遮挡行人”，分开控制条件会比一次性输入更容易成功。先生成“夜间弯道”，再叠加“暴雨”，再添加“行人遮挡”，每一步条件变化幅度小，生成稳定性会明显好于一步到位，这会大幅减少废样本。4.3 自动标注的复用价值多模态统一生成系统还有一个隐藏价值，标注文件是自然产生的。既然系统在生成时已经知道了每个目标的位置、尺寸、类别和运动轨迹，它天然可以输出图像上的 2D 框、点云里的 3D 框、雷达目标列表和全景分割标签。不需要额外请标注团队，也不存在人工标注跨模态不一致的问题。利用这个特点，可以构建一个“老师模型”框架。先用 OmniGen 生成大量带标准标注的数据，训练一个基础感知模型；再用这个模型去真实路测数据上做预标注，人工只修正小部分错误。第二阶段的标注成本会显著下降。这种生成数据驱动标注的闭环，本质上是用合成数据降低真实数据的标注依赖。5. 训练策略和评估体系5.1 训练前要想清楚：生成器的输入输出到底是什么格式很多人开始搭这种系统时会卡在第一跳：不同模态的生成器用的是完全不同的架构，怎么一起训？比较推荐的路线是主训练阶段各模态分支独立训练，只在共享场景表示层做梯度交互。共享场景表示通过统一条件解码器和各分支连通，分支梯度在反馈到共享层时被加权合并。这样做能避免不同模态之间收敛速度差异过大导致一个分支带崩全局。数据格式上，图像分支输出像素 RGB 图，激光雷达分支输出球面距离图和强度图，雷达分支输出稀疏回波张量。把点云转成距离图再参与训练，能让各分支共享类似的数据结构，分布式训练时减少大量专门为 3D 数据准备的特殊算子。损失函数方面，图像分支用标准的扩散损失，激光雷达分支要额外加上点云几何感知损失，比如点到网格的倒角距离。雷达分支建议使用基于占用网格的损失，因为雷达数据是稀疏的，直接逐点回归容易被大量空白区域主导，导致雷达目标准确率不高。5.2 怎么判断生成数据“够好”建一个能服众的评估体系，这件事比训练模型本身还重要。如果你拿生成数据给感知团队，他们说“看起来有点假”，那是定性感觉，不算数。得把“假”拆成可以量化的维度。真实性和多样性是两个基础维度。真实性可以用预训练特征统计指标来评价，比如 ImageNet 特征统计距离，或者用下游感知模型作为判据，如果生成数据上的检测精度与真实数据接近，说明生成质量在信息层面足够。多样性则通过场景属性分布宽度来衡量，看目标类别分布、光照分布、天气分布是否符合预期覆盖。对齐质量是 OmniGen 这类统一系统独有的评价维度。计算方法是抽取多个模态，找到同一个目标在不同模态中的投影位置，比较它与基准位置的重投影误差。毫米级的误差说明外参统一做得好，几十像素的偏移就说明对齐失效了。另外还要检查时间一致性，计算相邻帧光流的平滑度，越高越好。最后是下游任务收益。这是最实际的一关，用真实数据训练一个基线模型，再用真实数据加生成数据训练一个模型，两者的精度差和学习曲线提升率就是生成数据的最终价值。很多生成系统在这个环节败下阵来，费了大量计算资源生成的数据对模型提升微乎其微，所以要能在闭环中检验。5.3 算力预算到底怎么规划统一多模态生成的算力消耗比想象中高。图像 2048x1024 分辨率、扩散模型单帧，单卡推理带宽很低；激光雷达球面距离图尺寸稍小，但时序注意力依然吃显存。跑一个小规模场景生成任务，单卡几乎不可能同时带起所有模态分支。我不建议一开始就追求同步生成端到端推理。实际路线是离线批量生成，分三个阶段：先基于文本和 BEV 布局生成共享场景表示，这个阶段消耗主要是 Transformer 解码；然后再对每个模态分支分别做扩散采样，顺序执行，把显存压力摊开；最后运行对齐校验。每个阶段单独部署、单独横向扩容。实时生成固然更酷，但对算力的要求完全不是同一个量级。在训练阶段，数据并行加多模态分支张量并行的组合通常最稳。共享场景表示层用模型并行，图像和激光雷达分支各自张量并行，两个分支不共用一批设备，避免互相抢占。实测下来比所有分支都在一个设备上训练更能稳定收敛。6. 常见问题排查与避坑实录先说结论，联合生成系统的大部分调试时间不是花在模型结构上，而是花在“各模态怎么对不齐”这个脏活累活上。6.1 检查单向可视性问题最常见的一个问题是图像分支生成了一张完整的街景，但激光雷达分支生成的点云里，某些目标却缺失或者只有寥寥几个点。排查时先想想是不是遮挡关系没有同步。共享场景里被遮挡目标本来就不该出现在当前传感器的数据里，但如果连未被遮挡的目标都掉了，更大的可能性是目标框位置本身飘了。我一般会固定一个随机种子，先用同一份场景表示分别生成相机和点云各十帧，然后手动在可视化工具里逐帧叠加查看目标位置。位置一致的占比如果低于九成，多半是场景表示里的目标属性预测与分支解码器之间存在分布偏移。6.2 动态目标闪烁和不同步问题如果单帧质量很好，但连续帧之间目标出现明显位移闪跳，问题通常出在时间建模上。先检查共享场景表示中目标的轨迹是否经过平滑，直接用一个带速度约束的卡尔曼滤波或样条拟合处理轨迹。再检查光流模块是否只用了图像输入，没有利用点云或者运动目标框交叉验证。时间一致性的修复要按从粗到精的顺序来，先保证完整轨迹没有断裂，再优化相邻帧微小的位置抖动。6.3 监控里常见的数值异常怎么处理训练时最容易出现的数值异常是损失突然发散，常见原因是雷达分支的稀疏张量将大面积的空白区域计算成负损失贡献，导致梯度爆炸。我的建议是把雷达分支损失设计为掩码加权损失，只对有效回波位置计算回归损失，对空白区域不计算或给予极小的权重。激光雷达分支偶尔也会出现距离图像里出现深度无穷大的点反投影成一堆失效 3D 点的情况，记得在反投影前做深度截断和球面坐标有效性校验。6.4 一套排查工具的搭建思路要维护一个生成系统，三套辅助工具必须提前备好。第一套是多模态可视化工具。支持同一帧的图像、点云球面图、雷达回波图在同一窗口叠加显示，并可以切换外参视角。调试对齐问题时，我会把图像里的目标框和点云投影下来的目标框同时画在图像上，寻找不一致区域，效率很高。第二套是场景属性统计面板。每次生成任务结束后，自动统计天气分布、目标类别分布、遮挡率分布，和请求时的目标分布做差分对比。第三套是下游模型网关。生成数据批量完成后，自动跑一次感知模型推理，输出检测精度。这个值的变化比任何生成指标都更直接地反映数据是否可用。7. 一些个人的深度思考这类统一生成系统，本质上是把自动驾驶的数据管线从“采集 + 标注”的重模式变成“生成 + 校验”的轻模式。但我不觉得它能在短期内完全替代真实数据。真实数据带来的传感器退化模式、场景分布里的微小物理细节，任何生成模型都还有差距。我更愿意把 OmniGen 放在数据管线的一个上游位置，不是终点，而是加速器。真实数据依然是稀缺资源，但生成数据让车企可以在稀有的真实数据上做精准补充，为真实路测中的罕见场景生成横向增强样本。往后看，这个系统的扩展方向大概是两个。一个是条件输入会越来越自然，从文本、标框逐步进化到直接输入自然语言意图加一段粗糙的参考视频，系统自动抽取其中的场景结构并重新变换视角。另一个是向端侧模型压缩方向发展，把统一场景表示蒸馏成一个小模型，部署在车载计算平台上，做实时场景推演和预测。这个方向一旦走通，自动驾驶系统就不只是“感知世界”，而是能够在运行过程中主动生成未来几秒的传感器预期数据，用来做异常检测和规划校验。回到实务，我的建议是，别急着追求一步到位。先把单模态生成质量做到可用，再逐步打通对齐层，最后再做统一输入。很多人一开始就陷入全模态联合训练的正确性泥潭，结果光一个图像和点云的对齐就废了三个月。沿着这条接近真实业务的路径走，OmniGen 这类系统才有机会真正从论文里的架构图变成日常研发流程里的常备工具。