TrackEverything：如何让AI记住一段1000帧长视频里的每一个点

你有没有想过，一段视频里，有多少点是被浪费掉的？

假设你拍了一段十秒钟的桌子俯拍视频，桌上放着一个杯子。杯子没动，但摄像机在缓慢平移。传统的视频算法会怎么处理这段视频？它会把每一帧都当成全新的画面，重新识别一遍杯子的边缘、颜色、位置。哪怕杯子压根没挪窝，算法依然要为它在第1帧、第2帧、第300帧分别生成一份独立的记录。

这就是这篇论文想解决的核心矛盾。视频越长，重复计算的浪费就越夸张,而这恰恰是"点追踪"这个研究方向卡了很多年的死结。

先说说什么是点追踪。

点追踪：给视频里选定的一个或多个点，追踪它们在后续每一帧里跑到了哪个位置，这是计算机视觉里理解物体运动、相机运动、场景结构的基础技术。

在这个领域里,一直存在一个让人很不舒服的选择题:你要长时间追踪,还是要追踪很多点,鱼和熊掌不可兼得。

稀疏追踪器（比如CoTracker3）可以追很长的视频，但只能追你事先指定的少数几个点，比如你点了杯子的把手，它就死死盯住这个把手追踪几百帧。而稠密追踪器想追踪画面里的每一个像素点，但代价是只能处理48到64帧的短片段，超过这个长度,显存直接爆掉。

这就好比你雇了两个保镖。一个保镖体力好，能跟你走一整天，但只能盯一个人。另一个保镖能同时盯住广场上所有人，但走不到十分钟就累瘫了。你要嘛牺牲覆盖面，要嘛牺牲续航,没有两者兼得的选项。

TrackEverything这篇论文的野心,是同时要两者。他们做到了追踪超过1000帧视频里的所有可见点，而且显存占用控制在40GB以内。这在此之前,没有任何一个稠密3D追踪方法能做到。

问题出在哪:2D世界的诅咒

要理解TrackEverything的巧妙之处，得先弄明白为什么之前的方法这么费显存。

答案是:它们都困在2D像素空间里出不来。

想象你在给一栋房子拍视频，镜头绕着房子转了一圈。房子的墙面被拍了很多次,从不同角度、不同帧里反复出现。但传统的稠密追踪方法压根不知道"这堵墙在第5帧和第50帧其实是同一堵墙",它只会认认真真地把每一帧的每个像素都存下来,当成全新的信息。

论文里给出一个具体的数字对比:如果要在一段512×512分辨率、200帧的视频里追踪所有点,按传统方式需要处理的预测量高达10的10次方级别。这不是夸张的说法,是实打实的计算量爆炸。

TrackEverything的核心洞察是:视频本质上只是三维世界的二维投影。

如果你把追踪这件事换到三维世界坐标系里做,同一块物理表面,不管在哪一帧被看到,它在三维空间里的坐标应该是同一个点。这样一来,复杂度就不再随视频长度线性增长,而是随场景里"独特物理内容"的多少增长。房间就那么大,墙就那么几面,不会因为你多录了十分钟视频,墙的数量就变多。

这个思路听起来简单，但真正落地需要解决三个技术难题：怎么去掉重复观测、怎么高效更新每个点的位置、怎么避免昂贵的匹配计算。这就是论文三个核心创新的由来。

体素去重:给三维空间发身份证

第一个创新叫做体素化去重机制。

体素：三维空间里的一个小立方体单元，相当于二维图片里"像素"概念在三维世界的延伸,把连续空间切成一个个规则的小方块。

具体做法是这样的:论文把视频切成长度为16帧的滑动窗口,处理完一个窗口后,会把所有点的三维坐标按照固定边长(默认0.02)量化成整数坐标。落在同一个体素里的点,会被合并成一个,用均值池化的方式取一个代表值。

这个操作背后的逻辑很直白:两个物理实体不可能在同一时刻占据同一个空间位置。所以如果两个来自不同帧的观测点落在了同一个体素里,它们大概率就是同一块表面的重复记录,合并掉完全没问题。

这就像小区里的快递代收点。如果没有这个机制,每个快递员送到你家门口的每一件包裹,不管是不是同一个人重复下单,都要单独占一个格子存放,格子很快就爆满。而代收点的做法是:同一个收件地址、同一批到达的包裹,直接合并成一份记录处理。如果不做这个合并,格子(也就是显存)会随着包裹数量(视频帧数)线性增长,迟早爆仓。做了合并之后,格子数量只跟"这个小区实际住了多少户人家"有关,跟快递员跑了多少趟没关系。

