企业官网建设流程全解析

8GB 显存玩家的极限：LTX-2.5 的 INT8 量化 + 低显存模式实测清单

【免费下载链接】LTX-2.5项目地址: https://ai.gitcode.com/hf_mirrors/Lightricks/LTX-2.5

220 亿参数、一次前向就要吃掉几十 GB 权重的扩散 Transformer，和一张 8GB 显存的甜品卡，本来是两个世界的东西。但 LTX-2.5 把这件事变成了一道值得认真做的"内存工程题"：官方在 diffusion_models/ 目录里同时发布了 bf16、Comfy int8 + convrot、NVFP4 三档量化检查点，社区则用--lowvram、CPU Offload、分片拼接等手段把 8GB 的 RX 6700 XT 真正跑出了成片。本文不堆参数，直接给一份可复现的边界清单：量化、卸载、分块解码三件套各自管什么、在什么条件下失效，8G 与 12G 卡分别能守住哪一档分辨率与时长，以及每一步降级对应的画质代价。

一、先看货架：22B 模型的"瘦身梯度"长什么样

LTX-2.5 的仓库以"按组件拆分"的方式发布权重，Transformer（DiT）一个文件、文本编码器一个文件、VAE 一个文件，互不捆绑。这意味着显存预算可以按需裁剪，而不是为整个模型家族买单。Transformer 的量化梯度在 diffusion_models/ 下清晰可见：

同样的情况出现在文本编码器上：text_encoders/ 里 bf16 与 comfy-int8-convrot 两个版本并存。文本编码器是 Gemma 4 12B 级模型，体量与 DiT 相差无几，在低显存场景下它与 Transformer 是"二选一进显存"的关系。

按参数量粗算：22B 的 bf16 权重约 44GB、int8 约 22GB；12B 文本编码器 bf16 约 24GB、int8 约 12GB；视频 VAE 若干 GB。这个量级决定了：8GB 显存装不下任何一档的完整权重，任何低显存方案的本质都是"分层卸载 + 按需调度"，而不是把模型塞进显存。

二、三件套的适用边界：量化、Offload、分块解码

1. INT8 量化：ComfyUI 的专属通道

仓库里两个comfy-int8-convrot文件在 README.md 中被反复标注"ComfyUI only— not forltx-pipelines/ PyTorch"。这是一个经常被忽略的边界：INT8 检查点是给 ComfyUI 工作流准备的，走 Python 的ltx-pipelines路径时，即使你下载了 int8 文件，加载器也不会识别它。

在 ltx-pipelines 侧，官方给出的等价物是运行时在线量化--quantization fp8-cast——加载 bf16 权重时降为 FP8、推理时再临时升回，官方文档明确它"works on any GPU with FP8 support"，且建议配合PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True使用以减少显存碎片。也就是说，两种生态各有一条低显存通道：

• ComfyUI 生态：直接用*-comfy-int8-convrot.safetensors检查点（配合 --lowvram 启动参数）；
• Python 生态：用 bf16 检查点 +--quantization fp8-cast。

把 int8 文件拖进 Python 管线、或把 fp8 思路套到 ComfyUI 上，都会踩空。这是第一件套的边界。

2. CPU / 磁盘 Offload：省显存的代价是带宽

官方 CLI 的--offload {none,cpu,disk}三档，语义在安装文档里写得很直白：cpu把 Transformer 权重常驻系统内存、按层流式送显存；disk在系统内存也不够时直接从磁盘流式读取，更慢。它只卸载权重，不解决激活值——激活值的高峰恰恰由分辨率与帧数决定。

值得注意的是，在 README.md 的低显存提示中，官方给出的组合是：

# Downcast bf16 transformer on the fly + CPU offload ...existing flags... \ --quantization fp8-cast \ --offload cpu

"量化 + 卸载"是官方盖章的标准组合：量化先砍掉一半权重体积，卸载再把剩余部分逐层搬运，两者叠加才谈得上 8G。社区在 AMD 平台上的做法与此同构：INT8 量化模型 + CPU 卸载 + 显存受限启动参数，三管齐下。

边界在于：卸载的瓶颈是 PCIe 带宽，不是显存。每步去噪都要把几十 GB 的权重在 CPU↔GPU 之间搬运一轮，8 步蒸馏还能忍，40 步完整采样就是灾难——这也是低显存场景必须优先选蒸馏版的原因。

3. 分块解码（tiled decode）：管住 VAE 而不是 DiT

