01
Before you install
Read the MiniMax H3 Community License that governs the VDN-H3 weights before downloading them. The OpenVDN code is Apache 2.0, but the derivative weights are not; the model agreement has territorial and redistribution restrictions.
The current official README recommends Python 3.12 and PyTorch 2.13 (`2.13.0+cu129`) and installs FlashAttention 4 because the code relies on FlexAttention's Flash backend. OpenVDN also uses a patched Diffusers setup.
02
1. Clone the official repository
Clone `OpenVDN/vdn-minimax-h3`, enter the repository and create the documented Conda environment. The current setup installs `uv`, then PyTorch 2.13 from the CUDA 12.9 wheel index.
Install the remaining project dependencies with prereleases enabled, then run `bash scripts/setup_diffusers.sh`. OpenVDN says the prerelease flag is needed for the current FlashAttention 4 dependency chain.
03
2. Download the official weights
The documented command is `hf download OpenVDN/vdn-minimax-h3 --local-dir ckpts`. The complete bundle is about 82 GB, so plan disk space before starting.
- `ckpts/h3-base/` — about 72 GB of released MiniMax H3 base components
- `ckpts/stage-b-step-2000/` — about 4.3 GB for the 50-step VDN stage
- `ckpts/stage-dmd-step-250/` — about 5.1 GB for the distilled 8-step stage
04
3. Choose 8 steps or 50 steps
Use the 8-step DMD stage when generation speed is the priority; it is the checkpoint behind OpenVDN's fastest published result. Use the 50-step stage when you want a higher-step path for evaluating the hybrid-attention model without relying as heavily on the distillation speedup.
05
4. Start with the single-GPU script
OpenVDN's simplest documented first render is `bash scripts/inference/8nfe_tuned_fp8.sh`. The first run compiles kernels and may take several minutes; later runs can reuse the compile cache.
For a custom text prompt, first run `src/inference/encode_prompt.py` to create the prompt representation, then pass it into `src/inference/infer.py` with `configs/inference/8nfe_tuned_fp8.yaml` and the `stage-dmd-step-250` checkpoint.
06
5. Use image or first/last-frame conditioning when needed
As of September 8, OpenVDN documents image-to-video and first/last-frame-to-video support with the same checkpoints. The first/last-frame workflow uses `src/inference/encode_keyframes.py` before the normal inference command.
OpenVDN currently says keyframe conditioning is supported on the single-GPU entrypoint while the multi-GPU Ulysses scripts are text-to-video only. Recheck this boundary if you automate around it because it is a newly added capability.
07
6. Use the hardware-specific multi-GPU script for H200 or B200
OpenVDN provides dedicated eight-GPU scripts for H200 and B200 systems using Ulysses sequence parallelism. Choose the script matching the hardware rather than assuming one distributed configuration is portable across GPU families.
- single GPU: `8nfe_tuned_fp8.sh`
- eight H200s: `8nfe_tuned_fp8_ulysses_h200.sh`
- eight B200s: `8nfe_tuned_fp8_ulysses_b200.sh`
08
What performance should you expect?
For the official 768p, 14.4-second workload, OpenVDN reports about 5.3 minutes at 50 steps or 51 seconds at 8 steps on one B200; about 1.2 minutes or 11.23 seconds on eight B200s; about 9.4 minutes or 90.5 seconds on one H200; and about 1.9 minutes or 18.3 seconds on eight H200s.
09
What about RTX and other consumer GPUs?
The official release does not publish a universal consumer-GPU minimum-VRAM table. The single-GPU script auto-detects the best available kernels, but memory needs still depend on precision, checkpoint stage, resolution, video length and loading strategy.
Do not turn community RTX results into official requirements. If you use a community ComfyUI port, keep its kernels, benchmarks and memory behavior clearly separated from OpenVDN's reference implementation.
10
Troubleshooting checklist
- if the first run is slow, distinguish kernel compilation from normal generation
- if imports fail, verify the documented PyTorch/CUDA/FlashAttention combination
- confirm `scripts/setup_diffusers.sh` completed successfully
- use the H200 or B200 distributed script that matches your hardware
- if wall-clock time exceeds a benchmark, remember the published table excludes decode and file encoding
11
Bottom line
Start with the official single-GPU 8-step path to validate your environment and checkpoint layout. Move to the H200/B200 distributed scripts only when your hardware matches those documented routes, and avoid inventing a universal VRAM floor that OpenVDN itself does not publish.
For the architecture, licensing split, broader release context and the exact boundaries of OpenVDN's speed claims, return to the main VDN-H3 overview.
Sources
Primary and supporting sources
Facts were rechecked against the linked sources immediately before publication. Pricing, product availability and rollout status can change.