# 图生视频（I2V）与参考生视频（Ref2V）：概念差别，以及 LTX-2.5 与 MiniMax H3 的取舍

> **本文性质**：技术选型参考文档，不是插件契约的一部分。
> 插件本体保持**模型无关**——只说能力（`video.image2video` / `video.reference2video`），模型名只出现在工作流清单里。
> 因此本文里的模型名（MiniMax H3 / LTX-2.5）**不得**被写进 skill 流程、prompt 模板或工具契约；换模型 = 换 / 加一份 workflow JSON。
>
> **数据来源**：① 本机单卡 Ampere（sm_80）+ ComfyUI 0.33.3 实测（`docs/minimax-h3-video-benchmark.md`，H3 侧）；② 两家官方文档 / 模型卡 / 官方博客（分辨率、时长、语言、许可）；③ 社区实测（LTX 本地侧 VRAM 与耗时，非本机、非官方，已标注）。
> **未做的**：两个模型**同 prompt、同参考图、同 seed 的 A/B**还没跑过——所以「谁更一致」是机制推断 + 公开证据，不是本机实测结论。文末 §10 列了补齐这张表的最小实验。

---

## 0. 三十秒结论

| 问题 | 答案 |
|---|---|
| I2V 和 Ref2V 的本质区别？ | **I2V 锁"一个端点"，Ref2V 锁"一个身份/角色"**。前者管住这一镜的首帧（或首末帧），后者管住"这是谁"以及"从哪张卡来"。 |
| 什么时候用 I2V？ | 你**已经有一张成图**（分镜图 / 上一镜末帧 / 品牌原始素材），要的只是"让这张图动起来"，且构图不能变。 |
| 什么时候用 Ref2V？ | 角色要**换场景、换机位、换景别**，或者一个镜头里要同时出现**多个已知角色/场景/道具**。 |
| 一部片子该只用一种吗？ | 不该。主流做法是**两头都用**：跨场景的新镜头用 Ref2V 锚身份，同场景续接镜/转场镜用 I2V 首末帧锁构图。 |
| 角色一致性谁强？ | **H3 Ref2VA 机制上更强**：独立的参考 checkpoint + 最多 9 图/3 视频/3 音频的多模态绑定，官方 prompt 规范里就有 `subject_definitions` / `retention_analysis` 这种"给每张参考图派角色"的结构。 |
| 最大分辨率/时长谁强？ | **LTX-2.5**：原生 4K、最高 50fps、API 侧单次最长 20s。H3 本地 768p（短边），2K 要走未开源的 `H3-Regenerate-2K`。 |
| 生成速度谁强？ | **LTX-2.5**（同规模下）。本机 H3 768p 20 步成片档 **≈395s / 5.2s 一镜**；LTX 蒸馏档在 24–32GB 消费卡上按**秒级~分钟级**出 4–5s 720p 片段（旁证，非本机）。 |
| 那本插件该用谁？ | **默认继续用 H3**（已接入、带原生音频与音画同步、有本地实测阶梯）；LTX-2.5 是**接入候选**，收益在速度/分辨率/多镜一次生成，代价是 35GB+ 模型体积、额外 IC-LoRA 才能做参考绑定、以及一套没跑过的实测。 |

---

## 1. 先把两个概念掰干净

### 1.1 I2V：把一张图当作"端点"

- **输入契约**：文本 + 一张（或两张）图；图被**编码进潜空间的指定帧位置**（首帧、末帧，或两端）。
- **不变量**：**这一镜的开头（和结尾）像素级构图**。首帧长什么样，成片第 0 帧就该长什么样。
- **模型怎么"理解"这张图**：它是"要给这个画面补上时间维"，而不是"要从这张图里提取一个角色"。所以它天然继承首帧里的**一切**——身份、服装、光照、镜头、场景、甚至画错的地方。
- **典型用途**：分镜图动起来、上一镜末帧续接、首末帧串成一个"转场镜"、品牌物料（LOGO / 包装 / UI）不许重绘只能动。
- **失效模式**：① 你想要的机位首帧里没有 → 模型只能**编造**，接缝处立刻穿帮；② 两个端点差异过大（换装换景换光）→ 有限的时长全花在"变形过渡"上；③ 首帧里的错误（多手指、糊脸、图上文字标注）会被**原样继承并放大**。

