如何使用 MiniMax H3：提示词、本地运行，以及不垃圾的音频

8月4日，西蒙·威利森下载了约115GB的权重，将MiniMax H3的非官方MLX移植版指向他的M5 Max MacBook Pro，并要求生成一只在超市里跃过一根长满苔藓的原木的彩虹色臭鼬。不到45分钟后，他得到了一段被他称为确实令人印象深刻的视频片段——但音轨被他形容为古怪的、类似语音的垃圾。他自己的诊断才是最有用的部分：他没有给模型任何音频指令，也没有事先阅读提示词指南。这就是对开始使用H3（也以Hailuo 3.0之名销售）体验的最简短概括。画面几乎等于白送。其他一切——声音、镜头节奏、2K分辨率，以及必须连续撑过四个镜头的角色——都需要你明确要求，而且提示格式比目前几乎任何其他视频模型都要严格。

这是一份使用指南，而非发布报道。三个信息来源层级贯穿全文，且每次出现都会明确标注：公司的官方文档（模型卡、仓库内附带的两种提示词编写指南、平台API文档）；社区发现来自实际运行过它的人——ComfyUI的维护者、独立基准测试者、经销商文档和Hugging Face讨论帖，日期均在2026年7月31日至8月5日之间；此外还有少数几处我们亲自阅读原始文件并对此加以说明。除非另有说明，社区数据均为非受控硬件上的单一报告。当实践者之间存在分歧时，我们如实报告分歧，而不代为解决。

首先：你可能没有运行整个模型。

H3 上线第一周的大部分困惑都源于一个被营销文案模糊化的结构性事实：H3 并非单一模型。根据其模型卡，它是一个三部分系统，且只有中间部分被开源：

• H3-Context-IR — 一个多模态指令预处理器。它读取你的文本、图像、音频和视频，推理它们之间的关联，并输出你所请求内容的结构化、语义增强表示。仅提供托管 API。它以独立任务类型的形式对外提供，返回增强后的提示词，且完全不返回视频。

• H3-Base——真正能生成画面和声音的33B参数生成模型。这是开放权重部分。

• H3-Regenerate-2K——一种上下文内重新生成流程，可将 768p 结果提升至 2K。仅提供托管 API。

两个后果随即显现，它们决定了你的整个工作流程。第一，本地生成存在 768p 的上限。H3 的原生画布短边为 768 像素，最高为 768×1344——16:9 时约为 1344×768。如果你的 ComfyUI 输出不是 2K，并不表示出了问题；你下载的是 H3-Base 安装包，里面没有放大模块。第二，托管 API 会修正含糊的提示词，而你的本地安装不会。Context-IR 在付费 API 调用中所做的一切——推断结构、解析每条引用指的是什么、补全你语焉不详的部分——都是你需要在 H3-Base 看到你的文字之前，手动或借助另一个模型完成的步骤。正是这种不对称性，解释了为什么大多数反馈是“同样的提示词在 Hailuo 上正常，在 ComfyUI 里却像是坏了。”

从仓库本身值得注意的一点是：权重带有minimax-h3-community-license-agreement标签，而非 Apache 或 MIT（下文将详细说明，因为这才是决定你是否能发布产品的关键），该模型标注为 F32/BF16 格式的 33B 参数，且截至目前，仅有一家推理提供商——fal——被列为支持该模型的服务方。在其之上已经存在 23 个微调版本、20 个量化版本和 31 个 Spaces，这充分表明了社区的反应速度之快。

提示格式：镜头块，而非时间码。

这就是社区与文档公开存在冲突之处，而这比本文中任何其他单一事项都更为重要。

传播最快的模板——先是通过Reddit，随后出现在多份公开指南中——将片段按时间码括号切分：[0s-2s]，[2s-5s]，依此类推，之后是一个六块结构：风格约定、时间线、镜头、音频、拼写文本和负面清单。它是通过阅读该公司发布的45个示例提示词逆向推导出来的，并非无稽之谈：这些示例实际上就是附带了声音提示表的镜头清单，中位长度约为130个中文字符，最长的达到657和858个字符。

但该公司自己的VIDEO_PROMPT_WRITING_GUIDE_base_en.md，位于仓库的docs文件夹中，却规定了不同的做法。它按镜头块，而不是按时间范围。我们直接阅读了它；它要求的结构是：

• 指令——图像对齐规则，用于关键帧模式（I2VA、FL2VA、L2VA），纯文本转视频时省略。

