GPT-6.1 Ultrafast 對決 GPT-6.1 Sol：三項任務，各有一項評斷

問問看 GPT-6.1 Ultrafast是否值得花上 GPT-6.1 Sol六倍的價格，而誠實的答案是：你三種工作負載中有兩種應該原封不動地留在原地。互動式編碼代理應該搬過去。整夜跑批次評估不該搬，批次摘要器也不該，而原因並不是這個等級定價過高——而是它們從來就沒有在買它所販售的東西。GPT-6.1 Sol 於 2026 年 9 月 29 日推出，Ultrafast 則在 2026 年 10 月 8 日以它之上的模式登場：同一個檢查點、同樣 1,050,000 個 token 的上下文視窗、同樣 128,000 個 token 的輸出上限、同樣 2026 年 4 月 30 日的知識截止日、同樣的答案，價格為每百萬輸入 token 12.00 美元、每百萬輸出 token 60.00 美元，對比 2.00 美元與 10.00 美元。速度等級買的是實際耗時，而實際耗時唯有對有人正在等著的任務才值錢。

那個重新框定就是整篇文章的重點。其餘部分則是算術，告訴你你的哪些工作屬於等待型，以及無論你是否事先規劃，都會伴隨那個倍數而來的兩項成本。

真正不同的是：一個請求欄位和一份帳單

沒有 Ultrafast 檢查點，沒有獨立的上下文限制，沒有替代的知識截止點，也沒有任何需要釘選的東西。你送出同一個模型識別碼，並設定 service-tier 欄位，OpenAI 會以不同方式排程該請求；若不帶該欄位送出，你就是在 Standard 上。開發者據以撰寫程式的一切都相同，而且值得對這份清單一板一眼，因為清單的長度就是論點。

• 模型 ID — 兩邊都是同一個識別碼，只有一個預設快照，沒有帶日期的版本可固定。

• 上下文 — 1,050,000 個符元的視窗、922,000 個符元的輸入上限，以及 128,000 個符元的輸出上限，兩者皆適用。

• 推理階梯 — 低、中（預設）、高、xhigh 與 max 在兩者上皆支援，而 none 與 minimal 在兩者上皆不支援。

• 工具介面 — 網頁搜尋、檔案搜尋、影像生成、程式碼解譯器、託管 Shell、套用修補、技能、電腦操作、MCP 與工具搜尋，在兩者上皆透過 Responses API 提供。

• 價格 — Standard 每百萬個符元：輸入 $2.00 / 快取 $0.10 / 快取寫入 $2.50 / 輸出 $10.00，對比 Ultrafast 的 $12.00 / $0.60 / $15.00 / $60.00。

• 超過 272,000 個輸入 token 時，整個請求會以 2 倍輸入與快取費率，以及 1.5 倍輸出費率重新計價（兩者皆適用），這使得 Ultrafast 長上下文價格為 $24.00 / $1.20 / $30.00 / $90.00。

• 速度 — 依定義，Standard 就是基準；Ultrafast 是最高一階，而 OpenAI 唯一公布的模型專屬倍數是屬於 GPT-6 Astra，而非此模型。

最後那一行是貫穿其他所有內容的但書，而且它會在更下方自成一個章節。首先，是工作。

第一項任務：互動式代理。這就是會動的那一個。

一個會連續發出四十次工具呼叫的代理迴圈，正是這個層級所鎖定的買家，因為每一回合的生成時間都會卡住下一回合的進行，而使用者就在一旁緊盯著。以一場每回合送出 30,000 個輸入 token、接收 1,500 個輸出 token、橫跨 40 回合的工作階段為例——總計 1,200,000 個輸入 token 與 60,000 個輸出 token，每個請求都遠低於 272,000 token 的重新定價門檻。

• 標準 — 120 萬個輸入 token 以 $2.00 計算為 $2.40；60,000 個輸出 token 以 $10.00 計算為 $0.60。這次執行要三美元。

• Ultrafast — 120 萬個輸入 token 以 $12.00 計為 $14.40；60,000 個輸出 token 以 $60.00 計為 $3.60。這次執行要十八美元。

• 價差 — 只要 $15.00，就能從一項輸出在其他方面完全相同的作業中，移除大部分的生成延遲。

$15.00 便不便宜，是關於分鐘的問題，不是 token 的問題。如果這段工作階段在 Standard 上要花二十分鐘，在 Ultrafast 上只要四分鐘，你就是用十五美元買了十六分鐘——大約每分鐘 $0.94——而真正重要的比較，是這十六分鐘對你來說成本是多少。以全負載成本費率計算，一位開發者每分鐘價值超過一美元，所以對 human-in-the-loop 的情況而言，答案毫無懸念。一個等待人工審核佇列的 agent，每分鐘價值為零，而在那裡，同樣的十六分鐘是免費的十六分鐘，這個 tier 就是浪費。

