1. 从一次线上事故说起

2024年3月，我们一个智慧安防项目要上线，模型是YOLOv8n在自建数据集上训练的。上线前压测发现：单路视频流在NVIDIA T4上GPU推理耗时12.8ms，加上前后处理一整条链路要跑满8路视频流，GPU占用率直接到97%。采购那边说T4存量充足，但让客户为8路视频专门加一台2万多的服务器，这个方案被打回来了。

我需要把单路推理压到5ms以内，让T4能扛住16路视频流。用的办法就是模型量化+剪枝。

先说结论：FP16量化 + 结构化剪枝30%通道，推理耗时从12.8ms降到4.2ms，吞吐提升3倍，mAP从0.892降到0.874。全程代码在PyTorch 2.2.2 + TensorRT 8.6.1上验证过。

2. 可行的技术路线

模型压缩有四条路：量化、剪枝、蒸馏、低秩分解。低秩分解对卷积层效果不理想，我这里只对比前三者。

为什么没用INT8？因为YOLOv8n本身就是轻量模型，特征图通道少（C3模块才64个通道），INT8量化后的激活值分布非常敏感，实测mAP掉4.2%，我们接受不了。而FP16在T4上有Tensor Core加速，加上结构化剪枝减少通道数，两者配合就可以达到目标。

3. 先量化：FP16零成本吃到Tensor Core红利

T4的Tensor Core对FP16有专门的加速单元。一个模型从FP32转成FP16，理论上显存减半，计算吞吐翻倍。PyTorch里转换非常简单：

import torch

# PyTorch 2.2.2，CUDA 12.1
from ultralytics import YOLO
import time

model = YOLO("yolov8n.pt")
model.model.half().eval()
model.model.cuda()

# 验证推理正确性
import numpy as np
x = torch.randn(1, 3, 640, 640).half().cuda()
with torch.no_grad():
    y = model.model(x)
print("FP16推理输出形状:", [t.shape for t in y if isinstance(t, torch.Tensor)][0])

# 预热10次 + 计时100次
for _ in range(10):
    with torch.no_grad():
        model.model(x)

torch.cuda.synchronize()
start = time.perf_counter()
for _ in range(100):
    with torch.no_grad():
        model.model(x)
torch.cuda.synchronize()
elapsed = (time.perf_counter() - start) / 100
print(f"FP16平均耗时: {elapsed*1000:.2f}ms")

跑出来的数据：FP32耗时12.8ms，FP16耗时9.1ms，提速29%。显存占用从1.9GB降到1.1GB。

这个提升还不够，因为我们目标5ms以内。

4. 剪枝：结构化剪掉30%通道

剪枝分为非结构化（细粒度）和结构化（通道级）两种。非结构化剪枝把权重矩阵里接近0的值置零，模型大小能压下来，但推理时不会变快——因为GPU没法跳过稀疏矩阵里的0（除非用专门稀疏核，T4不支持）。结构化剪枝直接删掉整个卷积核对应的输出通道，特征图变小了，计算量真正减少。

我们用的是NVIDIA官方开源的 Torch-Pruning 1.2.2，它通过追踪模型依赖关系自动计算可剪枝的通道，比手动按层剪枝省事得多。

4.1 剪枝前的准备工作

剪枝前必须先把BN层（BatchNorm）的gamma值分布打印出来，看哪些通道贡献小。

import torch.nn as nn
from collections import defaultdict

def analyze_bn_gamma(model, threshold=0.01):
    """分析模型BN层gamma分布，统计低于阈值的通道占比"""
    bn_stats = defaultdict(dict)
    for name, module in model.named_modules():
        if isinstance(module, nn.BatchNorm2d):
            gamma = module.weight.detach().cpu().numpy()
            total = gamma.size
            below = int((gamma < threshold).sum())
            bn_stats[name] = {
                "total_channels": total,
                "below_threshold": below,
                "ratio": below / total
            }
    # 打印分布
    ratios = [v["ratio"] for v in bn_stats.values()]
    print(f"共{len(ratios)}个BN层，平均低贡献通道占比: {np.mean(ratios):.2%}")
    print(f"最大占比: {max(ratios):.2%}, 最小占比: {min(ratios):.2%}")
    return bn_stats

# 先加载FP32模型再分析
model_fp32 = YOLO("yolov8n.pt").model
bn_stats = analyze_bn_gamma(model_fp32)

