YOLOv8低帧率追踪优化：光流法运动补偿实践指南

如果只看过YOLOv8的检测demo，你大概率会觉得视频追踪不是难事：每帧检测，做一做框的匹配不就完了？真正跑到实际项目里，尤其是在低帧率场景，你会发现这是完全两码事。我自己就栽过跟头。有个监控类的项目，为了省带宽，把视频压到了5帧每秒，结果YOLOv8自带的那套基于检测框关联的追踪逻辑，直接变成"连连看"，目标一帧一帧跳，ID反复横跳，轨迹也跟着乱。后来我用光流法做运动补偿，把整个追踪管道重新搭了一遍，才算把问题解决。这篇文章，就把这套思路从头到尾讲清楚。

低帧率视频追踪的难点在于"信息断层"。目标在两帧之间走了一大段路，外观、位置、尺度全变了，单靠YOLOv8的检测输出去做关联，根本对不上。光流法恰好能补上这块空白——它用相邻帧的像素位移估计运动方向，让追踪器在检测结果还没出来之前，先把目标位置"推"到下一帧。这套"检测为主、光流为辅"的思路，适合几乎所有的低帧率追踪场景：带宽受限的监控回传、无人机巡航、工业质检的抽帧处理，都能直接套用。如果你正准备把YOLOv8从单纯的检测升级为能在低帧率真实场景落地运行的追踪系统，这篇文章正好对症。

1. 低帧率为什么这么难：先理解"帧间隔"的放大镜效应

1.1 帧间隔变大，目标位移和外貌变化被同时放大

很多人一开始意识不到，帧率对追踪的影响不是线性的，而是放大的。以30帧每秒的视频为例，假设一个行人以正常速度从画面左侧走到右侧，单帧之间的位移可能只有三五个像素。这时候物体在相邻帧里几乎"没怎么动"，检测框的交并比（IoU）很高，随便用个贪心匹配都能把同一目标接上。

但如果你把视频变成5帧每秒，目标在一帧间隔里可能移动了几十个像素甚至上百个像素。这个位移量一上来，问题就多了。首先是检测框的重叠区域急剧下降，前一帧的框和当前帧的框可能只在角落里碰一下，IoU掉到0.1以下，IoU追踪直接失效。然后是外观变化：运动模糊、光照变化、姿态切换，都会在帧率变低之后被放大。原本靠特征匹配还能认出来的目标，现在第一眼看上去就像换了个人。

更要命的是尺度变化。低帧率下，物体前后帧之间的距离变化也放大了，目标由远及近或由近及远的速度看起来特别快。一个在上一帧还只占画面千分之一的目标，下一帧可能已经大了一圈。追踪器如果只依赖原始检测框做尺寸外推，很容易把框越拉越大或越缩越小，最后框里全是背景，目标反而跑到了框外。

1.2 数据关联的经典约束被打破

追踪的本质，是把每一帧的检测结果串联成一条带有固定ID的轨迹。这里面的核心操作是"数据关联"——判断当前帧出现的检测框，到底对应历史轨迹里的哪一个目标。绝大多数常见追踪器都默认一个隐含条件：相邻两帧之间，同一个目标的位置变化不大，外貌变化也不大。

低帧率把这个隐含条件直接推翻了。位置变化大，IoU约束就失效；外貌变化大，重识别特征就不稳定。再加上低帧率视频往往伴随着压缩伪影、运动模糊，检测器本身都可能漏检。一旦漏检，追踪器找不到匹配的检测框，只能靠插值把轨迹硬延下去，延迟一两帧还行，延迟三五帧以上轨迹就完全失真了。

这也是为什么很多人在低帧率数据上跑YOLOv8的官方追踪demo，会发现同一行人的ID一会儿是3一会儿是7，轨迹线在画面里画成一团毛线。不是模型出了问题，是追踪器的数据关联假设根本不适用于这种帧率环境。你必须给追踪器补充额外的运动信息，光流法就是干这个用的。

1.3 现实里哪些场景最容易遇到低帧率

学术界做追踪研究默认用的是30帧甚至60帧的公开数据集，但真实项目里低帧率到处都是，而且往往是不能妥协的硬约束。

