MiniMax-H3 Multishot — chained shots, one master, with audio — v1.0 — v2.2.3 More Mem Fix

Three changes: the timeline is now assembled into one preallocated buffer, releasing each shot as it is copied (bit-exact — the same bytes as before); frames are parked as fp16, which is well clear of the 8-bit the encoder writes anyway; and master normalize upcasts to fp32 for its arithmetic and writes back, so the memory saving costs no precision.

Effect: six shots of 243 frames upscaled drops from ~70 GB peak to ~21 GB. Twelve shots of 192 frames drops from ~58 GB to ~31 GB. Both now fit in 64 GB with the per-shot upscale unchanged. Diagnosed by a second operator on a 3090 box; thank you.

Fixed: the auto-reserve inflated its own estimate until the render spilled

If your chains got slower as they went — shot 1 fine, shot 3 sluggish, shot 4 crawling — this is why. After each shot the pack measures how much activation memory that shape needed. It subtracted the weight bytes currently resident rather than the model's full size, so whenever the model was only partly loaded the measurement came out too large by exactly the amount that had been offloaded. That number then raised the next shot's reserve, which left less room for the weights, which offloaded more.

shot 1 recorded 6.4 GB true 6.4 (full load - correct) shot 2 recorded 8.0 GB true 5.3 (2749 MB offloaded) shot 3 recorded 8.9 GB true 4.3 (4784 MB offloaded) shot 4 asked for 19.9 GB -> clamped -> 262 s/step

The overstatement equals the offload every time. The measurement now uses the model's full size, and a shot that offloaded weights records nothing at all — it measured a spill, not an activation pool.

The cache also only ever grew, so a single bad shot poisoned a shape permanently. Entries written by earlier versions are dropped once on first load; you will see a line saying so, and those shapes re-measure on their next run.

This does not make an over-committed render fit. If a shot honestly needs more memory than the card has you still have to lower frames_per_shot or resolution — the difference is that the warning now fires on true numbers instead of the reserve quietly climbing.

Fixed: the sol_attn and chunk_ffn switches did nothing

Reported by sdktertiaire2 . Those switches shipped ON, but the nodes they gate ship bypassed — they need third-party packs that cannot be bundled ( ComfyUI-sol-attn , comfyui-minimax-h3-blockcache-T8 ). A toggle routing into a disabled node changes nothing and warns about nothing. That contradictory default was mine.

Both now ship OFF so the panel states what the canvas actually does, and the panel is labelled with the fix: install the pack, then select the node and press Ctrl+B to un-bypass it. The switch only routes; it cannot enable a bypassed node. If you do not want those packs, leave the switches off and lose nothing — they are speed and memory optimisations, not quality features. Everything renders identically without them, just slower.

The nodes stay bypassed on purpose. Enabling them by default would hard-fail every install that lacks the optimizer packs.

2.2.2 — the reference block was forcing glasses on everybody

One fix, reported by a user against 2.2.1. If you render with reference images, take this one.

Fixed: reference renders forced glasses onto the subject

Reported on Civitai: a reference image produced a character wearing thick black frames in every shot, and prompting to remove them changed nothing.

The pack injects a retention_analysis block alongside reference images so identity and voice stop drifting across a chain. That block was hardcoded to say the subject "retains the same face, skin, hair, glasses and wardrobe" - so every ref2va render was told to keep glasses whatever the prompt said. And it could not be argued with, because the sampler runs on a BasicGuider : cfg 1.0, no negative branch . There is nothing for a negative statement to subtract from, so "remove the glasses" only put the word into the conditioning a second time.

The block now says "the same face, skin and hair" and names no accessories. Eyewear, hats and jewellery belong to your prompt.

The rule this exposes, and it applies to every prompt you write for this graph: anything hardcoded into unconditional conditioning is permanent from your side. At cfg 1.0 you can add but never subtract, so phrase everything positively - "clear unobstructed eyes", never "no glasses". Negations do not work anywhere in this pack.

2.2.1 — three crashes, all of them after the expensive part

A bug-fix release. Four defects, three reported from real renders on real machines rather than found in review. If you have been unable to finish a long chain, or a high-resolution one died partway with the whole server going down with it, this is the release for you.

Fixed: two crashes that only appear on long or high-resolution chains

Both were DefaultCPUAllocator: not enough memory — system RAM, not VRAM — and both killed the job after it had already done the sampling.

master_normalize built the entire finished timeline four times over. A 12-shot 1088x1920 chain asked for a single 31.2 GB block and died on a 24 GB machine after 81 minutes of work. One of those four copies was pure waste: the code rebuilt a tensor byte-for-byte identical to one already in memory, purely to compute two numbers for a log line, then threw it away. Every statistic it needs is one-dimensional. It now measures per shot and releases each shot as it is consumed, so peak memory is one finished timeline plus one shot instead of four timelines. Output is bit-identical — verified against the old implementation across every colour mode and median width, on the pixels and on the log strings.

