8GB 显存玩家的极限LTX-2.5 的 INT8 量化 低显存模式实测清单【免费下载链接】LTX-2.5项目地址: https://ai.gitcode.com/hf_mirrors/Lightricks/LTX-2.5220 亿参数、一次前向就要吃掉几十 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 的仓库以按组件拆分的方式发布权重TransformerDiT一个文件、文本编码器一个文件、VAE 一个文件互不捆绑。这意味着显存预算可以按需裁剪而不是为整个模型家族买单。Transformer 的量化梯度在 diffusion_models/ 下清晰可见检查点精度用途边界ltx-2.5-22b-dev-transformer-bf16.safetensorsbf16完整可训练版微调/引导式两阶段管线用ltx-2.5-22b-distilled-transformer-bf16.safetensorsbf16蒸馏版固定 8 步采样、CFG1低显存玩家的默认选择ltx-2.5-22b-distilled-transformer-comfy-int8-convrot.safetensorsint8 convrotComfyUI 专属ltx-pipelines / PyTorch 路径不加载ltx-2.5-22b-dev-transformer-comfy-int8-convrot.safetensorsint8 convrot同上dev 版ltx-2.5-22b-distilled-transformer-nvfp4.safetensorsNVFP4需 BlackwellSM ≥ 10与ltx-kernels消费级卡用不上同样的情况出现在文本编码器上text_encoders/ 里 bf16 与 comfy-int8-convrot 两个版本并存。文本编码器是 Gemma 4 12B 级模型体量与 DiT 相差无几在低显存场景下它与 Transformer 是二选一进显存的关系。按参数量粗算22B 的 bf16 权重约 44GB、int8 约 22GB12B 文本编码器 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_CONFexpandable_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.safetensorsDiffVAE 扩散解码器画质更高、更吃显存与 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 11、9、17、…、121宽高必须被 32 整除。所有降级方案都必须在这个网格上做。官方优化文档给出的 token 公式可以量化一帧画面值多少钱video_tokens ((num_frames - 1) / 8 1) × (height / 32) × (width / 32)以 121 帧约 5 秒24fps为例1024×1536 是 24,576 tokens4K3840×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×32032 整除网格上的低档位720p 单次生成基本无望帧数9 或 17 帧约 0.4-0.7 秒24fps起步靠拼接累计时长步数只走蒸馏 8 步CFG1完整 dev 版 40 步采样不在考虑范围音频音频 VAE 与音频 token 同样占显存8G 建议优先关闭或后置。12GB如 RTX 3060 12GLTX 系模型在 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 显卡流畅生成 4K12G 落在两者之间帧数17-33 帧约 0.7-1.4 秒为主121 帧需谨慎2 万 tokens 的激活值会冲破预算步数蒸馏 8 步是唯一合理档位--compile的 CUDA graph 模式capturetrue、reduce-overhead必须配--offload cpu才能用12G 以下建议直接放弃 graph 加速VAE选 ltx-2.5-video-vae-conv-bf16.safetensors 或 DiffVAE 的chunked_eager。四、降级优先级先砍什么、后砍什么综合官方 token 公式与社区实测低显存降级的正确顺序是砍步数第一优先且近乎免费蒸馏版固定 8 步 CFG1这是 LTX-2.5 相比完整模型的自带折扣。README.md 明说蒸馏版retains much more of the full models visual quality, prompt adherence, and motion consistency画质损失是三者里最小的砍帧数第二优先线性收益token 公式中帧数是线性项17 帧砍到 9 帧省一半时序 token损失体现在运动完整度可用分片拼接弥补砍分辨率最后动平方收益也平方代价从 1024×1536 降到 512×320token 数掉到 1/9但同时丢失的是画面细节——社区对 LTX-2.5 与 H3 的对比评测中分辨率与显存占用正是硬件门槛分档8GB/16GB/24GB的核心分水岭砍附加能力音频、多镜头、时长预测音频 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 convrotComfyUI 专属这是真正的常驻 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 分档项目8GB 卡12GB 卡Transformerint8Comfy或 fp8-castPython CPU offloadfp8-cast CPU offload 可选文本编码器int8 版用完即卸载bf16 或 int8与 DiT 分时加载视频 VAEConv VAE 优先Conv VAE 或 DiffVAE(chunked_eager)分辨率512×320 / 544×320720p960×544短片段帧数9-17 帧多片段拼接17-33 帧采样蒸馏 8 步CFG1蒸馏 8 步CFG1音频关闭可选注意 audio tokensLTX-2.5 的 22B 参数决定了它永远不可能是8G 卡的原生体验但它确实把能不能跑从一道判断题变成了一道参数选择题INT8 检查点把权重减半--offload把常驻显存转嫁给系统内存与 PCIe 带宽分块解码管住 VAE 侧的峰值剩下的就是按步数 → 帧数 → 分辨率 → 附加能力的顺序在 8k1 与 32 整除的网格上找到自己能接受的那个档位。对 8G 玩家而言这份清单的结论很直接能用、够用、但要接受短片段 拼接的生产方式真正让 LTX-2.5 舒展开来的甜点区间是 12G 到 16G 的显存。【免费下载链接】LTX-2.5项目地址: https://ai.gitcode.com/hf_mirrors/Lightricks/LTX-2.5创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
