企业官网建设流程全解析

1. 项目概述与设计动机

1.1 实时目标检测的痛点

实时目标检测这几年一直是工程落地的硬骨头。一提到“实时”，大家想到的往往是帧率、算力、延迟这几个字，可真做起来就会发现，问题远不止把模型跑快这么简单。YOLO系列之所以能一直占据主流地位，靠的是把“单阶段检测”这条路线做到了极致——网络结构整体简洁、推理路径短、部署方案成熟，所以很多实时场景里它都是首选。但YOLO类模型也有一个绕不开的软肋：在高密度小目标、遮挡严重、形态多变这类复杂场景下，用标准卷积堆出来的主干网络很难同时兼顾特征表达的丰富性和计算效率。换句话说，想让模型快，它就在复杂场景下“看”不准；想让模型准，参数量和计算量又立刻涨上来。这正是很多开发者实际跑业务时最头疼的地方。

YOLO-Master这个项目，本质上就是针对这个问题做的一次完整尝试。它把混合专家模型（Mixture-of-Experts，MoE）的思路和专用变换器（Transformer）结构引入到传统单阶段检测框架里，目标只有两个：一是用MoE的门控路由机制把计算量花在真正需要的地方，二是用变换器模块补上卷积网络在全局上下文建模上的短板。听起来有点绕，但拆开看其实是一条很清晰的技术路线：先用MoE做“选择性算力分配”，再用Transformer做“关键特征放大”，两条腿走路，最终在保证实时性的前提下把检测精度抬上一个台阶。

1.2 从实际场景倒推设计需求

在这个项目启动之前，我整理过一批实际业务里比较有代表性的检测需求，覆盖了交通路况、工业质检、仓储监控几个方向。这些场景有一个共同特点：目标数量多、尺度差异大、对误检和漏检的容忍度低，同时还对单帧推理时间有硬性要求。举个最直观的例子，一个中等分辨率的监控画面里可能出现几十甚至上百个目标，其中有不到二十像素的小目标，也有占据画面四分之一的大目标，如果只用常规的多尺度特征结构，小目标分支往往需要非常深的骨干网络才能提出来足够的语义信息，而深网络带来的延迟又会让整个系统不满足实时要求。

所以在设计YOLO-Master的时候，我没有走“盲目加深加宽”的老路，而是把需求拆成了几个可以量化的目标：在公开检测数据集上，整体精度要比同等速度的传统单阶段模型高三到五个点；在低计算能力的边缘设备上，单帧延迟要控制在实时可用的范围内；在密集小目标场景下，召回率要比基线模型提高至少两个点。这几个指标看起来很朴素，但要把它们同时做到，就需要在架构设计上做一些“聪明”的取舍，而不是一味堆模块。这也是为什么最终方案里既有MoE又有Transformer：它们各自解决不同维度的问题，缺一个都会让整个系统的均衡性破功。

2. 整体架构设计与关键决策

2.1 设计目标与指标体系

开始动手之前，我习惯先把“什么是好”定义清楚，否则后续所有参数调整都会变成直觉猜谜。针对YOLO-Master，我定了四个维度来衡量一个改动是否值得落地。

首先是精度维度，用通用检测评估指标来度量，重点关注在不同交并比阈值下的表现。这个指标能直观反映模型的定位和分类综合能力，也是业务方最认可的“效果”口径。

其次是速度维度，不只看GPU上的推理时间，还要看CPU和边缘设备上的表现。因为很多实际部署场景根本没有独立显卡，模型设计阶段就必须把计算设备的能力纳入考量。

第三是模型复杂度维度，包含参数量和浮点计算量两个子指标。复杂度直接影响部署时的磁盘占用、内存占用和功耗，对产品化非常重要。

最后是稳定性维度，具体表现为训练过程中是否容易收敛、换数据集后是否要重新调一大堆超参数。一个模型如果只能在自己的测试集上表现好，换个场景就崩，那在实际工程里是没有生命力的。

这四个维度构成了整个项目的评估框架。后续每做一次架构调整，我都会重新跑一遍完整评测，而不是只看单一指标。这个方法虽然费时间，但能避免“某个指标变好了，其他指标却悄悄倒退”的陷阱。

2.2 结构总览：MoE辅助加速与专用Transformer分支