• 集成多模态描述 — 主体部分，分为 [镜头1]、[镜头2]，等等。

• 整体音景 — 一至四句关于剧情内声音的描述。

• 非叙事音乐 —— 一到三句配乐。

在此框架内，这些约定足够具体，可以核查。[Shot 1] 完全没有时间戳——后续镜头均以绝对时间码切换开始，表述为“在 00:03.500 处，镜头切换到……”。摄影机运动按照运动类型+幅度+速度来书写，融入自然的英语表达，而非堆叠成标签：小幅缓慢推进，而不是 camera: dolly-in, slow。可用的运动方式是常见的那套——变焦、摇摄、俯仰、跟拍、弧线、POV，以及轻微和强烈两种程度的抖动。对白用标签包裹：<d>[English] Get in the car.</d>，标点符号精确保留，绝不翻译或转述。说话人有固定 ID——(S1)、(S2)，联合台词为 (S1,S2)——并在首次出现时描述其年龄、性别、音色和口音。旁白标记为画外台词，并明确注明嘴唇保持闭合，以此防止模型将旁白对上人脸口型。交叉剪辑的对话使用<scenetrans>标记，外加一条连续性说明。

该指南明文禁止的内容与其规则一样富有信息量：不要为第一个镜头添加时间戳，不要在overall_soundscape内重复对话、演唱或画内音乐，不要在non_diegetic_music中使用抽象的情绪词汇，并且永远不要重写对白。还有一个值得注意的缺失——官方指南完全没有负面提示词部分，这意味着流行社区模板中的“禁止转场”列表是社区的发明，而非文档中记录的功能。

这场冲突需要多认真地对待？在 H3 仓库的 Hugging Face 讨论中，一位社区成员将时间码式结构作为指南贴了出来，另一位从业者则直白地回应说，他们用过类似的结构，那种结构完全不对，人们应该去读随附的手册。这只是一人在反驳另一人，并非维护者的裁定。我们对证据的解读是：两者都能通过托管 API 工作，因为 Context-IR 会对你发送的任何内容做归一化处理；只有文档中记载的格式才能直接可靠地用于 H3-Base。如果你运行的是本地权重，请遵循仓库中的文件。如果你使用的是 API，并且时间码提示能为你带来不错的片段，那是预处理器在替你完成这项工作，你不应断定这种格式就是功劳所在。

将一份惰性简报编译为H3的方言

以威利森那十二个词的提示作为输入——一只彩虹色的臭鼬在超市里跃过一根覆满苔藓的原木。按照文档记载的写法，这大致会变成：一个[镜头1]区块，先点明风格（实景真人、手持摄影、荧光灯照明）和画面（一条超市过道，油毡地板上横着覆满苔藓的原木，货架向远处退去），再按物理顺序呈现主体与动作——两步轻踏、一次蹲伏、跃起、落地——摄影机则以缓慢、小幅度的跟拍移动，最后停在原木的另一侧；一个overall_soundscape，其中有爪子划过油毡的声响、原木潮湿的摩擦声、冰箱的嗡嗡声和远处手推车的轮子声；以及一条non_diegetic_music：一段简短、轻快、拨弦演奏、无人声的音乐提示。这里面毫无天才创意可言。这仍是同一个想法，只是真正提供了H3所要求的四样东西——而这正是无人要求的环境音与你亲手设计的配乐之间的差别。

这一步机械、重复，且浪费人力，这正是公司为此发布工具的原因，但几乎没有任何报道提及它。该仓库包含一个技能目录，内含九个智能体技能，第一个——h3-prompt-writing——做的正是这件事：它接收请求，并跨所有五种生成模式编写结构化的 H3 提示词，还包含完整的音景和音乐部分。其余八个是类型配方（产品广告、3D 动画短片、纸艺解说、音乐视频字幕、合作游戏开场、手绘与真人实拍混合等），它们将相同的格式封装进一个工作流中。

