Good question, and my sentence is what misled you, sorry. "ref2va treats a keyframe as a suggestion; fl2va treats it as the task" is about keyframes (a frame you want the video to pass through), not about reference pictures (identity). Two different mechanisms, and for what you're describing you want the other one.

For one picture, same person, different environments: ref2va, not fl2va.

fl2va has no reference rows at all. If you hand it an identity picture it is ignored entirely — there is nowhere in that checkpoint for it to live. What fl2va conditions on is the first and last frame, so it plans a travel from A to B. Chain it and shot 2 opens on shot 1's closing frame, which carries the whole picture forward: the person, but also the room, the light and the framing. That's exactly what you don't want when the point is a new environment each shot.

ref2va's reference rows bind at t=0 and hold the subject rather than the frame. That's the mechanism built for your case, and it's why you're getting worse consistency than Wan 2.2 across a cut right now — on fl2va there is nothing binding identity across that cut in the first place.

The recipe:

- ref2va checkpoint.

- continuity = cut. No keyframe, every shot a fresh take, identity carried by the reference bank. Framing and exposure step between shots, which is what you want from a cut.

- Feed the identity pictures through H3 Ref Folder — up to 9. More angles of the same face beats one picture repeated; front, three-quarter and profile is a good minimum.

- If more than one person is in the scene, set reference_subjects — 3,3 means pictures 1-3 are person A and 4-6 are person B. Without it, different people blend into one face.

Note the "keyframe as a suggestion" caveat doesn't apply here at all, because in cut mode you aren't using keyframes.

One thing that surprised me and is worth stealing: shot 1's own rendered audio works as a ref2va voice reference for every later shot, so the voice stays the same person across the chain too, not just the face. Verified in both directions. If you're chaining dialogue that matters more than it sounds like it should.

On Enhance-A-Video: nothing equivalent that I know of for H3, and I'd rather say so than point you at something that isn't the same thing. If someone builds it I'll link it.

And yes — early days. Most of what's in the pack came from finding out something didn't work the way the docs implied, so if the above doesn't hold up on your material, tell me what you saw and I'll dig.

@HugMeIntoFace Are you using my workflows? Any chance you could open a discussion here: joeygambino/MiniMax-H3-Multishot-Workflow · New Discussion


It'll be much easier to troubleshoot with you.

@HugMeIntoFace Understood. The reason I've built my workflow is because character consistency was difficult to come by in the basic ComfyUI workflows. Every shot prompt you write, you have to describe every single detail of your character, word for word, their position on screen, identically, or your prompts become more of a suggestion than a definite. My workflows do a lot of that internally with toggles in the Sampler and automatic references, even for voice consistency. That's the only real advice I can give for it - your character's description has to be 100% word for word identical in every single shot. If you're using a workflow with reference images or keyframes, use them.

Yeah, I screwed up and uploaded the wrong ones. The right ones are going up now. Sorry!

@Dasher787

Two things are probably going on, and one line of your log will tell us which.

First, check whether nvfp4 is actually running natively. When ComfyUI loads a comfy-native quantised model it prints:

Native ops: int8_tensorwise, nvfp4, mxfp8, asym_w4a8_int8, ... | emulated ops: ...

That line is the only reliable statement of what your machine can do, and nothing in the UI tells you otherwise. NVFP4 needs Blackwell tensor cores, which your 5060 Ti has - but it also needs a recent enough ComfyUI to use them. I have measured the same file run native on one build and emulated on the same card 22 minutes later after nothing but an update.

Your timings are what emulation looks like. At 11.67 GB the nvfp4 fits in your 16 GB outright while the 19.53 GB int8 has to offload - so nvfp4 should be clearly faster, not 108s against 106s. Tying on speed while fitting in VRAM means the compute penalty is eating the offload win. If that line says emulated, you are paying 4-bit quality for zero 4-bit speed, and the answer is simply to use int8 on that machine.