YOLO-Master的整体架构可以理解为三大部分：主干特征提取网络、MoE加速模块、以及专用Transformer分支。主干网络负责最底层的特征提取，输出不同尺度的特征图。MoE加速模块嵌在主干网络的中后段，负责把计算资源动态分配到当前输入最需要的地方。专用Transformer分支则架设在高层特征之上，专门负责捕捉全局上下文信息和长距离依赖。

这里有个容易混淆的点需要先说明：MoE模块并不是用来让推理跑得更快的“加速器”那种感觉，而是通过“稀疏激活”的方式来减少无效计算。传统卷积网络在推理时，无论输入是什么，每个卷积核都会在整张特征图上计算一遍。MoE的做法是把一部分层替换成多个“专家”子网络，再通过一个门控单元判断当前输入更适合走哪些专家，其余专家就不参与计算。这样一来，模型的理论参数量可以做得很大，但实际推理时只用其中一部分，计算量反而比同体积的稠密网络还低。

专用Transformer分支则完全不同。它不做“省算力”的工作，反而要“多算一点”，通过自注意力机制让每个位置的信息都能与其他位置交互，从而建模出卷积局部感受野捕不到的关系。这个分支只在特征图分辨率已经缩小的高层阶段启用，计算开销可控，又能显著提升对遮挡目标、相似目标的区分能力。

MoE负责“省”，Transformer负责“补”，两者在位置上天然错开，不会互相打架。这也算是这个项目里比较关键的一个设计决策：不是把先进模块强行塞进去，而是让它们各管一段。

2.3 为什么选中MoE加Transformer的组合

很多人会问，为什么不干脆把整个主干网络都换成Transformer结构，像很多视觉大模型那样？原因很现实：目标检测需要高分辨率特征图来定位小目标，而Transformer的自注意力机制在高分辨率特征图上的计算量是随像素数量平方级增长的，部署到实时场景根本扛不住。即便有各种线性注意力优化方案，在训练成本和工程复杂度上依然比卷积网络高一个量级。

但完全只用卷积也不行。卷积的感受野是局部的，堆叠再多的层，本质还是靠层层扩大感受野来间接实现全局建模。这个过程会丢失不少细粒度位置信息，尤其在目标密集重叠时，卷积特征很容易把两个紧挨着的目标“糊”成一片。所以Transformer分支要做的，是在高层语义特征上做一次全局关系建模，让模型意识到哪些区域属于不同目标，哪些区域其实是同一个目标的组成部分。

MoE的加入则解决了另一个问题：网络规模变大后的效率问题。Transformer分支和更宽的主干都会让模型变大，如果在推理时所有参数都被激活，算力不够的设备会直接被拖垮。MoE让模型在“大”和“快”之间找到了一个折中——参数可以多，但每次推理只激活一小部分专家。这个思路很像一个大型公司里不同部门只处理自己擅长的事务，不会所有部门同时扑到一个任务上。

所以最终答案变得很清晰：用卷积主干保底，保证基础检测能力；用MoE做稀疏激活，控制实际计算量；用Transformer分支做全局增强，把复杂场景下的精度短板补起来。三者各司其职，才形成了YOLO-Master的方案雏形。

3. 核心实现细节拆解

3.1 MoE模块的设计与实现

先聊MoE模块的具体实现。我在主干网络的中后段选取了两个位置插入MoE层，位置选择的依据是特征图分辨率已经降低到输入尺寸的八分之一和十六分之一。这个位置的好处有两个：一是分辨率降低后特征图大小适中，即使有多个专家分支并行计算，内存占用也可控；二是这些层已经具备一定的语义抽象能力，门控路由可以学到更有区分度的选择策略。

每个MoE层的内部结构包含三部分：输入投影、专家网络集合、以及门控路由器。输入先经过一个线性投影把通道数对齐，然后送入门控路由器，路由器会输出一组权重，表示每个专家对这个输入的“适用程度”。在实际推理时，我不会直接取权重的最大值把其他专家全丢掉，而是采用Top-2激活策略，也就是把权重最大的两个专家及其对应计算结果做加权融合。这个选择借鉴了业界在大规模语言模型上的经验，Top-2策略既保留了多专家协作的多样性，又比全部激活省下大量计算。

专家网络本身并不是什么复杂结构，我用的是带残差连接的两层线性映射加激活函数，输出维度与输入一致。之所以不让专家结构太复杂，是因为每个专家只在部分数据上被训练，如果单个专家本身就很深，很容易过拟合到门控分配给它的小部分样本上。简洁的专家结构配合合适的正则化手段，反而能让每个专家学出更有区分度的特征。