运行该技能需要的是文本模型而非视频模型，这正是路由器真正有用、而不是一个插件的地方。该公司自己的 LLM——MiniMax M3——是这项工作的合理选择，它在 OrcaRouter 上的价格为每百万输入 token 0.30 美元、每百万输出 token 1.20 美元（供应商列表价，因为我们以 0% 加成透传），上下文窗口为 100 万 token，而且不同寻常的是，它还接受视频作为输入类型。最后这一点正是它契合的原因：你可以一次调用就把官方提示指南、你的简报和一段实际参考片段交给它，然后取回描述它的[Shot N] 块。编译一条提示仅需不到一美分的成本，而视频生成是按秒计费的，因此没有理由手写这些提示。有两个需要坦诚说明的注意事项：H3 视频生成本身并不在 OrcaRouter 上运行——片段来自该公司的平台、fal 或你自己的 GPU——而且编译步骤只是一种便利，并非质量保证。路由器在这里带给你的价值在于：流程的文本部分只需一个具备自动故障转移功能的密钥即可接入，因此批次中途的供应商服务中断不会让渲染队列卡住；而且将 M3 换成另一个模型来比较编译后的提示，只是改一个字符串，而不是重新签一份契约。

音频是第一天所有人都会栽跟头的地方。

第一周中最被广泛证实的故障模式正是 Willison 遇到的那一个：不指定声音，H3 就会糟糕地凭空编造出某种东西。他从一个没有音频方向的提示中得到了类似语音的噪声。对官方示例进行逆向工程的文章以较为温和的形式报道了同一类故障——省略音频块，模型就会输出一个未经请求的房间环境音——并将这些视为缺失而非错误，这正是思考音视频联合模型的正确方式。它总是在生成配乐。你唯一的选择就是是否指定它。

将官方提示指南中的指导与经销商文档和评论者报告的实际有效内容汇集起来：

• 对话是最难求得的东西。 每五秒的片段中，台词应保持在一到两句。过长的台词会导致语速仓促、音频超出最后一帧，或口型同步紧张——审阅者一致反映这些问题。

• 在台词之前描述说话者，并同时说明其表达方式。按照官方指南，在首次出现时注明年龄、性别、音色和口音；表达提示要简单直接（清晰、热情、平淡），而非详细的表演指导——据说复杂的表演指导会降低同步性。

• 将每个效果都绑定到一个可见事件上。“软木塞飞出时砰的一声”要好过“声音：砰”。这些词 as、when和then才是实现同步的关键。

• 按流派、节奏、情绪和配器简要描述音乐——绝不按艺术家或歌曲。 当画面应占主导时，加上"no vocals"；这是保持混音干净的一种有据可查的方式。

• 用单个分句叠加氛围。 雨打玻璃、低语交谈、偶尔的杯盏轻碰、轻柔的背景爵士乐——堆叠在同一句中，而非逐项罗列。

• 不要在音景部分重述对话。这是官方指南中明确禁止的行为；各部分应当互不重叠，在那里重复台词会使其出现两次。

• 如果某个词需要在屏幕上可读，请用引号将该词括起来。审核人员反馈称，明确指定的字符串能清晰渲染，而模糊的请求（如“HUD elements”“a sign”）则会生成形似字母的噪点。

根据多位评测者的说法，音频真正表现出色的地方在于具体的物理声音——与可见物体相关的拟音和效果——以及环境声。而在抽象或氛围类需求上则较弱。多说话人场景经常需要剪辑才能把说话顺序弄对，而且发音质量因语言而异，所以在把项目交给它之前，最好先用一段一次性片段测试你的目标语言。几位评测者也指出了其真实的上限：声音质量足以用于社交媒体分发，但通常不足以在不替换的情况下作为广播或付费广告混音交付。这些都不是厂商的指导，而是从业者的实际报告。

引用：让每个文件各司其职

H3的参考系统是其最强大的差异化优势，也是设置错误最常见的地方。平台API文档中记载的限制为：最多9张图片、3段视频剪辑和3段音频剪辑，总计不超过12个文件，每段参考视频或音频时长在2到15秒之间，且总时长不超过15秒。参考转视频需要至少一张图片或一段视频；仅音频不被接受。

官方参考指南和社区报告一致认可的技巧是为每个输入打上标签并为其分配任务。按照文件附加的确切顺序，通过标签逐一引用——<Picture 1>、<Video 1>、<Audio 1>——然后在提示词中明确说明哪个参考项驱动哪个属性：身份、风格、动作、镜头或声音。官方示例提示词正是以此开篇，声明第一张图片是整体氛围和风格参考，第二张图片是主角。从业者反馈，明确分配的效果远好于一次性堆入九张图片然后寄希望于运气。

两个让人付出渲染代价的细节：

• <Picture 1> 不是情绪板——它就是真正的第一帧，出现在 0.000 秒处，属于 [Shot 1]。在描述由它引发的动作之前，先描述其中的内容（风格、主体、构图、场景锚点）。把它当作你在制作动画的一个静帧，而不是一个提示。

