全天候感知这件事过去几年在自动驾驶和机器人圈子里一直是个烧钱的命题。想让车在雨雾雪夜里照样看清世界常规思路无非两条要么堆更多传感器——加毫米波、加热成像、加更高线束的激光雷达要么堆更大算力——上更宽的骨干网络、更深的融合模块。结果就是硬件成本飙升、功耗爆炸、车规级芯片根本扛不住。AW-MoE 这个开源工作有意思的地方在于它把全天候这件事从堆资源转向了改结构用一套稀疏专家混合的思路在单张消费级显卡上把 3D 检测的全天候性能做上去了同时模型参数砍掉约 80%极端天气下的指标反而涨了 15% 左右。这篇我就从它到底解决了什么问题、MoE 在 3D 检测里怎么落地、为什么参数少了性能还能涨、以及实际复现时容易踩的坑几个角度把这件事拆开讲透。1. 全天候 3D 检测的真实痛点到底在哪1.1 传感器堆叠路线的边际收益正在快速衰减先说清楚背景。3D 检测的主流输入是 LiDAR 点云辅以摄像头和 Radar。LiDAR 在晴天表现极好测距准、点云密、几何信息干净。但一到雨雾雪问题就来了雨滴和雾滴会对激光产生后向散射形成大量虚假点雪片会遮挡真实目标路面湿滑导致反射率变化点云强度分布整体漂移。这时候你加一路 Radar确实能补上穿透性但 Radar 的分辨率低、角分辨率差融合时反而容易引入噪声。加热成像能解决夜间和部分恶劣天气但成本高、分辨率低、标定复杂。我自己的体会是传感器堆叠在早期确实有效每加一路都能带来几个点的提升。但到了某个临界点之后边际收益急剧下降——你加第四路、第五路传感器融合模块的复杂度指数上升标定误差、时间同步误差、数据对齐误差全都在放大最后提升可能只有零点几个点但成本和功耗翻倍。这就是为什么行业开始转向用更聪明的模型结构去榨取已有传感器的潜力。1.2 恶劣天气下模型失效的根因不是看不清而是学偏了很多人以为恶劣天气下检测变差是因为点云质量下降模型看不清。这个理解只对了一半。更深层的原因是常规检测网络在训练时晴天数据占绝对主导网络学到的特征表达是偏向晴天的分布。一旦输入分布偏移到雨雾雪网络的注意力机制、特征提取器全都用错了经验。打个比方这就像一个只在白天开过车的人突然让他夜里开山路。他不是眼睛不行而是大脑里没有对应的经验模式可以调用。AW-MoE 的核心洞察就在这里与其让一个庞大的稠密网络去同时学所有天气模式结果每种都学不精不如让多个专家分别擅长不同场景再通过一个路由机制动态选择。这就是 MoEMixture of Experts专家混合的思路。1.3 为什么是单卡这个约束条件特别关键标题里单卡搞定这四个字含金量比看起来高。车规级部署场景里算力和功耗是硬约束。你不能指望量产车装一张 A100。所以一个方案如果只能在多卡集群上跑通工程价值就大打折扣。AW-MoE 把参数量压到原来的 20% 左右意味着它能在单张中端显卡甚至边缘芯片上推理这才是它能被称为开源可用而不是论文好看的关键。提示评估任何感知模型时先看它的部署约束再看它的精度指标。一个在 8 卡上刷 SOTA 的模型和一个在单卡上做到 90% 性能的模型工程价值可能后者更高。2. MoE 塞进 3D 检测稀疏激活到底省了什么2.1 稠密网络 vs 稀疏专家一次算力账的对比要理解 AW-MoE 为什么能参数减少 80%得先搞清楚 MoE 的算力逻辑。常规稠密网络里每个输入 token在 3D 检测里可以理解为每个体素或每个点簇都要经过网络里所有的参数。参数量 计算量两者基本线性挂钩。MoE 的做法是把一个大 FFN前馈网络拆成 N 个专家每个专家是一个独立的小网络。每次前向传播时路由网络Router只挑选 Top-K 个专家参与计算其余专家不激活。这样一来总参数量N 个专家加起来可能很大但这是容量不是每次计算量。单次计算量只有被选中的 K 个专家参与实际 FLOPs 远小于稠密网络。举个具体数字。假设原来一个稠密 FFN 有 4096 维隐藏层参数量约 16M。现在拆成 8 个专家每个专家隐藏层 1024 维总参数约 8 × 4M 32M看起来更多了。但如果每次只激活 2 个专家单次计算量只有 2 × 4M 8M是原来的一半。这就是参数容量大、计算量小的稀疏特性。AW-MoE 在这个基础上做了针对 3D 检测的改造把专家数量、激活策略、路由方式都调到了适合点云任务的配置最终实现了参数量减少约 80% 的同时保持甚至提升性能。2.2 路由网络整个方案里最容易被忽视也最关键的部件MoE 能不能 work90% 取决于路由网络设计得好不好。路由网络的任务是给定一个输入特征判断它应该交给哪个专家处理。听起来简单实际坑很多。最常见的失败模式叫专家坍缩Expert Collapse路由网络偷懒把所有输入都分配给同一个专家其他专家永远不被激活等于白搭。另一个极端是负载不均少数专家被过度使用训练时这几路梯度爆炸其他专家欠拟合。AW-MoE 在路由设计上做了几件事来缓解这个问题。第一是引入负载均衡损失Load Balancing Loss强制让各个专家的激活频率接近均匀。第二是路由的输入不是原始点云而是经过骨干网络提取后的中间特征这样路由决策基于的是语义信息而非原始几何噪声在恶劣天气下更鲁棒。第三是 Top-K 的 K 值选择K 太小路由不稳定K 太大退化成稠密网络需要根据专家总数做权衡。2.3 为什么恶劣天气下 MoE 反而比稠密网络更强这是整个工作最反直觉也最精彩的地方。按理说恶劣天气数据少、噪声大模型应该更难学才对为什么 MoE 反而涨点我的理解是这样的恶劣天气下的点云其特征分布和晴天差异极大。稠密网络用同一套参数去拟合两种分布必然要做妥协结果两边都不讨好。而 MoE 的多个专家可以分工——一部分专家专门学晴天的干净几何特征另一部分专家专门学雨雾雪下的噪声模式。路由网络根据输入特征自动切换相当于给模型装了一个天气自适应开关。更妙的是这种分工是隐式学出来的不需要显式标注天气类型。你不需要告诉模型这是雨天路由网络自己会从特征里判断出来。这就避免了天气分类错误带来的级联误差。对比维度稠密网络AW-MoE 稀疏专家参数量大减少约 80%单次计算量与参数线性相关仅激活 Top-K 专家恶劣天气适应性需全局妥协专家分工自适应切换训练稳定性相对稳定需负载均衡约束部署门槛高单卡可跑3. 从点云到检测框AW-MoE 的完整数据流拆解3.1 骨干特征提取阶段做了什么取舍AW-MoE 的输入是 LiDAR 点云可能还融合了 Radar 或图像但核心是点云。骨干网络负责把原始点云转成体素或柱体特征再提取出高维语义特征。这一步和常规 3D 检测器比如 PointPillars、CenterPoint 那一类思路接近但 AW-MoE 在骨干设计上做了轻量化处理。为什么轻量化因为 MoE 的专家模块本身要占参数如果骨干还是重量级的总参数量压不下来。所以 AW-MoE 的骨干相对精简把表达能力的重担交给了后面的专家层。这个设计取舍很关键它假设点云的底层几何特征不需要太深的网络就能提取真正难的是高层语义和场景适应而后者正好交给 MoE。实际复现时如果你把骨干换成一个特别重的版本可能会发现 MoE 带来的收益被骨干的过拟合抵消了。这是我踩过的一个坑后面会细说。3.2 专家层的输入到底是什么粒度MoE 的专家处理粒度是个容易搞混的点。在 NLP 里MoE 通常作用在 token 级别每个 token 选专家。但在 3D 检测里token的定义不唯一可以是每个体素、每个柱体、每个 BEV 网格也可以是每个候选框的特征。AW-MoE 选择的是在 BEV 特征图或体素特征层面做专家路由。这个粒度比较合适因为太细比如每个点会导致路由计算量爆炸而且点级别的特征噪声大路由不稳定太粗比如整帧一个决策又失去了自适应性退化成整帧选一个专家表达能力受限。BEV 粒度还有个好处它天然对齐了检测头的输出空间专家学到的特征可以直接喂给检测头不需要额外的对齐模块。3.3 检测头与损失函数的配合细节专家层输出的特征最终要送进检测头输出类别、中心点、尺寸、朝向等。AW-MoE 的检测头本身没有太多花哨设计基本沿用主流的 anchor-free 或 center-based 范式。真正的功夫在损失函数上。除了常规的分类损失和回归损失AW-MoE 额外加了两个约束项一是前面提到的负载均衡损失二是路由一致性损失让相邻帧或相邻区域的路由决策保持一定平滑性避免抖动。这两个损失项的权重需要仔细调权重太大主任务学不好权重太小约束不起作用。论文里一般会给推荐值但实际数据分布不同还是得自己微调。注意负载均衡损失的权重是 MoE 训练里最敏感的超参之一。我建议从 0.01 开始试观察各专家的激活分布直方图如果某个专家激活率超过 60%就加大权重如果所有专家都接近均匀但主任务指标掉了就减小权重。4. 复现与调优那些文档里不会写的实操细节4.1 环境搭建与依赖版本的血泪教训AW-MoE 是开源项目但开源不等于开箱即用。3D 检测的依赖链特别长CUDA、PyTorch、稀疏卷积库如 spconv、点云处理库、检测框架如 mmdetection3d 或 OpenPCDet。版本不匹配是头号杀手。我的建议是先看项目 README 里有没有 requirements 或 environment.yml严格按它来。如果没有就按发布时间推断——比如项目是 2024 年中的那大概率对应 PyTorch 2.1~2.2、CUDA 11.8 或 12.1。spconv 的版本尤其要小心2.x 和 1.x 的 API 完全不兼容装错了直接 import 报错。还有一个隐蔽的坑稀疏卷积库对显卡架构有要求。如果你用的是比较新的显卡比如 40 系老版本的 spconv 可能没有对应的编译好的 wheel需要自己从源码编译编译过程又依赖特定版本的 CUDA toolkit 和编译器。这一步能卡掉不少人。4.2 数据准备恶劣天气样本的稀缺怎么破AW-MoE 的卖点是全天候但公开数据集里恶劣天气样本往往很少。nuScenes 有部分雨天和夜间但雪雾样本稀缺。这就带来一个现实问题你想复现它的恶劣天气提升但手头没有足够的数据。几个可行的思路。第一是用数据增强模拟恶劣天气给点云加噪声模拟雨雾散射随机丢弃点模拟遮挡调整强度分布模拟湿滑路面反射。这些增强虽然不完美但能让模型见到更多类恶劣分布。第二是跨数据集迁移用有恶劣天气标注的数据集如某些专门采集的数据集做微调。第三是利用 MoE 的特性——即使恶劣天气样本少只要路由网络能学到区分特征少量样本也能激活对应专家这比稠密网络对数据量的要求低。我实测下来第二种思路效果最稳但需要处理不同数据集的坐标系、标注格式、类别定义差异工作量不小。4.3 训练过程中的专家激活监控MoE 训练和普通网络训练最大的区别是你必须盯着专家激活情况。普通网络你只看 loss 和指标MoE 你还得看每个专家被用了多少次、路由熵是多少。具体做法在每个 epoch 结束后统计一批验证数据的路由决策画出专家激活频率的柱状图。理想情况下各专家激活率应该在一个合理区间内波动没有哪个专家长期为 0 或长期霸占。如果发现异常就要调整负载均衡损失权重或路由温度参数。路由温度temperature也是个关键参数。温度高路由分布更均匀但决策更模糊温度低决策更尖锐但容易坍缩。一般从 1.0 开始调配合退火策略逐步降低。4.4 推理阶段的加速与显存优化训练完了要部署MoE 的推理有个特殊问题虽然单次只激活 K 个专家但所有专家的参数都得加载到显存里。所以显存占用不一定比稠密网络低省的是计算量不是显存。如果你的部署场景显存紧张可以考虑几个优化一是专家参数用低精度存储FP16 或 INT8激活时再转精度二是把不常用的专家放到 CPU 内存需要时再加载但这会引入延迟三是根据实际数据分布裁剪掉长期不被激活的专家做一次专家剪枝。AW-MoE 号称单卡可跑但单卡的定义要看具体显卡。我建议至少 16GB 显存起步24GB 会更从容。如果只有 8GB可能需要大幅降低 batch size 或输入分辨率。5. 这套思路能迁移到哪些别的场景5.1 多传感器融合里的专家分工潜力AW-MoE 的核心思想——用稀疏专家处理不同分布——其实不限于天气。多传感器融合里LiDAR、Radar、Camera 各自的数据分布差异极大用稠密网络融合同样面临互相妥协的问题。完全可以设计一组专家分别擅长处理不同传感器的特征再用路由动态加权。这比简单的 concat 或 attention 融合可能更有效。5.2 不同路况、不同地域的域适应自动驾驶模型经常遇到域偏移问题在 A 城市训练的模型到 B 城市就掉点因为道路结构、交通参与者分布、光照条件都不同。MoE 的专家分工天然适合做域适应——不同专家学不同域的分布路由根据输入自动切换。这比传统的 fine-tune 或 domain adaptation 方法更灵活因为不需要预先知道有几个域。5.3 边缘部署场景下的算力弹性MoE 还有个被低估的优势算力弹性。你可以根据部署设备的算力动态调整激活的专家数量 K。算力强的设备 K 大一点精度高算力弱的设备 K 小一点速度优先。同一套模型权重适配不同档位的硬件这在车规级量产里非常有价值。6. 我对这类稀疏感知方案的一点个人判断折腾了一段时间 AW-MoE 这类方案之后我最大的感受是感知模型的竞争正在从谁的网络更大转向谁的结构更聪明。过去几年大家习惯了用参数量和 FLOPs 来衡量模型能力但到了车规部署这个环节这些数字的意义要打个折扣。真正重要的是单位算力下的有效性能以及在分布偏移下的鲁棒性。MoE 不是新概念NLP 领域早就玩烂了但把它搬到 3D 检测并针对点云特性做改造AW-MoE 算是走得比较扎实的一个。它的价值不在于刷了多高的 SOTA而在于证明了一条路不堆硬件、不堆算力靠结构设计也能把全天候感知做上去。当然它也不是银弹。路由训练的稳定性、专家负载的均衡、恶劣天气数据的稀缺这些都是实打实的工程难题。如果你打算在自己的项目里用这套思路我的建议是先把路由机制在小规模数据上跑通、把专家激活监控做起来再逐步放大。别一上来就上全量数据MoE 训练崩起来比稠密网络难调多了。最后分享一个我在调路由时的小技巧训练初期先把负载均衡损失权重设大一点让专家先分散开等激活分布稳定了再逐步降低权重让主任务损失主导。这个 warm-up 策略比固定权重稳定不少亲测有效。