一、一个尴尬的事实：99% 的算力花在了最简单的路况上
一辆车一天的行驶里程里，大约九成时间在干什么？高速巡航跟车、直路保持车道、等红灯。这些场景对模型来说是"送分题"——前车轨迹平稳，车道线清晰，一个小网络绰绰有余。真正要命的是剩下那一成：雨夜里从违停车之间探出来的行人、施工区里锥桶围出的临时车道、路口无保护左转时和对向车的博弈。这些场景才需要大模型的深度推理。但前两篇讲的架构有一个共同的尴尬：不管场景多简单，模型的每一个参数都要参与计算。空旷高速上跟车，和暴雨天施工区绕行，跑的是同一个网络、同样的计算量、同样的延迟。这就像医院规定：不管你是来开感冒药还是做开颅手术，全院三百名医生必须集体会诊。结果就是一个死结：想覆盖复杂场景，模型就得大；模型一大，车端芯片的算力和延迟预算就爆；为了上车又只能砍小模型，复杂场景又罩不住。能力和算力，在 Dense（稠密）架构里是一根绳上的蚂蚱。MoE（Mixture of Experts，专家混合模型）要剪断的，就是这根绳。它也是理解 UniDriveVLA 里 MoT 架构的必经之路——这一篇我们先把 MoE 拆透。
二、先讲直觉：把"全科医生"换成"分诊台 + 专科团队"
MoE 的思想用一句话就能说完：模型可以很大，但每次只用其中一小部分。回到医院的类比。Dense 模型是一个全科巨无霸医生，什么病都找他，他脑子里装着所有科室的知识，每看一个病人都要把全部知识过一遍。MoE 医院则不同：进门先到分诊台（Router，路由器），分诊台看一眼你的症状，把你分给两三个相关的专科医生（Expert，专家）——感冒去呼吸科，骨折去骨科。全院三百名医生的知识都在，但你这次就诊只占用了其中两三个人的时间。落到模型结构上：Transformer 的每一层里有个前馈网络（FFN），它占了大部分参数量。MoE 做的手术就是——把这一个大 FFN 复制成 N 份并联的小 FFN（N 个 expert），前面加一个轻量的 router。每个 token 流到这一层时，router 给它打分，选出得分最高的 k 个 expert（这就是Top-k routing，通常 k=1 或 2），token 只进这 k 个专家，其他专家这次完全不算，输出按 router 给的权重加权合并。于是出现了一个关键的解耦：总参数量（模型的知识容量）和单次激活参数量（每帧的计算开销）不再相等。一个总参数 100 亿的 MoE 模型，每个 token 可能只激活 15 亿参数——知识库是巨无霸，账单是小网络。这对自动驾驶意味着什么，不用我多说：车端芯片按"激活参数"付费，而长尾场景按"总参数"受益。
三、再拆结构：Router 是怎么"分诊"的，Expert 是怎么"成专家"的
新手看完上一节就够了，这一节给工程师，我们把两个核心组件拆开。Router：一个学出来的分诊台
Router 本身简单得出奇——通常就是一个线性层：token 的 embedding 进来，输出 N 个分数（每个 expert 一个），softmax 归一化后取 Top-k。真正的深水区在于：这个分诊逻辑不是人写的，是训练出来的。没有人告诉 router"雨夜的 token 归 3 号专家管"。训练开始时分数接近随机，token 被胡乱分配；随着训练推进，某个 expert 碰巧在某类 token 上表现稍好，router 就倾向于把同类 token 继续送给它，这个 expert 于是在这类数据上练得更精——正反馈滚起来，分工自发涌现。这和第二篇讲的 attention 权重一样：不是规则，是从数据里长出来的秩序。但自发秩序有个著名的失败模式：赢家通吃。训练早期哪个 expert 先冒头，router 就把所有 token 都塞给它，其他 expert 饿死，MoE 退化成 Dense。所以所有 MoE 训练都要加负载均衡损失（load balancing loss）——强制 token 在专家之间分布得别太离谱。这是个微妙的对抗：均衡拉得太狠,分工就被抹平（人人都是全科，白搭了架构）；拉得太松，专家又会饿死。这个度，是 MoE 训练的第一手艺。Expert：分工往往不按人类的剧本走
一个反直觉的事实：expert 学出来的分工，经常不是人类想象的那种分工。你以为会出现"雨天专家""高速专家"，实际观察 routing 模式，更常见的是按 token 的底层特性分——有的 expert 专管边缘纹理密集的 token，有的专管运动模糊的 token，有的专管语义边界。分工的粒度是 token 级的，不是场景级的。这恰恰是它的强大之处。举个例子：大车/挂车的非刚体运动。一辆铰接卡车占据几十个 BEV token，车头部分的 token 运动模式规整，可能被路由给"刚体运动"倾向的 expert；挂厢摆动部分的 token 运动特征完全不同，被路由给另一个 expert。同一个目标的不同部位走不同专家——这是任何人工模块划分都做不到的细粒度分工。再看雷达速度与视觉速度冲突：融合层的 MoE 里，多径鬼速度污染的 token 和干净 token 的特征分布不同，router 可以学会把"可疑速度"的 token 送去更擅长冲突仲裁的 expert。人工规则写的是"if 冲突 then 信视觉"，MoE 学的是一整套按特征分布的柔性分流。
四、自动驾驶为什么天生适合 MoE：三个结构性理由
理由一：驾驶场景的难度分布是极端长尾的。这是核心。90% 的里程是送分题，9% 需要认真做，1% 是决定安全上限的压轴题。Dense 模型对所有题目付出同样算力，等于把绝大部分预算花在送分题上。MoE 的条件计算（conditional computation）刚好匹配这个分布：简单 token 走小路，困难 token 走大路。空旷高速上，大部分 BEV token 是路面和天空，浅浅走过；而两轮车突然横穿时，那一小片区域的 token 被路由到重型专家做深度加工——算力跟着难度走，而不是均摊。理由二：驾驶任务本身就是异构的。同一个统一模型里，检测要几何精度，速度估计要时序敏感，预测要博弈推理，规划要权衡舒适与安全。第一篇讲过，端到端把这些任务缝进了一个网络，但缝合不等于兼容——多任务在共享参数上互相拉扯（检测涨了规划崩的跷跷板，第二篇也提过）。MoE 提供了一个缓冲带：共享 attention 让任务互通信息，分开的 expert 让任务各留一块自己的参数自留地，拉扯自然减轻。理由三：长尾数据的"稀释问题"。数据闭环挖回来的 hard case——比如几百段低速起步目标（路边车辆亮转向灯、车轮微动即将汇入）——混进上亿帧的常规数据里重训 Dense 模型，就像往游泳池里倒一杯盐：浓度太低，模型学了跟没学一样；加大采样权重，又可能损伤常规场景的表现。MoE 里这个矛盾缓和得多：这类 token 会被 router 集中送往少数几个 expert，hard case 的监督信号集中打在专属参数上，既学得进去，又不打扰别的专家。数据引擎的飞轮和 MoE 的分工机制，是天然的搭档。
五、专家团队可以安插在链路的哪里
顺着前两篇建立的数据流（image token → BEV token → object/track query → 预测 → 规划），MoE 可以逐站安插：感知专家。BEV 编码层用 MoE：近处高密度信息的 token 和远处稀疏模糊的 token（第二篇讲过 BEV token 的表达密度不均）走不同 expert，远距离小目标不再被近处的"多数派"淹没。多传感器融合层用 MoE：相机主导的 token、雷达主导的 token、冲突 token 各有归属。
跟踪与运动专家。track query 的更新网络里，规则运动的目标（匀速跟车）和不规则运动的目标（急变道、非刚体挂车）由不同 expert 处理，遮挡后目标重现时的重关联这种"疑难杂症"也可以路由给专门的时序推理专家，缓解一个网络既要稳又要灵的矛盾。
预测专家。多模态轨迹天然适合专家结构：直行意图、转弯意图、激进博弈、保守让行，不同 expert 生成不同模态的轨迹假设。无保护左转里对向车"70% 右转、30% 直行"的两条轨迹，背后可以是两个专家各自的输出——比一个网络硬吐多条轨迹的模式坍塌问题（所有轨迹挤成一条）要健壮。
规划专家。planner 的保守性和效率权衡，本质是不同驾驶风格的冲突：接送孩子的场景要保守，高速汇流犹豫反而危险。用 expert 承载不同风格倾向，由 router 根据场景 embedding 调配权重，比用一个标量参数调"激进度"表达力强得多。
数据闭环。这一站最容易被忽略，但价值极大：routing 记录本身就是免费的场景分类器。哪些帧激活了"疑难专家"，哪些 token 的路由熵特别高（router 拿不准该分给谁），就是现成的 hard case mining 信号——router 不确定的地方，正是数据缺口所在。云端的自动标注大模型也可以用 MoE 扩容，用更大的总参数换更高的真值质量，反正离线不心疼延迟。
六、工程账本：MoE 上车，钱花在哪、省在哪
省的是算力，不省显存。这是上车前必须想清楚的第一件事。Top-2 routing 让计算量只有同容量 Dense 的几分之一，但全部 expert 的参数都要装进内存——router 是逐 token 实时决策的，你不知道下一个 token 要哪个专家，所以谁都不能卸载。车端本来就紧张的 memory 预算（第二篇讲过 KV cache 已经是大户），现在还要为"大部分时间在睡觉的专家"付房租。缓解手段有：expert 参数量化压缩、跨层共享 expert、把冷门 expert 放次级存储做预取——每一条都是精度、延迟、复杂度的三方谈判。延迟从"确定"变成"分布"。Dense 模型每帧计算量恒定，延迟可预期，这对实时系统是宝贵的性质。MoE 的每帧延迟取决于 token 被路由去了哪——最坏情况下大量 token 挤进同一个重型专家，出现"专家排队"，尾延迟（P99）显著恶化。高速 cut-in这种毫秒必争的场景，平均延迟达标但 P99 超标，就是安全问题。量产方案通常要给 routing 加容量上限（capacity factor）：专家满员后溢出的 token 降级处理——但"谁被降级"又成了新的安全评审议题。评测复杂度翻倍。Dense 模型测一个就是一个。MoE 要额外回答：routing 稳定吗？换一个软件版本，同一段路的 routing 模式会不会漂移？某个 expert 更新后，只走它的那类场景会不会退化？评测体系必须加一层"按 routing 切片"的维度——这是 Dense 时代不存在的工种。什么地方别贸然用。几何精度主导、算力本就吃紧的窄任务——比如泊车场景 5 厘米级近距离避障——一个专用小网络又快又稳，硬上 MoE 是给自己找麻烦。MoE 的甜蜜区在于：任务分布宽、长尾重、模型容量确实不够用的地方，典型就是统一大模型的中后段（融合、预测、规划、语义理解）。
七、坑：分诊台本身会生病
坑一：routing 抖动。同一辆车、连续两帧、几乎相同的画面，token 的 router 分数在两个 expert 之间来回横跳，输出跟着轻微跳变。感知输出抖一点，下游预测放大一点，规划再放大一点——第一篇讲的误差级联在 MoE 时代有了新变种：分工不稳定导致的级联抖动。工程上要给 routing 加时序平滑或滞回逻辑（这一帧走了 3 号专家，下一帧分数接近时倾向继续走 3 号），但平滑太强又会拖慢对场景突变的响应。坑二：专家饿死与知识遗忘。极端长尾的 expert（比如逐渐专精"雨夜行人"的那个）在常规数据主导的持续训练里份额越来越小，负载均衡损失甚至会主动把它的 token 抢走分给别人——最需要保护的专家，恰恰是均衡机制最想消灭的对象。需要在数据配比和均衡策略上单独开小灶，这是数据引擎和训练框架的联合工程。坑三：训练比 Dense 更玄学。Top-k 选择是不连续操作，梯度只流向被选中的 expert，没被选中的这一步啥也学不到；加上均衡损失和主任务损失的拉扯，MoE 的训练曲线比 Dense 更容易出现 loss spike。多模态输入（第二篇讲的四类 token 分布差异）会进一步放大这个问题。坑四：可解释性的两面性。routing 模式给了你一个观察模型分工的窗口（这比 Dense 强），但当事故归因时，"这个 token 当时被分给了 5 号专家"并不能回答"为什么 5 号专家算错了"。分诊记录能定位科室，定位不了误诊原因。
八、总结：从"一个大脑"到"一个大脑里的分工"
MoE 的本质是把"知识容量"和"单次算力"解耦：总参数决定你能装下多少长尾，激活参数决定你每帧付多少钱——这恰好命中自动驾驶"场景极端长尾、车端算力恒定"的死结。Router 的分工是涌现的，不是设计的：它按 token 特征分流而非按人类的场景标签分流，这既是它超越人工模块划分的地方，也是 routing 抖动、专家饿死等新问题的根源。MoE 省算力不省显存，换来的是延迟从确定值变成分布：上车的关键不是"能不能跑"，而是尾延迟、routing 稳定性和切片评测这三笔新账能不能算平。Dense 模型相信"一个足够大的脑子能搞定一切"，MoE 承认"再大的脑子也得学会分工"——自动驾驶需要的不是更大的大脑，而是一个会自己排班的专家团队。
到这里，铺垫完成了：我们有了统一的 token 空间（第二篇），有了按需分工的专家机制（本篇）。但 MoE 的 router 分流时基本不管 token 是视觉、地图、轨迹还是语言——如果按模态来组织专家分工呢？这就是 UniDriveVLA 采用的 MoT（Mixture of Transformers）：下一篇，我们拆这个"给每种模态配一套专属参数"的架构，看它如何解决多模态互相干扰这个老大难。
