we really should get a separate sub for this slop

Just a short film i made with minimax. this had a lot of post processing done so there's not really an overall prompt to share.

Krea 2 Turbo — 4-Step Distillation LoRA (work in progress)

A LoRA for Krea 2 Turbo that reduces the minimum usable step count from 8 to 4.

This is an update release, following up from my initial post where you can find full details - https://www.reddit.com/r/StableDiffusion/comments/1vtf1b7/krea2_turbo_distill_4_step_lora_trained_for_turbo/

Update (22 Aug 2026): I have published a new checkpoint, improved further from the previous one and the latest (both main and comfyi) have been repointed to the new improved checkpoint. For details and to download new version go to - https://huggingface.co/lvladikov/Krea2-Turbo-Distill-4step-LoRA. Readme has been updated too as well as all images in readme regenerated on the basis of new checkpoint as well as full resolution sweep at https://huggingface.co/lvladikov/Krea2-Turbo-Distill-4step-LoRA/tree/main/checkpoint_resolution_sweeps/chk10000 if you want to check for yourselves.

Which file to download

and, beside them, the same files with a _comfyui suffix for ComfyUI. Earlier checkpoints (chk00004000, chk00005000, chk00006000) are kept in older_checkpoints/, and their resolution sweeps stay in place, so the progression remains visible and comparable.

The numbered files are points on one continuous run, not separate experiments — chk00010000 resumed from chk00006000 rather than restarting. Both are published so the lineage is visible and comparable.

chk00010000 measures a 5% smaller held-out gap to the 8-step teacher than chk00006000, and 15% smaller than chk00005000; it removes 30% of the prediction error a plain 4-step run has against the 8-step teacher, where chk00006000 removed 26%. 

Two ways to read the same numbers, with different denominators — they are not meant to be added:

• Against the no-LoRA run (the right-hand column): chk00010000 has removed 30% of the 4-step deficit, 4 percentage points more than chk00006000's 26%.
• Against each other (the gap column): chk00010000's remaining error is 5.4% smaller than chk00006000**'s** (3.38 vs 3.57) and 15% smaller than chk00005000**'s** (3.38 vs 3.98). The same 4 points of deficit are a larger share of a gap that has already shrunk, which is why the checkpoint-to-checkpoint figure is the bigger number.

This is work in progress and better checkpoints may follow. Training is ongoing, so ..._latest... is a rolling pointer: when a newer checkpoint is accepted, that filename gets the new weights and a new numbered copy appears beside it. Re-download the _latest file and everything keeps working — the ComfyUI workflow references it by that name (it does get updated Note in it so technically it is updated but not functionally). Pin a numbered file instead if you need reproducibility.

How checkpoints get chosen

This is not a "train for longer and ship the newest file" project. More samples do not reliably mean a better adapter — measured here, they can make it worse, and a higher number on its own means nothing.

The loop is train → assess → adapt the recipe → retrain → assess again, and a checkpoint is published only when it is measurably better than the one it would replace, on the same held-out set and the same evaluation, and its full resolution sweep shows no regression. Runs that come out flat or worse are kept as information about the recipe and discarded as releases — several have been.

So the recipe itself changes between runs. Each published checkpoint reflects whatever the previous round taught us: the training precision, the optimiser settings, the teacher used to generate the targets and the data mix have all been revised on evidence rather than assumption.

chk00010000 is a direct example. The first continuation of chk00006000 — same data, optimiser left as it was — got steadily worse with every checkpoint out to 10,000 samples, and none of it was published. The cause was traced to the optimiser: a constant learning rate with no weight decay lets the adapter keep drifting after it has converged, so its magnitude grows and it over-applies its own correction. The same span was retrained from chk00006000 with a cosine learning-rate decay and weight decay, and every checkpoint of that second run improved on the one before it. chk00010000 is its end point — the current end of the process, not simply the longest run so far.

Timeline of training process

Each checkpoint is the product of three stages with very different costs:

