A 30-second H3 render that took down the host

This is the sibling to the LongMedia native 30s write-up: same goal (a coherent single-shot 30-second MiniMax H3 render on a 3090), different route. This branch (feature/h3-30s-attention-stack-test) tried getting there with a bespoke attention stack instead of shipped segmentation machinery, and it is the one that didn't make it.

The 5s control clip that succeeded: 864x480, h264+aac, 5.167s, 336,894 bytes, confirmed via ffprobe. The 30s arm never produced a file (it OOM'd the host during decode, twice), so there's nothing to embed for that arm; that absence is itself part of this write-up's result.

The hypothesis

The idea came from a r/StableDiffusion post claiming 570 seconds for a single-prompt 30s/0.4MP H3 render, using a native ComfyUI node (ModelAttentionBacked) to route into a custom attention module (SolAttn) plus a Spectrum step-skipping node, on top of the turbo LoRA now bundled in ComfyUI's own H3 template. That exact node doesn't exist on this box's pinned ComfyUI core (v0.31.1), confirmed by grepping comfy/model_management.py inside the container and by a public code search that turned up nothing. Rather than substitute Sage in its place (already tried and a wash on a prior branch), this test isolated the genuinely new part: SolAttn + Spectrum + the turbo LoRA, at two durations, everything else pinned identical.

What happened

5s control: succeeded. Build 4 (prompt 7dcbade2-d6d7-47ca-9228-7cedebfbb226) finished in 103.16 seconds server-side and produced a valid 864x480 h264+aac clip, 336,894 bytes. Slower than the project's existing no-extra-attention baseline (78.1s), which is expected overhead from the added stack, not a regression against a like-for-like comparison.

30s claim: failed twice, the same way. Builds 3 and 4 both loaded models normally, sampled for several minutes, then wedged during audio/video VAE decode with no execution_success or execution_error ever reaching the websocket. Only the build's own 30-minute safety timeout ended each attempt. docker logs for build 4 shows the process reach Requested to load MiniMaxH3AudioVAE/MiniMaxH3VideoVAE at 17:47:02 UTC, then go silent for 2.5 minutes until a container restart. Host dmesg for that exact window shows the kernel OOM-killer firing at the host level, not just inside the container: it killed an unrelated awk process and an unrelated fly process before killing comfyui-local's own python3 process, logged at anon-rss:50705572kB, roughly 50GB resident. This is host system RAM exhaustion, not GPU VRAM, a different failure signature than the OOM class this lab has hit before. Two reproduced crashes via the sanctioned Concourse path were treated as sufficient; a third attempt on a shared host was judged not worth the collateral-kill risk.

Chasing a generic fix: VAEDecodeTiled, ruled out by reading the source. The standard mitigation for a long-duration VAE OOM is swapping the monolithic decode node for a tiled one. Tracing comfy/sd.py and comfy/ldm/minimax/vae.py first (before touching any workflow) showed this specific VAE already runs handles_tiling=True with fixed internal defaults (256px spatial tiles, 17-frame temporal chunks), and its decode_tiled() method is literally return self.decode(z), discarding every kwarg the outer tiled node would pass in. Both node choices converge on the identical call. No third render was attempted because there was nothing left to try at that layer.

Chasing the fix again: rebuilding on LongMedia, blocked by design. Gavin asked to try rebuilding on the shipped segment-and-stitch suite instead. Reading its source showed why that wouldn't actually test this branch's hypothesis: MiniMaxH3LatentLabLongMediaSampler installs its own per-block attention wrapper that resolves via block.attn() or its own vendored Sol kernel directly, never delegating to whatever forward-wrapper this branch's SolAttn node had installed upstream. Wiring the stack into a LongMedia-based workflow would produce a render, but the "SolAttn" contribution would silently become dead code. No workflow JSON was written and nothing was rendered, because a working render that quietly tests something else isn't a result.

Where it landed

Refuted, cleanly. The 5s arm works; the 30s arm reliably OOMs the host during decode, twice, and no available mitigation (tiled decode, or rebuilding on the shipped segmentation path) survives contact with what this stack actually does. Something in the SolAttn+Spectrum decode path buffers far more in host RAM at 30s than at 5s, and root-causing exactly why (buffer accumulation in Spectrum's step-skipping cache, or un-freed intermediate tensors held across the full duration) was flagged as follow-up work needing non-shared hardware, not attempted here. The sibling branch's clean win came from using only shipped LongMedia machinery and hitting an unrelated, fixable bug instead of this one; this branch's failure is the more fundamental of the two, and it's the reason the register still counts this class of approach as refuted rather than merely blocked.