TensorRT部署实战：YOLO转ONNX到推理加速的五大避坑指南

第一次听说TensorRT，大多数人都是从同一句话开始的：它能让你YOLO推理速度直接翻倍。这句话本身没毛病，但我见过太多入门的朋友，不是败在模型性能上，而是败在环境报错、算子不支持、engine序列化失败这一串连环坑上。

本篇文章专门写给刚接触TensorRT的小白。我会结合最近带一个项目把yolo12转成ONNX再转TensorRT、用C++写推理测试的实际经历（测试环境是RTX 5070显卡），把最容易踩的五个坑一次讲透。内容不绕弯子，直接给结论、给排查思路、给可抄作业的命令和代码。如果你正打算在Windows或Linux上用TensorRT部署一个检测模型，这篇应该能帮你少走半个月弯路。

1. 入门TensorRT前，先把环境这颗雷排掉

1.1 版本地狱：CUDA、cuDNN、TensorRT三者的“锁链关系”

TensorRT不是独立工作的，它必须和CUDA、cuDNN配套使用，但这里面的坑在于：不是你随便装一个最新CUDA就能跑最新TensorRT。官方每个TensorRT版本都对应着经过验证的CUDA和cuDNN版本组合，三者的关系就像锁链一样，一环配错，编译的时候可能不报错，但运行时直接给你一个“Error: invalid device buffer”之类的模糊信息，或者干脆加载engine时崩溃。

我见过一个最典型的案例：用户机器上装的是CUDA 11.8，他下载了TensorRT 10.x的tar包，编译也没问题，但一跑就报failed to load library libcudnn.so.9。原因就是TensorRT 10.x内部依赖cuDNN 9.x，而他的CUDA 11.8安装包默认带的cuDNN是8.x，两者编号对不上，后续所有操作全卡住。

所以入门第一步不要凭感觉装。动手之前，先确认三件事：

• 显卡驱动支持的CUDA版本：运行nvidia-smi看右上角的CUDA Version，这个数字是驱动的上限，必须大于等于你要装的CUDA版本。
• 目标TensorRT版本对应的CUDA/cuDNN组合：直接去官方文档里的“TensorRT Support Matrix”表格查，不要相信网上任何二手信息，官方表会随版本更新，我甚至见过不少人因为参考了旧帖导致装错的。
• 现有Python环境和打包工具链（如果走pip安装）：确认python -m pip可用，且系统PATH里没有多个CUDA版本混乱的情况。

在RTX 5070这类新卡上更要注意：50系是Blackwell架构，官方推荐的CUDA版本至少是12.8环境起步，TensorRT版本也要用已经支持Blackwell的较新版本（比如10.x以上）。如果你拿一个很老的TensorRT 8.x去跑，驱动可能直接拒绝初始化上下文，很可能提示“no kernel image is available”，就是老版本TensorRT内置SASS不认新架构。

1.2 小白最省事的安装路线：容器镜像和本机安装选哪个

安装TensorRT有三条主流路线：官方Docker容器镜像、deb/rpm包、tar包或pip包。我给小白的建议是：如果你只是做实验和验证性能，优先用官方Docker镜像；如果你要配合自己的C++工程长期开发，再考虑本机安装。

选容器镜像唯一要记住的是：镜像标签里写明了CUDA版本，比如nvcr.io/nvidia/tensorrt:24.05-py3这类镜像内部已经配好了TensorRT所需的完整环境，你拉下来就少踩八成环境坑。缺点也有，就是Windows下Docker在GPU透传上偶尔会有兼容性问题，如果你用WSL2，一般问题不大。

本机安装时，我建议按“deb包优先”的顺序走：deb包会把TensorRT的头文件、库文件、trtexec工具一次性放进系统目录，编译时直接用-ltensorrt就好。tar包和pip包更适合不想动系统环境的场景，但后续配置环境变量容易出问题。以我测试的DGX/个人机经验来看，最干净的组合是：

• 系统：Ubuntu 22.04（Windows下用WSL2也行）
• 驱动：550+（50系需要更新版驱动）
• CUDA：12.8（或官方支持矩阵中对应的版本）
• cuDNN：9.x（配合TensorRT 10.x）
• TensorRT：10.x

装完先不要急着转模型，跑一句验证：

python -c "import tensorrt as trt; print(trt.__version__)"

