Workflow notes: conditions first

Dreamverse FastH3: frame carry is a mechanism, not a measured stream

Project says: FastVideo’s current Dreamverse README exposes an opt-in FastH3 Preview v1 profile. It uses four visible GPUs by default, creates 124-frame 768×1344 audio-video segments, and supplies a segment’s last frame as first-frame conditioning to the next.

That distinguishes this route from a queue of unrelated clips. It does not establish a clean visual handoff, a warm segment rate, queue margin, visible response time, recovery, cost, or a consumer-GPU path. Its default compile warm-up can take tens of minutes on a cold cache; record readiness separately from the first finished segment.

FastH3 8-Step V2: the task boundary is still the first test

Project says: FastVideo’s current 35B 8-Step V2 model card and schedule call the checkpoint text-to-audio-video only, say FL2VA and Ref2VA were not distilled, and name four B200 GPUs for its trained default. ComfyUI says: its current image-to-video template for the same named checkpoint supports T2VA and first/last-frame FL2VA, excluding Ref2VA. Its paired text-to-video template says T2VA only and again says FL2VA was not distilled.

Do not call this a reliable frame-to-frame transition workflow until a pinned run checks it. Record the model-card and template revision, checkpoint, task, grid, scheduler, component files, attention path, GPU, system RAM, cold/warm result, and whether the supplied first and last frames visibly anchor the output.

FastH3 V2 on a Radeon 8060S: native canvas is not a live route

Community report: one author names a Ryzen AI Max+ 395, Radeon 8060S graphics, 128 GB unified memory, Windows, ROCm 10.0.0, and ComfyUI v0.36.0. The author reports a 768×1344, 243-frame V2 job in 33 minutes 9 seconds—about 10.1 seconds of output at 24 fps. Treat this as a condition-rich local-render lead, not an AMD baseline or a real-time result.

The author says the VSA path stays dense below 12,288 tokens. Their smaller 640×384 case did not gain from FastH3; the larger native-canvas case did. Put canvas, frame grid, token count, attention backend, memory topology, and the timing boundary beside any eight-step headline.

FastH3 Preview v1 on a 5090: a named timing, not a V2 result

Platform benchmark says: Sogni’s stated FastH3 Preview v1 image-to-video test ran a 15.08-second, 24 fps clip on one RTX 5090 (32 GB) in 55 seconds at 480×640 and 126 seconds at 768×1024. The hot boundary starts at job start and ends at a complete MP4; queue and model loading are excluded.

Use this as a review-loop or prequeue lead. It is not a normal-speed stream, a time-to-first-frame measurement, or a consumer result you can transfer to FastH3 8-Step V2. Record model family, task, attention path, checkpoint, source still, resolution, frames, audio setting, GPU, system RAM, and cold/warm state before comparing it with another FastH3 claim.

vLLM-Omni: H3 can live on another machine

Project says: vLLM-Omni has a current H3 recipe for an OpenAI-compatible service that covers T2VA, FL2VA, and Ref2VA. A ComfyUI integration proposal describes the UI as a remote client, so it can run separately from the H3 GPU service.

The route is useful when you need dependency isolation, a shared endpoint, or a workstation that does not host the model. It is not a speed recipe: the project’s stated full-H3 four-B300 FL2VA baseline returns about 8.71 seconds at 24 fps in 86.964 seconds mean HTTP client latency. Treat a two-RTX CPU-offload profile as a capacity route, then measure it before scheduling playback.

The task and adapter are part of the server

Project says: H3 uses different T2VA/FL2VA and Ref2VA task paths. The current vLLM-Omni RFC says FastH3 works by fusing one selected adapter at server start; its remote ComfyUI LoRA control cannot switch FastH3 for a request. The current client also exposes only a subset of reference combinations.

Record the checkpoint, task, adapter filename, server revision, GPU and host memory, client revision, request shape, cold/warm state, response boundary, and audio result. An endpoint label alone is not a workflow.

One-5090 FastH3 channel: a format-specific community route

Community project says: FastH3 Live runs an unattended local audio-video channel on one RTX 5090 (32 GB) with ComfyUI. Its current card claims 22.1 sustained fps at 448×448 through a dense four-step FastH3 conversion, a prequeue, retimed playback, and a large library of self-contained scenes.

That is not a local interactive-session recipe. The source frames are authored for 24 fps; the project retimes delivery to its sustainable pace. Its scenes do not retain a viewer’s current world state across the next clip. Treat it as a reproducibility lead for a particular AI-TV format.

FastH3 has named attention paths

Project says: FastVideo’s current FastH3 Preview example selects VSA or dense FA4 attention from the adapter payload. An adapter carrying the VSA compression gate must run VSA; an adapter without it defaults to dense. Keep that fact beside any FastH3 speed number.

The one-5090 community project says it chose a dense conversion because stock ComfyUI does not preserve its VSA gate tensors. Its result is therefore not a consumer version of Reactor’s VSA B200 deployment. Same model family is not the same workflow.

Comfy’s official H3 access route: a footprint is not a speed claim

Comfy says: its optimized H3 path prunes modulation weights, uses INT8 ConvRot, and reduces the smallest variants’ total memory footprint from 123.6 GB to 42.5 GB. It says dynamic VRAM offloading can run H3 on a GPU like an RTX 3060.

That is useful for a first local test. It does not say which task mode, resolution, duration, quality, system RAM, retry rate, or wall time fits that card.

Record this before calling any workflow fast

Capture client and inference hosts, exact checkpoint, adapter, attention path, quantisation, canvas, source frames, delivered fps, task mode, host RAM, GPU, version, seed, cold and warm wall time, API time boundary, queue state, failures, and observed quality. A workflow without those fields is a screenshot, not a dependable route.