← 目錄

K1 論文詳解

2026-07-23


單張桌上型 GPU 跑出無限開放世界:ABot-World-0 如何實現即時互動影片世界模型

ABot-World-0: Infinite Interactive World Rollout on a Single Desktop GPU

Alibaba AMAP CV LabFan Jiang、Zhaoxu Sun、Mengchao Wang、Ziyu Zhu、Chiyu Wang、Yunpeng Zhang、Wenlin Liu、Yun Wang▲ 170Hugging FacearXiv
世界模型video diffusion遊戲AI模型蒸餾即時推理

背景

近年來「世界模型」(world model)成為生成式 AI 的熱門方向之一:讓模型不只是生成一段影片,而是能根據使用者的操作(例如鍵盤方向鍵)即時「演化」出一個可互動、可探索的虛擬世界,類似 Google 的 Genie 3、以及 HappyOyster、LingBot-World、HY-World 1.5 等競品。這類模型的難點在於三個互相拉扯的目標:畫質要好、能長時間(long-horizon)維持世界一致性而不崩壞、同時還要能即時(real-time)在消費級硬體上跑起來。過去許多世界模型只能在雲端多卡叢集上以離線或準即時方式生成,普通玩家或開發者的一張桌機顯卡幾乎無法承受。

ABot-World-0 的目標正是打破這個門檻:在單張 NVIDIA RTX 5090(消費級桌上型 GPU,並非資料中心卡)上,做到 720P、最高 16 FPS 的串流生成,操作到出現第一幀的延遲僅 1.2 秒,峰值顯存(VRAM)約 19GiB。這代表這類世界模型第一次有機會被個人開發者、獨立遊戲工作室甚至遊戲主機等級的裝置實際運行,而不只是研究 demo。

方法

ABot-World-0 建立在 Wan2.2 影片擴散 transformer(diffusion transformer, DiT)骨幹之上,整體方法可以拆成「資料」、「模型訓練」、「動作與角色控制」、「部署推理」四塊:

資料基礎設施(WorldExplorer):團隊沒有單純依賴人類手動蒐集或既有影片,而是打造了一個「智能體驅動」的資料採集系統 WorldExplorer——由導航 agent 在虛擬環境中自主探索、依多階段目標選擇路徑,同步捕捉影片畫面、相機參數與操作訊號;並用「訓練回饋」動態調整不同資料類型的採集比例(哪類資料訓練效果差就多採一些)。資料來源涵蓋三種:AAA 遊戲(直接拿遊戲引擎 API 的控制訊號)、模擬引擎(Unreal Engine、3D 高斯潑濺技術 3D Gaussian Splatting,有確定性的軌跡標籤)、以及網路影片(用姿態估計產生偽標籤)。所有資料都要通過涵蓋六個維度、共 14 項確定性品質檢查(檔案完整性、視覺有效性、幾何一致性、遊戲狀態正確性、動作對齊、metadata),再加上 VLM(視覺語言模型)語義評估與同步的動作、文字標註。

漸進式蒸餾訓練:訓練分三階段。第一階段訓練一個「雙向」(bidirectional)動作條件教師模型,在多來源動作-影片資料上以全時域雙向生成方式微調。第二階段做 ODE 蒸餾(概率流常微分方程蒸餾),把這個雙向教師轉換成「因果」(causal,也就是只看過去、能逐幀串流輸出)的少步驟(few-step)學生模型,本質是學習從帶噪聲的中間潛變量直接映射到教師 ODE 定義的乾淨終點,藉此大幅減少推理所需的擴散步數。第三階段是本文的核心創新之一 LongForcing:用一個「延長時域」的雙向教師來監督學生自己做長 rollout(自迴歸連續生成)的結果,做分布匹配式蒸餾,專門解決自迴歸生成常見的「誤差累積/漂移」(distribution shift、autoregressive drift)問題——也就是模型跑久了畫面會逐漸模糊、飽和度異常、出現色塊重複等劣化現象。

動作與角色控制:控制介面採用原始鍵盤輸入(W/A/S/D 移動、I/J/K/L 視角旋轉等 8 維訊號),打包成 32 維的時序動作 token,並與 VAE 壓縮率對齊,透過 PixelUnshuffle 加殘差卷積模組注入到每個 token。這套「統一」介面同時支援第一人稱場景漫遊與第三人稱角色操控。為了讓第三人稱角色在長時間 rollout 中「看起來還是同一個角色」,團隊設計了「參考角色記憶」(reference-character memory)模組,用角色的標準(canonical)圖片編碼成 identity token,並採用不對稱的 memory-video attention,持續提供外觀線索。