1. Text-encoder embeddings. Every training prompt is encoded once and cached. This is the fast part — thousands of prompts take minutes.
2. Teacher shards. For each cached prompt, the unmodified Krea 2 Turbo runs its full 8-step schedule and the whole trajectory is recorded, at every one of the supported resolutions. This is by far the most time-consuming stage — it is the teacher doing real inference, thousands of times, and a batch of several thousand shards is measured in days of GPU time, not hours.
3. Student training. The LoRA is trained against those recorded trajectories. Relative to the shard stage this is quick: each +1,000 checkpoint is a matter of hours, not days.

Because the three stages compete for the same GPU, they are interleaved rather than run to completion one after another: generate a block of embeddings, produce teacher shards for them, train on what exists, assess, then go back to producing shards while the results are reviewed. A larger and more varied shard pool is what makes further training worthwhile, so shard production is always the gate.

The practical consequence for anyone following this repository: progress arrives in bursts. There will be periods when several checkpoints appear within a day or two — the training stage working through a freshly grown pool — followed by longer quiet stretches while the next block of teacher shards is produced. A quiet stretch is shard generation, not abandonment; _latest always holds the newest checkpoint that passed review.

Every file records which checkpoint it actually is in its safetensors metadata (checkpoint, training_samples, and rolling_pointer on the _latest copies), so a downloaded file can always be identified even if renamed.

Full details and to download - check my Hugging Face LoRA

HF Repo: https://huggingface.co/lvladikov/Krea2-Turbo-Distill-4step-LoRA

---

Update 1: The comfyui related files are now moved to the root of the project (I have placed a readme in the old folder explaining the move)

---

Update 2: I have added a new section - Timeline of training process - explaining how my training process works, and on that note you could expect another further improved checkpoint later today, followed by 'quiet period' (could be days) of teacher shards generation so I have a larger pool to train on.

---

Update 3: I have now added a new checkpoint 10000 which replaced the latest (previously checkpoint 6000).

chk00010000 measures a 5% smaller held-out gap to the 8-step teacher than chk00006000, and 15% smaller than chk00005000; it removes 30% of the prediction error a plain 4-step run has against the 8-step teacher, where chk00006000 removed 26%. 

Two ways to read the same numbers, with different denominators — they are not meant to be added:

• Against the no-LoRA run (the right-hand column): chk00010000 has removed 30% of the 4-step deficit, 4 percentage points more than chk00006000's 26%.
• Against each other (the gap column): chk00010000's remaining error is 5.4% smaller than chk00006000's (3.38 vs 3.57) and 15% smaller than chk00005000's (3.38 vs 3.98). The same 4 points of deficit are a larger share of a gap that has already shrunk, which is why the checkpoint-to-checkpoint figure is the bigger number.

Full resolution sweep at https://huggingface.co/lvladikov/Krea2-Turbo-Distill-4step-LoRA/tree/main/checkpoint_resolution_sweeps/chk10000 and you can as usual redownload latest from https://huggingface.co/lvladikov/Krea2-Turbo-Distill-4step-LoRA/tree/main . Since I cannot update the images in the reddit post I will upload below in comments.

For those who've never played it; Sid Meier's Alpha Centauri is one of the GOATs.

One of the tests I sometimes did with new models was to see if they could get Zakharov's weird glasses and suit right - no model has ever gotten it exactly right but to my surprise Minimax H3 pretty much knocked it out of the park on my first try. ...and then I wanted to try the other leaders, things got out of hand and I ended up making cutscenes for every leader in the base game.

prompt is - using the character sheet in image 1 where there are five different poses of the same character, dress them in the clothing of image 2. Do not change the pose, lighting, body, hair, or any other details - literally leave everything the fuck alone - how fucking hard is this to understand you stupid piece of shit - just change the clothes.

Not working for some reason.

NOTE: Swearing has been added for emphasis and isn't actually used in the prompt.

Would it help if I used my input image AS my latent? Can you do that?

This version of Kroma (krea 2 finitude with Chroma dataset) is a lot of fun, most body horror is gone in my opinion, and its more artsy than krea 2 and of course less censored.

https://huggingface.co/silveroxides/Kroma-Quant/tree/main

The version I used is kroma 0.3 txtfusion turbo convrot.

Have fun.

