AI 视频生成 API：作业、模型和成本

您的聊天补全在 400 毫秒内返回，所以您也以同样的方式传输视频：一个 POST 请求，等待，然后收集字节。四分钟后，连接超时，视频片段仍然完成，但您却为一项无人领取的任务付了费。

这个差距正是大多数 AI 视频生成 API 项目出错的地方。文档让视频看起来像一个较慢的聊天模型，而定价表则引导您比较每秒多少美分，仿佛一秒钟生成的素材是您总能保留的单位。市场扩张得足够快，以至于这个错误的影响也随之扩大。Research and Markets 估计全球 AI 视频生成器和编辑器市场在 2024 年价值 623 百万美元，并预计到 2034 年将达到 3.51 十亿美元，复合年增长率为 18.64% (Research and Markets, 12 月 2024)。

真正有用的问题不是哪个 API 每秒最便宜。而是经过失败、重试以及需要四次尝试的模型之后，一个可用、已下载、已存档的视频片段到底要花多少钱。

目录

• 视频生成能力和请求类型
• 视频任务如何从提交到文件
  • 健康的任务日志是什么样的
• 轮询或 Webhook 获取完成的视频结果
• 按用例选择视频模型
• 每可用片段成本与广告价格
  • 价格表中遗漏了什么
• 要检查的请求字段和输出元数据
  • 每个完成任务要存储的输出字段
• 将视频生成集成到现有 SDK 代码中
  • 精简视频服务的四个部分
• 生产故障以及如何防止重复
  • 为什么自动故障转移会让你花钱
• 在提交之前运行模型基准测试

视频生成能力和请求类型

聊天回复是一条消息。视频任务是一个稍后送达的文件，你选择的请求类型决定了提供商需要生成什么以及返回什么。

文本到视频是最纯粹的形式。你发送一个提示词和一个模型标识符，模型会根据描述生成每一个像素。图像到视频则添加了一个参考图像，因此主体、构图和光照来自图像，而提示词提供运动。这一单一的改变消除了大部分的身份漂移，而正是这种漂移使得纯文本生成的片段无法用于产品拍摄和角色创作。

视频超分是内容固定而只改变分辨率的一种类型，因此它最容易估算成本，也最不容易出错。音频分为两部分。当你开启音频时，有些模型会随画面返回音轨，而音乐和音效则是独立的模态，使用相同的请求结构和任务机制。

每行都包含三个输入：提示词或源媒体、模型标识符，以及你想要的长度和分辨率。尽早将这三项纳入你自己的请求 schema 中，这样以后更换提供商就只是一项配置更改。

在构建任何东西之前，请设定好时间预期。聊天回复在几秒内送达，而视频请求是先被接受，稍后完成，典型运行时间约为30秒到几分钟。你立即收到的响应是一个任务，而不是一个片段。

视频任务如何从提交到文件生成

每个生产就绪的视频 API 都遵循一个模式，这个模式在 OpenAI 的 视频 API 指南中有所阐述：即：创建任务，读取其状态，然后一旦状态达到最终成功状态，就获取内容。将此流程建模为异步任务系统，绝不能作为同步媒体下载。

1. 提交请求。 发送提示、模型标识符、时长和分辨率。响应会包含一个任务 ID 和一个初始状态（例如“已排队”）。在进行任何其他操作之前将其存储起来，否则进程重启将丢失您已付费工作的唯一句柄。
2. 将任务 ID 映射到您自己的记录。 保留您的内部请求 ID、所属用户或租户、您发送的参数以及卖家或提供商路由。当三天后出现账单问题时，这一行就是答案。
3. 监控状态资源。 轮询它或等待事件，并用时间戳记录每次状态转换。已排队、运行中、已成功、已失败。“已排队”和“运行中”之间的间隔是队列等待时间，正是这个数字解释了与模型本身无关的“模型慢”投诉。
4. 等待最终状态。 成功和失败都是最终状态。超时不是，连接断开也不是，所以绝不要将它们视为结果。
5. 仅在成功时获取文件。 请求内容位置，将其流式传输到您自己的存储中，并记录校验和。在失败时执行此操作会浪费调用，并可能将真实错误掩盖为下载问题。
6. 在失败时读取错误。 决定修复方法是更改参数、使用不同的模型，还是向用户发送消息。在内容被拒绝后重新提交相同的参数只会浪费金钱。

健康的任务日志是什么样的

一个任务 ID，一次从“已排队”到“运行中”再到“已成功”的干净运行，以及恰好一次下载。日志中任何其他情况都是可衡量的错误：两次下载意味着您没有去重的重复 webhook，而客户端放弃后记录的成功则意味着您需要进行对账。

