Divide the wall clock by the frame count and the margin looks thinner than the headline number. The worst reported run, 8.710 seconds, spread over 243 frames is 35.8 ms of average wall time per frame, against a 41.7 ms interval at 24 fps [1][2][1][4]. That is 5.8 ms of average slack per frame, in a pipeline that is not organised per frame at all.
Here is what actually happens when the request lands. H3 encodes the prompt and any reference media, generates video and audio latents together, decodes them through separate video and audio autoencoders, moves hundreds of frames off the GPUs, and packages the result as an H.264 and AAC MP4 [11]. vLLM-Omni's work covers attention, inter-GPU communication, parallel video decoding, output transport and MP4 construction [12]. The last two are terminal stages. You cannot mux a container you have not finished writing, which is why vLLM's phrasing stops where it does [5].
The property is also length-dependent. The 15-second request completed in 14.059 to 14.177 seconds [3]. Treat that as 15.0 seconds of playback and the headroom is 5.5 percent, against 14.0 percent on the ten-second clip [2][3]. Exact playback length is not given for the longer request, and the 10.125-second figure suggests durations quantised to frames, so read 5.5 percent as approximate. The direction is what matters: ask for longer output and the cushion narrows to well under a second.
The distillation is roughly a twelvefold cut in denoising calls [10][5]. The service did not get twelve times faster, because encode, dual-autoencoder decode, host transfer and muxing do not shrink with the sampler, which is precisely why vLLM had to optimise all of those [12]. Hao AI Lab's single-Blackwell speedup is a component measurement, reported by the project itself [14], and vLLM declined to compute a base-to-FastH3 figure from its own runs because the two lanes differed in code revision, prompt, seed and artifact [15]. Good discipline, and it means there is no published apples-to-apples number yet.
For the 8.7 seconds to transfer, your workload needs eight B300s, output at 1,344 by 768 and 24 fps, and a text-only prompt [1][2]. The initial FastH3 release only does text to video and audio; first-and-last-frame conditioning and mixed image, video and audio references live on the base H3 checkpoints [16]. And the vLLM implementation fuses FastH3 into the model through load_weights() when the service loads, rather than exposing it as a request-level switchable adapter [17]. One deployment, one behaviour. The compensation is that the published serving recipe hands you an API service instead of a pipeline to assemble [13].
What ships is generous: base checkpoints, encoders, tokenizers, audio and video decoders, 768p generation locally, and public recipes for text, frame-conditioned and reference-guided work [19]. The community licence from the August 2026 release still requires separate permission for the United States, the EU, the UK and the Republic of Korea [8][9]. Downloading a checkpoint and being allowed to run it are separate procurement items. In those four jurisdictions the capacity plan is downstream of a licence conversation, and no amount of denoising reduction changes that ordering.
