字節跳動與廈門大學突破：視頻AI生成速度提升6倍無損畫質

這項由字節跳動與廈門大學多媒體可信感知與高效計算教育部重點實驗室聯合開展的研究，發表于2026年5月（預印本編號arXiv:2605.01725v1），同時有來自德國圖賓根ELLIS研究院的學者參與。感興趣的讀者可通過該編號在arXiv平臺檢索原文。

**一、一段7秒的視頻，為什么要等27分鐘？**

在手機上刷短視頻只需要幾秒鐘，但你可能不知道，讓AI"憑空"生成這段視頻，背后的計算量有多驚人。研究團隊在論文里舉了一個具體數字：用當前頂尖的視頻生成模型SkyReels-V2，在一塊專業級A800顯卡上，生成一段僅7秒鐘、分辨率540×540的短視頻，需要整整27分鐘。這還只是單張顯卡、單個任務的情況。

這27分鐘是怎么花掉的？理解這個問題，需要先知道AI視頻生成的基本原理。現代的視頻生成模型，本質上是一個"去噪"機器。它從一堆隨機噪點出發，一步一步把噪點"擦掉"，最終露出一段清晰的視頻。這個過程需要反復執行幾十次甚至上百次，每一次都要對視頻里的每一幀、每一個像素點做大量數學計算。分辨率越高、視頻越長，計算量就越大，耗時就越久。

更麻煩的是，現代視頻生成用的神經網絡結構（叫做Diffusion Transformer，可以理解為一個超級復雜的"注意力分配器"）存在一個天然缺陷：它在處理視頻時，需要讓視頻中的每一幀都"關注"其他所有幀，這導致計算復雜度隨視頻長度呈平方級增長。視頻長度翻倍，計算量就變成原來的四倍。這對于需要生成幾十秒甚至幾分鐘長視頻的應用場景，幾乎是一道無法逾越的墻。

為了繞過這道墻，研究者們想出了一個聰明的方案：不要一次性生成整段視頻，而是把視頻切成一小段一小段，像流水線一樣逐段生成，前一段的結果作為下一段的參考。這就是所謂的"自回歸視頻生成"（Autoregressive Video Generation）范式，字節跳動的SkyReels-V2和初創公司Sand AI的MAGI-1都采用了這種框架。這樣做確實把內存消耗從"隨視頻長度平方增長"壓縮到了"線性增長"，理論上可以生成無限長的視頻。

然而，即便解決了內存問題，速度問題依然嚴峻。逐段生成意味著每一段都要獨立走完那幾十步去噪流程，而且段與段之間還得等待上一段完成才能開始。研究團隊面臨的核心挑戰是：有沒有辦法讓這個"去噪流水線"跑得更快，同時又不讓生成的視頻質量變差？

**二、"偷懶"的藝術：緩存復用的聰明與局限**

面對這個速度瓶頸，學術界已經探索出一條思路：既然每一步去噪的結果跟上一步差別不大，那能不能"偷懶"，直接把上一步算好的結果拿來用，跳過當前這步的計算？這就是"特征緩存"（Feature Caching）策略的核心邏輯。

用一個日常比喻來理解：廚師每天都要給同一家餐廳做招牌菜。如果菜譜今天和昨天幾乎一樣，他完全可以把昨天炒好的底料先存著，今天直接加熱復用，不用從頭開始炒。只有當菜譜發生了明顯變化，他才需要重新開爐。特征緩存干的就是這件事——把中間計算結果存起來，下一步需要的時候直接取用，省掉重復計算。

這個方向已經有一些先行者。TeaCache通過分析輸入數據的變化幅度，來判斷當前這步要不要重新計算；FlowCache則專門針對自回歸視頻生成的特點，觀察到不同"段"之間的去噪難度不一樣（靠前的段噪點多、變化大，靠后的段已經相對穩定），據此決定哪些段可以跳過計算。FlowCache是第一個專門為自回歸視頻生成量身打造的緩存方案，已經是該領域的重要突破。