如果能正常打印版本号，说明Python API部分没问题；再运行trtexec --version确认命令行工具可用，然后才开始下一步。这一步能筛掉90%的环境问题。

2. 模型从PyTorch到ONNX，99%的问题都出在导出这一步

2.1 ONNX导出时的三个隐藏开关

很多人以为torch.onnx.export就是一句简单代码，其实里面藏着三个直接影响TensorRT能否成功解析的开关。

第一个是opset_version。TensorRT对ONNX算子版本有支持范围，太新的opset里可能暗示着某些新算子它还没实现，太旧的又可能让某些高级算子无法表达。经验值是：TensorRT 10.x配合opset 17到19都可以，yolo12这种偏新的模型建议直接选17以上。记住选完opset后要在TensorRT里实测，不要盲目追新。

第二个是dynamic_axes。如果你导出时不给模型指定动态维度，转出来的ONNX就会把输入shape写成固定的[1, 3, 640, 640]，之后engine只能在这一个shape下跑。问题是部署时你大概率需要不同batch或者不同分辨率，所以每个涉及动态的维度都要显式声明。我见过只声明了batch维度、没声明宽高维度的人，后端加一个resize逻辑反而把推理变慢了。

第三个是do_constant_folding。pytorch导出时默认会做一部分常量折叠，把一些计算提前算好。这个开关通常保持默认开启，但如果你的模型结构里有对输入动态信息敏感的算子（比如某些坐标生成类算子用了torch.arange根据输入shape动态生成），常量折叠可能会把不该提前算的东西算死，导致输出的onnx行为异常。我习惯的做法是：导出后先用onnxruntime跑一遍onnx，比对和pytorch输出的数值差异，差异超过1e-3就要回头检查是不是这个开关引起的。

2.2 算子不支持怎么办：以yolo12的DCN为例

ONNX导出成功不等于TensorRT能解析。yolo12这个模型里很典型的一个坑，就是backbone里带的可变形卷积相关算子（DCNv2/DCNv3）在TensorRT全系列默认插件里不是都直接支持的。我实际测试的时候，用trtexec直接转yolo12导出的onnx，第一轮就在DCN相关节点上报“Unsupported operator”或者直接找不到对应plugin。

遇到这种情况，不要立刻慌，更不要马上放弃这个模型。处理路线按优先级排列：

• 路线一：检查有没有官方或者第三方提供对应的TensorRT plugin。很多视觉模型用到的算子社区已经写过现成插件了，编译进去就能用。但注意插件版本要和TensorRT主版本严格对应，10.x编译出来的插件在8.x上基本不能直接用。
• 路线二：改导出策略。如果这个算子只在训练阶段有用，或者可以用等效算子替换，就导出时做替换。比如某些DCN在推理时如果用普通卷积加修正能接近效果，那就直接导出成普通卷积。
• 路线三：用onnx-simplifier做简化，有时候一些多余的结构化算子简化后会被合并，间接绕开不支持节点。但这招对DCN类算子的成功率不高，因为问题不是效率而是没有实现。
• 路线四：不换模型结构，把onnx里的DCN节点写成自定义plugin。这是终极方案，工程量大，不建议小白入门阶段碰。

如果你跑的是仓库里官方已经转好的onnx（很多人喜欢直接下载别人放出来的模型文件），也要自己用工具过一遍，别轻信“已经转好了”这句话。我拿到手的第一时间都会用polygraphy检查算子覆盖情况。

2.3 导出后先做“体检”，别急着转engine

我强烈建议在进入TensorRT流程前，先给onnx做一个“体检”。体检工具我用得最多的是polygraphy，它是NVIDIA官方维护的，功能很强大，但你不用全会，只要会用两条命令就行。

第一条，检查onnx里有哪些算子可能是TensorRT不支持的：

polygraphy run model.onnx --trt --trt-min-shape input:[1,3,640,640] --trt-opt-shape input:[1,3,640,640] --trt-max-shape input:[1,3,640,640]

它会在构建engine的过程中把不支持算子打印出来。如果报错信息里有Unsupported Layer，基本就定位了问题节点。

第二条，检查onnx本身的输出是否正确。如果这边都错了，后面再怎么优化也白搭：

polygraphy run model.onnx --onnxrt --save-outputs onnx_outputs.json

然后用polygraphy run model.onnx --trt --load-outputs onnx_outputs.json对比TensorRT和onnxruntime的数值差异。