最容易遇到低帧率的就是带宽受限的回传链路。有些现场视频需要从远端设备传到中心服务器做分析，传输带宽只有几百Kbps，为了保住画质只能降帧率，最后传到服务器的往往只有三到五帧每秒。还有低功耗设备，像电池供电的野外监测相机、太阳能供电的巡检装置，处理器算力有限，连续跑检测发热量太大，只能隔几帧抽一帧分析。无人机巡航也是重灾区，飞机的电池和存储都有限，很多时候只能按固定间隔拍照而不是录满帧视频，照片之间的时间差可能达到几百毫秒甚至一秒以上。

在这些场景里，你不能等帧率提升了再做追踪，只能靠算法去弥合帧与帧之间的信息断层。这也是光流法+低帧率追踪这个方向一直有需求的原因。想明白这一点，你就知道这套方案不是炫技，而是解决实际部署问题的刚需。

2. 光流法原理与选型：稀疏还是稠密，别选错

2.1 光流法解决的是"不知道目标去哪"的问题

光流法的任务很直白：给定两帧图像，计算出画面中每个像素（或者某些特征点）在两帧之间的运动方向与速度。它输出的是一组运动矢量，告诉你可以理解为"这些像素点从上一帧的位置移动到了当前帧的哪个位置"。

追踪场景里，光流法不是替代检测器，而是给检测器当"外挂"。检测器干的是"认东西"的活，光流干的是"找位置"的活。两者配合起来，追踪器就有了两条信息来源：一条是外观识别，一条是运动预测。低帧率下外观变化大，检测不可靠，但运动预测只要有连续两帧的信息，就能给目标位置提供一个非常强的先验。

我刚接触光流法时有个误解，以为它只能处理运动幅度特别小的场景。后来才发现，真正决定适用范围的是你选了哪种光流方案，以及参数怎么配。选错方案、配错参数，光流一样追不上低帧率下的快速目标。

2.2 两个基础假设：亮度恒定与微小运动

光流法背后有两个核心假设，理解假设才能理解参数的意义。

第一个是亮度恒定假设。它认为同一个点在运动过程中，其像素亮度在前后帧保持不变。这是光流的出发点，也是所有后续推导的基石，但这个假设在现实里很容易被打破：光照变化、阴影切换、动态模糊，都会让同一个点的亮度发生明显改变。低帧率视频因为帧间隔大，亮度的变化也更大，所以实际使用中必须通过预处理、灰度化、均衡化等操作来尽量降低光照干扰。

第二个是微小运动假设。它假设目标在两帧之间的位移足够小，这样才能在邻域范围内通过求导来计算运动。低帧率场景恰恰违背了这个假设，所以我们要借助图像金字塔，把原始图像一层层缩小，大位移就变成了小位移。这也是为什么做低帧率追踪时，金字塔的层级设置一定要够深，否则光流计算出来全是噪声。

2.3 稀疏光流和稠密光流怎么选

光流法分成两大流派，稠密光流和稀疏光流，应用场景完全不同。

稠密光流对每个像素都计算运动矢量，输出一个和图像尺寸一样大的运动场。它对场景的建模非常完整，能看出物体边界、遮挡区域、背景滚动等细节，但代价是计算量大，实时性不佳。在低帧率追踪场景里，你本来就是因为算力或者带宽紧张才降的帧率，再上稠密光流，整条管线可能跑不过实时。

稀疏光流则聪明得多，它只对少量特征点计算光流。先挑出画面里那些纹理明显、不容易弄混的点（比如角点、边缘交叉点），再跟踪这些点的移动。计算量小，速度极快，适合嵌入式设备和实时场景。缺点也很明显：它只知道特征点怎么动，不知道整个场景怎么动，如果目标内部没有足够的特征点，跟踪质量就会下降。

具体到追踪目标框的场景，我的选择很明确：先用稀疏光流的思路，在检测框内采样并跟踪特征点，再用这些点的位移推算整个框的位移。因为我们要追踪的是"目标框"，不是要重建整个场景的逐像素运动场，稀疏光流的信息量已经足够。

2.4 辅助追踪到底辅助在哪一层

有人会把光流法直接当作"追踪器"来用，跟踪一堆特征点就完事，这是常见的误解。纯光流追踪的问题在于，跟踪的特征点没有语义，时间一长就会飘到背景上去，也没有办法区分不同的目标类别。真正稳妥的做法是让光流法辅助YOLOv8的检测结果，不在底层替代检测，而在上层辅助关联。

具体来说，追踪器手里维护的是YOLOv8检测出来的目标框，光流法的作用是在帧间隔中帮追踪器提前预测这些目标框的新位置。检测到的那一帧，用YOLOv8的结果修正预测；没检测的那几帧，用光流把框推着往前走。这样一来，追踪器对检测的依赖从"每帧都需要"降到了"隔几帧需要一次"。