### 1.2 Ref2V：把图当作"角色/素材的档案"

- **输入契约**：文本 + **一份或多份参考素材**（图 / 视频 / 音频），然后在 prompt 里**声明每份素材的身份和作用**。参考素材不占用目标视频的任何一帧——它是一份"casting 资料"。
- **不变量**：**"这是谁 / 这是什么 / 用谁的声音"**。构图、机位、景别、环境由 prompt 重新指定。
- **模型怎么"理解"这些图**：它是"从这批素材里抽取可复用的属性（身份、几何、材质、风格、音色、运动节奏），再去生成一个**全新的镜头**"。
- **典型用途**：同一个角色出现在新场景 / 新机位；同一个商品在多个广告布景里复用；把一段运镜视频当运动参考；把一段音频当音色参考。
- **失效模式**：① **参考素材之间的冲突**（两张图脸不一样、光不一样）→ 结果被两边拉扯，需要显式写"脸以图 1 为准"；② 参考图里的**非身份内容被一起搬进成片**——多视图拼图里的第二个人、图上的角色名/`FRONT VIEW` 标注、水印（本插件实测：**在 prompt 里声明"同一角色多角度"完全无效**，唯一解是只传单视图）；③ 参考"强度"过高时，模型倾向复刻参考图的构图，于是你得到一个"新场景里的原角度"，而不是真机位变化。

### 1.3 一张对照表

| 维度 | I2V（`video.image2video`） | Ref2V（`video.reference2video`） |
|---|---|---|
| 输入的形状 | 1–2 张图，**有序、位置敏感**（首帧 / 末帧） | N 份素材，**按角色声明**（身份 / 场景 / 风格 / 运镜 / 音色） |
| 参考图进不进成片 | **就是成片的一部分**（第 0 帧 / 末帧） | **一帧都不进**，只贡献属性 |
| 保的是什么 | 构图、光照、镜头、场景（"这一镜的样子"） | 身份、几何、材质、音色（"这是谁/什么"） |
| 机位自由度 | ≈0（首帧定了就是定了） | 高（prompt 指定新机位） |
| 跨场景能力 | 弱（跨场景串末帧会强行把上一镜的环境拖进来） | 强（本来就是为了换场景） |
| 多角色同框 | 基本没法控制（首帧里有几个就几个） | 可以按 `Subject N` 分别绑定 |
| 音频参考 | 不涉及 | H3 Ref2VA 支持音频参考（音色 / 复用 BGM） |
| 成本结构 | 便宜一点（本机实测 i2v 比 ref2v 高**约 6%**：多一次首帧编码） | 略贵（多一份/多份参考编码） |
| 提示词重心 | **运动路径**：从这张图**怎么动到**下一秒 | **新镜头的规格**：机位、动作、环境、声音；**别复述参考图里已经有的外观** |
| 失败长相 | 接缝穿帮、身份在运动中漂移、首帧错误被放大 | 参考内容"污染"（多一个人 / 图内文字入画）、身份被拉扯、构图被参考图锁死 |
| 最省事的用法 | 分镜图直接动 / 上一镜末帧续接 | 单视图角色卡 + 场景卡绑定，一次生成一个新镜头 |

### 1.4 为什么一部片子通常两种都要

```
跨场景新镜头  ──Ref2V──▶  角色卡 + 场景卡绑定       （锚身份）
   │
   └─ 同场景续接/转场 ──I2V──▶  上一镜末帧 → first_frame_node  （锁构图，省一次"重新描述"）
                                  上一镜末帧 + 下一镜首帧 → 生成真正的过渡镜
```

- **跨场景只用 Ref2V**：本插件实测与官方文档一致——**跨场景不要带上一镜末帧**，否则上一镜的环境会被拖进新场景。
- **同场景只用 I2V**：同一条机位轴内的运动、续接、转场，用末帧串联比重新描述一遍又快又稳。
- **这就是插件里两个 capability 并存的原因**，不是二选一。

---

## 2. 两个模型在架构上就不一样