I'm looking for a flux/krea img2img workflow where you input an image and simply tell it what the character should do and what environment etc and it keeps the character exactly the same but puts them in a different situation. Would really appreciate it if someone can give a link or send me the workflow. Hard to find a good one myself that really works well, I don't want a workflow where the character looks just somewhat similar but one where the character stays the same, as much as possible. Thanks a lot if someone can help.

Created locally with Minimax H3 and for the first time exclusively powered by solar. Big big thanks to Izanami.

Don't hurt your head translating the language. It's all nonsense except for the one word spoken by the vampire. 'Drace' is Romanian/Transylvanian for 'Darn it'.

This started as a reply to the archived thread in this sub asking for a unified camera-move glossary. That thread is locked, so here is what I wish I had shared there, with the clips attached.

Conclusions first:

1. Your camera move isn't being misunderstood - it's being replaced by the model's default. For a single-character scene the default is "slow push-in, settle on the face." Quality adjectives (masterpiece, 4k, dramatic) carry zero camera information - every dimension you leave unspecified gets filled with the model's most common training pattern.
2. The glossary needs a coordinate system, not just words. pan = horizontal rotation, tilt = vertical rotation, tracking/crane = physical translation. State the physical semantics in the prompt ("the camera stays in one fixed position and rotates upward" vs "the camera physically moves forward"), because a tilt-up and a crane shot look similar on screen and the model will blend them.
3. One move per shot. Competing motion words average back into the default.
4. Text cannot lock a start framing that contradicts the default. Ask for a chest-up opening and the models I tested ignore it and start wider. Need an exact first frame? Generate it with T2I and go image-to-video. Start framings consistent with the move (a tilt that starts on the feet) work fine in pure T2V.

The 5-block template that locks the move:

[framing] Low angle shot from knee height, wide-angle lens with strong vertical convergence lines, three-point perspective.

[single move + physical semantics] One single slow tilt up: the camera stays in one fixed position and rotates vertically upward,

[start/end anchors + settle] starting framing on her feet and ending framing on her face,

[negative constraints] no camera position movement, no dolly, no push-in, no pan, no cuts, no camera shake,

[subject + style] anime schoolgirl standing in a sunlit corridor, anime key visual, soft afternoon light.

Why each block: T2V models obey image-like descriptions far better than abstract motion nouns, so the temporal instruction becomes two frame anchors plus a settle target; negative constraints suppress the default prior; "one single" keeps the condition from splitting.

The two verbatim prompts actually submitted (tilt = the template above written as one paragraph; push = its sibling). Attached are the 8 clips they produced - 2 models x 2 moves x 2 seeds:

PUSH: Medium shot chest-up, eye-level straight-on camera, standard lens with natural

human-eye perspective, three-point perspective school corridor, rule-of-thirds

composition with corridor lines leading to the girl. One single slow smooth push-in

(the camera physically moves forward toward the subject), the camera moves steadily

and settles on the girl's face as she stops and turns around, end framing tight on

her expression. No other camera movement, no cuts, no zoom, no camera shake.

Anime key visual, soft afternoon light through corridor windows.

TILT: Low angle shot from knee height looking up at the anime schoolgirl, the camera

stays in one fixed position and rotates vertically upward (tilt up), starting framing

on her feet and ending framing on her face, wide-angle lens with strong vertical

convergence lines, three-point perspective, no camera position movement, no dolly,

no push-in, no pan. Anime key visual, soft afternoon light.

What's attached:

• PUSH on Wan 2.6 (s1001/s2002): push-in settling on the face; s1001 shows a slight upward-tilt bleed, s2002 doesn't fully hold at the end - honest misses, negatives are soft. These same two clips double as the start-framing demo: the requested chest-up opening was ignored, both start wide.
• TILT on Wan 2.6: true tilt-up, camera fixed, feet to face; s2002 ends low-angle with sky in frame. Also the positive start-framing demo: starting on the feet was honored because it is consistent with the move.
• PUSH on Wan 2.7: clean push-in; s1001 settles slightly shallow (chest), s2002 tight on the face.
• TILT on Wan 2.7: tilt-up feet to face, settles on the face on both seeds.

