字節(jié)跳動與廈門大學(xué)突破：視頻AI生成速度提升6倍無損畫質(zhì)

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

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

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

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

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

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

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

**二、"偷懶"的藝術(shù)：緩存復(fù)用的聰明與局限**

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

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

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

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

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

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

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

**三、用數(shù)學(xué)證明"哪里動了就算哪里"不是拍腦袋**

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

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

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

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

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

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

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

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

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

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

**四、MotionCache：給每個像素點(diǎn)單獨(dú)配一個"更新計劃表"**

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

具體來說，MotionCache的工作流程分為三個環(huán)節(jié)。

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

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

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

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

**五、實(shí)驗(yàn)結(jié)果：數(shù)字背后的故事**

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

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

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

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

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

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

**六、調(diào)參的學(xué)問：α和K設(shè)多少合適**

任何方法都有需要調(diào)整的參數(shù)，MotionCache也不例外。研究團(tuán)隊做了細(xì)致的消融實(shí)驗(yàn)，幫助理解這兩個關(guān)鍵參數(shù)的影響。

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

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

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

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

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

對于普通用戶而言，這項(xiàng)研究的直接意義是：未來在使用AI視頻生成工具時，生成同樣質(zhì)量的視頻，等待的時間可能從半小時縮短到幾分鐘；或者在同樣的等待時間內(nèi)，生成的視頻分辨率更高、時長更長、細(xì)節(jié)更精準(zhǔn)。對于視頻創(chuàng)作者、游戲開發(fā)者、電影特效團(tuán)隊、甚至自動駕駛仿真數(shù)據(jù)生產(chǎn)這些場景，這都意味著實(shí)質(zhì)性的工作效率提升。

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

Q&A

Q1：MotionCache和FlowCache相比，主要優(yōu)勢是什么？

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

Q2：MotionCache的運(yùn)動重要性是怎么判斷的？

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

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

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