PaddleSeg 推理 Benchmark 全解析：GPU 加速、TensorRT 精度配置与实测数据解读

• 人工智能
• 计算机视觉
• 预训练

PaddleSeg 官方推理 Benchmark 文档系统性地评估了 7 个主流语义分割模型在 V100 GPU 上的推理性能，覆盖 Paddle Inference 原生 FP32、TensorRT FP32/FP16/INT8 四种推理组合，并给出 mIoU 与单图耗时指标。本文以 docs/deployment/inference/infer_benchmark.md 为核心骨架，结合 deploy/python/infer.py 与 deploy/python/infer_benchmark.py 的源码实现，完整复现测试方法论、参数体系与结果解读，帮助你复现同款基准测试，并为自己的分割模型做精度-速度权衡选型。

一、测试环境与测试方法

1.1 硬件与软件栈

Benchmark 数据对应的测试环境如下：

需要强调的是，该环境属于 Benchmark 发布时的固定快照，其中 TensorRT 6.0 / Paddle 2.1.1 均为当时版本。如果你在更高版本（如 CUDA 10.2 + cuDNN 8.1 + TensorRT 7.x + Paddle 2.3+）上复测，绝对数值会发生变化，但 FP16/INT8 相对 FP32 的加速趋势与精度变化规律仍可参考。部署环境的具体准备步骤见 Python 部署指南：GPU 场景下 Naive 模式可直接安装paddlepaddle-gpu>=2.1，TensorRT 模式还需额外下载与 CUDA/cuDNN 匹配的 TensorRT 库并加入LD_LIBRARY_PATH。

1.2 四项测试约定

原文档明确了 4 条测试约定，它们是理解 Benchmark 数值的前提：

1. 数据集：使用 Cityscapes 全量验证集（原始分辨率 1024×2048）测试；
2. 运行方式：单 GPU、batch size 为 1；
3. 耗时口径：只统计纯模型推理时间，不包含数据预处理与后处理；
4. 推理后端：使用 Paddle Inference 的 Python API 测试，通过use_trt参数决定是否启用 TensorRT，通过precision参数设置预测数据类型。

这四条约定与 deploy/python/infer_benchmark.py 的实现一一对应：该脚本的PredictorBenchmark.run()只执行predictor.run()循环并用time.time()掐表，测量区间严格限定在模型前向推理上。

二、GPU 推理 Benchmark 数据总览

下表为原文档提供的 7 个模型 × 4 种推理组合的完整数据（mIoU 与耗时 s/img）：

注：UNet 的 mIoU 为 Cityscapes 上以 1024×512 输入得到的基准值，与表中其余模型在 1024×2048 下的测试口径不同，直接横向比较 mIoU 意义有限，请结合模型配置理解。对应训练配置可参考 configs/unet/unet_cityscapes_1024x512_160k.yml。

2.1 从数据中能读出的关键规律

（1）TensorRT 并非在所有场景下都更快

对比 Naive FP32 与 TRT FP32 两列可以发现：对 ANN、PSPNet 这类模型，TensorRT 加速有限甚至略慢（ANN 0.274→0.281 s/img）；而 UNet 在开启 TRT 后反而明显变慢（0.071→0.099 s/img）。这印证了官方文档的提示——"a small number of models do not support deployment using TensorRT on Nvidia GPUs"（少数模型使用 TensorRT 部署可能得不到加速）。原因从源码可推断：TRT 引擎对算子做子图融合需要满足特定条件，且动态 shape 模式下每次推理可能涉及引擎调度开销，对小模型收益常被开销抵消。是否启用 TRT 应实测决定，不能默认更优。

（2）FP16 是多数模型的性价比之选

EMANet 在 FP16 下达到 0.062 s/img，相比 Naive FP32 的 0.208 s/img 加速约 3.4 倍，且 mIoU 基本无损（0.7905→0.7904）；GCNet 从 0.247 降到 0.100 s/img；DNLNet 从 0.381 降到 0.230 s/img。这些模型在 FP16 下精度损失几乎为 0。

（3）INT8 依赖量化校准，效果因模型而异

INT8 需要加载量化后的预测模型并配合校准（源码中对应use_calib_mode=False的配置路径），其精度与加速比在不同模型上差异较大：

