奧特曼在播客中透露，OpenAI 為何將資源傾向 Codex 而非 Sora。Sora 的視頻生成需要大量連續算力，單條任務佔用的 GPU 時間難以複用；而 Codex 透過 KV cache、continuous batching、工具調用等機制，將算力分散至多個可交錯階段，使同一 GPU 能支援更多並行工作流。GPU 時間複用能力開始決定 AI 產品的擴張速度。

文章作者、來源：雷峰網

Sora 為什麼輸給 Codex？

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 時間應該怎麼用的選擇。

Sora 的成本或許從視頻進入模型時就已經開始膨脹了。它會先將原始視頻壓縮到 latent space，再切成 spacetime patches，讓 Transformer 在這些 patch 上計算。

文本 token 主要沿序列方向增長，視頻 patch 同時鋪在時間、高度和寬度上，因此視頻在模型內部天然是一塊有體積的狀態。

粗略來看，視覺 token 數可以理解成 N_video ≈ T × H × W。這裡的 T、H 和 W 已經經過壓縮和 patch 化，但三維乘法關係仍然存在。

延長視頻時間會增加時間方向上的 patch，提高畫面尺寸則會擴大空間 patch。也就是說，視頻長度和空間尺寸並不會獨立地增加成本，它們會共同將 latent 網格撐大。

這塊網格進入 Transformer 後，還要面對 diffusion 帶來的第二層計算。Sora 從帶噪聲的 latent 開始，每輪根據當前狀態更新視頻表示，再把新的 latent 送進下一轮。

單條視頻的計算量可以粗略理解成 C_video ≈ D × C_transformer(N_video)，其中 D 是採樣迭代次數。視頻 latent 越大，每輪越重；採樣輪數增加，同一條視頻又要多跑幾輪網路。

這裡可以看出視頻 diffusion 和 LLM 的關鍵差異。語言模型生成後續 token 時，前面的 Key 和 Value 可以保存在 KV cache 裡，模型不需要在每一步重新構造整段歷史狀態。

每完成一輪更新，視頻 diffusion 的主體 latent 已經發生變化，下一轮面對的是一塊新的時空狀態，因此視頻主體的大量計算仍然需要繼續執行。

因此，Sora 的成本很難透過「重用歷史」來大幅分攤。它更像一段視效鏡頭進行多輪加工，每輪都要處理一整塊已變化的畫面。影片越長、解析度越高、取樣越多，這條生成路徑就越沉重。

也正因為單個任務足夠重，Sora 的 GPU utilization 反而可能很好看。大尺寸矩陣計算可以讓 Tensor Core 長時間保持繁忙，監控圖表裡 GPU 幾乎沒閒著。

高可利用率僅說明晶片一直在運作，並不代表單位時間內交付了大量任務。如果一條影片長期佔用一組 GPU，那麼即使利用率再高，單筆請求消耗的 GPU-seconds 依然很高。

視頻 serving 仍會因 shape 差異而受阻。時長、解析度和長寬比不同，會形成不同的 tensor shape。伺服器為提升 batch 效率，需將尺寸相近的請求放入同一個 bucket。多等一會兒可湊出更密集的 batch，但會增加排隊延遲；立即執行可縮短等待時間，但 batch 可能無法填滿。

因此，Sora 的大部分算力成本已經鎖在一條影片自己的生成路徑裡。採樣輪數可以減少，latent 可以繼續壓縮，模型可以蒸餾，kernel 也可以繼續優化，但 scheduler 能改動的主要是「這些重任務怎麼排」，很難改變「一條影片本身就需要大量連續計算」這個事實。

這也是理解 Codex 的入口。Codex 同樣昂貴，但它沒有把全部成本壓在一個連續計算塊裡，而是把任務拆成了許多可以暫停、恢復和重新組合的階段。

用戶給 Codex 一句「修掉這個 bug」，任務不會以一次模型調用結束。Agent 可能先讀取倉庫，讓模型判斷下一步，再執行 shell；拿到錯誤後，把日誌加入上下文，重新調用模型；隨後修改代碼、運行測試，再根據新的結果繼續推理。

所以一條 Codex 任務更接近很多輪 Prefill + Decode + Tool 的累加。關鍵在於，每完成一輪工具調用，下一轮模型看到的上下文往往比上一輪更厚。

任務剛開始時，模型可能只有用戶要求和少量代碼。運行一段時間以後，更多文件、diff、終端輸出、測試日誌和工具結果不斷進入 prompt。

用戶最後看到的也許只是幾百字的完成說明，GPU 中間處理過的內容卻可能已經非常龐大。Agent token 消耗的壓力，就藏在這條不斷增長的工作軌跡裡。

如果每輪 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 和併發規模。

這意味著，如果單獨運行一條 sequence，會非常浪費。模型權重依然那麼大，為了生成一個 token 也要參與一次完整前向計算。伺服器必須將許多 sequence 放入同一個 batched forward 中，才能讓一次權重訪問同時推進更多請求。

而 batch 能否繼續增大，又會受到 KV cache 的限制。每條 sequence 的上下文越長，佔用的 HBM 越多。Agent 數量增加以後，GPU 可能還有算術餘量，顯存卻已經裝不下更多活躍狀態。