这套组合还有一个额外好处：当光流预测出的位置和YOLOv8检测出的位置差别很大时，大概率是出现了遮挡、误检或者漂移，这个不一致信号本身就能被用来做异常判断，可以帮助系统决定是跟还是丢。这在纯检测追踪的架构里是没有的。

3. 方案落地：把光流法"焊"进YOLOv8追踪管道

3.1 整体管道设计与状态机

这套方案的整体流程不长，核心思路围绕"关键帧检测 + 中间帧光流外推"展开。

运行流程分成两条分支。每到预设的关键帧，对当前帧跑YOLOv8检测，拿到目标框列表；把这些框和历史轨迹做关联，匹配成功的用于更新轨迹，匹配不上的新框创建新轨迹，已经跟丢的轨迹标记失活。没到关键帧的那些中间帧，不跑YOLOv8，而是对每条存活轨迹的上一帧位置做光流计算，得到当前帧的预测框。这两条分支交替执行，追踪器就在"检测"和"预测"之间来回切换。

这里有个关键点：关键帧的检测结果非常重要，而后光流预测结果作为候选框的"先验"，能大幅简化关联匹配的负担。在低帧率下，如果你把当前帧所有新检测框和历史轨迹直接做IoU匹配，效果很差，因为框和框可能根本不重叠。但如果你先用光流把历史轨迹的位置推到当前帧，拿推之后的预测框去和检测框算IoU，重叠度就高多了，匹配成功率自然上去了。

3.2 轨迹对象如何设计：决定工程上限

低帧率追踪的工程复杂度一大半来自轨迹对象的设计。就算光流预测再准，轨迹状态管不好，照样会乱。

我的轨迹对象里至少包含这些字段：轨迹ID、目标类别、当前目标框坐标、预测框坐标、历史框队列、状态（活动/静止/丢失）、最近一次检测的置信度、连续丢失帧计数、以及上一帧的图像位置。其中最重要的字段是"预测框"和"连续丢失帧计数"。预测框是光流外推的产物，直接参与关联匹配；丢失帧计数则决定一条轨迹什么时候被正式宣告死亡。

状态机部分我建议把轨迹分成三档：TRACKED表示当前帧有检测框或者光流预测成功，ACTIVE表示虽然没有检测但光流仍在延续，LOST表示光流都救不回来了，等待删除。为什么不能用简单的一刀切？低帧率下漏检太频繁了，你如果连续三帧没有检测框就删轨迹，目标稍微被遮挡一下就丢ID，后面重新出现又要新建轨迹，等于没追踪。搞了ACTIVE这个中间态以后，ID的稳定性明显好转。

3.3 关键帧与光流外推的具体逻辑

关键帧间隔是整个方案最核心的超参数。间隔选得越小，越接近全帧检测，准确率有保证但算力压力大；间隔选得越大，算力省了，但光流要承受的外推距离越长，误差累积越严重。

我的经验是从"检测间隔3到5帧"开始调。假设视频是5帧每秒，3帧间隔意味着大约1.5秒才做一次检测，中间4帧靠光流推，这对算力非常友好，但需要光流质量足够高。如果你发现轨迹在预测阶段频繁漂移，可以试着把间隔缩到2帧，或者把关键帧设置成"固定间隔+置信度触发"的混合模式：距离上一个关键帧超过N帧时强制检测，同时如果光流预测置信度低于某个阈值，也提前触发检测。

光流外推的具体操作是这样一步步来的。首先从目标框内部选取特征点，不是每个像素都选，而是选那些角点响应值高、纹理丰富的点，一般每个框选50到100个点足够。用上一帧作为参考，把这些特征点做光流匹配，找到它们在当前帧的位置。接着计算这些特征点的位置变化量，求一个平均位移或者用中位数位移，作为整个目标框的平移向量。最后把上一帧的目标框坐标加上这个平移向量，得到当前帧的预测框。

要注意尺度变化。如果只做平移，目标在靠近相机时框会越推越不准。我在实操中会把特征点之间的平均距离变化也计算进去，得到一个尺度缩放因子，同时修正框的宽高。这样虽然多了一点计算量，但低帧率场景下目标的尺度变化往往很明显，这步省不得。

3.4 核心代码：追踪循环的伪代码实现

下面这段是追踪主循环骨架，用清晰结构展示"检测帧"与"光流帧"的交替逻辑。

