TensorFlow目标检测端到端落地实战：从pipeline.config到Jetson部署

1. 这不是调个API就能搞定的事：TensorFlow目标检测到底在解决什么问题

“Object Detection in TensorFlow”——看到这个标题，很多人第一反应是：哦，用现成的模型跑个demo，画几个框，输出坐标和类别，不就完事了？但我在工业质检产线干了七年，带过十二个CV项目落地，从手机镜头模组缺陷识别到光伏板隐裂定位，踩过的坑比读过的论文还多。实话讲，真正卡住90%工程师的，从来不是“怎么调通模型”，而是“为什么在TensorFlow里做目标检测，要绕这么多弯、填这么多坑、改这么多配置”。核心关键词就三个：TensorFlow、目标检测、端到端落地。它不是教你怎么写model.predict()，而是告诉你：当你要把一个能识别螺丝松动、焊点虚焊、PCB铜箔起翘的模型，塞进一台只装了CUDA 11.2和TensorFlow 2.12的工控机里，稳定跑满7×24小时，误检率压到0.3%以下时，你得亲手拧紧哪几颗螺丝。

这内容适合三类人：一是刚学完YOLOv5想转TensorFlow生态的新手，别急着抄GitHub代码，先搞懂TF Detection Model Zoo里每个.config文件里那堆first_stage_nms_iou_threshold、second_stage_post_processing参数背后的真实物理意义；二是正在做边缘部署的嵌入式工程师，你得知道为什么saved_model导出后体积暴增3倍，而TFLiteConverter一量化就崩在NonMaxSuppressionV5算子上；三是带团队的技术负责人，你需要判断：在2024年，继续押注TensorFlow Object Detection API，还是该把主力切到PyTorch Lightning + MMDetection？我的答案很直接：如果你的客户明确要求模型必须跑在NVIDIA Jetson Orin上，且系统镜像锁死在Ubuntu 20.04 + TF 2.8，那你就得把TF OD API的每行C++底层注册逻辑都摸透。这不是技术情怀，是合同里的SLA条款。接下来所有内容，全部来自我去年在汽车电子Tier 1厂商做的ADAS摄像头障碍物识别项目——从数据标注规范、TFRecord生成脚本的内存泄漏修复、到export_tflite_ssd_graph.py源码级魔改，全是真刀真枪的现场记录。

2. 为什么非得用TensorFlow Object Detection API？绕不开的四个硬约束

2.1 生态绑定：不是选择，而是继承

很多新手以为“TensorFlow目标检测”就是自己搭个SSD网络然后model.fit()。错。真正的TF目标检测，特指TensorFlow Object Detection API（简称TF OD API）这一整套工程化框架。它不是库，是带完整训练流水线、评估工具链、模型导出管道的“操作系统”。为什么大厂还在用？看四个无法回避的现实约束：

第一，硬件兼容性遗产。某德系车企的车载域控制器，芯片是NXP S32G274A，BSP由供应商固化，只提供TensorFlow Lite for Microcontrollers的预编译库，且强制要求输入模型必须是TFLite格式，而该格式的SSD模型图结构，必须严格匹配TF OD API导出的TFLiteGraphDef。你用Keras自定义SSD，哪怕精度高0.5%，也过不了他们的CI/CD流水线——因为验证脚本里硬编码了graph.get_tensor_by_name('TFLite_Detection_PostProcess:0')。

第二，标注协议锁定。工业场景大量使用LabelImg或CVAT，它们导出的XML格式，天然适配TF OD API的generate_tfrecord.py脚本。而PyTorch生态的COCO格式，需要额外写转换器处理<bndbox>坐标系与[x,y,w,h]的归一化差异。我们曾为某电池厂做极片缺陷检测，客户提供的5万张LabelImg标注数据，直接喂给MMDetection会因<xmin>坐标越界报错，但TF OD API的dataset_util.read_examples_list()函数内置了容错裁剪逻辑——这是七年来无数工业项目沉淀下来的鲁棒性。

第三，模型压缩路径唯一。TF OD API的export_tflite_ssd_graph.py脚本，是目前唯一能将SSD-MobileNetV2的PostProcessing子图完整剥离并重写为TFLite原生算子的工具。我们实测过：用PyTorch训练的SSD，转ONNX再转TFLite，NonMaxSuppression会被拆成十几个基础算子，推理延迟飙升47%；而TF OD API导出的TFLite模型，TFLite_Detection_PostProcess是一个原子算子，Jetson Nano上单帧耗时稳定在83ms。

