Sora 為什麼輸給 Codex？

GPU 時間能否被複用，開始決定產品的擴張速度。作者丨鄭佳美 編輯丨岑 峰 8 月 23 日，奧特曼在 David Senra 的播客中談到 OpenAI 內部的資源取捨時主動提到了 Sora。他說得很直接：Sora 本身是個好產品，繼續做下去也能成為一門不錯的生意，但它實在太吃 compute，同一時期，Codex 的優先級更高，於是算力和團隊投入開始往 Codex 傾斜。但有趣的是，Codex 其實也一點都不省 GPU。

Sora 生成一段視頻，要讓巨大的時空 latent 經過多輪 Transformer 計算；Codex 接到一句“把這個 bug 修掉”，後臺則可能連續跑很多輪推理、讀代碼、調用工具、跑測試，再帶著新的日誌和上下文回來繼續推理。一個把算力壓在單次視頻生成裡，另一個則是把算力攤進一條可能持續幾十分鐘甚至更久的 Agent 工作流裡。於是，Sora 和 Codex 真正拉開差距的地方開始落到機房內部。

同樣是一批 GPU，為什麼視頻生成的 compute 更難被攤開，而 Coding Agent 卻能通過 KV cache、continuous batching、prefill / decode 調度和工具等待，把算力重新塞進更多併發任務裡？事實上，Sora 並非輸在算力消耗的絕對值上，而是輸在了工作負載架構上：Sora 的算力是連續且獨佔的，而 Codex 的算力是碎片且可複用的。正是這種調度機制的差異，拉開了兩者的擴張速度。沿著這條線往下看，會發現 Sora 輸掉的那部分資源，背後或許是一場關於 GPU 時間應該怎麼用的選擇。

01Sora 為什麼難拆Sora 的成本或許從視頻進入模型時就已經開始膨脹了。它會先把原始視頻壓縮到 latent space，再切成 spacetime patches，讓 Transformer 在這些 patch 上計算。文本 token 主要沿序列方向增長，視頻 patch 同時鋪在時間、高度和寬度上，因此視頻在模型內部天然是一塊有體積的狀態。粗略來看，視覺 token 數可以理解成 Nvideo ≈ T × H × W。這裡的 T、H 和 W 已經過壓縮和 patch 化，但三維乘法關係仍然存在。視頻時間拉長會增加時間方向上的 patch，畫面尺寸提高又會擴大空間 patch。

也就是說，視頻長度和空間尺寸並不會彼此獨立地增加成本，它們會一起把 latent 網格撐大。這塊網格進入 Transformer 後，還要面對 diffusion 帶來的第二層計算。Sora 從帶噪聲的 latent 開始，每輪根據當前狀態更新視頻表示，再把新的 latent 送進下一輪。單條視頻的計算量可以粗略理解成 Cvideo ≈ D × Ctransformer(Nvideo)，其中 D 是採樣迭代次數。視頻 latent 越大，每一輪越重；採樣輪數增加，同一條視頻又要多跑幾輪網絡。這裡能看出視頻 diffusion 和 LLM 的關鍵差異。

語言模型生成後續 token 時，前面的 Key 和 Value 可以保存在 KV cache 裡，模型不需要在每一步重新構造整段歷史狀態。視頻 diffusion 每完成一輪更新，主體 latent 已經發生變化，下一輪面對的是一塊新的時空狀態，因此視頻主體的大量計算仍然需要繼續執行。所以 Sora 的成本很難靠“複用歷史”來大幅攤薄。它更像一段視效鏡頭在做多輪加工，每輪都要處理一整塊已經變化的畫面。視頻越長、尺寸越高、採樣越多，這條生成路徑就越沉。也正因為單個任務足夠重，Sora 的 GPU utilization 反而可能很好看。

