MiniMax H3 开放 API：多模态视频生成、音画同步与成本拆解

2026 年 7 月 31 日，MiniMax 正式发布新一代视频生成模型 H3。与此前主要围绕文生视频和图生视频展开的产品不同，H3 开始强调对多模态上下文的统一理解。开发者不仅可以输入文字和图片，还能够提供参考视频、音频等素材，让模型依据不同类型的信息生成包含原生立体声音频的视频。

8 月 3 日，MiniMax 进一步开放 H3 模型权重，并公布了系统架构、输入限制及完整生成流程。官方资料显示，H3 支持生成 4 至 15 秒的视频，最高输出分辨率为 2K，帧率为 24 FPS，音频采样率为 32 kHz。与此同时，MiniMax 开放平台提供了视频生成、上下文理解和高分辨率再生成等 API，使开发者可以在自己的程序中组织视频生产流程。

这次更新值得关注的地方，不仅是模型画质和生成能力的变化。随着视频生成模型逐渐具备统一处理文本、图像、参考视频和声音的能力，AI 视频的使用方式也开始发生改变。过去，创作者通常需要在网页界面中手动填写提示词、上传素材并下载结果；现在，同样的操作可以被拆分成能够由程序控制的任务，接入电商营销、广告制作和内容管理系统。

对于开发者而言，这意味着 AI 视频生成正在从单次创作工具向可编排的生产环节发展。不过，开放 API 并不等于自动具备完整的视频生产系统。任务调度、素材存储、结果校验和成本管理，仍然需要应用层进行设计。

一、MiniMax H3 为什么受到关注？多模态参考能力正在改变视频生成方式

早期的视频生成模型主要依靠文字描述画面，后来逐渐增加首帧图生视频和尾帧控制能力。这些功能已经可以满足简单的短视频制作需求，但在需要保持角色一致性、产品外观或镜头动作的场景中，仅凭提示词仍然存在较大的不确定性。

例如，一个电商团队需要为同一款商品制作多条展示视频。如果完全依靠文字描述，模型可能在不同批次中改变商品颜色、比例或包装细节。即使加入一张商品参考图，也不能保证复杂镜头中的商品始终保持一致。

H3 的设计思路是扩大模型能够理解的上下文范围。官方将其定义为通用全模态生成系统，支持通过统一输入结构提供不同类型的参考素材，使生成任务不再局限于传统的文生视频或单张图片驱动。

2026 年 8 月的官方开源公告将 H3 基础模型划分为两种主要输入模式。

H3-Base-FL2VA 用于首尾帧控制，可以不提供图片，直接通过文本生成视频，也可以提供首帧、尾帧或同时提供两张图片。该模式更适合画面起止状态相对明确的镜头，例如展示产品由静止状态进入运动，或者完成一个具有固定结尾构图的视觉片段。

H3-Base-Ref2VA 则面向多模态参考生成。按照官方公布的限制，单次任务最多支持 9 张参考图像、3 段参考视频和 3 段参考音频。参考视频每段长度为 2 至 15 秒，总时长不超过 15 秒；音频也遵循相同的时长限制，而且不能单独作为唯一参考输入，必须搭配图像或视频。

这种设计为视频编辑和商业内容制作提供了新的可能性。比如在制作品牌广告时，可以用图片约束商品外观，通过参考视频传达镜头运动方式，再结合音频素材提供声音或节奏参考。

但多模态输入并不等于生成结果一定能够精确复现参考内容。对于商品 Logo、文字、包装尺寸和人物身份等细节，仍然需要通过实际生成测试和人工审核确认。

H3 的另一项变化是原生音视频联合生成。传统流程可能先生成无声画面，再通过单独的音频模型添加背景声音和口播。H3 尝试在同一个生成体系中处理视觉与声音，使音频能够与画面内容建立更直接的关联。

官方公布的 H3 输出规格如下：

表格