论文的实验数据也验证了这一点。在不做体素化的情况下,模型很快就会内存溢出，因为它保留的token数量跟2D方法一样多。而设定体素边长为0.02时,追踪准确率能维持在31.3左右的高位，同时显存需求从24GB(边长0.005时)降到15GB左右,速度也提升了将近一倍。这个数字选择不是拍脑袋决定的,是经过网格搜索找到的甜蜜点。

值得一提的是,这个去重不是简单粗暴的一刀切。论文特意保留了一个"非体素化查询点分支",如果用户指定了某个亚像素级的关键点,这个点会被排除在合并范围之外,永远不会被误合并进临近的点里去。这算是给系统留了一个手动豁免的通道。

先猜终点,再补细节:内分泌式的追踪策略

第二个创新是把追踪任务拆成了两步:先预测终点,再补全轨迹。

这个设计的出发点其实很朴素。论文观察到,现实世界的场景里,大部分点根本不会动。桌子是静止的,墙是静止的,只有杯子被人碰了一下,只有走过去的人在动。如果你对每一个点都不分青红皂白地去解码它完整的运动轨迹,那大量计算力都花在了"证明这个点没动"这件毫无信息量的事情上。

于是论文设计了两个模块。第一个叫端点精炼器,它的任务不是算出整条轨迹,而是只算出这个点在当前窗口结束时会落在哪个位置,顺便判断这个点是静止的还是运动的。

端点精炼器：一个循环更新的神经网络模块,通过反复迭代来逐步修正每个点在窗口末尾的预测坐标,同时输出这个点的可见性和静态/动态分类。

第二个模块叫轨迹精炼器,只对被判定为"动态"的那部分点生效,专门去解码它们在窗口内每一帧的详细路径。静态点直接偷懒,坐标原地不变。

这就好比公司年度体检。如果每个员工都要做全套核磁共振检查,医院的仪器根本转不过来。合理的做法是先做一轮快速筛查(血压、体重这种简单指标),把筛查结果异常的人挑出来,再对这批人做详细的深度检查。绝大多数体检正常的人,压根不需要占用宝贵的核磁共振时间。如果不做这个分级,机器(也就是算力)要么排长队排到明年,要么就得多买十倍的设备。

论文的消融实验证明了这个设计确实划算。强行让所有点都走一遍完整的动态轨迹解码流程,准确率没有任何提升(还是31.2),但延迟增加了4.8倍,显存占用增加了2.5倍。也就是说,这个分级策略是纯粹的效率红利，没有牺牲精度。

分类器本身的表现也很稳。在Dynamic Replica和PointOdyssey两个数据集上,静态/动态分类的F1值分别达到93.1和92.5,说明这个判断相当可靠。而且论文特意设计了容错机制:哪怕分类器偶尔判断失误,把一个静止的点误判成动态,轨迹精炼器也能自己学着预测出零位移,不会拖累最终准确率;反过来,如果一个动态点被误判成静态,顶多在这个窗口里被冻结住,下一个窗口重新评估的时候就能纠正回来。

3D WAFT:用采样代替昂贵的暴力搜索

第三个创新叫3D WAFT,这个名字来自它借鉴的2D光流方法WAFT(Warp-Aligned Feature Transform)。

WAFT：一种用于光流估计的技术,通过在源位置和目标位置分别采样特征,让模型判断当前的位置估计是否准确,而不需要构建完整的相关性矩阵。

要理解这个模块的价值,得先知道传统方法是怎么做特征匹配的。经典的做法是构建一个4D相关性体积,简单说就是把源图像里每一个点跟目标图像里所有可能的候选位置都算一遍相似度,生成一张巨大的相似度表格。这种方法精度不错,但计算量随着点数和候选位置数量疯狂膨胀。

3D WAFT换了一种思路。对于每一个点,它把当前估计的目标位置投影回2D图像上,双线性采样一下那个位置的特征,同时也采样一下这个点最初诞生位置的特征。把这两份特征拼在一起丢给Transformer去处理。如果两份特征很像,说明当前的位置估计大概是对的;如果差得很远,说明还需要继续调整。

这就像找钥匙。传统的4D相关性方法相当于把家里所有角落都翻一遍,逐个跟钥匙的形状比对,费时费力但一定能找到。3D WAFT的做法是,你先凭经验猜一个大概的位置(比如"钥匙应该在门口鞋柜上"),伸手去摸一下,摸到的手感跟记忆里钥匙的手感对比一下,对得上就确认,对不上就换个地方接着猜。这种"猜测再验证"的方式远比"翻遍所有角落"快得多,前提是你的初始猜测不能太离谱,而这恰恰是论文用恒定速度初始化来保证的。