门控路由器的设计是整个MoE模块的重心。它接受输入特征的全局池化结果作为依据，而不直接用原始特征图，因为全局池化能把二维空间的分布信息压缩成一个紧凑向量，让路由器把注意力放在“当前图像整体更像哪类分布”上，而不是被局部噪声干扰。

3.2 门控路由与专家划分策略

门控路由能否真正发挥作用，很大程度上取决于专家划分是否有意义。如果各个专家学出来的东西高度相似，门控怎么路由都没有意义。所以我在项目里做了一次对比实验：一组采用随机初始化的专家，另一组采用按语义类别预聚类的专家初始化。

预聚类的过程说起来也不复杂。我先用训练集里的特征向量做一次无监督聚类，把特征空间粗略分成若干簇，每个簇对应一个专家，然后用簇中心向量去初始化对应专家的权重。这么做的逻辑是：如果不同专家一开始就落在特征空间中相距较远的位置，后续训练中它们更容易分化出不同的“专长”。

从实验结果来看，预聚类初始化确实让门控路由的选择分布变得更加离散，不同专家处理的特征类型呈现出明显差异。举例来说，在交通场景里，一个专家的权重会在包含车辆目标的区域被拉高，另一个专家则在包含行人目标的区域更活跃。这种分化非常有利于整体精度的提升，因为每个专家只需要专注学一类相似的模式，拟合难度显著降低。

还要注意一个细节：路由权重在训练过程中需要加一个负载均衡损失。如果不做约束，门控很容易陷入“赢家通吃”的状态，也就是少数几个专家总被激活，其他专家几乎没有梯度更新，最后白占了参数量。我在实现中参考了一项常用做法，用每个专家在当前批次的平均路由概率和理想均匀分布的相对熵作为惩罚项，再乘一个较小的系数加入总损失。这个系数需要仔细调，太大会压制路由的区分度，太小则均衡效果不明显，实测下来设置在千分之一到万分之一级别比较合适。

3.3 专用Transformer分支的实现要点

再来说Transformer分支。它没有直接改变主干网络的结构，而是作为一条旁路分支在高层特征之后并行计算，最终把得到的全局增强特征再融合回原检测流程中。

具体实现上，分支的输入来自分辨率最低的高层特征图，这个特征图尺寸已经缩小到很低的倍率。我先对这个特征图做展开操作，把所有位置的点展开成序列，然后送入一个有若干个自注意力层的轻量级变换器。因为特征图尺寸小，序列长度不算夸张，自注意力的计算代价可以接受。

为了让Transformer分支具备空间位置感知能力，我在送入自注意力层之前加了一套可学习的位置编码。这个编码是训练出来的，不是手工固定的正余弦编码，因为检测任务对平移敏感，手工编码反而可能引入不必要的偏置。可学习位置编码能让模型在训练中自己决定要多大程度依赖位置信息，灵活性更高。

分支输出的序列会被重新塑造成特征图的形状，然后通过一个轻量的卷积层做通道对齐与平滑处理，再与原特征图逐元素相加。这种残差式的融合方式有个好处：即使Transformer分支训练初期效果不稳定，模型仍有一条完整的主干路径可以依赖，不会因为分支的波动而导致整个训练崩掉。我特意在融合前加了层归一化，确保两个分支的特征尺度一致，避免数值震荡。

Transformer分支的参数量控制也是一个重点。我用了比较小的隐藏维度和较少的头数，而不是照搬大规模语言模型的设置。原因是检测任务里的自注意力不需要那么大的表达能力，关键是让每个位置能有效“看到”全局，而不是追求特征维度的宏大。实测下来，这个轻量分支在总参数量中的占比控制在几个百分点左右，却明显拉高了复杂场景下的检测效果。

4. 训练流程与数据处理

4.1 数据准备与增强策略

训练数据直接影响模型的天花板。YOLO-Master的定位是通用实时检测，所以我选择在公开目标检测数据集上做基础训练，再在专门构造的密集小目标子集上做针对性微调。

公开数据集的好处是类别覆盖广、场景多样，能保证模型学到通用的特征表示。但公开数据集里小目标的占比相对有限，所以我又补充了一批模拟数据，通过把大目标切割、粘贴到不同背景中的方式构造了大量小目标样本。这种“复制粘贴”式的增强策略在工业界非常成熟，它能显著提高小目标类别的样本量，成本却很低。

