> ## Documentation Index > Fetch the complete documentation index at: https://docs.omnichar.org/llms.txt > Use this file to discover all available pages before exploring further. # Hardware requirements for Omnichar Studio > What VRAM and system RAM each local model needs to generate and to train, measured on real cards, plus the Windows pagefile setting MiniMax H3 depends on. System RAM matters as much as VRAM here, and for the video models it matters more. Check both rows before you download: MiniMax H3 is about 139GB of files, and a machine that cannot hold it will say so only once the files are on disk. ## What each model needs Generation, with the smallest build of each model. A card below the VRAM figure streams weights from system RAM instead of holding them, which works and is slower. | Model | VRAM to generate | System RAM | Notes | | - | - | - | - | | Z-Image Turbo | 12GB | 16GB | The low-VRAM place to start | | FLUX.2 (klein 4B/9B) | 16GB | 16GB | 4-bit fits a 16GB card | | FLUX.1 dev | 12GB | 16GB | 4-bit | | Krea 2 (RAW) | 40GB | 32GB | 1024 peaks near 36GB | | MiniMax H3 (video, sound) | 24GB | **64GB** | Streams on less, see below | | LTX-2.5 (video, sound) | 48GB | 64GB | bf16 streams on a smaller card | H3's measured peaks are 23.1GB for text to video and 37.5GB for reference to video, both at 960x544 on a 45GB card. Below that it streams rather than refusing: on a 15GB card the 21GB int8 reference-to-video build loads in 6.5 minutes and holds only 1.8GB of VRAM through the caption pass, because every weight is streamed from host RAM a layer at a time. What it costs instead is system RAM, and that figure is in the next section. > [!NOTE] > > **A 16GB card is not yet a verified configuration for H3 reference-to-video.** On a 15GB Tesla T4 > the weights load and stream correctly, but encoding a single image reference asked for one 16GB > allocation inside the vision tower and failed before the first denoising step. We have not > reproduced that allocation outside the full pipeline, so we cannot say yet which cards it affects > or whether it is avoidable. If you run H3 on a 16GB card, the numbers would be useful to us. Training peaks at 512px, lower than generating for every model. The 16GB column is measured on a Tesla T4 for Z-Image, Krea 2 and MiniMax H3; the rest is interpolated from 48GB runs. | Model | Trains on 16GB | Peak VRAM | System RAM | | - | - | - | - | | FLUX.2 (klein Base 4B/9B) | yes | 8.6GB | 16GB | | FLUX.1 dev (4-bit) | yes | 10.4GB | 16GB | | Krea 2 (RAW, 4-bit) | yes | 11.9GB | 32GB | | Z-Image Turbo | yes | 13.4GB | 16GB | | MiniMax H3 | yes, slowly | 12.7GB | **64GB** | | LTX-2.5 | no, needs 48GB | 42.0GB | 64GB | The full matrix, including every resolution and the time each card takes, is in [TRAINING.md](https://github.com/omnichar/OmniChar/blob/main/TRAINING.md#benchmark-results). ## MiniMax H3 is limited by system RAM H3 peaks lower on a 16GB card than on a 48GB one. The run has three phases that never overlap, and on a big card the tallest is the caption pass, where the 32B conditioner sits on the GPU. On a card too small to hold it, the conditioner runs on the CPU instead and the peak drops to the training phase. You pay for that in time. On a T4 a step takes 16.2s against 0.63s on an L40S, and the caption pass adds about 19 minutes. A 16GB card runs H3 where a 24GB card is comfortable. The host RAM is the same whatever the card. The weights live in system RAM and stream to the GPU as each block is needed, so the whole model has to fit there. Generating at 960x544 peaks at 47.0GB of unreclaimable host RAM, which is why 64GB is the figure. ### On Windows, raise the pagefile H3 maps a large checkpoint into memory, and Windows counts that against the commit limit whether or not it is resident. On a 64GB machine, training crashed with a 64GB pagefile on each of two drives and ran with 128GB on each. Omnichar counts the pagefile toward the headroom around the weights, not toward the weights themselves, which still have to be physically resident. A pagefile cannot carry something read on every step without thrashing. That split matters because the headroom is large. Loading the 21GB int8 reference-to-video build on a 33GB machine took 6.4 minutes and reached 37.1GB of unreclaimable host RAM before the first denoising step, then **over 45GB** once the conditioner ran, with 24GB of it in swap. The first step is where it jumps, because it converts the checkpoint's file-backed pages into anonymous memory the kernel can no longer drop. So a 32GB machine needs a large pagefile for this model, and the 64GB figure in the table above is roughly where it stops paging. With **no** pagefile or swap at all, Omnichar asks for 12GB of real headroom instead of 6GB, and refuses below that. That is not caution for its own sake. A load sized with 6GB and nothing to reclaim peaked at 1.9GB free once the first denoising step converted the page cache out from under it, and the kernel reset the machine: no error, no shutdown, a log that stops mid-line. On Linux, add a swapfile. On Windows, do not set the pagefile to none. Set it under System Properties, Advanced, Performance, Advanced, Virtual memory. ## RTX 50-series Blackwell cards (sm\_120) need a CUDA 13 build of PyTorch, and `--install` picks `cu130` for you. CUDA 13 needs driver R580 or newer. On an older driver, `--install` falls back to `cu128`, which still has sm\_120 kernels but is frozen at torch 2.11, so update the driver when you can. To see what your driver reports and which index would be used, without installing anything: ```powershell theme={null} .\webui.bat --print-torch-index ``` If you install with `uv sync` rather than through the launcher, you get the `cu126` index, which has no sm\_120 wheel at all. The app detects this at startup and tells you which flag fixes it. ## When a model is refused A model too large for your VRAM and your RAM is refused before anything loads, rather than during the render. Host-RAM exhaustion does not raise an error. It takes the whole process down, and on a machine with no swap it can reset the box. Each message names the levers that apply to its own limit: canvas, clip and build for a VRAM refusal, pagefile or swap for a RAM one. In order of how much they buy you: 1. **Lower the canvas.** 960x544 needs far less than 1344x768 and renders about 2.3x faster per step. Doubling the canvas costs more than double. 2. **Shorten the clip.** 3. **Use the int8 build** from the model popup, which is a third of the download and stays int8 in VRAM. 4. **Raise the pagefile or swap**, per above. If you want to try anyway, set `INLINE_IGNORE_MEMORY_LIMITS=1` and the refusals become warnings. Accept that an oversized load may be killed by the operating system. ## Other hardware | Hardware | Status | Extra steps | | - | - | - | | NVIDIA, Linux | Tested | None | | NVIDIA, Windows | Supported | None. `--install` picks the CUDA build for your card. | | Apple Silicon (MPS) | Code path exists, untested | No int8 on MPS, so a model must fit in unified memory. | | AMD ROCm, Linux | Untested, reports welcome | Install a ROCm build of PyTorch after the normal install. | | AMD ROCm, Windows | Untested, reports welcome | Pass AMD's own wheel index with `--torch-index`. | | CPU only | Works, very slow | `./webui.sh --cpu` | See [Install Omnichar Studio](https://docs.omnichar.org/app/install.md) for the install itself, and [Supported models](https://docs.omnichar.org/app/models.md) for what each model does and where its files go. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.