def run_tracking(video_source, detect_interval=3): tracker = TrackManager() last_frame = None frame_idx = 0 while True: current_frame = read_frame(video_source) if current_frame is None: break # 第一帧或者关键帧：做YOLO检测 if frame_idx == 0 or frame_idx % detect_interval == 0: detections = yolo_inference(current_frame) matched_ids = set() # 能匹配的先匹配 for det in detections: candidates = tracker.predict_bboxes_for_frame(frame_idx) best = match_detection_to_track(det, candidates, iou_threshold=0.2) if best is not None: tracker.update_track(best, det, current_frame) matched_ids.add(best) # 新目标建新轨迹 tracker.create_new_tracks(detections, matched_ids, frame_idx) # 中间帧：只做光流外推 else: if last_frame is not None: for track in tracker.active_tracks(): # 在目标框内采样特征点，用光流推到当前帧 newest_bbox = track.boxes[-1] pts = sample_feature_points(last_frame, newest_bbox) moved_pts = optical_flow_forward(last_frame, current_frame, pts) track.predict_bbox = extrapolate_bbox(newest_bbox, pts, moved_pts) tracker.decay_lost_tracks(max_lost_frames=5) tracker.render(current_frame) last_frame = current_frame frame_idx += 1

代码里最有价值的是extrapolate_bbox这一步，它对应的就是前面说的平移加尺度修正。我这里把关联阈值设到0.2，比正常同帧检测的阈值低很多，因为你拿的是光流预测框和真实检测框做匹配，两者天然会有偏差。如果你把IoU阈值设成0.5，大概率啥也匹配不上，一切努力白费。

4. 参数标定与避坑：光流不是加上就能用

4.1 金字塔层数和窗口大小

光流参数里，金字塔层数和窗口大小最影响低帧率场景的表现。

金字塔层数决定了算法能扛住的最大位移。低帧率下目标单帧移动几十个像素很正常，就需要往上多放几层金字塔。我自己常用的起点是4到5层，对大多数640x640的输入图来说，5层金字塔能把位移量级缩小到5个像素以内，光流算法容错率高很多。但层数也不是越大越好，层数太多，图像缩得太小，细节丢失，特征点反而可能跟丢。

窗口大小控制的是光流匹配的邻域范围，它决定了算法在多大范围内搜索对应的特征点。窗口设得小，定位精度高但容易跟不上快速运动；窗口设得大，能捕捉的位移范围广但精度下降。低帧率场景建议窗口设在21到31之间，同时把迭代次数适当提高，让每个点的运动估计更细化。

参数的直观感受就是：目标跑得快、帧率低，金字塔就往深处加；目标纹理丰富但位移幅度不大，就减小窗口换取精度。别想着找到一组万能参数，不同分辨率和不同运动速度的视频，大概率要单独调。

4.2 检测间隔如何选：算力与精度的折中

检测间隔是整个方案性价比最高的旋钮。设置得越密，追踪精度越接近全帧检测，但算力也越接近全帧检测，光流方案的优势就不明显了。设置得越稀，算力省得多，但光流误差累积越严重，轨迹漂移风险直线上升。

我一般用两个指标来定检测间隔：跟踪成功率要求多少，单帧可接受的推理耗时是多少。比如你的设备每秒只能跑2次YOLOv8推理，视频是5帧每秒，那检测间隔设为2是上限；如果设备能跑4次推理，检测间隔可以设到3，光流承担两帧外推，效果和算力之间比较均衡。

这里有个经验值得分享：检测间隔设置成"固定N帧"和设置成"不超过N帧且根据置信度触发"完全是两个体验。固定N帧实现简单，但遇到目标被严重遮挡或者光流质量差的片段，预测框可能早就飘到天涯海角了，固定间隔不会救你。混合触发机制在光流预测置信度低于阈值时提前做一次检测，能有效避免轨迹在几帧之内彻底跑飞。代价是代码复杂度高一些，调试点也多一些，但生产环境我强烈建议做成混合模式。

4.3 轨迹判丢与拉回策略

低帧率追踪最容易出现的两个问题，一个是轨迹不该丢的时候丢了，一个是轨迹该丢的时候死撑着不丢。两者都会让输出变得很难看。