然而這些方法都有一個共同的根本缺陷：它們的決策粒度太粗了。無論是TeaCache按時間步（整個去噪步驟）決策，還是FlowCache按視頻段（整段緩存或整段計算），它們的邏輯都是"要么全部重新算，要么全部拿緩存"。

問題出在哪里？一段視頻里，并不是所有區域都在動。以"一個人騎自行車穿過公園"這段視頻為例，自行車輪子、人的腿、飛速運動的樹影——這些區域變化劇烈，需要每一步都認真計算，否則就會出現模糊、扭曲甚至形狀"幻覺"（比如人多長了一根手指）。而遠處的天空、靜止的草坪、固定的建筑——這些區域幾乎一幀一幀都沒什么變化，完全可以大膽地復用緩存，不用浪費算力。

但FlowCache這類方法的"眼神"不夠細，它只能看到整段視頻的平均狀態，一旦決定跳過這一段的計算，動態區域就跟著靜態區域一起被"偷懶"了。這就好比那位廚師，明明主菜的肉類部分需要重新烹飪，但他因為配菜沒變化就把整道菜都直接端出來了——主菜的口感肯定會出問題。

這就是字節跳動與廈門大學這篇論文所要解決的核心矛盾：**如何把緩存決策的粒度，從"整段視頻"精細到"每一個像素點"，讓動的地方精心計算、靜的地方大膽偷懶？**

**三、用數學證明"哪里動了就算哪里"不是拍腦袋**

在動手做方案之前，研究團隊先做了一件很重要的事：用嚴格的數學，弄清楚"跳過計算"到底會引入多大的誤差，以及這個誤差跟什么因素有關。

去噪過程可以理解為一系列"修正動作"。在每一步，模型會計算一個"當前應該朝哪個方向修正"的向量，姑且叫它"殘差"。當我們決定跳過這一步的計算，直接用上一步存好的"殘差"來代替，誤差就來自于"上一步的殘差"和"這一步真正應該有的殘差"之間的差距。

研究團隊從數學上嚴格推導出了這個誤差的精確公式（論文中的命題4.1）：**跳過一步計算引入的誤差，等于時間步長乘以"真實殘差"與"緩存殘差"的差值**。這個結論看起來簡單，卻有深刻含義：誤差完全由殘差的"穩定程度"決定。如果某個區域的殘差從一步到下一步變化不大，那就可以放心跳過；如果變化很大，就必須重新算。

接下來的問題是：殘差的變化到底跟什么有關？研究團隊做了一系列實驗來觀察真實視頻生成中的殘差分布（論文中的圖2）。他們發現了兩個重要現象。

第一個現象叫"異質時間冗余性"：在相鄰兩個去噪步驟之間，不同區域的殘差變化幅度差異極大。大多數區域的變化很小（中位數約2.078），但有一些區域的變化可以高達9.878，是中位數的將近五倍。這說明一刀切的"整段跳過"或"整段計算"策略都是低效的——靜態區域被過度計算浪費了，動態區域被跳過又損失了質量。

第二個現象叫"塊內幀間差異性"：即便在同一個視頻段內，不同幀之間的殘差變化也差異明顯，最大差值可以達到5.9219。這就再次否定了"把一整段作為原子單元"的思路——同一段里，有的幀動得多，有的幀動得少，理應區別對待。

然后，研究團隊繼續追問：既然殘差變化決定了哪里該算、哪里可以跳，但我們在計算之前根本不知道殘差會變多少，怎么辦？能不能找到一個簡單易得的"替代指標"來預測殘差變化？

這就是論文中最精妙的理論推導（引理4.2）：**在數學上可以嚴格證明，相鄰幀之間的像素差異，是殘差變化量的一個上界**。也就是說，兩幀之間變化越大，殘差變化就越可能越大；兩幀之間幾乎沒變化，殘差變化就一定很小。

這個結論的意義在于：我們不需要等到模型算完才知道哪里變化大，只需要看一眼相鄰幀的像素差異，就能預測出哪些區域的計算不可跳過。幀間差異是現成的信息，計算成本幾乎可以忽略不計——這就是所謂的"輕量代理"（lightweight proxy）。