• 有两个独立的检查点，用错一个会静默失败。 fl2va处理文生视频和首/末帧工作；ref2va处理参考图转视频。这是 ComfyUI 中最常被报告的错误：R2V 图运行时仍然选择了 FL2VA 模型。另外值得了解的是，ComfyUI 公告上的一位评论者指出，随附的 R2V 模板只提供了两个图像参考槽位，而该模型实际上接受九个——这是模板限制，而非模型限制。

在托管端，另外两条来自经销商文档的实践要点：ratio 参数在 ref2va 端点是必填的，不能保留为“adaptive”；重叠任务会因任务并发而返回 429，而不是排队等待——所以要么按顺序批量处理，要么自行构建队列。在本地，ref_image_size 默认为 match，这样速度更快；max 会保留参考图的短边（最多 2048 像素），并且更耗时。

本地运行实际消耗的墙钟时间是多少

下载完整的官方仓库是498 GB，而ComfyUI重新打包的镜像为343 GB。你不需要完整下载两者。ComfyUI官方教程列出的用于文生视频和图生视频的四个文件总共约42.5 GB：

• 扩散模型 — minimax_h3_fl2va_pruned_int8_convrot.safetensors，20.97 GB，放入 models/diffusion_models。

• 文本编码器 — qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors，15.69 GB，放入models/text_encoders.

• Video VAE — minimax_h3_video_vae_fp16.safetensors（5.21 GB）放入models/vae。

• Audio VAE — minimax_h3_audio_vae_fp32.safetensors，0.61 GB，也放入models/vae。

• 添加用于参考转视频 — minimax_h3_ref2va_pruned_int8_convrot.safetensors，另需 20.97 GB。

那42.5 GB并非显存数字——而是磁盘占用，各部分会被流式加载和卸载。该模型之所以能塞进消费级显卡，靠的是ComfyUI记录的一项工程技巧：大约40%的参数位于AdaLN调制分支中，这些分支的输出可以预先计算，并用功能等价的查找表替代，从而将加载的模型从33.12B降到约20.11B，且按ComfyUI的说法，质量无损。全精度需要123.6 GB。如果你在做微调或追求最后几个百分点的保真度，还有未剪枝的int8检查点（每个34.04 GB）和bf16检查点（每个66.28 GB）可用。

需要 ComfyUI 0.30.0 或更高版本，它自带三个模板：T2V、I2V 和 R2V。所有指南和维护者一致推荐的首次运行基线故意设置得较小：16:9、0.4 MP（864×480）、5 秒、20 步、使用 simple 调度器的 res_multistep 采样器、denoise 1.0、batch 1。在调整分辨率或时长之前，先导出一个同时包含视频和立体声音频的 MP4。一个需要了解的算术特性：时长会对齐到 17k+5 帧的网格，因此 5 秒的请求会变成 124 帧——在 24 fps 下约为 5.17 秒——而 10 秒的请求会落在 243 帧，即 10.125 秒。5–15 秒范围内的请求是更安全的区间。

那么，从社区报告来看，这些在实际时间上要花多少（均为单次运行、未加控制、且设置各不相同——上方图表在每个柱旁标出了对应配置）：一台配备 12 GB RTX 3060、32 GB 系统内存和高速 NVMe 的机器，使用动态卸载，在不到九分钟内完成了 864×480 / 124 帧 / 20 步的基线任务。一台启用 SageAttention、配备 16 GB RTX 4090 的笔记本电脑，在 182 秒内完成了 960×540、5 秒、20 步的任务。在单个 RTX 5090 上构建的 NVFP4 版本，以 10 步在 175 秒内生成了 243 帧（10.1 秒）的 864×480 片段，VRAM 峰值达 26.9 GiB，磁盘上仅占用 31.7 GB 文件。SGLang 自己的 cookbook 参考——1344×768、124 帧、50 步，跨两张 RTX 5090 并使用分层卸载——耗时 559.67 秒。而 Apple Silicon 路径，通过非官方 MLX 移植版，单个片段耗时不到 45 分钟。

从这些报告中提炼出的实用要点：

• 系统内存和磁盘速度是承重因素，而非可选项。 在12 GB显卡上，所选文件按设计就会超出显存容量，因此卸载路径会先经过内存，再写入固态硬盘。两份成功的低显存报告都使用了32 GB内存。目前尚不存在经证实的8 GB结果。