部署推理棧:為了塞進單張桌機 GPU 並做到即時串流,團隊共同設計了一整套系統層優化:輕量化 VAE 解碼器(裁剪過的解碼架構)、SageAttention2 高效注意力、Fast-RoPE 時序位置編碼、有界 KV cache(本地上下文快取加滾動淘汰機制,並可對 cache 做量化)、記憶體感知排程(按執行順序做模組分階段載入以壓低峰值顯存)、以及低位元(low-bit)DiT 推理(預設 FP8,並提供更激進的量化選項換取更高吞吐量)。

實驗結果

在效能面,ABot-World-0 在最佳化的低位元配置下,於單張 RTX 5090 上可串流輸出 720P 影片、最高達到 16 FPS,動作輸入到畫面第一幀輸出的延遲僅 1.2 秒,推理時峰值顯存約 19GiB——這個顯存量級是消費級旗艦卡就能負擔的範圍,而非需要 40GB/80GB 級的資料中心 GPU。

在效果評測上,團隊建立了自有 benchmark WorldRoamBench,並與 Genie 3、HappyOyster、LingBot-World、HY-World 1.5 等同類世界模型比較,在動作保真度(action fidelity)、軌跡跟隨(trajectory following)、視覺品質、物理一致性與記憶保持(memory retention)等多個維度上取得具競爭力的表現。此外還做了延伸的長時互動 rollout 實驗,包括「小時級」的連續 rollout(驗證場景連貫性與可控性維持)、以及「天級」的極限壓力測試(在多個取樣時間點檢查畫質與世界動態是否仍然活躍、未塌縮)。

針對 LongForcing 的消融實驗特別值得一提:在 60 秒的連續 rollout 中,相較於單純 Causal-Forcing(即只用因果教師做逐幀監督、不做延長時域對齊)的基線,加入 LongForcing 後在 rollout 後半段的 HPSv3(人類偏好評分)分數明顯更高,且畫面飽和度異常、模糊、色塊重複等自迴歸誤差累積的典型症狀顯著減少——這直接證明了「用延長時域教師對齊長 rollout」這個設計對長時間穩定性確實有效,而不只是理論上合理。另外,模型在分布外(out-of-domain)場景與角色組合上也展現出一定的泛化能力,並能生成碰撞、環境痕跡、幾何約束等合理的物理互動效果。

意義

ABot-World-0 的價值不在於單一指標刷新 SOTA,而在於把「可互動世界模型」從研究論文式的雲端 demo,往「消費級硬體可跑」的方向推進了一大步。過去這類系統的效能瓶頸不只是模型本身的生成品質,更是工程系統層面——擴散模型多步採樣天生慢、雙向注意力天生不能做串流、長 rollout 天生會漂移崩壞。這篇論文的解法是「教師-學生蒸餾三階段」加「系統層全棧優化」的組合拳:用 ODE 蒸餾把多步擴散壓成少步、用因果注意力換取串流能力、再用 LongForcing 專門治療長時漂移問題,最後靠低位元推理、輕量 VAE、高效 kernel 把一切塞進 19GiB 顯存與 16 FPS。

對產業而言,這意味著遊戲原型設計、虛擬角色互動、UGC(使用者生成內容)式的世界探索體驗,未來有機會不依賴雲端算力、直接在玩家自己的桌機上運行——這對成本結構和延遲體驗都是質的改變。同時,WorldExplorer 這套「訓練回饋驅動的智能體資料採集」思路,也提供了一個可能推廣到其他世界模型/具身智能(embodied AI)訓練場景的資料飛輪範式:讓資料採集本身變成一個閉環優化問題,而不是一次性靜態蒐集。整體來看,ABot-World-0 是世界模型從「能不能生成」邁向「能不能落地在真實終端裝置上跑起來」這條路上頗具代表性的一步。

DataFlow-Harness:讓 LLM 寫的資料處理流程不再是「一次性腳本」

DataFlow-Harness: A Grounded Code-Agent Platform for Constructing Editable LLM Data Pipelines

Peking UniversityRunming He、Zhen Hao Wong、Hao Liang、Zimo Meng、Chengyu Shen、Xiaochen Ma、Wentao Zhang▲ 122Hugging FacearXiv
LLM Agent資料工程MCPDAGAI Coding

背景