在您自己的任务记录中定义取消、超时、重试和过期。这些语义属于您的网关，而不是渲染视频片段的任何上游服务。如果调用者在渲染过程中断开连接，让任务完成并在稍后进行对账。取消是您发送的明确状态更改，而不是意外关闭的 HTTP 连接。

轮询或 Webhook 以获取完成的视频结果

这两种信号都回答了同一个问题，它们的不同之处在于谁来“追逐”信息。轮询意味着您的代码会重复读取状态资源，直到任务达到最终状态。Webhook 意味着提供方会通过完成或失败事件调用您，然后您的端点做出响应。

对于以分钟计的生成任务，事件在成本和延迟方面都更胜一筹。每隔几秒轮询每个任务所产生的请求量会在队列中累积，并且相同的流量会延迟您的检测，直到下一个间隔。Webhook 与直接 API 轮询的比较 阐明了每种模式的适用场景。

按照以下顺序构建处理程序，进行五项检查：

1. 验证签名 当提供方提供签名时，并在边缘拒绝未签名的交付。
2. 将事件持久化到提供方任务 ID 在任何下载、计费或通知工作运行之前。
3. 假设至少一次交付，因为同一个完成事件可能合法地到达两次。
4. 使处理程序幂等，这样第二次交付会看到已存储的最终状态，并跳过下载和费用。
5. 将失败事件视为真实结果，而不是作为超时盲目重试。

然后添加安全网。如果在根据您测量的延迟设定的截止日期前没有事件到达，则使用退避策略轮询任务 ID，从大约 15 秒 开始，并逐渐延长到 60 秒。在上线前测试两种故障路径：强制发送一个重复事件，然后完全抑制一个事件，并确认用户最终只获得一个视频和一次收费。

实用规则： Webhook 是针对“快乐路径”（即正常情况）的优化。您的协调轮询才是使系统正确的关键。

按用例选择视频模型

在查看排行榜之前，先根据五个标准筛选候选模型：所需的模态、最大时长和分辨率、音频支持、实测生成时间以及提供商的计费单位。这五个标准比任何质量排名都能更快地淘汰大部分模型。

计费单位和数字本身一样重要。按秒计费的价格适用于可变长度的片段，但会惩罚长片段；而按任务计费的价格使固定长度的片段成本可预测，更长的片段则免费。在相同的时长和分辨率下比较两个模型，否则比较毫无意义。

生成时间决定了您是否能将模型直接展示给用户。在 2026年10月29日 上进行的测试中，一个 5 秒的 Kling 3.0 片段大约需要 80 秒，这对于短片段来说是可观的，但无法在没有进度状态的加载动画后面隐藏。一个 5 秒的片段如果需要 80 秒才能完成，则需要显示可见状态、预估等待时间以及离开页面后返回的方式。

按以下顺序将模型范围缩小到两三个：首先是模态，然后是分辨率和音频，最后是您可以接受的速度和计费单位。即使选择了默认模型，也要在候选列表中保留至少一个备用模型。一个符合您视觉风格的模型可能仍然对您的界面来说太慢，当这种情况发生时，您会希望备用模型已经过基准测试。通过一个 endpoint 可用的 AI 模型完整列表] 是开始筛选的合理起点，而不是开设九个供应商账户。

可用片段成本与广告价格对比

每秒广告费率告诉您一次尝试的成本。它没有说明一个可用片段的成本，而这才是您的财务团队关心的数字。

让我们用一个具体案例来算一算。以每秒 $0.10 的价格，一个 5 秒的片段每次尝试成本为 $0.50。如果四次尝试中只有一次达到您的质量标准，那么被接受的片段成本为 $2.00。一个竞争对手以每秒 $0.07 的价格，每次尝试成本为 $0.35，如果两次尝试中只有一次可用，那么被接受的片段成本为 $0.70。看起来更便宜的模型实际上胜出近三倍，而每秒价格表显示的排名却恰恰相反。

价格表中遗漏了什么

根据 Runway 的 AI 视频 API 定价比较，已公布的费率大致介于每生成秒 $0.02 到 $1 之间，并且这个范围是在决定实际预算的成本之前测量的。同份分析指出，一个看起来更便宜的模型，如果需要四次尝试而不是一次，最终可能会更昂贵。将这些因素添加到您的模型中：

