OpenAI Videos API 技术解读

目　录

一、技术发展过程与技术路线　　模型代际与接口形态两条线

二、定义、功能与作用　　五个端点，一条异步链

三、技术架构　　调用层、编排层、生成本层

四、技术原理　　三路输入，一路输出

五、技术发展路线　　片段、编辑、生产三个方向

六、技术应用场景　　先按有没有素材分两类

七、实际市场案例　　一条流水线能跑多快

关于 LinkTokenView　　一个密钥，接入你所有的大模型

附、数据来源与说明　　哪些核实了，哪些没有

  阅读提示：本文的接口规格取自 Microsoft Learn 的 Sora 2 文档（与 OpenAI v1 API 同 schema），端点、参数、默认值、状态机与各类上限均可逐条核对；第七章的吞吐数字是由官方上限直接推导的算术，不是厂商披露的客户数据；模型代际时间线属公开记录，本次未能重取 OpenAI 官网原文，文中已标注。由于未能获得可核实的按秒计费单价，本文不给出任何金额。

  一  技术发展过程与技术路线

讲 OpenAI 的视频能力，容易只讲模型一代比一代强。但对真正要接进系统的人来说，更值得看的是另一条线：接口形态怎么变。模型代际决定画面上限，接口形态决定你能不能把它工程化。这两条线是同时走的。

图 1　两条演进线：模型代际与接口形态

  1.1 模型代际：三次跃迁

按公开记录，Sora 的路线大致分三步：先是研究预览阶段，证明长时长、多分辨率、多宽高比的视频可以由文本条件生成；随后面向消费者产品做了速度优化；再到支持音轨生成、支持对已有视频做定向修改，并以标准接口对外开放。第三步才是 API 使用者真正受益的一步——因为它把「生成」变成了「可编程的生成」。

  这一节的代际划分属公开记录，本次未能重取 OpenAI 官网原文逐条复核（该站点本次访问被 Cloudflare 拦截）。若需对外引用，建议以 OpenAI 官方发布页为准。

  1.2 接口形态：从作业到资源

这条线可以完整互证，因为两份公开文档里同时存在新旧两种 schema。早期的形态是「作业 + 变体」：向生成作业接口提交一个请求，参数里带秒数、变体数量，以及用裁剪边界描述位置的图或视频输入；作业有 queued、preprocessing、running、processing、succeeded 这样一串状态；产物挂在作业下面，要按 generation_id 去取。

新形态则把视频变成了一等资源：创建接口直接返回一个 video 对象，带有自己的 id 与 status；之后可以对这同一个 id 做查询、下载、列举、删除，还可以拿它去做 remix。状态机也收敛成四个：queued、in_progress、completed、failed。

这个变化的价值不在名字，而在语义。作业是一次性的，跑完就结束，你没法对它再做别的事；资源是可以被反复操作的，所以编辑、批量管理、生命周期治理这几件事才有地方落。remix 能成立，前提就是视频已经是一个可寻址的对象。

表 1　接口形态的演进对照

维度	旧形态：作业 / 变体	新形态：视频资源
提交对象	生成作业（video.generation.job）	视频（video）
关键参数	n_seconds、n_variants、inpaint_items	size、seconds、input_reference、remix_video_id
状态机	queued→preprocessing→running→processing→succeeded	queued→in_progress→completed／failed
取产物的方式	按 generation_id 取内容	按 video id 取 content
可否再编辑	不可，需重新提交作业	可以，用原 id 做 remix
可否治理	弱	可列举、可删除、可统计

  二  定义、功能与作用

  2.1 定义

OpenAI Videos API 是 OpenAI v1 API 中面向视频生成的一组 REST 接口。它以视频为一等资源，接受文本、图像或视频作为输入，异步产出一段带音轨的 MP4。当前对应的模型标识是 sora-2，官方仍将其标注为 preview 状态。

用一句话概括它的本质：它不是一个「生成视频的函数」，而是一套「提交、轮询、取回、修改、清理」的资源生命周期接口。把这个理解放到架构设计里，后面的并发、重试、落盘策略自然就清楚了。

  2.2 功能：五个端点

图 2　五个端点与作业状态机

表 2　五个端点的职责分工

动作	端点	做什么	什么时候用
create	POST /videos	提交提示词，返回 video 对象	所有生成流程的起点
retrieve	GET /videos/{id}	查状态与进度百分比	轮询等待时
download	GET /videos/{id}/content	取回 MP4 本体	状态为 completed 之后
list	GET /videos	分页列举视频	历史查询、看板、清理
delete	DELETE /videos/{id}	删除指定视频	存储治理与合规清除

