FastH3 V2 · Accepted LOW / HIGH Context Port (T8 EXP)

FastH3 V2 is a distillation, not a speed-up knob. FastVideo's 8-step student is a separate full checkpoint (int8 convrot, around 22GB on disk - which is not 22GB of VRAM) that replaces H3's schedule with a fixed DMD table and finishes in eight forward passes. Different weights, different maths. Do not stack it on top of the EMA-B acceleration LoRA and call it an upgrade.

The awkward part is long video. A distilled student plus the old 4+4 continuation recipe works, but the piece that glues the two halves - the selected clip you are continuing from - was buried inside an all-in-one node. These ports pull it out.

What this node exposes

You give it the authenticated accepted-window contexts object (the same typed thing the continuation chain builds by selecting and preparing an accepted parent) and a phase of low or high. It hands back a single native context for that phase.

What differs between the two phases is the source of the context, and the author is precise about it:

• low - the accepted picture, resized to RGB24 and VAE-encoded. This is the picture-derived context a continuation needs for motion guidance.
• high - the completed AV tail. This is the finished segment's latent-side context, used at the resolution stage rather than as a guide.

Outputs are context, plus segment_index, context_frames, width and height as integers for wiring, and report_json recording which accepted source the context came from.

Where it plugs in

Both phases feed a separate native Long Video or Prompt Relay conditioning node - the context output is the native context type, so it goes where a long-video context normally goes. There is no hidden sampler here and, importantly, no dependency of the HIGH context on LOW's conditions. LOW and HIGH can run different models, different LoRAs and different prompts.

If you are adding Relay plans to a V2 graph, the pack's own docs say to use the dense compatibility profile: the trained VSA path has no adapter for Relay's per-query time bias, so Relay plus trained VSA is a combination the author declines rather than approximates. That is a documented boundary, not a bug you can work around by connecting the wires anyway.

Install

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

Restart ComfyUI fully - registration is at import. Manager search: "MiniMax H3 Audio T8". The pack installs no pip packages, by design, so it cannot replace ComfyUI's Torch/CUDA stack; the FastH3 V2 student does not need FastVideo's distributed runtime either. What you do need is the V2 checkpoint itself:

fastvideo_fasth3_8step_v2_pruned_int8_convrot.safetensors
→ ComfyUI/models/diffusion_models/

Pin the revision the pack documents (0de92ab26fcb74ee47596332d93e55d20cddfd45), and check the size and SHA - 22,128,378,696 bytes, SHA256 0922785978dc9bfe1adf27d8b291b0ca763f9f165f882e6cb297c72fbb6deda8. The Qwen encoder and the native video/audio VAEs are reused.

Things that will bite you

The context is the accepted parent's, not yours. If you edited the parent since accepting it, the port still describes the accepted revision - that is what "authenticated" means here, and it is the same warning the source node carries. Changing any upstream input invalidates the binding and the node refuses until you rebuild it.

If you are coming from the older 4+4 workflow expecting one node to do everything: it does not. This is the first of several ports - the context here, a reconcile node for the joint audio, a HIGH prefix node, and a delivery-window report. The payoff is that each one can be inspected and saved, and the cost is that wiring all of them correctly is a real task. Budget an evening, not ten minutes.