Anymatix SeedVR2 Load VAE Model
The SeedVR2 VAE half of the config pair — and why tiling is the knob you'll actually touch
- SEEDVR2_VAE
Like its sibling AnymatixSeedVR2LoadDiTModel, this node's name oversells what it does. It doesn't load a VAE into memory. It builds a configuration for the VAE half of a SeedVR2 upscale - which VAE weights, where they run, and how to tile the encode and decode passes - and hands that config off to a consumer that lives inside the Anymatix app. The output type is SEEDVR2_VAE, and on a stock ComfyUI nothing downstream understands it. It's plumbing that makes an exported workflow self-describing: the "which VAE, what tile settings" decision travels with the graph instead of being re-decided per machine.
That framing matters because it tells you which inputs are worth thinking about. The file-choice and device inputs mirror the DiT node: model (default ema_vae_fp16.safetensors - note the fp16 default, matching the "run the VAE at fp16" advice that SeedVR2 users converge on), device (default cuda:0), offload_device (default none), and cache_model (default false, with the same rule as its sibling: enabling it demands an offload_device, or the node raises).
The interesting part: tiling
SeedVR2's reputation for OOMs is earned - the KB panel says so outright. The VAE encode and decode are where a big image blows past your VRAM budget, which is exactly what the six tiling controls exist to prevent. For each direction you get the same triad:
- encode_tiled / decode_tiled - turn tiling on for that pass.
- encode_tile_size / decode_tile_size (default 512) - how big each tile is. Smaller tiles use less VRAM but can introduce visible seams and cost extra overlap work.
- encode_tile_overlap / decode_tile_overlap (default 64) - how much tiles bleed into each other so the model has context across the boundary. The community guidance on SeedVR2 is that overlap is where you fix tile seams: too little overlap and you see grid lines, too much and you pay for it.
- tile_debug (
false/encode/decode) - a diagnostic that visualises the tiling itself. If you're chasing seams or OOMs and can't see what the tiler is doing, this is the output that shows you. Turn it off for real renders.
The classic SeedVR2 recipe that falls out of all this: fp16 weights (the FP8 default on the DiT side is a VRAM compromise that can leave artefacts - the KB is firm that "FP8 tiles" and "GGUF damages skin," with FP16 the quality choice), encode at 512 tiles with generous overlap on a big image, and let it run. One-step upscaling means it's fast enough that the tiling tax is usually worth paying.
Install and the reality check
It ships in anymatix-comfy-nodes (Manager: search "anymatix-comfy-nodes"; or clone https://github.com/Anymatix/anymatix-comfy-nodes into custom_nodes and restart). But as with the DiT node, installing the pack in a bare ComfyUI leaves this inert - the SEEDVR2_VAE consumer is the Anymatix app itself. If you want SeedVR2 upscaling in ordinary ComfyUI, you're looking for a community SeedVR2 node pack, not this config node. Here, the honest job is: set the VAE file, set offload if your card is small, tune tiling if you hit OOM or seams, and otherwise let it be.
Inputs (11)
| Name | Type | Default | Description |
|---|---|---|---|
| model | STRING | ema_vae_fp16.safetensors | — |
| device | STRING | cuda:0 | — |
| offload_device | STRING | none | — |
| cache_model | BOOLEAN | false | — |
| encode_tiled | BOOLEAN | false | — |
| encode_tile_size | INT | 512 | — |
| encode_tile_overlap | INT | 64 | — |
| decode_tiled | BOOLEAN | false | — |
| decode_tile_size | INT | 512 | — |
| decode_tile_overlap | INT | 64 | — |
| tile_debug | COMBO | false | 3 options: false, encode, decode |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| SEEDVR2_VAE | SEEDVR2_VAE | — |