• 失败和被审核的任务。 一次拒绝会消耗一个请求，并且不返回任何您可用的内容，因此它应该计入您成功率的分母中，而不是排除在外。
• 您选择的重试。 每一次重新提交都是另一次尝试成本，这就是为什么尝试次数应该包含在公式中，而不是单独注明。
• 影响费率的设置。 分辨率和音频会改变每秒的价格，因此，在默认设置下运行的基准测试所报的价格，您可能永远不会支付。
• 您未设置的默认时长。 当您想要 5 秒时，提供商默认 8 秒，会使每个片段的成本增加 60%。
• 存储和重新托管。 结果链接是临时的。将文件复制到您自己的存储桶是接受片段成本的一部分。

计费规则也影响着计算。视频一旦生成完成，就会按最终价格计费，并且对请求的回复会说明视频开始前该任务的最高成本，这让您可以为每个任务和每个租户设置预算上限。这两条规则将模糊的每月估算转化为您可以在代码中强制执行的每个请求的上限。

严格定义“接受”。报告成功的任务不等于可用片段。只有当它通过提示一致性、保持时间连贯性、保持主体身份且没有明显的运动或物理错误时，才将其计入。有关每秒费率和每任务费率在不同路线之间如何比较的更详细分析，请参阅 AI 定价模型如何运作的指南，其中涵盖了计费单位。

“成功”状态意味着渲染完成。这不意味着该片段值得发布，并且只有后者才计入分子。

要检查的请求字段和输出元数据

视频请求不仅仅包含一个提示。每个字段都决定了路由选择、价格变动，或者能否在以后重现一个好的结果。请发送以下七个字段：

1. 模型标识符，用于选择提供商路由。标识符具有结构，因此 fal-ai/kling-video/v3/standard/text-to-video 将提供商、系列、版本、层级和模态编码在一个字符串中。请将其保存在配置中，切勿在请求逻辑中硬编码。
2. 提示，对于图像转视频，还需要参考图像或其上传位置。
3. 时长（秒），因为价格和生成时间都与它成比例。
4. 分辨率和宽高比，因为两者都会影响每秒费率。
5. 音频设置，如果模型支持音频。
6. 随机种子，如果模型接受，以便重现好的结果。
7. 您自己的请求 ID，以便提供商的任务可以映射回您的记录。

每个已完成任务要存储的输出字段

容器格式、视频编解码器、尺寸、帧率、时长、音频存在与编解码器、可用比特率、文件大小，以及持久的内容 URL 或对象标识符。请将元数据与文件一起存储，因为仅凭文件本身无法在下个季度告诉您是哪些设置生成了它。

请记录这些元数据，而不是假设每个结果都是等效的。两个时长相同的片段可能以不同的编解码器、不同的比特率，带或不带音轨的形式返回。W3C WebCodecs 规范 定义了用于编码和解码音频和视频的接口，但没有强制要求编解码器或编码方法，因此无法保证两次渲染会以相同的格式返回。

为浏览器和应用程序提供一个保守的 MP4 配置文件，并在质量对后续编辑很重要时保留提供商原生的文件。然后，在成功之前进行验证。根据请求检查解码后的时长和帧数，因为即使 API 报告成功，长度错误的文件也是失败。一个 4 秒的片段，而您要求的是 5 秒，这与失败的任务一样严重地破坏了时间线，而且更难被注意到。

将视频生成集成到现有 SDK 代码中

现有的文本集成无需重写即可适应。将文本和视频保持在不同的路由上，这样它们就可以共享一个 API key、一个 base URL 和一个余额，并保留 SDK 封装器。迁移兼容 OpenAI 或 Anthropic 的客户端只需更改 endpoint 和凭据，而切换模型只需更改标识符。

轻量级视频服务的四个部分

一个创建函数 验证输入，调用生成路由，并立即返回您自己的内部作业 ID。您的调用者永远不会看到提供商 ID，这使得后续的故障转移对他们来说是不可见的。

一个作业表 将内部 ID 映射到提供商作业 ID、状态、路由、时间戳和输出元数据。将其视为账单核对的唯一真实来源，而不是提供商的仪表板。

一个工作器 轮询或接收 webhook，推进状态机，并应用您定义的重试和截止日期规则。一个工作器处理这两种信号，因此错过的事件和缓慢的轮询会汇聚到相同的代码路径。

一个存储步骤 将完成的 MP4 复制到您自己的存储桶中，计算校验和并写入元数据行。这是团队经常跳过，然后在第一个链接过期后才重建的步骤。

将每个 API key 限制在一个环境中，并保持密钥可撤销，这样泄露的 staging key 就无法访问生产容量。对于大型源图像或视频文件，请通过签名的 URL 上传，而不是将字节嵌入请求正文中，因为多兆字节的 JSON payload 本身就是一种故障模式。

然后运行高级工程师会询问的测试。发送一个在客户端超时请求，并确认系统最终只有一个存储任务、一个最终下载且没有重复提交。如果该测试通过，其余的集成都是细节。