体检这步看似多花了时间，其实是在给你省时间。我见过太多人跳过这个步骤，辛辛苦苦把engine建好，最后推理结果全是乱框，回头排查才发现onnx导出的时候输出节点就少了几个。这个阶段多花十分钟，能帮你省下后面整整一天的排查时间。

3. 精度掉点惊掉下巴？FP16和INT8都要讲方法

3.1 先搞清楚“模型精度”和“推理精度”的区别

很多小白在TensorRT里听到“精度”两个字就混成一团，其实这里有两层完全不同的概念。

第一层是模型本身在训练集上的能力，叫模型精度，比如YOLO的mAP，这个由你的训练数据和训练策略决定，TensorRT再怎么折腾也不会提升它。第二层是TensorRT用低精度表示（FP16、INT8）时数值近似带来的精度损失，叫推理精度，这个是TensorRT优化带来的副作用。

这两层之间有换算关系：TensorRT做低精度推理时，模型输出的坐标、置信度会发生微小偏移，再经过NMS等后处理，最终检测效果可能掉一点。但你测的时候要用“目标指标”来评估，比如YOLO模型就用COCO mAP（或你这个任务的mAP），不要只看某个输出张量的平均绝对误差。平均绝对误差很小，但可能导致边界框坐标偏移了一两个像素，对严格任务来说就是致命；反过来，误差看似大，但NMS之后框的位置基本没变，那就不用纠结。

我常用的评估套路是：先用同一条测试集跑FP32的onnx模型作为基线，再跑FP16/TensorRT，然后对比两张结果表上的mAP或者Rec@0.5之类的核心指标。如果指标掉得小于0.5%，多数场景可以直接用；如果大于1%，就要警惕了。

3.2 FP16加速的底线在哪里

FP16是小白最常用的加速配置，毕竟一条trtexec --fp16就完事。但FP16会损失精度，主要原因是FP16只有5位指数位和10位尾数位，表示很大或很小的数值时容易出现舍入误差。

对YOLO类检测模型来说，输入图像的归一化值本来就比较小，经过网络浅层后中间特征图大多在一个合理的数值范围内，FP16通常不会出现灾难性掉点。我实测yolo系列在TensorRT FP16下，mAP相对FP32的下降基本在0.2%以内，几乎可以忽略。但如果你的模型里包含了大范围的注意力权重，或者有些头的输出值接近阈值边界，FP16就可能让本不该超过阈值的输出变成超过阈值，导致大量误检。

实操上两个建议：

• 不要直接在整引擎上开FP16，可以先让TensorRT自动安排各层精度，用--precision=FP16配合--stronglyTyped（较新版本才支持）来约束关键层保持FP32运行。
• 如果必须整引擎FP16，且掉点明显，就从输入归一化开始修正。很多模型FP16掉点严重是因为输入数据没有先缩放到[0,1]区间，而是保持了[0,255]的大数值，导致第一层卷积数值就超出FP16合适范围。我的习惯是无论图省事还是为了最佳精度，都把/255归一化放到网络里处理，这样输入读到引擎的是0到255的uint8或float32，由引擎内部第一步去scale，而不是拿到外面手动除以255。

3.3 INT8量化：校准集选不好，模型直接“变傻”

FP16基本是安全性能加速，INT8则是性能顶尖但需要更多操作。INT8推理速度确实快，尤其对50系这类新架构，Tensor Core对INT8的吞吐比FP16更高。但代价是，你必须给量化过程提供合适的校准数据集（calibration data）。

这个坑是小白最容易翻车的重灾区。校准数据的作用，是在离线阶段统计每一层激活值的分布，从而决定量化时用的缩放因子。如果你给的是纯背景图、或者全是白天街景图，模型在真实场景里就可能全部输出“烂框”。原理很好理解：校准集代表的是你期望模型看到的输入分布，如果校准集里没有目标物体，那么激活值分布就根本没有覆盖到目标出现时的情况，量化后目标信息全部被压没了。

合格的校准集不需要大，通常500到1000张就够，但必须满足三点：

• 图像内容与目标场景一致，做交通检测就用真实道路数据，别用办公室照片。
• 图像中必须包含模型关心的目标，最好每张都有不同scale、不同位置的目标。
• 采样要均匀，避免全部是同一时间段、同一地点的相似图。

校准偏差的修复成本其实不小，所以我建议小白在入门阶段先用FP16，踩熟了部署流程后，再回来研究INT8。INT8适合模型量大、硬件资源有限的工程化场景，但前提是你要愿意花时间做数据准备和评估。

