Disk offload mode leaks host RAM during denoising (RSS grows every step, >15x slowdown from swap thrashing)

[zhouxixiong4]

Environment

• OS: Windows 11 (x64), 24 GB RAM
• GPU: RTX 4060 Laptop 8 GB
• Python 3.12.10, torch 2.11.0+cu128, bitsandbytes 0.50.0
• DiffSynth-Studio: current main, installed via pip install -e ".[quant]" (2026-08-03)
• Model: DiffSynth-Studio/MiniMax-H3-NF4 (disk-offload low-VRAM path)

Observation

Running MiniMax-H3 NF4 FL2VA with the official disk-offload vram_config (offload_device="disk", onload_device="cpu", preparing_device="cuda", computation_device="cuda"), host RAM usage of the python process grows monotonically with every denoising step and is never reclaimed:

• After the text-encoder phase (which alone peaks at ~15 GB), the process working set keeps climbing during denoising — ~11.3 GB by step 39/50 and still growing
• On a 24 GB machine this pushes the OS into swap thrashing: per-step time degrades from ~65-75 s/step (steps 1-3) to ~1000-1100 s/step (step 39+), i.e. a >15x slowdown
• A 50-step 5-second 640x640 video took ~10 hours instead of the ~1 hour the early-step speed would suggest

Expectation

In disk offload mode, weights that _load_from_disk loads into CPU RAM (module.load_state_dict(state, assign=True) in layers.py) should be released when the layer is offloaded again (offload() re-creates a quantized shell). Host RAM should stay roughly constant across steps, but it looks like the CPU-side copies or the rebuilt quant state from quantize.unflatten_state_dict() are kept alive somewhere, so each step's reloads accumulate.

Impact

This disproportionately affects exactly the audience the disk-offload path targets: low-VRAM and low-RAM machines (the model card advertises ~6 GB VRAM as enough). Short runs (<= 8 steps) finish before the leak hits the wall, which masks the issue in quick tests; any 50-step or long-video run degrades severely.

Happy to provide py-spy dumps, tracemalloc snapshots, or per-step RSS logs if helpful.

[mi804]

We’re sorry that we still haven’t been able to reproduce the issue you described, where system memory usage gradually increases over denoising steps. However, with your current VRAM configuration, our tests do show approximately 30 GB of system memory usage. On a system with only 24 GB of RAM, this could trigger swap usage.

For now, you can use the following configuration to reduce memory consumption further. In our tests, it uses approximately 7 GB of VRAM and 6 GB of CPU RAM:

import torch
torch.cuda.set_per_process_memory_fraction(0.999, torch.device("cuda:0"))
from diffsynth.pipelines.minimax_h3_audio_video import MiniMaxH3Pipeline, ModelConfig
from diffsynth.utils.data.audio_video import write_video_audio
from modelscope import dataset_snapshot_download
from PIL import Image

vram_config = {
    "offload_dtype": "disk",
    "offload_device": "disk",
    "onload_dtype":"disk",
    "onload_device": "disk",
    "preparing_dtype": torch.bfloat16,
    "preparing_device": "cuda",
    "computation_dtype": torch.bfloat16,
    "computation_device": "cuda",
}
pipe = MiniMaxH3Pipeline.from_pretrained(
    torch_dtype=torch.bfloat16,
    device="cuda",
    model_configs=[
        ModelConfig(model_id="DiffSynth-Studio/MiniMax-H3-NF4", origin_file_pattern="minimax-h3-fl2va-nf4.safetensors", **vram_config),
        ModelConfig(model_id="DiffSynth-Studio/MiniMax-H3-NF4", origin_file_pattern="minimax-h3-text-encoder-nf4.safetensors", **vram_config),
        ModelConfig(model_id="DiffSynth-Studio/MiniMax-H3-NF4", origin_file_pattern="video_vae_nf4.safetensors", **vram_config),
        ModelConfig(model_id="DiffSynth-Studio/MiniMax-H3-NF4", origin_file_pattern="audio_vae_nf4.safetensors", **vram_config),
    ],
    processor_config=ModelConfig(model_id="MiniMax/MiniMax-H3", origin_file_pattern="FL2VA/processor/"),
    vram_limit=1,
)