从产线卡顿说起上周在工厂部署YOLOv11检测系统时遇到一个典型问题：模型在测试集上mAP跑得挺漂亮，但一上产线视频流就出现明显卡顿，平均延迟飙到200ms以上，产线主管直接喊停。拆开日志一看，预处理、推理、后处理三个环节的时间分布极不均衡，GPU利用率像心电图一样忽高忽低。这种问题在实验室里很难暴露，却是实时系统设计的致命伤。实时系统不是“跑得快”就行，得在延迟、吞吐、资源三者间找到平衡点。今天我们就拆解一套能扛住产线压力的YOLOv11系统架构。核心矛盾：延迟 vs 吞吐设计实时系统前得想清楚主要矛盾。低延迟要求单个请求尽快完成，高吞吐要求单位时间处理更多请求。这两个目标经常打架——比如为了吞吐量而批量处理图像，必然增加单张图的等待时间。工厂场景下，我们通常这样定指标：延迟：从图像进入系统到输出结果，95%的请求在50ms内完成吞吐：单卡至少处理30路1080P视频（按25FPS算）资源：GPU内存使用率不超过80%，留出波动余量流水线拆解与优化预处理阶段：别让CPU拖后腿# 糟糕的写法：在循环里一条条处理for