LTX-2 音视频联合 DiT 拆解：单模型直出同步音视频

Lightricks/LTX-2 的定位写在 README 第一句：“the first DiT-based audio-video foundation model that contains all core capabilities of modern video generation in one model”。市面上多数方案是"先出无声视频、再用别的模型配音"，两个模型各画各的时间线，口型和动作对不上靠后处理补救。LTX-2 把音频和视频放进同一个 DiT 骨干里联合去噪，声音和画面共享同一条时间轴，这是它与两阶段拼接方案的本质区别。

这篇文章拆四件事：双流架构怎么组织（论文口径）、推理管线怎么选（仓库现状）、显存和速度怎么省（文档口径）、商用边界在哪（许可原文）。文中 GitHub 读数与仓库结构核对至 2026-10-03 的 main 分支；正文另注明 LTX-2.3（本文初稿时的推荐模型）与 LTX-2.5（当前推荐模型）的差异，两代权重文件不通用。

一、架构：14B 视频流 + 5B 音频流

论文（arXiv:2601.03233，2026-01-06）给的关键数字是 19B 参数：一条 14B 的视频流加一条 5B 的音频流，通过双向音视频交叉注意力耦合。权重文件名里的 22b 与论文的 19B 并存——前者是发布文件的命名口径，后者是论文对双流骨干的统计口径，本文不强行调和，引用时各自注明出处。

每个双流块按固定顺序做四步：同模态自注意力、文本交叉注意力、音视频交叉注意力、前馈网络。视频流用 3D RoPE 编码时空位置，音频流用 1D 时间 RoPE，共享的时间步条件走跨模态 AdaLN。音频流只拿 5B，参数大头给了视频——论文的解释是这样能保证视觉质量不因联合训练而妥协，同时音视频交叉注意力仍让每个视频块都能"听到"每个音频块。

文本侧，论文用的是 Gemma3-12B 的特化版：在骨干上做两层加工——多层特征抽取加专门的多 token 预测块——因为 decoder-only 模型的末层嵌入对语音的音素和语义精度不够。这条线索在推理仓库里能看到延续：现在的 LTX-2.5 要求用 LTX 特调的 gemma4-12b-ltx-v1（Gemma 4 12B 加投影打包成单文件），README 明确说 Google 原版 Gemma 4 不能替代，加载时会校验编码器版本与训练时一致。

引导机制上，论文引入 modality-CFG（模态感知的 classifier-free guidance），视频和音频各自按模态算引导尺度，解决"一条 CFG 同时伺候两种模态"的对齐问题。仓库里 CFG/STG 参数按视频、音频分两组传（video_guider_params / audio_guider_params），就是这个设计的落地。

两个论文数字值得记住：H100 上 121 帧 720p、单步 Euler、CFG=1 的条件下，LTX-2（19B，音+视频）每步 1.22 秒，对比 Wan 2.2-14B（纯视频）每步 22.30 秒，约 18 倍差距；时长上限 20 秒连续立体声。开源排行榜（Artificial Analysis，2025-11-06 快照）上它的视觉流排 Image-to-Video 第 3、Text-to-Video 第 4——这些数字都是官方自报或特定时点快照，独立复测尚未见到，看的时候留个心眼。

二、从 LTX-2.3 到 LTX-2.5：两代权重怎么分

本文初稿（2026-06）写的是 LTX-2.3 时代：权重是单文件捆绑（transformer、双 VAE、文本投影打在一起），文本编码器 Gemma 3 另下。2026-08-11 的 v1.2.0 引入 LTX-2.5 支持，两代格局变成现在这样：

仓库文档明确两代文件不可互换，LoRA 只对训练它的那一带模型生效。老的 IC-LoRA（2.3 系列）留在 HF 上，但新项目应该从 2.5 的 IC-LoRA 家族起步——这个家族现在已经覆盖修复（Restore）、细节精化（Refine-Details）、透明通道生成（Alpha-Gen）、布局转渲染（Layout-To-Render）、SDR 转 HDR、上色（Colorization）、去模糊（Deblur）、去压缩（Decompression）、清版（Clean-Plate）、白天转夜晚等十几个用途。