这些数字来自 MiniMax 官方 H3 开源公告。其中，2K 输出依赖对应的高分辨率生成工作流，而不是所有本地部署版本都直接输出 2K 视频。

对于短视频开发者来说，4 至 15 秒的长度足以生成单个广告镜头或者分镜片段，但还无法直接覆盖所有长视频需求。制作 30 秒或 60 秒内容时，通常需要生成多个片段，再通过剪辑和后期处理完成成片。

因此，H3 更适合被理解为具备较强多模态参考能力的视频生成组件，而不是能够独立替代全部视频制作工具的软件。

二、H3 背后的技术机制：为什么模型能够同时理解画面、声音和动作？

H3 的技术架构主要涉及三个部分：H3-Context-IR、H3-Base 以及 H3-Regenerate-2K。

这种设计并不是把所有任务直接交给单个模型处理，而是将多模态语义理解、基础音视频生成和高分辨率再生成组织成相互配合的流程。

其中，H3-Context-IR 负责理解输入素材及其关系。假设用户上传一张产品图、一段镜头运动参考视频和一段音频，系统需要理解哪些信息描述产品外观，哪些信息属于动作约束，以及声音应该如何与画面关联。

普通提示词通常只能表达相对概括的生成要求，而多模态素材包含的信息更加复杂。图像具有空间结构，视频包含随时间变化的动作，音频则有语音、音效和时间节奏。不同模态之间需要建立对应关系，才能形成能够用于生成的上下文表示。

MiniMax 将这一处理过程称为 Context Intermediate Representation，也就是上下文中间表示。H3-Context-IR 通过多阶段预处理理解输入信息，再将其整理成 H3-Base 能够接收的结构化形式。

需要注意，这套预处理系统本身并没有随 H3 模型权重完整开源。官方为开发者提供了独立的 H3-Context-IR API，也允许开发者参考公开指南构建自己的预处理流程。

完成上下文处理之后，H3-Base 负责实际的音视频生成。

按照官方技术资料，H3-Base 使用不同的编码器和变分自编码器处理各类输入。文本通过 H3-Encoder 编码，视觉输入由 H3-Encoder 与 H3-VisualVAE 共同处理，音频通过 H3-AudioVAE 编码。处理后的表示被组织成统一的多模态序列，再交给 H3-Omni-Transformer 进行建模。

这里的 VAE 是 Variational Autoencoder，即变分自编码器。在视频生成系统中，它通常承担将高维图像或视频数据压缩到潜在空间，以及将潜在表示还原为可观看内容的任务。

H3-VisualVAE 采用时间因果结构，官方公布的空间压缩倍率为 16 倍、时间压缩倍率为 4 倍，潜在通道数为 24。这种压缩可以减少生成模型直接处理高分辨率视频时的计算负担。

H3-Omni-Transformer 进一步联合预测视频潜在表示和音频潜在表示，最终通过相应解码器恢复画面和立体声音频。

这一设计与先生成视频、再单独配音的串联工作流存在区别。联合生成可以让音视频在同一个建模过程中建立联系，但具体同步效果仍受到输入素材、动作复杂度和生成内容的影响。

值得注意的是，音视频联合生成不等于所有语言中的口型、语音和肢体动作都能达到完全准确的同步。对于需要严格口型匹配、专业配音或多语言商业投放的项目，仍然有必要保留字幕检查、音频对齐和后期修正环节。

为什么还需要 H3-Regenerate-2K？

按照官方公布的完整工作流，H3-Base 主要生成短边为 768 像素的基础音视频结果，H3-Regenerate-2K 负责结合原始生成上下文进行高分辨率再生成。

这一环节不能简单理解为传统的视频插值放大。

普通超分辨率处理通常以已有低分辨率图像为主要输入，尝试恢复或增强画面细节。而 H3-Regenerate-2K 会同时利用基础视频和原始上下文信息，让模型在生成更高分辨率结果时继续参考原本的语义约束。