為了驗證這個代理的實際效果，研究團隊做了一個"排名對比實驗"：把所有像素點按照"幀間差異"從大到小排列，再把它們按照"真實殘差變化"從大到小排列，看兩個排列有多相似。用一個叫NDCG的評分來衡量相似度（滿分1.0），結果在整個去噪過程的50個步驟中，得分始終高于0.94，平均值達到0.9687（論文圖3）。這意味著用"幀間差異"來預測"哪里更需要計算"，準確率高達96%以上，完全可以用于實際決策。

**四、MotionCache：給每個像素點單獨配一個"更新計劃表"**

理論基礎打牢之后，研究團隊提出了MotionCache方案。它的核心邏輯可以用一個"差異化管理"的比喻來理解：公司里，表現穩定的員工不需要每周開績效會議，但負責關鍵項目、工作變化頻繁的員工則需要每天溝通進展。MotionCache就是給視頻里的每一個像素點制定了個性化的"溝通頻率"——動得多的像素高頻更新，靜止的背景低頻復用。

具體來說，MotionCache的工作流程分為三個環節。

第一個環節是**計算"運動重要性圖"**。對于視頻段中的每一幀，系統會計算它與前一幀之間的像素差異，差異越大，說明這個位置運動越劇烈，"重要性"就越高。第一幀與上一視頻段的最后一幀比較，以保持時間連續性。唯一例外是整段視頻的第一幀沒有前驅幀，這時就借用第二幀的重要性分數來代替（這是一個工程上的實用處理）。計算出原始重要性之后，系統還會對每幀內部的分數做歸一化處理，把數值映射到一個統一的區間，并設置一個"兜底值"α，確保即便是最靜止的背景，也有一個最低更新頻率，不會被徹底凍結。這個α參數有點像給所有員工設置的"最低溝通底線"——就算事情不多，至少也要定期打個招呼，避免徹底失聯。

第二個環節是**"重要性加權累積"決策機制**。系統為視頻中的每一個像素點維護一個"誤差累積器"，每過一個去噪步驟，就把該步驟的總體變化量乘以這個像素點的運動重要性權重，加到累積器里。高運動像素的權重接近1，所以它的累積器漲得快；低運動像素的權重接近α（比如0.6），累積器漲得慢。當某個像素點的累積器超過預設閾值τ時，系統就判定"這個點的誤差已經積累到不能再忽視了，必須重新算"，隨即觸發計算并將累積器清零。這就像一個精密的"誤差預算管理"系統：每個像素都有自己的誤差賬戶，賬戶余額超支就必須結算（重新計算），否則繼續透支（復用緩存）。

第三個環節是**"粗到細"雙階段推理調度**。研究團隊在實踐中發現，視頻去噪的前期和后期，情況很不一樣。前期（去噪的最初幾步）就像一幅畫還在草稿階段：整體結構還沒定型，筆觸雜亂，這時候如果只計算部分區域，很容易導致整體構圖出錯。論文圖3也驗證了這一點——在前期，運動重要性圖的NDCG分數波動較大，說明幀間差異作為代理的可靠性還不夠高。正因如此，MotionCache在前K步（K是一個可調參數，默認為6步）執行的是"全量計算"策略：要么這一段完全重新算，要么完全復用緩存，跟FlowCache一樣保守但安全。

等到完成了K次全量計算之后，整體結構已經穩定，運動重要性圖也變得清晰可靠（論文圖6展示了這個演變過程：前期的重要性圖模糊彌散，后期則精準地勾勒出運動物體的輪廓）。從這一刻起，MotionCache切換到"精細模式"，啟動前面描述的像素級差異化管理。系統只把"需要更新"的像素點集中起來做一次前向計算，計算完畢后把結果寫回緩存，不需要更新的像素則直接取用緩存里存好的殘差值。這樣一來，每次去噪步驟實際需要計算的像素數量大幅減少，整體速度就顯著提升了。

**五、實驗結果：數字背后的故事**

