This checkpoint was converted from a mixed 𝐁𝐅𝟏𝟔 / 𝐅𝐏𝟖 checkpoint by converting all 𝐁𝐅𝟏𝟔 tensors to 𝐅𝐏𝟖_𝐄𝟒𝐌𝟑
The main difference is 𝐜𝐡𝐞𝐜𝐤𝐩𝐨𝐢𝐧𝐭 𝐬𝐢𝐳𝐞 𝐚𝐧𝐝 𝐢𝐧𝐟𝐞𝐫𝐞𝐧𝐜𝐞 𝐞𝐟𝐟𝐢𝐜𝐢𝐞𝐧𝐜𝐲 — this is 𝐧𝐨𝐭 𝐚 𝐧𝐞𝐰 𝐯𝐢𝐬𝐮𝐚𝐥 𝐬𝐭𝐲𝐥𝐞 or a visually enhanced model.
𝐊𝐞𝐲 𝐏𝐨𝐢𝐧𝐭𝐬
• Smaller checkpoint: about 𝟐𝟏.𝟒 𝐆𝐁
• Aggressive 𝐅𝐏𝟖-𝐄𝟒𝐌𝟑 conversion
• 𝐎𝐫𝐢𝐠𝐢𝐧𝐚𝐥 𝐦𝐨𝐝𝐞𝐥 𝐚𝐫𝐜𝐡𝐢𝐭𝐞𝐜𝐭𝐮𝐫𝐞 𝐩𝐫𝐞𝐬𝐞𝐫𝐯𝐞𝐝
• 𝐋𝐨𝐰𝐞𝐫 𝐕𝐑𝐀𝐌 𝐮𝐬𝐚𝐠𝐞 than heavier BF16 checkpoints
• Best for local ComfyUI users who want a smaller LTX-2.3 checkpoint
𝐂𝐨𝐧𝐯𝐞𝐫𝐬𝐢𝐨𝐧
• 𝐁𝐅𝟏𝟔 tensors → 𝐅𝐏𝟖_𝐄𝟒𝐌𝟑
• Existing 𝐅𝐏𝟖_𝐄𝟒𝐌𝟑 tensors preserved
• 𝐅𝟑𝟐 and 𝐔𝟖 tensors preserved
For more details, files, and the full models repository:
https://huggingface.co/SOLRICKS/ltx23_srx_fp8_e4m3_experimental
Description
Experimental FP8_E4M3 repack.
Converted from a mixed BF16 / FP8 LTX-2.3 checkpoint by converting all BF16 tensors to FP8_E4M3.
This is an experimental dtype conversion / repack, not a newly trained model and not a merge.
FAQ
Comments (6)
hi, i'll go try it out.
do you need help with testing specific use cases?
We tried image-to-video and text-to-video conversions with no audio or video issues found. We are continuing to test and will next upload new images to try with the Civitai generator. Thank you.
could you please give a brief explanation of what is supposed to be different about this? or where it 'shines' compared to the base model? just a bullet-point description would be nice.
Just less vram usage. What I want to know is if its 1.0 or 1.1 as 1.1 is superior in every way.
The main difference is size/efficiency, not a new visual style: it is a smaller experimental FP8-E4M3 LTX-2.3 checkpoint, around 21.5GB, with tensor names/shapes preserved, tested in ComfyUI, and confirmed working with audio output; it is mainly intended for local ComfyUI users who want a lighter experimental inference checkpoint, not something designed to visually outperform the base model.
@ylvlylvuyv374212 This is based on the current LTX-2.3 dev 22B / model_version 2.3.0 family, repacked to FP8-E4M3 for smaller checkpoint size and lower VRAM usage. No fine-tune or merge was done. Note: VRAM usage should be lower, but depending on the loader/workflow, system RAM usage may still be high or even slightly higher during loading/offloading.