A 5090 can reportedly keep FastH3 on air. That is not the same as a live 24-fps show.

There is finally a consumer-GPU channel claim worth opening

Community project says: FastH3 Live runs on one RTX 5090 (32 GB) under Windows 11 with ComfyUI. Its v1.2.0 dataset card says it sustains 22.1 fps at 448×448 after using a four-step dense FastH3 conversion, a faster attention path, a different text-encoder quantisation, and a custom video writer.

That is a serious change from “local H3 is only an offline clip tool.” It is still one author’s result on one machine. This pool has not downloaded the gated files, run the workflow, or independently checked a long stream.

The channel stays continuous by changing the output contract

Community project says: FastH3 authors motion at 24 fps. The project plays its 362 generated frames at the rate its measured run can sustain, with matching audio retiming. Its own earlier 18-fps example turns 15.08 seconds of native-speed frames into 20.11 seconds of playout—75% motion speed—and says mid-speed people are where the slowdown becomes obvious.

Its current 22.1-fps claim is closer to native speed, but still is not a 24-fps result. The project also chose a square 448×448 canvas around decoder-tile cost. That may fit a deliberately paced character or atmosphere channel. It is not evidence that a normal 16:9, native-motion, viewer-driven show will keep up on the same card.

“No queue” is not the operating model

Community project says: the stream generates the next clip while the prior one plays and keeps two prompts in ComfyUI’s queue so the GPU is not idle. Its scene library rotates self-contained prompts and characters. That is a sensible playout pipeline for an unattended feed.

It does not demonstrate a viewer’s new instruction arriving in the current scene, durable character or camera state across clips, a recovery from a failed render, or what the audience sees when the ready work runs out. Treat it as a local AI-TV route, not an interactive-session route.

Do not merge FastH3 variants into one benchmark

Project says: FastVideo’s current FastH3 example distinguishes dense and VSA attention paths from the adapter payload. The one-5090 project says it uses a dense conversion because stock ComfyUI does not preserve its VSA gate tensors. That makes its timing a named workflow result—not a consumer-GPU version of Reactor’s documented VSA B200 profile.

What to ask before you call a one-GPU stream viable

1. What are the canvas, source-frame count, delivered fps, and native-motion speed?
2. Which FastH3 checkpoint, quantisation, attention path, node versions, host RAM, and operating system produced it?
3. How many clips are ready or in flight, and what happens after a slow render or retry?
4. Are scenes deliberately independent, or must a viewer’s choice survive into the next clip?
5. What did people actually think of the motion, artifacts, framing, and audio after a long watch?

For now, the honest claim is narrower and more useful: a community project reports a continuous, locally generated FastH3 channel at a source-stated sub-24-fps pace on one 5090. That is a format to test—not a blank cheque for “real-time AI video.”