PixVerse API 的「限流」不是速率限制。官方那一页限制的是同一时刻能有多少条任务在生成,搜索结果里那个每秒请求数属于某家转售商的网关。下面所有内容来自那一页、错误码表,以及负责解释处置办法的排查页。
官方限流页到底公布了什么
那一页只有一句话开场,而这句话没提速度。
Different concurrent requests are provided based on membership level.
下面是一张两列表,表头是 Membership Type 和 Concurrent Requests;再下面一条脚注给这个词下了定义:Concurrent Requests: Maximum number of simultaneously generating tasks。想要更多,页面写的是 upgrade/purchase membership,或者写信到 api@pixverse.ai。
一张表,一条脚注
没有速率这件事可以自己验,不必听我们的。
# Ask the vendor page itself whether any per-second wording exists.
curl -s 'https://docs.platform.pixverse.ai/rate-limit-796040m0' \
| grep -o -i -E 'per (second|minute)|rps|rpm|requests per' | sort -u
# prints nothing: the page constrains simultaneous tasks, not a rate
表格和脚注都回来了,每秒请求数、每分钟请求数、每日上限一个都没有。在有人拿这个网址给速率背书之前,「PixVerse 每秒允许 N 个请求」说的都是另一家服务。
索引摘要比正文承诺得更多
官方文档站还有一份给机器读的索引,它把这页描述成覆盖 Per-account request and concurrency limits。点进去的那一页只公布了并发。以正文页为准,因为数字长在它身上;那句索引说明的是为什么二手文章总在承诺一个没有数字的请求限制。
并发与每秒请求数

