简介TensorRT部署FastBEV算法实战完整项目包面向自动驾驶视觉感知方向的高校学生与开发者适合毕业设计、课程设计及算法部署入门。资源围绕BEV感知模型在TensorRT环境下的落地展开涵盖从ONNX导出、PTQ量化、TensorRT引擎构建到运行验证的完整链路并附详细设计文档与部署说明便于对照复现。压缩包共45个文件以Python脚本、C头文件与源文件、CUDA内核、Shell部署脚本等为主整体仅1.96MB轻量易下载目录明确区分src、configs、tool、ptq、demo等模块结构清晰。已有85人学习浏览对正在选型或调试TensorRT部署方案的同学具有直接参考价值。1. 第一次把 FastBEV 往 TensorRT 上搬先想清楚你要换回什么做过 BEV 感知上车的人应该都体会过那种窒息感PyTorch 里精度漂亮得很一搬到车载 Orin 或者 T4 上帧率直接掉到个位数整个感知链路被一个模型卡死。FastBEV 这类多相机 BEV 算法本来就是为“实时”设计的但实时指的是 GPU 上的理论算力不是工程上能直接用的帧率。TensorRT 部署 FastBEV 实战说白了就是把这套模型从“能跑”变成“跑得动”。这个毕设项目的价值不在算法本身而在那条完整的落地链路源码怎么组织、模型怎么从 PyTorch 变成 TensorRT engine、部署流程里哪些环节会让人翻车。适合正在做自动驾驶感知相关毕设、或者刚进车端部署团队的新人也适合那些手头有 BEV 模型但一直在用 FP32 硬扛的工程师。你拿到的是一套工程模板不是一篇调参笔记。2. FastBEV 部署链路拆解为什么 BEV 感知必须走 TensorRT2.1 FastBEV 的模块构成Backbone、视角变换与任务头FastBEV 的核心思路不复杂把多路相机的 2D 图像特征投影到统一的鸟瞰图栅格里然后在 BEV 特征图上做检测或分割。整个网络大致能切成三截。第一截是图像 Backbone负责从每路相机图像里提 2D 特征常见的是 EfficientNet、Twins 这类轻量结构。第二截是视角变换这是 BEV 算法和普通 2D 检测最大的区别所在它要把 N 路相机的特征图结合内外参投影到 BEV 栅格上。FastBEV 在这个环节做了加速设计相比原生 LSS 那套密集体素投射要轻很多。第三截是 BEV Encoder 加任务头在俯视图特征上做检测或分割。对部署工程师来说这三截的“脾气”完全不同。Backbone 是最听话的标准卷积加注意力TensorRT 支持得很顺任务头也还行无非是卷积、归一化、反卷积上采样。真正让人头疼的是中间那截视角变换——里面有栅格采样、体素池化、坐标变换这些操作落到 ONNX 里往往是 gather、scatter、grid_sample恰好是 TensorRT parser 支持得最磨人的算子。2.2 整体导出还是子网络拆分部署前的第一道选择题拿到 FastBEV 源码后第一个要做的决定不是调参而是确认导出策略。常见做法有两种把整个模型一键导出 ONNX或者拆成子网络分别导出。我一般会选择拆分理由很实际。整体导出看着省事但视角变换里的 scatter/gather 很容易在转 ONNX 时产生 TensorRT 不支持的子图一旦触发 fallback性能直接归零。而且整体模型跑一次回传梯度没有问题推理时却是纯前向很多训练代码里的分支在推理时根本走不到导出的 ONNX 里却原样保留白白增加转换失败的概率。方案优点缺点适用场景整体导出端到端一条命令部署后无需拼接自定义算子易卡壳排错难模型内无特殊算子的简单任务按子网络拆分每段可单独验证、替换、调试需要自己写前后处理拼接逻辑FastBEV 这类含视角变换的算法拆分的粒度我习惯按上面那三截来Backbone 一段、视角变换单独处理、BEV Encoder 加任务头一段。视角变换这段常见做法是分离出来用 CUDA 实现或者干脆保留在 PyTorch 里做只把 Backbone 和任务头放进 TensorRT。这样每一段都能单独跑精度对比出问题知道该查谁不会整个模型黑匣子一锅端。2.3 精度模式取舍FP16 白捡、INT8 要还TensorRT 加速最直接的来源是降低计算精度。FastBEV 的部署实践里FP16 基本上是无脑开的精度损失通常在可接受范围内推理速度却能翻一倍左右。INT8 则需要更谨慎因为 BEV 特征图是多个相机特征在栅格里累加出来的数值分布和普通 2D 特征图不太一样直接量化容易让远处的小目标消失在噪声里。精度模式速度收益精度风险工程成本FP32基线无最低FP16约 1.5~2 倍低注意大数值累加溢出低INT8约 3~4 倍高BEV 特征对量化敏感高需校准集和敏感层分析我踩过的坑是FP16 模式下 FastBEV 的检测头输出偶尔出现 NaN排查下来是视角变换里特征求和时数值过大FP16 表示不了就溢出了。解决方法是把几处大数值累加单独保留 FP32 计算其余层继续用 FP16。TensorRT 支持按层设置精度不必为了几个敏感算子牺牲全局收益。2.4 为什么是 TensorRT不是单纯快而是省出“余量”很多人问为什么不直接用 PyTorch 的 JIT 或者 ONNX Runtime我做过对比TensorRT 在 FastBEV 这种多分支、多输入的模型上优势非常明显。原因有三一是层融合卷积加偏置加激活这种小组合会被合并成单一 kernel省掉多次显存读写二是 kernel 自动调优同一个卷积 TensorRT 会在启动时跑一遍 benchmark选出当前 GPU 上最快的实现三是显存池复用推理时输入输出 buffer 复用同一块显存不会像 PyTorch 那样频繁分配释放。这个优势放到多路视频流场景里特别直观。比如用 T4 跑 1080p 25 帧的视频流分析单路模型延迟低到一定程度才能在一个 GPU 上同时塞下多路推理而不掉帧。FastBEV 在车端也一样多相机输入本身已经占了大量算力TensorRT 省下来的每一毫秒都是给其他感知模块留的余量。3. Ubuntu 下安装 TensorRT版本匹配清单与最小验证3.1 版本匹配三件套CUDA、cuDNN、TensorRT部署 FastBEV 的机器通常是 Ubuntu 20.04 或 22.04安装 TensorRT 前第一个要确认的不是 TensorRT 本身而是它和 CUDA、cuDNN 的版本匹配关系。TensorRT 是有编译期依赖的用错版本最常见的结果是运行时直接报undefined symbol或者libcudnn.so.8: cannot open shared object file。我整理过一个自己常用的匹配原则TensorRT 8.x 对应 CUDA 11.xTensorRT 10.x 对应 CUDA 12.x具体小版本以 NVIDIA 官网的兼容性表格为准。cuDNN 的版本要求更严格TensorRT 8.5 需要 cuDNN 8.6 以上但也不能无脑装最新版装成 cuDNN 9 反而可能不被识别。组件推荐版本组合示例注意事项CUDA11.8 / 12.2用nvcc -V确认不是nvidia-smi里的驱动版本cuDNN8.6 / 8.9与 TensorRT 小版本严格对应TensorRT8.6.x / 10.x优先选长期支持版本避免尝鲜PyTorch对应 CUDA 的 cu11x / cu12x与模型训练时的版本尽量一致一个常见的低级失误是把nvidia-smi显示的驱动版本当成 CUDA 版本。驱动支持高版本 CUDA 不代表你机器上装的就是那个版本FastBEV 训练时的 PyTorch 是用 CUDA 11.x 编译的TensorRT 却基于 CUDA 12.x 构建两边混用会在运行时报错。我建议先统一一个 CUDA 大版本再往上叠 PyTorch 和 TensorRT。3.2 Ubuntu 上安装 TensorRTdeb 与 pip 两条路安装 TensorRT 常见有两条路用 NVIDIA 的 apt 仓库装 deb 包或者用 pip 装 Python 版。做毕设和快速验证我通常先用 pip因为一条命令就能把 Python 接口、parser、runtime 全部装好适合在这个阶段跑通流程。# 用 pip 安装 TensorRT注意先确认本机 CUDA 版本 pip install tensorrt8.6.1 -i https://pypi.org/simple # 验证装的是哪个版本 python -c import tensorrt as trt; print(trt.__version__) # 如果要用 ONNX parser装一下 onnx 和 onnxruntime 做对照参考 pip install onnx onnxruntime-gpu这段命令里tensorrt8.6.1这个版本号要和你机器上的 CUDA 匹配装完第一件事是打印版本号确认导入成功。我遇到过 pip 装完 TensorRT 后 Python 里能导入但trtexec命令行却找不到的情况那是因为 pip 包装到的是 Python 的 site-packages命令行工具不在 PATH 里。如果后续要跑 C 接口我建议改用 NVIDIA apt 仓库装完整版 deb 包会把 include 头文件、trtexec可执行文件、libnvinfer.so都放到系统路径省去手动配置环境变量的麻烦。# NVIDIA apt 仓库方式安装 TensorRT以 Ubuntu 22.04 CUDA 12.x 为例 distribution$(. /etc/os-release; echo $ID$VERSION_ID) curl -fsSL https://developer.download.nvidia.com/compute/cuda/repos/$distribution/x86_64/cuda-keyring_1.1-1_all.deb -o cuda-keyring.deb sudo dpkg -i cuda-keyring.deb sudo apt-get update sudo apt-get install tensorrt装完后检查一下动态库路径确保/usr/lib/x86_64-linux-gnu或者 TensorRT 安装目录下的libnvinfer.so能被找到直接设环境变量是最稳的。3.3 验证安装的最小命令trtexec 跑通一个网络装完 TensorRT 后不要急着去转 FastBEV先用trtexec跑一个最小模型验证环境可用。trtexec是 TensorRT 自带的命令行工具能完成 ONNX 到 engine 的转换、性能测试、精度校验是部署流程里出场率最高的工具。# 最简单的验证用内置的 softmax 测试网络跑一遍 trtexec --onnx/path/to/test.onnx --saveEnginetest.engine # 如果还没有 ONNX 文件可以直接构造一个高斯随机输入做性能测试 trtexec --shapesinput:1x3x256x704 --fp16 --iterations100第一条命令要求手头有一个测试 ONNX第二条会在没有模型的情况下用--shapes指定虚拟输入跑一个空网络验证 TensorRT runtime 能正常初始化。这里--shapes的格式是输入名:维度维度默认是 NCHW。能看到类似[04/01/2025-10:00:00] [I] Engine built in X seconds的输出说明环境基本没问题。3.4 PyTorch 与 TensorRT 共存小心 ABI 与 CUDA 版本这个环节最后提醒一件事PyTorch 和 TensorRT 都装在同一个 Python 环境里时经常出现 CUDA runtime 版本冲突。FastBEV 训练环境如果用 PyTorch 的 cu118 预编译包它内部绑定了 CUDA 11.8 的 runtime 库而 TensorRT 若是基于 CUDA 12.x 构建的两个库同时被导入轻则警告重则崩溃。我现在的习惯是建立一个独立的 conda 环境专门放部署相关依赖把 FastBEV 源码里的训练依赖和部署依赖分开。部署环境只需要 PyTorch导出权重时要用、TensorRT、ONNX、OpenCV、numpy 这几个核心包不需要训练时的分布式依赖和数据增强库。这样即使版本打架出了错也知道是哪个环境的问题最少能让排错范围缩小一半。4. 从 PyTorch 到 Engine导出 ONNX 与构建 TensorRT 的可复现步骤4.1 导出前的输入侧对齐归一化、图像布局与多相机维度FastBEV 的输入和普通 2D 检测模型不一样它是多相机图像一起进网络的。常见代码里输入 shape 是[B, N, C, H, W]N 是相机路数。导出 ONNX 之前必须先决定怎么处理这个 N 维。我习惯把 N 折进 batch 维即把[B, N, C, H, W]reshape 成[B*N, C, H, W]让 Backbone 部分按普通 batch 处理。TensorRT 对动态 batch 的支持比对五维动态 shape 的支持成熟得多这样做能减少一个动态维度降低转换时的算子兼容性风险。代价是视角变换之前的特征要再 reshape 回五维这个 reshape 在 ONNX 里只是 view 操作TensorRT 能无缝处理。# 导出前的 wrapper把多相机输入折叠成伪 batch import torch class FastBEVDeployWrapper(torch.nn.Module): def __init__(self, model, num_cams6): super().__init__() self.model model self.num_cams num_cams def forward(self, images): # images: [B*N, C, H, W]已经在外部 reshape 好 # 内部要把伪 batch 还原成 [B, N, C, H, W] B images.shape[0] // self.num_cams imgs images.view(B, self.num_cams, *images.shape[1:]) # inter 是内外参矩阵导出时用固定值占位运行时用真实参数替换 rots, trans, intrins, post_trans self.model.get_calib_params(B) x self.model.image_backbone(imgs) x self.model.view_transformer(x, rots, trans, intrins, post_trans) x self.model.bev_encoder(x) return self.model.task_head(x) # 实例化并加载训练好的权重 deploy_model FastBEVDeployWrapper(origin_model).cuda().eval() checkpoint torch.load(fastbev.pth, map_locationcuda) deploy_model.load_state_dict(checkpoint[state_dict], strictFalse)这个 wrapper 的核心作用是剪掉训练代码里不属于推理路径的分支同时固定住内外参矩阵这些在推理时不会变化的输入。注意get_calib_params在部署时应该返回固定常量而不是像训练那样每 step 随机生成噪声。很多导出失败案例都是在这里埋的雷——训练代码里内外参可能带着 aug 参数导出时忘了关掉导致 ONNX 图里混入随机节点。4.2 导出 ONNXdynamic_axes 与 opset 的取舍输入侧对齐后就可以做 ONNX 导出了。FastBEV 部署时最常见的导出报错都集中在一个点某些算子的 opset 版本不够。grid_sample需要 opset 11 以上部分新版 PyTorch 导出的注意力算子需要 opset 13。我一般直接用 opset12 或更高反正 TensorRT 8.6 对高 opset 的支持已经很稳定。# 导出 ONNX 的核心代码 import torch dummy torch.randn(1 * 6, 3, 256, 704).cuda() # 6 路相机分辨率按训练配置 torch.onnx.export( deploy_model, # 上一步的 wrapper dummy, # 固定 shape 的假输入 fastbev.onnx, opset_version12, # 至少 11推荐 12 input_names[images], output_names[bev_det, bev_seg], # 按任务头实际输出改 dynamic_axes{ images: {0: batch}, bev_det: {0: batch}, bev_seg: {0: batch}, }, do_constant_foldingTrue, # 把 BN、常量运算折叠掉 verboseFalse, )dynamic_axes这里只给 batch 维开了动态空间维度锁死。这样做是有意的FastBEV 的图像分辨率是一个固定配置部署时不会频繁改动而 batch 维必须动态化否则没办法做多路并发推理。do_constant_foldingTrue会把推理时不会变化的计算比如归一化层里的均值方差提前算掉降低 ONNX 里的节点数量。导出后用onnx.checker做一次快速校验是个好习惯。我见过不少导出过程没有报错、但 ONNX 里有 dangling 节点的情况直接拿去 TensorRT 构建会报奇怪错误。# 用 python 快速检查 ONNX 是否完整 python -c import onnx m onnx.load(fastbev.onnx) onnx.checker.check_model(m) print(graph node count:, len(m.graph.node)) print(inputs:, [i.name for i in m.graph.input]) print(outputs:, [o.name for o in m.graph.output]) 这一步不需要额外装什么ONNX 包本身就带 checker。看到graph node count在合理范围内FastBEV 这类模型大概几百到上千个节点输入输出名符合预期再往下走。4.3 用 trtexec 构建 EngineFP16、动态 shape 与显存池ONNX 文件没问题下一步就是用trtexec构建 TensorRT engine。这一步的参数会直接影响最终性能和显存占用值得逐项说清楚。trtexec \ --onnxfastbev.onnx \ --saveEnginefastbev_fp16.engine \ --fp16 \ --minShapesimages:1x6x3x256x704 \ --optShapesimages:4x6x3x256x704 \ --maxShapesimages:8x6x3x256x704 \ --memPoolSizeworkspace:2048MiB \ --builderOptimizationLevel3这里有几个参数需要解释。--fp16开启半精度对应 2.3 节说的收益和风险。--minShapes/optShapes/maxShapes三者必须同时出现min 和 max 定义了 batch 的上下界opt 是 TensorRT 做 kernel 调优时用的参考值一般设成实际使用场景最常见的大小多路并发设 4 或 6 比较合理。--memPoolSize在 TensorRT 8.5 之后替代了旧的--workspace设的是构建时允许使用的最大显存不是运行时显存不要调太低否则某些 kernel 找不到好实现。--builderOptimizationLevel3是调优等级范围 0 到 5等级越高构建时间越长。第一次构建用 3 就行能把层融合和 kernel 选择做得很不错又不会像 5 那样等半小时。构建日志里最后会打印每种 kernel 的耗时留意有没有算子是走了CPU或者Fallback这两类出现任何一个都说明有算子没被 GPU 内核覆盖要去修。4.4 用 Python API 构建 Engine工程化的 build 函数trtexec适合验证但工程上还是建议把构建逻辑写进 Python 脚本这样能控制异常处理、能自动拼接多段子网络。FastBEV 如果是按第 2 章说的拆分了子网络每个子网络都要独自构建再用 Python 串联起来。# 用 TensorRT Python API 构建 engine 的模板函数 import tensorrt as trt def build_engine(onnx_path, engine_path, fp16True, max_batch8): logger trt.Logger(trt.Logger.WARNING) builder trt.Builder(logger) network builder.create_network(1 int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)) parser trt.OnnxParser(network, logger) with open(onnx_path, rb) as f: if not parser.parse(f.read()): for i in range(parser.num_errors): print(parser.get_error(i)) return None config builder.create_builder_config() config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE, 2 30) # 2GiB 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, min(1, 6, 3, 256, 704), opt(max_batch // 2, 6, 3, 256, 704), max(max_batch, 6, 3, 256, 704)) config.add_optimization_profile(profile) engine builder.build_serialized_network(network, config) with open(engine_path, wb) as f: f.write(engine) return engine_path这段代码里有几个细节值得注意。EXPLICIT_BATCH标志必须设置否则网络默认走隐式 batch 模式开不了动态 shape。set_memory_pool_limit的第二个参数是字节数我写2 30是 2GiB。build_serialized_network返回的是序列化后的二进制直接写文件就是部署时要加载的 engine 文件。解析错误打印用parser.get_error(i)这是排查 ONNX 转不过去的第一手资料。我见过很多人构建失败后只看到FAILED两个字就不知道怎么办了其实错误列表里往往已经写清楚了哪个算子、哪一层出了问题。构建成功后会生成fastbev_fp16.engine文件后续推理全部基于这个文件离线构建一次线上只做加载。5. FastBEV 部署避坑指南五个典型故障排查5.1 推理结果全黑或全 NaN预处理折叠与数据流错位现象engine 构建成功推理不报错但输出的 BEV 检测图全是背景分割图全黑或者直接输出 NaN。原因这个问题八成不在 TensorRT而在预处理。FastBEV 训练时输入图像通常要做归一化减均值除以方差这些操作如果被写进了 PyTorch 模型内部导出 ONNX 时do_constant_foldingTrue可能把它折叠成常量。折叠后TensorRT 这边不知道输入还需要归一化直接拿原始像素值喂了进去。另一个可能性是图像通道顺序PyTorch 训练用的是 RGB部署时读图用的 OpenCV 默认是 BGR没有转换就直接喂给了 engine。解决先把预处理从模型里拆出来让 ONNX 的输入就是“原始像素”。然后在部署代码里显式做归一化和通道转换并用同一张图分别跑 PyTorch 和 TensorRT 推理对比中间特征图。特征图对上了再往下查对不上就逐层缩窄范围。5.2 FP16 精度退化远处小目标漏检与检测头数值溢出现象FP16 engine 在测试集上 mAP 比 FP32 掉了 2 到 5 个点尤其远处的小目标明显漏检。原因我在 2.3 节说过BEV 特征和多相机特征累加相关数值范围比普通 2D 特征大。FP16 的指数位只有 5 位大数一累加就丢精度。FastBEV 的检测头里如果还有 sigmoid 或者 softmaxFP16 下这些非线性函数的导数区域会变窄输出概率分布被压平小目标就没了。解决TensorRT 支持按层设置精度。先跑一遍层级 profiling找出精度退化贡献最大的几个层把它们单独设成 FP32。操作上可以在构建时遍历网络层对特定名字的层调用layer.precision trt.float32并设置set_output_type。工程上我习惯先无脑全 FP16 跑一遍再对检测头和视角变换里的 reduce 层单独提精度通常能把掉点控制在 1% 以内。5.3 grid_sample 算子不支持parser 版本与 fallback 陷阱现象构建时日志显示某个算子not supported或者整个子图被标记 fallback推理速度骤降。原因FastBEV 的视角变换如果用到了grid_sampleONNX 里对应的是GridSample节点。TensorRT 8.4 之前对 grid_sample 的支持不完整三线性插值和 padding mode 的某些组合会直接拒绝。另外PyTorch 新版导出的 grid_sample 可能带align_corners属性旧版 TensorRT parser 不认。解决先升级 TensorRT 到 8.6 以上绝大多数 grid_sample 问题都能解决。如果还在报错检查导出的 ONNX 里GridSample节点的属性modebilinear、padding_modezeros、align_cornersFalse是最稳的组合。再不行就要自己写 plugin 或者在 CUDA 层面实现采样逻辑这也是最初建议子网络拆分的原因——视角变换拆出来单独处理就不会让整个 engine 构建失败。5.4 动态 Batch 显存暴涨optShapes 与池化策略现象启动时显存占用正常一旦推理 batch 从 1 切到 4显存突然翻了好几倍甚至直接 OOM。原因TensorRT 构建时预留的显存池和 kernel 选择依赖optShapesoptShapes设多大显存池就可能按多大预留。如果optShapes设了 batch 8但实际只跑 batch 1引擎占用的显存并不会按 batch 1 收缩。另一个原因是动态 shape 下 TensorRT 会为不同 shape 保留多个 kernel 实例batch 跨度越大中间产物越多。解决optShapes设成实际使用的最常见 batch。如果既想支持大 batch 又不希望常驻显存太高就把 maxShapes 设成略高于实际需求的值而不是往上无脑拉。运行时如果发现显存紧张优先检查--memPoolSize是否设得过大2GiB 够用就不用给 4GiB。5.5 反复推理显存泄漏binding 复用与缓存策略现象单次推理没问题连续跑几百帧后显存占用缓慢爬升最终CUDA Out Of Memory。原因最常见的原因是推理代码在循环里反复调用torch.cuda.empty_cache()或者每次推理都重新分配输入输出 buffer。TensorRT 推理本身不会泄漏显存泄漏的是调用方没有正确复用 binding。解决在加载 engine 后一次性创建所有 binding 对应的显存 buffer推理循环里只做copy_htod和copy_dtoh不新建张量。我习惯在推理代码里加一个固定 buffer 池输入输出都从池子里取跑完放回。加一个显存统计打印连续推理 200 帧后确认显存曲线是平的才算过这一关。# 推理时复用 buffer 的核心逻辑 import tensorrt as trt import pycuda.driver as cuda engine load_engine(fastbev_fp16.engine) context engine.create_execution_context() # 创建持久化的输入输出 buffer d_input cuda.mem_alloc(1 * 6 * 3 * 256 * 704 * 4) d_output cuda.mem_alloc(1 * 200 * 256 * 704 * 4) h_input np.zeros((6, 3, 256, 704), dtypenp.float32) h_output np.zeros((200, 256, 704), dtypenp.float32) for frame in video_stream: # 只做拷贝不重新分配 cuda.memcpy_htod(d_input, preprocess(frame)) context.execute_v2([int(d_input), int(d_output)]) cuda.memcpy_dtoh(h_output, d_output)这里execute_v2接收的是 binding 地址列表TensorRT 8.x 里推荐用它替代旧的execute。注意输入输出 buffer 一次性分配后循环复用这既是性能优化手段也是规避显存泄漏的正确姿势。6. 把 Engine 推到多路并发吞吐压测与精度回归整个部署流程跑通后最后一步不是直接发版而是做两件事压测吞吐和回归精度。吞吐压测的方法很简单先让 engine 预热 50 帧把 kernel autotune 和 CUDA context 初始化完成然后连续推理 300 帧记录每一帧的延迟取 P99 而不是平均值——平均值会被偶尔的调度抖动拉低P99 才是用户能感受到的最差情况。# 用 trtexec 直接做性能压测输出 P50/P90/P99 延迟 trtexec \ --loadEnginefastbev_fp16.engine \ --shapesimages:4x6x3x256x704 \ --streams4 \ --iterations300 \ --warmup50--streams4模拟 4 路并发推理--warmup50跳过前 50 帧的初始化不稳定期。压测得到的 P99 延迟乘以并发路数就能预估一张卡能撑起多少路视频流。精度回归则拿一套固定的测试场景对比 FP32 引擎和 FP16/INT8 引擎的检测 mAP注意保持输入完全相同不要一边归一化一边没归一化。我自己的教训是第一次把 FP16 engine 丢上车时只看平均帧率没看 P99结果颠簸路段直接掉帧后来养成了每次构建引擎先压 300 帧看延迟曲线的习惯。这个工程做完了性能和精度都有了数字依据才敢说这套部署流程真的落地了。FastBEV 是好算法但把它变成稳定上车的引擎靠的是这些不亮眼却关键的收尾动作。希望帮到你。从 FastBEV 整体导出到多路并发压测我踩过的坑基本都在这里了。这套从环境搭建开始的流程你按着走一遍比对着博客碎片拼凑要省下至少两三个通宵。本文还有配套的精品资源点击获取
示例详解)