The upscaler was handed every frame at once. 243 frames at 1472x2560 is an 11.0 GB float32 allocation on top of the input. It now runs in chunks into a preallocated buffer, so peak is one chunk rather than the whole batch. Bit-identical, verified at two chunk sizes. Set H3_UPSCALE_CHUNK if you want to trade memory for a little speed; default 16.

Fixed: auto-reserve could clamp itself into a hard crash

On a 12-shot 1280x736 run, shot 1 loaded completely and rendered fine. Shot 2 carries the context pin and the reference rows, so its activation-pool requirement roughly doubles — the node correctly costed it at 18.2 GB. It then clamped the pool to 9.4 GB "so the weights still load completely" , and the weights loaded partially anyway , 401 MB offloaded. Neither constraint was met and the render aborted inside a CUDA kernel, taking the whole ComfyUI process with it.

Two causes, both fixed. The keepout was 384 MB , which did not cover ComfyUI's own buffer plus the difference between what the driver reports free and what ComfyUI treats as usable — about 400 MB short. It is now 1 GB . And the "this is tight" warning compared the clamped reserve against a previous shot's measurement rather than what this shot had just asked for, so a 9.4 GB clamp looked fine against shot 1's 9.1 GB while the payload needed 18.2. It now compares against the real request and says plainly that this usually dies inside a kernel, and that raising the reserve cannot help because the memory is not there.

Worth knowing regardless of this fix: shot 1 succeeding tells you nothing about shot 2. Shot 1 has no pin and no reference rows. If shot 2 will not fit, lower frames_per_shot or the resolution, or load a smaller quantisation of the DiT.

Fixed: start_image on the memory sampler silently did nothing

Reported by a user. start_image on H3MultishotMemorySampler is an identity reference row , not a first frame — and on an fl2va checkpoint, which has no reference rows, it is built and then ignored entirely. Meanwhile the sibling node H3MultishotSampler has an input with the same name that really is an I2V first frame, which is where the perfectly reasonable expectation comes from. The combination produced no warning at all.

It now prints one, naming both ways to actually open shot 1 on a picture: use H3MultishotSampler , whose start_image is a true first frame, or set continuity=flf_chain here and feed keyframe_images (N+1 stills for N shots). Note that continuity=first_frame is not about your image either — it hands over the previous shot's last frame, and does nothing on shot 1.

Verified

Three chained shots rendered end to end on ComfyUI 0.32.0 with the new auto-reserve: every shot full load: True , which is exactly where the crashing run went partial, and the new warning fired on shot 2 with real numbers and did not stop the render. master_normalize ran on that same 685-frame chain. The chunked upscaler is proven bit-identical by test rather than by render — that graph had upscaling off, so I will not claim end-to-end coverage it did not get.

2.2.0 — everything since 2.1.2, in one post

Seven point releases folded into one version, because 2.1.2 is where most people still are. Five separate defects that stopped the workflow running , a measured campaign against drift over long chains that changed the shipped defaults, and a whole ComfyUI version this pack could not previously run on.

the Audio Spine produced static on ComfyUI 0.32.0

naming an mmproj file broke GGUF text encoders

The value 1 for reference_image_size is not available

the full workflow needed a node from a pack that is not in the zip

H3_Seamless_Chain_CORE could not be queued at all — the no-third-party-dependencies workflow, un-runnable since 2.1.3

New controls: pin_frames , pin_noise , pin_renorm , and master_normalize 's luma+contrast mode. Changed defaults that change your output: memory_frames 2 → 0 , and join_anchor_noise / handoff_release to 0 because they are inert under context_pin . New runtime: ComfyUI 0.32.0 ; 0.30.0 is unchanged and still supported.

Everything below is the original note for each version, newest first.

2.1.9 — CORE could not be queued, and bypassed nodes now say what they need

If you use H3_Seamless_Chain_CORE , it has been un-runnable since 2.1.3. Queueing it failed with:

value_smaller_than_min: Value 0.0 smaller than min of 1.0 - output_scale

Its sampler still carried the widget array it was saved with before 2.1.3 removed the four two_pass_upscale dials . Nineteen saved values against the class's fourteen live widgets, so the frontend put false into output_scale (minimum 1.0) and 1.5 into save_every_shot , and the server rejected the whole prompt. The workflow advertised as the one with no third-party dependencies — the safest thing for a new user to open — was the one that could not run.

It survived because CORE had never been rendered end to end . Our own release checklist said "one CORE render before posting" and that line rode along, unticked, through six releases.

The array is now generated from a name→value map resolved against the server's own schema, with the map stored on the node so it can be re-applied by name. CORE has now rendered: three chained shots at 960x544, 370 frames, picture and audio, holding framing, wardrobe and lighting across both joins. All three bundled workflows are...

Text encoder · Unknown