与官方 API 的差异

这套 API 实现的是 MiniMax Video Generation V2 接口。请求与响应体与 platform.minimax.io 逐字段一致，已有的接入只要改 base URL 和密钥就能迁过来。

所有差异都列在下面。没有别的，而且没有一条改变请求的结构 —— 只是收窄了可接受的取值。

差异清单

项	官方托管	这里	原因
`resolution`	`768P`、`2K`	仅 `768P`，`2K` → `400`	产出 2K 的 H3-Regenerate-2K 未开源
`duration`	4–15	5–15，`4` → `400`	4 秒是 96 帧，低于模型 120 帧的下限
`model`	`MiniMax-H3`	多 `-Fast`、`-Economy`	承载服务档位
`/v2/h3_context_ir`	有	未实现	H3-Context-IR 是托管的多模型工作流，未发布
取消	无端点	`POST /v2/video_generation/{id}/cancel`	官方 status 有 `cancelled` 却无接口产生它
`ref2va`	同一服务	独立 worker 池，未部署时 `503`	它用的是另一个 checkpoint
`seed`	不在请求体	`X-H3-Seed` 头	保持请求体与官方 schema 逐字节一致

关于 2K 与提示词扩写

这两项在开源版本里是真的没有。2K 来自 H3-Regenerate-2K，扩写后的提示词来自 H3-Context-IR，MiniMax 两者都没有发布。

我们返回结构化的 400 并说明原因，而不是把 2K 请求悄悄降到 768p，也不是塞一个质量与官方不可比的提示词扩写。如果你确实需要这两样，MiniMax 的托管 API 仍然提供，并且他们的 README 描述了「本地 H3-Base + 官方托管接口」的组合用法。

本地部署接口

MiniMax 还发布了一套用 SGLang 驱动本地 H3 部署的契约：

POST /v1/videos          { task, prompt, conditions[], target, seed } → { id }
GET  /v1/videos/{id}                                                  → { status }
GET  /v1/videos/{id}/content                                          → mp4

我们也对外提供这套接口，同样鉴权、同样计费，所以已经在驱动 SGLang 的客户端可以原样指过来。 MiniMax-H3/scripts/readme/*.sh 里的参考请求体被我们直接当作测试夹具使用。

在内部，这也正是我们 TPU worker 说的那套接口 —— 这就是为什么 SGLang worker 和我们的 worker 可以互换。

使用官方 SDK

把 base URL 指过来即可：

from minimax import MiniMax  # 官方客户端

client = MiniMax(
    api_key=os.environ["H3_API_KEY"],
    base_url="https://api.h3.studio",
)

视频生成相关的接口都能用。文本、语音、音乐类接口这里没有 —— 这套部署只服务 H3。