RK3588上SuperPoint+LightGlue边缘目标定位部署实践

如果你和我一样，这几年一直在跟“特征匹配做目标定位”这件事较劲，大概率会有同一个感受：ORB参数调到吐、SIFT在换个光照或者转一个角度之后匹配点直接掉一半，后面再怎么RANSAC都救不回来。这一轮我直接把SuperPoint和LightGlue这对组合搬到了RK3588平台上，搭了一套完整的模板目标定位流程，并且把每段延迟、匹配质量和定位精度都做了量化测试。这篇文章不是泛泛介绍模型原理，而是完整记录在边缘设备上从模型转换、Pipeline实现到性能调优的真实过程，适合正在做边缘视觉定位、巡检机器人或者特定目标跟踪落地的朋友参考。

先说结论：在640x480分辨率下，整套流程端到端稳定跑在5~7 FPS，SuperPoint特征提取交给NPU推理，后处理和LightGlue匹配放在CPU侧，单帧延迟里面最大的头是LightGlue的匹配耗时。这个结果不算惊艳，但在“不训练目标检测模型、纯靠特征匹配完成像素级定位”这个前提下，性价比已经很高了。下面把整个过程中的选型判断、模型落地、Pipeline细节、性能测试方法以及踩过的坑逐一展开说清楚。

1. 为什么在RK3588上做这件事：需求背景与选型思路

1.1 传统特征在复杂场景下的脆弱性

做目标定位的人对特征点都不陌生。传统方案里，ORB因为速度快、开源实现多，是边缘设备上的首选；SIFT和RootSIFT精度更高，但计算量也更大，在ARM核上经常要几百毫秒。问题的关键不在速度，而在稳定性：ORB在光照变化、视角旋转、尺度缩放叠加的场景下，特征点匹配率掉得特别快，我实测过同一块目标区域，视角从正对变成45度，ORB的正确匹配对数直接少一半以上，再用单应矩阵拟合，输出框就开始抖。

SIFT虽然对旋转和尺度更宽容，但对光照边缘敏感的问题依然存在，而且专利期过后各种实现的质量参差不齐，在ARM上做全分辨率提取基本不现实。传统特征还有一个共性短板：描述子是手工设计的，遇到重复纹理、模糊、弱纹理区域，它没法判断“哪些信息值得保留”，只能靠增加描述子维度硬扛，代价是匹配阶段的计算和误匹配一起涨。

所以这套流程的核心动机很简单：用深度学习特征提取网络替代手工特征，把“匹配稳定性”这个天花板抬高，再配合深度匹配网络把误匹配压下去，让后面的几何验证真正可靠。

1.2 SuperPoint与LightGlue的组合价值

SuperPoint的核心思路是让网络自己学习“哪些像素是关键点、每个关键点长什么样”。它用全卷积网络同时输出关键点热力图（角落响应）和256维描述子，训练时通过自监督方式生成伪真值，不需要人工标注。好处是描述子天然带有上下文语义，对光照和视角变化的鲁棒性比ORB强很多，而且模型本身是CNN结构，对NPU友好，这是它能在RK3588上高效部署的前提。

LightGlue是专门做特征匹配的网络，结构上用了多层Transformer，在自注意力和交叉注意力之间交替，让两组特征点互相“对话”。和早期方案相比，它在推理效率上做了明显优化：浅层能判断出匹配已经收敛时可以直接提前退出，不用每次都跑满全部层数，这对边缘设备很关键。输入就是SuperPoint提取出来的关键点坐标和描述子，输出是点对匹配关系。效果上，它对重复纹理和相似结构的区分能力明显好过暴力匹配和最近邻匹配。

这两个模型组合的本质，是把“特征提取”和“特征匹配”两个环节都用可学习的网络替代，前者解决关键点找不准的问题，后者解决匹配对选不对的问题。代价是多了一层模型部署的复杂度，但对定位精度和稳定性的提升是实打实的。

1.3 RK3588的算力画像与部署路线取舍

RK3588的硬件资源，一句话概括：CPU很强，NPU够用但不是万能的。它带了4个A76大核和4个A55小核，NPU宣称6 TOPS算力，支持INT8和INT16量化。跑CNN结构检出一类任务绰绰有余，但遇到Transformer这种带大量动态形状张量的模型就会很别扭。

