Matrix-Game 4.0 解析：引擎守規則，單卡 AI 畫面離可玩多遠？（2026）

2026 年 10 月 20 日，Jihai Zhang 等研究者在 arXiv 提交了〈Matrix-Game 4.0: Harnessing Video Models for Real-Time Playable Game Worlds〉。Matrix-Game 4.0 把一個看似矛盾的方向擺上桌：要讓 AI 世界更像遊戲，先把規則與狀態交給可執行的遊戲引擎，再讓影片模型生成畫面。

這個日期是 arXiv 首次提交日。官方儲存庫的更新紀錄另列 10 月 15 日釋出專案、10 月 16 日提供技術報告，不能把它們合成同一天的新產品發布。以下先看這個分工解決什麼，再拆開速度與可玩性的證據，最後判斷它值得期待在哪裡。

Matrix-Game 4.0 的核心：誰負責世界真的發生了什麼？

想像你在遊戲裡射倒一個敵人，轉身再回來。玩家期待的不只是兩段畫面都漂亮，而是敵人是否仍被擊倒、剩餘子彈是否正確、牆壁是否繼續擋住道路。這些要求都涉及同一件事：畫面之外，必須有能延續的狀態與可檢查的規則。

The video model then only has to render.

中文：接著，影片模型就只需要負責渲染。

Matrix-Game 團隊，官方專案頁 Overview

官方專案頁把系統拆成三個角色：引擎記錄狀態並輸出低多邊形代理畫面；Coding Agent 把玩家想法轉成遊戲程式與描述；影片模型根據代理畫面、文字和參考幀補上外觀。這裡的代理畫面，可以想成保留位置、形狀與運動的簡化場景草圖。

圖中的箭頭比「一句話造世界」更有解釋力。引擎先決定車移到哪裡、什麼東西擋住它，模型再畫出路面、材質與光線。Coding Agent 修改規則之後，後續遊戲仍要靠程式執行。若你想先理解這類分工，世界模型入門能補上預測、生成與行動推演的差別。

這條路線也有前例。2026 年 8 月提交的 Code World Model 原始論文已提出以程式維持世界演化、影片模型實現視覺的分工。因此，評估這篇研究的重點應放在具體的即時化工程與公開實作，不能只憑分工概念就授予「首創」地位。

Matrix-Game 4.0 的 60 FPS、83 FPS 與 112 ms，回答三個不同問題

論文作者報告，在單張 RTX 5090、864×480 輸出下，系統可呈現 60 FPS 遊玩，按鍵到首個反映該動作的生成畫面約 112 ms。論文第 5 節同時列出更高的模型吞吐量；這些數字必須連同量測範圍一起讀。

渲染器以 Wan2.2 5B 的控制模型為起點，學習對齊的低模與高品質影片配對。加速來自模型與執行工程共同改變：作者把生成單位縮為每次四幀，透過蒸餾減少去噪步數，再結合輕量編解碼、CUDA Graph、融合核心與 KV 快取優化。這些做法分別減少生成計算、重複啟動與資料處理成本；模型能否即時回應，取決於整個推論流程如何配合。

作者報告的數字	量的是什麼	讀者可以推論到哪裡
60 FPS	該測試配置的遊戲運行呈現	具體系統的示範目標；不能外推每台電腦
83.4 FPS	單步去噪的穩態模型生成率	渲染器產能；不是每秒送到瀏覽器的保證
112 ms	按鍵至第一個反映動作的生成畫面	互動回應；不能從 FPS 的倒數換算
約 18.2 GiB	作者 RTX 5090 模型推論測試的峰值顯存	這個配置的用量；不是所有同容量顯卡的相容保證

上述數字出自原論文的系統量測，屬於作者報告。本文沒有使用 RTX 5090 重現這份結果；研究的單卡成績，應保留在它的解析度、去噪設定與量測邊界內。

舉例來說，每秒 60 幀對應約 16.7 ms 的畫面間隔，但玩家按鍵可能先等下一次取樣，之後才經過生成與顯示。112 ms 約等於 6.7 個這樣的間隔；這是單純換算，並不代表知道每一段延遲各佔多少。畫面連續、操作跟手，是兩個需要各自量的品質。

這也是為什麼 Vidu S2 的互動影片解析會把幀率與互動延遲分開談。對玩家，最有感的往往是「我轉向後，什麼時候看見世界轉過去」，而不只是 GPU 一秒能生產幾張圖。

公開版本比願景更具體，也更有限

固定版本的執行文件列出城堡、古埃及與城市賽車三組場景模型。文件也明確分開提示詞模式：兩個射擊場景使用固定描述，賽車可用固定或隨場景更新的描述；頻繁更新文字編碼會降低吞吐量。這表示「系統設計裡有 Agent」與「每一幀都呼叫大型模型寫新規則」是不同的敘述。