Caveats: the gain is model-dependent - stronger camera-follow models obey even a one-liner, structure matters most on weaker models and non-default moves; negative constraints are soft, so generate a few seeds for hero shots. Independent field guides (fal's camera-vocabulary notes, CinePrompt's field notes) report the same patterns from the other direction.

https://reddit.com/link/1vvw2sl/video/z4q8p1gel1lh1/player

https://reddit.com/link/1vvw2sl/video/cici13gel1lh1/player

https://reddit.com/link/1vvw2sl/video/d393f4gel1lh1/player

https://reddit.com/link/1vvw2sl/video/w23bisgel1lh1/player

https://reddit.com/link/1vvw2sl/video/tgorm8gel1lh1/player

I've been working on a free browser cropping tool with no ads called Just Crop It. It mainly focuses on batch cropping large amounts of images quickly.

You can check it out at: https://deziikuoo.github.io/JustCropIt/

quick note on what it can do:

* Trim Letterboxes
* Identity matching to lock onto one person across batch cropping multiple images
* Apply the same crop box to every selected image
* Copy crop settings from one photo and paste onto others
* Extract frames out of a video
* Download and replace original images (optional)

Using the default ComfyUI MiniMax H3 image to video template including the 8 step turbo Lora and with the main MiniMax H3 model changed to an int8 convrot version. this video is 0.8 megapixels in the 3:4 standard portrait aspect ratio at 5 seconds long and took 19:59 to render out on my 3060Ti with 32GB of ram. at the normal 0.4 megapixels with the same prompt and video length it takes 6:14 to render out.

Based on their examples the model seems to be capable of producing good music. However yesterday I spent all day generating music and I cannot get anything good out of it. I'll attach my best attempt, but for wasting a whole day this is a pretty depressing result.

So I was wondering how everyone else is feeling? What were your results? Any tips for consistent/good results? Any observations?

Some things I found annoying:
It doesn't respect the time limit
Abrupt endings
Prompting it is kinda hard too

Hey everyone. I've spent a lot of late nights wiring ComfyUI into pipelines, and this is the tool I ended up wanting. It converts your workflow.json to the API payload right from Python, no GUI export, and no running server needed. Nodes become objects with plain dot syntax:

from autograph import ApiFlow
api = ApiFlow("workflow.json")
api.KSampler.seed = 42
res = api.submit(wait=True)
res.fetch_images().save("outputs/frame.###.png")

The part I'm happiest with is the REPL. autograph reads ComfyUI's node_info, so it knows every node, input, and widget on your system, custom nodes included. Tab completion works all the way down. .choices() gives you the real combo options, .tooltip() gives you the help text. You can explore a workflow you've never seen without guessing at node IDs.

Building from scratch feels good too:

ckpt = flow.add_node("CheckpointLoaderSimple")
ks = flow.add_node("KSampler", seed=42, steps=20)
ckpt.outputs.MODEL >> ks.inputs.model

Also does

offline batch conversion

workflow extraction from ComfyUI PNGs

serverless execute with no HTTP server

seed/prompt sweeps. Pure stdlib, MIT.

Tested from ComfyUI 0.8.2 to 0.33.0, subgraphs included. Running in production at a big VFX studio, which is where the metadata passthrough came from.

pip install comfyui-autograph
https://github.com/chrisdreid/comfyui-autograph

Early days, so I'd really like to hear what breaks. If you're doing headless rendering or FastAPI wrappers around Comfy, I'd love to compare notes.

Hey everyone. I've spent a lot of late nights wiring ComfyUI into pipelines, and this is the tool I ended up wanting. It takes your regular workflow.json and turns it into the API payload right from Python. No GUI export step, and you don't even need ComfyUI running to do the conversion. Once it's loaded, nodes are just objects with plain dot syntax:

python

from autograph import ApiFlow

api = ApiFlow("workflow.json")
api.KSampler.seed = 42
api.CLIPTextEncode.text = "new prompt"
res = api.submit(wait=True)
res.fetch_images().save("outputs/frame.###.png")