我最初的设想是把SuperPoint和LightGlue都扔给NPU，实际动手之后很快放弃了这个想法。原因有两方面：一是LightGlue里MultiHeadAttention的Q、K、V矩阵乘法和softmax，在RKNN工具链里算子支持不完整，转换直接报错；二是就算强行转换成功，注意力矩阵的尺寸会随关键点数量变化，NPU对动态shape的支持极差，要么固定最大关键点数浪费算力，要么频繁重编译模型得不偿失。

最后的部署路线定为：SuperPoint走RKNN量化在NPU推理，LightGlue导出成固定shape的ONNX，用ONNX Runtime的CPU版本跑A76核。这个取舍在后面看是正确的，性能和稳定性的平衡点刚好落在这一档。

2. 环境准备与模型落地：从PyTorch到RKNN/ONNX的迁移过程

2.1 板端软件栈与整体架构

板端用的系统是Ubuntu 22.04（aarch64），宿主机上完成模型转换和交叉验证。关键依赖只有几个：RKNN-Toolkit2负责把SuperPoint转成RKNN格式并量化，ONNX Runtime负责跑LightGlue，OpenCV做图像读写、缩放和RANSAC，NumPy做后处理里的softmax、NMS和数组操作。如果你拿到的是全新板子，建议先确认NPU驱动和RKNN runtime版本能对上，rknn-server服务正常起来再谈部署，很多“模型推理输出全错”的诡异问题最后都指向驱动没起来。

整个系统跑起来以后的数据流是这样的：模板图和查询图先经过同一套SuperPoint特征提取，得到归一化坐标和描述子；再由LightGlue做匹配，输出匹配对和置信度；最后用RANSAC拟合单应矩阵，把模板图的四个角点投影到查询图上，框出目标位置。模板图的特征可以离线算好存下来，线上只需要对查询图实时提取，这一步对性能影响很大，下面会细说。

2.2 SuperPoint转RKNN：量化与算子处理

把PyTorch权重导出ONNX这一步不算难，真正折腾的是后处理和量化策略。SuperPoint网络本身输出两个分支：一个是H/8 x W/8 x 65的得分图，另一个是H/8 x W/8 x 256的描述子。注意这里的65是64个局部格子加1个dustbin通道，后者表示“这个区域没有关键点”，必须在后处理里先去掉，再做softmax，才能得到有效关键点响应。

我建议导出ONNX时只导出原始的网络主干，把softmax、argmax、grid_sample这些后处理全部留在板端CPU做。几个原因：第一，RKNN工具链对argmax和grid_sample这类算子的支持在不同版本里表现不一，容易卡转换；第二，后处理留在CPU侧，方便随时调NMS窗口大小、置信度阈值和top-K数量，不用为一次调参重新转换模型；第三，量化误差对softmax之前的logits影响不大，但对argmax结果影响可能很大，CPU上做softmax更稳。

量化校准集我踩过一次坑。最开始图省事只用了10张图做校准，结果模型输出的关键点分布明显偏保守，很多本该检测出来的角点直接消失。换成100张覆盖不同光照、不同场景的校准图之后，问题消失。我的建议是：校准集宁多勿少，最好涵盖你实际使用场景中的图像分布，否则INT8量化会为了“平均误差最小”牺牲掉低响应区域的细节。

2.3 LightGlue部署策略：为什么放在CPU侧跑

LightGlue的ONNX导出需要先固定输入规模。我在实现里把最大关键点数固定为1024，输入张量形状为(1, 1024, 2)的关键点坐标、(1, 1024, 256)的描述子，不足部分用-1和全零填充。这样做的好处是ONNX Runtime不需要处理动态维度，内存分配稳定，推理时间也可预测；坏处是当实际关键点数远小于1024时会浪费计算量。实测数据是：当图像简单、关键点数只有300对时，固定512的输入形状比固定1024快35%左右，所以如果你明确知道业务场景特征点不会太多，可以按512甚至256去固定，代价是要对大图场景做截断后处理。