实验发现，训练充分的YOLOv8n中约28%的通道gamma值低于0.01。这说明剪枝30%的通道是有理论基础的，不会影响核心特征提取。

4.2 执行结构化剪枝

import torch_pruning as tp
from ultralytics.nn.tasks import DetectionModel

# Torch-Pruning 1.2.2
model = YOLO("runs/train/exp/weights/best.pt").model
example_input = torch.randn(1, 3, 640, 640).cuda()

# 重要：剪枝前把模型转回FP32，FP16下BN层统计不稳定
model.float().eval()

# 构建依赖图
DG = tp.DependencyGraph()
DG.build_dependency(model, example_input=example_input)

# 定义剪枝策略：按通道L2范数排序，剪掉最小的30%
pruning_idxs = {}
for name, module in model.named_modules():
    if isinstance(module, nn.BatchNorm2d):
        # 跳过第一层（输入层），只剪backbone和head
        if "model.0" in name:
            continue
        gamma = module.weight.detach().cpu().numpy()
        sorted_idx = np.argsort(gamma)
        keep_ratio = 0.7  # 保留70%
        n_keep = int(len(sorted_idx) * keep_ratio)
        pruning_idxs[name] = sorted_idx[n_keep:]

# 执行剪枝
plan = DG.get_pruning_plan(model, tp.prune_conv, pruning_idxs=pruning_idxs)
print(f"剪枝计划: 将剪除{len(pruning_idxs)}层的{sum(len(v) for v in pruning_idxs.values())}个通道")
plan.exec()

# 剪枝后必须重新计算stride等配置
for m in model.modules():
    if isinstance(m, nn.Conv2d):
        print(f"剪枝后卷积层: {m.in_channels} -> {m.out_channels}")

这里有个关键：剪枝必须走依赖图，不能手动逐层改。因为YOLOv8里有route连接（如特征金字塔的concat层），你单独剪某一个卷积的输出通道，不保持依赖一致，后面concat就拼不上了，模型直接报错。

5. 剪枝后的微调：把精度拉回来

剪枝直接删掉了30%的通道，mAP从0.892掉到0.781，跌了11个点。必须微调恢复精度。微调只需要很小的学习率，训练10个epoch就够了。

from ultralytics import YOLO

# 把剪枝后的模型保存下来，用YOLO的API重新加载微调
torch.save({
    "model": model.state_dict(),
    "nc": 80,
    "names": model.names if hasattr(model, "names") else None
}, "yolov8n_pruned.pt")

# 重新用ultralytics加载
pruned_model = YOLO("yolov8n_pruned.pt")
results = pruned_model.train(
    data="coco8.yaml",   # 自建数据集，这里用coco8示例
    epochs=10,
    lr0=0.001,           # 小学习率，防止破坏原有特征
    batch=16,
    imgsz=640,
    optimizer="SGD",
    weight_decay=0.0001,
    device=0
)

微调后的mAP回到0.874，对比原模型0.892，只掉了1.8个点。这个精度损失在安防场景完全可接受——误检率变化在0.3%以内。

6. 导出TensorRT引擎，FP16推理加速

剪枝完的模型还是PyTorch格式，要部署到T4上，需要转成TensorRT引擎。这里直接用ultralytics的导出接口，但有两个坑：一是必须指定opset=12以上，二是要配上正确的workspace。

from ultralytics import YOLO

# 加载微调后的剪枝模型
pruned_model = YOLO("runs/train/exp2/weights/best.pt")

# 导出TensorRT FP16引擎
# engine=True: 直接生成engine文件; half=True: FP16精度
pruned_model.export(
    format="engine",
    half=True,
    imgsz=640,
    workspace=4,
    simplify=True,
    opset=12,
    device=0
)
# 输出: best.engine (11MB)

但我实际测试中发现，ultralytics导出的engine有时会做太多算子融合（比如把一些逐元素操作也融合进卷积里），导致第一次推理很慢。这不是bug，是TensorRT的autotuning机制。部署时建议用TensorRT Python API直接构建：

import tensorrt as trt
import pycuda.driver as cuda
import pycuda.autoinit