例如，一段商品展示视频经过基础生成后，可能已经确定了主体位置和镜头运动。高分辨率再生成阶段可以继续利用商品参考素材和生成指令，尝试改善局部细节的表现。

从工程角度看，这种分阶段设计允许开发者先确认基础镜头是否符合要求，再决定是否进行高分辨率处理，从而避免在每个不合格片段上投入完整的高分辨率生成成本。

不过，商业 API 已经封装了部分生成流程，直接请求 2K 输出与开发者自行组合三个模块并不完全相同。尤其是自部署开源权重时，需要区分本地 H3-Base 能力与官方托管服务的完整能力范围。

三、从网页生成到 API 生成，AI 视频工作流究竟发生了什么变化？

对于偶尔需要制作视频的个人用户，网页端通常更加直观。上传素材、输入描述、选择生成参数后，等待结果即可完成基本操作。

但当视频生产规模扩大到数十个 SKU、多个投放市场或者不同内容版本时，手动操作的效率问题会逐渐明显。

假设一个电商团队每周需要为 40 款商品制作视频，每款商品需要三个不同卖点版本。按照每个版本先生成一个候选视频计算，一周就会产生 120 个视频任务。如果某些镜头需要重新生成，实际提交的任务数还会继续增加。

在网页界面中，工作人员需要逐一管理商品素材、提示词版本、生成结果和下载文件。即使模型本身生成速度较快，整个业务流程也可能因为大量重复操作而受到影响。

API 的价值在于将视频生成从人工操作转变为可编排的程序任务。

应用系统可以根据商品数据库读取素材，为不同 SKU 配置对应的提示词模板，并通过接口自动提交生成任务。任务完成后，程序将结果保存到素材库，再由审核流程决定是否进入正式发布环节。

这种方式可以让视频生成与现有业务系统建立连接。

例如，商品管理系统中已有的 SKU 编号可以直接用作生成任务的业务标识。生成时记录商品 ID、提示词版本和模型参数，后续即使需要重做，也可以追溯上一版使用了哪些素材。

相比单次生成，批量工作流更依赖任务状态管理。

MiniMax H3 的视频生成接口采用异步机制。开发者发送生成请求之后，服务器返回 task_id，该 ID 表示生成任务已经被创建，并不意味着视频已经生成完成。

应用需要继续查询任务状态，或者在支持的情况下使用回调通知。官方当前任务状态包括 queued、running、succeeded、failed 和 cancelled。

对于规模较大的系统，可以将生成请求放入任务队列，由独立工作进程负责提交与查询。这样既能控制并发，也能够在应用服务器重启后恢复未完成的任务。

API 工作流还需要考虑素材存储问题。视频通常比文本响应占用更多存储空间，因此不适合将所有视频直接保存在业务数据库中。较合理的方式是将生成结果保存到对象存储，再在数据库中记录文件地址、任务 ID、生成参数和审核状态。

这并不是 H3 独有的架构要求，而是多数程序化视频生成服务在规模化使用时都会遇到的工程问题。

四、如何通过 MiniMax H3 API 生成视频？从任务提交到结果获取

MiniMax 开放平台目前提供 V2 视频生成接口。根据官方文档，H3 视频生成任务使用 POST /v2/video_generation 创建，成功后返回任务 ID；查询结果则使用 GET /v2/query/video_generation/{task_id}。

官方提供的模型标识为 MiniMax-H3。API 支持文生视频、首尾帧图生视频以及参考素材生成。不同输入模式需要通过 content 数组组织素材，其中每个请求都必须包含非空的文本提示词。

下面采用 Python 演示一次基础文生视频请求。示例基于官方公布的请求结构编写，需要安装 requests 库并配置有效 API Key。

提交视频生成任务

import os
import requests

API_KEY = os.environ["MINIMAX_API_KEY"]
BASE_URL = "https://api.minimax.io/"