为什么不用rknn跑LightGlue？从方便维护的角度讲，这种包含注意力机制的模型在RKNN上需要大量手动改图和算子替换工作，而且每升级一次工具链就要重新验证一遍，投入产出比太低。CPU侧跑LightGlue的延迟虽然看起来不低，但它和SuperPoint的NPU推理是前后级流水关系，实际对总吞吐的影响没有想象中大。A76大核用8个线程跑ONNX Runtime，我把线程数从默认值手动绑到4~6个之后，延迟反而更稳定，因为8线程在内存带宽吃紧时线程切换开销太大。

3. 目标定位Pipeline实现：特征提取、匹配与几何验证

3.1 模板与查询图的特征提取

模板特征离线计算，这个没什么争议。查询图每一次都要实时走完整流程：读取图像、缩放、转灰度、归一化、NPU推理、后处理提取关键点和描述子。这里有一个容易被忽略的点：模板图和查询图的缩放方式要保持一致，我用的都是OpenCV的INTER_LINEAR，颜色转换统一走COLOR_BGR2GRAY，归一化统一除以255.0，任何一边不一致都会导致描述子空间出现系统性偏移，匹配率下降。

SuperPoint后处理的关键参数有三个：置信度阈值、NMS窗口大小、top-K数量。我实验下来，置信度阈值设在0.015附近比较合适，太低会混入大量背景噪声点，太高会让弱纹理区域没有关键点可用；NMS窗口用3x3就够，加大到5x5并不能显著提升匹配纯度，反而会让关键点分布更稀疏。top-K取1024是匹配精度和延迟的折中，取2048时LightGlue的推理时间几乎翻倍，但定位精度提升不超过5%，不值得。

3.2 从匹配对到单应矩阵的定位输出

LightGlue输出的是两组索引对应关系和一个匹配置信度分数。拿到匹配对之后，我会先用score阈值过滤一遍低置信度的匹配，阈值我自己设在0.95，后面还会根据场景微调。然后再把匹配对送入cv2.findHomography，用RANSAC求解单应矩阵H，重投影误差阈值默认给5.0像素。

为什么在有了深度匹配网络之后还要再做RANSAC？因为LightGlue再强也不是100%准确，尤其是在重复纹理场景里，偶尔会出现置信度很高但空间位置完全错误的匹配对。RANSAC的价值就是用几何约束把这部分错误挑出来，保证最终定位结果不会因为个别误匹配而发生跳变。我测试过，去掉RANSAC这一步，平均定位误差会从4像素左右暴增到20像素以上，所以几何验证环节绝对不能省。

得到H矩阵后，把模板图的四个角点（0,0)、(w,0)、(w,h)、(0,h)投影到查询图坐标系，画出目标包围框。如果业务需要更精细的位姿，可以用已知模板尺寸和相机内参分解H，得到3自由度的平面位姿估计。

3.3 关键代码片段

SuperPoint的RKNN推理代码比较简洁：

import numpy as np import cv2 def infer_superpoint(rknn_ctx, img_bgr, target_size=(640, 480)): img = cv2.cvtColor(img_bgr, cv2.COLOR_BGR2GRAY) img = cv2.resize(img, target_size, interpolation=cv2.INTER_LINEAR) img = img.astype(np.float32) / 255.0 img = img[np.newaxis, np.newaxis, :, :] outputs = rknn_ctx.inference(inputs=[img]) semi, desc = outputs[0], outputs[1] return semi, desc

关键点提取和描述子采样：

def extract_keypoints(semi, desc, conf_thresh=0.015, nms_size=3, top_k=1024): # semi: (1, 65, Hc, Wc) -> 去掉dustbin并做softmax semi = semi[:, :-1, :, :] semi = softmax_channel(semi) semi_map = np.squeeze(semi, axis=0) # (64, Hc, Wc) # 网格分数取最大值，得到 Hc x Wc 的响应图 scores = semi_map.max(axis=0) # NMS找局部峰值，然后映射到原分辨率坐标 kpts_local = nms_peak(scores, size=nms_size, thresh=conf_thresh) # 根据关键点网格位置采样描述子（双线性），并做L2归一化 kpts = [] descs = [] for y_grid, x_grid in kpts_local: x = (x_grid + 0.5) * 8.0 y = (y_grid + 0.5) * 8.0 d = sample_descriptor(desc, x / 8.0, y / 8.0) d = d / (np.linalg.norm(d) + 1e-12) kpts.append([x, y]) descs.append(d) # 按分数排序截断top_k ... return np.array(kpts), np.array(descs)

