CineTimeline｜H3 Turbo 完整加载

Turbo LoRAs on H3 are not ordinary LoRAs

On Wan and every other video family, the step-distillation LoRA is what makes local generation bearable: 20+ steps down to 4–8, CFG pinned at 1, and the whole quality/consistency trade-off that comes with it. H3's production baseline in this pack does the same thing - LightX2V v1.0 BF16 at strength 0.75, 8 steps, applied to both Ref2VA and FL2VA.

The difference on H3 is that its acceleration LoRAs also carry AdaLN curve projections. Those aren't linear weight pairs a generic loader can just add in; they're curve adapters that get installed as forward patches on the diffusion model. Load that file with a stock LoraLoaderModelOnly and the best case is that half the LoRA silently doesn't apply, and the second-best case is a model that renders like it's been fed an incompatible delta. CineH3TurboLoRA exists so the third case - a loud, specific error before any patch is registered - is the one you get.

What it does with the file

The adapter is strict on purpose. It accepts both key conventions (.lora_down.weight / .lora_up.weight and .lora_A.weight / .lora_B.weight) plus .alpha, then refuses anything it doesn't recognise: unknown tensor names, a module with duplicate parts, a missing half of a pair, non-2D tensors, a.shape[0] != b.shape[1], a NaN alpha. Alpha and rank are folded into B in memory, so nothing on disk is rewritten and the arithmetic is the same either way.

Then it validates destinations. Before a single patch is applied, every target module is looked up on the live diffusion model and its weight shape is compared against the LoRA's A/B shapes. Mismatch, error, nothing applied. That check is what catches "this is a Wan LoRA" or "this is the LoRA for the other quant family" - the two mistakes that otherwise look like bad sampling.

Curve handling comes next. If the loaded diffusion model reports use_adaln_curves, the adaln_proj modules are split out from the backbone. Those get forward patches, and the node refuses to stack two curve adapters - one acceleration LoRA, by design. The backbone then takes one of two paths: the default bypass apply, which skips fc2 modules already fused on the INT8 ConvRot checkpoints, or the low_vram merge path, which folds the backbone weights in directly.

The inputs that matter

model is your H3 diffusion model. lora_name is a dropdown straight from your models/loras folder - no path typing. strength defaults to 0.75, which is the pack's own production number for LightX2V v1.0 on both generation modes, and 8 steps is the matching step count. Don't push it higher looking for acceleration: distillation LoRAs want the strength they were trained at, and over-driving one gets you mushy motion and identity drift. low_vram changes how the LoRA is delivered, not how strong it is - bypass injection by default, weight merge when you're tight on memory. Pick it once; flipping it to fix a quality problem will not work.

The single output is MODEL, and it chains like any other LoRA loader, before the attention patch and the sampler.

Installing it

The pack comes from Manager (CineTimeline) or:

cd ComfyUI/custom_nodes
git clone https://github.com/bo341805sg/ComfyUI-CineTimeline
# restart, hard-refresh the browser

Here's the part people miss: this node is a format adapter over another pack. It calls into the MiniMaxH3TurboLoRA loader registered by ComfyUI-MiniMax-H3-Turbo. Install that separately, or the node raises ComfyUI-MiniMax-H3-Turbo is required for curve-aware LoRA loading the moment you hit queue. The pack's own pyproject.toml declares no pip dependencies at all; the real weight is in the H3 model files, the Qwen3-VL encoder, KJNodes, and minimax-h3-audio-T8 1.3.2.

If you're on the INT8 ConvRot pair the author treats as baseline, note two loader guards: INT8 mixed with NVFP4 is rejected, and INT8 won't load in a ComfyUI process that still has DynamicVRAM enabled - launch with --disable-dynamic-vram.

Errors you'll actually see

• Stacking two curve-AdaLN H3 LoRAs is not supported; use one acceleration LoRA - you chained two Turbo-class files. Drop one.
• H3 LoRA target mismatch: <module>: (shape) versus (shape) - the file isn't for this model. Check the family and the quant.
• Unsupported H3 LoRA tensor: <key> - usually a LoRA with text-encoder or extra keys bundled in. Split it or re-export model-side only.
• Incomplete H3 LoRA pair / Duplicate H3 LoRA tensor - a broken or partially downloaded file. Re-download before you debug anything else.

And a last piece of context the node can't give you: H3 is 33B with a 32B text encoder, and the licence is the MiniMax H3 Community License, which grants broad rights worldwide minus the EU, UK, Republic of Korea and the US - outputs included. If you're in one of those regions, the licensing question comes before the LoRA question.