| | **MiniMax H3** | **LTX-2.5** |
|---|---|---|
| 形态 | 通用 omni-modal 生成系统，**按任务拆 checkpoint** | 单一视频+音频基座，**任务靠条件节点/适配器区分** |
| 参数规模 | H3-Omni-Transformer **33B dense 单流**（约 13B 在 AdaLN 分支，推理可缓存不加载） | **~22B DiT** 家族（dev / distilled 两版） |
| 文本编码器 | Qwen3-VL-32B（取第 50 层 hidden state），tokenizer 加 `<d>` 等特殊 token | **自研 Gemma 4 12B** 文本编码器（官方称长 prompt 不掉子句） |
| 视觉 VAE | f16t4d24（空间 16×、时间 4×、24 通道） | 视频 VAE + **Diffusion Video Decoder**（替代常规 VAE 解码） |
| 音频 | **独立 H3-AudioVAE**，32 kHz 立体声，联合预测 | **独立音频 VAE**，与视频一次前向联合产出 |
| 官方输入口径 | ≤9 图 / ≤3 视频（每段 2–15s）/ ≤3 音频（须随图或视频，不能单独），总文件 ≤12 | T2V / I2V / FLF2V / A2V；参考素材走**适配器**（见下） |
| 官方输出口径 | 4–15s、24fps、短边默认 768、**最高 2K**（需 `H3-Regenerate-2K`） | **最高 4K、最高 50fps**、API 侧最长 20s（变体/分辨率相关） |
| 多镜一次生成 | 官方推荐"**多镜写在一个 prompt 里**"（`[Shot N]`，H3-Context-IR 统一编排） | **Native multi-shot**（一次生成多个相连镜头，跨剪辑保角色/场景/光/声） |
| 开源完整性 | 开源 H3-Base 两个 checkpoint；**H3-Context-IR（提示词预处理）与 H3-Regenerate-2K（2K 重生成）未开源**，官方给 API 与 Prompting Guidance | **权重全开源**（transformer / TE / VAE / duration head / upscaler），dev 是微调基座 |
| 参考绑定机制 | **专用 checkpoint `Ref2VA`**，与 `FL2VA`（首末帧）是**两个不同的模型** | 基座**不含**专用 ref2v checkpoint；参考靠 **IC-LoRA 适配器**（Ingredients/角色-物体一致性、Union Control 等）+ 社区 MSR 多参考 LoRA |
| 许可 | MiniMax H3 Community License | LTX-2.x Community：**ARR < $10M 免费商用**，之上需谈 |

**一句话读法**：
- H3 是"**把不同任务做成不同模型**"——想要参考能力，就得为 Ref2VA 单独备一份权重（本机各 ~21GB，**切换 base 会重载，首次多花 10–20s**）。
- LTX 是"**一个基座 + 适配器**"——参考能力是"再挂一个 IC-LoRA + 条件节点"，灵活但要自己拼图。

---

## 3. 角色一致性

| 视角 | MiniMax H3 | LTX-2.5 |
|---|---|---|
| 机制 | **独立 Ref2VA checkpoint** + 多模态参考（图/视频/音频），官方 prompt 规范有 `subject_definitions` / `summary` / `retention_analysis` 三段**显式描述"每份参考担什么角色、保留到什么程度"** | 基座 I2V/FLF2V 保端点；跨场景身份靠 **IC-LoRA**:<br>• **Ingredients**：把角色/道具/场景摆在**一张参考图**上，成片保持这些元素一致（官方定位就是"跨多个片段保持角色一致"）<br>• **Union Control**（depth/canny/pose 控结构）<br>• 社区 **MSR 多参考 LoRA**：1–5 个参考槽（`pic1..pic4` + `background`），带学习到的槽位嵌入 |
| 可绑定的信息面 | **最宽**：身份 + 服装 + 场景 + **音色** + **运动/运镜**（视频参考）+ BGM 复用 | 身份/风格/道具/场景（图），结构（depth/pose/canny IC-LoRA），运动轨迹（Motion Control IC-LoRA，画样条） |
| 多角色同框 | 可以用 `Subject N` 分别绑定、分别写保留关系 | Ingredients 参考图可以摆多个角色；MSR 最多 5 槽 |
| 单视图 vs 多视图 | **必须单视图**：多视图拼图 = 成片多出一个角色；图内标注/水印会被当内容印进画面（本插件实测硬规则） | 同类风险（参考类模型通病）；MSR 是**每槽一张图**，天然避免了"拼图污染"——但 MSR 是社区扩展，不在官方主链路 |
| 跨剪辑连续性 | 官方推荐"多镜写进一个 prompt"，由一次性生成承载连续性 | **原生 multi-shot**：一次生成多镜、跨剪辑保角色/场景/光/声 |
| 文档口径的克制提醒 | `retention_analysis` 里允许标 `partially_preserved` / `weak_reference`——官方承认**不是所有参考都能被完整保留** | 官方对 IC-LoRA（如 Pixel Upscaler）明确写"**生成式、不是复原**"；一致性问题同样按"证据 + 复测"处理 |