第四，长尾类别支持。医疗影像中“微小肺结节”的IoU阈值需设为0.1，而自动驾驶中“远处车辆”的IoU必须≥0.7，否则漏检致命。TF OD API的pipeline.config里，post_processing模块允许为不同类别单独配置score_threshold和max_detections_per_class，这种细粒度控制，在Hugging Face Transformers的AutoModelForObjectDetection里至今没有等效实现。

提示：别被“TensorFlow 2.x已弃用OD API”的传言误导。官方确实在2023年将OD API移出主仓库，但维护从未停止——最新版2.15.0仍通过pip install tf-models-official安装，且models/research/object_detection/目录下的model_lib_v2.py已全面支持tf.distribute.Strategy多GPU训练。所谓“弃用”，只是把它从“默认组件”降级为“官方认证插件”。

2.2 架构选型：SSD vs Faster R-CNN vs CenterNet，选错等于返工三个月

TF OD API支持三大主流架构，但选型绝不是看论文指标。我列一张真实产线决策表：

关键洞察：SSD不是“低端方案”，而是工业场景的最优解。原因有三：其一，SSD的anchor机制对固定尺寸缺陷（如PCB焊盘直径300μm）泛化性极强；其二，TF OD API的ssd_mobilenet_v2_quantized_coco预训练模型，其anchors参数已针对0.5mm~5mm尺度优化，迁移学习时只需微调最后两层；其三，SSD的loss函数中localization_loss权重可独立调节，这对“位置精度远比分类置信度重要”的场景（如机械臂抓取定位）是刚需。

注意：千万别用ssd_resnet50_v1_fpn_coco跑边缘设备！它的FPN层会生成5级特征图，而Jetson的TFLite runtime对ResizeNearestNeighbor算子支持不全，实测在Orin上会触发SIGSEGV。我们最终方案是：用ssd_mobilenet_v2_fpnlite，手动将fpn_depth=2（默认3），牺牲1.2% mAP换取300%稳定性提升。

2.3 数据准备：TFRecord不是容器，是性能瓶颈本身

新手常问：“为什么不用TFRecord直接喂tf.data.TFRecordDataset？”——因为TFRecord根本不是为“即读即训”设计的。它是Google为MapReduce场景优化的分块序列化协议，核心优势在于：1）单文件内按Exampleprotobuf序列化，避免小文件IO；2）支持ZLIB压缩，降低存储带宽；3）tf.io.parse_single_example可并行解析，但前提是buffer_size设置科学。

我们处理12万张工业图像时发现：当buffer_size=1000，tf.data流水线GPU利用率仅32%；调至buffer_size=10000后升至79%，但内存暴涨至42GB。最终方案是双缓冲策略：

• 第一层：tf.data.TFRecordDataset(filenames, buffer_size=10*1024*1024)—— 按10MB块读取文件，减少磁盘寻道
• 第二层：dataset.prefetch(tf.data.AUTOTUNE)—— 启用自动预取，让CPU解析与GPU计算重叠

更关键的是Example构造。TF OD API要求image/encoded字段存JPEG原始字节，而非解码后的uint8数组。很多人用cv2.imencode('.jpg', img)生成，结果发现训练时image_decoder报Invalid JPEG data。根源在于：OpenCV默认用cv2.IMWRITE_JPEG_QUALITY=95，而TF的tf.image.decode_jpeg对APP0头信息敏感。解决方案是：

# 正确写法：强制清除EXIF头 import PIL.Image pil_img = PIL.Image.fromarray(img) output = io.BytesIO() pil_img.save(output, format='JPEG', quality=95, optimize=True, progressive=False) jpeg_bytes = output.getvalue()

实操心得：TFRecord生成脚本必须加--include_masks=True参数（即使不用实例分割）。因为mask字段会触发dataset_util.create_tf_example内部的_get_mask_shape校验，能提前暴露image/height与image/width字段类型错误——这是我们在某面板厂项目中，因int64误写为int32导致训练3天后崩溃才发现的血泪教训。

3. 核心细节解析：从pipeline.config到TFLite导出的17个生死参数

3.1 pipeline.config：每一行都是生产环境的契约

TF OD API的pipeline.config不是配置文件，是模型行为的法律文书。下面逐行解析工业项目中最关键的17个参数，附真实影响案例：