大尺寸矩陣計算可以讓 Tensor Core 長時間保持繁忙，監控圖表裡 GPU 幾乎沒閒著。可利用率高只說明芯片一直在工作，並不代表單位時間交付了很多任務。一條視頻如果連續佔住一組 GPU 很久，那麼 utilization 再漂亮，單條請求消耗的 GPU-seconds 依然很高。視頻 serving 還會被 shape 差異繼續卡住。時長、分辨率和縱橫比不同，會形成不同 tensor shape。服務端為了提高 batch 效率，需要把尺寸接近的請求放進相同 bucket。多等一會兒可以湊出更厚的 batch，卻會增加排隊延遲；立即執行可以縮短等待，batch 又可能填不滿。

因此，Sora 的大部分算力成本已經鎖在一條視頻自己的生成路徑裡。採樣輪數可以減少，latent 可以繼續壓縮，模型可以蒸餾，kernel 也可以繼續優化，但 scheduler 能改動的主要是“這些重任務怎麼排”，很難改變“一條視頻本身就需要大量連續計算”這個事實。這也是理解 Codex 的入口。Codex 同樣昂貴，但它沒有把全部成本壓在一個連續計算塊裡，而是把任務拆成了許多可以暫停、恢復和重新組合的階段。02Codex 為什麼越跑越貴用戶給 Codex 一句“修掉這個 bug”，任務不會以一次模型調用結束。

Agent 可能先讀取倉庫，讓模型判斷下一步，再執行 shell；拿到報錯以後，把日誌加入上下文，重新調用模型；隨後修改代碼、跑測試，再根據新的結果繼續推理。所以一條 Codex 任務更接近很多輪 Prefill + Decode + Tool 的累加。關鍵在於，每完成一輪工具調用，下一輪模型看到的上下文往往比上一輪更厚。任務剛開始時，模型可能只有用戶要求和少量代碼。運行一段時間以後，更多文件、diff、終端輸出、測試日誌和工具結果不斷進入 prompt。用戶最後看到的也許只是幾百字完成說明，GPU 中間處理過的內容卻可能已經非常龐大。

Agent token consumption 的壓力，就藏在這條不斷增長的工作軌跡裡。如果每一輪 inference 都重新處理全部歷史，長任務會很快被重複 prefill 拖住，所以 prompt caching 對 Codex 很關鍵。假設一個 Agent 已經擁有 100K token 上下文，工具執行後只新增 3K token 日誌，如果前面的穩定 prefix 能夠命中緩存，本輪新增計算主要集中在後面這部分；一旦 prompt 前部變化導致 cache miss，系統就可能重新面對一次很重的 prefill。

這裡出現了一個重要變化：邏輯 token 數已經不能直接代表實際 GPU 成本。兩個請求都顯示 100K input tokens，其中一個大部分內容已經緩存，另一個需要重新計算，它們對 GPU 的壓力完全不同。Agent 的負載因此取決於上下文增長速度、cache hit，以及一個任務反覆進入模型多少次。進入單次 inference 後，prefill 和 decode 又有不同的硬件需求。

Prefill 一次處理很多輸入 token，矩陣尺寸較大，更容易形成 compute-heavy workload；decode 每條 sequence 每輪只生成少量 token，卻要反覆訪問模型權重和 KV cache，因此更依賴 HBM bandwidth 和併發規模。這意味著 decode 如果單獨跑一條 sequence，會非常浪費。模型權重依然那麼大，為了生成一個 token 也要參與一次完整前向計算。服務端只有把許多 sequence 放進同一個 batched forward，才能讓一次權重訪問同時推進更多請求。

而 batch 能不能繼續增大，又會受到 KV cache 限制。每條 sequence 的上下文越長，佔用的 HBM 越多。Agent 數量增加以後，GPU 可能還有算術餘量，顯存卻已經裝不下更多活躍狀態。PagedAttention 一類設計通過分頁式管理 KV cache，降低顯存碎片，本質上是在增加一張 GPU 能同時容納的活躍 sequence 數量。工具調用又把 Codex 的負載進一步拆開。Agent 跑測試、編譯代碼或等待 I/O 時，GPU 不需要繼續為它工作，CPU、容器和文件系統會接手。等結果回來後，這個 Agent 再進入下一輪 inference。

