Phase 3：部署深挖（你的护城河，贯穿全程）

用大白话说：这一页帮你搞懂「模型怎么跑得更快，又不会看漏东西」。

打个比方。模型是工人，GPU（说人话：专门跑 AI 计算的显卡）是工厂。这一页要教你两件事：怎么让工人干活更利索，怎么让工厂同时接好几条流水线。

你要吃透三块：量化（说人话：把模型「减肥」，好让显卡跑更快）的道理、TensorRT（说人话：英伟达出的「模型加速器」，把模型改装成显卡最爱吃的形状）的内部、还有多路视频一起跑。这是你已经有手感、市场上又最缺人的方向。Phase 0 的系统解剖，加上这一页，就凑齐了「视觉部署工程师」的核心本事。

一、量化理论（你前面 INT8 漏检的底层）

先说人话。量化就像把一张高清图压成小图：文件变小、加载变快，但细节会糊。模型也一样——数字位数用少了，跑得快，可小目标就容易看丢。下面这几个词，就是压缩时的不同玩法。

PTQ（训练后量化）（说人话：模型练完了再压缩）：直接量化，靠一批样本（叫校准集）来定压缩的档位（scale）。好处是快。坏处就是你 VisDrone 漏检踩的那个坑。
QAT（量化感知训练）（说人话：一边练一边先适应压缩）：训练时就假装被压缩了，让模型提前习惯低精度。这样召回率能拉回来，接近 FP16 的水平。
校准（说人话：拿一批样本试试水，定压缩档位）：entropy（KL 散度）这种算法一般比 minmax 更适合做检测。minmax 容易被个别极端数值带跑偏。
精度粒度（说人话：一刀切还是分开定档）：per-tensor 是整层共用一个 scale；per-channel 是每个通道单独一个 scale，更准。
INT8 / FP16 / INT4：FP16（说人话：中等精度，又快又不太丢精度）几乎不掉点，能快约 2 倍；INT8（说人话：用很少的数字位来算，快但容易丢细节）再快 2–4 倍，但小目标容易漏；INT4 掉点很明显，你要谨慎用。

回顾一下你踩过的坑：你校准时用的是训练集，这一步没做错。可 VisDrone 的小目标还是漏检。为什么？因为 INT8 能表示的数值范围就那么窄，装不下那些很微弱的信号。这是它天生的毛病，不是你选错了校准集。换校准集救不回来。你只有三条路：混合精度、QAT，或者干脆退回 FP16。

🔧 混合精度（保召回的关键）

说人话：不用全身减肥，只给不重要的部位减。

具体做法是：backbone 和 neck（模型前半段，负责「看」）走 INT8，检测 head（最后下判断那一段）留 FP16。 Ultralytics 里那一行 int8=True 是整个网络一起压，它没给你逐层开关。你要精细控制，就得自己写 TensorRT 的 build 流程，在 ONNX 阶段用 precision_constraints=obey 把敏感的层标出来。对 VisDrone 这类小目标任务，这是我们能找到的最稳的折中办法。

二、TensorRT 内部（从「会 export」到「懂 builder」）

大白话：以前你只会喊一句「帮我转成 engine」，现在要搞懂它转的时候到底在干嘛。你可以把 TensorRT 想成一个改装车间——你把模型开进去，它按你给的要求改装成最适合这块显卡的样子。

builder / network / config（说人话：车间、图纸、改装要求）：先定义网络结构，再配置精度和 profile，最后构建出 engine（改装完的成品）。
optimization profile（说人话：提前告诉它输入会有多大变化）：动态 shape 的范围声明，就是你写 batch=[1,2,4,8] 那种。
动态 vs 静态 shape（说人话：尺寸会变 vs 尺寸固定）：实时流的分辨率如果是固定的，你就把 dynamic 关掉。尺寸定死了，TensorRT 能挑到更快的算法。
plugin（说人话：外挂零件）：EfficientNMS 这个插件让 NMS（筛掉重复框的步骤）在 GPU 上做完，别再退回 CPU 绕一圈。
CUDA Graphs（说人话：把一整套动作录下来，下次一键重放）：把整段推理「录」成一张图，能省下 10–30% 的启动开销。单张图（batch=1）要压低延迟时，这招很关键。
workspace（说人话：给它一块草稿纸）：给 2–4GB，让它有地方试各种方案、挑出最快的那个。

这条特别容易翻车：engine 是跟 GPU 型号 + TensorRT 版本绑死的。所以你必须在真正要跑的那台机器上重新 build 一遍。别在自己电脑上转好，拷到服务器就想用——跑不起来。

三、三格式实测（用你 model-TensorRT.py）

光讲道理没用，你得自己跑一遍，用数字说话。下面这张表是你要填的答卷。

用哪种格式	跑一帧要多久	准不准（mAP）	你要注意什么
.pt FP16	基线	基线	你现在的默认
FP16.engine	~2× 快	≈ 基线	必做，几乎无损
INT8.engine	再 2–4×	小目标掉	需同域校准 + 回测

顺序你别搞反了。先上 FP16，确认一点不掉；再试 INT8，用同一个场景的数据做校准，然后回头测一遍准确率；一旦发现掉点，就上混合精度，或者老老实实退回 FP16。

四、多路并发（你系统的真瓶颈）

这一节是你系统现在最堵的地方。一路视频跑得动，好几路一起上就卡——问题多半不在模型，而在「谁在干活、谁在排队」。

NVDEC / NVENC（说人话：显卡自带的视频解码器 / 编码器）：让显卡去干拆视频、压视频的粗活，把 CPU 解放出来。你现在是 CPU 软解码，加上 libx264 软编码，等于让一个人干三份活。
解码独立线程 + 队列（说人话：拆视频的和认目标的各干各的，中间放个传送带）：这样解码慢下来，推理也不用跟着停。这就是 Phase 0 里那个阻塞点①的解法。
跨路 batch（说人话：几路的画面攒成一摞，一次性交给显卡）：GPU 一次处理一摞比一张一张来划算得多。你现在是 batch=1，一帧一帧喂，显卡大半时间在闲着。
模型共享 + 缓存（说人话：同一个模型只请一次，别每路都重新请一遍）：你那个 fram_load_dir 缓存被注释掉了，记得打开。

一个常见误会：开了多线程 ≠ GPU 就并行了。你在 CPU 那边分了好几条线，到了 GPU 上活儿还是一个个排队做。想让显卡真并行，得靠 CUDA streams 或者多 context。

五、🔧 Phase 3 验收

做完下面三件事，这一页才算真过了。

交一份对比报告：.pt、FP16.engine、INT8.engine 三种格式，各自的延迟和 mAP 摆在一起。
把系统改一版。解码独立线程、NVENC、跨路 batch、模型共享，你挑一项做，然后量一量延迟降了多少。
你能用自己的话讲明白：为什么 INT8 在 VisDrone 上会漏检，混合精度又是怎么把它救回来的。

下一步：Phase 4 Agent 机制。