Sol-H3 Studio is a workspace inside ComfyUI for running an optimized MiniMax H3 engine on your own hardware. Its October 16 announcement highlights five-second videos with native audio in 35.5 seconds on an RTX 5090. That number belongs to a particular two-stage, already-loaded configuration. Choosing the correct pipeline matters as much as installing the interface.
This guide follows the NVlabs package and its installation and validation records, checked October 18, 2026. We have not installed this GPU runtime or repeated its measurements. H3Vid has not integrated Sol-H3 Studio as an online generator.
Choose one stage or two stages
The one-stage route runs an eight-step HyperFlow adapter merged into an FP8 transformer, with an AdaLN lookup table, Sol-Attn, compilation, and an optional distilled video decoder. It supports text, first-frame conditioning, and reference-image requests at the documented 480p or 768p settings.
Two-stage generation first produces an H3 draft, then applies LTX refinement. The current Studio documentation limits this route to text at 768p. It is therefore a different production recipe, rather than a faster switch that preserves every one-stage input mode.
| Choice | Useful starting question | Important boundary |
|---|---|---|
| One stage | Do I need a starting frame or reference images? | Reference generation needs a separate converted transformer |
| Two stages | Can a text-driven draft plus refinement solve my shot? | Requires the separate H3/LTX package and its setup |
| Original baseline | What does the comparison actually measure? | Its encoder and runtime are specified, rather than an arbitrary untouched installation |
The existing SoL-Refiner article explains the refinement component separately. HyperFlow explains the adapter's own loading contract. Neither component alone is the entire Studio deployment.
Prepare the runtime before the interface
The published RTX 5090 requirements include Linux, a 32GB card, at least 90GB host RAM, and ComfyUI 0.30 or newer. The runtime uses Python 3.12, PyTorch 2.12 with CUDA 13, Triton 3.7, FastVideo, and attention libraries built for the target architecture. These are package-specific requirements, not a promise that any 32GB system is ready.
The plugin runs the GPU engine in a separate Python process. Linking its folder into custom_nodes supplies the interface and bridge; it does not install all the model execution dependencies into a working runtime automatically.
The installation guide starts from this repository location:
git clone -b sol-engine https://github.com/NVlabs/Sana.git
Link models/minimax_h3/Sol-H3-ComfyUI into your ComfyUI custom-node directory. Prepare a paths file containing the runtime interpreters, FastVideo and attention checkouts, H3 model directory, Qwen checkpoint, and required supporting paths. Keep virtual-environment interpreter paths intact rather than resolving their symlinks.
Next, build the checkpoints for your chosen route. One-stage acceleration needs the merged FP8 transformer and schedule-specific AdaLN table; reference images require the corresponding transformer_ref conversion. The table builder checks against the official module, and an unsupported schedule fails instead of silently using an unrelated table. Two-stage users must prepare the separate RTX 5090 package and supply its paths file.
Run scripts/configure.py from the plugin directory with the options for the components you actually prepared. It validates checkpoint shards, writes configuration files, and prints the SOL_ENGINE_CONFIG setting. Export that setting before starting ComfyUI. The upstream guide provides the complete command; copying a large all-components example before preparing those files creates unnecessary missing-path failures.
Read the speed numbers with their clocks
The validation record separates request time from loading and warmup. Its headline two-stage result uses resident Qwen conditioning: four formal requests were approximately 35–36 seconds, with a median of 35.5 seconds. The package configuration that reloads Qwen for each request instead took about 90–91 seconds on that host.
The first two-stage session also incurred 881 seconds of loading and warmup. Persistent compilation caches help later sessions, but do not make that first preparation disappear. The one-stage eight-step profile reports a 67.2-second median in a different recorded session; CPU MP4 encoding load contributes to variation.
These observations suggest a useful evaluation plan: time startup, the first request, repeated requests, and mode switches separately. The reference-image path swaps checkpoints when changing between reference and text/first-frame modes. Its first response therefore answers a different latency question from several consecutive reference jobs.
Review the finished shot before scaling up
Begin with one short prompt and the published canvas. Save the prompt, seed, pipeline, precision, decoder, model revisions, and whether the session was warm. Listen to the exported MP4 as well as watching the preview. Compare subject identity, motion, fine texture, audio timing, and scene transitions before changing resolution or input mode.
An exact AdaLN table does not establish that the entire accelerated pipeline is numerically or perceptually identical: quantization, sparse attention, and the distilled decoder introduce their own differences. The authors report visual evaluation under stated conditions, not universal quality equivalence.
Your next step is to choose the input mode first, prepare only its runtime and checkpoints, then retain one reproducible successful clip. If your goal is a browser-based generation job without managing that environment, the MiniMax H3 Max page describes a separate hosted route.