那就是該套用的測試，而且它與模型毫無關係。生成時間是算在誰的時鐘上，而那個時鐘又值多少？如果答案是「某個人的，而且很值錢」，Ultrafast 就是你帳單上最便宜的一項。如果答案是「排程器的，而且一文不值」，它就是最貴的一項。

第二項工作：通宵評估掃描。這是不行的。

一次評估掃描會讓數千個提示跑過模型，將結果寫入物件儲存，然後由人在早上閱讀表格。它的延遲預算不是幾分鐘，而是一整晚。管線中除了佇列裡的下一個請求之外，沒有任何事情在等待模型。

Ultrafast 並不會消除 sweep 的實際耗時成本，因為 sweep 的實際耗時成本是你自己做出的排程決定，而不是你本身遇到的延遲問題。它真正做的，是把帳單乘以六，並把這項工作移到一個帶有各自組織速率限制的用量額度上——這在無人看管的批次作業中是真實的風險，因為速率限制上限正是大規模 sweep 會撞上的失敗模式，而方案等級頁面並沒有公布那個數字。

而且同一張費率表上還有一個方案，是為這項工作定價，且定價方向恰恰相反。Batch 和 Flex 的價格是 Standard 的一半，而 API 的 Batch 處理正是為這種形態設計：大量資料量、沒有互動式截止期限、結果以非同步方式回傳。就上述數字而言，同樣的 40 回合 token 總量，在 Batch 上費用為 $1.50，而在 Ultrafast 上則為 $18.00。對一項根本無法分辨差異的工作來說，這是 12 倍的價差。

要避免的錯誤，是把 Ultrafast 當成通用型升級方案。它是階梯的頂端——Batch 與 Flex 為半，Standard 為一，Fast 為二，Ultrafast 為六——而階梯不是一份「更好版本」的選單。選錯階梯的代價，比選錯模型更高。

第三項工作：批次摘要器。同樣不行，但原因不同。

假設這個工作負載是每晚對文件儲存庫進行一次掃描：輸入很長、輸出很短、流程中沒有真人介入，而且 SLA 以小時為單位衡量。在這種情況下，token 組成反而對 Ultrafast 不利，而非有利。

272,000 個權杖的門檻就是原因。無論在哪個層級，單一請求一旦跨過這個門檻，就會讓整個請求重新計價——每一個輸入權杖、每一次快取讀取、每一個輸出權杖——輸入與快取費率變成兩倍，輸出則為 1.5 倍。因此，長上下文 Ultrafast 的價格為每百萬輸入權杖 $24.00、每百萬輸出權杖 $90.00，而重新計價是由請求本身觸發，不是由超過門檻的那部分觸發。一個偶爾送出 300,000 個輸入權杖請求的文件摘要工具，會為全部 300,000 個權杖支付長上下文費率。

快取行為讓這個問題更加雪上加霜。快取讀取是這個模型上最便宜的 token，也是最有效的成本槓桿，而且它們會隨著層級等比放大，而不是吸收掉層級差異——Standard 上每百萬快取輸入 $0.10，Ultrafast 上 $0.60，兩者都是未快取輸入費率的 5%。無論快取與全新 token 如何混合，都無法緩和這個倍數，因此即使大幅最佳化的快取管線，也無法從快速通道獲得折扣。它只是以六倍的代價支付一個較小的數字。

把兩者放在一起看，摘要工具正是 Ultrafast 溢價以絕對值而言最大、效益卻最小的情況。如果文件真的很長，而且截止期限真的只有幾個小時，正確的配置是 Batch 或標準版 Standard，而 Ultrafast 的正確用途是開發中期的迴圈：你正在反覆迭代提示詞，而且有人正等著每一次修訂。

伴隨倍數而來的兩項成本

六倍費率是價格中看得見的部分。在生產中，另外兩個看不見的部分更為重要。

首先是速率限制預算。Ultrafast 採用自己的一套限制，與 Standard 和 Fast 的額度各自獨立，而 OpenAI 是按組織個別設定這些限制，並不會公布在方案層級頁面上；官方建議是在提高流量之前先確認貴組織的限制，若需要調高，請聯絡客戶團隊。因此，把工作負載切換到 Ultrafast 會同時造成兩件事：費用倍增，以及把工作負載移往一個你可能根本讀不到的天花板。對無人看管的代理程式來說，先撞上的就是這個天花板。