1. model.ssd.num_classes: 4

   • 表面看是类别数，实际决定classification_loss的softmax_cross_entropy维度。若标注数据含5类但此处写4，训练时不会报错，但第5类的logits全为0，部署后该类别永远不出现。我们曾因此漏检“绝缘胶带脱落”这一致命缺陷。

2. train_config.fine_tune_checkpoint_type: "detection"

   • 必须设为"detection"而非"classification"。后者只加载骨干网权重，box_predictor层随机初始化，收敛慢且mAP波动超±5%。某汽车雷达项目因此延误交付，被迫重训。

3. train_config.optimizer.momentum_optimizer.learning_rate.manual_step_learning_rate.initial_learning_rate: 0.01

   • 初始学习率不是越大越好。SSD-MobileNetV2在0.01下训练震荡剧烈，实测0.004最稳。公式：lr = base_lr * (batch_size / 64) ^ 0.5，我们8卡训练时设为0.008。

4. train_config.optimizer.momentum_optimizer.learning_rate.manual_step_learning_rate.schedule: [{step: 0, learning_rate: 0.008}, {step: 9000, learning_rate: 0.0008}, {step: 12000, learning_rate: 0.00008}]

   • 学习率衰减步数必须按total_steps = (num_examples / batch_size) * num_epochs精确计算。我们12万图、batch=64、epochs=50，总步数=93750，故衰减点设为9000/12000（≈10%/13%）。

5. train_config.data_augmentation_options: {random_horizontal_flip {}}

   • 工业图像禁用random_vertical_flip！电路板丝印文字上下颠倒后无法识别。必须用random_rotation90替代，且angle_interval设为[0, 1]（仅90°倍数）。

6. train_input_reader.label_map_path: "data/label_map.pbtxt"

   • label_map.pbtxt中id必须从1开始，0保留给背景。若写id: 0，tf.metrics.mean_iou计算时会把背景当有效类别，mAP虚高12%。

7. train_input_reader.tf_record_input_reader.input_path: ["data/train.record-00000-of-00100"]

   • 文件名必须带-of-分片标识。TF OD API的input_reader会自动按-of-分割并轮询读取，若写["data/train.record"]，只读第一个分片。

8. eval_config.num_examples: 2000

   • 评估样本数必须≤验证集总数。若验证集仅1800张却设2000，model_lib_v2.eval_continuously()会无限循环，占满GPU显存。

9. eval_input_reader.label_map_path: "data/label_map.pbtxt"

   • 必须与train_input_reader路径完全一致。路径差异会导致category_index加载失败，评估时DetectionResult的classes全为0。

10. eval_input_reader.tf_record_input_reader.input_path: ["data/val.record-00000-of-00020"]

    • 验证集分片数应远少于训练集（20 vs 100），确保eval阶段IO不拖慢train。

11. model.ssd.anchor_generator.ssd_anchor_generator.height_stride: 16

    • 此值=骨干网下采样总倍数。MobileNetV2为16，ResNet50为32。设错会导致anchor中心点偏移，小目标检测框漂移超3像素。

12. model.ssd.anchor_generator.ssd_anchor_generator.width_stride: 16

    • 同上，必须与height_stride一致。异构设置会生成菱形anchor，破坏SSD的轴对齐假设。

13. model.ssd.box_coder.faster_rcnn_box_coder.y_scale: 10.0

    • 坐标回归缩放因子。值越大，ty,th梯度越小，训练越稳但收敛慢。工业场景推荐8.0~12.0，我们最终定为10.0。

14. model.ssd.post_processing.batch_non_max_suppression.iou_threshold: 0.5

    • NMS IoU阈值。OCR场景需0.3（字符粘连），自动驾驶需0.7（车辆遮挡）。我们电池极片项目设0.45，平衡漏检与重叠。

15. model.ssd.post_processing.batch_non_max_suppression.score_threshold: 0.3

    • 置信度阈值。低于此值的预测框直接丢弃。设0.1会导致误检爆炸，0.5则漏检小目标。我们用0.3 + 0.05 * (class_id - 1)动态调整。

16. train_config.use_bfloat16: true

    • A100/V100必备。开启后显存占用降35%，训练速度升1.8倍。但必须配合mixed_precision.set_global_policy('mixed_bfloat16')，否则LossScaleOptimizer失效。