PagedAttention 一類設計透過分頁式管理 KV cache，降低顯存碎片，本質上是在增加一張 GPU 能同時容納的活躍 sequence 數量。

工具調用進一步拆分了 Codex 的負載。當 Agent 執行測試、編譯代碼或等待 I/O 時，GPU 無需繼續為其運算，CPU、容器和文件系統會接手處理。待結果返回後，該 Agent 進入下一輪推理。

因此，一個運行 60 分鐘的 Agent，並不意味著連續佔用 60 分鐘 GPU。它的任務時間被拆分為模型計算和外部執行兩部分，這讓 scheduler 獲得了一個 Sora 很難提供的空間：當某個 Agent 執行工具時，GPU 可以立即服務其他 sequence。

當然，這也會製造新的顯存問題。等待工具的 Agent 要不要繼續保留 KV cache？保留可以更快恢復，卻會長期佔據 HBM；驅逐可以騰出空間，任務回來時又需要承擔恢復成本。Agent 數量越多，這類取捨越像作業系統在管理大量會休眠和喚醒的進程。

到這裡，Codex 和 Sora 的差異已不在「誰更重」，而在成本有沒有被拆開。Sora 的算力集中在一條連續生成路徑中，Codex 的算力分散在多個階段裡。正因為被拆開，Codex 才能進入下一層優化：讓 scheduler 決定這些階段怎樣共享同一批 GPU。

當大型模型在線上運行時，權重通常需要長期駐留在 GPU 中，並維持張量並行、節點通信和緩存狀態。因此，Sora 和 Codex 的資源爭奪更多發生在機群層級：一部分 GPU 長期進入視頻服務池，另一部分長期進入 LLM 池，上層容量系統再決定何者擴容、何者縮容。

真正複雜的事情發生在 Codex pool 內部。假設系統裡同時存在 200 條 Agent sequence，其中一部分正在 decode，一部分等待工具，還有幾十條剛從工具環境回來，需要處理新的長上下文。Scheduler 面對的約束不只包括 FLOPs，還包括 HBM 容量、memory bandwidth、KV cache residency 和延遲預算。

Continuous batching 先解決 decode 的利用率問題。傳統靜態 batch 會讓一組請求綁定在一起，短 sequence 結束以後，剩下的長請求還占著 batch。

Continuous batching 會在 token 迭代層面動態換人，一條 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 帶寬、KV cache 和穩定的逐 token 延遲。將它們分開後，便可根據各自的需求配置資源。

這說明 Agent serving 的核心已超越「把模型 kernel 寫快一點」。許多容量提升來自重新安排任務的運行時間與地點、哪些狀態值得保留在顯存中，以及當前 batch 中應包含哪些內容。

因此，GPU 利用率到這裡已經不夠用了。容量團隊需要同時關注 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 實際上能夠支撐的工作時間，就可能高於一小時。

假設一個 Codex Agent 從接獲任務到完成總共運行 60 分鐘，其中只有一部分時間真正用於模型 prefill 和 decode，其餘時間用於編譯、測試、讀寫文件或等待工具。具體比例會因任務而異，但結構至關重要：Agent 的牆鐘時間與 GPU 計算時間並非一一對應。

如果系統裡同時存在大量 Agent，它們也不會在同一秒內全部需要 GPU。有人正在 prefill，有人在 decode，有人在跑測試，還有其他人正在等待檔案系統。只要 scheduler 能將這些階段交錯安排，有限的 GPU 就能支援遠高於 GPU 數量的活躍工作流。

可以將這種關係粗略理解為：Agent-hours 取決於 GPU-hours、模型推理占空比和調度效率。工具執行時間越多，batch 越厚，快取命中率越高，一小時 GPU 就越有機會支撐更長的 Agent wall-clock 工作。

這會直接改變新增 GPU 的含義。給 Codex 增加一批 GPU，帶來的不只是單個任務更快，還可能讓系統同時維持更多 Agent。一名工程師可以並行啟動多個任務，一條改後端，一條補測試，一條處理另一個倉庫，只要這些任務之間沒有強依賴，機器工作時間就可以並行增長。

Sora 的容量曲線更直接。一條影片的大量牆鐘時間本身就在 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 的算力被拆成多個可交錯階段。兩邊一樣昂貴，資源回報曲線卻不一樣。

Sora 和 Codex 的資源轉移說明，AI 產品開始多出一個會直接影響擴張速度的變數：workload architecture。

同樣使用昂貴的 GPU，一類任務將大量算力鎖定在單條生成路徑上，另一類任務則可透過快取、batching、工具執行和排程，將同一批 inference capacity 交錯分配給更多工作流程，它們的資源曲線自然會分開。

因此，未來一些看似底層的問題，會越來越接近產品問題。KV cache 該怎麼放置，prefill 該怎麼切分，decode batch 能塞多厚，等待工具的 Agent 是否要驅逐快取，這些選擇最終將決定一批 GPU 能同時維持多少任務。

Sora 和 Codex 的差異，也就不只是影片和代碼的差異。

它們爭的是同一小時 GPU，究竟能撐起多少工作。