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 字段这类信号接进监控；如果产品强依赖视频生成，那么在选择供应商时，把「有没有替代型号」和「公告期有多长」当作和价格、质量同等重要的评估项。剩下的，交给不断的迭代就好。