两者各自限的是什么
速率限制数的是到达次数,并发上限数的是占用。在每秒限制下,一条任务只算在它到达的那一秒,之后不再有影响。在 PixVerse 这套模型里,账号在整个渲染期间都占着一个名额,任务离开 generating 才还回来。
为什么占位的是任务
长时间渲染按墙钟时长吃掉容量,所以一批 15 秒片段和一批 5 秒片段对同一个上限的压力完全不同。卡住的任务也一直占着名额,因为文档里没有任何地方能提前放掉它。
| 每秒请求数 | 同时生成中的任务 | |
|---|---|---|
| 数的是什么 | 窗口内的到达次数 | generating 状态的任务 |
| 突发流量会怎样 | 一部分被拒 | 先收下,到上限后再拒 |
| 长任务的成本 | 不多占任何东西 | 整段运行时间占一个名额 |
| 官方是否公布 | 没有 | 有,按会员档 |
档位与错误 500044
公布的档位
| 会员档 | Free | Essential | Scale | Business |
|---|---|---|---|---|
| Concurrent Requests | 3 | 15 | 20 | 25 |
免费档允许三条同时生成的任务。这是在说重叠度,不是总量:它没说一个账号一天能生成多少条,官方也没有公布日上限。买积分包同样不改这个数字,因为上限跟着会员档走。
卡住的占位怎么释放
排查页用一句话点出成因:账号已经 exceeded the number of videos allowed to be in "generating" status according to your current plan。接着给了别的页面都没写的细节:任务长时间停在 generating 就让它等十分钟,十分钟后仍未完成的,系统会自动释放它占的 generating 名额。文档里没有取消端点,所以更用力地重试是错的方向。
# Persist one submit response, then read only the fields that decide your next move.
curl -s --request POST 'https://app-api.pixverse.ai/openapi/v2/video/text/generate' \
--header "API-KEY: ${PIXVERSE_API_KEY}" \
--header "Ai-trace-id: $(uuidgen)" \
--header 'Content-Type: application/json' \
--data-raw '{"aspect_ratio":"16:9","duration":5,"model":"v6","motion_mode":"normal","prompt":"a slow dolly across a wet street at dusk","quality":"720p","seed":0}' \
> /tmp/pixverse-submit.json
jq -r '.ErrCode, .ErrMsg, (.Resp.video_id // "no id")' /tmp/pixverse-submit.json
# ErrCode 500044 means the account already holds its full quota of generating videos
代码里怎么处理 500044
是背压,不是失败
两个习惯能让集成待在上限之内:把 500044 读成背压而不是故障,因为这次请求本身是合法的;以及慢慢轮询,官方索引建议 every 3–5s。
# Submit with backoff, and never mint a second job while the ceiling is full.
submit() {
local body="$1" response code
response=$(curl -s --request POST \
'https://app-api.pixverse.ai/openapi/v2/video/text/generate' \
--header "API-KEY: ${PIXVERSE_API_KEY}" \
--header "Ai-trace-id: $(uuidgen)" \
--header 'Content-Type: application/json' \
--data-raw "$body")
code=$(jq -r '.ErrCode' <<<"$response")
case "$code" in
0) jq -r '.Resp.video_id' <<<"$response" ;;
500044) echo 'ceiling full, waiting for a slot' >&2; sleep 60; submit "$body" ;;
500090) echo 'insufficient balance' >&2; return 1 ;;
*) echo "submit failed with $code" >&2; return 1 ;;
esac
}
在 500044 上把同一条提示词重新提交,是唯一一种保证把情况变糟的写法。上限数的是任务,不是尝试次数,被拒的提交既不消耗名额,也不释放名额。
# Poll the documented status endpoint until the task leaves status 5.
video_id="$1"
while :; do
response=$(curl -s \
"https://app-api.pixverse.ai/openapi/v2/video/result/${video_id}" \
--header "API-KEY: ${PIXVERSE_API_KEY}" \
--header "Ai-trace-id: $(uuidgen)")
status=$(jq -r '.Resp.status' <<<"$response")
case "$status" in
1) jq -r '.Resp.url' <<<"$response"; break ;;
5) sleep 4 ;;
7) echo 'moderation failure, credits refunded' >&2; break ;;
8) echo 'generation failure' >&2; break ;;
*) echo "unexpected status $status" >&2; break ;;
esac
done
状态 6 只出现在官方索引里,含义是 deleted;端点页没有它,所以只按端点页写的客户端会把它记成未知状态。
那些每秒数字是谁的
转售商网关不是 PixVerse
搜这个关键词,提到速率的页面都是转售商。一家云网关为它自己的任务查询接口写了默认每秒 20 个请求;另一家公布了自己的 queued / processing / success / failed / cancelled 生命周期。两家都在转售 PixVerse 的模型,两个数字都不是 PixVerse 的限制。
走网关就有两个上限,小的那个说了算。两者失败的方式也不同:网关直接拒掉调用,PixVerse 回的是格式完好的响应体,里面装着 500044。500069 也不是配额,它要的是更长、带抖动的重试。
按并发上限估算批次
算波次,不算请求数
决定墙钟时间的是并发。任务数除以上限得到波次,再乘以你实测的渲染耗时,后者官方没有公布。
# Published ceiling in, wall-clock estimate out.
clips=120 # shots the project needs
seconds_per_clip=90 # your own observed average
concurrency=15 # Essential, per the rate-limit page
waves=$(( (clips + concurrency - 1) / concurrency ))
printf '%s clips at %s concurrent = %s waves\n' "$clips" "$concurrency" "$waves"
printf 'first-pass estimate: about %s minutes\n' "$(( waves * seconds_per_clip / 60 ))"
这个算法没有算重试、审核失败和那十分钟的释放窗口,它们都会把交付日往后推,所以承诺日期之前先加进自己的重试率;每秒积分单价要和波次一起看,两者共同决定项目花多少。API 指南讲的是本文默认你已经会用的请求头,图生视频链路在上限生效之前还多一次调用。
常见问题
PixVerse API 有每秒请求数限制吗? 官方未公布。限流页只公布同时生成中的任务数,免费档 3 条到商业档 25 条。
错误 500044 是什么意思? Reached the limit for concurrent generations. 账号 generating 状态的任务已经占满当前会员档允许的数量。
卡住的名额会占多久? 排查页写明,超过十分钟仍未完成的任务,它占的 generating 名额会被系统自动释放。
买积分能提高上限吗? 不能。表按会员档给,积分包和 API 会员是两笔独立的购买。