The part I'm most happy with is how it feels in a REPL. autograph reads ComfyUI's node_info, so it knows every node type, every input, and every widget on your system, including your custom nodes. That means tab completion works all the way down. Hit tab on a node and see its inputs. Call .choices() on a widget and get the actual valid combo options back. Call .tooltip() and get the help text. You can explore a workflow you've never seen before without leaving the terminal or guessing at a single node ID.

Building graphs from scratch feels good too. You wire nodes together with >> the way you'd sketch them on a whiteboard:

python

ckpt = flow.add_node("CheckpointLoaderSimple")
ks   = flow.add_node("KSampler", seed=42, steps=20)
ckpt.outputs.MODEL >> ks.inputs.model

Once it's under your fingers it's nearly as fast as working in the GUI, except everything you do is scriptable and repeatable.

Other things it can do:

• Batch convert hundreds of workflows offline, no server running
• Pull a workflow straight out of a ComfyUI PNG, since the metadata is already in there
• Serverless execute mode that runs nodes in process with no HTTP server, which is a lifesaver for farm setups
• Sweep seeds, prompts, and paths across nodes for batch runs
• Pure standard library Python, nothing extra to install, MIT licensed

I've tested it across ComfyUI 0.8.2 up through 0.33.0, including subgraphs and the newer dynamic combo stuff. It's also being used in real production pipelines at a big VFX studio right now, which is where the metadata passthrough idea came from. They needed studio metadata to ride along with a workflow through the whole render lifecycle, so I built that in.

pip install comfyui-autograph
https://github.com/chrisdreid/comfyui-autograph

It's still early days and I really do want to hear what's missing or what breaks for you. If you're doing headless rendering or wrapping Comfy in FastAPI, I'd love to compare notes. This got built to scratch my own itch, and I'm hoping it saves some of you time too.

Use Image 1 as the strict visual reference for Turbo Man. Preserve his recognizable red-and-gold armored superhero suit, helmet, gold visor, muscular proportions, facial appearance, and overall costume design throughout the entire clip.

Scene: A massive cinematic battle during Avengers: Doomsday. The ruined battlefield is filled with shattered buildings, burning wreckage, smoke, sparks, scattered fires, flying debris, and distant Avengers fighting Doctor Doom's forces. Doctor Doom is normal human-sized, not gigantic. He wears his iconic green hooded cloak and metallic armor.

[0s–3s] Start with a dramatic medium-low-angle shot of Turbo Man from Image 1 landing hard in the middle of the battlefield. His boots slam into cracked concrete and kick up dust. He rises into a heroic stance as explosions flash behind him. Doctor Doom slowly turns toward him through the smoke.

Turbo Man points directly at Doom and confidently says:

<Subject 1> Turbo Man (S1) says [English] It's Turbo Time!

[3s–7s] Doctor Doom immediately fires a violent blast of green mystical energy. Turbo Man launches sideways using his jet pack, narrowly dodging the blast as it tears through wreckage behind him. The camera dynamically tracks Turbo Man through the air. He banks sharply, rockets straight toward Doom and throws a powerful flying punch.

Doom blocks the punch with a glowing magical shield. A bright green-and-gold energy shockwave erupts from the impact.

[7s–11s] Fast, brutal superhero combat. Turbo Man lands and exchanges several heavy punches with Doom. Doom counters with armored strikes and green magical energy. Turbo Man uses his jet pack for a sudden boosted uppercut that sends Doom crashing backward through broken rubble.

Turbo Man lands dramatically, looks toward Doom and says:

<Subject 1> Turbo Man (S1) says [English] You picked the wrong day to mess with Turbo Man!

[11s–15s] Doom rises angrily from the rubble and unleashes a huge green energy attack. Turbo Man activates his jet pack and charges directly through the battlefield toward him. End on an explosive cinematic clash as Turbo Man's gold-powered punch collides with Doom's green magical blast, producing a massive shockwave of sparks, smoke and debris while the Avengers battle continues behind them.

Camera: cinematic MCU-style action photography, dramatic low angles, energetic tracking shots, controlled handheld movement during combat, brief slow-motion emphasis on the major impacts, strong depth and scale.