研究團隊在兩個頂尖的自回歸視頻生成模型上進行了全面評測，分別是字節跳動自家的SkyReels-V2（13億參數，540p分辨率）和Sand AI的MAGI-1（45億參數蒸餾版，720p分辨率）。評測使用了多種指標：PSNR和SSIM衡量生成視頻與原版的像素級相似度，LPIPS衡量人眼感知上的差異，VBench-long則從十余個維度綜合評估視頻質量（包括畫面清晰度、時間連貫性、語義一致性等）。

在SkyReels-V2上，結果相當亮眼。原始模型（不做任何加速）的基準延遲是1540秒。TeaCache慢速版能做到1.89倍加速，但VBench從83.84%降到82.67%，PSNR只有21.96；TeaCache快速版加速到2.2倍，但VBench驟降到80.06%，PSNR更跌至18.39，畫質損失明顯。FlowCache慢速版把速度提到了6.26倍（延遲降至246秒），VBench 82.70%，PSNR 21.83，這已經是相當不錯的成績。

而MotionCache慢速版在6.28倍加速（延遲245秒，與FlowCache幾乎相同）的情況下，VBench達到82.84%，PSNR高達23.46，SSIM達到0.9093，LPIPS只有0.0875。與FlowCache慢速版相比，速度相當，但PSNR高出近1.6分，SSIM高出約0.036，LPIPS（越低越好）則低了約61%——這意味著MotionCache在相近速度下，保留了更多視頻細節，人眼看到的"失真感"大幅降低。

MotionCache快速版則達到7.26倍加速（延遲212秒），是所有方案中最快的，且VBench仍維持在82.75%，比TeaCache慢速版（82.67%，只有1.89倍加速）還要高——換言之，MotionCache最快版本的質量，比TeaCache最慢版本還要好，速度卻快了將近4倍。

在MAGI-1上，情況有些不同。這個模型架構更復雜，各方法整體加速幅度都比SkyReels-V2小，但MotionCache依然表現最佳。TeaCache快速版加速到1.41倍時，VBench從77.26%暴跌到68.81%，質量損失觸目驚心；FlowCache快速版1.94倍加速時，VBench也降到73.42%。而MotionCache慢速版在1.64倍加速下，VBench維持在77.25%，與原始模型基本持平（僅差0.01%），PSNR達到19.71，遠高于FlowCache慢速版的18.16。MotionCache快速版在2.07倍加速下，VBench保持74.59%，同樣優于所有其他快速版方案。

論文中還展示了一些具體的視覺案例，直觀呈現了這些數字背后的差異。比如在SkyReels-V2上測試"一個人品嘗啤酒"的提示詞，FlowCache生成的視頻里，人的手出現了"六根手指"的解剖學幻覺；在MAGI-1上測試"大象平靜漫步"，TeaCache和FlowCache都導致大象的象牙消失了，而MotionCache則完整保留了這一細節。這些細節上的差異，恰恰印證了"動態區域需要精細計算"這一核心理念。

**六、調參的學問：α和K設多少合適**

任何方法都有需要調整的參數，MotionCache也不例外。研究團隊做了細致的消融實驗，幫助理解這兩個關鍵參數的影響。

關于兜底值α的影響，實驗在SkyReels-V2上把α從0.0掃到1.0（間隔0.1），逐一記錄質量指標。結果顯示出一條清晰的規律：α=0.0時效果最差（PSNR 20.22），因為靜止背景區域完全沒有強制更新機會，背景細節逐漸劣化；隨著α增大，質量穩步提升；在α=0.6時，PSNR達到23.46的峰值；之后繼續增大α，質量基本穩定（在23.4~23.5之間徘徊），但計算量有所上升，效率下降。因此α=0.6被選為默認最優值，這個點恰好平衡了"保護背景質量"和"節省計算資源"兩個目標。當α=1.0時，所有像素點的權重都變成1，退化為與FlowCache邏輯相近的方案，驗證了這一極端情況的預期行為。