現在很多團隊已經在用 LLM coding agent(例如 Claude Code)來自動化資料處理工作,例如生成 QA 資料集、做審核治理、處理長文件、多欄位評分、schema 正規化、資料品質過濾等。這些 agent 確實能寫出可以跑的 Python 腳本,解決眼前的任務。

但論文作者觀察到一個問題,他們稱之為「NL2Pipeline gap」(自然語言轉工作流程的落差):agent 產生的腳本通常只是一次性的、不透明的程式碼檔案,並不會自動變成平台裡「可持久保存、可編輯」的工作流程物件。換句話說,今天你叫 agent 生成一個資料清理流程,它給你一份 script,但明天你想調整其中一個步驟、或想在視覺化介面上檢視流程結構、或想讓另一個非工程背景的同事去修改,你會發現這份 script 沒辦法被納入平台管理——沒有結構化的節點與依賴關係,沒辦法被 UI 讀取、沒辦法安全地做局部修改,只能整份重寫或人工重構。

DataFlow-Harness 就是為了填補這個落差而設計的平台。它的核心想法很直接:與其讓 agent「自由發揮寫腳本」,不如引導 agent 直接在平台原生的資料結構——有向無環圖(DAG,directed acyclic graph)——上做「型別化、漸進式的變更(typed, incremental mutations)」。這樣產生的成果從一開始就是平台可以理解、儲存、視覺化、並且日後可編輯的工作流程,而不是一份要另外「材料化(materialize)」進系統的獨立腳本。

方法

DataFlow-Harness 的架構由四個互相配合的部分組成:

DataFlow-Skills:這是程序性知識的載體,把「怎麼組裝一個資料流程」的隱性經驗,轉成明確的藍圖——包括建議的組裝順序、以及哪些 operator(運算子)彼此相容、哪些組合方式在領域中是合理的。這一層負責補足 LLM 本身缺乏的「業內施工順序知識」。

MCP(Model Context Protocol)工具層:實作了一套「Request-Validate-Commit」協定。Agent 想對 pipeline 做任何變更,都要先透過 MCP 拿到目前 pipeline 的即時狀態與可用 operator 清單(即時 operator registry),再把變更表達成型別化的操作請求,系統會驗證這個操作是否會造成環路(acyclicity 檢查)、schema 是否相容,通過驗證才會真正提交(commit),並透過 WebSocket 把最新狀態廣播出去,讓其他介面同步更新。

資料流程後端(Data Pipeline Backend):是整個系統的「單一事實來源」,把一個 pipeline 表示成 P = (D, O, E, S, R) 這樣一個結構——D 是資料來源、O 是 operator 實例、E 是依賴關係邊、S 是 schema 紀錄、R 是執行期狀態。所有的 agent 操作最終都落到這個結構化表示上,而不是散落在腳本文字裡。

DataFlow-WebUI:提供雙模式、彼此同步的介面——一邊是對話式的自然語言建構介面,另一邊是視覺化的 DAG 編輯器。使用者可以用講的方式叫 agent 修改流程,也可以直接在圖上拖拉節點做調整,兩邊即時同步,這解決了「只有工程師看得懂 script、其他人無法參與」的問題。

整體设计哲學是:讓 agent 的每一步操作都是「有型別、可驗證、可回溯」的圖變更,而不是任意生成一大段自由格式的程式碼。

實驗結果

研究團隊建立了一個涵蓋六種產業情境、共 12 個任務的資料工程 benchmark(QA 生成、審核治理、長文件處理、多欄位評分、schema 正規化、品質過濾),並比較四種設定,每種各跑 10 次(總共 120 次執行):

  • Vanilla Claude Code(不受限制的自由腳本生成)
  • Context-Aware Claude Code(有讀取專案上下文的腳本生成基準線)
  • MCP-Only(只有平台的圖結構限制,但沒有 DataFlow-Skills 的程序性引導)
  • DataFlow-Harness(完整方案)

成功率:DataFlow-Harness 的觀測到端到端通過率為 93.3%,Context-Aware Claude Code 是 94.2%,兩者只差 0.9 個百分點;Vanilla Claude Code 是 91.7%;而 MCP-Only(拿掉 Skills 引導)只有 83.3%,顯示光有結構化的 MCP 層還不夠,程序性知識(Skills)才是補齊成功率的關鍵。

