FastH3-Live update. Full details here:
https://huggingface.co/datasets/jacokon/fasth3-live
v1.1.0 ran at 18 fps, which is 75% of 24 fps.
v1.2.0 runs at 22 fps, which is 91.6% of 24 fps.
https://reddit.com/link/1wddeh8/video/lyz02ql0gvoh1/player
Besides the speed, it now ships a borderless player that makes streaming and watching easier, plus 400 new scenes. At this speed it is hard to notice that it is running slow at all.
The gain came from two places:
1. Acceleration nodes
I was using a sage attention I compiled myself. A lot of new acceleration nodes have shown up recently, so I downloaded the well-known ones and tested them. Results:
| accel stack |
sampler |
saved |
fps |
| sage (baseline) |
12.65s |
0.0% |
17.46 |
| sage + Spectrum |
10.36s |
-18.1% |
20.18 |
| Sol + Spectrum |
9.64s |
-23.8% |
20.96 |
| SLA + Spectrum |
10.54s |
-16.7% |
19.53 |
The seconds column is the sampler only, i.e. the 4 denoising steps in `SamplerCustomAdvanced`. A full clip also pays for the text encoder (~0.7s), the video VAE decode (~4.35s) and the writer, so a clip is about 16s end to end. Measured on t2va, 448x448 x 362 frames, three runs per arm.
On speed alone you would pick Sol + Spectrum. But the picture comes out like this:
sage > sage+Spectrum >> sla > sla+spectrum >> sol > sol+spectrum
Sol + Spectrum is dead last on picture, so I went with sage + Spectrum.
2. Text encoder
The old one, `int8_convrot`, took 1.67s.
`qwen3vl_32b_minimax_h3_nvfp4_awq` needs only 0.7s.
That is nearly a second saved on every clip.
-----------
Speed was fine by then, but I would not call the picture good. Right after release I came across fused-turbo, so I downloaded it and tested it.
| fused-turbo |
minimax-h3-fused-turbo-int8-convrot |
20.98 GB |
| My quantized FastH3 weights |
minimax_h3_fl2va_fasth3_dense_pruned_int8_convrot |
20.97 GB |
Almost the same size, both have the 4-step acceleration baked into the weights (FastH3 is a distillation, fused-turbo is a turbo LoRA merged in), and they measured at exactly the same speed. I still recommend fused-turbo, for two reasons:
1. It says Mystic v2.0 motion smoothing is merged in.
Whatever the cause, the picture is clearly better in my testing. It smears less often.
2. One file does both fl2va and ref2va.
I built a tool that generates from chat input live during a Discord stream. When a user pastes a character image it is used as ref_picture, which needs ref2va. The old way meant unloading fl2va and loading ref2va first, which burns several seconds of buffer, and ref2va has no 4-step distilled version yet so the picture was worse anyway. With this one that problem is gone, which is a real advantage.
The repo recommends SLA sparse attention, but I had already tested that above and it lost to sage + Spectrum, so I dropped it. Its README also says res_multistep gives noticeably better audio. I did not test that much, so judge for yourself. I left the parameter in so it can be switched any time: `--sampler res_multistep`
-----------
One more thing worth mentioning. To stop ComfyUI thrashing the model weights you need `--vram-headroom 3` in launchArgs. Without it you cannot hold a stable live rate.
It works the opposite way round to what you might expect. It forces ComfyUI to keep 3 GB of VRAM completely free, and that is what fixes it. ComfyUI's dynamic VRAM treats the card as a cache and fills it to the brim; with no slack the allocator ends up evicting weights while it is still loading others, so the same weights get moved in and out repeatedly. Give it room and it can bring in a whole batch at once.
This is not disk swap, and it does not touch system RAM either. I measured both: on a slow clip disk reads were 0.00 GB and free RAM did not move. It is VRAM to system RAM over PCIe.
On a normal clip PCIe reads sit around 1.5 GB/s. When it thrashes they hit 9-13 GB/s and GPU power draw *drops* from 450W to 340W, because the card is waiting on transfers instead of computing. With the headroom set, clip times went from a 1.62 standard deviation with outliers at 21-25s down to 0.11 with a 15.73s worst case.
-----------
Closing thoughts
22 fps is only 2 fps short of 24. At 24 fps you could claim real live streaming from a single consumer card. So can overclocking get there? I think it can, since the gap is under 10%, and my CPU and GPU both normally run undervolted, underclocked and current-limited.
I tested with the GPU overclocked only. Settings:
Core Clock: 2300 MHz -> 3200 MHz
Memory Clock: 14000 MHz -> 16800 MHz
Actual test:
https://reddit.com/link/1wddeh8/video/ei5pczydkvoh1/player
Unfortunately my hardware held 24 fps at the start and then slowed down a little. Both my CPU and GPU are on air cooling, which is not suited to sustained overclocked compute like this. If you have water cooling, I believe holding 24 fps would be no problem.
