Project MonetRequest demo
Home/Blog/How to Run VDN-H3 Locally: Install, Weights, GPUs & 8-Step Setup

AI · Project Monet Briefing

How to Run VDN-H3 Locally

The official VDN-H3 stack supports single-GPU inference and dedicated eight-GPU H200/B200 paths, but its fastest published numbers come from datacenter hardware.

Published 2026-09-08 · Updated 2026-09-08 · By Project Monet Editorial Team

Official VDN-H3 local setup flow showing an 82 GB model download, 8-step or 50-step checkpoint choice and single-GPU or H200/B200 paths

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.

Project Monet

Useful signals. Clear decisions. Better digital work.

Project Monet turns relevant shifts in AI, creator tools and the web into practical context—and builds focused websites for businesses ready to grow.

Request a free homepage concept