Helios：一個不走捷徑的即時長影片生成模型

我腦中一直有一份心理清單，列著我以為影片生成模型必備的東西：加速用的 KV-cache、節省記憶體的稀疏注意力、防止畫面飄移的關鍵幀採樣。來自 PKU-YuanGroup 的 Helios 把這些全部丟掉——卻依然在單張 H100 上達到 19.5 FPS。這個矛盾讓我停下了滑動的手指。

我是 Dora。過去幾天我仔細閱讀了 Helios 論文和程式碼庫，在本地端跑了能跑的部分，並試圖理解為何這套方法在傳統智慧認為行不通的情況下仍然奏效。這不是一篇基準測試評測，更像是一個被「革命性」宣稱燒傷過太多次、習慣要求拿出憑據的人所寫下的筆記。

Helios 究竟是什麼

Helios 是一個自回歸影片生成模型，每個區塊產生 33 幀，透過將區塊串接在一起生成分鐘級的影片——最多可達 1,452 幀、24 FPS，大約相當於 60 秒的連續畫面。

光是這樣並不令人震驚。真正不尋常的，是它不使用的那些東西：

• 無 KV-cache
• 無因果遮罩
• 無稀疏或線性注意力
• 無 TinyVAE
• 無漸進式噪聲排程
• 無量化
• 無 self-forcing、error-banks 或關鍵幀採樣（這些是標準的防飄移工具包）

看到這份清單，感覺就像有人描述一輛不需要引擎就能跑的車。上面每一項技術的存在都有其原因——影片生成耗費資源、佔用大量記憶體，且在長序列中容易發生品質劣化。Helios 繞開了所有這些，卻仍能實現即時推理。問題不在於它是否有效——示範影片都在那裡——而在於為何有效。

三階段訓練流程

Helios 提供三個模型變體，分別對應一個訓練階段。理解這些階段有助於解釋其設計邏輯。

第一階段：Helios-Base

基礎模型。這是核心架構創新落地之處：

• 統一歷史注入（Unified History Injection） — 模型在不產生通常誤差累積懲罰的情況下，對先前的區塊進行條件化
• 簡易防飄移（Easy Anti-Drifting） — 一種訓練時的策略，取代了大多數自回歸影片模型在推理時依賴的各種技巧（self-forcing、error-banks）
• 多期記憶塊化（Multi-Term Memory Patchification） — 一種處理長時序上下文的記憶體高效方法

Helios-Base 採用 v-prediction 搭配標準的無分類器引導（CFG）。它在三個變體中產生最高的原始品質，但推理時負擔也最重——每個區塊需要 50 個擴散步驟。

第二階段：Helios-Mid

中間檢查點，引入**金字塔統一預測校正器（Pyramid Unified Predictor Corrector）**進行 token 壓縮。這是模型開始以些微品質損失換取顯著速度提升的地方。它採用 CFG-Zero*，消除了推理期間無條件模型評估的需求。

如果你使用過擴散模型，就會知道 CFG 通常會讓計算量翻倍，因為每個步驟需要跑兩次模型——一次帶提示詞，一次不帶。消除這個需求是相當可觀的效率提升。

第三階段：Helios-Distilled

最終變體採用對抗式階層蒸餾（Adversarial Hierarchical Distillation），將 50 個擴散步驟壓縮至 3 步。它從 v-prediction 切換至 x0-prediction，搭配自訂排程器（HeliosDMDScheduler），並完全捨棄 CFG 需求。

這就是達到 19.5 FPS 的變體。三步、無 CFG、無加速技巧——只是一個被訓練成一次就做對的模型。

「不走捷徑」方法的重要性

影片生成領域的大多數加速工作都是疊加式的。你建好模型，發現它太慢，於是加上 KV-cache。記憶體還是不夠，於是加上稀疏注意力。長序列品質飄移，於是加上關鍵幀採樣。每個修補方案都引入了自身的故障模式和複雜性。

Helios 走的是相反的路：讓基礎模型本身就足夠高效，從而不需要那些附加元件。訓練流程承擔了推理時技巧通常處理的繁重工作。

這裡有個容易被忽略的實際結果：活動部件越少，能出錯的東西就越少。 如果你曾經除錯過 KV-cache 損壞問題，或者看過稀疏注意力在特定幀邊界產生偽影，就會明白那些系統帶來的代價。Helios 不需要付這個代價。