headers = {
    "Authorization": f"Bearer {API_KEY}",
    "Content-Type": "application/json"
}

payload = {
    "model": "MiniMax-H3",
    "content": [
        {
            "type": "text",
            "text": (
                "A clean commercial product shot of a "
                "wireless headphone on a white desk. "
                "Slow camera orbit, soft studio lighting, "
                "natural shadows, no added text."
            )
        }
    ],
    "resolution": "768P",
    "duration": 5,
    "ratio": "16:9"
}

response = requests.post(
    f"{BASE_URL}/v2/video_generation",
    headers=headers,
    json=payload,
    timeout=30
)

response.raise_for_status()
result = response.json()

task_id = result["task_id"]

print("Task ID:", task_id)

代码中使用 MiniMax-H3 作为模型名称，生成时长设置为 5 秒，输出分辨率为 768P，画面比例为 16:9。这些参数符合官方当前接口允许的取值范围。

对于图生视频任务，可以在 content 数组中增加 image_url 元素，并通过 role 指定首帧或尾帧。如果使用参考素材模式，则应采用 reference_image、reference_video 或 reference_audio 等角色标识。

需要注意，首尾帧模式与参考素材模式在当前接口中不能混用。如果一个请求已经包含参考素材角色，就不能同时加入首帧或尾帧角色，否则可能触发参数校验错误。

查询生成状态

视频任务提交成功后，需要根据任务 ID 查询结果。下面的示例继续使用前一步生成的 task_id。

import time

query_url = (
    f"{BASE_URL}/v2/query/"
    f"video_generation/{task_id}"
)

video_url = None

for attempt in range(60):
    response = requests.get(
        query_url,
        headers=headers,
        timeout=30
    )

    response.raise_for_status()
    data = response.json()
    task = data["task"]
    status = task["status"]

    print("Status:", status)

    if status == "succeeded":
        video_url = task["content"]["url"]
        break

    if status in ("failed", "cancelled"):
        raise RuntimeError(
            f"Video task ended: {status}"
        )

    time.sleep(10)

if video_url is None:
    print("Task is still pending. Save the task ID.")
else:
    print("Video URL:", video_url)

这段代码以 10 秒为查询间隔，最多查询 60 次，只是为了演示异步流程。实际生产环境不应在等待超时后直接判定生成失败，因为任务可能仍在服务端运行。

官方查询接口支持查询最近 7 天的相关任务，因此应用应当在任务完成后及时保存结果，而不是长期依赖平台保留历史任务。

对于需要管理大量任务的系统，官方还提供状态变更回调能力。开发者可以在创建任务时设置 callback_url，通过服务端通知减少无效轮询，但回调接收端需要按照文档完成验证和安全处理。

下载并保存视频文件

当任务状态变为 succeeded 后，可以从响应中的 task.content.url 获取生成视频地址。

if video_url:
    with requests.get(
        video_url,
        stream=True,
        timeout=120
    ) as video_response:
        video_response.raise_for_status()

        with open("h3_output.mp4", "wb") as file:
            for chunk in video_response.iter_content(
                chunk_size=1024 * 1024
            ):
                if chunk:
                    file.write(chunk)

以上示例完成从任务提交到查询、下载的基础流程，并没有包含完整的限流处理、断点续传、重试去重和业务数据库记录。生产使用时，还需要根据接口返回的错误码制定处理策略。

例如，HTTP 429 表示请求触发限流，应采用合理的退避策略，而不是持续高频重试。HTTP 401 通常与认证有关，需要检查 API Key 配置。对于因内容审核而失败的任务，则不能将同一请求无限重复提交。

还需要区分视频生成接口与普通文本模型接口。H3 使用的是独立的视频生成端点，不能直接将 MiniMax-H3 填入通用 Chat Completions 请求，并假设能够获得视频文件。

五、MiniMax H3 生成视频需要多少钱？为什么批量生产更需要成本管理