成本與延遲:相較於 Vanilla Claude Code,DataFlow-Harness 把金錢成本降低了 72.5%(從每次任務 $0.950 降到 $0.261),生成延遲降低了 49.9%(從 190.7 秒降到 95.5 秒)。相較於效果最接近的 Context-Aware Claude Code,DataFlow-Harness 的成本則低了 42.8%,但成功率幾乎持平。

消融分析(RQ3):程序性引導(Skills)在「需要隱性施工知識」的任務上最有價值,例如 QA 生成任務,有 Skills 的版本從 18/30 次成功大幅提升到 29/30 次;但在簡單的路由型任務上,有沒有 Skills 差異不大(兩者都接近滿分),說明 Skills 的效益取決於任務本身的程序複雜度,而不是普遍適用。

下游訓練效用(RQ4):在數學推理資料 pipeline 上,用 DataFlow-Harness 產出的資料訓練一個 epoch 後,下游模型準確率達到 51.6%,優於 Vanilla Claude Code 產出資料訓練出的 49.9%;在通用指令微調 pipeline 上,DataFlow-Harness 產生資料訓練出的模型整體 benchmark 平均分達 63.8,優於 61.5。

案例研究(教科書轉 VQA):這是一個需要結合文件解析、版面分析、多模態理解的複雜抽取任務。DataFlow-Harness 達到 97.2% 精確率、87.3% 覆蓋率,明顯優於 MCP-Only 的 78.4% 精確率、62.1% 覆蓋率,顯示當任務需要串接成熟的 operator 生態系時,Skills 引導的優勢更明顯。

意義

這篇論文的意義不在於「LLM 又能多寫幾行程式碼」,而在於它重新定義了 agent 產出的「單位」——從一次性的腳本文字,變成平台可以長期管理、可視化、可協作編輯的結構化工作流程。這對企業級資料工程場景特別重要,因為實務上資料 pipeline 很少是「寫一次就不用改」的,後續維運、需求變更、跨團隊交接都需要一個可讀、可追溯、可局部修改的表示方式,而不是每次都重新生成整份腳本或依賴工程師手動重構。

從成本效益角度看,72.5% 的成本下降與 49.9% 的延遲下降,同時成功率只比表現最好的基準線低不到 1 個百分點,這說明「給 agent 一個結構化、受限的施工環境(MCP + DAG)」不僅沒有犧牲太多效果,反而因為減少了自由發揮空間、減少了無效嘗試與重寫,大幅節省了 token 用量與時間。這對於需要大規模、重複性地用 agent 建構資料 pipeline 的公司來說,是一個很實際的降本方向。

另一個值得注意的發現是:MCP-Only(只有結構限制,沒有 Skills)成功率明顯下降到 83.3%,說明「限制 agent 只能在合法的圖結構裡操作」本身還不夠,agent 仍然需要領域內「怎麼做才對」的程序性知識——換句話說,平台化的關鍵不只是給 agent 一套 API 或 schema 限制,更需要把業內經驗封裝成可注入的 Skills。這對想要複製這套方法論到其他領域(例如 ETL、MLOps、DevOps 自動化)的團隊來說,是一個重要的設計提示:光做「工具化」不夠,還要做「知識化」。

當然,論文也坦承其評估規模有限(12 個任務、120 次執行),統計顯著性與泛化性仍待更大規模驗證,但作為一個展示「即時平台狀態接地(live platform grounding)」如何同時兼顧可靠性、可編輯性與成本效率的原型,DataFlow-Harness 提供了一個具體、可衡量的參考架構,對正在思考如何讓 LLM agent 產出「可長期治理的系統資產」而不是「用完即丟的程式碼」的團隊,具有直接的參考價值。

文字模板token其實是Diffusion Transformer的隱性語意暫存器

Text Template Tokens Are Implicit Semantic Registers in Diffusion Transformers

RTP-LLMMaohua Li、Qirui Li、Yanke Zhou、Yiduo Li、Zhaosheng Chi、Chao Xu、Cuifeng Shen、Yixuan Xu▲ 66Hugging FacearXiv
diffusion transformer可解釋性文字生成圖片注意力機制模型剪枝

背景

文字生成圖片的擴散模型近年全面轉向 diffusion transformer(DiT)架構,例如 Qwen-Image、FLUX 系列等,把文字 token 與圖片 latent token 放進同一個 transformer 裡聯合處理、共同做注意力運算。這種設計效果很好,但模型內部到底怎麼「消化」文字提示、如何在逐步去噪過程中維持物件身份(object identity)一致,始終是個黑箱。

