企业官网建设流程全解析

RT-DETR-R18 这个模型，我在移动端折腾了大半年。从最初PyTorch训练完的600多MB权重文件，到最后落到手机上不到20MB的INT8量化模型，中间踩过的坑比想象中多得多。特别是把它部署到TensorFlow Lite这条链路上，跟传统的YOLO系模型完全不一样，Transformer结构带来的算子兼容问题、量化精度回退、输出解码逻辑，每一步都可能让你卡上几天。这篇文章把自己从模型导出、ONNX转SavedModel、TFLite量化，到移动端C++推理和后处理的完整过程记录下来，重点写那些普通教程里不会讲的取舍和坑。项目背景是做低功耗场景下的实时目标检测，不是极限帧率竞赛，而是要在尽量小的电量和发热下稳定输出结果。这套方案适合IPC本地分析、离线检测盒子、低功耗摄像头这类场景，也适合刚想跑通RT-DETR移动端部署的开发者参考。

2. 为什么选RT-DETR-R18做移动端低功耗检测

2.1 端到端检测架构的部署红利

先说说模型选型。RT-DETR全称是Real-Time Detection Transformer，R18表示骨干网络是ResNet18。相比之前流行的那批anchor-based检测器，RT-DETR在架构上最核心的区别是端到端集合预测。通俗点讲，它直接把检测任务变成了一个从特征到候选框集合的映射问题，模型输出一组预测框和对应的分类置信度，不需要传统的Anchor匹配、不需要NMS非极大值抑制。

这件事在移动端部署上的意义非常大。传统YOLO系模型推理完成后，还要在CPU上跑一段NMS后处理，框多了的时候这个耗时很可观，而且容易出现神秘的双框、漏框问题。到了RT-DETR这边，模型自己通过匈牙利匹配和去重机制在训练阶段就把这些逻辑学进去了，推理时只需要做一次TopK筛选或者阈值过滤。省下来的这段CPU时间，在低功耗场景下可以直接折算成更低的整机功耗。

另一个优势是模型体积。R18作为骨干，FP32权重大概在60MB上下，做完整INT8量化后能压到15MB左右。这个体积对移动端非常友好，无论是从包内资产加载还是从文件系统动态读取，启动加载时间都在百毫秒级别，不会像那些几百MB的大模型一样一加载就把内存吃满。

2.2 R18在精度与算力之间的平衡位置

我最初也纠结过要不要用Swin骨干的RT-DETR版本，精度确实更高，但看一眼算力账单就冷静了。RT-DETR-R18在COCO验证集上的mAP虽然不及大骨干版本，但在低功耗移动端这个约束下，它其实是精度和算力的一个合理平衡点。R18这种残差结构在移动端CPU上跑起来，卷积计算密度集中，INT8量化后的速度提升非常明显。更重要的是，它的Transformer部分被压缩得比较小，整体计算量对比ViT骨架要低一个量级。

这里要说一个部署的心得：如果设备是带NPU的低功耗SoC，那么模型的计算模式比模型的参数量更关键。RT-DETR-R18混合了CNN骨架和Transformer解码器，卷积部分在NPU上基本可以加速，Transformer部分还得看NPU对Softmax、层归一化这些算子的支持程度。如果NPU不支持，就退到CPU兜底，这时一个轻量级的R18骨架就是保底体验的关键。

2.3 移动端落地的整体技术链路

整个部署链路可以拆成四段。第一段是PyTorch端训练好的权重导出为ONNX格式，这一步要处理的是算子兼容和输出结构约定。第二段是ONNX转到TensorFlow SavedModel格式，这一步是整个流程中最容易出问题的地方，Transformer里的GridSample、Deformable系列算子在ONNX和TF之间的语义差异会让转换工具直接报错。第三段是SavedModel转TFLite，同时完成量化，这一步既要处理好校准数据集，又要决定模型输出类型。第四段才是移动端推理，Android或者嵌入式Linux上加载TFLite解释器、做图像预处理、解析输出。

这个链路和传统的YOLO部署流程看着差不多，实际上每一步的坑位都不同。YOLO转出来就是Conv、Add、Sigmoid这些基础算子，TensorFlow Lite内置的算子库全都认识。RT-DETR就不一样了，它的解码器里有可变形注意力，导出的ONNX图里会出现GridSample、大的Reshape/Slice组合、还有动态Shape相关的算子，这些在TFLite里的支持情况属于“时常翻车”的水平。所以后面每一节，我都会围绕RT-DETR这个特定模型来讲，而不是泛泛而谈TFLite部署。