17. model.ssd.feature_extractor.depth_multiplier: 0.75

    • MobileNetV2通道缩放系数。0.75比1.0快2.1倍，mAP仅降0.8%。但必须同步修改ssd_anchor_generator的scales，否则anchor尺寸错配。

提示：所有参数修改后，必须运行model_lib_v2.validate_and_update_config()校验。该函数会检查num_classes与label_map一致性、stride与骨干网匹配性等12项硬约束，避免“训完才发现配置矛盾”的灾难。

3.2 训练过程：model_lib_v2.train_loop()背后的五个隐藏战场

调用model_lib_v2.train_loop(pipeline_config_path, model_dir)看似简单，实则暗藏五大战场：

战场一：混合精度训练的陷阱
TF 2.12+默认启用mixed_float16，但SSD的sigmoid激活函数在FP16下易溢出。解决方案：

# 在train_config中添加 train_config.optimizer.mixed_precision_loss_scale: "dynamic" # 并在train_loop前插入 from tensorflow.keras.mixed_precision import set_global_policy set_global_policy('mixed_float16') # 关键：为box_predictor层强制设为FP32 for layer in model._feature_extractor._box_predictor._prediction_heads.values(): layer._dtype_policy = tf.float32

战场二：分布式训练的梯度同步
8卡训练时，tf.distribute.MirroredStrategy()默认用NCCL，但某些驱动版本下all_reduce超时。必须显式指定：

strategy = tf.distribute.MirroredStrategy( cross_device_ops=tf.distribute.NcclAllReduce(num_packs=2) ) # num_packs=2将梯度分2批传输，规避NCCL通信阻塞

战场三：Checkpoint保存的IO瓶颈
默认每1000步保存一次，但checkpoint包含optimizer状态，单次IO达2.3GB。我们改为：

# 只保存模型权重，不存optimizer checkpoint_options = tf.train.CheckpointOptions( save_debug_info=False, experimental_io_device='/job:localhost' ) # 并用tf.io.gfile.copy()异步复制到NAS

战场四：Eval的资源抢占
model_lib_v2.eval_continuously()默认每300秒启动一次评估，但会独占1个GPU。我们改用tf.distribute.get_strategy().run()封装评估函数，与训练共享GPU，通过tf.device('/GPU:0')精细调度。

战场五：OOM的终极解法
当batch_size=64仍OOM，终极方案是梯度累积：

# 在train_step中 with tf.GradientTape() as tape: loss = model.loss(...) gradients = tape.gradient(loss, model.trainable_variables) # 每4步累积一次梯度 if step % 4 == 0: optimizer.apply_gradients(zip(gradients, model.trainable_variables))

实操心得：训练日志里global_step/sec低于0.8，说明IO或CPU成为瓶颈。此时应检查tf.data的prefetch和cache是否启用，而非盲目加卡。我们曾用nvidia-smi dmon -s u发现GPU利用率仅40%，根源是TFRecord文件放在机械硬盘上——换NVMe后global_step/sec从0.6升至2.1。

4. 实操全流程：从零到Jetson Orin部署的完整链路

4.1 环境准备：TensorFlow 2.12 + CUDA 11.8的精准配方

别信“pip install tensorflow-gpu”——工业部署必须源码编译。我们的标准配方：

• OS: Ubuntu 20.04.6 LTS（Jetson Orin官方镜像基线）
• CUDA: 11.8.0_520.61.05（必须与NVIDIA驱动520.61.05严格匹配）
• cuDNN: 8.6.0.163（TF 2.12要求cuDNN ≥8.6）
• TensorFlow: 2.12.0（源码编译，启用-march=native和-O3）
• Bazel: 5.3.0（TF 2.12编译必需）

编译命令：

# 下载TF 2.12.0源码 git clone https://github.com/tensorflow/tensorflow.git cd tensorflow && git checkout v2.12.0 # 配置 ./configure # 问CUDA路径时填 /usr/local/cuda-11.8 # 问cuDNN路径时填 /usr/lib/x86_64-linux-gnu/libcudnn.so.8 # 启用XLA: Y # 启用CUDA: Y # 编译（16核CPU） bazel build --config=opt --config=cuda --copt=-march=native //tensorflow/tools/pip_package:build_pip_package # 打包 ./bazel-bin/tensorflow/tools/pip_package/build_pip_package /tmp/tf_pkg # 安装 pip uninstall tensorflow -y pip install /tmp/tf_pkg/tensorflow-2.12.0-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl

注意：--copt=-march=native让编译器针对当前CPU指令集优化，Orin的ARM Cortex-A78AE核心可启用SVE2向量指令，实测推理速度提升18%。但若在x86服务器编译后拷贝到Orin，会因指令集不兼容直接段错误。

4.2 数据工程：工业级TFRecord生成的七步法

我们为某半导体厂生成12万张晶圆缺陷TFRecord，流程如下：

步骤1：清洗原始图像
用OpenCV做CLAHE增强（clipLimit=2.0, tileGridSize=(8,8)），提升微米级缺陷对比度。禁用cv2.equalizeHist()——它会放大噪声。

步骤2：标准化标注格式
将LabelImg的<bndbox>转换为[ymin,xmin,ymax,xmax]归一化坐标，并校验：

# 必须满足 0 <= ymin < ymax <= 1 and 0 <= xmin < xmax <= 1 if not (0 <= ymin < ymax <= 1 and 0 <= xmin < xmax <= 1): # 自动裁剪到边界，而非丢弃样本 ymin, ymax = max(0, ymin), min(1, ymax) xmin, xmax = max(0, xmin), min(1, xmax)

步骤3：生成label_map.pbtxt

item { name: "scratch" id: 1 display_name: "Scratch" } item { name: "crack" id: 2 display_name: "Crack" } # id必须连续，不可跳号

步骤4：分片策略
12万图分100个TFRecord文件（每片1200张），文件名：train-00000-of-00100.tfrecord。分片数必须是质数（100不是质数，但TF OD API接受），避免哈希冲突。

步骤5：TFRecord写入
用tf.io.TFRecordWriter，关键参数：

options = tf.io.TFRecordOptions( compression_type='ZLIB', flush_mode=tf.python_io.TFRecordCompressionType.ZLIB ) # ZLIB压缩比LZ4高23%，且TF OD API的reader原生支持

步骤6：校验TFRecord完整性
写入后立即用tf.data.TFRecordDataset读取前10条，校验image/encoded可解码、image/shape匹配、object/class/label在label_map范围内。

步骤7：生成examples.list
创建train.examples.list，每行一个TFRecord路径。TF OD API的read_examples_list()函数依赖此文件顺序读取，乱序会导致训练数据重复。

实操心得：TFRecord生成脚本必须加--max_num_boxes=100参数。工业图像单图缺陷可达200+个，超出TF OD API默认的max_num_boxes=100限制，会导致parse_single_example静默截断，后100个框永远丢失——这是我们在LED屏坏点检测项目中，mAP卡在0.65再也上不去的根本原因。

4.3 模型训练：从pretrained checkpoint到mAP 0.82的实战记录

我们以ssd_mobilenet_v2_fpnlite_320x320_coco17_tpu-8为起点（下载地址：http://download.tensorflow.org/models/object_detection/tf2/20200711/ssd_mobilenet_v2_fpnlite_320x320_coco17_tpu-8.tar.gz），训练流程：

阶段一：Warmup（前2000步）

• 学习率从0线性增至0.004
• 冻结骨干网（trainable_variables中排除MobilenetV2）
• 只训练BoxPredictor和FeatureExtractor的FPN层
• 目标：让检测头适应新数据分布，避免梯度爆炸

阶段二：Full Training（2000~90000步）

• 学习率按余弦退火：lr = 0.004 * (1 + cos(pi * step / 90000)) / 2
• 解冻全部层，但MobilenetV2/Conv/BatchNorm/gamma设为不可训练（防止BN统计量污染）
• 启用tf.keras.callbacks.EarlyStopping(patience=5000)，监控eval_loss

阶段三：Fine-tuning（90000~120000步）

• 学习率降至0.0002
• 添加tf.keras.callbacks.ReduceLROnPlateau(factor=0.5, patience=2000)
• 每5000步用model_lib_v2.export_inference_graph()导出一次冻结图，验证mAP趋势

关键结果：

• 训练耗时：8×A100，118小时
• 最终mAP@0.5: 0.823（COCO标准）
• 小目标mAP@0.5（<32×32像素）：0.712（比基线高0.15）
• 模型体积：14.2MB（TFLite量化后）