整体训练时用的数据增强管线包括随机翻转、随机缩放、随机颜色抖动、马赛克增强和混合增强。马赛克增强把四张图拼成一张输入，相当于变相扩大了批次大小，对检测任务特别有效。混合增强则把两张图的像素按比例混合，标签也按相同比例混合，强迫模型学会更鲁棒的特征，不容易过拟合到单张图的纹理上。

需要特别注意的是，增强策略不能一成不变。我在训练后期逐渐关闭了马赛克增强，因为拼图后的图像分布和真实场景有一定差异，如果一直开到最后，模型在真实场景上反而会掉点。这种“先强后弱”的增强退火做法，是我在多个检测项目里验证过比较稳妥的处理方式。

4.2 两阶段训练与渐进式优化

训练策略我拆成了两个阶段：第一阶段训练整网但冻结MoE的门控路由器，第二阶段再解冻所有参数联合微调。

第一阶段冻结门控是有意的设计。门控路由器本身是个比较敏感的部分，如果在训练一开始就让它自由更新，而各专家又还没有形成有意义的区分，路由就会乱跳，导致梯度信号不稳定。先把主干和专家网络训练到基本收敛，让各部分掌握了基本特征，再放开门控去学习路由策略，整个训练过程会顺畅很多。

第二阶段联合微调时，我把学习率调低一个数量级，同时把负载均衡损失的权重上调一点，让路由分布更均匀。这里有个经验技巧：微调阶段一定要用较小的学习率，否则门控权重的更新幅度过大会破坏第一阶段学到的稳定特征。

除了分阶段训练，我还采用了渐进式分辨率策略，先在较低分辨率下训练若干个轮次，再切到较高分辨率继续训练。低分辨率阶段能加速收敛，让模型先掌握稳定的轮廓特征，高分辨率阶段再聚焦细节和小目标。这个做法在检测训练里很常见，实测下来能节省不少训练时间，同时让最终精度略有提升。

优化器方面用的是带动量的随机梯度下降方法，配合余弦退火学习率调度。虽然自适应优化器收敛更快，但最终精度往往不如精心调过参数的随机梯度下降。对于目标检测这种复杂任务，我还是更倾向于用随机梯度下降配合扎实的学习率调度，保证模型落到一个比较平缓的最优点上。

4.3 推理部署与实时性调优

训练完成的模型要想真正跑起来，部署环节还得下一番功夫。我优先做了模型导出与计算图优化，把训练过程中用到的动态控制流和辅助损失结构全部剥离，只保留前向推理所需的核心算子。这个步骤能消除大量多余计算，有些动态控制流在训练时是必要的，但部署时完全是负担。

在量化方面，我在MoE模块上做了特殊处理。MoE的专家网络本身就是线性层加激活函数，结构简单，量化误差相对容易控制，所以我采用混合精度量化的策略：主干网络的关键层保持高精度，而专家网络和门控路由器使用较低精度。这样能在精度损失极小的前提下进一步压缩模型体积。

还有一个容易被忽视的部署问题是批处理大小。实时检测场景多数时候是单帧输入，如果模型在推理框架里被默认按固定批大小编译，单帧输入时反而会变得低效。我特意把模型导出为动态批维度，让推理框架可以灵活处理不同批量请求。这个细节在流量波动明显的业务场景里尤其重要，能有效避免排队延迟。

针对边缘设备的部署，我还做了算子融合，把卷积、批归一化和激活函数合并成单一算子。这能减少内存读写次数，在CPU设备上提升尤其明显，实测推理速度提升了将近两成。算子融合的实现原理并不复杂，但它属于“做了才有感知、不做也能跑”的优化项，很多人容易忽略。

5. 实验结果与消融分析

5.1 与常规单阶段模型的对比

为了验证YOLO-Master的设计价值，我选择了一组规模相近的传统单阶段检测模型作为对照组，包括两组不同深度的主流实现。所有模型都在相同数据集上重新训练到收敛，并用同样的评测脚本进行公平对比。

先看整体精度。YOLO-Master在整体均值平均精度上比对照组中较浅的模型提高了三个点左右，比对照组中较深的模型也提高了将近两个点。速度方面，在相同设备上，YOLO-Master的推理耗时与较浅模型基本持平，比较深模型低了近三成。这说明MoE的稀疏激活确实有效，让模型获得了接近大模型的表达能力，却没有付出同等规模的计算代价。