生产故障以及如何防止重复

生成 API 不是函数调用，将其视为函数调用是产生重复的原因。对于同步文本 API，超时几乎总是意味着工作从未发生。对于视频，超时仅意味着你停止了监听。作业可能仍在排队、仍在运行，并且在完成的那一刻仍将以最终价格向你收费。下图展示了该理念的实际操作版本：一个自我修复的管道，由专人负责，而不是一个无人看管的队列。

大多数视频集成错误都归结为七种症状，每种症状都对应一个原因和一个修复方案。

为什么自动故障转移会让你花钱

故障转移是文本领域的一个习惯，但不能很好地应用于视频。在聊天 endpoint 上，重试超时请求成本低廉，并且无论如何答案都是相同的。在视频 endpoint 上，每次重新提交都是一个新的可计费作业，按每秒输出定价，并且重新路由到不同的模型可能会改变运动、身份一致性、安全结果或片段时长。关于最佳 AI 视频生成 API]的比较报告指出，并发限制、速率限制、队列行为和慢速异常值是不同提供商之间的主要差异，而平均延迟恰好隐藏了那些会破坏交互式产品的尾部延迟。

因此，将重试和故障转移视为成本和一致性风险，而不是免费的安全网。每次重复提交都会增加每个接受片段的成本，而不会提高接受率。对于任何必须匹配的片段系列，请固定模型，并且只允许在您已在自己的 prompt 上测试为等效的模型之间进行故障转移。将审核拒绝视为结果而非瞬时错误：读取代码，更改 prompt，不要自动重新发送相同的输入。

经验丰富的团队会遇到的故障模式更为微妙：在你的客户端请求已经超时后，作业仍可能成功。如果你重新提交而不是协调存储的作业，你将为同一个片段支付两次费用。结果链接也是临时的，可能会过期，因此请立即下载完成的文件，使用 checksum 存储它，并写入归档行。这一步是控制措施，而非日常维护。UberLLM 在视频或音乐作业完成后会保留结果文件约 3 小时，这对于重试循环来说足够长，但远不足以替代你自己的存储桶。

精确一次计费由多个部分组成，每个部分本身都很小：每个用户请求的幂等键、持久的任务状态、经过验证的 webhook、截止日期后的协调轮询、已完成媒体的 checksum，以及每个完成文件的不可变归档。跳过其中任何一个，某个边缘情况最终会找到漏洞。

第一天规则： 每个视频作业都必须有一个存储状态，你可以协调它而无需收费或重新提交工作。如果你无法从自己的数据库中回答“这个作业花费了多少钱，我们是否交付了它”，那么集成就没有完成。

在您承诺之前运行模型基准测试

您可以通过一个下午就能完成的测试来确定模型选择。选择一个默认模型和一个具有不同成本单位或速度配置的挑战者模型。Kling 3.0 Standard 是文本到视频和图像到视频的实用首选默认模型，而 Veo 3.1 Fast 则是一个有用的成本挑战者。然后：

1. 重用您成本模型中的固定提示、时长、分辨率、音频设置和接受规则。只有相同的输入才能使比较有意义。
2. 每个模型至少运行 10 个任务，足以看到故障率，而不是侥幸成功。
3. 只带回四个数字：成功率、中位延迟、尾部延迟和每个接受剪辑的成本。
4. 检查您将调用的路由上的费率。对于 1080p 无声的相同文本到视频配置文件，Veo 3.1 Fast 在 UberLLM 上每秒成本为 $0.075，而在 fal.ai 上每秒成本为 $0.10，这种大小的差距会改变哪个模型获胜。
5. 保持管道独立：视频请求发送到 /v1/video/generations，聊天请求保留在 /v1/chat/completions，即使一个 API key 和一个 base URL 同时覆盖两者。

更换候选模型只是模型标识符的更改，因此基准测试只会花费您的提示和时间，而不是迁移成本。选择每个接受剪辑成本最低且仍满足您的延迟和质量标准的路由，将其固定用于任何必须匹配的系列，并随着价格和队列条件的变化，每月重新运行相同的 10 个任务集。

---

UberLLM 通过一个与 OpenAI 和 Anthropic 兼容的 endpoint，将视频生成请求路由到不同的提供商，因此您只需提交一次任务，即可让网关处理卖家、任务 ID 和回调契约。文本到视频、图像到视频和超分辨率模型与您的聊天模型共享相同的 key 和预付余额，并且失败的生成不会收费。将您的下一个视频基准测试指向 UberLLM，并比较每个接受剪辑的成本，而不是每秒的成本。