注意：export_inference_graph()导出的saved_model不能直接用于TFLite转换！必须用专用脚本export_tflite_ssd_graph.py，因为它会：1）剥离PostProcessing子图；2）重写NonMaxSuppression为TFLite原生算子；3）插入TFLite_Detection_PostProcess占位符。我们曾跳过此步，直接tflite_convert，结果TFLite模型输出raw_outputs/box_encodings和raw_outputs/class_predictions，而没有detection_boxes——这意味着你得在应用层手写NMS，精度和速度全毁。

4.4 TFLite导出与Orin部署：三步通关指南

步骤1：导出TFLite Graph

# 必须用TF OD API自带脚本 python object_detection/export_tflite_ssd_graph.py \ --pipeline_config_path=training/pipeline.config \ --trained_checkpoint_prefix=training/model.ckpt-120000 \ --output_directory=tflite_export \ --add_postprocessing_op=true \ --max_detections=10 \ --max_classes_per_detection=1 \ --detection_threshold=0.3

关键参数：

• --add_postprocessing_op=true：插入TFLite_Detection_PostProcess算子
• --max_detections=10：限制输出框数，避免Orin内存溢出
• --detection_threshold=0.3：与pipeline.config中的score_threshold一致

步骤2：TFLite量化转换

import tensorflow as tf converter = tf.lite.TFLiteConverter.from_saved_model( 'tflite_export/saved_model' ) converter.optimizations = [tf.lite.Optimize.DEFAULT] converter.target_spec.supported_ops = [ tf.lite.OpsSet.TFLITE_BUILTINS, tf.lite.OpsSet.SELECT_TF_OPS # 必须启用，否则PostProcess算子不支持 ] converter.experimental_enable_resource_variables = True # 量化为int8 converter.representative_dataset = representative_data_gen converter.target_spec.supported_types = [tf.int8] converter.inference_input_type = tf.int8 converter.inference_output_type = tf.int8 tflite_model = converter.convert() with open('model.tflite', 'wb') as f: f.write(tflite_model)

representative_data_gen必须用真实校准数据：

def representative_data_gen(): dataset = tf.data.TFRecordDataset('data/calib.record') for raw_record in dataset.take(100): example = tf.train.Example() example.ParseFromString(raw_record.numpy()) image = tf.io.decode_jpeg(example.features.feature['image/encoded'].bytes_list.value[0]) image = tf.cast(tf.image.resize(image, [320, 320]), tf.uint8) yield [image.numpy()]

步骤3：Orin C++推理

// 加载模型 std::unique_ptr<tflite::FlatBufferModel> model = tflite::FlatBufferModel::BuildFromFile("model.tflite"); tflite::ops::builtin::BuiltinOpResolver resolver; std::unique_ptr<tflite::Interpreter> interpreter; tflite::InterpreterBuilder(*model, resolver)(&interpreter); // 设置输入 interpreter->AllocateTensors(); auto input = interpreter->typed_input_tensor<uint8_t>(0); // 将BGR图像转RGB并归一化到[0,255] cv::cvtColor(frame, frame, cv::COLOR_BGR2RGB); cv::resize(frame, frame, cv::Size(320, 320)); memcpy(input, frame.data, 320*320*3); // 推理 interpreter->Invoke(); // 解析输出（TFLite_Detection_PostProcess输出4个tensor） auto output_boxes = interpreter->typed_output_tensor<float>(0); // [1,10,4] auto output_classes = interpreter->typed_output_tensor<float>(1); // [1,10] auto output_scores = interpreter->typed_output_tensor<float>(2); // [1,10] auto num_detections = interpreter->typed_output_tensor<int>(3); // [1] // 转换为OpenCV Rect for (int i = 0; i < *num_detections; ++i) { float ymin = output_boxes[i*4 + 0]; float xmin = output_boxes[i*4 + 1]; float ymax = output_boxes[i*4 + 2]; float xmax = output_boxes[i*4 + 3]; cv::Rect rect( xmin * frame.cols, ymin * frame.rows, (xmax - xmin) * frame.cols, (ymax - ymin) * frame.rows ); cv::rectangle(frame, rect, cv::Scalar(0,255,0), 2); }

实操心得：Orin上interpreter->Invoke()耗时不稳定，有时22ms，有时156ms。根源是TFLite的thread_count默认为0（自动），在多进程环境下会争抢CPU。解决方案：interpreter->SetNumThreads(4)，固定4线程，耗时稳定在23±1ms。

5. 常见问题与排查技巧实录：那些文档里不会写的真相

5.1 训练阶段高频问题速查表