Second, 4 steps is thin for this. Our tested policy here is 10 steps on the reference path and 12 with no reference, euler/beta - a 6-step ladder got overruled by eye. Quantisation error shows up worst where sampling is thinnest, and "noticeable motion blur" at 4 steps is exactly where an under-sampled turbo render and a low-precision weight set compound each other. Before concluding the file is bad, re-run the same A/B at 10 steps. If the gap closes, it was the step count interacting with the quant rather than the quant alone.

There is a better option for your card than either of these. A w4a8build is going up on this page now - 11.68 GB, so it fits your 16 GB the same way nvfp4 does, but asym_w4a8_int8 is native much further back than NVFP4 is.

I have it running native on a 3090 here, verified over ten consecutive chained shots at a flat ~45 s/it, and your 5060 Ti is newer than that card.

One caveat: the format did not exist in ComfyUI 0.30 and raises a KeyError there, so you need a current build - which you will want anyway for the reason above.

If nvfp4 is emulating on your machine, w4a8 is the file that gives you the small size AND native execution instead of making you choose.

And the general rule, which I should have put on the model page: a file fitting in your VRAM does not mean it runs natively. Pick a comfy-native quant by architecture first and size second. On a card and build where nvfp4 is emulated, the bigger int8 is the better model in every way that matters.

For what it is worth I have seen nvfp4 underwhelm here too on a high-resolution render, so you are not chasing a ghost. If you post the Native ops line I can tell you which of the two problems you have.

Mine just landed.

nvfp4 is in your native list. It is running on your Blackwell tensor cores properly and emulation has nothing to do with what you are seeing. I guessed emulation because your timings look exactly like it: 11.67 GB fits your 16 GB outright while the 19.53 GB int8 has to offload, so nvfp4 should have won on speed by a wide margin rather than tying at 108s against 106s. That reasoning was wrong. At 0.5 MP over 5 seconds at 4 steps the run is short enough that model load, text encode and VAE dominate the wall clock, leaving almost no

matmul time for a faster format to save. Your speed test is being masked by the workload being small, not by the format being emulated.

So the quality difference you are seeing is real 4-bit precision loss, not a broken build. That is worth knowing rather than chasing.

Two things I would still try before settling on int8. Raise the step count. 4 steps is thin. Our tested policy here is 10 on the reference path and 12 with no reference, euler/beta - we tried a 6-step ladder and it got overruled by eye. Quantization error shows up worst where sampling is thinnest, and "noticeable motion blur" at 4 steps is exactly where an under-sampled turbo render and a low-precision weight set compound one another.

Re-run the same A/B at 10 steps. If the gap narrows, the file was never the whole story.

Testing Kijai's in the meantime is exactly the right move. w4a8_int8 is in your native list, it is the same ~11.7 GB class as nvfp4, and it keeps activations at 8-bit rather than going 4-bit throughout. I run it natively on a 3090 here, verified over ten consecutive chained shots at a flat ~45 s/it. I have NOT done a controlled nvfp4-vs-w4a8 comparison at identical settings, so I will not promise you it is better - but on your hardware both are native, so whatever you measure is a clean result.

If neither closes the gap, use int8. On a 16 GB card it offloads and still comes in at 106s for you, which is a completely reasonable price for the quality you said you preferred. I do have an int8 going up now as well, could be an hour though. I haven't done an A/B between mine and Kijai's to know if they're any different though - I didn't even know he put any up yet, I thought he just had LoRA's.

@Dasher787 Could you open a discussion on HF (joeygambino/MiniMax-H3-Multishot-Workflow · New Discussion) and add a video to it, so I can grab the meta data and look at your workflow? Or export the workflow?

Are you using all of the same settings for both INT8 and w4a8?

I can understand the quality difference - but the speed just doesn't make any technological sense.

AH DAMNIT. Re-uploading now.

@clevenger Civ just likes to do whatever it wants. There must be some magic naming convention I am not aware of that I followed accidentally to get it to work this time.