記憶體方面的故事同樣引人注目。論文聲稱，訓練時可以在 80 GB GPU 記憶體內容納四個 140 億參數的模型，使用圖像擴散規模的批次大小。這對通常龐大的資源佔用來說，是相當激進的壓縮。

它能做什麼

Helios 在三個變體中均支援四種生成模式：

• 文字轉影片 — 輸入提示詞，輸出影片
• 圖像轉影片 — 第一幀加上提示詞
• 影片轉影片 — 風格轉換、重新計時、修改
• 互動模式 — 迭代精修

幀數計算有其規則：以每個區塊 33 幀的倍數為單位。想要大約 30 秒？那就是 22 個區塊 = 726 幀。完整一分鐘？44 個區塊 = 1,452 幀。區塊邊界是自回歸交接發生的地方，從我看過的示範影片來看，接縫處出奇地乾淨。

最後這點值得特別強調。自回歸影片模型通常在區塊邊界表現最差——動作卡頓、色彩偏移、物體飄移。「簡易防飄移」訓練策略似乎確實解決了這個問題，儘管在宣告問題已解決之前，我還是想看到更多樣化的測試案例。

整合與生態系統

Helios 已支援多種推理後端：

• Hugging Face Diffusers — ModularPipeline 整合
• vLLM-Omni — 具有基於階段圖架構的分散式服務
• SGLang-Diffusion — 具有最佳化核心的統一流程
• Ascend NPU — Day-0 硬體支援（Ascend 上約 10 FPS）

Diffusers 整合是最容易上手的。vLLM-Omni 路徑對於希望在不同硬體上分離預填充和解碼階段的生產部署來說很有趣。SGLang-Diffusion 感覺是面向未來的選項——它是為批次化、流程化服務而設計的，這類服務使即時應用成為可能。

Ascend NPU 支援是一個策略性信號。對非 NVIDIA 硬體的 Day-0 支援表明這並非事後才想到的。在 Ascend 上約 10 FPS，雖然比 H100 路徑慢，但對許多應用來說仍然可用。

HeliosBench

團隊建立了他們自己的基準測試——HeliosBench——專門設計用於評估即時長影片生成。這值得一提，因為現有的大多數影片基準測試都專注於短片段（4–16 秒），無法捕捉在分鐘級長度下才會出現的故障模式：時序飄移、動作劣化、物體持續性失敗。

擁有專用基準測試並不能保證客觀性，但至少意味著他們在測量正確的東西。我希望看到使用 HeliosBench 進行的獨立評估來驗證其方法論。

我仍在思考的問題

極端情況下的品質。 33 幀的區塊設計很優雅，但 44 個連續的自回歸步驟是相當多的誤差累積機會。示範影片看起來很乾淨，但示範影片永遠都看起來很乾淨。我想看到對抗性提示詞——複雜的鏡頭運動、許多互動的物體、整整一分鐘內的劇烈光線變化。

蒸餾的取捨。 從 50 步降到 3 步相當激進。蒸餾模型通常以犧牲多樣性和精細細節來換取速度。Helios-Base 變體的存在是有原因的——當品質比速度更重要時，你要付出 17 倍的計算量。這兩個操作點之間的差距相當大。

生態系統成熟度。 模型是開源的（Apache 2.0），這很好。但開源影片模型需要社群工具才能變得實用——ComfyUI 節點、微調訓練腳本、LoRA 支援。這個生態系統需要時間發展，而目前 Helios 還是全新的。

硬體需求。 在 H100 上即時運行令人印象深刻。但 H100 並不是大多數人桌上閒置的配備。對許多用戶來說更相關的問題是：在 4090 上的體驗如何？在 A100 上呢？論文對 H100 和 Ascend 的性能說得很清楚——對於長尾硬體則說得較少。

為何這值得關注

過去一年我看過很多影片生成的發佈公告。大多數都是漸進式的：更好的 FID 分數、稍長一點的片段、略微更快的推理。Helios 感覺不同，因為它挑戰了一個我沒意識到已內化的假設——即時長影片生成需要一層層堆疊推理優化。

Helios 提出的答案是：如果只是把模型訓練得更好呢？ 把複雜性推入訓練流程，而非推理堆疊。讓模型本身就具有高效性，而非事後才補上效率。

這種方法能否擴展、能否泛化、能否在生產工作負載的考驗下存活，仍是未解的問題。但這個方向很有說服力：更少的活動部件、更簡潔的架構，以及不言而喻的性能數字。

程式碼和權重在 GitHub 上。Apache 2.0 授權。如果你有一張 H100 和一個下午的時間，值得一看。