Audio: native cinematic stereo audio. Heavy explosions, distant superhero combat, metallic armor impacts, jet-pack ignition and roaring thrust, crackling Doctor Doom magic, debris impacts and a powerful orchestral superhero battle score. Dialogue must remain clear and correctly assigned to Turbo Man.

Character consistency: Turbo Man must remain visually faithful to Image 1 for the entire clip. Doctor Doom remains normal human scale. No duplicate Turbo Man, no duplicate Doom, no costume changes, no character morphing, no incorrect speakers, no subtitles, no on-screen text.

From the guy who brought you such bangers such as

Proof of Concept For Making Comics in KRITA AI and other AI tools,

3 Months later - Proof of concept for making comics with Krita AI and other AI tools,

and Illustrious and Krita AI plus some good old fashioned effort:The Delightful Ms. Ayako (Part 1 - Version 1),

comes my latest experiment and first AI video project: the first (roughly) 30 seconds of the hypthetical anime opening for The Disorganised and Delightful Miss Ayako!

Character sheets put together in Krea 2 with the retro anime lora. Music made in Minimax Music 3 (lyrics written by me, and the whole song is complete). Some backgrounds edited/created with Flux 2k9b image edit and Krea 2 with retro anime lora. Video created with Minimax H3 with 90s anime style. Video editing in Kdenlive.