不该丢的时候丢，往往是因为遮挡或漏检造成连续若干帧没有检测框。这时候光流虽然能推着框走，但推了一段时间后框里全是遮挡物，特征点全跟丢了，光流置信度骤降。我的拉回策略是：一旦发现目标被标记为ACTIVE，立刻降低它的输出权重，不让它参与最大匹配；但如果下一帧检测到它出现在预测框附近，就重新恢复到TRACKED。不要因为一两次漏检就删轨迹，连续丢失帧数一般可以放到5到8帧。

该丢的时候死撑着，问题出在另一头。有些目标出画或者被完全遮挡后，轨迹框停在原地，光流特征点找不到目标，但框里的背景纹理会提供"虚假光流"，导致追踪器以为目标还在动。解决办法是盯住特征点响应质量：如果特征点数量持续低于初始点数的一半，或者特征点的速度方向和历史平均方向差异太大，就果断把轨迹丢弃，别让一条死轨迹在画面里挂好久。

4.4 那些容易被忽略的"脏"工程细节

光流对输入图像质量非常敏感，这一点容易被低估。原始视频帧直接进光流算法，经常会因为噪点、压缩伪影、隔行扫描等干扰导致特征点匹配质量很差。我的习惯是先做降噪处理，比如做一次轻度的中值滤波或者高斯滤波，再把图像转到灰度空间。不要小看这一步，预处理干净了，光流成功率能涨好几个百分点。

另外，低帧率视频常有时间戳不均匀的问题。有些视频的帧间隔不是严格均匀的，中间可能突然停了几秒。如果在长停顿之后还用两帧之间的光流去推目标位置，位移量会爆炸。工程上要加一个时间戳检查：如果当前帧和上一帧的时间间隔超过正常值的2倍以上，强制把这一帧当成关键帧处理，让YOLOv8重新检测一次。

还有一个隐蔽问题：目标框边缘的特征点往往不稳定。框边缘容易混入背景特征点，拉伸时特征点数量分布不均，光流位移估计会被背景带偏。我采样特征点时，会故意在框中心区域多采样，靠近边缘的候选点优先级压低，宁可少采几个点，也不让背景点进来捣乱。

5. 评测方法：用降采样构造低帧率样本，量化改善效果

5.1 怎么构造低帧率测试集

很多人在项目初期根本找不到现成的低帧率标注视频，训练和验证成了无米之炊。其实最有效的办法是利用已有的高帧率视频，通过抽帧构造低帧率版本。

具体做法是一句线：取一段30帧每秒、目标运动连续的视频，每隔N帧抽一帧，形成3到5帧每秒的低帧率视频。因为是同一份视频，原始高帧率版本里目标的位置和轨迹是确定的，你可以直接把高帧率的标注下采样到低帧率时间戳上，当作真实轨迹。这样一来，你有了一份带ground truth的低帧率测试集，评测指标才能算得出来。

注意抽帧策略要讲道理。每隔N帧均匀抽，会模拟匀速运动的场景；如果想要模拟真实监控的随机性，可以用"随机抽帧+随机丢长间隔"的方式，有的地方间隔两帧，有的地方间隔七八帧，这样测试集更贴近真实环境的复杂性。

5.2 三个核心指标：追踪成功率、ID切换率、漂移距离

评测低帧率追踪，不能只看平均精度，那是检测竞赛的思路。追踪要看的指标主要有三个。

第一个是追踪成功率。高帧率视频中跟踪到的目标ID，在低帧率版本中还能保持同一ID的轨迹长度占比是多少。这个指标代表方案的"持续跟踪能力"，比例越高越好。

第二个是ID切换率。同一目标被错误分配了不同ID的次数。低帧率场景里，ID反复漂移是最令人头大的问题，ID切换次数越少，说明关联稳定性越好。这个指标对用户体验影响特别大，毕竟业务方最不能接受的就是同一个目标一会儿是"行人1"一会儿是"行人3"。

第三个是漂移距离。跟踪框的中心位置相对ground truth中心位置的平均偏差。低帧率下检测频率低，光流外推的预测框难免有偏差，但偏差如果超过目标尺寸的一半，基本就失去了追踪意义。这个指标直接反映光流外推的精度上限。

我在实际测试中会用一张对比表记录数据，格式如下：

从表格能看到，检测间隔3帧时综合表现最好，间隔再拉大，光流误差累积就让方案得不偿失。这些数字说明，光流辅助的价值在于"用少量的检测间隔换大幅的稳定性提升"，但也不是无脑拉大间隔。

5.3 计算成本与优化

低帧率追踪的核心优势就是省算力，但如果光流部分实现得粗糙，省下来的算力可能全被光流吃掉。光流计算确实比YOLOv8推理轻量，但你要注意它是对每条轨迹的目标框独立计算的，轨迹数量多时，总耗时也不可忽视。