第二個是節省效益的形態。Ultrafast 縮短的是詞元之間的時間，而不是首字時間，也不是思考階段。一個把大部分實際時間花在產生任何輸出之前思考的請求，即使切換到 Ultrafast，仍會感覺很慢，因為這個層級加速的是請求中從來就不是瓶頸的那個部分。這正是產生「我們付了六倍的錢，速度卻一樣」這類回報的失效模式：它衡量的是一個延遲存在於該層級觸及不到之處的應用程式。在投入之前，先測量那些秒數實際上花在哪裡——首字時間相對於詞元間時間——因為這個層級只掌控其中一項。

為什麼「更快」還不是一個你能拿來要求 O​penAI 兌現的數字

Ultrafast 以「最高可達 8 倍」作為賣點，但這個說法背後的量測數據其實屬於另一個模型。已發布的句子是關於 GPT-6 Astra Ultrafast 在 Codex 中生成 token 的速度最高可達 GPT-6 Astra 在 Standard 模式下的 8 倍。目前並沒有針對 GPT-6.1 Sol 公布同等的倍數，也沒有任何獨立第三方公布過 Sol 變體的每秒 token 數。此層級的說明文件將其描述為縮短生成輸出 token 之間的時間，並指向一份費率表。

「倍數能夠沿用」是合理的先驗——兩個模型都建構在相同的服務堆疊上，而且該層級的機制也如出一轍——但「最高可達」在那句話裡確實發揮了實質作用，而在不同用戶端上以同系列模型測得的廠商上限，並不是你的工作負載會看到的數字。較舊的那一階同樣如此：GPT-5.6 Sol 上的 Ultrafast 於 2026 年 8 月以有限預覽的形式宣布「最高可達比 Standard 處理快 14 倍」，而文件至今仍寫著預覽存取，且 Ultrafast 費率表正好就只有兩列。

你能要求 OpenAI 負責的是價格，因為價格是公開的，而且適用於每一個 token。這意味著，本頁所談的決策，是關於你自己的延遲預算的決策，而不是關於供應商的速度宣稱。

在不提交的情況下進行測試，然後切換回來

這個層級開放給所有 API 使用者，所以要回答實際耗時（wall-clock）這個問題，最省事的做法就是在開啟與關閉該欄位的情況下，把同一組提示各跑一次，再比較 token 數量和計時結果。這項測試有兩件事要留意：你的請求是否跨越 272,000 個 token 這條界線，以及首個 token 的等待時間（time-to-first-token）是否壓過 token 之間的間隔時間。只要碰上其中任何一種情況，就可能讓測試看起來像是得到無效結果（null result），但其實該層級的運作完全符合它所宣稱的表現。

切換回來是一個請求欄位，不是一次遷移，而標準通道是透過 OrcaRouter 以供應商自身的定價表價格提供 openai/gpt-6.1-sol——每百萬輸入字符 2.00 美元、每百萬輸出字符 10.00 美元，0% 加成，供應商價格直接透傳，因此供應商調價在我們這邊當天就會生效。Ultrafast 本身不是我們販售的東西；它是在你自己的 OpenAI 帳戶上計費的服務層級旗標，而這樣說比暗示並非如此更有用。單一金鑰真正買到的是標準通道，加上在單一 OpenAI 相容端點後方的其餘型錄，以及跨供應商自動容錯移轉——如果你即將把昂貴的層級放到生產代理前面，並希望標準通道是一項路由決策而非程式碼變更，那這就值得擁有。

關於快速通道、且不適用於便宜方案的一點實務提醒：WebSockets。O​penAI 建議 Ultrafast 採用持續性的 WebSocket 連線，這對於會發出大量循序呼叫的代理程式來說是正確的形式，但對於每個行程只發一次請求的批次腳本而言卻是錯誤的形式。如果你的用戶端屬於第二種，那麼該層級本身建議的傳輸方式，正是這項夜間工作該另尋他處的另一個理由。

當裁決改變時

三項發展能讓工作從「留下」清單中移除。若 GPT-6.1 Sol 的 Ultrafast 速率限制正式公布，就能消除批次情境中的上限風險。若 Sol 層級有已公布或經獨立重現的速度量測數據，你就能把省下的實際耗時納入估算，而不必憑空假設。而快速通道上多一層折扣級距——相當於 Batch 的 Ultrafast 版本，該層級依然快速，但價格不會高達六倍——將改變階梯中段每一項工作的成本效益。

那些今天都不存在。現有的是一個完全名副其實的層級：同樣的 GPT-6.1 Sol，只是排程方式不同，而每一行的價格都是六倍。把互動式代理移過去，另外兩個則不要動，並先衡量你的秒數實際上花在哪裡，再決定哪一個才是你的。