这项由澳门大学、中国电信人工智能研究院(TeleAI)以及南京大学联合开展的研究,以预印本形式于2026年6月8日发布在学术平台arXiv,论文编号为arXiv:2606.09516。感兴趣的读者可以通过该编号检索到完整论文。
![]()
每天,无数人在手机上刷短视频,在电脑上看直播,或者打开云游戏。但有没有注意过,当网速不好、信号不稳时,画面会变得模糊、马赛克横飞?更让人无奈的是,很多老视频、低画质录像,想看清楚细节却根本无从下手。如果有一种技术,能在视频播放的同时,实时把模糊画面变得清晰锐利,就像给眼睛戴上了一副从未有过的超级近视眼镜,这对于普通用户来说意味着什么?
研究团队给出的答案叫做"SwiftVR"——一个能在普通消费级显卡上,以每秒超过26帧的速度,实时把低质量视频修复为高清画面的系统。更惊人的是,在专业服务器级别的显卡上,它甚至能处理4K超高清视频,而同类竞争对手在这个分辨率下直接内存溢出、完全无法运行。
要理解这项研究的意义,先从视频修复(Video Restoration,简称VR)这件事说起。所谓视频修复,就是把质量差的视频变成质量好的视频——去除噪点、去除压缩产生的块状感、提升分辨率、让细节更清晰。这在技术上是一道极度困难的填空题,因为你不知道原来的画面到底是什么样子,只能靠算法去"猜"。
近年来,一类叫做"扩散模型"的人工智能算法在这个领域大放异彩。扩散模型的核心原理,可以理解为:先把一张清晰的图片一步步"弄脏",加入噪声,然后训练AI学会如何反向"清理"这些噪声,最终恢复出清晰的图像。这类方法生成的画面质量非常高,细节丰富,感觉真实,但代价是计算量巨大——有时候一段视频要反复"清理"好几十次才能得到满意结果,根本无法用于实时播放场景。
后来研究者发明了"一步扩散"技术,把这个反复清理的过程压缩成只需一步,大大提升了速度。但即便如此,想要在高分辨率视频上做到实时处理,仍然面临两座大山:一是注意力机制的计算量随分辨率暴增,二是视频编解码器(VAE)的延迟居高不下。SwiftVR的核心任务,就是把这两座山同时搬掉。
一、视频修复为什么这么难做到实时?
要理解SwiftVR解决了什么问题,先要明白为什么现有方法在实时场景下举步维艰。
当前最先进的视频修复扩散模型,其核心是一种叫做"Diffusion Transformer"(扩散变换器,简称DiT)的神经网络结构。这个网络在处理视频时,会把每一帧画面切成很多小方块(称为"token",可以理解为信息单元),然后让每个小方块都去和其他所有小方块互相"打招呼"——这个过程就是"自注意力机制"。这种互相打招呼的方式,让模型能理解画面中不同区域之间的关系,从而做出更好的修复。
然而,问题在于这个"打招呼"的计算量是平方级增长的。也就是说,如果画面分辨率翻倍,参与打招呼的小方块数量也翻倍,但总计算量却要增长四倍。分辨率从720p提升到4K,信息单元数量增长约十六倍,计算量则是惊人的约两百五十六倍。研究团队实测了一个代表性的5B(50亿参数)视频生成模型Wan2.2在不同分辨率下的实际运行时间,结果触目惊心:光是自注意力计算一项,从720p到4K,计算量从0.47拍次浮点运算(PFLOPs)暴增到21.3 PFLOPs,增长了约45倍。加上整个前向传播过程,720p下需要大约2.36秒,1080p下需要8.37秒,4K下则需要约93秒——这还只是处理一小段视频片段的时间。
除了注意力计算之外,视频的编解码器(VAE)也是一个严重的瓶颈。VAE的作用是把视频压缩到一个较小的"潜在空间"(latent space)让AI处理,处理完再解压回视频画面。原始的3D视频VAE体积庞大,在4K分辨率下,仅解码一段25帧的视频片段就需要约25.8秒。这两个瓶颈加在一起,让任何希望在高分辨率下实时运行扩散模型的尝试都显得遥不可及。
与此同时,实时视频修复还有一个特殊约束:必须是"因果式"处理,也就是说,系统只能利用已经到来的视频帧,而不能"偷看"未来的帧。这就像听广播直播时不能回放一样——播出去的信号不能等你看完整段录音再处理,必须即时反应。这排除了许多依赖完整视频段落的离线处理方法。
二、SwiftVR的整体架构:流水线上的精密协作
SwiftVR的设计哲学,可以用一条高效运作的生产流水线来理解。原材料(低质量视频)进入流水线,经过三个紧密协作的工位(编码器、扩散变换器、解码器),输出成品(高清视频)。每个工位都经过专门优化,确保整条流水线能以足够快的速度稳定运转。
具体来说,SwiftVR采用分块(chunk)式因果流处理视频。视频被切成固定长度的片段,每次处理一个片段,处理完立即输出,再处理下一个片段。这样做的好处是,每次需要处理的视频长度T是有上限的,不会随着视频总长度的增加而无限增长,从而把注意力计算的复杂度控制在可接受的范围内。
在这套流水线中,有两个最关键的创新设计:一个是针对注意力计算的"无掩码移位窗口自注意力"(MFSWA),另一个是针对编解码器的"修复感知自编码器"(ReAE)。这两个设计分别解决了计算效率和内存/速度的瓶颈问题,下面详细展开介绍。
三、第一把钥匙:让AI的"打招呼"变得更聪明
回到之前的比喻。如果把视频的每个像素区域比作一个人,自注意力机制就是让每个人都和其他所有人握手交流。当画面很大时,握手的总次数呈爆炸式增长,效率极低。一个更聪明的做法是:把人们分成若干小组,组内成员互相握手,不同组之间通过代表传递信息。这就是"窗口注意力"的基本思路。
然而,传统的窗口注意力方法(比如来自微软研究院的Swin Transformer)在实现时有一个技术细节的麻烦:为了让不同窗口之间能够共享信息,需要对数据进行"循环移位"操作,还要使用"注意力掩码"来处理边界。这两个操作会让计算过程偏离所谓的"密集标量积注意力"(SDPA)的快速执行路径,导致底层硬件无法充分发挥加速效果,反而拖慢速度。此外,处理视频时还涉及时间维度,需要在三维空间(时间+高度+宽度)中划分窗口,进一步增加了复杂性。
SwiftVR的MFSWA(无掩码移位窗口自注意力)用了一个更为精巧的方案来绕过这些麻烦。
首先,由于视频被切成固定长度的片段,时间维度已经被自然限制住了,所以窗口划分只需要在空间维度(高度×宽度)上进行,而不需要在三维中划分。每个空间窗口内,该片段的所有帧都是完整可见的,这样既控制了计算量,又保留了时间维度上的信息流动。
其次,MFSWA通过一个关键设计解决了"循环移位"和"注意力掩码"的问题:它用"确定性索引张量"提前把每个窗口的数据收集(gather)成一个密集的矩形张量,然后直接对这个密集张量调用标准的SDPA。整个过程中不存在任何掩码、循环移位或者填充操作,所有注意力计算都走的是硬件最优的密集路径。
第三,为了让相邻窗口之间能够交换信息,MFSWA在偶数层使用正常的窗口划分,奇数层则将窗口整体移动半个窗口大小(向右移动宽度的一半,向下移动高度的一半)。这样交替进行,随着网络层数的加深,信息就能在全局范围内流动。移位操作不是在注意力计算内部实现的,而是通过提前计算好的索引映射来实现,确保收集到的数据始终是密集的矩形块。
还有一个细节值得关注:当视频的高度或宽度不能被窗口大小整除时,边界处的窗口会通过"边界钳位"(boundary clamping)方式处理——边缘窗口会与相邻窗口重叠,共享部分数据,从而保证每个窗口的大小始终是固定的矩形,不存在大小不一的边角窗口。这种重叠会带来少量冗余计算,但研究者通过数学分析证明,这个额外开销随着分辨率的提高而趋近于零,在实际使用的分辨率下是完全可以接受的。
更重要的是,MFSWA使用的全部是标准的PyTorch SDPA接口,不依赖任何特殊的硬件指令或定制化的稀疏注意力核。这意味着训练好的模型可以直接在不同品牌、不同型号的显卡上运行,无需为每种硬件重新训练或修改代码。
在实际效果上,与完整注意力(full attention)的教师模型相比,MFSWA将推理速度从每秒19.36帧提升到了31.32帧,提升幅度达1.62倍。与此同时,画面质量几乎没有损失,PSNR(峰值信噪比,衡量图像保真度的指标)从25.86 dB仅微降至25.58 dB,LPIPS(感知相似度,数值越低越好)从0.2417小幅增至0.2508。
四、第二把钥匙:给视频编解码器"减肥"
解决了注意力计算的效率问题之后,视频编解码器(VAE)的延迟就变得更加突出。原始的Wan2.2视频生成模型使用的3D VAE,参数量高达7.047亿,在处理一段25帧的1920×1080视频时,光解码就需要约2.7秒,占到了整个处理流程的相当大一部分。这对于实时应用来说是不可接受的。
研究团队引入了一个专门为视频修复任务设计的轻量化编解码器,称为"修复感知自编码器"(Restoration-aware AutoEncoder,简称ReAE)。ReAE从一个公开的轻量化自编码器(专为HunyuanVideo设计的TinyAutoEncoder)初始化,然后在视频数据上进行微调,使其适应视频修复的特定需求。
ReAE的训练分两个阶段进行。第一阶段专注于重建质量:同时优化像素误差(让重建的视频和原视频在每个像素上尽量接近)、感知相似性(让重建视频在视觉上感觉接近,而不仅仅是数值接近,这通过LPIPS指标衡量)和时间一致性(让相邻帧之间的变化保持平滑,避免闪烁)。第二阶段在第一阶段收敛后,引入对抗训练(GAN),进一步提升输出画面的锐利程度和视觉真实感。
ReAE最终的参数量只有约4095万,不到原始Wan2.2 VAE的6%,而解码速度从约2.7秒下降到约0.099秒,提升了约27倍,内存占用也从约24.86 GB下降到约16.97 GB。当然,这种大幅提效是有代价的:重建质量(以PSNR衡量)从35.48 dB下降到32.74 dB,LPIPS从0.0513上升到0.0777。但与更小的通用轻量编解码器(PSNR仅27.14 dB,LPIPS 0.1183)相比,ReAE通过针对视频修复任务的专门微调,在效率和质量之间找到了更好的平衡点。
在实际推理中,ReAE通过维护"边界状态"(boundary states)来保证视频片段之间的连续性。编码器在处理每个片段时,会保存一些状态信息并传递给下一个片段的处理,解码器同样如此。这样,即使视频被切成了独立处理的片段,输出的视频在片段接缝处也不会出现突变或不连续感。
五、三阶段训练:从粗糙到精细的磨砺过程
SwiftVR的扩散变换器(DiT)通过三个递进的训练阶段逐步打磨,每一阶段都在前一阶段的基础上解决新的问题。
第一阶段是"全注意力潜在流匹配预训练"。研究者在冻结的ReAE潜在空间中(也就是说,先把视频用ReAE编码成紧凑的潜在表示,再在这个压缩后的空间里训练),训练一个使用完整注意力机制的DiT。训练目标是让模型学会预测从低质量视频的潜在表示到高质量视频的潜在表示之间的"速度向量"——类似于告诉模型,从A地(低质量)到B地(高质量)的方向和距离是什么。数学上,这通过"流匹配"(flow matching)框架实现,定义了一条从高质量到低质量的线性路径,模型学习这条路径上每个点的切线方向。
第二阶段是"无掩码移位窗口蒸馏"。在第一阶段训练出高质量的全注意力教师模型后,第二阶段使用知识蒸馏技术,把教师模型的能力转移到采用MFSWA的学生模型中。学生模型不仅要完成原本的流匹配任务,还要尽量让自己预测的速度向量与教师模型的预测保持一致。这个双重约束既保证了学生模型的修复能力,又引导它向教师模型靠拢,避免因为注意力机制改变而出现明显的质量下降。
第三阶段是"联合对抗微调"。前两个阶段的训练都在潜在空间中进行,模型优化的是潜在表示的准确性。但潜在空间中的精度不等同于最终解码出的像素画面质量。为了弥合这个"潜在到像素"的鸿沟,第三阶段将DiT和ReAE解码器放在一起,以实际推理时的单步推理协议进行端到端的联合训练。模型接收低质量视频,一步预测速度向量,解码得到修复后的视频,然后直接在像素空间中计算损失函数,包括像素误差、感知损失、时间一致性损失,以及来自一个视频判别器的对抗损失。
这个视频判别器的设计也颇为用心:它基于一个冻结的VGG-19骨干网络(一种经典的图像特征提取器),从每一帧中提取多尺度的感知特征,然后把这些特征重新组织成时空特征体积,输入到可训练的三维卷积判别头中。这个设计让判别器既能评估单帧画面的质量,也能感知帧间的时间一致性,从而引导生成器在保持时序稳定性的同时产生更锐利、更真实的细节。
六、实验数据:用数字说话的表现报告单
研究团队在多个基准数据集上对SwiftVR进行了全面评测,对比对象涵盖了三类代表性方法:非扩散的回归式方法(Real-ESRGAN、RealBasicVSR、RealViFormer)、多步扩散方法(Upscale-A-Video)以及一步扩散方法(DOVE、SeedVR2-3B、FlashVSR-Tiny)。
评测数据集包括三个合成降质基准(SPMCS、UDM10、YouHQ40)和一个真实世界数据集(VideoLQ)。所有方法均在统一的分块流处理协议下评测,以确保公平比较。
在感知质量指标上,SwiftVR表现突出,在全部四个数据集上的MUSIQ(机器感知图像质量)指标中均排名第一,在UDM10和YouHQ40数据集上的CLIP-IQA(基于CLIP模型的图像质量评估)和MANIQA(多尺度注意力网络图像质量评估)指标也均排名第一。在DISTS(全参考感知相似度指标)上,SwiftVR在YouHQ40数据集上排名第一,在SPMCS上排名第二。LPIPS方面,SwiftVR与领先的一步方法相差不大。
相比之下,以DOVE为代表的像素保真度导向的方法在PSNR(峰值信噪比)和SSIM(结构相似度)等全参考保真度指标上表现更好,但这类方法倾向于生成过于平滑的输出,牺牲了真实感和细节。研究团队明确表示,SwiftVR的设计目标是优先追求感知真实性,与真实世界视频修复的实际需求更为契合。
在效率方面,SwiftVR的优势更为显著。在2560×1440分辨率下,SwiftVR达到31.32帧每秒,而FlashVSR-Tiny仅为9.61帧每秒,DOVE和SeedVR2-3B在启用VAE分块(tile)处理的情况下分别只有0.87和1.39帧每秒。峰值内存方面,SwiftVR使用38.01 GB,FlashVSR-Tiny为34.35 GB,DOVE高达59.24 GB,SeedVR2-3B为35.35 GB。
在更高的3840×2160(4K)分辨率下,所有参与对比的扩散模型在单张H100 80GB显卡上均因内存不足而无法运行,而SwiftVR可以稳定地以13.84帧每秒运行,峰值内存60.91 GB,恰好在H100的80GB限制内。
在消费级显卡上,研究团队在一张NVIDIA RTX 5090上测试SwiftVR,在1920×1080分辨率下达到了26帧每秒,落在24到30帧每秒的实时流媒体标准范围内。这是目前已知的第一个在消费级显卡上实现1080p实时处理的生成式视频修复模型。
运行时间的详细分解显示,在所有分辨率下,DiT(扩散变换器)的推理时间均占据端到端延迟的主要部分:在1080p下,编码器耗时25.67毫秒,DiT耗时327.72毫秒,解码器耗时85.37毫秒;在4K下,这三个数字分别为111.06毫秒、1270.10毫秒和344.27毫秒。这个规律与一步扩散模型的特点吻合:采样瓶颈已经从迭代采样转移到了单步变换器计算本身。
跨后端部署测试进一步证明了MFSWA的通用性。在同一台H100上,使用PyTorch SDPA、FlashAttention-2、FlashAttention-3、SageAttention和xFormers五种不同的注意力后端,SwiftVR的速度和质量几乎完全一致(最快的FlashAttention-3约比PyTorch SDPA快3%,SageAttention略慢约2%),无需为不同硬件做任何模型调整。
定性比较同样支持了量化结果。在对比真实世界视频的修复效果时,研究团队选取了两个代表性场景:一只停栖的猎隼(考验羽毛纹理的精细恢复)和一条秋叶街道(考验树枝、叶片、栅栏等细密结构的还原)。回归式方法能恢复大致轮廓,但过度平滑细节,枝条边缘有明显的色彩晕染。DOVE输出稳定但细节偏软。SeedVR2-3B和FlashVSR-Tiny能恢复更多高频细节,但在枝条和车辆轮廓附近存在局部色偏、光晕或过度锐化。SwiftVR输出的羽毛方向感清晰、喙部细节干净、枝干边界清楚、叶片分离良好、车辆轮廓锐利,视觉上更自然,与感知指标的改善相吻合。
七、局限与展望:这条路还有多远?
研究团队对SwiftVR的局限性持坦诚态度,并不回避现有问题。
目前最主要的局限在于,SwiftVR尚未能在消费级显卡上实现实时4K修复。在3840×2160分辨率下,即使是在H100这样的专业服务器显卡上,SwiftVR也只能达到13.84帧每秒,距离24帧每秒的实时门槛仍有差距,内存需求也超过了消费级显卡的上限。此外,SwiftVR目前也没有采用任何推理侧的额外加速技术。
研究团队指出了两个主要的未来方向。其一是推理加速,包括训练后量化(把模型中的浮点数精度降低以减少计算量)、KV状态缓存与压缩(保存中间计算结果供后续复用),以及可学习的token减少技术(让模型自主学会忽略不重要的信息单元),这些技术与SwiftVR现有的架构设计是正交的,可以叠加使用。其二是更小、压缩比更高的骨干网络。SwiftVR目前基于50亿参数的Wan2.2-TI2V-5B,体量依然庞大,更高的潜在空间压缩比和更小的基础模型对于真正实现4K消费级实时修复可能是必要条件。
归根结底,SwiftVR提交的这份答卷,是在现有技术条件下"能做多快、做多好"的一次认真探索。它通过两个精心设计的核心模块——既不需要特殊硬件又能充分利用硬件加速的窗口注意力机制,以及在质量和速度之间取得更好平衡的轻量化编解码器——在不牺牲太多画面质量的前提下,把生成式视频修复的速度推进到了消费级硬件上1080p实时处理的里程碑。对于追求高清画质的直播观众、视频会议用户或云游戏玩家来说,这类技术未来很可能成为视频平台后台默默运行的标配组件,让每一个画面都尽可能清晰,即便原始信号并不完美。若想深入了解技术细节,可通过编号arXiv:2606.09516查阅原始论文。
Q&A
Q1:SwiftVR在普通消费级显卡上能达到什么速度?
A:SwiftVR在NVIDIA RTX 5090这张消费级显卡上,能以每秒26帧的速度实时处理1920×1080(Full HD)分辨率的视频。这落在直播、视频会议和云游戏所需的24到30帧每秒的实时门槛范围内,是目前已知的第一个在消费级显卡上实现1080p实时处理的生成式视频修复模型。
Q2:SwiftVR和同类扩散模型比有哪些速度差距?
A:在2560×1440分辨率下,SwiftVR在单张H100显卡上达到每秒31.32帧,而同为一步扩散方法的FlashVSR-Tiny仅有9.61帧每秒,DOVE和SeedVR2-3B分别只有0.87和1.39帧每秒。在4K分辨率下,所有对比的扩散模型直接因内存不足无法运行,只有SwiftVR能以13.84帧每秒稳定运行。
Q3:SwiftVR的MFSWA(无掩码移位窗口自注意力)为什么不需要特殊硬件就能加速?
A:传统的窗口注意力方法在实现时需要使用"循环移位"和"注意力掩码",这会让底层计算偏离硬件最优的密集执行路径。MFSWA通过预先计算好的索引张量把每个窗口的数据直接收集成密集矩形块,再调用标准的SDPA接口,整个过程不含任何掩码或特殊操作,所以可以在任何支持标准PyTorch SDPA的显卡上充分发挥加速效果,无需定制驱动或专用核。





京公网安备 11011402013531号