OpenAI 公佈即時訪問引擎:Codex 與 Sora 撞限額後無縫扣積分
OpenAI 介紹了為 Codex 和 Sora 打造的即時訪問引擎。當用戶觸碰速率上限時,系統會在單次請求中無縫轉扣積分繼續執行,不再硬性掐斷。這套自研架構通過解耦事件與非同步扣費,既防止誤扣重複扣款,也讓創作和程式設計心流得以延續。

當你正用 Codex 調程式碼調得起勁,或者在 Sora 裡生成影片剛摸到感覺,螢幕突然彈出一句請稍後再試,這種硬中斷幾乎能瞬間澆滅所有創作欲。
OpenAI 技術團隊成員 Jonah Cohen 發文解釋了他們如何徹底重構 Codex 和 Sora 的訪問控制架構。核心變化很簡單:OpenAI 打造了一套把速率限制和積分餘額融為一體的即時訪問引擎,當用戶用完常規額度後,系統會自動無縫切換到積分扣費,不再粗暴彈窗攔截。
把許可權判斷做成瀑布流
過去處理 AI 服務用量通常只有兩條路。要麼設死頻次上限,用完就讓使用者等;要麼從第一個 token 開始按量收費,但這樣對早期試探性使用的使用者非常不友好。
OpenAI 既不能簡單調高限流,因為這會擊穿伺服器算力並破壞公平性;也不能完全依賴傳統的非同步計費系統,因為計費延遲會導致透支和賬單對賬問題。
最後他們把許可權判斷重構成了一個決策瀑布流。系統不再二元地判斷這次請求允不允許,而是即時判斷允許使用多少、從哪裡扣除。免費額度、訂閱頻次、促銷活動、積分和企業特權全都在同一個決策棧裡,使用者在同一次請求裡就能完成額度用盡到消耗積分的平滑過渡。
OpenAI 透露,他們評估過現有的第三方計量與計費平臺,但這些平臺更適合做發票和對賬報表,無法在使用者觸碰上限的幾毫秒內做出確定性判斷,最終逼得他們只能完全自研。
寧願扣超退款,也不讓賬單算錯
這套自研系統的底層邏輯來源於企業級客戶的剛需:每一筆賬都必須能被數學證明是準確的。
系統拆分成了三套相互驅動的資料集:使用者到底做了什麼的使用事件、決定收多少錢的計費事件,以及實際扣減餘額的更新記錄。三者完全解耦,隨時可以離線重放和對賬。
每個事件都帶上了唯一的冪等鍵,哪怕系統重啟或重試,也絕對不會發生重複扣費。為了保證審計軌跡嚴謹,餘額更新實際上是在幾毫秒的極短非同步時間內完成的。
如果因為這微小的延遲導致系統不小心扣超了積分,OpenAI 的策略是自動給使用者退款。他們寧願承擔短時間透支並主動補齊差額,也絕不讓使用者在併發操作時被卡住。
為什麼重要
對普通使用者和重度創作者來說,這解決了生成式 AI 工具最令人煩躁的心智負擔。過去很多人用 Sora 生成影片時都要掐著手指算剩餘次數,一旦進入心流狀態很容易被強制打斷。現在只要賬戶裡備一點積分,就可以像插上無限續航電池一樣把活幹完,不用中途被迫換號或等冷卻時間。
我們認為,OpenAI 這一步走得相當務實,甚至可以說是生成式 AI 商業化基礎設施走向成熟的標誌。很多做 AI 應用的團隊以為計費只是調一下 Stripe 的介面,但在高併發、高算力消耗的生成場景下,訪問控制本質上就是算力排程的一部分。
它給行業指明瞭一條折中路線:前端用訂閱制和額度上限平抑高峰期流量,後端用付費積分給高淨值使用者的緊迫需求開綠燈。這種混合模式大機率會逼著 Anthropic 和 Google 等對手在各自的程式碼與多模態工具裡跟進類似的混合扣費架構。
不過這也留了一個潛在隱患。當額度耗盡的提示變得越來越隱形,使用者很容易在高度沉浸的創作中不知不覺燒掉大量積分。如何在不打斷使用者心流的同時,提供足夠清晰的即時成本感知,看起來是 OpenAI 接下來必須面對的體驗課題。
來源 (1)
- openai.com(在新分頁開啟)原文openai.com