与文本模型主要按照 Token 数量计费不同，视频生成的费用更依赖输出时长和分辨率。涉及参考视频或额外图片时，还可能产生输入素材费用。

根据 MiniMax 官方开放平台截至 2026 年 10 月公布的按量计费价格，MiniMax-H3 生成 768P 视频的基础输出价格为每秒 0.08 美元，生成 2K 视频为每秒 0.13 美元。

表格

上述费用只计算视频输出，不包含可能发生的额外参考素材计费及独立调用的上下文处理服务。价格以美元计，具体以官方账单为准。

按照这个口径，如果每天生成 100 条 10 秒的 768P 视频，仅输出费用就达到 80 美元。假设连续生产 30 天，理论输出费用为 2400 美元。

但实际生产成本通常还要考虑无效片段与重新生成。

例如，一项广告生产任务最终需要 100 条可用视频。如果每条视频平均需要生成 1.5 次才能获得满意结果，那么实际生成数量约为 150 条。对于 10 秒 768P 视频，基础输出费用相应增加至 120 美元。

这里的 1.5 次是为了计算而设置的假设值，并不代表 H3 官方实测返工率。

如果项目还需要输入参考视频，成本会进一步变化。根据官方定价，H3 使用参考视频时会按照输入视频时长和所选输出分辨率另外计费。对于 2K 输出，输入视频的参考计费价格同样为每秒 0.13 美元；768P 输出则为每秒 0.08 美元。

图片参考也有独立规则。H3 每次任务的前 5 张输入图片免费，超过部分按每张 0.04 美元计算。音频参考当前不单独收费。

因此，一次包含多张参考图片与参考视频的生成任务，费用可能高于仅按照输出时长估算的结果。

还有一个容易被忽略的细节是高分辨率再生成。

MiniMax 提供 H3-Regenerate-2K 接口，可以将 768P 基础视频结合原始上下文重新生成 2K 结果。官方公布的再生成输出费用为每秒 0.05 美元，但如果原始任务使用了参考视频或额外图片，这些素材可能在再生成阶段再次计费。

对于批量生成系统，这意味着低分辨率初稿和高分辨率成片应该采用不同的管理策略。可以先使用 768P 生成候选镜头，通过人工或自动审核之后，仅对最终选中的内容执行 2K 处理。

需要注意，这种流程并不意味着每一种情况下都比直接请求 2K 更便宜。如果所有候选片段最终都需要生成 2K，那么分阶段处理还可能增加总体费用。实际选择应根据初稿淘汰率、参考素材数量与最终画质要求进行计算。

另外，H3-Context-IR 独立接口采用 Token 计费，当前输入价格为每百万 Token 0.90 美元，输出为每百万 Token 3.60 美元。只有单独调用相关接口时，才需要按照其实际用量核算，不能简单将这笔费用固定叠加到所有直接生成请求中。

从工程角度来看，视频生成系统最好为每个任务记录实际输出时长、所用分辨率、参考素材数量和完成状态。这样才能分析不同业务类型的平均成本，并识别大量重复生成的环节。

六、视频生成为什么需要统一 API 管理？模型能力之外还有工程问题

当 AI 视频生成开始进入实际业务，模型本身只是其中一个环节。一个完整的视频生产系统通常还包括提示词管理、素材上传、任务执行、结果审核和文件归档。

对于单模型应用，可以直接调用 MiniMax 官方接口。但如果团队同时使用不同视频模型，或者需要将图像生成、文本脚本、视频制作和语音处理串联起来，管理复杂度就会明显提高。

不同模型可能采用不同的请求结构。某些视频接口根据任务 ID 异步获取结果，另一些模型可能通过文件 ID 下载，部分服务则使用回调通知。即使底层都支持 HTTP 接口，也不意味着它们能够通过同一套请求参数直接互换。

因此，开发者可以在业务系统与模型服务之间设计统一接入层，将不同模型的认证信息、调用适配与结果状态管理集中处理。