較低階顯卡的數字尤其容易被抽走條件：官方列出的 RTX 5080 約 67 FPS、RTX 5070 Ti 約 58 FPS，使用固定提示詞與 SageAttention，量的是排除影片 I/O 的穩態模型吞吐量。它們不能直接替代 5090 的整套互動結果。

文件也將瀏覽器示範定位為單人服務，並提醒影像編碼、網路、緩衝與瀏覽器解碼會增加延遲。對想試用的人，這比一句「本地單卡能跑」更有用：先辨認哪台機器負責推論、哪個端點顯示畫面，以及你的測量有沒有把整條路徑算進去。

We train one model per game.

中文：我們為每個遊戲各自訓練一個模型。

Matrix-Game 4.0 論文，第 4.2 節

這句話直接界定了成果範圍。官方模型卡說明權重針對提供的場景與相機設定專門化；陌生幾何、快速轉動、遮擋或長時間遊玩，可能出現外觀漂移或幾何錯誤。公開權重也需要搭配專案推論程式，訓練程式與訓練資料並未隨這份模型發布。

圖中的質化評估採兩步去噪，前述 83.4 FPS 則是單步配置，兩者不能拼成一項同時達成的成績。上圖適合觀察「結構大致如何被保留、外觀增加了什麼」，卻不能單靠幾個取樣畫面判斷整段操作是否穩定。想檢查回頭後是否仍是同一個地方，WorldCrafter 的回訪記憶檢查提供另一種有用視角：刻意重走路徑，找出記憶何時失效。

AlphaLab 的判讀：規則正確與看起來正確，要接在一起

一、把確定的事寫成規則，是合理的工程取捨

我同意這個分工。子彈數、碰撞與勝負條件，都是能寫出答案的問題。把這些事放進明確狀態，開發者比較容易重播同一段輸入、定位錯誤，也能更精確地修改玩法。影片模型則把算力用在材質、氣氛與細節，讓研究問題變得比較可拆解。

但外部引擎的正確，不會自動替畫面背書。假設模型畫出一扇門，引擎卻把那裡當作實牆，玩家就會碰到「看起來能走，實際過不去」的落差。這是推演出的驗收情境，不是本文發現的實測漏洞；它說明視覺與規則之間，還需要共同的驗收。

二、狀態記憶與外觀記憶，值得分開考

引擎可以記得某個物件仍在原地，生成畫面仍可能把它畫成另一種樣子。對玩家而言，兩者都會影響可信度：前者決定東西能否互動，後者決定你是否認得它。理想的進步，是回到同一位置時，物件身分、狀態、外觀與可操作範圍都能對上。

讀過 AgentGarten 論文解析的人，會看到相近的「程式守住世界」思路。但 AgentGarten 的讀者問題是經驗如何幫 Agent 學會行動；這篇更關心即時渲染器能否把既定狀態，穩定變成玩家看得懂的畫面。兩者的成功指標不同。

三、值得追蹤的是新場景成本，而非把單卡換成萬用

我存疑的是，從三組專門化模型直接跳到「往後所有遊戲都能免做高品質美術」。開放權重讓更多研究者能檢查和改進系統，卻沒有替新遊戲省掉資料準備、場景適配、風格控制與品質驗收。若一次換地圖就需要大量重做，原型變快與整個開發週期變便宜，仍有距離。

同樣地，一段成功的賽車展示，不能替競技射擊的瞄準或高速轉身作證。合適的比較應固定畫面品質、玩法與硬體，然後同時比較延遲、失敗率及開發成本。這不是否定單卡結果，而是決定它先適合哪類作品。

四、下一份有用證據，應讓失敗也看得見

更有說服力的公開紀錄，可以讓操作者臨時選路、反覆折返、改動物件，再把引擎狀態與玩家畫面一起保存。出現問題時，要知道是規則、輸入、渲染還是傳輸出了錯。只給最後的漂亮片段，很難讓外部團隊估計自己會遇到多少返工。

模型卡主動列出漂移與場景限制，值得納入判斷；它也讓後續進步有了可對帳的方向。團隊在論文結尾提出降低成本、提高解析度與探索多人一致性等後續工作，這些是研究方向，應等待相應實作與測試，不能提前算成已交付功能。

下一步：先用一個小場景，驗三種一致性

對一般讀者，現在最值得做的是打開官方示範頁，比較代理畫面與生成畫面：哪裡只是材質變漂亮？哪裡改變了你對可互動物件的判斷？不用先買顯卡，也能練習把「畫得像」與「玩得對」分開看。

對已有合適測試環境的開發者，可以先定義一個小場景的三項驗收：規則一致，同一動作產生預期狀態；視覺一致，看見的物件對得上可互動的物件；時間一致，按鍵、狀態更新與可見回應能串成一條紀錄。這是建議的測試設計，本文未執行硬體測試。

Matrix-Game 4.0 最值得期待的地方，是把生成影片帶進一個能持續操作、修改與查錯的系統。先證明一段小遊戲能穩定接住玩家的動作，再談它能改變多大的世界，會讓這條路走得更實在。