主模型之外还有几个小件：video VAE 有两个解码器版本——扩散解码器（NADiffusionDecoder，质量更好但更慢更吃显存，natten extra 加速）和卷积解码器（轻量、零额外依赖）；audio VAE 供生成和解码声音的管线用；一个可选的 Duration Head，挂上后可以不传 --num-frames，让模型从 prompt 自己预测时长（--auto-duration MIN MAX 给出秒数区间）。

Quick Start 的完整下载约 66 GiB。显存吃紧时 README 给的组合是 --quantization fp8-cast --offload {cpu, disk}。

三、Pipelines：从 8 步原型到 DFR 生产线

仓库按"质量 vs 速度"把推理路径分了档。当前 README 的推荐顺序是：DistilledPipeline 做起点，DFRPipeline 做生产质量——注意生产推荐已经不是本文初稿时的 TI2VidTwoStagesPipeline，后者现在定位是"想要 CFG/STG 显式引导的两阶段"时的选择。

DFR 值得单独说。它复用蒸馏 transformer（与 DistilledPipeline 同一个权重，不要再传 dev 版），加一个 detailing IC-LoRA（Pixel Spatial Upscaler，强度硬编码 0.5）：stage 1 在半分辨率生成视频并按 8 帧边界的段网格铺生成关键帧槽，stage 2 以这些关键帧为条件在全分辨率重去噪。声音出自 stage 1，stage 2 的音频分支只为维持跨模态注意力，不再精修。

时间维度上 --temporal-upscalings {0,1,2} 每开一档播放帧率翻倍：121 帧 @ 24fps 约 5.04 秒的片子，两档后变 481 帧 @ 96fps，但时长仍是 5 秒——加密的是帧密度不是秒数。空间维度上 --spatial-upscalings 2 让 stage 2 停在半分辨率、用分块 epilogue 收尾，这是 4K 的推荐路径（4K 是 3840×2176 不是 3840×2160，尺寸要落在 64 像素网格上，开 2 时要落在 128 网格上）。多卡走 ltx_pipelines.dfr_mgpu，两阶段都是序列并行。

一次生成的完整路径：装好环境、按组件下完权重后，跑 uv run python -m ltx_pipelines.distilled，传五个组件路径加 --num-frames 121 --seed 42 和一段 prompt——README 的示例 prompt 是一段电影镜头式的口播描述，镜头、表情、台词、背景全都写在一句话里。输出先经过 video VAE 解码（DiffVAE 默认 chunked_eager 模式）、音频经 audio VAE + vocoder 解码，封装成一个带同步音轨的 mp4。换成 DFR 就多下一步：下载 detailing IC-LoRA，命令换成 ltx_pipelines.dfr_pipeline 并传 --detailing-lora，换来的是全分辨率的细节密度。跑 4K 时如果 stage 2 显存爆了，文档给的出口是 --spatial-upscalings 2 或 --offload cpu。

长视频方面，v1.4.0 给主流管线加了 --chunked：97 帧窗口 + 25 帧交接的滑窗生成，--chunk-blend-frames 控制接缝交叉淡化。基座 20 秒上限（论文口径）由此可以向上扩展。

四、优化：量化、注意力、编译、解码四条路

官方优化建议有六条，可归成四类：

量化。--quantization fp8-cast（bf16 权重加载时降精度，任意 FP8 GPU）和 --quantization fp8-scaled-mm（Hopper+ 原生 FP8 矩阵乘，需 fp8 checkpoint）之外，Blackwell（SM ≥ 10）现在多了 NVFP4 两档：nvfp4-cast 在线转、nvfp4-prequant 直接加载预量化 checkpoint。配合 PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True 使用。