三件套里最容易被忽略的是 VAE 侧。官方优化文档里，视频 VAE 分两种：vae/ltx-2.5-video-vae-bf16.safetensors（DiffVAE 扩散解码器，画质更高、更吃显存）与 vae/ltx-2.5-video-vae-conv-bf16.safetensors（卷积解码器，更快更轻）。

DiffVAE 的解码分块由--diffvae-optimization控制，四档预设的显存差异是量级的：chunked_eager（默认）与chunked_compile的峰值显存大约只有combined_compile的一半。LTX2.3 时代社区总结的tiled_decode优化，到 LTX-2.5 这里对应的就是这套 chunked 机制。低显存玩家的选择应该是Conv VAE（或 chunked_eager 的 DiffVAE）+ 显式分块，而不是追求最快的combined_compile。

官方文档还给出了一组"Tile 体积 vs int32 编译阈值"的工程数据：潜空间体积T × (H/4) × (W/4) × 512 ≤ 2,147,483,647时编译器保持 int32 寻址（冷编译约 30-35 秒），超过则退回 int64（冷编译约 70 秒以上）。例如 512×512×48 帧的 tile 落在 int32 区间，1024×1024×120 帧则越界。分块大小不是越大越好，跨过 int32 阈值会同时损失编译速度与内存可控性。

三、8G 与 12G 显存下的可用参数区间

LTX-2.5 的采样约束在 README.md 写死了两条：帧数必须满足num_frames % 8 == 1（1、9、17、…、121），宽高必须被 32 整除。所有降级方案都必须在这个网格上做。官方优化文档给出的 token 公式可以量化"一帧画面值多少钱"：

video_tokens = ((num_frames - 1) / 8 + 1) × (height / 32) × (width / 32)

以 121 帧（约 5 秒@24fps）为例：1024×1536 是 24,576 tokens，4K（3840×2176）飙到 130,560 tokens——分辨率对 token 数的影响是平方级的，帧数只是线性级。这直接决定了降级优先级。

8GB（如 RX 6700 XT / RTX 4060 8G）

社区在 Windows 11 + AMD 平台上（DirectML/ONNX Runtime 推理后端）跑通的完整链路是：INT8 量化模型 +--lowvram启动 + CPU 卸载，同时对帧数、分辨率、采样步数三重降级，最后用多片段拼接的方式把短片段接成 2 分 5 秒的成片。这是一个信号：8G 卡的单次生成预算非常有限，"一次出长片"不现实，"分片生成再拼接"才是工程常态。

8G 卡的现实参数窗口大约在：

• 分辨率：512×320 或 544×320（32 整除网格上的低档位），720p 单次生成基本无望；
• 帧数：9 或 17 帧（约 0.4-0.7 秒@24fps）起步，靠拼接累计时长；
• 步数：只走蒸馏 8 步（CFG=1），完整 dev 版 40 步采样不在考虑范围；
• 音频：音频 VAE 与音频 token 同样占显存，8G 建议优先关闭或后置。

12GB（如 RTX 3060 12G）

LTX 系模型在 12G 上已有可复现的先例：LTX2.3 时代社区通过"低显存模式 + CPU Offload + tiled_decode + 参数配置（compile_mode 等）+ 分批处理与显存回收"五招，把 32GB 的显存需求压到 24GB，进而在 RTX 3060 上跑出 720p——这验证了"显存需求压一半以上"在 LTX 架构上是可行的。LTX-2.5 体量更大，但同样的方法论成立：

• 分辨率：720p（约 960×544 或 1280×736）短片段可行，社区报道"16GB 显存可本地跑"、"24GB 显卡流畅生成 4K"，12G 落在两者之间；
• 帧数：17-33 帧（约 0.7-1.4 秒）为主，121 帧需谨慎（2 万+ tokens 的激活值会冲破预算）；
• 步数：蒸馏 8 步是唯一合理档位；--compile的 CUDA graph 模式（capture=true、reduce-overhead）必须配--offload cpu才能用，12G 以下建议直接放弃 graph 加速；
• VAE：选 ltx-2.5-video-vae-conv-bf16.safetensors 或 DiffVAE 的chunked_eager。

四、降级优先级：先砍什么、后砍什么

综合官方 token 公式与社区实测，低显存降级的正确顺序是：

