Checked 22 September 2026 · Research update 013
Dreamverse gives FastH3 a frame-carried chain. It still has to earn “live.”
The update: FastVideo’s current Dreamverse README documents a FastH3 Preview v1 chain that carries one segment’s last frame into the next. The default is four visible GPUs, 124-frame 768×1344 segments, and a cold warm-up that can take tens of minutes. That is a continuity design to inspect, not a live-capacity result.
What works today
| Route | What the evidence supports | What it does not prove | Best first move |
|---|---|---|---|
| Remote H3 via vLLM-Omni | Project says: one OpenAI-compatible service can handle T2VA, FL2VA, and Ref2VA; a remote ComfyUI client can call it. | A live endpoint. Its published full-H3 four-B300 FL2VA row returns roughly 8.7 seconds of output in roughly 87 seconds. | Pin task, adapter, server revision, GPU and host memory, then time cold and warm response before building a client promise. |
| Dreamverse FastH3 profile | Project says: an opt-in FastH3 Preview v1 profile uses four visible GPUs, generates 124-frame 768×1344 audio-video segments, and feeds the prior last frame into the next segment. | A measured transition, a warm segment rate, queue margin, live response, cost, recovery, or consumer-GPU path. | Separate boot-to-ready from warm generation; inspect visible handoff and the fallback after one missed segment. |
| FastH3 8-Step V2 in ComfyUI | Community report: one named Radeon 8060S, 128 GB unified-memory environment completed a 768×1344, 243-frame V2 job in 33 min 9 s. The author says VSA did not engage below 12,288 tokens. | A general consumer baseline, quality result, live capacity, or reliable frame anchoring. FastVideo and the current official Comfy text-to-video template say T2AV only; the paired image-to-video template says T2VA plus first/last-frame FL2VA. | Pin task, package, canvas, frame grid, attention path, and memory; verify FL2VA separately if a transition matters. |
| YoLive / H3 Superfast | Provider says: a group can propose and vote on the next scene; 10 seconds of 768p, 24 fps output with native audio generate in four seconds on eight B200 GPUs. | Vote-to-screen delay, individual control, public uptime, cost, or durable continuity. | Record the control rule, vote window, moderation, delivery time, and what survives into the next scene. |
| H3 Max Director on fal | Provider says: an open WebRTC session can accept directions while audio and video arrive, with carried context between segments. | A permanent channel, measured interaction delay, or a tested restart handoff. | Price a finite session at the current $0.08/generated-second list price before a test. |
| FastH3 queue + playout | Project says: distinct generated clips can sit in build and playout queues. The cited roughly 15-second build is 15.5 s on four B200s and 12.9 s on eight. | Automatic viewer-safe continuity. Clips still hard-cut and reset the scene; timing is not an independent test. | State the GPU count, warm build time, ready seconds, autoplay policy, filler, and empty-queue fallback. |
| FastH3 Preview on one RTX 5090 | Platform benchmark says: a pinned 15.08-second image-to-video run took 55 s at 480×640 and 126 s at 768×1024 on a 32 GB 5090. | A general 5090 baseline, a live response, time to first frame, queue behavior, quality parity, or 8-Step V2 timing. The stated hot boundary excludes queue and model loading. | Use it for a clip-review or prequeue estimate only. Reproduce cold and warm timing with your task, resolution, adapter, and quality bar. |
| One-5090 FastH3 channel | Community project says: a dense four-step route can sustain 22.1 fps at 448×448 while an earlier clip is playing. | Native 24-fps motion, viewer control, continued story state, a normal 16:9 picture, a general 5090 baseline, or an independent result. | Start with the delivered fps, canvas, checkpoint, attention path, prequeue, and motion trade-off. |
| Local MiniMax H3 | Community report: one RTX 5090 and 64 GB RAM setup made roughly 15 seconds at 768×1024 in about 22 minutes. | A general 5090 baseline, a free route, or a live route. | Keep GPU, system RAM, model additions, frames, steps, version, wall time, and failure together. |
The pre-download card
For a frame-carried loop, record readiness first, then the model and adapter, GPU count, frame grid, conditioning asset, and visible handoff. Only after that should you compare warm time, quality, price, queue margin, or audience wait. A carried last frame is not a promise that the next shot holds together.
Pick the promise first
- I need a frame-carried FastH3 editing loop: inspect Dreamverse’s four-GPU Preview v1 profile, then measure readiness, handoff, and the viewer-visible result before promising continuity.
- I need a remote H3 workflow: investigate vLLM-Omni, then verify the exact task and time-to-ready on your hardware.
- I want the crowd to choose the next beat: study YoLive’s collective control loop, then ask for a timestamped vote-to-screen record.
- I want viewers to alter a held stream: compare Director’s session behavior with the interaction delay and restart plan you can afford.
- I want a local TV-shaped feed of distinct scenes: investigate the one-5090 FastH3 route as a named workflow, then test its motion, quality, queue, and long-run cost.