视频生成接口进中转：三种形态、四个计量陷阱，以及一份验收清单

为什么视频是最不整齐的一类

文本接口有事实标准 POST /v1/chat/completions，图片接口有 POST /v1/images/generations。视频没有。

到今天为止，视频生成没有形成统一协议：每家厂商一套提交方式、一套任务状态机、一套结果获取路径。中转站夹在中间，只能一家一家透传，于是同一个站点上，不同视频模型的调用方式可能完全不同。

这一条直接决定了三件事：你的代码没法写一套通用封装、计费没法用统一倍率、失败重试没法用统一策略。

三种接口形态

形态一：OpenAI 风格异步任务

提交返回任务对象，再按 id 轮询：

# 提交
curl -s https://<base_url>/v1/videos \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{"model":"<video-model>","prompt":"a cat walking on a beach","seconds":"8","size":"1280x720"}'

# 轮询
curl -s https://<base_url>/v1/videos/<video_id> -H "Authorization: Bearer $KEY"

判据：提交响应里必须有 id 和 status；轮询到 status 变成 completed 之后，响应里才会出现可下载的地址。

形态二：提交、轮询、取结果

国内厂商更常见：任务 id 叫 task_id，状态接口是单独的路径，结果 URL 有效期有限。

curl -s https://<base_url>/v1/video/generations \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{"model":"<model>","prompt":"...","duration":5}'
# => {"task_id":"..."}

curl -s https://<base_url>/v1/video/generations/<task_id> -H "Authorization: Bearer $KEY"
# => {"status":"succeed","data":{"url":"https://.../xxx.mp4"}}

形态三：同步返回（少见）

提交即返回 URL，或直接返回 base64。只适合极短、极低分辨率的场景，因为 HTTP 连接要挂几十秒，任何一层代理超时都会把连接掐断。

三种形态对照：

如果你的客户端或网关不擅长长连接，一律走形态一或形态二，不要碰形态三。

四个计量陷阱

陷阱一：按秒、按次、按 token，三种口径混在同一个站里

同一个站点上，模型 A 按「生成秒数 × 单价」计费，模型 B 按「每次调用固定价」计费，模型 C 按输入 token 加输出视频 token 计费。你在后台看到的「消耗」是一个混算后的数字，无法反推单价。

做法：给每个视频模型单独做一次「最小请求」记录 —— 同样的 prompt、最短时长、最低分辨率，记下扣费金额。这就是你的基准单价，后面所有异常都以它为参照。

陷阱二：分辨率和时长会改变单价，而倍率表只对文本定义

中转站的「倍率」通常按文本 token 定义。视频的 720p 与 1080p、5 秒与 10 秒，单价可能差 2~3 倍，而倍率表上只写一个数。

判据：同一 prompt 分别用 720p/5 秒和 1080p/10 秒各跑一次，比较扣费。如果倍数关系与厂商官方价目表不一致，说明中转站自己加了档位系数 —— 这时它欠你一份说明。

陷阱三：失败也扣费

生成失败（内容审核拒绝、上游超时、任务卡在 processing）之后扣费是否退回，各家不一致，而这一条几乎从不写在价目表上。

做法：故意提交一个必然被拒的 prompt，然后看扣费记录。这一条比读十页条款有效。

陷阱四：结果 URL 会过期

返回的 url 通常是对象存储的预签名地址，有效期从几分钟到 24 小时不等。过期之后，你既取不回这个视频，中转站通常也不提供「重新签发」接口。

唯一正确的做法是拿到 URL 后立刻下载落地，不要把它存进数据库当永久链接。

六步验收清单

第 4 步是最容易省掉、也最容易暴露问题的一步。请求 10 秒、实际只给 5 秒这种事在中转站上真实发生过 —— 上游按档位取整，网关没有校验。

ffprobe -v error -select_streams v:0 \
  -show_entries stream=width,height,duration \
  -of csv=s=x:p=0 out.mp4
# 期望输出形如 1280x720x8.000000

什么时候值得走中转

视频生成走中转，只在两种情况下划算：

1. 你需要多家视频模型做对比，又不想为每家单独开户、单独充值；
2. 你的业务在国内，而厂商只接受境外支付，中转是唯一现实的结算方式。

反过来说，如果你用量稳定、只用一个模型，直接对接厂商更便宜也更好排查 —— 视频这类接口的中间层并没有带来协议统一的好处，只多了一个可能出错的环节。

小结

1. 视频没有统一协议，三种形态决定了你的代码怎么写；
2. 单价必须自己测，按秒、按次、按 token 三种口径不能混算；
3. 分辨率与时长会改变单价，而倍率表通常不覆盖；
4. 失败是否退费，用一个必然失败的请求去测；
5. 结果 URL 会过期，拿到就落地；
6. 一次成功生成不等于验收通过，要用 ffprobe 量出来的参数说话。