4. engine文件玄学多，序列化与推理代码都要踩稳

4.1 engine是“一次性”产品：绑卡绑版本

很多小白第一次看到.engine文件以为就像pt模型一样到处能用，这是天大的误解。engine文件和你的GPU架构、TensorRT版本、CUDA版本、甚至具体某个优化flag是绑定的。你在自己机器上生成的engine，拷贝到同事同型号显卡但有不同TensorRT版本的机器，十有八九直接加载失败，报错信息是Unsupported engine或者Engine could not be deserialized。

这个特性和PyTorch模型完全不同。PyTorch的torch.save是把模型结构和参数打包，在新环境反序列化重建即可；engine文件则是NVIDIA针对你当前硬件的特定优化产物，里面记录的kernel基线全部指向具体GPU架构的SM版本。所以部署流程要改成：engine在目标机器上现场生成，或者带上生成环境，不要在跨环境复制上费劲。

处理方法也有两条路：一是目标机器第一次启动时延迟生成engine，然后缓存到本地指定目录，之后启动直接加载；二是把engine生成放成一个独立的部署步骤，确保每台机器生成一次。无论哪条路，都要在代码里检查engine文件是否存在，不存在就触发build。

4.2 C++推理的最小骨架与显存生命周期管理

接下来是最容易让小白崩溃的C++代码环节。TensorRT的C++ API虽然功能强大，但抽象层次低，每一步都要你手动管好资源。拿yolo12的部署来说，至少要经历这几步：创建builder、创建network、用onnx parser解析模型、设置config、构建engine、创建context、分配host和device内存、拷贝输入、执行推理、同步结果、后处理。中间任何一个对象忘了释放，轻则内存泄漏，重则程序崩溃。

先给一个最小骨架上，关键点我用注释标出来：

// 1. 创建logger和builder（注意logger必须在engine整个生命周期存活） nvinfer1::ILogger* logger = new MyLogger(); nvinfer1::IBuilder* builder = nvinfer1::createInferBuilder(*logger); // 2. 创建network（kEXPLICIT_BATCH表示显式指定batch） uint32_t flag = 1U << static_cast<uint32_t>(nvinfer1::NetworkDefinitionCreationFlag::kEXPLICIT_BATCH); nvinfer1::INetworkDefinition* network = builder->createNetworkV2(flag); // 3. 用parser加载onnx nvonnxparser::IParser* parser = nvonnxparser::createParser(*network, *logger); parser->parseFromFile("yolo12.onnx", 1); // 4. 创建config并设置精度 nvinfer1::IBuilderConfig* config = builder->createBuilderConfig(); config->setFlag(nvinfer1::BuilderFlag::kFP16); // 5. 构建engine，这个build过程在1070上可能要几分钟，5070上明显快很多 nvinfer1::IHostMemory* serialized = builder->buildSerializedNetwork(*network, *config); // 6. 反序列化得到runtime和engine nvinfer1::IRuntime* runtime = nvinfer1::createInferRuntime(*logger); nvinfer1::ICudaEngine* engine = runtime->deserializeCudaEngine(serialized->data(), serialized->size()); // 7. 创建context，后面通过enqueueV3执行 nvinfer1::IExecutionContext* context = engine->createExecutionContext();

注意这里用的enqueueV3是较新版本TensorRT的API，它把IO绑定到IOLayer上，比老版本enqueueV2灵活很多，但第一步你需要调用context->setInputShape为输入指定形状（对应动态shape场景），然后通过context->setTensorAddress绑定输入输出buffer地址。这个改动很多人不习惯，因为它把内存绑定复杂度推给了开发者，但换来的是动态shape下的高效推理。

显存生命周期管理上，我最深的体会是：把host内存和device内存的分配/释放写在一个单独的类或函数里，而不是散落在推理循环各处。我以前在循环里每次调用前分配cudaMalloc，推理后再cudaFree，看起来像是在“确保干净”，实际上一方面反复分配开销极大，拖慢整体帧率；另一方面如果中间任何一步异常，device内存就泄漏了。正确做法是初始化阶段分配最大尺寸的device buffer，推理循环里只做数据拷贝和kernel执行，只有动态shape发生变化时才重新分配。

4.3 序列化engine后加载失败的根源