3. TensorFlow Lite模型转换全流程实操

3.1 从PyTorch导出ONNX的关键参数

先确认环境版本，我使用的是PyTorch 2.x、ONNX opset 13之后版本。RT-DETR训练完成后，用官方导出脚本生成ONNX比较省事，它会把后处理逻辑一并处理好，输出结构是固定的。如果自己手写torch.onnx.export，有几个参数必须留意。

import torch from model import build_model model = build_model(backbone='r18', export=True) model.eval() dummy_input = torch.randn(1, 3, 640, 640) torch.onnx.export( model, dummy_input, "rtdetr_r18.onnx", opset_version=13, do_constant_folding=True, input_names=["images"], output_names=["num_dets", "boxes", "scores", "labels"], dynamic_axes=None )

这里有一个很容易踩的坑：不要把dynamic_axes设置成动态宽高。RT-DETR的Transformer解码器对序列长度很敏感，动态Shape导出后，ONNX图里会保留大量非定值的Reshape和Slice，转换到TF时更容易卡住Shape推断。虽然动态分辨率听起来很灵活，但在TFLite侧你一般用固定分辨率推理，动态反而给自己找麻烦。我实际项目中全部固定为640x640输入，只在量化后推理阶段通过降采样到320x320来换速度，而不是动态修改输入尺寸。

官方脚本和手写导出还有一个区别在输出层。官方导出会把DETR的Query输出经过解码后直接输出最终坐标：num_dets表示保留的目标数量，boxes为 1x300x4 的坐标数组，坐标值是原图像素坐标系下的cx/cy/w/h这种编码或者x1/y1/x2/y2这种形式，具体看配置。scores和labels也都是固定维度输出。如果在移动端拿到的模型输出格式跟预期不一致，先回来看导出配置，不要盲目改后处理。

3.2 ONNX转TF SavedModel再转TFLite的路径选择

目前把ONNX转到TFLite，大家常用的是直接走onnx2tf转SavedModel，然后交给TFLite Converter。这条路比老旧的onnx-tf稳定不少，尤其是对复杂模型的算子支持更完整。

onnx2tf -i rtdetr_r18.onnx -o rtdetr_r18_saved_model

转换过程中会看到一堆warning，比如某些算子被映射到Flex子图，或者有内置算子布局转换。关键要看有没有error级别的报错。RT-DETR的GridSample算子一般能转过去，但转过去之后在SavedModel里往往变成了一堆自定义组合算子，这会导致后面转TFLite时有机会触发Select TF Ops路径。

import tensorflow as tf converter = tf.lite.TFLiteConverter.from_saved_model( "rtdetr_r18_saved_model" ) converter.target_spec.supported_ops = [ tf.lite.OpsSet.TFLITE_BUILTINS_INT8 ] converter.optimizations = [tf.lite.Optimize.DEFAULT] converter.representative_dataset = representative_dataset_gen converter.inference_input_type = tf.uint8 converter.inference_output_type = tf.uint8 tflite_model = converter.convert() with open("rtdetr_r18_int8.tflite", "wb") as f: f.write(tflite_model)

这里要注意supported_ops的选择。如果转换时报错说某些算子不支持，一个常见操作是把TFLITE_BUILTINS_INT8换成一个包括SELECT_TF_OPS的列表，但这样会让TFLite解释器依赖TensorFlow核心库，这在移动端是不希望看到的：模型文件变小了，运行库体积上去了，低功耗目标也受影响。所以我的原则是优先保留全部内置算子，实在不行再考虑Flex方案，并且要实测这个“Flex算子”在推理时是否频繁触发额外的内存分配。

3.3 INT8量化与校准数据集制作

量化是RT-DETR移动端低功耗部署里最关键的一环。模型从FP32压缩到INT8，参数量和计算量同时降低，在CPU上通常能拿到2到4倍的加速。但目标检测模型量化后精度掉点比分类模型明显，因为输出坐标的数值范围大、类别置信度又很敏感。

校准数据集的制作方式直接影响量化质量。我的做法是从真实使用场景里采集图片，而不是用公开数据集的几百张图来凑数。低功耗检测盒子要装在哪，就拍哪类场景的画面，至少要有200到500张覆盖不同光照和角度的图。代码里这样组织代表性数据集：