**结论（机制层面）**：**H3 在"跨场景、多素材、带音色"的身份绑定上机制更完整**——参考是模型的一等公民，还有官方结构化的绑定语义。**LTX 的一致性更像"外挂"**：能做得不错（尤其 Ingredients），但要多备适配器、多拼一层图，且质量取决于所挂 IC-LoRA。

**但必须说清的边界**：以上是机制推断 + 官方定位，**没有本机 A/B**。真要下结论，按 §10 跑同 prompt / 同参考 / 同 seed。

---

## 4. 最大分辨率与时长

### 4.1 官方口径

| | MiniMax H3 | LTX-2.5 |
|---|---|---|
| 分辨率 | 短边默认 **768**；支持 21:9 / 16:9 / 4:3 / 1:1 / 3:4 / 9:16 等；**2K 需 `H3-Regenerate-2K`**（未开源，走 API，且它靠"用上下文重生成"而非超分——好处是能恢复小字和细节） | **720p / 1080p / 1440p / 4K**，横竖版均可（`1280x720` … `3840x2160` / `2160x3840`） |
| 帧率 | **24 fps**（固定） | **24 / 25 / 48 / 50 fps** |
| 单次时长 | **4–15s** | API：fast 720p/1080p 最长 **20s**（24/25fps）；48/50fps 与 1440p/4K 上限 10s；Pro 6/8/10s |
| 时长与分辨率联动 | — | **>10s 掉到 720p/1080p 且 24/25fps** |
| 参考视频/音频时长 | 每段 2–15s，合计 ≤15s | A2V：输出长度跟随输入音频 |

### 4.2 本机实际能跑到哪（H3 侧）

| 档 | 分辨率 | 备注 |
|---|---|---|
| 画布推导默认 | 质量档长边 1344 / 快速档长边 832，snap 32 | `settings.aspectRatio` 决定比例，支持 16:9 / 9:16 / 1:1 等 |
| 清单允许的比例 | 16:9 / 9:16 / 1:1 | 见 workflow 的 `constraints.aspectRatios` |
| 长度上限 | `maxDurationFrames: 310`（24fps ≈ 12.9s） | 帧数**步进 17**，`124` ≈ 5.17s |
| 实测分辨率阶梯 | 832×480 → 1024×576 → 1344×768 | 成本 **∝ token^1.5**，token ∝ 宽×高×帧数 |

> **一句话**：**LTX-2.5 在"分辨率上限 / 帧率上限 / 单次时长"三个格子上全面胜出**，而且 4K/50fps 是**开源权重路径**就能碰到的（受显存与量化档限制），而 H3 的本地开源部分**止步 768p、24fps**，2K 在闭源模块里。

---

## 5. 生成速度

### 5.1 H3：本机单卡 Ampere（sm_80）实测，124 帧 ≈ 5.17s 一镜

| 档 / 工作流 | 分辨率 | 端到端 | 折算 |
|---|---|---|---|
| `fast`（4 步 LoRA） | 832×480 | **24.6s**（ref2v）/ 26.1s（i2v） | ≈4.8 s 计算 / s 成片 |
| `fast` 4 步 LoRA 跑 768p（不配对格） | 1344×768 | 94.8s | 仅作构图预演，材质偏糊 |
| `balanced`（8 步 768p LoRA + shift 6/3 + euler） | 1344×768 | **166.3s**（ref2v）/ **177.3s**（i2v） | 日常主力 |
| `balanced` + Sol-Attn | 1344×768 | 136.3s / 130.5s | 1.23–1.36× |
| `balanced` PDD nfe=8（无蒸馏 LoRA） | 1344×768 | 184.7s / 178.8s | 细节量**高于**成片档 |
| `quality`（20 步无 LoRA） | 1344×768 | **396.6s** / 394.8s | 成片档 |
| `quality` + Sol-Attn | 1344×768 | 311.2s / 314.7s | 1.25–1.27× |

