OpenAI 關閉 Sora：影片生成服務退場
2025 年 9 月 30 日釋出的 Sora 2，在一年後走到了終點。2026 年 4 月 26 日，Sora 的網頁版與 App 下線；2026 年 9 月 24 日，Sora API 與 Sora 2 模型正式關停。也就是說，Sora 系列的獨立影片生成業務就此退場，前後大約一年。
先說清楚這東西是什麼。文生影片模型接收文本（有時還有影像）作為條件，輸出一段在時間上連貫的畫面，評價它的通常是幾個維度：畫面質量、可控程度，以及時長更長時角色與場景能不能保持一致。這類模型的推理開銷也是所有模態裡最重的之一——一段幾秒鐘的影片要在時空兩個維度上反覆去噪，算力與視訊記憶體佔用遠高於生成同樣長度的文字。這也決定了它的商業形態：便宜不起來，就很難靠大規模免費使用來鋪開。
時間線：從釋出到關停
整件事其實有預告。2026 年 3 月 24 日，OpenAI 就通知開發者，Videos API 與 Sora 2 的模型別名和快照將被棄用，並從 API 中移除，日期定在 9 月 24 日。公告到關停之間正好半年，中途的 4 月 26 日，面向消費者的網頁版與 App 先行下線。關停清單裡列得很具體：Videos API 本身，以及 sora-2、sora-2-pro、sora-2-2025-10-06、sora-2-2025-12-08、sora-2-pro-2025-10-06 這些別名與快照。值得注意的是同一張表裡的「推薦替代」一欄——它是空的，或者說只畫了一條橫線。
這意味著什麼？在 OpenAI 的棄用文件裡，這次關停沒有給出替代的影片模型。原先通過 API 呼叫 Sora 2 的路徑，自此不再有官方指定的接續方案；還在用它的開發者，需要自己去別處找影片生成的能力，而不是換一個模型名就能繼續跑。
關停機制：公告期是怎麼運作的
這份文件還順帶說明了 OpenAI 處理模型退役的一般規則。除非安全或合規問題要求更快，正式可用的模型至少提前 6 個月通知；專用變體（比如聊天變體、Codex 變體、深度研究變體）至少 3 個月；名字裡帶 preview 的預覽模型則可能只有兩週長通知期，官方因此不建議把預覽模型用於關鍵生產負載。通知方式是郵件加上文件頁面，較大的變動還會有部落格說明。
對照 Sora 的時間線：3 月 24 日發出通知，9 月 24 日執行，正好落在「一般可用模型至少 6 個月」的口徑上。這也解釋了為什麼 4 月 26 日消費端的網頁版與 App 先下線，而 API 側要等到 9 月——兩條線的節奏不同，開發者需要更長的遷移視窗。
對工程團隊來說，6 個月的公告期不是客套。文件裡寫明這段時間的用途：評估推薦的替代模型、測試應用行為、並在模型不可用之前完成遷移。可這次的情況特殊——替代一欄是空的，於是這半年裡真正要做的是找外部方案，而不是升級到自家新品。評估工作量因此更大：提示詞寫法、引數體系、輸出格式、稽核與計費方式，各家都不一樣。
文件裡還有一個面向工程的細節：你可以通過列出模型介面（GET /v1/models）讀取每個模型可選的 shutdown_date 欄位，提前知道某個型號會不會被關停。欄位是 YYYY-MM-DD 格式的日期字串，也可能是 null（表示尚未公佈關停日期）。對把模型寫死在配置裡的團隊來說，把這個欄位接進監控，比等到郵件通知再動手要從容得多。此外，官方提到某些情況下可以通過銷售團隊申請專用容量，在關停日期之後繼續訪問。
順帶說一句，同一份文件裡還排著一批同期進行的棄用：比如 GPT Image 的舊型號在 2026 年 12 月 1 日關停，GPT-4 系列部分型號定在 2027 年 1 月 14 日，語音合成與轉錄模型分別排在 2027 年 1 月 6 日與 2 月 26 日。這提醒我們，Sora 的關停不是一次孤立事件，而是一套持續運轉的退役流程中的一條；模型更替的速度，本身已經成了平臺使用成本的一部分。
賽道的另一邊
Veo 3.1 的覆蓋面本身也說明了一件事：影片生成正在從「一個獨立產品」變成「嵌在各類產品裡的功能」。它同時出現在對話助手、影視工具、短影片平臺、辦公套件與雲平臺上，使用者不一定知道自己在用哪個模型，但會持續地用上這項能力。對這種分發方式來說，模型的可替換性反而是設計前提——換一個更強的版本，使用者側不應該有任何感知。同一賽道的另一邊，Google 的 Veo 3.1 仍在擴張。2026 年 1 月 13 日的更新為它加入了原生音訊、9:16 豎屏、增強的圖生影片能力，以及 1080p 與 4K 放大；覆蓋面包括 Gemini、Flow、YouTube Shorts、Google Vids、Vertex AI 與 Gemini API。規格上，它支援 4、6、8 秒的片段、影片續接、首尾幀條件，以及最多 3 張參考圖。
兩件事放進同一張圖裡就是：一家把消費級影片生成的產品與介面一併收掉，另一家還在往更多入口鋪。這裡只陳述事實——把落點放在各家自己的產品決策上，比去猜背後的原因更穩妥；服務下線、替代為空、競爭對手仍在更新，這三條都是可核對的公開資訊。
還有一點容易被低估：影片生成介面之間並不互通。別的廠商有類似的介面，也不代表把模型名換掉就行——輸入條件的形式、時長與解析度的檔位、返回結果的取回方式都可能不一樣，鏈路上任何一環假設了「和我原來用的一樣」，遷移時就會暴露出來。真正省時間的做法，是在公告期內先用小流量搭一條旁路，把差異提前測出來。
從產品的角度看，這類能力的商業形態本來就有兩種：一是面向普通使用者的編輯器式產品，二是面向開發者的介面。前者的成敗取決於使用者規模與留存，後者取決於呼叫量與單位成本，而影片生成恰恰是算力開銷最重的模態之一。兩者是否長期維持，往往不會同步——Sora 這一年的路徑就演示了這種不同步：先用消費端開啟局面，再由 API 側收尾。
對做產品的人來說，這件事的可操作結論其實很樸素：把「模型可能消失」當成常態來設計。不要預設某個介面會一直存在，給關鍵鏈路留一條可切換的替代路徑；把棄用公告、shutdown_date 欄位這類訊號接進監控；如果產品強依賴影片生成，那麼在選擇供應商時，把「有沒有替代型號」和「公告期有多長」當作和價格、質量同等重要的評估項。剩下的，交給不斷的迭代就好。