• 正向案例：DeepLabV3P_ResNet50_OS8 在 INT8 下耗时降至 0.083 s/img（约 2 倍于 Naive FP32），mIoU 反而从 0.8036 提升到 0.8044；
• 负向案例：DNLNet 在 INT8 下耗时 0.236 s/img 反超 FP16 的 0.230 s/img，且 mIoU 从 0.7995 微降至 0.7989；
• 无明显收益案例：UNet 三种 TRT 精度耗时均为 0.099 s/img。

这说明 INT8 的收益高度依赖模型结构与量化实现，选择前务必结合自身数据实测。

（4）精度-速度的选型建议

若追求极致精度，Naive FP32 或 TRT FP32 即可；若追求高吞吐且精度敏感，优先尝试 FP16——表中所有模型在 FP16 下 mIoU 与 FP32 的差值最大不超过 0.0001；若对精度容忍度高且模型结构适合量化（如 DeepLabV3P），INT8 能带来最大加速比。

三、复现 Benchmark：从导出模型到运行脚本

3.1 前置步骤：导出推理模型

Benchmark 使用的部署模型需要通过 tools/export.py 从训练权重导出。以 PP-LiteSeg 为例（详见 模型导出指南）：

python tools/export.py \ --config configs/pp_liteseg/pp_liteseg_stdc1_cityscapes_1024x512_scale0.5_160k.yml \ --model_path model.pdparams \ --save_dir output/inference_model

导出产物为 4 个文件，其中deploy.yaml是部署配置（含预处理 transforms、模型与参数文件名），model.pdmodel是静态图模型，model.pdiparams是参数文件：

output/inference_model ├── deploy.yaml # 部署配置文件 ├── model.pdiparams # 静态模型参数 ├── model.pdiparams.info # 附加信息（一般无需关注） └── model.pdmodel # 静态模型文件

DeployConfig（paddleseg/deploy/infer.py）在推理时会解析该 yaml：model/params属性基于 yaml 中Deploy.model、Deploy.params拼出完整路径，transforms则通过manager.TRANSFORMS注册表按type键加载预处理算子并组合为T.Compose流水线。这也是为什么推理脚本只需传入--config即可自动还原与训练一致的预处理逻辑。

若在导出或推理时遇到 shape 相关报错，官方指南建议显式指定--input_shape（如--input_shape 1 3 1024 1024）导出固定输入形状的模型。

3.2 运行 Benchmark 脚本

仓库提供了两个层级的能力：

• 常规推理：deploy/python/infer.py 面向真实预测场景，支持批处理与可选--benchmark日志；
• 专项 Benchmark：deploy/python/infer_benchmark.py 面向性能测试，固定 batch=1、可自定义 warmup/repeats，是本 Benchmark 数据的方法来源。

infer_benchmark.py的核心用法：

python deploy/python/infer_benchmark.py \ --config ./inference_model/deploy.yaml \ --image_path ./cityscapes_demo.png \ --save_dir ./output \ --use_trt True \ --precision fp32

对比infer.py，infer_benchmark.py新增了--warmup（默认 50）与--repeats（默认 100）两个参数，用于控制预热轮数与计时轮数。其run()流程为：先做 warmup 循环预热 GPU 与 TRT 引擎，再对repeats次推理计时，最后输出Average time: %.3f ms/img，同时会把预测结果以伪彩色图保存到save_dir。

3.3 关键参数速查表

以下参数同时适用于 deploy/python/infer.py 与 deploy/python/infer_benchmark.py（warmup/repeats仅后者有）：

组合使用规则（官方说明）：

• CPU 部署：--device cpu，可配--cpu_threads与--enable_mkldnn；
• GPU Naive 部署：--device gpu；
• GPU TensorRT 部署：--device gpu --use_trt True，并按需指定--precision：
  • fp32：加载常规预测模型，执行 FP32 精度；
  • fp16：加载常规预测模型，执行 FP16 精度，可加速推理；
  • int8：加载量化后的预测模型，执行 INT8 精度，可加速推理。

四、源码级原理：精度开关与动态 shape 的实现

4.1 precision 到 PrecisionType 的映射

deploy/python/infer.py 的_init_gpu_config()用一张映射表把命令行精度翻译成 Paddle Inference 的枚举：

precision_map = { "fp16": PrecisionType.Half, "fp32": PrecisionType.Float32, "int8": PrecisionType.Int8 }