**本机速度律**：`端到端 ≈ 固定项(~19s) + 步数 × 单步成本`，单步成本 ∝ token^1.5 ∝ (宽×高×帧数)^1.5。
⇒ **想快：先降分辨率，再降步数，最后才动注意力内核**。

### 5.2 LTX-2.5：公开数据（**非本机**，量化档/卡型/分辨率各不相同，不可与上表直接比）

| 环境 | 产出 | 耗时 | 来源类型 |
|---|---|---|---|
| 2× NVIDIA GB200 | 10s / 720p | **6.8s** | 厂商头条（天花板演示，别当预期） |
| RTX 5090 32GB | 4s / 720p / 24fps | **≈25s** | NVIDIA 官方指南 |
| RTX 5090 32GB | 8s / 720p | **≈3 min** | 同上：超出 32GB，开始权重流式换入换出 |
| RTX 3090 24GB | 5s | **≈2.5 min**（distilled，无 SageAttention） | 社区报告 |
| RTX 4090 24GB | 5s | int8 全程常驻 **22.67 GiB**（卡 24 GiB），10s 可能在 VAE 解码处卡死 | 社区测量 |
| 社区横向对比 | — | LTX-2 家族约 **3–4× 于 Wan 2.2 / HunyuanVideo** | 社区汇总 |

**特征差异**：
- H3 的时间**随步数线性、随分辨率超线性**，行为可预测，适合做阶梯规划（本机已有完整阶梯表）。
- LTX 的时间**在显存边界处会阶跃**（权重流式换入换出：4s 25s → 8s 3min）。**它的瓶颈常常不是算力，而是"放不放得下"**。
- LTX 官方**最低要求写的是 32GB+ 显存、推荐 A100/H100**；「16GB 也能跑」是 int8 + 权重流式 + 32GB 以上系统内存的社区路线。

---

## 6. 音频与字幕

| | MiniMax H3 | LTX-2.5 |
|---|---|---|
| 音频 | **原生立体声 32 kHz**，与视频联合生成；支持**音频参考**（音色 / 复用 BGM） | **原生同步音频**，与视频一次前向产出；另有"A2V 音频驱动视频"、Video-to-Audio 拟音、Dub-It（beta，重配语音并保说话人外观/音色） |
| 对白语言 | **官方稳定支持 11 种**：中/英/日/韩/法/德/意/葡/俄/西/阿；其他语言"程度不一" | 未见同口径语言清单 |
| 画面内原生字幕 | 本插件实测：**支持**——字幕要求写进 video prompt 末尾即可，无需后期叠加（`constraints.supportsSubtitles: true`） | 见 §6.1：**模型无原生字幕参数**；能力上"文字渲染得清楚"（新解码器），实践上等价于"在场景里生成一块有字的物体"，不是字幕轨 |
| 收尾工作流 | 直接出带音轨 mp4（本机 `SaveVideo` + `VAEDecodeAudio` 链路，各档实测音轨均在） | 同上，音频 VAE 解码后封装 |

**这一格 H3 更"开箱即用"**：中文对白 + 画面内字幕 + 音画同步，是它在本插件里被选为默认的实际原因。

### 6.1 LTX-2.5 到底有没有字幕功能？（结论 + 依据）

**结论：没有"字幕"这个特性，只有"能画清文字"这项渲染质量。想要字幕，LTX 侧得靠 prompt 造字 + 后期，不是一条原生能力。**

必须把三层东西分开，混在一起最容易误判：