• SageAttention 是唯一的免费加速方案——在 ComfyUI 中大约可实现 2 倍加速，如果运行主要受卸载流量限制，效果则略低。安装与你确切的 PyTorch 和 CUDA 构建版本匹配的 wheel，加上 ComfyUI-KJNodes，然后插入Patch Sage Attention KJ到 UNET 加载器和引导器之间，并将其设为自动。预计会出现某些 H3 层不是 FP16/BF16 的警告；这种回退行为已有文档记录，属于正常现象。

• 步数可以灵活调整。5090 基准测试运行了 10 步，ComfyUI 基线运行 20 步，而 SGLang 参考配置使用 50 步。还没有人发布过质量-步数曲线，所以在假设你需要 50 步之前，先找到你自己的下限。

• OOM时，一次只更改一个变量。文档记录的恢复方法是回退到0.4 MP、5秒、批量1，并且每次尝试只移动一个旋钮。

• 静音音频意味着音频 VAE 未连接到视频输出节点。这是一种不同于音频损坏的故障，且容易被误认为是模型拒绝生成声音。

• Apple Silicon 是非官方的。Willison 的路线是PipeNetwork/minimax-h3-mlx，一个社区移植版本，通过运行uv来针对 MLX 需求文件。该公司自己的材料提到了 SGLang、vLLM、Diffusers 和 ComfyUI，典型部署为四个 BF16 GPU，并且没有提及 Metal 或 MPS。请将 Mac 支持视为社区维护的。

本地与托管，附具体数据

由于2K模块和提示词预处理器仅在托管环境中可用，这实际上并不是非此即彼的选择。架构促使你采用的模式是：在本地以768p分辨率迭代，每次尝试只需消耗电费和三分钟，然后为最终成品付费。按秒计费对你保留的那一版来说没有问题，但对你扔掉的那四十版来说则是毁灭性的。

在价格方面要小心，因为价格会因卖家不同而相差约2倍，而且供应商自己的博客文章没有给出任何美元数字——只提到2K分辨率的价格不到主流机型的三分之一，768p分辨率的价格不到竞品720p价格的一半。已明确公布的信息是：fal，目前Hugging Face仓库中列出的唯一推理服务提供商，收费：768p下每秒$0.16，2K下每秒$0.26。第三方追踪平台显示，该公司自己的标价要低得多——大约768p下每秒$0.09–$0.10，2K下每秒$0.13–$0.14——而且这些数据彼此之间连一分钱都对不上，所以只能把它们当作参考，在制定预算之前查看平台的定价页面。另外，做预算时还要考虑到：参考视频本身会按其时长计费，生成的输出也会计费。

用一个真实数字来算。一百个保留片段，每个八秒，就是800秒的生成量：按$0.14的2K费率约$112，按fal的$0.26约$208，如果按较低价目表以768p交付则约$76。每个保留片段对应的四十个弃用片段才是决定账单的因素，而这些应该在本地生成。这也是为什么你比较的价格必须保持真实的原因——在OrcaRouter上，该流水线的文本端按供应商列表价传递，没有加价，所以当供应商降价时，当天就会生效，而不是在利润率重新计算之后。再说一次，视频生成不是我们的；重点只是编译步骤不应该是你需要操心的一项。

在基于此构建产品之前，请阅读许可证。

这是大多数“如何使用”指南都会跳过、但对很多读者来说却是唯一能改变决定的部分。我们直接阅读了仓库中的 LICENSE 文件。权重以 H3 Community License Agreement 发布，而非开源许可证，其中包含的条款相当不寻常，值得在此引用其实质内容：

• 地区。该许可证将其“适用地区”定义为全球不包括欧盟、英国、韩国和美国。按字面理解，这排除了目前发布本地生成结果的很大一部分人——而且该限制的表述旨在覆盖输出，而不仅仅是权重。

• 署名。商业使用需在产品界面上显示“H3”；该许可还鼓励添加“Powered by H3”声明。

• 收入门槛。基于其构建的产品或服务年收入超过2000万美元的组织，必须获得公司的单独书面授权。

• 禁止蒸馏。 您不得使用H3或其输出改进任何其他AI模型，除非是H3的衍生模型。这排除了标准的合成数据做法。

• 管辖法律。香港特别行政区，香港法院拥有专属管辖权。

• 一个真正开放的组件。Qwen3-VL-32B 文本编码器采用 Apache 2.0 许可证；上述限制适用于 H3 权重。

