AI 视频生成到底多久失败一次？498 次真实运行里的供应商故障与审核拒绝

数据窗口：2026-05-06 至 2026-08-22 · 最后更新：2026-08-23

结论先说

2026 年 5 月 6 日到 8 月 22 日之间，在一个多模型平台上跑的 498 次视频生成里， 6 个模型中有 4 个的供应商侧失败很罕见，落在 0% 到 1.4% 之间。有两条供应链路差得多： 一条 36.2%，另一条在本表之外的图像模型路由上是 17.0%（53 次里 9 次）。内容审核 拒绝率按模型从 0% 到 26.0% 不等，而 47 次拒绝里有 31 次点名了参考图里的真人脸。 下面每一个比率都带 95% 置信区间，每一次失败的分类规则也全文公开。

两种不同的失败

让人回去重跑一个镜头的事件有三种，其中只有两种会在日志里留下可以计数的痕迹：

1. 生成坏了。超时、供应商报错、队列失败。什么都没回来。
2. 内容审核拒了。模型正常工作，是它的内容策略拒绝了这次请求。
3. 跑完了，但不是想要的。技术上算成功，记录跟一条留用的片子一模一样。

这篇文章量的是前两种。第三种不在范围内，也没法从日志里量： 被丢掉的生成和被留下的生成，记录上没有任何区别。关于「一个能用的镜头要试几次」， 公开的估计是有的，但它们要么是举例性质的假设，要么是单部片子的个案，都不是受控测量， 所以这里不给第三类推算任何占比。

两者成因不同：坏掉来自供应链路，而拒绝来自内容策略碰上了被提交的东西。

数据

窗口内有 6 个视频模型的有效运行超过 30 次。图像模型完全排除在外；把它们混进来， 就成了拿别的东西的数据去回答一个关于视频的问题。 另一篇早前的文章覆盖了图像模型，用的是同一份日志上范围更宽、但边界划得没这么细的一刀。

字节跳动并没有发布过所谓的 "Pro" 档；那个叫法是经销商给标准版 Seedance 2.0 端点起的，上面那一行量的就是它。

括号里是 95% Wilson 置信区间。从中能读出两件只看点估计支撑不住的事。

每一次失败是怎么分类的

数据来源：平台的生成日志，筛出 2026-05-06 到 2026-08-22（含两端）之间创建的视频类记录。 每一行只归入一个类别，按下面的顺序匹配：

ok       : status = 'completed'

refused  : error_message ~* '(may contain real person|inappropriate
           content|celebrity|involving minors|copyright restrict|
           watermark|AUDIO_FILTERED|content security audit)'

ourside  : error_message ~* '(Insufficient corporate funds|balance is
           insufficient|validation failed|only supports|Invalid
           parameters|Parameter validation|input.prompt: size|Error
           validating image|style reference must be|iw )'

broke    : every other failed row

ourside 这一类被从分母里拿掉了，因为这些失败量的是 我们的接入而不是模型：上游的账户层问题，以及被我们自己的代码写坏的请求。 被剔除的条数按模型列在上面的表里，让这次校正在总数里始终可见。 Seedance 2.0 Mini 就是它为什么重要的例子：82 次原始失败里剔了 32 次； 不校正读作 39% 的失败率，校正后是 50 次有效运行上的 0%。

输出侧的音频过滤（AUDIO_FILTERED、content security audit）归在 refused 下，因为用户体验到的和任何其他策略拦截没有区别。 它们占 47 次拒绝里的 15 次。

有一处边界判断会直接改变一个头条数字：像 Operation failed. Please retry. 和 An error occurred. 这样的泛化上游消息不带任何归因。它们被计入 broke，而不是剔除。按这条规则 Grok Imagine 读作 36.2%， 如果把这些消息另置一边则是 16.1%。我们报高的那个数，因为当被测量的对象是供应商时， 把一次无法解释的失败算在供应商头上而不是算在自己头上，才是保守的选择。

什么会触发拒绝

这个窗口内所有视频模型合计有 47 次生成被拒：42 次落在表内这 6 个模型上， 另外 5 次落在没到 30 次门槛的模型上。按供应商返回的消息分组：

• 31 次 · 参考图里有真人。返回的是 "The request failed because the input image may contain real person."
• 11 次 · 版权或音频权利。对生成音频或被引用音频做的内容安全审查。
• 4 次 · 音频被过滤，发生在原生会出声的模型上。
• 1 次 · 露骨或性暗示内容。

全部拒绝的三分之二出自同一个原因。过滤器读的是参考图，不是提示词——这就是为什么 改措辞很少管用，而把真人照片换成生成的角色通常管用。

日志不记录某次运行有没有带参考图，所以表里没有一列能说明每个比率背后的输入构成。 有一个测量可以顶上：这个窗口内 145 次 Grok Imagine 运行没有任何一次带图片参数或 绑定角色，所以它 0% 的拒绝率反映的是纯文字的使用方式，而不是一个宽松的过滤器。 31 次真人相关的拒绝全部落在 Seedance 家族，其中 20 次在 Seedance 2.0、 11 次在 Seedance 2.0 Fast。

两个异常值来自我们的路由

Grok Imagine 那 36.2% 量的是供应链路，不是模型。这个平台上的每一次生成都要经过 这样一条链路，而供应商侧失败量的正是这条链路：超时、上游报错、中间商的容量问题。 换一个平台、换一种路由方式跑同一个模型，会得到不一样的数字。

这份数据里第二条高失败率的链路（表外的一个图像模型）也是同理。这两个数字正是促使 我们去复核那两条路由的原因。它们属于基础设施那一节，不该被当成关于模型质量的证据。

拒绝率的可迁移性更强，但有一个前提。像这 31 次一样、带着模型供应商自己的错误串，这类拒绝反映的是那家供应商的策略， 在通往同一端点的其他路由上应该会重现。中间商可以再叠加 自己更严的过滤：比如 RunningHub 就在平台层强制了不分模型的真人拦截。 把这些比率当成下限来看。

这份数据说明不了什么

• 它量的是拒绝和坏掉，不是质量。一次跑完了但看着不对的生成， 在这里算成功，而这一类很可能才是实践中重跑的最大来源。
• 样本量小且不齐。够门槛的有 6 个模型；148 次运行和 35 次 不是同一个证据分量，这正是每一格都带区间的原因。
• 拒绝率反映的是我们的用户提交了什么。换一批用素材不同的用户， 同样这些模型会跑出不一样的比率。
• 拒绝率被输入构成混淆了。表里没有显示每个模型有多少次运行带了 真人参考图。如果某个模型收到的照片上传比另一个多，它就会继承更多拒绝， 与策略严不严无关。
• 窗口期内供应链路变过。供应商侧失败率是一个时刻的测量值， 而上面那两个高值，恰恰就是触发了变更的那两个。
• 内容过滤器随时会动，且不打招呼。模型供应商持续调整阈值， 很少公告，所以拒绝率会漂。