| 层 | 是什么 | LTX-2.5 的情况 |
|---|---|---|
| **① 模型的原生能力** | 生成时就带字幕轨 / 有字幕参数 | ❌ 没有。官方 API 支持矩阵（分辨率 / 帧率 / 时长 / `camera_motion` / `generate_audio` / `last_frame_uri` / 自动时长）**没有任何字幕或文字参数**；官方 Prompting Guide 的 6 个必填要素（镜头 / 场景 / 动作 / 角色 / 运镜 / 音频）里**也没有"文字画面"这一类** |
| **② 模型渲染文字的质量** | 画面里出现文字时，字写不写得清 | ✅ 官方明确宣称：**新的 Diffusion Video Decoder 让 "on-screen text stays legible"**（faces 更锐、文字更清楚、快速运动少拖影），且称这是 2.5 相对 2.3 保真度提升的**最大贡献项**。这是**质量改善**——针对招牌、书页、包装、UI 这类"世界里本来就有的字" |
| **③ 产品级字幕功能** | 编辑器 / 时间轴上的字幕 | ⚠️ 有，但**不在模型里，也不在 ComfyUI 链路里**：LTX Studio（商业 Web 产品）提供 subtitle editor / caption 工具。那是**后期工具**，跟"模型能不能直接吐字幕"是两件事——别的模型同样可以套这个工具 |

**那 LTX-2.5 到底能不能出带字幕的画面？** 能，但属于**借用场景渲染**：在 prompt 里写"画面底部居中显示一行白字中文「……」"，让它当作**画面元素**画出来。代价是——这**不是字幕轨**：没有时间轴、没有断行控制、没有字体锁定，本质是"和画面一起被生成的一块文字"，跟我们做片时"按对白时间轴烧字幕"的诉求不是一回事。要真字幕，稳妥路径仍是**后期叠加**（ffmpeg 烧轨 / 剪辑器），而这恰好是 H3 不需要额外做的部分。

**为什么本插件里 H3 是字幕方案**：H3 的 workflow 清单显式带 `constraints.supportsSubtitles: true`，且本机实测字幕随画面原生生成（写进 video prompt 末尾即可）——这是**核对过的能力**，不是推断。

**未验证的部分（别过度承诺）**：
1. **中文/CJK 字形与多帧稳定性**：官方说的 "legible text" 未给语言口径；LTX 侧**没做过**中文长句、多帧一致、字体不漂的验证。
2. **时间轴语义**：LTX 侧没有"第 N 秒出现哪句字幕"的原生控制。
3. **A/B**：H3 原生字幕 vs LTX 借场景渲染字幕，两边没有同条件对照。
⇒ 因此本文的立场是：**要字幕就用 H3 或后期，别指望 LTX 的"文字清晰"变成字幕能力。**

---

## 7. 部署成本、显存与许可

| | MiniMax H3（本地） | LTX-2.5（本地） |
|---|---|---|
| 权重体积 | 两个 base 各自约 **21GB**（int8 convrot 实测档），**ref2v 与 i2v 各一份**，切换需重载 | int8-convrot transformer ≈ **21.5GB**，**整套（transformer + Gemma 4 12B TE + 视频 VAE + 音频 VAE）预留 35GB+ 磁盘**；bf16 transformer ≈ 42GB |
| 显存 | 本机大显存卡上跑满档无压力（实测档常在几 GB~十几 GB 空余波动）；换 base 有 10–20s 重载成本 | 官方**最低 32GB+**、推荐 A100/H100；24GB 卡 int8 实测 22.67 GiB **刚好塞下**，长片段会 spill |
| 系统内存 | 本机系统内存充足（数百 GB 级） | 社区低显存报告要求 **32GB 起**，极低显存路线（6GB 卡）靠 **44GB** 系统内存 |
| 许可 | H3 Community License | LTX-2.x Community：ARR < $10M 免费商用 |
| 微调 | 权重开源可微调；但 **Context-IR / 2K 重生成不开源** ⇒ 想复刻官方最佳质量需要接它的 API | 全链路开源，**有 LTX Trainer**（LoRA / IC-LoRA 训练），dev 就是微调基座 |
| 生态 | ComfyUI 官方模板 + 官方 prompt 规范（本插件已把规范落成 `h3-prompt-writing` skill） | ComfyUI day-0 原生节点 + 官方示例工作流 + **IC-LoRA 矩阵**（Control / Ingredients / In-Outpainting / HDR / Dub-It / Upscaler…）+ 社区 MSR |

---

## 8. 逐维度打分（tick = 该维度更优，`−` = 未见明确证据）