对于以国产模型为主的应用，也可以考虑星链 API 等聚合 API 服务，将文本、图像或其他已支持的模型统一管理，减少重复维护不同服务商配置的工作量。不过，视频生成接口往往具有独立的异步任务协议，是否能够通过某个聚合平台完整调用 H3，还需要逐项确认实际支持情况，不能简单套用文本模型的兼容接口。

在系统设计中，统一 API 入口与任务调度服务最好保持职责清晰。

API 接入层负责请求路由、服务认证和不同供应商的协议适配；任务系统则负责记录生成状态、安排轮询或回调处理，以及控制失败任务的重试。最终生成的文件需要进入素材存储服务，再由业务系统完成审核和发布。

这种架构的优势在于降低模型切换对上层业务的影响。当某个模型版本升级，或者团队需要增加新的生成服务时，可以将部分变化限制在接入层，而不是重新修改全部业务流程。

但统一接口无法消除模型之间的能力差异。不同视频模型对参考图像、首尾帧控制和音频生成的支持范围可能不同。如果某个模型不具备原生音视频联合生成能力，统一 API 也不能凭空补齐这项能力。

对于已经投入使用的系统，更合理的方案是根据任务类型选择模型。例如，要求严格遵循商品参考图的镜头，可以优先使用经过实际测试、具有较强参考控制能力的模型；普通背景过渡镜头则可以根据成本与效率选择其他生成方案。

随着调用规模扩大，任务监控也会变得重要。开发者需要关注任务排队时间、生成完成率和失败原因，而不是仅记录接口是否成功返回 HTTP 200。对于异步视频生成，任务创建成功与视频生成成功是两个不同事件。

在多供应商环境下，调用成本还可能受到不同服务商定价、汇率和计费方式影响。如果使用星链 API 等第三方中转服务，应以实际服务支持范围及其公开计费规则为准，不能直接把 MiniMax 官方美元价格视为第三方平台的最终收费。

七、H3 开放 API 之后，AI 视频生产会出现什么变化？

MiniMax H3 的发布说明，AI 视频模型正在从单一提示词驱动向多模态上下文驱动发展。模型能够同时接收文字、图像、参考视频和音频，使视频生成不再完全依赖用户通过文字描述所有细节。

H3-Context-IR、H3-Base 和 H3-Regenerate-2K 组成的工作流，也展示了一种值得关注的系统设计方式。复杂输入可以先经过语义整理，基础模型负责生成候选片段，再根据实际质量需求进行高分辨率再生成。

对于开发者来说，这种结构有利于将 AI 视频生成接入已有业务系统，并通过 API 实现任务自动提交、状态查询及结果存储。

不过，从单次生成走向规模化生产，并不只是增加 API 调用数量。视频生成仍然存在结果不确定性，而且不同任务对画面一致性、音频同步和内容合规的要求并不相同。要让生成结果真正进入商业流程，还需要稳定的任务调度、质量审核和素材管理机制。

从实际应用来看，电商商品视频、品牌广告分镜、游戏素材和动态 UI 演示都具有较明确的自动化需求。这些场景往往需要重复生成大量相似但不完全相同的内容，更适合通过程序组织模型调用，而不是完全依赖人工操作网页界面。

H3 提供了多模态视频生成能力和可供开发者使用的 API，但最终的生产效率仍取决于整个工作流的设计。模型能够生成高质量片段，并不意味着系统已经具备自动筛选、批量合成和发布成片的能力。

对于准备使用 AI 视频模型的团队，比较稳妥的路线是先建立小规模生成流程，验证素材约束和结果质量，再逐步扩展批量任务、成本监控与多模型管理。

视频生成正在成为 AI 应用中的一个可编排环节，而不再只是独立的网页创作工具。MiniMax H3 的实际意义，也正在于它将多模态生成能力进一步开放给开发者，使这些能力可以与现有软件系统结合。

了解更多：https://xinglianapi.com/