LightGlue的ONNX Runtime推理：

import onnxruntime as ort def match_lightglue(session, kpts0, desc0, kpts1, desc1, max_k=1024): # 坐标归一化到[-1, 1] kpts0_norm = normalize_kpts(kpts0, img_w, img_h) kpts1_norm = normalize_kpts(kpts1, img_w, img_h) # 固定形状，不足补-1/0 k0, d0, mask0 = pad_to(kpts0_norm, desc0, max_k) k1, d1, mask1 = pad_to(kpts1_norm, desc1, max_k) feed = { "kpts0": k0.astype(np.float32), "descs0": d0.astype(np.float32), "kpts1": k1.astype(np.float32), "descs1": d1.astype(np.float32), "mask0": mask0.astype(np.float32), "mask1": mask1.astype(np.float32), } matches0, matches1, scores = session.run(None, feed) return matches0, matches1, scores

这里有个细节：padding的时候要额外传一个mask张量，告诉LightGlue哪些点是真实关键点、哪些是填充位，否则模型会把填充位也当成特征点参与注意力计算，输出一堆脏匹配。

4. 性能测试协议与实测数据

4.1 测试指标与边界定义

性能测试如果只报一个“端到端FPS”其实很糊弄人，因为你不知道瓶颈在哪个模块，也没法判断优化方向。我的做法是把整条链路拆成几个可独立测量的阶段：图像预处理、SuperPoint NPU推理、关键点后处理、LightGlue匹配、RANSAC几何验证。每个阶段分别计时，统计连续运行100帧的平均值、P95值和最大值，其中P95比平均值更能反映实际卡顿情况，因为边缘设备的调度抖动经常会把尾部延迟拉得很难看。

测试环境也需要固定：室温25度，板子加装铝合金散热片加一个小风扇，CPU governor设置为performance模式，NPU频率固定到最高档。如果不做这一步，大核在满负荷跑几分钟后就会因为温控降频，延迟数据会一路飘高，你根本分不清是算法慢还是散热跟不上。

4.2 分模块延迟实测

640x480分辨率、top-K=1024、LightGlue最大匹配数1024的实测数据如下：

LightGlue的时间跨度大，是因为它和实际关键点数强相关。特征点少的时候110ms可以搞定，关键点接近1000时就要180ms左右。这也是为什么模板特征离线缓存很重要：查询图单独走一遍提取和匹配，实际线上延迟比双侧都实时计算要低一截。

用固定形状1024跑ONNX Runtime、开6个线程的情况下，LightGlue内部的时间分布大概是：线性投影约10%，自注意力+交叉注意力约70%，匹配头约20%。如果后续想优化，减层数或者换小模型维度是更直接的手段。

4.3 温控、功耗与线程绑核对性能的影响

这部分数据是“意外收获”。我在裸板、无散热、仅靠自然冷却的情况下跑30分钟连续推理，大核温度升到80度以上，RK3588开始主动降频，A76从标称频率一路往下掉，LightGlue的单帧推理时间从120ms涨到190ms，端到端FPS直接从6掉到4。加装散热片和风扇后，温度稳定在60度左右，延迟恢复到正常水平。

线程绑核的收益也很明显。默认情况下ONNX Runtime会自己开线程，但系统调度器可能把线程在小核和大核之间乱跳。我用pthread_setaffinity_np把LightGlue的线程锁在4个A76大核上，P95延迟降低了约15%，稳定性明显改善。代价是4个A55小核被闲置，但整个流程本来就是大核跑CPU密集任务，NPU负责CNN，小核没有不可替代的活要干。

功耗方面，整机在持续推理时约6~9W，其中NPU占大头、CPU其次。对电池供电的移动设备来说，这个功耗是可以接受的，前提是散热必须做足。

4.4 定位精度对比实验