關于Phase 1時長K的影響，實驗把K從0掃到17（K=17時等同于全程使用FlowCache的粗粒度策略）。結果同樣清晰：K=0時（完全沒有初期保護階段）PSNR只有20.79，因為一開始結構就沒建立穩固；隨著K增大，質量迅速提升；到K=5時，各項指標基本趨于穩定；K=6被選為默認值，此后繼續加大K只帶來邊際改善，卻增加了延遲。這個實驗揭示了一個規律：只需要約6步全量計算來奠定視頻的"結構底稿"，之后就可以放心切換到精細模式，不會出現結構崩塌。

**七、為什么快速版和慢速版會有兩種配置**

細心的讀者可能注意到，表格里每個方法都有"slow"（慢速）和"fast"（快速）兩個版本。這兩個版本的區別主要在于緩存復用的閾值設置——閾值低，觸發計算的頻率就高，質量更好但加速比低；閾值高，計算觸發更少，加速比高但可能犧牲一些質量。MotionCache-slow對應的是質量優先配置，MotionCache-fast對應的是速度優先配置。兩種配置都顯著優于TeaCache和FlowCache的對應版本，說明MotionCache的優勢不只在于某個特定設置點，而是在整個質量-速度權衡曲線上全面領先。

歸根結底，MotionCache解決的是一個"資源分配公平性"問題。過去的方法對所有像素點一視同仁，要么都計算，要么都跳過。MotionCache意識到視頻里不同區域天然不平等——有的區域在努力"動"，有的區域在安靜"躺平"——然后給它們分別制定不同的"工作強度"，讓整個系統的算力花在刀刃上。這個思路在理論上有嚴格的數學支撐，在實踐中也被大量實驗所驗證。

對于普通用戶而言，這項研究的直接意義是：未來在使用AI視頻生成工具時，生成同樣質量的視頻，等待的時間可能從半小時縮短到幾分鐘；或者在同樣的等待時間內，生成的視頻分辨率更高、時長更長、細節更精準。對于視頻創作者、游戲開發者、電影特效團隊、甚至自動駕駛仿真數據生產這些場景，這都意味著實質性的工作效率提升。

這項研究也提出了一些值得繼續探索的方向。目前MotionCache主要針對自回歸視頻生成模型，能否將類似的精細化緩存思路遷移到其他視頻生成架構？在極端動作場景（比如快速變換的舞蹈、激烈的體育運動）中，幾乎每個像素都在高速運動，MotionCache能帶來多大收益？這些問題都留給了未來的研究者。對于想深入了解技術細節的讀者，可通過arXiv編號2605.01725查閱完整論文，代碼也已開源在GitHub（搜索ywlq/MotionCache即可找到），有技術能力的讀者可以直接嘗試復現或在自己的項目中應用。

Q&A

Q1：MotionCache和FlowCache相比，主要優勢是什么？

A：FlowCache把整段視頻作為一個整體來決定"算還是跳"，沒法區分段內動態區域和靜態區域。MotionCache則把決策精細到每一個像素點，動的地方重新算、靜的地方復用緩存。在SkyReels-V2上，兩者加速比相近（6.26倍對6.28倍），但MotionCache的PSNR高出約1.6分，人眼感知失真度（LPIPS）降低了約61%，視頻細節保留更完整。

Q2：MotionCache的運動重要性是怎么判斷的？

A：系統會計算相鄰兩幀之間的像素差異，差異越大的區域被認為運動越劇烈、越需要頻繁更新。論文從數學上證明了幀間差異是殘差變化的上界，實驗也驗證了用幀間差異預測"哪里需要計算"的準確率高達96%以上（NDCG評分均值0.9687）。這個判斷依據幾乎不需要額外計算，成本極低。

Q3：MotionCache在所有視頻類型上都有效果嗎？

A：目前論文主要在標準文本生成視頻場景下驗證了有效性，對于靜態背景多的場景（如海邊潮水、平靜走路）效果尤為突出。對于幾乎全幀運動的極端動態場景，由于大部分像素都需要高頻更新，加速空間會相對縮小，但方法本身依然適用，只是加速比會有所降低。