再看参数量与计算量。YOLO-Master的总参数量比对照组深模型还要多一些，但实际浮点计算量却更低。这种“参数多、计算少”的特性正是MoE架构的核心优势，它让模型可以容纳更多知识，但推理时只动用其中一小部分，非常适合算力受限的部署场景。

这个对比结果让我比较满意，因为它不是单纯靠某一个模块赢来的，而是MoE省算力和Transformer补精度两个机制共同作用的结果。对比表格里最能说明问题的一行数据是：在计算量略低于浅模型的情况下，精度还能比深模型更高。这充分说明算力没有被浪费，每一分计算都花在了刀刃上。

5.2 消融实验：MoE与Transformer各自带来的增益

只看最终效果还不够，我还得弄清楚每个模块到底贡献了多少。为此我做了一组消融实验，从完整模型里逐步去掉模块，观察指标变化。

第一组去掉Transformer分支，只保留主干和MoE。结果显示整体精度下降了约一个点，其中在遮挡目标和小目标上的降幅最明显。这说明Transformer分支的全局建模能力确实在复杂场景中不可或缺，没有它，模型对小目标的区分能力会明显变弱。

第二组去掉MoE模块，换回普通的稠密卷积结构，保持其他部分不变。这个变体的精度与完整模型比较接近，但浮点计算量增加了四成左右，推理速度明显变慢。这个结果的解读很有价值：MoE对精度的直接贡献相对有限，它的核心价值在于让高容量模型的推理成本保持在可接受范围内。

第三组把两个模块都去掉，退化成最基础的卷积单阶段检测结构。这组的效果明显垫底，不仅精度是最低的，小目标上的表现更是落后完整模型好几个点。这说明两个模块的组合并非简单叠加，而是在精度和效率两个维度上形成了互补，缺了任何一个，整个设计都会失去平衡。

为了更直观地展示数据，我把风格化的实验结果整理在下面的表格里（数值均为项目中归一化相对结果，便于对比趋势）：

5.3 典型场景实测

指标只能反映一个平均情况，实际跑业务场景时的表现才是更真实的试金石。我选了两个有代表性的场景做针对性测试。

第一个是交通路况监控场景，画面里同时有车辆、行人和非机动车，目标尺度跨度极大。远处的行人在整个画面里只占很小一片区域，而且常被近处的车辆遮挡。完整YOLO-Master在这个场景里的表现超出预期，许多肉眼都需要仔细分辨的遮挡目标都被成功检出。对比基线模型，漏检数量明显减少，尤其对重叠车辆与行人交织区域的区分能力改善非常明显。这主要归功于Transformer分支的全局建模能力，它让模型不再只依赖局部的纹理信息，而是能够从更大范围推断出目标边界。

第二个是仓储监控场景，货架上密集摆放着各种规格的商品，目标数量多且相互紧贴。这个场景对定位精度的要求很高，目标框稍微偏一点，就容易从一个商品偏移到另一个商品上。YOLO-Master在密集排列场景下展现了稳定的定位性能，检测框大多能准确贴合商品边缘。MoE路由在这种场景下的表现也颇具意思，通过可视化门控权重分布，能看到不同货架区域的图像倾向于激活不同的专家，这证明门控学到的是某种与场景布局相关的特征，而不是单纯的颜色或纹理统计。

6. 工程化问题与调参实录

6.1 训练中的常见坑与对策

训练过程中踩过的坑不少，这里挑几个最值得说的。

第一个坑是MoE门控路由器的收敛不稳定。前几次实验时，我在第一轮训练就不加限制地放开所有参数，结果门控权重震荡得很厉害，损失曲线像锯齿一样上下跳动。后来改成两阶段训练法，先冻结门控让主干和专家收敛，再放开联合微调，这个毛病基本就消失了。如果遇到类似问题，我的建议是先检查加载均衡损失系数是否太小，其次确认是否有冻结门控的稳定阶段，最后再考虑调整门控的初始化方式。

第二个坑是负载均衡系数对整体精度的干扰。系数调得太大，路由权重会趋于均匀，专家失去专长；系数调得太小，又会出现“赢家通吃”，多数专家梯度很小，几乎起不到作用。我花了比较长的时间在这个系数上来回试，最终确定在一个较小的区间内同时兼顾了路由区分度和专家利用率。