开启 TRT 时调用enable_tensorrt_engine，其中workspace_size=1 << 30（1GB 工作空间）、max_batch_size=1、precision_mode=precision_mode、use_calib_mode=False。use_calib_mode=False意味着 INT8 模式要求加载的模型本身是量化导出的（而非在推理时在线校准），这与文档"int8：加载量化预测模型"的说明一致。

4.2 TRT 动态 shape：手动指定与自动调优两条路径

由于分割模型输入尺寸可变，开启 TRT 时必须提供动态 shape 信息。源码中有两条路径：

• 手动路径（默认）：set_trt_dynamic_shape_info指定min=[1,3,100,100]、max=[1,3,2000,3000]、opt=[1,3,512,1024]三组 shape。若你的图片分辨率不在该区间内，推理可能报错；
• 自动调优路径：enable_auto_tune True时，先用部分测试数据离线收集各 TRT 子图的动态 shape 范围（collect_shape_range_info写入auto_tune_tmp.pbtxt），再通过enable_tuned_tensorrt_dynamic_shape加载。这正好对应官方文档中针对报错(InvalidArgument) some trt inputs dynamic shape info not set的解决方案——遇到该错误时设置--enable_auto_tune True即可，该能力要求 Paddle >= 2.2（deploy/python/infer.py 的use_auto_tune通过hasattr检查版本兼容性）。

此外，infer.py在创建 predictor 失败时会捕获异常并提示："If the above error is '(InvalidArgument) some trt inputs dynamic shape info not set ...', please set --enable_auto_tune=True to use auto_tune."，与官方部署指南中的排障建议相互印证。

4.3 Benchmark 计时口径的实现细节

infer_benchmark.py的PredictorBenchmark.run()是计时核心：

logger.info("Warmup") for _ in range(args.warmup): self.predictor.run() logger.info("Infer") start_time = time.time() for _ in range(args.repeats): self.predictor.run() results = output_handle.copy_to_cpu() end_time = time.time() avg_time = (end_time - start_time) * 1000 / args.repeats

两次predictor.run()之间只夹了一次copy_to_cpu()（将结果拷回主机），计时区间不包含图像解码、预处理与后处理——这正是原文档"运行耗时为纯模型预测时间"的源码依据。CPU 端拷贝对 GPU 推理耗时的影响可忽略，因此该口径在 CPU/GPU 两侧均成立。

同时，脚本提供--resize_width/--resize_height参数：默认（均为 0）按原始分辨率走deploy.yaml中的 transforms；若显式设置，则会读取 yaml 的Deploy.transforms并在最前面插入一个Resize(target_size=[w,h])算子，方便在低分辨率下快速验证性能。

4.4 与 TIPC 基准测试的衔接

仓库的 TIPC（Test In PaddleCloud）体系将上述推理能力与基准测试联动：例如 test_tipc/configs/pp_liteseg_stdc1/train_infer_python.txt 中，infer 段直接调用deploy/python/infer.py并开启--benchmark:True，可输出含环境、模型、配置与性能信息的日志；而infer_benchmark_params段则给出随机输入{float32,[3,1024,1024]}用于自动化性能摸底。这说明官方既提供了本文所述的"文档级"手工 Benchmark 路径，也内置了可脚本化、可回归的性能测试通道。

五、结论与选型建议

回到这份 Benchmark，可以形成以下可执行的工程判断：

1. 先实测再选型：TensorRT 对小模型（如 UNet）可能反而变慢，务必以自身模型的实际数据为准；
2. FP16 作为默认加速选项：表中 7 个模型 FP16 相对 Naive FP32 均有可观加速（EMANet 约 3.4×），且精度损失可忽略；
3. INT8 谨慎使用：加速比与精度保持性因模型而异（DeepLabV3P 显著受益，DNLNet 无收益），且需要额外准备量化模型；
4. 动态 shape 是 TRT 部署的常见坑：优先用--enable_auto_tune自动收集，或确保输入尺寸落在手动指定的 min/max/opt 范围内。

若需深入掌握推理部署全流程，可继续阅读仓库中的 Python 推理部署指南、模型导出指南 以及推理脚本源码 deploy/python/infer.py 与 deploy/python/infer_benchmark.py。

• 人工智能
• 计算机视觉
• 预训练