| 维度 | H3 | LTX-2.5 | 说明 |
|---|:--:|:--:|---|
| 参考绑定语义的完备度 | **✓** | − | H3 有专用 Ref2VA + `subject_definitions`/`retention_analysis` 结构化绑定；LTX 靠外挂 IC-LoRA |
| 多素材绑定（含音色/运镜） | **✓** | − | H3 图/视频/音频三类参考，最多 12 个文件 |
| 跨剪辑连续性 | − | **✓** | LTX 原生 multi-shot；H3 靠"prompt 里写多镜" |
| 分辨率上限 | − | **✓** | LTX 4K 开源可达；H3 本地 768p、2K 在闭源模块 |
| 帧率上限 | − | **✓** | LTX 最高 50fps；H3 固定 24fps |
| 单次时长上限 | − | **✓** | LTX 最长 20s；H3 4–15s（本机清单上限 310 帧） |
| 速度（同规模、消费卡） | − | **✓** | LTX 蒸馏档在 24–32GB 卡上秒级~分钟级 4–5s 片段；H3 本机 768p 主力档 ≈166s / 成片档 ≈395s |
| 速度可预测性 / 有本地实测阶梯 | **✓** | − | H3 在本机有 4 档 × 3 分辨率 × 加速件的完整阶梯；LTX 未在本机验证 |
| 消费卡可达性（低显存） | − | **✓** | LTX int8 在 24GB 卡上有实测；H3 本机档位未在低显存验证 |
| 原生音频 + 中文对白 + 画面内字幕 | **✓** | − | H3 11 语言稳定支持、本机实测字幕可用 |
| 本插件接入成本 | **✓** | − | H3 已接入并实测；LTX 需新增 workflow JSON（+ 可能要 IC-LoRA 节点包） |
| 微调 / 定制生态 | − | **✓** | LTX 有 Trainer + IC-LoRA 训练路径 |
| 单机默认路径的"省心度" | **✓** | − | H3：能力注册表 + 两档三档 + 单视图硬规则已在 skill 生效；LTX 的多参考要走自定义节点 |

**读法**：这不是"谁更好"，而是**"谁更适合哪一类镜头"**。

---

## 9. 决策建议

### 9.1 按镜头类型选

| 场景 | 建议 |
|---|---|
| 分镜图直接动起来 | **I2V**（`first_frame_node`） |
| 同场景续接、机位轴内的下一拍 | **I2V**（`first_frame_node = 上一镜末帧`） |
| 跨场景转场 | **I2V 双端点**：抽前一镜末帧 + 后一镜首帧 → 生成真正的过渡镜 |
| 跨场景新机位、角色要换环境 | **Ref2V**（单视图角色卡 + 场景卡） |
| 一镜里多个已知角色 / 道具要同时保真 | **Ref2V**（H3 更擅长；LTX 走 Ingredients） |
| 品牌 LOGO / 包装 / UI / 已确认物料 | **I2V 首帧锁定**，绝不重绘；没有可用原件时降级为精确文字锚点，不仿造 |
| 需要 4K / 高帧率 / 一次出多个相连镜头 | **LTX-2.5**（若已接入且显存够） |
| 需要中文对白 + 音画同步 + 画面内字幕 | **H3** |

### 9.2 给本插件流程的实操结论

1. **两个 capability 并行使用**，不要试图用一种统一：`video.reference2video` 负责跨场景锚身份，`video.image2video` 负责同场景锁构图/转场。
2. **参考图硬规则对两个模型都成立**：只传单视图、图内零文字、不把多张单视图拼成一张、多角度分别占 `ref_nodes` 槽位。
3. **要让某条镜头换成 LTX 时**：不改 skill、不改工具，只加一份 workflow JSON 并把 `preferred`（或显式 `workflow=`）指过去；prompt 需要退回**通用自然语言**（H3 的结构化六段式**只对 `minimax-h3-*` 前缀生效**）。
4. **跨模型不要混剪同一个"身份链"**：不同模型的采样轨迹、身份编码方式不同，同一部片子里逐镜换模型会放大身份漂移。要换就整段换，并且**换之前先跑 §10 的一致性对照**。

---

## 10. 还没验证的（补齐这张表的最小实验）

下面这张表一旦跑完，本文 §3 / §5 的推断就能变成结论。建议的实验设计：