建造engine很耗时，所以在正式项目里，你肯定希望只构建一次，之后直接用std::ofstream写入二进制文件，加载的时候用std::ifstream读入内存再反序列化。这本身没毛病，我见过加载失败的案例基本都是这几个原因：

• 文件读成文本模式而不是二进制模式。Windows下尤其容易踩，忘记加std::ios::binary标志，导致读入的数据中间被错误解释。
• 反序列化的runtime和构建engine的runtime不是同一个版本。你昨天用10.x生成的engine，今天升级到10.x补丁版，可能还好；但跨小版本有时候也会崩。
• 加载engine的设备和构建engine的设备不一致，比如你在一台A100上构建，拿回自己的5070上加载，肯定失败。
• 读取文件时没有完整读入内存。有人图省事直接读取文件size作为buffer大小，但文件size并不一定等于你要传给反序列化的engine大小，因为可能有文件头或其他元数据，正确的做法是读取实际字节数。

推荐做法：写一个loadEngineFromFile函数，用std::ifstream以binary模式打开文件，用std::vector<char>完整读入，再传给runtime->deserializeCudaEngine。如果加载失败，不要怀疑函数写法，先查环境和设备一致性。

5. 速度没起飞？先查这三个性能瓶颈

5.1 workspace和优化策略：别让TensorRT“施展不开”

很多新手说“我明明加了FP16，为什么速度跟没加一样？”如果模型结构比较简单，比如一个小分类网络，瓶颈可能根本不在推理kernel上，而在数据复制和调用开销上。但如果你用的是yolo12这种稍大的模型，速度上不去的常见原因之一就是workspace设得不够。

TensorRT在构建engine时，会为层融合、内存复用申请一个workspace空间。如果你的setMemoryPoolLimit设得太小，比如默认几十MB，TensorRT就不得不放弃很多优化机会，比如算子融合后会占用更多中间显存，放不下就只能退回不融合的方案。尤其对动态shape模型，优化器需要一个更大的搜索空间，workspace直接影响融合的效果。

config->setMemoryPoolLimit(nvinfer1::MemoryPoolType::kWORKSPACE, 1 << 30); // 1GB

在RTX 5070这种12GB或更高显存的卡上，建议至少给1GB，不要吝啬。workspace只影响构建期规划，不是运行时独占，不用担心它把显存吃光。真正运行时显存占用取决于实际激活值和buffer大小，workspace只是给构建优化用的“设计稿”。

5.2 动态shape的profile到底该怎么配

如果你的模型导出了动态shape，不配profile，TensorRT根本不知道你要跑哪些形状，会直接报错。profile的含义是：给定输入shape的范围，从最小到最大，以及最常见的最优shape，TensorRT会为这三个位置分别做优化选择。

配置profile时最容易犯的错误是：把min、opt、max三个值设得过于保守，比如都是[1,3,640,640]，这是你测试时的shape，但后面线上实际输入可能变成[1,3,1280,1280]，就会触发重新优化或者直接拒绝执行。反过来，如果把范围设太大，从[1,3,320,320]到[1,3,1280,1280]，TensorRT要为中间所有可能的shape留优化余量，engine体积和构建时间都会明显增加，而且在某些shape组合下性能不一定是全局最优。

我的建议配置方式是：先明确业务中实际会用到的shape集合，把它变成profile参数。比如你只需跑640分辨率的检测，完全可以把min、opt、max都设为640，这样engine只在640这个点上往死里优化，速度最快，engine也最小。如果你确实需要batch从1到8动态变化，可以把batch设为动态，宽高固定为640；如果还要支持不同分辨率输入，那就只能接受一定的性能折中。

5.3 CPU预处理在拖后腿：把归一化塞进网络里

很多人在TensorRT上精益求精，把每个算子的耗时都榨干了，最后测总延时却发现模型推理只占了40%，剩下的都在图像预处理和后处理上。对YOLO类模型来说，预处理里的resize、letterbox、归一化、BGR转RGB每一步都有讲究。

其中最容易被忽略的是归一化位置。常规PyTorch推理代码里，你会对输入图像做img / 255.0，在TensorRT部署时如果还是硬编码在运行前CPU循环里，相当于每个batch都要触碰一次完整图像数据，很拖时间。正确做法是把这个归一化融合到网络结构里，或者在预处理阶段直接对图像应用缩放因子。

