MiniMax H3 FlashVSR Plan / 质量与显存计划 (T8 Advanced EXP)

FlashVSR is a real video upscaler, but it has knobs - an attention budget, KV retention, a local window radius, and for tight VRAM a whole tiling strategy - and the T8 pack wants you to decide those before the heavy part runs. That's the whole job of this node: it looks at your frames, builds a "plan" describing exactly how the restore step should run, and hands it off. You wire it between the Model node and the Restore node and it quietly decides the boring stuff so the Restore node doesn't have to.

The nice part is the design: planning and execution are separate, so you can read what it decided in report_json before committing GPU time, and you can swap strategy without touching the sampler. The packed workflows ship three profiles that map to the three ways people actually use FlashVSR: fixed quality, motion-aware budgets, and memory-safe tiling.

How it works

The node takes your frames, downsamples them to a small grid, and measures per-chunk motion from frame-to-frame pixel deltas. Then it works out how the video gets split into 8-frame chunks (FlashVSR's streaming core processes the clip in overlapping groups), and assigns each chunk an attention budget. The three quality_profile options change what that assignment looks like:

• quality_locked (default) - every chunk gets the fixed, publicly-published LCSA budget: 2.0 / 3.0 / 11. Predictable, comparable, and what the README tells you to start with.
• balanced_dynamic_exp - opt-in experiment. Only interior low-motion chunks get their budget reduced; the first and last chunks and any high-motion chunk stay at the baseline. It trades a bit of quality for speed where the eye won't notice, but it changes the mask per chunk, so it's not bit-exact and you're expected to watch the full result.
• memory_safe - keeps the fixed 2.0/3.0/11 budget but routes through same-seed feathered tiles with staged offload, at the cost of being slower.

The spatial_strategy and memory_policy inputs default to auto, which picks full_frame/resident normally and adaptive_tiles/staged when you choose memory_safe - you mostly won't touch them. The three numbers that actually define quality are base_attention_budget (2.0), kv_retention (3.0), and local_radius (11): these are the top-k, KV-ratio and local-window values for the LCSA attention mask that the Restore node dispatches to the spas_sage_attn kernel. The plan is validated by schema when Restore consumes it, so a hand-edited or stale plan fails cleanly instead of doing something undefined.

Inputs and outputs that matter

The ones a beginner actually sets: quality_profile (start quality_locked), frames (the decoded clip you're upscaling), and if your card chokes, memory_safe plus the advanced tile_size (default 256) and tile_overlap (default 24). The two outputs are plan, which feeds the Restore node's plan input, and report_json - a human-readable report listing the chosen spatial/memory strategy, frame count, denoise chunks, and a per-chunk table of motion scores and assigned budgets. It's worth a glance once: it's the only way to see why a chunk got a reduced budget.

Getting it installed

It ships inside the MiniMax H3 Audio T8 pack, so it's one install for all four nodes in this chain: ComfyUI Manager → search "MiniMax H3 Audio T8", or

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git minimax-h3-audio-T8

then restart. This node itself has zero extra dependencies - it's pure planning math. The dependencies live on the Model and Restore side: the FlashVSR v1.1 model folder in ComfyUI/models/FlashVSR-v1.1 (plus the posi_prompt.pth the HF repo omits) and a spas_sage_attn wheel matched to your Torch/CUDA. And the usual T8 gotcha applies: update ComfyUI core + frontend + Manager together first, or every node in the pack goes red on startup.

Where people get burned

• Treating balanced_dynamic_exp as a free speed-up. It's an experiment that changes per-chunk budgets; on a low-motion clip it's nearly free, on a motion-heavy one it can soften detail. The author's own workflow docs say to watch the full result. Default to quality_locked.
• memory_safe not being free either. It trades VRAM for time. Tiling with overlap can be dramatically slower - the community's own FlashVSR threads describe tiled runs as far slower but using under a third of the VRAM.
• Forgetting the plan node entirely. It's optional in the sense that a default plan is easy, but you do need it in the graph - the Restore node won't run without a plan input wired.

One honest caveat from the pack itself: this is video restoration, not a way to recover detail the source already lost. No budget tweak brings back missing lip sync, identity, or true texture - 4× FlashVSR refines what's there, it doesn't invent the missing bits.