注意力后端。现状与本文初稿时差别很大：B200 数据中心卡手动装 flash-attn-4==4.0.0b9（README 说明这是与 torch 2.9.1+cu128 验证过的版本，更新的 beta 在消费级 Blackwell 上有问题）；Hopper 装 FlashAttention 3 wheel；其余 CUDA 卡自动用 PyTorch SDPA——初稿时期的 xFormers 路径已从文档移除。强制指定后端是 Python API 选项（AttentionFunction.FLASH_ATTENTION_3/4），不是 CLI flag。

编译。torch.compile 是 opt-in 默认关。capture=true 自管 CUDA graph 捕获整个块循环，单卡需要 --offload cpu/disk（weight slot 复用）；max_video_tokens / max_audio_tokens 给多个捕获形状共享一个静态输入池。文档给了 token 预算公式：视频 token = ((帧数−1)/8+1) × (高/32) × (宽/32)，默认 1024×1536 下是 24,576。

DiffVAE 解码。这是 LTX-2.5 之后的显存大户。后端阶梯从高到低：CuTe DSL（仅 B200 数据中心卡，--diffvae-optimization blackwell_dsl）→ NATTEN（uv sync --extra natten，非 B200 的最快生产路径，注意这个 extra 是 Linux + CUDA 专属，Windows/macOS 自动跳过）→ Triton → eager。natten 钉在 0.21.7+torch2130cu132 配 torch==2.13.0，解码报非法内存访问先查这套版本而不是怀疑分块配置。DFR 永远走关键帧感知解码，4K 加时间档后通常是解码而不是去噪先爆显存。

梯度估计（gradient estimation）仍然有效：把 40 步的常规去噪循环换成 gradient_estimating_euler_denoising_loop（ge_gamma=2.0），20-30 步保住质量。显存充裕时关掉阶段间自动清理也能省时间。

一个提醒：本文初稿写过"选了 DistilledPipeline 就别叠加 fp8 + FlashAttn 一通乱开"，这句话当时是我自己的推断，官方文档没有这个警告，此处收回。文档真正给出的排布逻辑是明确的依赖关系：CUDA-graph 编译模式依赖 --offload，NVFP4 依赖 Blackwell 和 ltx-kernels，fp8-scaled-mm 依赖 fp8 checkpoint——按依赖检查，比凭感觉开关可靠。

五、许可：Community License 的真实边界

权重和代码都不是传统开源协议。仓库根的 LICENSE 指向两份 Community License：LICENSE-2（2026-01-05，适用 LTX-2 全系含 LTX-2.3）和 LICENSE-2_x（2026-08-11，适用 LTX-2.5 及之后）。核心条款两份一致：

• 年收入 ≥ 1000 万美元的实体，任何使用都须向 Lightricks 购买商业许可（联系 [email protected]），纯非商业用途除外。年收入按含子公司、关联公司的合并口径算。
• 非商业用途对商业实体的开口很窄：仅限非生产环境的测试、评估和非商业研发。
• SaaS 托管是明确允许的（许可原文点名 software-as-a-service），条件是把使用限制条款传导给下游用户、随分发附上许可副本。
• 微调权重、LoRA 等衍生物必须按同一许可分发；把它们转移给商业实体时，对方也须先取得付费许可。
• 生成物（Output）归用户，许可方不主张权利；但用户要对输入和输出负责。
• 有一整条 AI 法规合规义务：遵守 EU AI Act、加州 AI 透明法等，不得移除或绕过模型内嵌的水印、溯源、披露功能，违反可被吊销许可。许可方声明其意图是让 LTX-2.x 按 EU AI Act 第 53(2) 条作为自由开源通用 AI 模型对待。
• 两份许可的一个实际差异：旧版（LICENSE-2）对违约设定了双倍许可费的违约金条款，新版（LICENSE-2_x）改为按标准商业费率补缴。

选型时这条边界比 star 数重要得多：年收入千万美元以下的团队和个人可以自由商用产出物，之上的公司要么谈商业授权、要么把 LTX-2 限制在研发评估环节。

六、训练侧：ltx-trainer 与 80GB 门槛