我实测下来，单条轨迹的稀疏光流计算在普通CPU上大约需要几毫秒到十几毫秒，如果画面里有30个目标，一帧的光流总耗时可能到几百毫秒，这就不可接受了。所以生产环境里不能傻乎乎地对每个目标框都重新计算光流，要做两件事：第一，对每条轨迹只在一个小矩形邻域里搜索特征点，不要在整个画面上做光流；第二，如果同一画面中多个目标距离较近，可以复用附近区域的运动场，避免重复计算。

另一个优化点是降低光流计算频率。不是每一帧都要对所有轨迹更新光流，在检测间隔内，我们可以只对距离上次光流修正超过一定帧数的轨迹做一次更新。目标运动状态在一两帧内变化不大，没有必要每帧都算一遍光流，省下来的算力可以用来跑更频繁的YOLOv8检测，或者降低整机功耗。

6. 常见问题与故障排查手册

6.1 实测中的常见问题速查

低帧率光流追踪的坑，我在项目里几乎踩了个遍。下面这个表格是各种症状和对应排查思路的浓缩版本，调试的时候可以对照着看。

排查的时候别一上来就改光流参数，先把日志里的特征点数量、预测框坐标、检测框坐标全打出来，对照之前一段时间的表现找规律。大多数问题不是单点参数不对，而是"预处理/光流参数/关联逻辑"链条上某个环节没配合好。

6.2 几个值得复盘的排查案例

第一个案例是目标框在画面里反复横跳。我刚开始以为是对光流的位移估计不准，花了好久调金字塔层数，效果很有限。后来把中间帧的预测框和下一关键帧的检测框一起可视化，才发现是关联匹配环节的问题：IoU阈值设的0.5太高，预测框和检测框明明位置很接近，但IoU不到0.5，于是检测框被当成新目标建了第二条轨迹。把阈值降到0.2之后，问题立刻消失。这个教训说明，低帧率下IoU阈值必须放宽，别拿常规帧率下的经验硬套。

第二个案例是目标在画面边缘被遮挡后，轨迹框趴在边缘不动，后来甚至开始在其他目标身上"吸血"。排查之后发现，特征点已经全部跟丢了，但追踪器没有及时判断光流质量，靠背景的虚假光流硬撑着。后来我加了"特征点数量低于初始数量一半，连续两帧就去死"的规则，这类问题才批量消失。判断轨迹不要只看有没有检测框匹配，更要看光流质量本身，特别是低帧率下遮挡极多，轨迹判死逻辑必须果断。

第三个案例比较隐蔽，是时间戳不均导致的。某路视频源设备的帧率标称是8帧每秒，但实际上传时间戳忽快忽慢，间隔从100毫秒到800毫秒不等。大时间间隔跳变时，光流外推的距离远超过了正常范围，预测框直接飞到画面外。加了时间戳跳变检测，一旦间隔超过正常值2倍以上强制触发YOLOv8检测，问题就此解决。工程项目里，处理真实设备的时间戳抖动，往往比调整算法本身更能提升稳定性。

7. 个人工程笔记：最后的一些体会与建议

项目做到最后，我发现这套方案真正的难点不在于光流算法本身，而在于如何把它和YOLOv8的检测输出、轨迹的生命周期管理、真实设备的性能约束，严丝合缝地组装在一起。光流给追踪器提供了"预判未来"的能力，但这份预判一旦和检测关联不上，就成了噪声来源，所以每一步都要围绕"什么时候信预测，什么时候信检测"来做文章。

如果你也是第一次在低帧率场景下搞追踪，我建议先把检测间隔固定成3，把光流的金字塔层数设在5左右，然后在自己的数据上跑一遍，把预测框和检测框一起可视化出来。看到预测框能稳稳搭着检测框走，你自然就理解了这套方案为什么有效。之后再根据真实数据和算力约束去调参数，心里会清楚很多。

最后再分享一个小技巧。假设你的目标是省算力，但又不想牺牲太多追踪质量，可以考虑把YOLOv8的输入分辨率在关键帧和中间帧之间做区分：关键帧用高分辨率保证检测质量，中间帧的光流处理用降采样后的低分辨率，因为光流对细节的要求没有检测那么高。我在一个嵌入式的例子里用这个办法，把整体耗时又压低了将近四成。这个办法对你的场景大概率也有效，值得试一下。