多任务模型执行左转、右转、直行或刹车时，通常会完整运行同一套骨干网络，即使部分计算与当前任务无关。香港科技大学、华为诺亚方舟实验室、香港科技大学（广州）团队把任务命令直接变成硬件执行掩码，在FPGA闭环驾驶实验中将端侧延迟降低51%至59%。
任务条件稀疏同时减少66%至76%的FLOPs，单次推理能耗从263mJ降至108至128mJ。数据来自AMD/Xilinx Alveo U50和CARLA驾驶任务，不能直接外推到所有芯片、模型与真实道路。
命令在推理前就已经知道
自动驾驶控制器收到“跟车道”“左转”“右转”或“刹车”等高层命令后，才根据相机输入输出转向和加速度。旧方案虽然使用不同任务分支，共享骨干仍会把所有卷积通道算完。
论文Figure 1：不同任务激活不同计算块，门控网络输出二进制掩码，FPGA延迟降低54.4%。
新方法加入轻量门控网络，按命令生成每个输出通道块的二进制掩码。掩码在主干计算开始前就可用，被关闭的块不读取权重、不产生乘加，也不写回激活。
稀疏粒度直接对齐硬件调度
研究者没有先训练一个任意稀疏模型，再要求硬件适配不规则零值。每个Tile对应固定数量的输出通道，正好是加速器的原生调度单位；训练时的稀疏目标与硬件能够跳过的单位保持一致。
论文Figure 3：任务命令经过门控网络生成Tile掩码，被关闭的通道块在执行时跳过。
指令集把每个Tile的掩码字段一起送入调度器。加速器使用双缓冲存放权重和激活，Tile管理器协调DMA与计算流水线，不需要软件逐层插入分支判断。
论文Figure 4：指令调度器、Tile管理器、DMA、双缓冲和INT8计算流水线。
不同任务学出不同计算路径
可视化显示，刹车命令关闭的块最多，转弯和车道跟随保留更多通道；网络越深，部分任务被裁掉的块越多。门控不是固定剪枝，同一个模型会随任务命令切换路径。
论文Figure 10：橙色为激活Tile，刹车任务最稀疏，不同Transformer层的模式不同。
在Alveo U50上，延迟从9.12毫秒降到3.74至4.44毫秒，相当于2.1至2.4倍加速。论文同时检查闭环驾驶质量，报告在减少计算后维持任务表现；这里的“维持”基于CARLA路线与指标，不代表真实车辆安全验证。
FLOPs下降、延迟下降和能耗下降并不是同一个比例。跳过计算后，芯片仍要承担门控、掩码传输、内存访问和未被关闭的层；不同任务保留的Tile数量也不同。因此论文分别报告66%至76%的计算减少、51%至59%的延迟减少和具体能耗，而没有把理论稀疏度直接当成端到端加速比。
这一方案依赖高层任务命令在推理前已经明确。若系统同时需要检测多种目标，或命令来自一个可能出错的上游模块，过早关闭通道可能遗漏信息。真实部署除了平均精度，还要评估错误命令、任务切换和极端场景下的最坏表现。
论文中的FPGA实现证明结构化稀疏可以被硬件真正跳过，比只报告参数为零更接近端侧收益。不过，量产NPU通常有固定编译器和算子约束，能否动态更换Tile掩码、是否触发重新调度，都会改变实际加速效果。
下一步是跨模型和商用芯片验证
任务命令是很多端侧系统已有的免费信号。机器人可以按“抓取、移动、观察”切换计算，摄像头也可以按检测或分割任务选择不同路径，不需要先看完整输入再决定稀疏度。
真正落地还要验证GPU、NPU和量产SoC的指令与内存系统是否能获得同等收益，并处理命令不确定或多个任务同时激活的情况。论文已给出Transformer扩展实验，下一步是把软硬件协同设计迁移到更多主干与真实设备。
