can you make LTX 2.5 · 22B INT8 ?
or explain how i can do it? thank you!
also Qwen 3.8 27B ?
nice work! is this faster or slower than minimax? seems like its slower no?
are you on a discord. would love to chat in RT
Slower, yes — and structurally so, not by accident.
MiniMax-H3-Turbo has the Turbo LoRA merged into the weights, so it samples in 4 steps: 60.2 s for 512×288 × 39 frames on a 5090. LTX-2.5 takes 8, through a 21 B DiT that carries a video and an audio stream in the same 48 blocks, behind a 12 B prompt encoder — roughly 3 min for 384×256 × 49 frames on the same card. You get a soundtrack out of the same pass; that is what you are paying for.
Two things worth knowing if you run it:
--two-stageis the schedule the model was distilled for — 8 steps at half resolution, a learned ×2 latent upscale, then only 3 passes at full resolution instead of 8. Measured on an M4 just now, 768×448 × 241 frames with sound: the full-res step is ~360 s, so three of them is 18 min where eight would be 48.- Since 0.5.88 the prompt encode is cached, so a second take on the same text starts at the first denoising step instead of paying 29 s again.
No Discord, sorry — this thread and GitHub issues is where I am.
okay ill give it a try once i free up some disk space lol.
will it be possible to add the other inputs that mini max supports. ie reference images, characters sheets, video to video, audio to video (lip synching).
the closest ive come to character sheets is giving it a start frame with my character then prompting it to refer to the same character in first frames in next cut. here is an example (man with very long nose put into a scene) . you would then edit out the first frames with the reference
(this hack is limited - you cant use a high rez image to squeeze more people since that first frame defines the resolution for the whole clip which exceeds the memory)
okay - i will keep contacting you on these threads thanks for your great work!
On the other inputs — a straight answer per path, because they are not equally far away. The release is tagged for six conditioning modes; this container packs one (fl2va).
| you want | the release calls it | what is missing here |
|---|---|---|
| lip sync from a wav | audio-to-audio-video |
the audio VAE's encoder half — we pack only the decoder. The DiT side already exists: the packed layout carries a reference-audio segment with its own condition timestep |
| video → video | video-to-audio-video |
plumbing only. The video VAE encoder is already in the fl2va files — it is what encodes --first-frame |
| character sheets / subject references | ref2va |
a different DiT checkpoint (minimax_h3_ref2va_*) with its own turbo LoRA — a second container, not a flag |
None of them needs training. Your first-frame hack is the right workaround today, and you are right about its cost: the keyframe defines the render's resolution, so a high-res character sheet blows the memory budget for the whole clip.
Also new in 0.5.92: --lora at runtime, so community adapters run against this file as they ship — #8.
--video landed in 0.5.93, which is the closest thing to v2v this container can do:
cortiq animate model.cmf --prompt "…" --video ref_frames/ --video-stride 8
Every n-th frame of a reference clip becomes a condition pinned to its own moment of the render — the fl2va keyframe path with more than two frames, mapped onto the render's length by position. It is not the release's own v2v node, which conditions differently; what it gives you is exactly the chaining hack you described, without editing the first frames out.
Reference audio still needs the audio VAE's encoder to run; its weights are packed as of this build, the runtime path is next.