值得注意的是,輸入到文字編碼器(text encoder)的 token 序列裡,除了真正描述畫面內容的「提示詞 token」(prompt-content tokens),還夾雜著大量屬於固定範本、跟畫面內容無關的「結構性模板 token」(structural template tokens)——例如系統提示詞、格式標記等重複出現的片段。過去大家普遍假設,這些模板 token 只是無意義的填充物,真正承載語意的一定是提示詞 token 本身。這篇論文正是要挑戰這個假設:模板 token 究竟在 DiT 內部扮演什麼角色?

方法

作者提出一套針對大型 DiT 的「因果可解釋性框架」(causal interpretability framework),結合注意力分解(attention decomposition)與跨 token 範圍、跨注意力頭(head)、跨層(layer)的針對性介入實驗。具體做法包括:token 層級的注意力貢獻拆解、對特定 span(提示詞 vs. 模板)做條件替換或遮罩、跨去噪軌跡的「注意力頭移植」(head transplantation),以及逐層的因果遮罩實驗,藉此觀察哪些 token、哪些頭、哪些層真正對最終生成結果有因果影響,而不只是相關性。

研究主要以 Qwen-Image 系列模型(包含 Qwen-Image、Qwen-Image-2512)為對象,並延伸驗證到 FLUX.2、Krea-2-Turbo 及一些圖片編輯模型,評測則使用 GenEval(553 條提示詞)、DPG-Bench(1,065 條)以及中文提示詞的 Qwen-Image-Bench(1,000 條)三個 benchmark。

實驗結果

第一個關鍵發現:在文字編碼器輸出端,模板 token 幾乎不含提示詞特有的語意——把 100 個不同提示詞的模板 token 表徵取平均後,彼此相似度仍高達 93%,顯示這些 token 本質上跟具體畫面內容無關。

但進入 DiT 之後,情況完全反轉。模板 token 竟成為圖片 token 對文字 token 注意力的主要「注意力匯聚點」(attention sink):在 GenEval 提示詞上,結構性模板 token 吸收了約 19% 的圖片到文字注意力,而真正承載內容的語意 token 只佔約 4.6%,換算成單一 token 的平均吸收率,兩者相差高達 6.4 倍。更驚人的是,若把對模板 token 的圖片→文字注意力遮罩掉,物件的視覺身份會在最前面兩個 block 內就迅速崩潰——證明模板 token 對維持物件一致性具有真正的因果作用,而非單純的統計副產品。進一步的頭移植實驗顯示,只需替換約 18% 的注意力頭,就能把物件身份從一條去噪軌跡轉移到另一條。這些結果共同指出:語意其實是先被寫入圖片 latent token,再「回讀」進模板 token,而非由提示詞 token 直接傳遞——模板 token 扮演的是「隱性語意暫存器」(implicit semantic register)的角色。

基於這個機制,作者設計了一個免訓練的剪枝規則:找出那些主要把注意力放在提示詞 token 上的頭,證明這類頭其實是「多餘的」,直接剪掉。結果在不重新訓練的情況下,移除了 20% 的注意力 FLOPs,GenEval 分數只下降 1.4 分。此外,論文也刻畫出 DiT 內部計算的分工方式:語意路由(semantic routing)與視覺合成(visual synthesis)分別由不同頭負責,而深度方向上則呈現「身份形成 → 身份傳播 → 精細化」的漸進式結構。

意義

這篇論文最有意思的洞見在於:輸入端負責攜帶語意的 token,不一定是生成過程中負責維持語意的 token。過去對 DiT 的直覺理解——提示詞 token 一路把語意「傳」到圖片——並不完全成立;真正的機制更像是語意先被寫進圖片本身,再透過模板 token 這個中介暫存器來穩定與傳播。這對理解 transformer 式生成模型的內部計算方式提供了一個新的因果視角,也呼應了近年在 LLM 領域對「attention sink」、「register token」的觀察,顯示這類現象可能是 transformer 架構的通用特性,而不只是語言模型獨有。

從實用角度看,這個發現直接轉化成一個零訓練成本、可即插即用的剪枝方案——20% 的注意力算力節省、僅 1.4 分的 GenEval 代價,對於需要大規模部署文字生成圖片服務的公司而言,是相當有吸引力的效率提升。更長遠地看,這類因果可解釋性方法也為未來設計更高效的 DiT 架構(例如主動設計語意暫存器,而非依賴模板 token 意外承擔這個角色)提供了具體的實驗依據。