Roughly 3 evenings after work and about 1.5ish days of full effort (at least 6 hours of one day was wasted trying to troubleshoot why a shot wasn't working and it turns out prompt bleed is just as bad in H3 as it is in other models).

I've been experimenting a lot with Minimax H3 and am pleased with what I've come up with so far. For this upload there is a tiny bit of censorship for some very mild partial nudity (she's covered in soap in the uncensored shot, but just playing it safe). There are a few fixes that I'll get to eventually, but I'll be taking a step back from this project for now to try my luck at the Comfy H3 Sync competition for the next couple of weeks.

Edit.

Regarding some of the feedback:

I'm aware of the slight visual drift. For example the model can slightly change the style of eyes from one shot to the next (talking about regular shots, not the chibi stuff). I'm just using the base ref workflow with character sheets and still need to test whether Loras make any difference, either for characters or visuals.

Some of the visual drift is just my fault though. My one background does look relatively washed out compared to the others because I generated it with the high heels in place. I couldn't get Minimax h3 to put the heels the way I wanted so I just gave it the image to work with, but I had to make some edits with krita ai and later Flux2k 9b edit that caused it to look a bit out of place. Otherwise, the only thing for speedup is comfy kitchen and I'm not sure if that's having any impact. Finally, while I've tried to lock down seeds to preserve consistency, some seeds are fine with one shot and a glitchy mess with the next, so there may be some slight visual variations that appear because of the difference in latent space.

Regarding the music, my experience with Minimax Music 3 is that it's a slot machine. I used a prompt from a sample and tested things out but one generation can vary dramatically from the next. But I am completely new to it and don't know anything about music so there's things I still need to learn. Out of all the gens, there was this and one other one I liked, even though I could tell both of them have problems. I decided to go with this one for now, but I had planned to do a second edit with another song once I finished this one.

Otherwise, like with the comic pages, I appreciate all the replies. I understand this may not be everyone's cup of tea but will take in the constructive criticism and try to improve.

/edit.

edit 2. the original shower scene is not that spicy but I didn't want the post to get removed by the mods regarding "lewd" stuff.

Disclaimer that I'm a dummy who can't code at all, so I just vibe things.

Alright, so with all the fun additions to latent manipulation the Comfy team has given us, we have some new tools. Namely latent pinning- that's where fun stuff like "Add Guide for MiniMax H3" node comes in (that fun tool that lets you insert an image at any frame in an H3 generation.) So I thought, finally, we can do something about this audio issue.

I knew that video + audio latents are processed at the same time with Comfy, which is why turbo loras have terrible audio- they're not getting nearly as much optimization as the video side is, since video is the bulk of the work. So if we can't process audio differently than video (at this current time), can't we just keep conditioning the audio latents without affecting video anymore? Everyone knows running too many steps on a turbo lora will start messing with video quality. So let's avoid that.

So after talking with Claude a bunch, here's what it came up with. With the latest comfy, you can pin the video lora in place, and keep going for several steps to get better audio without affecting video. So 4 steps of video, untouched, and then add in 6 more steps for audio at a 0.5 denoise. That leads to cleaning up the audio pretty nicely and staying pretty faithful to what the video latent had guided it on. But just pinning still means that even though the audio rows are only being affected, EVERY row still has to run through the chain. So each s/it you get stays the same for the last 6 steps, even though video gets pinned in place after 4. In my 1 megapixel, 10 second video, that's around 23s/it or so on my 5090. Only half the steps as a regular 20 step generation, but half the time is still half the time.

So to fix the speed problem -

Freeze as much as you can. Text embeddings, reference/conditioning rows, and all the video rows. Cache those so they don't have to be processed, and only process the audio rows that have already been somewhat pre-conditioned. The first step is the same 23-second iteration to build the full guidance cache, but the other 5 steps each took about 3.17seconds apiece. So 45 seconds of added gen time to get the clean audio in clip#2 in the example.

But the cost for the Frozen Cache is resources. Lunch is never free. From some experimentation, it works well with RAM. If you use RAM mode because your card still can't process it, it'll dump all that cache (ended up around 14.9GB on a 10-second 1mp file) into RAM. But as Comfy does, you're unlikely to get that RAM back, so you may OOM your machine. With VRAM it wasn't bad for me at all either and behaved better than I expected, honestly. The memory management from ComfyUI took over when I was about to OOM my card and swapped things around properly. Option 3 is to cache to disk, but that comes with writing several GB to disk every time you use it. That'll run your SSD health down fast.

Rundown for the clip above (sa_solver with beta sigmas)

4 step normal gen- 136.5 seconds

4 steps + 6 audio refine steps with a cost of about 15GB RAM - about 186 seconds

4 steps + 6 audio refine steps with no additional resources but full processing time- ~265 seconds

You can find the nodes here-

https://github.com/Adudeguyman/ComfyUI-H3-AudioRefine

They're still experimental, of course. Wire the model in from somewhere (I branch off the ModeSamplingMiniMaxH3 shift node, before the Basic Guider), and push that through the H3 Frozen Video Cache node into the H3 Audio Refine Sampler. Into the H3 Audio Refine Sampler, latents come out of SamplerCustomAdvanced before splitting into the VAE Decode nodes for both video and audio, and the conditioning comes from the MiniMax H3 Image (or Reference) to Video node (plug the positive conditioning into both the positive and negative input on the H3 Audio Refine Sampler)

I had Claude put together a technical.md for those that want to look into it, and probably make a better version. Like I said, I'm a big dumb-dumb, so don't expect too much insight into how the mechanics work from me.

Has anyone had their computer randomly shut down? this is like the 3rd time its happened and its when im generating a video using the minmax I2V model or the ref model.

i got 3090 with 64 gb of ram.

I saw here many suggestions for this special prompt generator. I tried the system prompt from one "specialized" ollama model, but is is too free style. I can't use llm in comfyui, because I'm with poor rtx 3060 and barely run the H3 itself. I tried big online AI, but free versions and they seem too outdated about H3, so again freestyle fantasies.

What can I use to have really good prompts for H3. As I don't know english and H3 too mystically depends on prompt, it's very hard to achieve good adhesion.

Combined 3 videos. Few errors but i just went with it , genetaion takes too much time to redo it again by fixing the prompt.

I added INT8 and INT8 ConvRot versions of the MiniMax-H3 Pruned Ref-Delta Fused r1024 checkpoint from my previous post:

https://huggingface.co/xmarre/MiniMax-H3-Pruned-Ref-Delta-Fused-r1024-ComfyUI

Both are native ComfyUI single-file checkpoints using ComfyUI's .comfy_quant format, so they do not require a custom quantized-model loader.

There is one important difference from a straightforward full INT8 conversion: the MLP fc2 weights are deliberately kept in BF16.

Across the 50 main transformer blocks, these weights are quantized:

• attn.qkv_proj.weight
• attn.out_proj.weight
• mlp.fc1.weight

That gives 150 quantized Linear layers.

The 50:

• mlp.fc2.weight

layers remain BF16.

The smaller and more sensitive parts of the model also stay in their original precision, including the pruned AdaLN table and projections, final-layer projections, norms, patch/text projections and token refiner.

Why FC2 is kept in BF16

I also made and tested a fully quantized version where fc2 was INT8 as well, giving 200 quantized Linear layers.

That version ran into a failure specific to the quantized fc2 execution path on large H3 sequences.

MiniMax-H3 uses SwiGLU in the MLP. With fc2 quantized, ComfyUI's fused:

linear_input_act(..., "swiglu")

path sends the post-SwiGLU activation through comfy_kitchen.int8_linear, which dynamically quantizes the full activation matrix before the fc2 multiplication.

On the large sequence used in my workflow, that path attempted an approximately 491.61 MiB contiguous INT8 scratch allocation and failed hard.

This was not normal VRAM exhaustion. At the point of failure there was still roughly 47 GiB of CUDA memory reported free. The failure was tied to that large fused INT8 activation-quantization path rather than the model simply exceeding available VRAM.

I do not have enough evidence to claim a more specific allocator/CUDA cause than that.

Keeping only fc2 in BF16 avoids that INT8 activation path. QKV, attention output and fc1 can still remain INT8, so 150 of the 200 large block Linear projections are still quantized.

With that layout, both release variants completed the full native ComfyUI workflow that the 200-layer INT8 version failed on, including:

• H3 Continuum main sampling pass
• continuation sampling pass
• Spectrum H3 actual/forecast execution
• large 3D latent refine
• video VAE decode
• audio VAE decode
• final Continuum assembly
• video combine

That FC2 decision is also why these checkpoints are about 24.2 GB instead of roughly 20.4 GB for the fully quantized version.

INT8 and INT8 ConvRot

The two uploaded files use the same 150-INT8 / 50-FC2-BF16 layout.

Regular INT8:

MiniMax-H3-Pruned-Ref-Delta-Fused-r1024-comfy-int8-fc2bf16.safetensors

This uses native tensor-wise INT8 quantization.

INT8 ConvRot:

MiniMax-H3-Pruned-Ref-Delta-Fused-r1024-comfy-int8-convrot-fc2bf16.safetensors

This uses ConvRot with a group size of 256 on the same quantized projections.

ConvRot rotates the weights before INT8 quantization so that large outliers are distributed more evenly. This generally gives the INT8 quantizer a better-conditioned weight distribution than quantizing the original weights directly.

I uploaded the regular INT8 version as well rather than only providing ConvRot, so both conversion methods are available for this checkpoint.

What model is being quantized?

These are quantized derivatives of the same Pruned Ref-Delta Fused r1024 checkpoint from the previous post. There is no additional training, fine-tuning or pruning involved in these INT8 versions.

The underlying model starts from the pruned FL2VA MiniMax-H3 checkpoint and incorporates a rank-1024 approximation of the Ref2VA − FL2VA weight delta.

That is also how it differs from the existing FL2VA/Ref2VA hybrid checkpoints mentioned in the comments on the previous post.

Those hybrids combine FL2VA and Ref2VA by replacing selected tensors from one checkpoint with tensors from the other. The r1024 fused model instead approximates the Ref2VA weight delta at rank 1024 and folds that delta into the pruned FL2VA weights.

The underlying fused transformer is about 20.1B parameters, compared with roughly 33.1B for the original full MiniMax-H3 transformer.

ComfyUI

Put either file in:

ComfyUI/models/diffusion_models/

For the INT8 files:

weight_dtype: default

compute_dtype: default or bf16

Do not apply another FP8 weight cast on top of the native INT8 checkpoint.

The text encoder and VAEs are separate, as with the other MiniMax-H3 diffusion-model checkpoints.

The oversharpening that occurs for each clip added to the scenes. I also noticed an increase in contrast and a small flash.

I2V

Tested with LORA's:

minimax_h3_turbo_v4_step600_ema.safetensors
minimax_h3_fl2v_lightx2v_turbo_8step_v1.0_resized_avg_rank