前阵子我把 Ostrack 这个跟踪器成功跑通了环境是 Python3.9显卡是 RTX 5060数据集拿 LaSOT 的部分序列试水。整个过程比预想中多踩了几个坑尤其是新显卡带来的版本兼容问题折腾最久。这篇就把从零开始配置环境、准备数据、跑通训练和测试的完整过程记录下来给正准备复现目标跟踪模型的朋友做一个参考。这套流程同样适合其他基于 PyTorch 的 Transformer 跟踪器思路是通用的。1. 项目整体思路与方案选型1.1 Ostrack 的运行路径与复现目标Ostrack 是一个基于视觉 Transformer 的单目标跟踪器主流做法是用 ViT 作为骨干网络在每一帧上输出目标的位置框核心卖点是去掉了传统 Siamese 结构里的互相关分支改成在 Transformer 内部完成目标特征与搜索区域特征的融合。对我这种习惯把代码跑通再谈精度的人来说复现工作其实可以拆成四个环节环境依赖、数据集组织、模型参数加载、训练或测试脚本执行。很多人一开始会被 Ostrack 的仓库结构吓到里面既有 lib/train 的训练逻辑又有 tracking 的测试逻辑还有一堆 experiment 配置文件看起来层级很深。实际不用怕整个工程的入口是非常清晰的训练入口走 run_training.py测试入口走 test.py你只需要关心数据和配置两个点代码本身不需要大改。复现目标要定清楚不是每个人都要从零训一个和论文对齐的模型而是先在本地环境验证代码能不能跑、显存够不够、模型能不能正常输出结果。所以我建议第一次跑的时候拿 LaSOT 的少量序列加一个公开权重先做推理确认全链路通了再决定要不要启动完整训练。1.2 为什么用 Python3.9 加 RTX 5060 这个组合选择 Python3.9 不是拍脑袋很多目标跟踪项目在依赖声明里锁定了 Python 3.8 到 3.10 的范围3.9 是一个兼容性最稳的中间值。尤其当项目里同时用到 PyTorch、OpenCV、各类数据处理库时3.9 几乎不会碰到“这个库只支持到 3.8”或者“新库已经放弃 3.9”的尴尬局面。RTX 5060 这档显卡在个人复现场景真的很有代表性。显存规格有 8GB 和 16GB 两种版本我手上这张是 16GB跑 Ostrack 这类模型比较从容。这套组合的好处是既不用依赖实验室集群又能在本地完成大部分训练和验证工作坏处是 Blackwell 架构比较新对 CUDA 和 PyTorch 的版本要求相当苛刻装环境的时候不能无脑按老教程来。另外要纠正一个误区模型能不能跑不是光看显存大小还要看 PyTorch 是否官宣支持你这个新显卡的架构。老版本 PyTorch 针对旧架构优化拿到新卡上经常会出现“no kernel image”这种奇怪报错让你觉得是显卡坏了其实是编译时的内核镜像没覆盖到新卡。1.3 为什么以 LaSOT 部分序列为例LaSOT 是一个大规模长时跟踪数据集完整下载需要几十 GB测试集就有 200 多个视频如果每次改动代码都要全量跑一遍时间成本非常高。所以我选择了“部分序列验证”这个策略先挑 4 到 5 段属性差异大的序列把训练和测试流程走通再根据情况扩展。挑选序列也是有讲究的。我一般会选一段快速运动的比如骑自行车或者跑动的场景一段有遮挡的比如目标穿越树丛一段有尺度变化的比如相机靠近和拉远再加一段目标形变明显的比如动物转身或者飞机翻转。这样做的目的是在最短的时间里覆盖跟踪过程最常见的干扰因素快速判断代码和数据是不是正常。用部分序列还有一层好处方便手动检查结果。你对着几段视频一帧一帧看比看几十个视频的平均精度指标更直观。环境验证阶段不需要追求数值完全对齐只要视觉上不漂移、成功率合理就可以放心进入下一步。2. 环境准备Python3.9、驱动与 PyTorch 三方匹配2.1 创建 Python3.9 虚拟环境不管是用 Conda 还是 venv我强烈建议单独给项目建一个虚拟环境不要直接装进系统 Python。目标跟踪项目依赖多且容易冲突隔离环境可以省去无数重置环境的烦心事。conda create -n ostrack python3.9 -y conda activate ostrack pip install --upgrade pip基础依赖建议手动装不要一上来就pip install -r requirements.txt。先装这几类东西pip install numpy opencv-python pillow scipy pyyaml tqdm matplotlib tensorboardX装 OpenCV 的时候有些系统会遇到 libGL.so.1 缺失的问题这是没装系统图形库导致的。Debian/Ubuntu 类系统可以执行apt install libgl1CentOS 类系统则对应安装 libGL 相关包。这个问题很常见先解决掉再继续否则后面跑数据加载必报错。2.2 RTX 5060 的 PyTorch 与 CUDA 匹配问题这是我这次踩过最大的坑单独拿出来写一节。RTX 5060 属于新架构显卡如果按网上一些老教程安装 CUDA 11.8 配 PyTorch 1.13代码运行时会直接报“CUDA error: no kernel image is available for execution on the device”。这个报错不是说代码有问题而是 PyTorch 自带的 CUDA 内核没有针对新卡架构做编译。解决办法很直接安装支持新架构版本的 PyTorch。建议使用 PyTorch 官方发布的 cu128 及以上版本轮子安装命令大致如下pip install torch torchvision --index-url https://download.pytorch.org/whl/cu128安装完成后务必验证一下 PyTorch 能否正常调用显卡python -c import torch; print(torch.__version__); print(torch.cuda.is_available()); print(torch.zeros(1).cuda())如果能正常打印 CUDA tensor说明环境基本没问题。这一步验证非常重要很多人在这一步就卡住了后面还以为是模型代码的锅。显卡驱动也要注意更新到比较新的版本否则即使 PyTorch 版本对了底层驱动仍可能不认识新卡。建议直接去显卡厂商官网下载最新驱动或者用系统自带的驱动更新工具保持驱动在一个较新的状态。2.3 依赖安装顺序与避坑清单依赖安装顺序是有讲究的。我有一个习惯先把 PyTorch 全家桶装好再装项目里的其他依赖。原因是很多 requirements.txt 里会把 torch 写成类似torch1.9.0的旧版本直接执行会把新装好的 PyTorch 给降级回去导致新显卡又无法识别。另外要注意 torchvision 与 torch 的版本对应关系不能随便混装。PyTorch 官方一般有版本对应表按照对应关系安装就不会出问题。判断版本是否匹配有个简单办法跑一次数据加载和 tensor 转换如果出现_C相关报错基本都是 torch 和 torchvision 的版本搭配有问题。依赖安装完成后可以用下面这段代码快速自检import torch import torchvision import cv2 print(torch:, torch.__version__) print(torchvision:, torchvision.__version__) print(opencv:, cv2.__version__)我之前遇到过一个情况torch 正常但 torchvision 导入时报undefined symbol排查半天发现是两个版本跨了两个大版本。所以用官方源安装、版本号仔细核对是避免踩坑最有效的手段。3. 数据准备LaSOT 部分序列的下载与组织3.1 LaSOT 标准目录结构LaSOT 数据集的原始目录组织有固定规律通常是类别文件夹下面再套视频文件夹视频文件夹里是 img 序列和 groundtruth.txt。举例来说LaSOT/ airplane/ airplane-1/ img/ 00000001.jpg 00000002.jpg ... groundtruth.txt airplane-2/ ... bird/ bird-1/ ...理解这个结构很重要因为 Ostrack 在读取 LaSOT 数据时需要根据视频路径拼接出 image 路径和 groundtruth 路径如果目录层级对不上后面测试脚本会直接报文件找不到。有些下游项目还会把 GT 文件转成 json 格式统一管理 train/test 序列。这时候你只需要准备一个 json 文件里面记录每个视频的 image 路径、首帧位置、GT 序列就够用了不一定非要直接改代码里的路径拼接逻辑。3.2 从全量测试集抽出部分序列我通常的做法是先把 LaSOT 官方的测试集 json 拿到手然后写一个简单脚本只保留自己挑好的那几段序列。下面是示意代码字段名需要根据你所用仓库的实际读取逻辑做调整import json with open(lasot_test_full.json, r, encodingutf-8) as f: data json.load(f) # 只保留这几个视频 selected_keys [ airplane-1, bird-1, bicycle-1, bolt-1, ] subset {key: data[key] for key in selected_keys if key in data} with open(lasot_test_subset.json, w, encodingutf-8) as f: json.dump(subset, f, ensure_asciiFalse, indent2) print(done, subset keys:, list(subset.keys()))注意ensure_asciiFalse这个参数如果 json 里包含非英文字符不设置它会变成一堆\uXXXX虽然不影响解析但排错时看着不舒服建议写上。3.3 路径配置与数据一致性校验数据准备好之后还要修改 Ostrack 的配置文件把数据根目录指向你放 LaSOT 的文件夹。这里要提醒几个细节路径不要带中文不要带空格层级不要太深Windows 下的反斜杠最好统一转成斜杠。配置完路径后我建议先做一个数据一致性校验比直接跑训练脚本更省时间。检查内容包括视频里 GT 的帧数是否和 img 目录下的图片数量一致、首帧 bbox 坐标是否在图片尺寸范围内、图片能不能正常用 OpenCV 读出来。这些看着琐碎但大多数跟踪任务跑飞都不是模型问题而是 GT 没对上帧。也可以在数据加载逻辑里手动打印几条信息出来验证sample subset[list(subset.keys())[0]] print(sample[video_dir]) print(sample[img_names][:5]) print(sample[gt_rect][:5])到这里数据处理这一环就算走完了接下来才是真正烧显卡的阶段。我个人建议第一次跑的时候先不要直接开训练先加载预训练权重做推理确认整个数据链条是通的。4. 实操流程从配置到跑通训练与测试4.1 修改 Ostrack 训练与测试配置Ostrack 的配置一般集中在 experiments 目录下文件名会包含数据集名和模型结构名。我这次的步骤是复制一份 LaSOT 相关配置模板改名为自己的实验名然后修改三个关键位置。第一个是数据路径。把 DATA 段落里的 root 指向 LaSOT 目录把 json 文件路径改成刚才生成的 subset json。第二个是模型参数。如果你用的显卡是 8GB 显存版本建议把 batch size 降到 4图像输入尺寸如果允许的话也可以略微下调16GB 版本相对从容但也不要盲目开大。第三个是硬件配置。把并行相关的 worker 数量调低一些避免数据加载把 CPU 占满显卡反而在等待。训练与测试的启动命令不同版本之间会有差异我这里给出主流程示意具体参数以你本地仓库 README 为准# 训练入口示意 python -m torch.distributed.launch --nproc_per_node 1 --master_port 29500 \ lib/train/run_training.py \ --script ostrack \ --config ostrack/lasot_base_384 # 测试入口示意 python tracking/test.py \ --tracker_name ostrack \ --tracker_param lasot_base_384 \ --dataset lasot \ --subset test4.2 用预训练权重先跑通测试链路在投入训练之前我强烈建议先下载官方发布的预训练权重把它们放到合适的 checkpoint 目录然后直接跑推理测试。这么做有三个好处验证环境是否完全健康、验证数据组织是否被代码接受、验证显卡上的推理速度是否符合预期。测试脚本跑完后结果会保存在 results 目录下通常是每个视频对应一个 txt 文件里面记录的是跟踪算法预测出的目标框坐标。我第一反应是去逐行比对坐标是否合理或者把预测结果画到视频上肉眼看效果。这一步一旦通了训练链路基本就只剩显卡资源问题代码上的问题已经排除了。我当时的体验是加载权重后单个视频的推理速度比较快肉眼看着也不怎么漂移这说明显卡驱动、预处理、模型前向、后处理都是正常的。这时候才真正有了继续训练的信心。4.3 训练启动、显存监控与日志解读启动训练后要做的第一件事是看显卡状态而不是看 loss。用nvidia-smi看显存占用和 GPU 利用率确认模型真的在显卡上跑起来了。如果显存占用为 0 或者 GPU 利用率极低大概率是数据加载卡住了或者并行参数没设置对。训练日志也值得多看一眼。Ostrack 的日志里会周期性打印 loss 数值刚开始 loss 高是正常的但如果几百步之后 loss 完全没有下降趋势可能是学习率设置不合适也可能是训练数据里有 GT 异常。另外要注意日志里的吞吐量也就是每秒能处理多少帧。RTX 5060 在 384 分辨率输入下吞吐量可能不会像高端卡那么夸张但稳定性更重要不要因速度慢而盲目调高 batch size结果 OOM。显存不够的时候我一般按这个顺序处理先调低 batch size再考虑关掉混合精度之外的可选模块最后再看是否需要把输入分辨率降到 320。千万不要一上来就换模型结构那是最后一步才考虑的事情。4.4 结果评估与结果可视化测试完成之后需要用官方评估脚本或者自己的工具计算成功率、精度等指标。LaSOT 评测一般用成功率曲线下的面积AUC和归一化精度作为核心指标。不过我这次跑部分序列更加看重的是逐帧可视化结果毕竟样本少看视频远比看曲线直观。可视化的做法很朴素把预测框和 GT 同时画在每一帧上然后用 OpenCV 的 VideoWriter 写成 mp4 文件。如果预测框能持续锁住目标不出现大面积偏移就说明模型和数据处理都没问题。如果某一帧出现明显漂移就回看那一帧之前的输入判断是 GT 错误还是跟踪器本身失败。这里有个小习惯想分享我不喜欢只看跟踪器自己输出的框因为你会下意识忽略模型失败的地方。把 GT 画成一种颜色预测框画成另一种颜色并排在画面上就能很直观地看出偏差大小这对检查数据质量问题非常管用。5. 常见问题与排查技巧实录5.1 显存不足与输入参数调整单目标跟踪模型本身不算太吃显存但训练时的 batch size 和数据增强管道会显著拉高占用。在 8GB 显存版本的 5060 上如果直接按 64 batch size 的默认配置跑大概率会 OutOfMemory。这个问题没什么玄学就是把 batch size 降下来同时把数据加载线程数控制在 4 到 8避免内存峰值过大。如果你不小心把 batch size 调得太低导致模型拟合困难也不用慌。一个折中办法是先用小 batch 跑通再逐步调高观察显存占用与 loss 变化找到一个平衡点。我的经验是 384 分辨率、16GB 显存、batch size 8 是一个比较稳的起点。5.2 数据路径与 JSON 结构不匹配这类报错在跟踪项目里非常常见通常是“FileNotFoundError”或者“KeyError”。大部分原因是 json 里的 image 路径是相对路径而代码内部会基于 data_root 去拼接如果你的 json 里路径字段多了一层或少了一层就会差一个目录直接找不到图。排查思路很简单拿报错信息里的完整路径去文件系统里手动确认是否存在如果存在再看代码里究竟是拿哪个字段去拼接的。把 json 里的路径改成和代码逻辑一致比改代码更快因为数据文件的修改成本低很多。5.3 PyTorch、TorchVision 与驱动版本不匹配这类问题往往表现得很诡异导入库的时候不报错一跑训练就崩或者 CPU 模式下能跑一切到 GPU 就出问题。常见原因是 PyTorch 版本较老不支持新显卡架构或者 torchvision 和 torch 的版本组合错位。处理办法是从 PyTorch 官方版本索引中选择支持你显卡架构的 cu128 对应版本然后严格按官方给出的 torch/torchvision 配对关系安装不要混用其他渠道预编译的包。装好之后再跑一遍torch.zeros(1).cuda()做自检通过了再继续。5.4 训练卡死与线程数爆满有些时候训练没有报错但 loss 长时间不更新GPU 利用率却很漂亮地维持在 0%多半是数据加载卡住了。常见原因包括数据读取线程数设置过大导致 CPU 资源耗尽或者训练数据中某些视频的图片损坏导致进程等待。处理方法是把 DataLoader 的 worker 数调小并在启动脚本里设置合理的线程数环境变量export OMP_NUM_THREADS4同时检查 LaSOT 数据里是否有损坏图片可以用脚本把所有图片都读一遍把读取失败的路径打印出来提前清理掉。这个小动作能省下一整晚的无效训练时间。6. 最后分享一点实际感受这次用 Python3.9 加 RTX 5060 跑 Ostrack我最深的体会是新架构显卡带来的环境兼容问题有时比模型本身更费时间。你花了一整天去查“为什么 CUDA 报错”结果只是 PyTorch 版本不对。所以如果你也是新卡片先别急着改代码把 PyTorch 装到最新支持版本再一步步走推理和训练会顺很多。从流程上看我强烈建议新人复制我的节奏建环境、验 CUDA、抽部分序列、加载预训练权重做测试整条链路通了再投入正式训练。这样每一步都有明确反馈出了问题也容易定位。等你把 LaSOT 部分序列跑顺之后就可以继续扩展到 GOT-10k 或者自定义视频这个项目能玩的东西还很多。