import cv2 import numpy as np def representative_dataset_gen(): image_paths = [ "calib/001.jpg", "calib/002.jpg", # 装载300张左右 ] for path in image_paths: img = cv2.imread(path) img = cv2.cvtColor(img, cv2.COLOR_BGR2RGB) img = cv2.resize(img, (640, 640)) img = img.astype(np.float32) / 255.0 yield [img[np.newaxis, ...]]

有一点要提前说清楚：RT-DETR在PyTorch训练时图像归一化方式是除以255到[0,1]，并没有额外做减均值除方差。所以校准集的输入也要保持这个分布，不要随意加标准化，否则量化出来的Scale/ZeroPoint会偏差很大。量化完一定要用同一张测试图跑一遍FP32模型和INT8模型，对比框坐标和置信度的差异，如果置信度普遍掉0.2以上，说明校准集分布和推理时不一致，需要重新收集。

量化后的模型大小和速度对比可以参考这样一个项目里的实际记录，注意具体数据跟设备强相关，这里列的是某一款中端ARM SoC上的结果：

模型小到16MB之后，加载和mmap映射都很快，冷启动时间基本不会成为体验瓶颈。

4. 移动端推理实现与优化注意

4.1 推理引擎初始化与线程调度

TFLite在移动端的运行模式很成熟，但初始化正确与否差距很大。先给出一个最基础的C++端解释器构建函数：

#include "tensorflow/lite/interpreter.h" #include "tensorflow/lite/kernels/register.h" #include "tensorflow/lite/model_builder.h" std::unique_ptr<tflite::Interpreter> BuildInterpreter( const std::string& model_path, int threads) { auto model = tflite::FlatBufferModel::BuildFromFile(model_path.c_str()); if (!model) return nullptr; tflite::ops::builtin::BuiltinOpResolver resolver; tflite::InterpreterBuilder builder(*model, resolver); std::unique_ptr<tflite::Interpreter> interpreter; builder(&interpreter); if (!interpreter) return nullptr; interpreter->SetNumThreads(threads); if (interpreter->AllocateTensors() != kTfLiteOk) return nullptr; return interpreter; }

线程数设置很有讲究。移动端CPU多核架构一般是大小核混布，SetNumThreads(4)看起来稳妥，但在批量推理时可能会把一个核心上的大核任务跟实时线程抢占。我实际测试下来，低功耗场景里设置2到4个线程差别不大，反而线程数开满时发热上得更快，性能还会下降。正确的做法是结合具体SoC的动态调频策略反复验证，找到“速度不再提升”的那条线程数边界。

初始化阶段还要注意一次性AllocateTensors之后，尽量复用同一块输入输出内存。不要在每次推理时重新创建tensor，也不要频繁创建和销毁Interpreter实例。TFLite的arena内存分配在图初始化时已经规划好了，每次Invoke只是数据流动，这是它能保持稳定低延迟的重要原因。

4.2 输入预处理与输出解码全流程

图像预处理对齐训练逻辑是部署成功的第一步。RT-DETR推理输入是NCHW或NHWC的RGB数据，绝大多数情况你的摄像头或者OpenCV读出来是BGR。这个顺序不转，检测精度会崩得莫名其妙。

import cv2 import numpy as np img = cv2.imread("test.jpg") img = cv2.cvtColor(img, cv2.COLOR_BGR2RGB) img = cv2.resize(img, (640, 640), interpolation=cv2.INTER_LINEAR) img = img.astype(np.float32) / 255.0 # 假设输入是量化模型，uint8格式 input_scale, input_zero_point = input_details[0]["quantization"] img_q = img / input_scale + input_zero_point img_q = np.clip(img_q, 0, 255).astype(np.uint8) interpreter.set_tensor(input_details[0]["index"], img_q[np.newaxis, ...]) interpreter.invoke()

输出解析部分，RT-DETR的ONNX导出如果是完整配置，通常有4个输出：num_dets、boxes、scores、labels。拿到输出后，先读取num_dets的实际值，它表示有效目标数量，再去boxes和scores里取对应行。boxes坐标如果是原图像素坐标系，那么由于我们推理时把输入图resize到了640x640，解析后还要按原图尺寸的比例缩放回去。

num_dets, boxes, scores, labels = [ interpreter.get_tensor(out["index"]) for out in output_details ] num = int(num_dets[0]) conf_thresh = 0.3 for i in range(num): score = scores[0][i] label = int(labels[0][i]) if score < conf_thresh: continue x1, y1, x2, y2 = boxes[0][i] # 映射回原图坐标 x1 = int(x1 / 640 * orig_w) y1 = int(y1 / 640 * orig_h) x2 = int(x2 / 640 * orig_w) y2 = int(y2 / 640 * orig_h) draw_bbox(img_bgr, [x1, y1, x2, y2], label, score)

这里有个常见争议：RT-DETR既然端到端不需要NMS，是不是直接阈值过滤就够了。实际经验是，模型训练好了确实不会输出重复框，但量化之后个别框会“劈叉”，就是同一目标出现两个置信度很接近的框。所以我在后处理里加了一个轻量的按IoU过滤操作，只在重叠度大于0.6且类别相同时才删掉置信度低的一个，计算量很小，但能明显改善量化后的视觉观感。

4.3 不同Delegate选型实测心得

TFLite在移动端可以挂不同的Delegate来加速，最常见的四个是CPU默认、XNNPACK、GPU OpenCL、NNAPI。我在RT-DETR-R18这个模型上全都试过，说点个人感受。

XNNPACK对浮点模型增益明显，但对量化模型的优化通常有限，而且RT-DETR里某些复杂组合算子会破坏XNNPACK的算子融合，导致部分子图回退到CPU，实际收益不如预期。GPU Delegate在理论上是好东西，但RT-DETR里层出不穷的Slice、Reshape、Gather操作在OpenCL上支持不全，经常出现某个节点不支持、回退CPU，结果单帧耗时反而比纯CPU还高，因为多了跨后端的数据拷贝。NNAPI则看设备供应商的驱动水平，同一个模型在不同SoC上表现差距很大，有人是加速，有人是卡死。

最终我的方案是稳定优先，默认纯CPU加INT8量化。低功耗本就是目标，INT8 CPU推理已经可以在中端SoC上跑出35到110ms的单帧延迟，足够覆盖很多摄像头检测场景。实际上，在移动端CPU调度的语境里，最复杂的算子在CPU上的执行效率并不低，因为TFLite的INT8算子对ARM架构的DSP指令做了充分优化。

5. 项目实测数据与调优记录

5.1 不同分辨率与推理功耗对比

项目在某项目中端SoC设备上做了完整测试，测试内容包括640x640、480x480和320x320三档分辨率下的推理延迟、模型精度和整机功耗。需要提前说明，这些数据只代表同级别设备上的趋势，不能直接当作所有设备的指标。

从数据里能看出，分辨率降低带来功耗下降非常明显，但小目标检测能力也在同步下降。所以在实际项目里我推荐做动态分辨率调节：设备电量充足或者场景简单时用480，电量低或者距离较近时切到320。

5.2 精度与速度平衡的几个有效措施

除了动态切换分辨率，还有几个从实测里总结出来的优化手段。

第一，降低推理频率配合跟踪算法。连续视频帧之间目标位置变化很小，不需要每一帧都跑一遍完整模型。项目里我做了跳帧策略：每两帧跑一次检测，中间没跑的一帧直接用上一帧的框位置做简单平移预测，检测功耗直接减半，而对业务影响不大。这在固定摄像头场景尤其好用。

第二，窗口裁剪。在固定摄像头场景里目标通常只出现在画面的某个区域，可以先在较低分辨率上跑一次轻量检测，把目标范围锁定后，再在高分辨率上裁剪子图做精确识别。两种模型搭配起来，既保住了远程小目标，也没有让整体功耗失控。

第三，温度策略。低功耗设备通常有散热瓶颈，连续跑大模型几分钟后SoC降频，帧率会明显下滑还显得不稳定。项目中加入了一段简单的体温控逻辑：用系统接口读SoC温度，超过阈值时自动把输入分辨率降到480或者320，等温度回落再恢复。这样平均帧率未必最高，但长期运行的稳定性好很多，不会出现“前两分钟流畅后十分钟卡成幻灯片”的尴尬。

5.3 精度对比的验证方法

部署完成后必须建立一套精度回归的验证流程，不能只看一两张图的效果。我平时常用的方法是准备一个测试视频序列，里面包含项目实际关注的目标在不同距离、不同光照、不同遮挡程度下的几百帧画面。用FP32的PyTorch模型跑一遍得到参考结果，再用部署端INT8模型跑一遍，统计两边的检测框IoU和置信度差异。只有当总体IoU超过0.75、置信度平均偏差在0.1以内，我才认为这个部署版本可以交付。

另外一定要保留FP32形态的TFLite模型作为备查。无论INT8量化后速度多快，FP32模型都是排查问题的“标尺”。当INT8效果异常时，快速切换FP32跑同一张图，如果FP32正常而INT8混乱，那问题大概率出在校准数据集；如果两者都错，则要去查预处理流程或输出解码。

6. 部署中高频问题排查手册

6.1 转换阶段经典报错与应对

RT-DETR转TFLite过程中，我碰到最多的几类报错做一个速查表。

有一个隐藏坑很值得提：RT-DETR的MSDeformableAttention在PyTorch导出ONNX时，由于官方实现里用了大量自定义tensor操作，导出图会变得非常碎。如果是在旧版本的ONNX导出脚本上操作的，图中可能残留一些只支持CPU的算子，到TF侧就变成了“看着转成功，一跑起来就崩”。解决路径是尽量使用官方最新导出脚本，它会把可变形注意力整理成更规范的ONNX算子序列。

6.2 推理结果异常的原因定位

如果在移动端跑起来结果不对，不要急着调阈值，先按顺序排查这几个点。

先看输入数据排列。很多项目用Camera2输出YUV数据，转RGB后没有注意通道顺序，或者resize时用了不同的插值算法，这两个点最容易导致检测结果“差很远”。我的做法是先在pc端保存一张预处理后的输入数据，拿同一张测试图在PyTorch里得到结果，再在移动端打印输入tensor的第一个像素值对比，能把前处理问题快速隔离。

再看坐标解码方式。RT-DETR导出模型时有的配置输出cx/cy/w/h，有的输出x1/y1/x2/y2，还有的会输出归一化坐标。如果后处理沿用YOLO的anchored解码方案，那必然全错。正确姿势是导出ONNX时就把解码逻辑交给模型，后端只做坐标缩放和阈值过滤，这个原则能避开大多数解析问题。

最后看量化输入类型。转换时如果设置了inference_input_type为tf.uint8，那么输入tensor已经是量化后的uint8格式，代码里不能再做除以255的float归一化再叠加上scale，这一步做错的结果往往是检测框完全乱跑。

6.3 稳定部署的几个独家经验

第一，RTTDETR这类Transformer模型在TFLite上首次推理时会有一层图优化的开销，实测某些设备上的第一次Invoke会跑到几百毫秒。所以项目启动后要做一次“预热推理”，就是随便取一帧或者一张黑图跑一次，把模型真正加载和算子初始化都触发完，预热之后再统计真实业务帧率。

第二，INT8模型虽然体积小，但在低功耗模式下如果频繁分配大块tensor，内存碎片会越来越多，长时间运行后出现一次偶发的几百毫秒卡顿。解决方案是启动时一次性把interpreter和输入输出tensor都分配好，推理期间尽量复用，不要每帧重新创建Mat和tensor对象。

第三，检测结果里的类别置信度在小目标上普遍偏低。量化后尤其明显。不要因为看到置信度只有0.35就怀疑模型坏了，先看这个目标尺寸是否只有十几个像素。目标太小的情况下，先做一次双线性放大再送入模型，往往比调低阈值更有效。我在项目中就增加了一个局部放大分支，专门处理远距离小目标，效果比盲调threshold好很多。

7. 低功耗部署的延展优化方向

做完这个项目后，一个很深的体会是低功耗场景里“模型部署”只是第一步，真正让方案稳定可靠运行的核心在于系统和调度层的设计。比如每帧推理后主动把大tensor释放回内存池，避免让OpenCLContext长时间处于唤醒状态；比如检测线程用低优先级跑在能效核上，把交互线程放在性能核上，避免检测任务干扰UI响应。

后续想继续优化的方向有两个。一个是引入模型分时调度：在场景中目标数量很少时切换到一个更小的R18变体或者干脆降低输入分辨率，在目标密集时再把高精度模型拉起来。另一个是在量化感知训练QAT上下功夫，虽然目前PTQ量化已经能满足项目指标，但QAT通常能进一步压缩置信度偏差，尤其对低功耗设备上长期运行后的稳定性有帮助。

RT-DETR-R18搭配TensorFlow Lite这套组合，在移动端低功耗场景里是一款很能打的方案。虽然转换流程比传统CNN模型曲折一些，但跑通之后，INT8模型在体积、延迟、功耗三方面都让人满意。如果你正准备入手这个方向，建议先把固定分辨率导出ONNX、校准集质量、FP32验证护栏这三件事做好，后面的路会顺很多。