第三个坑是Transformer分支训练初期的震荡。分支刚接入主干时会产生较强的梯度噪声，不加保护措施的话，主干前几层的特征会被打乱，导致损失不降反升。我最后在分支入口前加了一层梯度缩放，相当于限制了分支反向传播的梯度强度，让主干稳定不被干扰。这类“梯度保护”手段在实际工程里很常见，属于经验性但极为有效的做法。

6.2 部署阶段的问题排查

部署时遇到的问题和训练时完全是两种画风。训练时关心的是loss降不降，部署时关心的是“能不能跑”“跑得多快”“精度掉没掉”。

最容易踩的部署坑是量化后精度骤降。我尝试过直接对整个模型做低比特量化，结果精度崩得非常厉害，定位框偏移严重。排查后发现主要问题出在主干网络中对数值敏感的结构上，不同层对量化的耐受度差异极大。解决方法是分层诊断：逐层对比量化前后的输出差异，找出误差放大明显的层并把这些层单独设置成高精度，最终在保持大部分量化收益的同时把精度损失控制到很小。

第二个部署坑是不同推理框架的结果不一致。同一个模型在不同框架里的算子实现细节有差异，导致输出框的位置出现微小偏移。这个问题的严重性在于，有些目标是紧贴着置信度阈值边缘的，算子差异可能直接导致检测结果被漏掉或误检。我的解决思路是在训练时就加入与部署环境一致的数据处理流程，减少训练与部署之间的环境差异。同时用一套统一的校准数据对模型输出做逐层校验，发现问题就立刻排查算子兼容性。

还有一个值得记录的部署问题是动态批处理容易踩内存峰值。模型导出为动态批维度后，如果业务请求量突然增大，内存占用会随之波动，边缘设备上甚至可能直接爆内存。我在实际部署中加了请求排队限流机制，控制最大并发数，同时给推理框架配置了显式内存池上限，确保极端情况下系统不会被拖垮，代价只是牺牲少量极端并发场景下的吞吐量。

6.3 一些实用的调参技巧

最后分享几个我个人觉得性价比很高的调参技巧。

第一，门控路由器使用独立的学习率。我对门控参数设置了比主干稍高的学习率，因为门控需要在训练后期更快地适应专家分工的变化。这个改动很小，但对路由分布的收敛速度有帮助。

第二，Transformer分支参与训练的时间要晚于主干。我在顺序上做了设计，让主干先充分学习尺度特征，分支再开始介入全局建模，效果比所有模块同时端到端训练更好。这种做法有点类似课程学习的思路：模型先解决容易的问题，再解决难的问题，训练过程会更平滑。

第三，数据加载和预处理的速度一定要提前优化。检测训练本身就吃数据，如果数据加载成为瓶颈，再好的训练策略也会被拖累。我用预取机制把图像解码和增强操作放到独立线程里执行，训练速度提升了将近三成，而且完全是纯工程优化，不影响任何算法指标。

第四，坚持记录每一次实验的完整配置。我建了一个实验记录表，把每条超参数、数据增强开关、训练了多长时间、最终精度多少全部存下来。不要高估记忆力，很多调参经验都是对比历史实验记录才总结出来的，有条理的记录能让实验推进效率提升不少。

7. 个人经验与后续扩展建议

这个项目从设计到落地的整个过程让我有一个很直观的体会：好的模型结构不一定意味着堆砌最先进的技术模块，而是要把模块放在正确的位置上，让它们解决不同维度的问题。MoE用来控制计算成本，Transformer用来补充全局建模能力，两个模块单独拿出来都不是这个项目的首创，但组合在一起，配合针对性的训练策略，就做出了一个在实际业务里能用的实时检测系统。这种“用已有积木搭出新效果”的思路，可能比从零发明一个新结构更有工程价值。

后续如果要继续扩展，我觉得有两条路可以再往深走。一条是把MoE的路由策略做得更精细，比如让门控不仅依赖当前层的特征，还参考前一帧的检测结果，从而在视频流场景下实现更稳定的时序路由。另一条是在Transformer分支里引入时序建模能力，让模型不再逐帧独立推理，而是能跨帧利用运动信息和时间上下文，这会对视频检测场景的精度带来更明显的提升。YOLO-Master目前做的是一个静态单帧的实时检测方案，但实时视频流才是更多真实业务的常态，所以这条技术路径值得继续探索。