Research update 008 · 17 September 2026
An OpenAI video endpoint does not make H3 a live-video server.
vLLM-Omni documents a route that lets a ComfyUI workstation call a separate MiniMax H3 GPU service. That is useful deployment plumbing. Its published four-B300 full-H3 baseline returns about 8.7 seconds of video in about 87 seconds, so this particular route is for a remote workflow—not a viewer waiting for the next scene.
The route is real: separate the client from the GPU box
Project says: vLLM-Omni can serve H3 through an OpenAI-compatible video API for text-to-video with audio (T2VA), first-frame-to-video with audio (FL2VA), and reference-to-video with audio (Ref2VA). A current ComfyUI integration proposal describes a client that can run on a different machine from the H3 server.
That can save a creator from tying the UI, CUDA stack, and large model to one desktop. It also makes an H3 service reusable by another client. It does not move a generated frame to the screen faster by itself.
One published full-H3 row misses playback by about ten times
Project says: the current vLLM-Omni recipe reports a four-NVIDIA-B300 FL2VA workload: 209 frames at 1248×768, 50 steps, and 86.964 seconds mean HTTP client latency after an excluded warmup. H3 output is fixed at 24 fps, so 209 frames equal about 8.71 seconds of video.
| Named condition | Published time | Output duration | What the arithmetic says |
|---|---|---|---|
| Full H3 FL2VA · 4× B300 · 1248×768 · 209 frames · 50 steps | 86.964 s mean HTTP client latency | About 8.71 s at 24 fps | About 10 wall-clock seconds for each output second |
This is a source-published benchmark for one warmed workload. It does not predict a Turbo/FastH3 run, a different task, another GPU profile, image quality, queueing, price, retries, or the time from a viewer’s input to a visible response.
FastH3 is a server choice here, not a button in the request
Project says: the current H3 integration can use FastH3 by fusing one selected adapter into the checkpoint at server start. The RFC says the remote ComfyUI LoRA control does not switch FastH3 per request. Name the loaded adapter, task, server revision, GPU profile, host RAM, and warm state beside every timing.
That detail matters because the endpoint can look simple while hiding the decision that changes its speed and capability. “H3 API” is not a complete reproducibility card.
Pick this route when the workflow needs a service—not a live promise
- Use a separate H3 server when you need a remote editor, a shared API, or isolated dependencies.
- Use the published time as a reason to budget an offline or queued workflow first.
- Before promising interaction, record cold and warm time-to-ready, task, model and adapter, GPU and host memory, queue depth, retries, delivery, and client-to-visible time.
Until that record exists, call this what the sources support: a documented H3 serving route with a named, full-H3 four-B300 latency result. It is valuable infrastructure. It is not evidence of continuous or interactive AI video.