配套的 SDK 方法名与端点一一对应：创建用 videos.create，查状态用 videos.retrieve，等结果可以用封装好的 videos.create_and_poll，取视频用 videos.download_content 并直接写到文件，修改用 videos.remix，列表与删除同样在 videos 资源下。如果你的 SDK 版本里没有 videos 这个属性，先升级客户端即可。

  2.3 作用：它替企业解决了什么

▪ 把视频从「制作」变成「试错」。一段视频从脚本到成片原本要拍摄、剪辑、配音多个环节；现在可以用提示词先产出草案，把「要不要拍」这个决策提前到很便宜的位置。

▪ 把创意评估变成可量化的事。同一个镜头可以一次要多个变体，用很低的边际成本做 A/B。

▪ 把已有素材盘活。有商品图、有概念图的团队，可以把静态素材直接转成动态片段，不需要重新搭景。

▪ 把修改成本降下来。remix 让「改一处」不必「重生一遍」，这是把生成接进生产流程的关键能力。

  三  技术架构

从调用方的视角，这套 API 是三层结构：最上面是你写的调用代码，中间是平台侧的作业编排，最下面是模型与存储。需要你自己实现的只有第一层，但第二层的规则会直接约束第一层怎么写。

图 3　三层架构与贯穿其中的异步链

  3.1 请求参数与默认值

表 3　创建视频的主要参数

参数	必填	默认值与取值范围	说明
prompt	是	—	自然语言描述镜头，建议单一只目的
model	否	sora-2	当前视频生成模型标识
size	否	默认 720×1280	参数表中常用竖屏 720×1280、横屏 1280×720
seconds	否	默认 4；4 / 8 / 12	单次片长；官方限制章节另述支持 1 到 20 秒
input_reference	否	—	单张参考图作首帧视觉锚点，分辨率须与输出一致
remix_video_id	否	—	已完成的视频 id，复用它结构与运动

  3.2 工程上真正会卡住你的四条约束

这些不是建议，是硬限制。做方案时如果不先看这四条，方案大概率要重做。

▪ 并发。同一时刻只能有 2 个视频创建作业在跑，必须等一个结束才能提下一个。这意味着吞吐有物理上限，加预算也提不上去。

▪ 留存。作业创建后 24 小时内可取产物，超时之后只能重新生成。所以下载落盘必须是流水线的必经环节，不能省。

▪ 变体。1080p 不支持多变体；720p 最多 2 个；其他分辨率最多 4 个。

▪ 输入。参考图最多 2 张（生成结果在两者之间插值）；输入视频最长 5 秒。

  3.3 状态机与轮询

期望状态是 queued、in_progress、completed、failed，另有 cancelled。轮询节奏不必太密，官方示例里单次生成通常耗时 1 到 5 分钟，按 20 秒到 30 秒的间隔查一次足够。要注意 failed 不是异常，是正常状态的一种——失败原因需要读响应体里的失败信息，再决定是改提示词重试还是终止。

  四  技术原理

用工程语言描述，这套接口做的事情是：把跨模态的条件输入，转成时空一致的视频序列，并同步合成音轨，最后封装成 MP4 交付。输入端有三条路，输出端只有一条。

图 4　三路输入到一路输出的条件生成过程

  4.1 三路输入

文本提示词是必填项，它决定内容。官方对提示词写作给了很具体的建议：写清镜头类型、主体、动作、场景、光线和想要的运镜，越具体歧义越少；并强调保持单一只目的，一个提示词只做一件事。另外官方建议用英文或其他拉丁字母语言写提示词，生成效果最好——这一条对中文团队是很实际的经验，值得直接写进规范里。

参考图是可选输入，作用是给首帧一个视觉锚点，适合把商品图、概念图直接变成动态片段的开场。这里有个很容易踩的坑：参考图的分辨率必须与输出尺寸完全一致，不是「差不多」而是「逐像素一致」，否则请求会失败。

第三条路是拿已有的生成视频作输入，用于延长或改造，最长 5 秒。它与 remix 的区别要分清：remix 是拿一个已完成的视频 id 做定向修改，而视频输入是把片段当作生成的基础素材。

  4.2 remix 的原理：少改