於是一個運行 60 分鐘的 Agent，並不意味著連續佔用 60 分鐘 GPU。它的任務時間被拆成了模型計算和外部執行兩部分，這讓 scheduler 獲得了一個 Sora 很難提供的空間：當某個 Agent 去跑工具時，GPU 可以立刻去服務別的 sequence。當然，這也會製造新的顯存問題。等待工具的 Agent 要不要繼續保留 KV cache？保留可以更快恢復，卻會長期佔據 HBM；驅逐可以騰出空間，任務回來時又需要承擔恢復成本。Agent 數量越多，這類取捨越像操作系統在管理大量會休眠和喚醒的進程。到這裡，Codex 和 Sora 的差異已經不在“誰更重”，而在成本有沒有被拆開。

Sora 的算力集中在一條連續生成路徑中，Codex 的算力分散在多個階段裡。正因為被拆開，Codex 才能進入下一層優化：讓 scheduler 決定這些階段怎樣共享同一批 GPU。03Codex 的效率來自重新組織計算大型模型線上運行時，權重通常要長期駐留 GPU，還要維持 tensor parallel、節點通信和緩存狀態。因此 Sora 和 Codex 爭資源，更多發生在 fleet level：一部分 GPU 長期進入視頻 serving pool，另一部分長期進入 LLM pool，上層容量系統再決定哪邊擴容、哪邊縮容。真正複雜的事情發生在 Codex pool 內部。

假設系統裡同時存在 200 條 Agent sequence，其中一部分正在 decode，一部分等待工具，還有幾十條剛從工具環境回來，需要處理新的長上下文。Scheduler 面對的約束不只包括 FLOPs，還包括 HBM 容量、memory bandwidth、KV cache residency 和延遲預算。Continuous batching 先解決 decode 的利用率問題。傳統靜態 batch 會讓一組請求綁定在一起，短 sequence 結束以後，剩下的長請求還佔著 batch。

Continuous batching 會在 token iteration 層面動態換人，一條 sequence 完成就移出，新的請求馬上補進來。Batch 越厚，一輪模型計算可以推進的 sequence 越多，模型權重訪問和內存帶寬的成本就越容易被攤薄。但這裡很快會碰到顯存牆。大量長 Agent 的 KV cache 會持續佔用 HBM，一張 GPU 可能還沒有把 Tensor Core 跑滿，顯存已經塞不進更多 sequence。此時繼續堆算力沒有意義，真正限制併發的是緩存容量和顯存管理。Prefill 和 decode 之間還存在另一種衝突。

假設幾十條 sequence 正在穩定 decode，這時一個 Agent 帶著 100K token 的新上下文回來，需要執行大型 prefill。如果這個 prefill 一次佔據很長的執行窗口，旁邊請求的 TPOT 就會明顯變差。Chunked prefill 會把長輸入切成多個小塊，讓 prefill 和 decode 交錯執行；更進一步的做法，是把 prefill 和 decode 拆到不同 GPU pool。原因在於，兩類階段本身就偏向不同硬件瓶頸：prefill 更偏計算吞吐，decode 更依賴 HBM bandwidth、KV cache 和穩定的逐 token 延遲。

把它們分開以後，可以分別按各自需求配置資源。這說明 Agent serving 的核心已經超出“把模型 kernel 寫快一點”。很多容量提升來自重新安排任務什麼時候運行、在哪運行、哪些狀態值得留在顯存，以及當前 batch 裡應該塞誰。因此，GPU utilization 到這裡已經不夠用了。

容量團隊需要同時看 GPU-seconds per task、TTFT（首字延遲，決定用戶覺得卡不卡）、TPOT（單字生成時間，決定模型“說話”有多快）、queueing latency、prefix cache hit、KV cache occupancy 和 SLO goodput（有效吞吐量，代表真正能賣錢的算力）。這些指標共同回答一個問題：在用戶能夠接受的延遲下，一小時 GPU 能維持多少有效任務。Codex 的可調度性就體現在這裡。