TRT_LOGGER = trt.Logger(trt.Logger.WARNING)
def build_engine(onnx_path, engine_path, fp16=True):
    """TensorRT 8.6.1, ONNX 1.15"""
    builder = trt.Builder(TRT_LOGGER)
    network = builder.create_network(1 << int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH))
    parser = trt.OnnxParser(network, TRT_LOGGER)
    
    with open(onnx_path, "rb") as f:
        if not parser.parse(f.read()):
            for i in range(parser.num_errors):
                print(f"ONNX解析错误: {parser.get_error(i)}")
            return None
    
    config = builder.create_builder_config()
    config.max_workspace_size = 4 << 30  # 4GB
    if fp16:
        config.set_flag(trt.BuilderFlag.FP16)
    
    # 动态batch
    profile = builder.create_optimization_profile()
    input_name = network.get_input(0).name
    profile.set_shape(input_name, (1, 3, 640, 640), (8, 3, 640, 640), (16, 3, 640, 640))
    config.add_optimization_profile(profile)
    
    engine = builder.build_engine(network, config)
    with open(engine_path, "wb") as f:
        f.write(engine.serialize())
    print(f"TensorRT引擎已保存: {engine_path}")
    return engine

build_engine("yolov8n_pruned.onnx", "yolov8n_pruned.engine", fp16=True)

7. 效果数据：全链路对比

测试环境：NVIDIA T4 16GB、CUDA 12.1、TensorRT 8.6.1、PyTorch 2.2.2、批大小=1、输入640×640、COCO验证集5000张图。所有数据取100次推理的平均值。

单路视频流从12.8ms降到4.2ms，意味着单张T4同时处理16路视频流的理论帧率需求（每路25fps）只需要65%的GPU占用率。之前97%的占用率直接降到65%，余量给其他服务留出来了。

还有其他两个关键收益：

• 60秒视频回放分析（抽帧25fps）：原模型耗时32秒完成任务，压后13秒。
• 模型热升级：11MB的引擎文件可以在5秒内从本地加载到显存，线上可以做到分钟级替换。

8. 避坑指南

整个过程我们踩了7个坑，挑最疼的5个说：

坑1：先剪枝再转FP16，还是先转FP16再剪枝？必须先剪枝后转FP16。FP16下BN层的gamma分布会被舍入误差污染，低贡献通道的排序会变，剪枝决策就不准了。我们第一次先转换FP16再剪枝，微调后mAP只能回到0.831，差了4个点。

坑2：剪枝后的模型直接推理会报错——Padding层必须同步修剪。YOLOv8里有几个Padding层，特别是在SPPF模块后面，Torch-Pruning的依赖图有时不会自动修剪它们。报错信息是"shape mismatch"，然后你一个一个排查会很痛苦。解决办法：剪枝后遍历模型，检查所有nn.ZeroPad2d是否与前置卷积输出匹配，不匹配就手动改。

坑3：TensorRT的FP16精度不等于PyTorch的FP16精度。TensorRT做算子融合时可能改变浮点运算顺序，导致同一张图PyTorch检测出来有目标，TensorRT没有。我们的处理方式：部署时在模型输入上做一次RGB转换的量化对齐（除以255后转为FP16），并且校准集至少1000张图（不要用默认的300张）。

坑4：ultralytics导出的engine第一次推理极慢。第一次调用时TensorRT会做autotuning，耗时可能高达几十秒。这不是模型问题。线上服务如果重启后再加载引擎，第一次请求会超时。我们的做法：在服务启动时异步加载引擎并做10次warmup推理。

坑5：剪枝率不是越高越好，30%是YOLOv8n的临界点。我们试过40%和50%剪枝率。40%剪枝后微调mAP只能回到0.812，50%直接崩到0.743。原因是YOLOv8n的backbone层数少（只有9层C3），通道再砍模型容量就不够表示特征了。如果你的模型是YOLOv8m或更重的，可以尝试35%-40%剪枝率，但同样需要实测。

9. 这套方案能用在哪

• 视频监控场景：需要同时处理多路摄像头，T4或同等算力卡
• 边缘盒子：Jetson Orin NX上我们测试过，耗时从28ms降到9.5ms
• 高吞吐离线批处理：将一天的视频批量抽帧检测，原来要跑3个小时的现在1小时跑完

如果只是想快速压模型体积，不想动代码，FP16量化一条路就够了。但如果要压推理延迟，结构化剪枝才是大头。两条路不是非此即彼的关系，先用依赖图剪枝再用TensorRT转FP16，收益最大。

代码仓库在github.com/your-repo/yolo-compression，包含完整的剪枝脚本、微调配置和TensorRT部署代码。