仓库是 monorepo，三个包分工：ltx-core（模型实现与推理栈）、ltx-pipelines（上文十二条管线）、ltx-trainer（训练）。trainer 支持 LoRA、全量微调，条件框架覆盖文生视频、文生音频、图生视频、视频/音频扩展、内外绘、音视频联合 IC-LoRA 等模式，文档按 quick-start、数据集准备、训练模式、配置参考、排障分册组织。

硬件口径写在 trainer README：标准配置推荐 80GB+ VRAM（Linux + CUDA，CUDA 13+）；32GB 卡（如 RTX 5090）走低显存配置，开 INT8 量化等优化。模型布局两代不同：LTX-2/2.3/2.5 的 unified 布局是单文件 transformer + 双 VAE + vocoder 配 Gemma 目录，LTX 2.5 另有 split 布局按组件给文件。

一个容易被忽略的入口：仓库自带 .claude/skills/train-model skill，声明可以探测数据与硬件、选训练模式、预处理数据集、启动并监控训练——想定制相机运动或风格 LoRA 的话，这是个比直接啃配置文件更平缓的起点。

七、ComfyUI 与 API

ComfyUI 用户走 Lightricks/ComfyUI-LTXVideo 节点仓库（4,164 stars，活跃维护），README 的 Integration 一节只给这一个链接。不想自建推理的，官方 Demo 在 console.ltx.io/playground（旧域名 console.ltx.video 现在 301 过来），API 走 LTX 平台商业侧，本文不展开。

八、采用建议

谁适合现在上：需要在自有管线里出"带同步声音的视频"的团队——口播、短片、有声内容——且年营收入在许可门槛之下；已有 ComfyUI 工作流想接 LTX-2 的；想基于 IC-LoRA 框架定制控制（透明通道、HDR、布局转渲染）的。

谁可以等等或绕开：需要分钟级长视频的（滑窗能续，但每段仍受基座时长与接缝质量约束）；显存预算只有消费级单卡还想跑 22B 全量精度的（fp8 + offload 能压，但 DFR 4K 这类生产路径实际是高显存游戏）；被许可门槛覆盖的大厂（先谈授权）。

升级路径（给读过本文初稿、还在 LTX-2.3 上的读者）：换 LTX-2.5 组件化权重、换 gemma4-12b-ltx-v1 文本编码器、蒸馏 LoRA 从 384 换 450，旧 IC-LoRA 全部作废重选 2.5 系列；生产管线从 TI2VidTwoStages 切到 DFR；装依赖从 uv sync --frozen 改为 uv sync --extra natten（Linux/CUDA）。2.3 的检查点仓库仍在、管线仍兼容，迁移不必一夜完成，但 LoRA 不跨代意味着新老并行要养两套资产。

上手顺序：先跑 DistilledPipeline 把组件路径和输出格式跑通，再上 DFR 看质量差距，第三步按内容类型挂 IC-LoRA，最后才动量化、编译、DiffVAE 优化这些开关——每一档优化都有明确的前置依赖（第四节），按依赖开而不是按感觉开。

参考与延伸

• 仓库：github.com/Lightricks/LTX-2（9,577 stars，2026-10-03 读数）
• 模型权重：Lightricks/LTX-2.5（gated）· Lightricks/LTX-2.3
• 论文：arXiv:2601.03233（LTX-2: Efficient Joint Audio-Visual Foundation Model）
• ComfyUI 节点：Lightricks/ComfyUI-LTXVideo
• 官网与 Demo：ltx.io · console.ltx.io/playground
• Prompt 指南：ltx.io/blog/prompting-guide-for-ltx-2

本文事实核对基准：GitHub API 与 main 分支源码/文档（2026-10-03）、论文 arXiv:2601.03233 v1、HF 模型页当次读数、LICENSE 与 LICENSE-2_x 全文。未在上述来源中给出的训练超参、数据配比细节，本文不作推断；官方自报的排名与性能数字已标注时点与"自报"属性。