Sora 2 是 OpenAI 首個普遍可用的文本轉影片模型，可透過官方 OpenAI API 以及日益增長的聚合器路由以程式化方式存取。其計費方式與文字模型不同（按生成影片的每秒計費，而非按 token），開發者在整合前關心的實務問題也與 LLM API 不同。一段剪輯實際要花多少錢？要花多久才能生成？有哪些速率限制？透過聚合器而非直接使用 OpenAI 時會有什麼變化？
本文是我們在規劃自家影片生成功能時希望能找到的參考。內容面向已經走過「Sora 有趣嗎？」階段、並需要回答「成本多少、整合要花多久、承諾前該知道什麼？」的開發者。
**快速閱讀：**Sora 2（標準模型）在 720p 的價格是每秒 $0.10。Sora 2 Pro 在 720p 為每秒 $0.30，在 1024p 為每秒 $0.50。典型的 10 秒剪輯在標準模型是 $1.00，在 Pro 的 HD 為 $5.00。生成為異步；對於 5–10 秒的剪輯，預期端到端耗時為 30–90 秒。存取需要付費 OpenAI 帳戶，最低使用等級為 Tier 2。
2026 年 Sora API 存取現況
Sora 2 於 2025 年 10 月 7 日在 OpenAI API 上線，之後持續可用。模型識別符為 sora-2（目前的快照 ID 為 sora-2-2025-12-08），更高保真度變體為 sora-2-pro。兩者皆支援文字轉影片與圖像轉影片，並提供同步音訊輸出。自 2026 年 1 月 10 日起，ChatGPT 產品的免費層消費者存取已終止，這使開發者級的 Sora 使用集中至付費 ChatGPT 訂閱或直接 API 存取。
以程式化方式使用 Sora 有三條路徑：
- OpenAI 直連 API。 正統路線。按秒計費、僅付費可用，需至少儲值 $10 以達到使用等級 Tier 2 以解鎖 Sora 模型存取。支援 SDK 與 REST API。
- Azure OpenAI。 微軟的企業路徑，在 OpenAI 官方費率之上疊加 Azure 訂閱開銷與企業合規功能。相同的按秒定價；不同的運維介面。
- 聚合器。 以自家統一 API 封裝 Sora 的服務。多數聚合器以與 OpenAI 同價的方式轉嫁按秒定價；其價值在運營面（單一憑證、單一帳單、與你的文字模型流量相同的 SDK）。也有部分聚合器提供自有資費方案，本文稍後會討論。
Sora 2 的每秒影片定價
Sora 的定價按模型層級與輸出解析度劃分，以每秒費率乘以剪輯時長得到生成成本。以下為 2026 年 5 月自 OpenAI 官方定價頁核實：
| Model | Resolution | Supported durations | Price per second | 10-second clip |
|---|---|---|---|---|
| Sora 2 (standard) | 720p | 4s, 8s, 12s | $0.10 | $1.00 |
| Sora 2 Pro | 720p | 10s, 15s, 25s | $0.30 | $3.00 |
| Sora 2 Pro | 1024p (1792×1024) | 10s, 15s, 25s | $0.50 | $5.00 |
關於定價結構的說明。 定價針對輸出，而非輸入；Sora 沒有像文字模型那樣的輸入 token 計費。圖像條件（提供參考圖像以錨定生成）不會改變每秒費率。各模型層級的時長選項是離散且固定的：在標準模型上不能請求 7 秒，只能是 4、8 或 12 秒。
兩個值得明確指出的實務影響。其一：這種定價更像影片渲染的帳單，而不是 LLM 的帳單。成本由輸出時長驅動，而非提示的複雜度或 token 數。其二：在 HD 下，Sora 2 與 Sora 2 Pro 的每秒成本相差 5 倍：10 秒剪輯在標準版為 $1.00，在 1024p 的 Pro 為 $5.00。為任務選對層級是你最大的成本槓桿，務必謹慎評估哪些工作負載真的需要 Pro 的更高保真度。
速率限制與配額
Sora 的速率限制建立在 OpenAI 的標準使用等級系統之上。與 Sora 相關的要點如下：
- **最低等級要求：**Tier 2，需至少儲值 $10 的 API 點數。Tier 1（新帳戶預設）不包含 Sora 模型存取。
- **併發生成限制：**依 OpenAI 的速率限制文件，影片生成的併發數量受等級限制：較低等級僅可同時執行少量生成，隨使用等級提升而擴大。確切上限以帳戶為準，可在 OpenAI 控制台查看。若為大規模工作負載，建議一開始就規劃 Tier 3 或 Tier 4。
- **配額申請：**超過預設等級上限的更高併發可透過 OpenAI 的速率限制提升表單申請。核准取決於工作負載，且非即時；若是有可預期流量高峰的上線計劃，請在發佈前數週提出申請。
值得知道的是：Sora 的速率限制池與同帳戶上的文字模型速率限制分開管理。大量的 Sora 流量不會影響你可用於 GPT-5.5 呼叫的速率額度；反之亦然。將兩者視為獨立的容量規劃問題。
生成時間：實際該如何預期
Sora 天生是異步設計。你送出生成請求，收到一個作業 ID，並輪詢（或透過 Webhook 回呼）以等待完成。從請求到完成的端到端耗時取決於輸出的時長與解析度、OpenAI 基礎設施的當前負載，以及你的作業是否在帳戶內排隊等待他人之後。
基於觀察行為的現實預期：
| Output | Typical wall-clock time | Notes |
|---|---|---|
| Sora 2 standard, 4s @ 720p | 20–45 seconds | 最快路徑；適合迭代 |
| Sora 2 standard, 8s @ 720p | 40–90 seconds | 最常見的生產時長 |
| Sora 2 standard, 12s @ 720p | 60–120 seconds | 偏長的社群內容 |
| Sora 2 Pro, 10s @ 720p | 60–150 seconds | 高品質；成本約為標準版的 3 倍 |
| Sora 2 Pro, 15s @ 1024p | 120–240 seconds | Full HD，高峰時段觀察到較長的排隊 |
| Sora 2 Pro, 25s @ 1024p | 200–360 seconds | 最長時長；價格線性擴增 |
兩個運營上的後果：
- 面向使用者的延遲預算需要重想。 若你的產品希望影片生成對使用者動作有「回饋即時」的體感，短片段 30–90 秒的等待意味著你需要一個能處理等待的 UX：進度指示器、在影片生成期間讓使用者可以並行處理的其他任務，或針對可預期情境的預生成。把 Sora 當作同步 API 呼叫，是團隊最常犯的架構錯誤。
- 輪詢與 Webhook 的取捨很重要。 天真的輪詢（高頻打狀態端點）會浪費你的速率限制額度與模型算力。請使用帶抖動的指數退避，或在環境允許時設定 Webhook 回呼。實務上可行的輪詢模式是：前 1 分鐘每 10 秒輪詢一次，之後每 30 秒一次，並以該時長在模型上的預期上限作為硬逾時。
支援的參數與提示結構
相較於像 DALL-E 3 這類圖像生成模型，Sora 的 API 面相刻意簡化。可調的旋鈕較少，但現有的旋鈕很關鍵。要點如下：
- **model：**sora-2 或 sora-2-pro。此選擇同時決定定價與可用的時長／解析度（見上方定價表）。
- **prompt：**描述場景的自由文本。Sora 處理電影語言（機位、運鏡、光線）、角色動作與環境細節。模型對提示結構很敏感：先鋪陳場景，再描述動作，最後補充技術指示，比把所有內容擠在一段密集文字中更可靠。
- **image：**可選的參考圖像，用於圖像轉影片。參考圖像作為第一幀錨點；模型從該起點生成運動。適用於產品示範、角色連貫與任何主體外觀不可更動的場景。
- **duration：**時長（秒）。受所選模型的離散選項限制（sora-2 為 4/8/12；sora-2-pro 為 10/15/25）。成本隨時長線性擴增。
- **size：**解析度。標準模型為 720x1280（直式）或 1280x720（橫式）；Pro 另外支援 1024x1792／1792x1024。長寬比由 size 隱含決定。
值得注意的缺失。 公共 API 目前不提供種子控制（因此跨次重現性不保證），也沒有像 Midjourney 等圖像模型那樣的獨立風格控制。模型有自己的風格傾向；主要槓桿是提示工程，而非參數調校。
使用 OpenAI Python SDK 的 Sora 2 生成請求簡例：
| from openai import OpenAIimport timeclient = OpenAI(api_key="YOUR_API_KEY")# 建立影片生成任務job = client.videos.create(model="sora-2",prompt=("日出時分拍攝覆雪山峰的廣角鏡頭。 ""當第一縷陽光照亮山頂時，攝影機緩緩向左運鏡。 ""映画風格、黃金時刻、4K 級光效。"),size="1280x720",duration=8,)# 輪詢等待完成while True:job = client.videos.retrieve(job.id)if job.status == "completed":video_url = job.output[0].urlbreakelif job.status == "failed":raise RuntimeError(f"生成失敗: {job.error}")print(f"目前狀態: {job.status}")time.sleep(10)print(f"影片已就緒: {video_url}") |
|---|
成本算例
按秒定價讓成本可預測，但前提是你清楚自己的工作負載形狀。以下三個代表性情境：
情境 1：SaaS 登陸頁的短產品示範
一段 5 秒的剪輯展示產品 UI 動態，生成一次並作為行銷站點的主視覺影片。發佈前預計迭代 5–10 次以得到滿意的片段。
在 Sora 2 標準版 720p 的成本：5s × $0.10 = $0.50 每次生成。以 8 次迭代達到最終版：$4.00。最終發佈版於 Sora 2 Pro 1024p：5s × $0.50 = $2.50（單次）。專案總成本：約 $6.50（若干次迭代＋HD 最終版）。
情境 2：行銷活動的一批 50 支剪輯
50 支獨立的 8 秒產品剪輯，每支依不同功能描述生成，全部在 Sora 2 標準版 720p。沒有迭代預算；接受首次生成結果。
成本：50 × 8s × $0.10 = $40.00。為未命中的剪輯增加 30% 迭代預算（50 × 0.30 = 15 次重試 × 8s × $0.10 = $12）。合計：約 $52.00 完成整個活動。
情境 3：面向消費者產品的用戶生成影片功能
使用者在你的 App 內按需生成 6 秒剪輯，使用 Sora 2 標準版 720p。平均用量：每日 1,000 支。你向使用者每次生成收費 $0.50，並以成本差作為單位毛利。
每支使用者剪輯成本：6s × $0.10 = $0.60。若使用者定價為 $0.50，此工作負載在標準層級下是虧損的：每次生成比收費多 $0.10。標準 720p 的損益兩平價至少需 $0.65（尚未包含基礎設施開銷）。每月 30,000 支：月度 Sora 帳單約 $18,000。在上線任何面向使用者的影片功能前，這類單位經濟性檢查非常必要。
**三個情境的總結：**對於行銷與一次性內容的工作負載（迭代次數可控、關注的是每件最終成品成本），影片生成的確經濟可行。對於大規模面向使用者的功能就更具挑戰，因為每次生成的成本必須覆蓋使用者支付的價格與產品開銷。承諾前務必明確你正在定價的工作負載類型。
OpenAI 直連與聚合器存取的比較
在多種路徑可用的情況下，多數團隊的實務問題是該整合哪一個。老實說，答案取決於你的其餘技術棧。
相同之處
輸出品質、模型層的生成時間、支援的參數與按秒定價通常不因路徑而異，因為多數聚合器以與 OpenAI 同價轉嫁費率，且底層模型相同。若只以輸出品質作為選擇依據，兩者無差。
不同之處
- **計費介面。**OpenAI 直連由你的 OpenAI 帳戶計費；聚合器則經由其自家點數或訂閱系統計費。若團隊已管理文字模型用量的 OpenAI 帳單，直連不會新增負擔。若運行多供應商工作負載（例如 Anthropic 的 LLM、Black Forest Labs 的圖像模型、Sora 的影片），聚合器可把這些匯總到一張發票。
- **可觀測性。**OpenAI 控制台能清楚呈現 Sora 的請求級用量。聚合器的儀表板在影片生成工作負載上的表現因服務而異；有的具備專門的影片觀測能力，有的則把影片當作一般 API 呼叫。若可觀測性是優先考量，上線前值得確認。
- **速率限制的池化方式。**在 OpenAI 直連中，你的 Sora 速率限制綁定於你的 OpenAI 帳戶與等級；在聚合器中，有些情況會在其客戶基礎上做池化，有些則按客戶分配。若是高量生產流量，整合前請詢問聚合器如何分配速率限制。
- **地理與合規態勢。**OpenAI 直連由 OpenAI 的基礎設施處理，並提供其所支援的資料屬地選項。有些聚合器位於不同法域，其資料屬地規則不同；也有些無論如何都轉送至 OpenAI 的美國基礎設施。對受監管的工作負載而言，這是決定性因素，值得要求聚合器的業務團隊以書面說明。
CometAPI 的定位
CometAPI 在單一、與 OpenAI 相容的端點後，將 Sora 2 與 Sora 2 Pro 與 500+ 其他模型一同提供，使用單一憑證與統一帳單。CometAPI 上的 Sora 定價與 OpenAI 的每秒費率一致；其運營價值在於把 Sora 與其他模型流量匯總到同一張發票。對運行混合工作負載（多供應商文字模型、圖像生成與 Sora 影片）的團隊，這是核心理由；對只用 Sora 與一兩個文字模型的團隊，運營收益較小，直接使用 OpenAI 也是可以辯護的選擇。
上線考量
在讓 Sora 面向生產流量前，有幾個模式值得先做好：
- **異步作業生命週期處理。**把每次 Sora 生成當作長時間作業，而非請求。建立後立即持久化作業 ID；服務重啟後能繼續輪詢在途作業；處理工作程序離線時作業完成的情況。這是分散式系統的基本功，但常因 Sora 是團隊第一個整合的異步 API 而在初期被忽略。
- **Webhook 為首選、輪詢為備援。**若平台支援完成事件的 Webhook（OpenAI API 支援），請使用它。Webhook 去除了輪詢需求，減少速率限制壓力與頻繁查詢造成的算力浪費。輪詢是無法暴露 Webhook 端點環境的備援方案。
- **會花錢的失敗模式。**OpenAI 不對失敗生成計費，但部分完成以及重試後第二次成功的請求會產生費用。在生產中，請記錄每次重試的成本，並在重試率超預期時告警，因為這往往意味著你發送的提示存在內容政策問題——在提示層修正比把費用吞下更便宜。
- **內容政策與生產部署。**Sora 受 OpenAI 使用政策約束，限制某些內容類別。對生產部署（尤其是提示部分由使用者控制的場景），請檢視 OpenAI 官方內容政策文件，並相應地在上游設計防護。以 OpenAI 的政策文件為準；該文件的更新頻率高於本文。
先做什麼
對哪些 Sora 工作負載今天已準備就緒、哪些在邊緣、哪些仍為時過早的務實判斷：
今日可上生產
行銷與創意內容工作負載，迭代可控、以每件最終成品成本為正確指標。產品示範影片、社群活動內容、登陸頁主視覺影片、內部訓練教材。經濟性可行，失敗模式已知，延遲（短片段 30–90 秒）在人在迴圈的內容團隊場景中可以接受。
邊緣地帶
面向使用者的影片生成功能，需要每支成本高於使用者支付價格。可行，但需要謹慎的單位經濟性：限制使用者可請求的時長、預設採用 Sora 2 標準版 720p、定價需高於每支成本以留有利潤。2026 年初一波消費者影片生成 App 多屬此類，能長期經營者都在限制使用者可生成內容上做了刻意設計。
尚嫌過早
長影片規模化（超過 25 秒，Sora 目前的時長上限）、以低牆鐘延遲為優先的高頻即時場景，以及期待幀級控制或基於種子的可重現性之應用。這些應待 Sora 能力面擴張後再評估，而非今日硬套。
**定位：**Sora 2 對於有人在迴圈的內容工作負載，確實已達生產可用；對刻意設計單位經濟性的面向使用者功能，可行；對長影片與需 Sora 尚未暴露之參數的情境，仍為時過早。針對今日成熟的場景構建，追蹤尚未成熟者。
*在你的工作負載上試試看：*CometAPI 上提供所有 Sora 2 與 Sora 2 Pro 變體，與你可能已使用的文字模型並列。免費試用點數可讓你以標準定價生成少量剪輯，唯一所需設定是將現有的與 OpenAI 相容的客戶端指向 CometAPI 端點。