1. 砍步数（第一优先，且近乎免费）：蒸馏版固定 8 步 + CFG=1，这是 LTX-2.5 相比完整模型的"自带折扣"。README.md 明说蒸馏版"retains much more of the full model's visual quality, prompt adherence, and motion consistency"，画质损失是三者里最小的；
2. 砍帧数（第二优先，线性收益）：token 公式中帧数是线性项，17 帧砍到 9 帧省一半时序 token，损失体现在运动完整度，可用分片拼接弥补；
3. 砍分辨率（最后动，平方收益也平方代价）：从 1024×1536 降到 512×320，token 数掉到 1/9，但同时丢失的是画面细节——社区对 LTX-2.5 与 H3 的对比评测中，"分辨率与显存占用"正是硬件门槛分档（8GB/16GB/24GB+）的核心分水岭；
4. 砍附加能力（音频、多镜头、时长预测）：音频 token 按round((num_frames / frame_rate) × 25)计入序列，音频 VAE 另有体积，8G 卡上应最后才考虑开启。

一个值得单列的判断：时长预测头（model_patches/ltx-2.5-duration-head-bf16.safetensors）在低显存下建议关闭。它让模型"按提示词自动决定帧数"，但自动预测的帧数往往偏高，超出 8G/12G 的预算区间；显存受限时应手动锁死 9/17 帧，把时长控制权握在自己手里。

五、画质损失的一手账：量化与蒸馏各付多少钱

关于"INT8 到底糊不糊"，可以按证据分层说清：

• 蒸馏 vs 完整模型：损失最小的一层。官方定位是"substantially improved distilled model"，蒸馏损失集中在极端细节（复杂文字、密集纹理）与提示词边界，日常镜头语言下与 dev 版差距很小；
• fp8-cast 在线量化：官方文档描述为"Downcasts transformer linear weights to FP8 during loading; upcasts on the fly"——权重先降后升，实际承担的是加载期内存与带宽压力，推理时恢复精度，属于接近无损的显存节省手段；
• int8 + convrot（ComfyUI 专属）：这是真正的常驻 int8，权重体积减半但引入量化噪声。社区 AMD 8G 实测中它的定位是"能跑"，画质账则通过降分辨率/帧数共同分摊；
• Conv VAE vs DiffVAE：这是最容易被忽略的画质分水岭。DiffVAE 是 LTX-2.5 的"diffusion fidelity rendering"核心——官方描述为"sharper faces, textures, and on-screen text, better motion, and fewer artifacts"。8G/12G 用户为显存选择 Conv VAE，省下的显存实际上是以人脸、文字清晰度和运动稳定性为代价的，这部分损失比量化更肉眼可见。

一句话总结画质账：低显存模式下，最先感知到的退化不是"糊"，而是"细节（人脸/文字）与运动连贯性"，这两者主要由 VAE 档位与帧数决定，而非 INT8 本身。

六、给 8G 玩家的一份启动清单

综合本仓库 README.md 的官方命令与社区验证过的参数组合，8G 显卡的推荐配置可以收敛成下面这条（ComfyUI 路径替换为 int8 检查点 +--lowvram）：

# Python 路径：蒸馏版 + 在线 FP8 + CPU 卸载 + 低分辨率短片段 uv run python -m ltx_pipelines.distilled \ --transformer-path models/ltx-2.5/diffusion_models/ltx-2.5-22b-distilled-transformer-bf16.safetensors \ --text-encoder-path models/ltx-2.5/text_encoders/gemma4-12b-with-proj-ltx-2.5-bf16.safetensors \ --video-vae-path models/ltx-2.5/vae/ltx-2.5-video-vae-conv-bf16.safetensors \ --quantization fp8-cast \ --offload cpu \ --num-frames 17 \ --width 512 --height 320 \ --output-path output_8g.mp4 \ --prompt "your prompt here"

显存预算自查表（按 8G / 12G 分档）：

LTX-2.5 的 22B 参数决定了它永远不可能是"8G 卡的原生体验"，但它确实把"能不能跑"从一道判断题变成了一道参数选择题：INT8 检查点把权重减半，--offload把常驻显存转嫁给系统内存与 PCIe 带宽，分块解码管住 VAE 侧的峰值，剩下的就是按"步数 → 帧数 → 分辨率 → 附加能力"的顺序，在 8k+1 与 32 整除的网格上找到自己能接受的那个档位。对 8G 玩家而言，这份清单的结论很直接：能用、够用、但要接受"短片段 + 拼接"的生产方式；真正让 LTX-2.5 舒展开来的甜点区间，是 12G 到 16G 的显存。

【免费下载链接】LTX-2.5项目地址: https://ai.gitcode.com/hf_mirrors/Lightricks/LTX-2.5