一、为什么你的“轻量级”YOLO跑不快？——问题的根源
很多做目标检测落地的开发者都有这样的困惑：用了各种“轻量级”骨干网络替换YOLO原生Backbone，FLOPs（浮点运算次数）确实降了，但实际跑起来延迟还是高、吞吐上不去，尤其在边缘设备和CPU上更加明显。这就好比你买了一辆标称油耗极低的车，踩着油门才发现百公里油耗并不低——问题出在哪里？
根据FasterNet原论文作者的研究，核心矛盾在于FLOPs的减少并不一定会带来同等级别的延迟降低。这主要是因为大量“轻量级”算子（尤其是深度卷积Depthwise Convolution，简称DWConv）在减少FLOPs的同时，却带来了频繁的内存访问（Memory Access），导致实际每秒浮点运算次数（FLOPS）低下。更直白地说：DWConv的FLOPs虽小，但每次运算都要去内存里“搬运”数据，搬运本身的时间开销比计算还大，GPU/CPU的大量时间浪费在“等数据”上，而非“算数据”上。
这就解释了为什么ShuffleNet、MobileNet、GhostNet等依靠DWConv或组卷积（GConv）来降低FLOPs的经典轻量级网络，其实际推理延迟往往远高于纸面FLOPs所暗示的水平。例如，根据原始论文的对比测试，CycleMLP-B1的FLOPs只有ResNet50的一半，但实际运行速度反而更慢（111.9ms vs 69.4ms）。
解决这个问题的关键在于找到一个既能减少冗余计算、又能降低内存访问频率的算子——而部分卷积（Partial Convolution，PConv）正是为此而生。<