论文的消融实验显示,去掉3D WAFT这个模块,准确率从31.2掉到29.3,下降了1.9个点。听起来不算特别惨烈,但结合它带来的巨大速度提升,这笔账显然是划算的。图6里有一组很直观的可视化:对于静止的点,零速度初始化几乎一步到位,采样到的目标特征和源特征高度一致;而对于运动的物体,第一次迭代明显投歪了,落在了背景上,采样出来的特征跟源特征差异很大,这个差异信号驱动模型在后续迭代里逐步修正,到第二次迭代基本就能锁定正确的表面。

数据说话:跟谁比,比出了什么

理论说得再漂亮,最终还是要看数字。

论文在TAPVid-3D基准上做了系统对比,这是一个专门评测3D点追踪的标准测试集，包含三个子数据集：室内自我视角视频ADT、驾驶场景DriveTrack、多摄影机实验室场景PStudio。

在所有开源的"全帧稠密追踪"方法里,TrackEverything比另一个代表性方法VDPM高出超过20个百分点的APD指标。这里说的APD是一个衡量预测点和真实点距离的综合指标,数值越高说明追踪越准。

APD：Average Percentage of Distance,论文用的官方评测指标,衡量预测的点位置落在真实位置一定阈值范围内的比例,数值越高说明追踪结果越准确。

有一个存在感很强但没法直接比较的对手叫D4RT,它在48帧短片段上的部分指标确实高于TrackEverything。但这个对比不太公平:D4RT用了超过10亿参数(是TrackEverything的20倍以上),训练数据里还包含大量未公开的私有数据集,而且没有开源代码和权重,更关键的是它压根跑不了超过48帧的视频。TrackEverything只用了61M参数(其中20M是冻结不训练的DINOv3骨干网络),用公开数据集训练,却能一直追踪到1000帧以上。这就像一个业余选手用普通装备跑完了全程马拉松,而对手用顶级装备但只跑了前一公里就退赛了,你说谁赢?

再看跟稀疏追踪器的对比。在完整长度的视频上,TrackEverything的平均APD-P达到31.2,跟专门为长视频优化的TAPIP-3D(29.8)、SpatialTracker-v2(29.5)基本处于同一水平线上,有些数据集上甚至反超。但要注意,这些稀疏方法只追踪用户指定的那几个点,而TrackEverything是把整个场景的所有点都追踪了一遍,这是一个数量级完全不同的任务。

复杂度曲线才是真正打脸的地方。论文在PointOdyssey数据集上专门做了一组扩展性实验,固定384个查询点,把视频长度从几十帧拉到900帧,观察各个方法的显存占用变化。结果是,Any4D在96帧就爆显存了,SpatialTracker-v2和DeltaV2稠密版本大约在200帧崩溃,DeltaV2稀疏版本能撑到500帧,CoTracker3能撑到600帧。而TrackEverything在900帧的时候,显存占用依然低于30GB,曲线增长得异常平缓。

反过来固定视频长度120帧,把查询点数量从几百个拉到一万个,情况也很类似。CoTracker3和DeltaV2稀疏版本一开始延迟很低,但分别在750个点和2000个点左右被TrackEverything反超,因为它们的延迟随点数线性增长,而TrackEverything几乎是一条平线,因为额外的查询点根本不会触发昂贵的4D相关性计算。

几何来源的灵活性

TrackEverything有一个容易被忽略但很实用的特性:它不负责生成三维几何信息,而是依赖外部提供的深度图或点云。

论文测试了三种不同的几何来源:一种叫Pi3的开源模型、一种叫VGGT-Ω的更强模型,以及传感器直接采集的真实几何数据。结果显示,换用更好的几何来源,PStudio数据集上的APD-P从23.5(用Pi3)提升到30.1(用VGGT-Ω),再提升到71.7(用真实传感器数据)；ADT数据集上也从39.3一路涨到46.5,超过了参数量多20倍的D4RT。

这个设计的价值在哪?就是模块解耦带来的免费升级。就好比你买了一台支持外接镜头的手机,厂商发布新款镜头之后,你不用换手机本体就能享受更清晰的拍照效果。TrackEverything的追踪逻辑跟几何估计逻辑是分开的,未来只要几何重建技术进步了,直接换个更好的几何来源插进去就行,不需要重新训练整个追踪模型。而D4RT这类端到端训练的大模型,没法接受外部几何输入,只能整体等厂家升级。

窗口长度的取舍

论文还做了一个关于滑动窗口长度的小实验。窗口设为8帧、16帧、24帧,分别测试准确率和效率。8帧和16帧的APD-P差不多(31.3和31.2),24帧掉到了29.8。虽然8帧在测试阶段延迟更低一点,但16帧在训练阶段每一步反而快26%。综合权衡之下,论文选定了16帧作为默认窗口长度。

这个细节其实反映了一个很常见的工程取舍:测试时的最优选择,未必是训练时的最优选择,最终拍板往往要考虑两头的平衡,而不是只盯着一个指标死磕。