remix 的机制是保留原片的框架、转场与视觉布局，只落实你指定的改动。所以它的效果好坏，取决于你的改动有多窄。官方明确建议一次只做一处清晰可描述的调整——改得越具体，对原片的保真度越高，出现画面缺陷的概率越低。反过来说，一次提一堆改动，等于让它重新发挥，那就退化成重新生成了。

  4.3 官方明说的能力边界

表 4　官方披露的能力边界与内容政策

维度	官方给出的已知限制
物理	复杂物理表现容易出错
因果	难以正确处理因果关系（官方举例：饼干上的牙印）
空间	空间方位推理弱（官方举例：分不清左右）
时序	精确的基于时间的事件序列，如运镜节奏
内容	仅限适合 18 岁以下观众的内容；受版权保护的角色与音乐会被拒绝
人物	无法生成真人（含公众人物）；含人脸的输入图会被拒绝

  这六条应当直接变成你方案里的「排除项清单」：凡是依赖精确手部交互、因果推理、左右方位或严格运镜节奏的镜头，不要指望模型一次做对，要么拆分，要么补人工。内容政策里的两条（真人、版权角色与音乐）是硬闸门，提示词侧必须做前置校验，否则浪费的是排队时间。

  五  技术发展路线

如果要判断这项能力往哪走，可以看三个方向，它们分别对应「能做一段」「能改一段」「能交付一条」。

图 5　三个发展方向与当前的工程约束

  5.1 从片段到序列

当前单次生成是秒级的片段。真正的视频内容是多镜头、有叙事的序列，所以下一步的难点不是画质，而是一致性：同一个角色、同一套场景、同一种风格，要在多个片段之间保持稳定。这既涉及模型能力，也涉及工程手段——比如用参考图固定视觉锚点，用 remix 在已通过的片段上做延展。

  5.2 从生成到编辑

remix 已经打开了编辑的门：保留结构只改局部。沿着这条路，补全、局部重绘、镜头延展都是自然的下一步。从成本角度看，编辑比重新生成便宜得多，这决定了它会成为生产流程里的主流操作方式，而不是每次都从零生成。

  5.3 从预览到生产

这一条最需要冷静。当前 API 处于 preview，官方明确不建议用于生产关键路径，并说明 preview 模型会按 preview 生命周期升级，行为可能变化。再加上并发 2、留存 24 小时这两条硬约束，现阶段的合理定位是：先做内部工作流与素材预研，等稳定版出来再考虑对外产品化。把 preview 直接架在对外产品的关键链路上，是把模型的生命周期风险转嫁给业务。

  六  技术应用场景

场景分类最有效的一刀，不是按行业切，而是按「你手上有没有素材」切。有素材走参考图或输入视频，工作流偏「改造」；没素材走纯文本，工作流偏「提示词工程」。这两类的团队配置完全不同。

图 6　两类场景与工程上必须提前设计的四件事

表 5　典型应用场景与各自的约束

场景	输入	产出什么	关键约束
电商短视频	商品图 + 提示词	商品动态展示片段	参考图分辨率须与输出严格一致
广告分镜预演	脚本 + 概念图	多个镜头草案，先看节奏	一次多变体，720p 最多 2 个
游戏／影视预可视化	概念图	运动与镜头测试	复杂物理与精确运镜易出错
内容创作 B-roll	纯文本	空镜、转场素材	需在 24 小时内落盘
教育与科普	纯文本 + 示意图	抽象概念可视化	因果与空间关系较弱，需人工复核
社媒素材批量生产	模板化提示词	多版本短素材	并发 2 是吞吐天花板

  七  实际市场案例

公开信息里，这项能力已经以两种形态进入市场：一是消费级产品形态，把视频生成做成普通用户可以上手的产品；二是企业级接口形态，通过主流云平台以 preview 方式开放，按生成时长计费，并提供内容过滤与责任 AI 保护。这两条腿同时走，说明它已经不是实验室演示，而是有商业计费的服务。

下面这个案例不编客户名，也不编合同金额。我用官方公开的四条硬限制，把一条素材流水线的真实产能算出来——这是任何企业接这套 API 时都会撞上的那道墙。

图 7　由官方上限推导的流水线吞吐测算

  7.1 测算过程

算法很直接：并发 2 意味着同时有两个「工位」。若单个作业耗时 2 分钟，每个工位每小时能跑 30 次，两个工位就是每小时 60 个作业，24 小时不停跑是 1,440 个。若单作业耗时 5 分钟，每个工位每小时只有 12 次，两工位每小时 24 个，一天就是 576 个。再乘以单个作业能要的变体数，就是素材条数的上限。