精度因为我没有激光雷达这类真值设备，就用单应性重投影误差作为评估标准：人工把模板图变换到查询图里，得到理论上的角点坐标，再和算法输出的角点坐标对比，计算平均像素误差。测试集一共50组查询图，覆盖光照变化、旋转0~75度、尺度变化和部分遮挡场景。

SuperPoint加LightGlue的组合在视角变化超过60度、光照对比强烈时依然保持了内点率60%以上，这是传统方案完全做不到的。我印象最深的是一张低照度、带明显噪声的查询图，ORB方案直接匹配到全乱，LightGlue却还能稳定框出目标区域，这就是深度特征的价值。

5. 踩坑实录：文档里查不到的三个细节

5.1 RKNN转换时的upsample算子风波

第一次转换SuperPoint到RKNN，工具链就报了一个upsample相关的算子错误，定位到网络里的双线性上采样层。查遍文档和社区，发现不同版本的RKNN-Toolkit2对这个算子的实现差异很大，同一个ONNX图在旧版本里能过、在新版本里报错的情况都有。最后解决方式是：先用onnxsim简化计算图，把不必要的reshape和transpose消掉，然后换了工具链版本重新转换。如果你也遇到类似报错，不要急着改网络结构，先把工具链版本对齐到官方推荐版本，再用onnxsim规整一遍，大概率能绕过去。

还有一个隐蔽问题：导出ONNX时如果用PyTorch默认的opset版本过高，RKNN转换器会有一些不兼容提示。我最终固定用opset 13，各个版本工具链都稳定支持。

5.2 NPU越跑越慢：内存带宽和拷贝是隐形瓶颈

SuperPoint的NPU推理延迟看起来只有十几毫秒，但如果你把这个数字直接叠加到端到端计时里，会发现实测总延迟比各部分之和还要多出一截。排查后发现，问题出在NPU和CPU之间的数据拷贝：RKNN的inference输出是NPU内存里的张量，拿回CPU侧做后处理要经过一次内存映射和拷贝，描述子张量本身不小（H/8 x W/8 x 256个float），拷贝开销被忽视了。

解决办法有两个层面：第一，尽量复用rknn的输入输出buffer，不要每帧重新申请和释放内存；第二，把描述子输出从RKNN的默认格式转成连续内存布局，避免后续NumPy操作触发隐式拷贝。做了这两步之后，SuperPoint整段的实际耗时从“看起来的15ms”降到了“包含拷贝的18ms”，没有大改善，但端到端延迟里的“幽灵时间”消失了，数据更干净了。

5.3 相似纹理场景的误匹配处理

模板目标如果本身带有大量重复纹理（典型场景是包装盒上的规则条纹、地砖、散热孔阵列），LightGlue也会输出一些“高置信度但空间位置错误”的匹配对。我调过score阈值，发现一个反直觉的现象：阈值从0.95往下调，内点数确实增加，但误匹配增加得更快，RANSAC的内点比例反而下降。

后来我改成了两段式过滤：先用score阈值0.9保留足够多的候选匹配，再用RANSAC的重投影误差阈值从默认5.0收紧到3.0。效果比单纯抬score阈值好很多，因为RANSAC在几何层面约束的是“匹配点连线和单应变换是否一致”，比网络置信度更可靠。如果你也遇到重复纹理场景，我建议优先调RANSAC的内点阈值，而不是一味提高网络置信度阈值，否则会把正确的弱响应匹配也一起过滤掉。

目前在RK3588上，这套流程在640x480分辨率下可以稳定跑到5~7 FPS，模板特征离线缓存后线上负载还会更低。后续如果想把帧率再往上拉，方向其实很明确：把LightGlue的层数从满配减到中途退出（模型本身支持这种自适应推理策略），或者限制查询图的实际处理区域，都还能再省出不少延迟。我个人的建议是，先用CPU版把整条链路跑通，再逐个模块迁移到NPU，每迁移一步都做量化前后的精度对比，否则出了问题你根本分不清是量化损失还是代码bug。这套方案我已经在几个不同光照条件的场景下验证过，稳定性足够应付实际项目，希望对正在挑特征匹配方案的朋友有帮助。