具体来说，我们可以在模型导出时，在输入后面加一个scale层，把网络输入变成[0,255]范围内的uint8数据（或float），然后在网络内部第一步做除以255的操作。这样做的好处是：数据从host拷贝到device时是原始图像字节，少一次GPU内存上的逐像素运算。实测下来对1080p图像，单帧预处理时间能省下1到2毫秒。yolo12导出时很多人也会遇到类似问题，我的建议是检查一下你是否可以修改导出脚本的预处理，不要图省事直接用默认代码。

后处理也是一个大坑。YOLO输出的是一个包含大量预测框的二维张量，NMS这一步如果用CPU做，且没有经过任何向量化优化，在较大输入尺寸下会成为新的瓶颈。小白先不用追求极致的NMS加速，但至少要记住：后处理时间要单独统计，不要以为“推理时间=整个程序时间”。如果检测到端到端速度不达标，先拆解时间分布再定位瓶颈，别盲改推理参数。

6. 常见问题速查表与调试经验

6.1 小白高频报错速查表

为了让你在实际操作时能快速定位，我把自己和同事遇到过的典型报错整理成一张速查表：

这张表不能覆盖所有问题，但覆盖了80%刚上手会碰到的类型。遇到问题先查表，再考虑是不是自己环境装错了。当然也别漏掉一个最常见的错误——输入数据格式不对：OpenCV读出来是BGR，而你导出模型时假设的是RGB，这个问题能让你的模型输出全部乱套，但代码和engine却不会有任何报错。

6.2 终极调试顺序：先trtexec，再写代码

我最后想分享一个实战顺序，这是我自己带项目时总结出来的、也是带过几个新人后最想强调的流程：先命令行，再写代码。

很多小白一上来就写C++代码，把builder、parser、engine、context全部串起来，结果报错后根本不知道是哪一步出问题。其实官方自带的trtexec就是最好的调试工具，它帮你封装了完整流程。拿到一个onnx，先跑一遍：

trtexec --onnx=yolo12.onnx --saveEngine=yolo12.engine --fp16

这个命令能帮你验证：模型能否解析、能否构建engine、FP32/FP16下推理延时多少、显卡利用率多高。如果这一步没通过，说明问题在模型或环境，不是你代码的问题，回退到前面几章检查。如果通过了，再去写自己的C++代码，而且代码里的配置参数尽量与trtexec保持一致，比如同样的FP16 flag、同样的workspace大小。

用trtexec测试RTX 5070上yolo12 onnx的速度有一个小提醒：trtexec给出的延时是纯GPU推理时间，不包括预处理和后处理，它只是kernel执行时间，不要拿它当端到端延迟对外汇报，否则上线后会差不少。

6.3 用5070显卡实测后的几个体会

项目从头到尾在RTX 5070上跑yolo12的onnx转TensorRT，有几个感受直接分享给准备入门的朋友。

新卡对老版本CUDA/TensorRT的兼容性确实不友好，一开始我拿手头现成的TensorRT 8.6去跑，直接黑屏重启级别的问题，后来升级到配套版本才正常。所以如果你用50系显卡，务必确保驱动、CUDA、TensorRT三者都是同一时期发布的版本组合，不要图省事拿旧环境硬上。

另一个体会是5070的Tensor Core对FP16和INT8的加速量确实给力，yolo12在640分辨率下用FP16跑一轮的kernel延时比我预期的低不少，但前提是模型能正常转换、精度不掉点。很多性能指标都是“纸面参数”，单看显卡算力并不能代表TensorRT实际转换后的性能，还是要动手跑一遍。

最后再说一个隐藏但非常重要的点：TensorRT构建engine时需要一些临时内存，你的显卡显存如果同时被别的进程占用，build过程中可能因为显存不够而报错。跑TensorRT之前把其他大显存占用的程序（比如浏览器GPU加速、其它训练进程）关掉，会少很多莫名其妙的问题。我就是因为开着好几个浏览器页面和另外一个训练任务，导致build阶段总是报“could not allocate memory”，关掉之后一次通过。

如果让我对刚入门的朋友说一句总结性的话，那就是：TensorRT本身并不难，难的是环境、模型导出、精度、显存这四件事之间互相牵连。你只要把环境版本对齐、模型导出规范、先trtexec验证、再写代码部署，这条路就会顺畅很多。这套流程我已经带过几批新人，基本都能在一到两周内跑通自己的第一个检测模型。希望这篇经验也能让你的入门流程直线化，少踩几个我已经替你踩过的坑。