表 6　流水线吞吐测算（由官方并发与耗时推导）

单作业耗时	每小时完成	每日上限	按 4 变体折算
2 分钟	60 个	1,440 个作业	最多 5,760 条素材
3 分钟	40 个	960 个作业	最多 3,840 条素材
5 分钟	24 个	576 个作业	最多 2,304 条素材

  说明：以上完全依据官方公开的「同时 2 个作业」上限与「通常 1 到 5 分钟」耗时估算得出，不涉及任何厂商披露的客户数据，也与具体单价无关。实际耗时随分辨率与时长波动，变体折算仅在 720p 及以下分辨率成立（1080p 不支持多变体）。

  7.2 这个案例真正说明了什么

结论有点反直觉：这条流水线的瓶颈不在钱，在并发。无论你预算多少，同一时刻就是只有 2 个作业能跑。所以「多花钱就能快」在这套 API 上不成立。

▪ 第一条路：错峰。把非紧急的批量生成放到夜间错峰，白天留给需要即时反馈的需求。

▪ 第二条路：拆镜。把一条长片拆成多个短镜头并行提交，用片段数换墙钟时间——这是唯一能真正提高日均产出的手段。

▪ 第三条路：把落盘做成一等公民。既然 24 小时内必须取走，落盘与归档就是流水线的必经工序，要按「一定会超时」来设计重试与告警。

  关于 LinkTokenView

视频只是多模态里的一路。真实业务往往要同时用文本、图像、语音和视频，而每一家的接口、计费方式、限流规则都不一样。LinkTokenView 是 AI 一站式服务平台：一个密钥，接入你所有的大模型。把不同模态、不同厂商的调用与成本放在同一处看，团队不必为了比价和分流在多个后台之间来回切换。

Link tokens, view the future.

www.linktokenview.com

  附  数据来源与说明

[1] Microsoft Learn《Video generation with Sora 2 (preview)》。本文的绝大部分事实来自此页：五个端点及其职责、prompt / model / size / seconds / input_reference / remix_video_id 参数与默认值、状态机（queued / in_progress / completed / failed，另有 cancelled）、SDK 方法名（videos.create、retrieve、create_and_poll、download_content、remix）、支持的分辨率清单、1 到 20 秒的时长范围、变体数量规则、并发 2 个作业、作业 24 小时留存、参考图最多 2 张、输入视频最长 5 秒、内容政策（真人、版权角色与音乐、含人脸输入图）、能力边界（复杂物理、因果、空间方位、时序）、提示词写作建议（单一只目、写清镜头与运镜、建议用拉丁字母语言）、remix 的保留结构语义、preview 状态与按秒计费的计费方式。该页与 OpenAI v1 API 使用同一 schema。

[2] Microsoft Learn《Foundry Models sold by Azure》。用于确认当前视频生成模型的标识为 sora-2，且仍标注为 preview；该页视频模型一节列出的只有 sora-2。

[3] 旧版作业式接口的细节（video.generation.job 对象、n_seconds、n_variants、inpaint_items 与 crop_bounds、queued→preprocessing→running→processing→succeeded 状态串、按 generation_id 取内容）同样见上述《Video generation with Sora 2》页面中的示例代码，本文第一章的新旧对照即由该页内部两套写法互证得出。

[4] 未能核实、因此本文不作断言的部分：

[5] （一）OpenAI 官网的原始文档与发布页本次访问被 Cloudflare 拦截，模型代际（研究预览阶段、消费级产品阶段、Sora 2 阶段）的时间点属公开记录，正文 1.1 节与图 1 均已标注「未逐条复核」，对外引用请以 OpenAI 官方发布页为准。

[6] （二）按秒计费的具体单价本次未能取得可核实的数值，Azure 定价页返回的是页面框架而非价格表。因此本文通篇不给金额数字，第七章的吞吐测算也刻意只用并发与耗时，不涉及单价。

[7] （三）第七章不提供具名客户案例。公开信息中可核实的是这项能力已通过消费级产品与企业级接口两种形态进入市场并以 preview 状态提供、按生成时长计费；但具体企业客户的名称、用量与合同金额均无公开可核实来源，本文不编造。

[8] （四）第七章的吞吐数字是由官方公开上限直接推导的算术结果，不是厂商披露的产能数据；实际耗时随分辨率与时长变化，请以自测为准。

[9] 关于本文的图：全部由脚本按上述事实绘制，数据类图中的每一个数字都能在对应章节的正文或表格中找到出处。