Stable prefix 可以減少重複 prefill，decode 可以 continuous batch，KV cache 可以分頁和驅逐，Agent 等待工具時還能讓出 GPU。它的 workload 很碎，但這些碎片可以被 scheduler 重新編排。這也把問題自然推向資源層：如果同一批 GPU 可以交錯服務更多長期 Agent，那麼一小時 GPU 實際上能夠支撐的工作時間，就可能高於一小時。

04為什麼 Codex 更容易吸收新增算力假設一個 Codex Agent 從接到任務到完成一共運行 60 分鐘，其中只有一部分時間真的在做模型 prefill 和 decode，其餘時間用於編譯、測試、讀寫文件或者等待工具。這裡的具體比例會隨任務變化，但結構很重要：Agent wall-clock time 和 GPU compute time 並非一比一。如果系統裡同時存在大量 Agent，它們也不會在同一秒一起需要 GPU。有人正在 prefill，有人在 decode，有人在跑測試，還有人在等待文件系統。

只要 scheduler 能把這些階段交錯起來，有限 GPU 就可以維持遠高於 GPU 數量的活躍工作流。可以把這個關係粗略理解成：Agent-hours 取決於 GPU-hours、模型推理佔空比和調度效率。工具執行時間越多，batch 越厚，緩存命中越高，一小時 GPU 就越有機會支撐更長的 Agent wall-clock 工作。這會直接改變新增 GPU 的含義。給 Codex 增加一批 GPU，帶來的不只是單個任務更快，還可能讓系統同時維持更多 Agent。

一名工程師可以並行啟動多個任務，一條改後端，一條補測試，一條處理另一個倉庫，只要這些任務之間沒有強依賴，機器工作時間就可以並行增長。Sora 的容量曲線更直接。一條視頻的大段 wall-clock 時間本身就在 GPU 上推進 diffusion，單條任務和 GPU 佔用結合得更緊。新增 GPU 可以直接增加視頻吞吐，但一小時 GPU 和視頻計算時間之間的關係很難拉開太大距離。Codex 的一條軟件任務卻會在 GPU、CPU、容器、文件系統和工具環境之間移動。GPU 負責模型推理，其他系統負責執行，多個 Agent 再通過 scheduler 交錯共享 inference capacity。

於是 GPU 從單純的生成設備，變成了整個 Agent 系統裡的稀缺“思考資源”。這就是為什麼 Codex 明明同樣能吞掉大量 compute，卻更容易獲得新的 compute。OpenAI 需要看的不只是單次推理成本，還要看新增 capacity 能否迅速轉化成更多並行工作量。當一批 GPU 可以支撐更多長期 Agent，同時這些 Agent 又能持續接收新的軟件任務時，資源就很容易繼續向這個方向流動。Altman 那句話的技術含義也因此清晰下來。Sora 的大量算力被鎖在單條生成路徑裡，Codex 的算力被拆成多個可交錯階段。兩邊一樣昂貴，資源回報曲線卻不一樣。

05被 workload 形狀影響命運Sora 和 Codex 的資源轉移說明，AI 產品開始多出一個會直接影響擴張速度的變量：workload architecture。同樣使用昂貴 GPU，一類任務把大量算力鎖進單條生成路徑，另一類任務可以通過緩存、batching、工具執行和調度，把同一批 inference capacity 交錯給更多工作流，它們的資源曲線自然會分開。所以未來一些看起來很底層的問題，會越來越接近產品問題。

KV cache 怎麼放，prefill 怎麼切，decode batch 能塞多厚，等待工具的 Agent 要不要驅逐緩存，這些選擇最後會決定一批 GPU 能同時維持多少任務。Sora 和 Codex 的差別，也就不只是視頻和代碼的差別。它們爭的是同一小時 GPU，究竟能撐起多少工作。參考鏈接：https://x.com/davidsenra/status/2091525869638434945上車，帶你看遍全球 AI 頂會精華可獨家暢覽：專家演講PPT大會報告全文熱門論文解讀學術新星訪談掃描上方二維碼或點擊「閱讀原文」關注專區。