我们不是你的律师，这也不是法律建议——请阅读公司随许可证一起提供的许可证和问答文档；如果你在被排除的地区进行商业开发，请咨询律师，而不是相信博客的解读。实际的区别在于：托管 API 是一笔具有不同条款的交易，与针对权重的社区许可证不同。因此，如果本地许可证不适用于你，API 途径可能仍然可用。请查看你所购买平台的具体条款。

第一周测试计划

按照这个顺序运行五次，就足以判断 H3 是否适合你的流水线：

• 运行1——验证基本流程。T2V模板，864×480，5秒，20步，res_multistep/simple。成功标准是一个包含立体声音频的MP4，而不是一个好的片段。

• 运行2 — 证明格式很重要。同一主题两次：一次作为松散的单行描述，一次写成 [Shot 1] 加上 overall_soundscape加上non_diegetic_music。如果第二个相对于 H3-Base 没有明显更好，那你的设置就有问题。

• 第 3 遍——一行对话。 一位说话者，一个句子，说明表达方式，五秒钟。这是判断音频是否达到你的使用要求，以及目标语言发音效果的最快方式。

• 运行4——参考规范。R2V 使用ref2va 检查点，提供两到三个参考，每个参考都明确标注并分配了任务，将<Picture 1>描述为实际的第一帧。然后故意打破这一规范：附加相同的参考但不做任何分配，并比较结果。

• 运行 5 — 收尾。将你最好的本地 768p 提示词提交到 2K 托管 API，看看 Context-IR 和再生成流程能增加什么。这个差异正是按秒计费所购买的价值，也是唯一能如实为混合工作流定价的方式。

常见问题

我能否从本地权重中获得 2K？

不。开源包是 H3-Base，其原生画布短边为 768 像素（最高 768×1344）。2K 来自 H3-Regenerate-2K，这是公司保留在托管 API 上的一个独立的上下文内再生模块。你可以使用任何通用放大器在本地放大，但那是与 H3 自身的再生流程不同的操作，无法与之匹配。

为什么相同的提示词在 API 和 ComfyUI 中表现不同？

因为 API 会先运行 H3-Context-IR。它读取你的文本和参考内容，推理它们之间的关联，然后向 H3-Base 传递一条结构化、增强过的指令。本地没有这一环节——H3-Base 接收的是你的原始文字。一个模糊的提示词之所以能通过 API 产出合格片段，靠的是某个你并未安装的预处理器在补救，因此文档中的提示词格式对本地用户的重要性远高于 API 用户。

[0s-2s] 时间码模板是错误的吗？

这不是随附指南所要求的内容。该公司的VIDEO_PROMPT_WRITING_GUIDE_base_en.md按[镜头N]块组织，不给镜头1设置时间戳，并将后续剪辑表示为绝对时间（"在00:03.500处，画面切换到……"）。它也没有负面提示（negative-prompt）部分，因此流行模板中的"禁用转场"列表是社区添加的。话虽如此，实践者报告称使用时间码形式在API上取得了不错的结果——这很可能是因为Context-IR对其进行了规范化。我们的解读是：在本地权重上使用文档化格式，不要把API结果归功于时间码括号——那些结果可能是预处理器的功劳。

美国或欧盟的公司能否将开放权重用于商业用途？

我们读到的许可证文本将欧盟、英国、韩国和美国排除在适用地区之外，而且这一排除条款明确涵盖输出和权重。对于在这些地区的商业部署来说，这是一个严重的障碍，而且这是一个法律问题，而不是技术问题——请自行阅读许可证和问答文件，并寻求法律意见。托管API受平台自身条款的约束，而非社区许可证，因此值得单独评估，而不是想当然地认为它受到同等限制。

提交前要检查什么

H3 对特定类型的工作来说性价比异常出色：{{1}}短小、声音设计精良、参考一致的片段，且你愿意为此编写真正的分镜表{{/1}}。它对你提问的方式要求异常苛刻。有三件事值得你亲自验证，因为它们变化最快：{{2}}fal 之外是否会出现更多推理提供商（这才是降低每秒价格的关键）、ComfyUI R2V 模板是否会从两个参考槽位扩展到该模型的九个，以及一旦有人用本地权重做受控对比，社区的时码习惯与文档化的镜头分块格式哪个会胜出{{/2}}。{{3}}目前还没人发布这样的对比。在那之前，仓库里的手册是更稳妥的选择——它就在你已经花了 42 GB 下载的数据里{{/3}}。