数据集里的坑

论文里还藏着一段挺有意思的debug故事。作者在训练过程中发现损失函数总是莫名其妙地跳崖式飙升,排查了很久才发现问题出在训练数据PointOdyssey身上。

具体来说,16个视频序列(大约2.5万帧)里存在相机外参错位的问题,记录的相机姿态实际上对应的是前一帧渲染出来的画面,但三维轨迹标注却是按正确帧号对齐的,这种错位在相机移动快的时候能达到600像素以上的偏差,相当离谱。作者写了一套程序化的修复流程,把相机索引重新对齐,并且在偏差过大的帧上直接放弃监督信号,还排除了一个存在无法修复的亚帧抖动问题的序列。

这段内容读起来有点像技术团队排雷的日记,但它说明了一个经常被忽视的现实:很多论文里漂亮的性能数字，背后是花了大量时间清洗别人不愿意清洗的脏数据。这种活不体现在方法创新的图表里,但没有它,模型可能连基本的收敛都做不到。

局限性:去重不是没有代价的

论文也很坦诚地列出了几个尚未解决的问题。

第一,虽然体素化去重让显存增长速度大幅放缓,但在永不停止探索的开放世界场景里,活跃内存依然会持续膨胀,只是速度变慢了而不是完全停止。如果要支持真正的数小时级别连续追踪,还需要引入某种空间缓存淘汰机制,把很久没被访问的旧场景内容清理掉。

第二,TrackEverything的效果高度依赖外部几何输入的质量,这是一把双刃剑,灵活性换来的代价是精度上限被卡在了几何估计模块的天花板上。

第三,跨窗口的体素合并是通过不可逆的均值池化完成的。如果追踪过程中出现误差,两个本该独立的物理表面可能被永久合并成一条轨迹,后续帧里再也分不开了。用户可以通过手动指定查询点的方式保护重要目标不被误合并,但这终究是一个局部补丁,不是根本解法。

写在后面

读这篇论文时,最触动我的其实不是三个技术模块本身,而是它背后那种"换维度思考"的姿态。

大部分优化工作都是在同一个坐标系里精打细算,省一点显存,加快一点速度。但TrackEverything选择了一条更彻底的路:把整个问题从二维像素世界搬到三维物理世界里去看待,复杂度自然就跟着场景内容走,而不是跟着视频时长走。这种"换个参照系,问题就变简单了"的思路,在物理学里屡见不鲜,但在深度学习工程里,真正敢这么干、又干成了的工作并不多。

论文里那个体素去重的实验数字让我印象很深:关掉去重直接就内存溢出,开了之后不仅没爆,准确率还几乎没有损失。这说明这个所谓的"冗余",在旧的处理框架里几乎是无法避免的结构性浪费,而不是一个可以靠精调参数解决的小问题。

还有一个细节值得琢磨:论文特意强调,TrackEverything不需要重新训练就能接入更好的几何估计模型或者真实传感器数据,直接从23.5跳到71.7的APD-P。这提示了一种模块化设计的长期价值,当整个领域的基础能力(比如三维重建)还在飞速进步时,把追踪能力和几何估计能力解耦开,可能比死磕一个端到端的巨大模型更划算,至少能少踩很多"重训一次就要烧掉几十万美元算力"的坑。

这篇论文没有解决所有问题,内存依然会随场景内容缓慢增长,合并出错依然不可逆。但它把"追踪一切"这件事从理论上的不可能,变成了实际可以在单张GPU上跑起来的东西。下一步会有人解决内存淘汰机制吗,又会有人想出办法让被误合并的轨迹重新分开吗?

Q&A

Q1：TrackEverything是什么？

A：TrackEverything是一种3D点追踪方法,它把视频表示成三维世界坐标系里的持久场景轨迹,通过体素化去重、终点先行再补轨迹、3D WAFT特征采样这三个创新,实现了对超过1000帧长视频里所有可见点的稠密追踪,显存占用控制在40GB以内。

Q2：TrackEverything和普通的稠密追踪方法有什么区别？

A：普通稠密追踪方法(比如VDPM、D4RT)只能处理48到64帧的短视频,因为它们把每一帧都当成全新画面重复存储,显存随视频长度线性增长。TrackEverything把追踪放到三维世界坐标系里做,同一块物理表面在不同帧里的重复观测会被体素化去重合并,复杂度只随场景内容增长,不随视频时长增长。

Q3：TrackEverything的准确率表现怎么样？

A：在TAPVid-3D基准测试上,TrackEverything比开源的全帧稠密3D追踪方法高出超过20个百分点的APD指标,在长视频上的表现也能跟专门的稀疏追踪器打平,同时还多追踪了数量级更大的点。