| 实验 | 设计 | 要测什么 |
|---|---|---|
| **A/B 身份一致性** | 同一张单视图角色卡 + 同一段"换场景新机位"的 prompt + 同 seed，H3 `video.reference2video` vs LTX-2.5（IC-LoRA Ingredients / MSR）各 3 个场景 | 人脸/服装/材质是否漂移、是否出现参考图外的多余角色、构图是否被参考图锁死 |
| **端点保真度** | 同一张成图 + 同 prompt，H3 `video.image2video` vs LTX I2V | 第 0 帧与首帧的像素差、运动中身份漂移速度 |
| **速度同条件对照** | 固定 5s / 16:9 / 768p 一镜，H3 `balanced` vs LTX distilled 8 步 | 端到端耗时、显存峰值、显存边界处是否出现阶跃 |
| **多镜连续性** | 一个 3 镜小场景，H3「多镜写在一个 prompt」 vs LTX native multi-shot | 跨剪辑的角色/光照/环境连续性、声音连续 |
| **失败成本** | 同一需求各跑 5 次，记录"可用产出率" | 哪个更省钱——**比较的是可用率，不是单次画质** |

> 未做这件事之前，本文所有"更优"都请按**机制优 / 公开证据优**来理解，而不是本机 A/B 结论。

---

## 附：参考来源

- 本机实测（H3 侧全部数据）：`docs/minimax-h3-video-benchmark.md`、`docs/minimax-h3-acceleration-lora.md`
- 插件侧能力与档位契约：`docs/tier-strategy-design.md`、`docs/workflow-contract.md`、`README.md` §内置工作流清单
- MiniMax H3 官方开源公告（架构、输入输出规格、模块划分、许可）：[minimax.io/news/minimax-h3-open-source](https://www.minimax.io/news/minimax-h3-open-source)
- MiniMax H3 系 ComfyUI 官方教程：[Comfy-Org/docs · minimax-h3](https://github.com/Comfy-Org/docs/blob/main/tutorials/video/minimax/minimax-h3.mdx)
- Ref2VA vs FL2VA 的实用取舍（含"每份参考派一个角色"的写法）：[seedance.tv/blog/minimax-h3-ref2v-vs-fl2va](https://www.seedance.tv/blog/minimax-h3-ref2v-vs-fl2va)
- H3 参考图的角色标注实践：[wavespeed.ai · How Do I Use Reference Images with the MiniMax H3 API](https://wavespeed.ai/blog/minimax-h3/minimax-h3-reference-images-api/)
- LTX-2.5 ComfyUI day-0（Diffusion Fidelity Rendering / 新解码器 / 原生 multi-shot / Gemma 4 12B / 自动时长）：[blog.comfy.org/p/ltx-25-day-0-support-in-comfyui](https://blog.comfy.org/p/ltx-25-day-0-support-in-comfyui)
- LTX-2.5 API 支持矩阵（分辨率 × 帧率 × 时长、自动时长、计费）：[docs.ltx.io/models/ltx-2-5](https://docs.ltx.io/models/ltx-2-5)
- LTX-2.5 系统要求（最低 32GB 显存、推荐 A100/H100）：[docs.ltx.io/system-requirements](https://docs.ltx.io/open-source-model/getting-started/system-requirements)
- LTX IC-LoRA 适配器全清单（Ingredients / Union Control / Motion Control / Upscaler / In-Outpainting / HDR / Dub-It）：[docs.ltx.io/ic-lo-ra-adapters](https://docs.ltx.io/open-source-model/integration-tools/ic-lo-ra-adapters)
- LTX-2.5 本地 VRAM 与耗时实测（24GB int8 22.67 GiB、5090 25s/4s、3090 ≈2.5min/5s）：[runaihome.com · LTX-2.5 for Local AI Video in 2026](https://runaihome.com/blog/ltx-2-5-local-ai-video-hardware-guide-2026/)
- LTX 社区多参考扩展（MSR：1–5 槽位、槽位嵌入、负时间偏移）：[github.com/liconstudio/ComfyUI-LTX2.5-MSR](https://github.com/liconstudio/ComfyUI-LTX2.5-MSR)
- LTX-2.5 发布概览与许可（ARR < $10M 免费商用、distilled 8 步 CFG=1）：[llm-stats.com · LTX-2.5 Fast & Pro](https://llm-stats.com/blog/research/ltx-2.5-launch)

*文档日期：2026-09-14 · H3 侧数据为单机单卡实测；LTX 侧为官方文档与社区公开数据，两者未经同条件对照。*