An endless AI TV channel on a single gaming GPU — MiniMax H3, generating faster than it plays

There is a video stream running on my desktop right now. It has sound, it has never repeated itself, and it will not stop. I point VLC at a local URL and it plays. One RTX 5090 does all of it — no cloud, no queue, nothing else running. It is MiniMax H3, generating locally through ComfyUI. H3 is an open-weights video model that produces picture and synchronised audio together from one text prompt — dialogue, room tone, footsteps — which is what makes this a channel rather than a montage with music over it. I run the 4-step FastH3 distillation of it, because the base model needs far more sampling steps than the arithmetic below can afford. The reason this is hard: to stream continuously, generation has to outrun playback. Not "fast enough to be impressive" — genuinely faster than a person watches, indefinitely, or the buffer drains and it stalls. Each clip is 362 frames. I have to finish the next one in less time than it takes you to watch this one, every time, forever. What it actually looks like Every clip is a scene drawn at random, cast at random. So you get Jean-Luc Picard grilling skewers at a night market. A Klingon, RoboCop and Jack Sparrow crowded around the same workbench. Four people arguing across a kitchen table about who signed something, and the camera cuts to a close-up at the seven second mark because the prompt told it to. 321 hand-written scenes, 503 characters, and the scenes that call for an ensemble draw three to five distinct people. The combinations run into the trillions. In practice it means you can leave it on, and it stays interesting in the way a channel you do not control is interesting. https://preview.redd.it/q2i7fvihq4nh1.png?width=1269&format=png&auto=webp&s=8ca556f65ddad3b34b85ffb9e096fb49baf6e721 A frame from a continuous run — five characters who could never share a room, and the two clocks that make the point: after ten clips it is 3:08 of video against 3:02 of GPU time. The gap is what lets it run forever. Everything is here, weights included — https://huggingface.co/datasets/jacokon/fasth3-live The rest of this post is how it got fast enough to work. The honest caveat, up front H3 authors motion at 24 fps. A clip is 362 frames — 15.08 seconds of content — and I play it at 18, so the motion runs at 75% speed. This is not real-time 24 fps generation and I am not claiming it is. What it is: 20.1 seconds of video produced per 19.2 seconds of GPU time, which is what makes it continuous. Whether 75% reads as slow motion depends on the subject. Fast subjects (rain, sparks, a train) look deliberate. Near-static scenes look normal. Mid-speed human motion — walking, hands working — is the worst case and you can tell. Where the time actually went The FastH3 student ships as 66 GB of diffusers weights, which do not fit on one card; converted and quantized to INT8 they come down to 21 GB, which do. With that, sage attention, and an INT8 VAE, a 15-second clip took 26.5 seconds to generate. Playback needs 15. That gap is the whole problem, and I spent a while optimising the wrong things because I did not know where the time was going. https://preview.redd.it/v91ypeker4nh1.png?width=1369&format=png&auto=webp&s=d6e0bded61f88345816b8eb04f0d81c0427b2cd0 Where one run's 19.2 seconds actually goes — the per-node breakdown and the four changes, on one card. ComfyUI's /history reports one number for a whole prompt, which cannot tell you whether the cost is the text encoder, the sampler or the VAE. Its websocket emits an executing event as each node starts, so the gap between consecutive events is that node's duration. That is about forty lines (profile_h3_nodes.py), and it changed what I worked on completely. Two of the four findings surprised me. 1. SaveVideo was a fifth of every run — 3.78 s ComfyUI's SaveVideo encodes through PyAV in a Python loop that, per frame, allocates a float array, clips it into a second, casts into a third and copies out a fourth. 362 frames of that is 3.78 s. ffmpeg alone does the identical payload in 0.21 s. It was also producing a file my streamer re-encoded a second later anyway. VHS_VideoCombine is better (1.31 s) — it pipes raw frames to ffmpeg — but it still iterates in Python and re-opens the finished file to mux the audio. I wrote a node that converts in chunks and muxes in one pass: 0.73 s. Then it hands the encode to a background thread and returns, so ComfyUI starts the next prompt instead of holding an idle GPU. The graph now sees 0.26 s. No hardware encoder involved. h264_nvenc measured slower end to end than libx264 — the encoder was never the bottleneck, and it has to stand up a second CUDA context on an already-full card. 2. The VAE bills by tile, not by pixel MiniMaxH3VideoVAE hardcodes tiling=True, tile_size=256, and split_tiles hands each pass a full tile regardless of how much picture is in it. Decode time tracks the tile count and barely notices the resolution: resolution pixels tiles VAE decode ---------------------------------------------- 320x192 61,440 2 2.35 s 512x288 147,456 6 6.98 s 576x320 184,320 6 6.31 s 768x432 331,776 8 8.74 s 512x288 and 576x320 differ by 25% in pixels and by nothing in decode cost. A side of length L costs: 256 or less is 1 tile, 257–448 is 2, 449–640 is 3, 641–832 is 4. So the cheap shapes sit just under a boundary. 448x448 needs four tiles where 576x320 needs six, while carrying 9% more pixels. That is why the stream runs square — not taste, just where the arithmetic lands. There is no 16:9 shape at four tiles that clears the resolution floor. I did try raising tile_size to reach a single tile. Do not. The decoder is a ViT, so its attention spans exactly one tile; a larger tile is out of distribution, not merely approximate. 384 visibly softens hands and faces (PSNR 27.2 dB against the stock decode); 640 smears the image into strokes (22.1 dB). 3 and 4, more briefly Quantizing the video VAE below INT8 buys no speed — INT8 already runs an INT8 matmul, and a W4A8 build expands back to INT8 for the same one — but it stages 1,657 MB of host RAM instead of 2,677 MB, and on a box holding ~41 GB of staged weights against 64 GB that gigabyte turned into both speed and a much tighter spread. And keeping two prompts in ComfyUI's queue instead of submitting one and waiting removes the idle gap between jobs. Result per clip sustains ---------------------------------------------- starting point 26.5 s 13.7 fps + writer node, async 20.2 s 17.9 fps + W4A8 VAE 19.9 s 18.2 fps + 448x448 19.2 s 18.9 fps The model did not change. Only how it is driven. If you came here wondering about ComfyUI and consumer cards That question is all over the FastH3 announcement thread and I had to answer it for myself, so: this is a ComfyUI-native conversion of the Dense-DataFree student, pruned and INT8, 21 GB, driven through the ordinary graph. Two things I found doing it that are worth passing on: The VSA weights do not survive stock ComfyUI. They carry 50 to_gate_compress tensors it has no code for, so it drops them silently and the output is noise. Dense converts cleanly. That is why I am on the slower student — if ComfyUI gains VSA support there is headroom here I am not using. NVFP4 measured identical to INT8 ConvRot. The FP4 fast path only fires when both operands are FP4; activations are BF16, so it dequantizes and runs at BF16 speed — 67.88 ms/block against BF16's 67.85. Someone reported the same on an RTX 6000 Pro. Worth knowing before anyone rebuilds a pipeline for it. Where this sits, so you can place it None of the speed here is mine — it is FastH3, the 4-step distillation Hao AI Lab, Nuva Lab and NVIDIA's FastGen team built on MiniMax's base weights. Without that student none of this is close. Their published benchmarks are 47.2 s for a 15-second 768p clip on a single B200, 12.88 s on 8×B200, and their consumer write-up covers Apple Silicon and DGX Spark with the RTX family listed as future work. What I did is a different task, not a better score on theirs: a fifth of the pixels, and playback at 18 fps instead of 24. Those two concessions are the entire trick. What they buy is that the arithmetic closes — 19.2 s of GPU per 20.1 s of video — and that is the difference between a fast generator and something you can leave running. If you want 768p, their numbers are the ones that apply and mine are irrelevant. https://huggingface.co/datasets/jacokon/fasth3-live The converted 21 GB weights, the quantized VAE, the 321-scene library, the writer node and the profiler. Everything above is reproducible from it. What it takes, so you can judge before downloading 21 GB: about 48 GB of weights are staged in total — a 25.9 GB text encoder, the 20 GB DiT, and the two VAEs. That does not fit in 32 GB of VRAM either, so ComfyUI streams it layer by layer from host RAM. On this box that streaming, not the arithmetic, was the thing to optimise: 48 GB staged against 64 GB of system RAM was tight enough that page-file pressure showed up directly in the clip times, and freeing a single gigabyte measurably tightened them. If you get it running, post your numbers. I have measured exactly one machine, and both findings that mattered came from measuring rather than reasoning, so I would rather not guess about anyone else's. I am interested in what it does on other hardware and, just as much, in where it falls over. And if it turns out useful, a like on the HF page is what makes it findable for the next person. Code is Apache-2.0. The weights are a MiniMax H3 derivative under the H3 Community License, which carries a territory restriction — read NOTICE before downloading. Live Demo: If you want to check out a short snippet of the continuous streaming output (with the model's native character generation), I've uploaded a TV-style demo recording here on X: https://x.com/Touma_945/status/2095141879453270385 submitted by /u/spartong945 [link] [comments]

Source: r/StableDiffusion | 2026-09-02

Related