Based on the production ComfyUI workflow files of ZView Space (node version 2.5.24), read on 19 October 2026, and on the SeedVR2 node's README. This covers still-image 2x upscaling, not video.
If you search for a SeedVR2 workflow you mostly find node screenshots with no explanation. We run SeedVR2 3B and 7B every day behind our image upscaler, so this page lists the exact settings of our workflow, says what each setting does according to the node's README, and is clear about what we have and have not measured. For a side-by-side look at the results, see our [3B vs 7B comparison on outfit portraits](/articles/seedvr2-3b-vs-7b-outfit-portrait-upscaling-en/en).
The two models we load
The node's README lists several DiT checkpoints: FP16 (best quality), FP8 e4m3fn (good quality), and GGUF 4-bit and 8-bit versions (acceptable to good quality), with VRAM use ranking FP16 above FP8 above GGUF. We use FP8 for both sizes:
| Variant | Checkpoint file in our workflow | What the README says about the format | | --- | --- | --- | | 3B | `seedvr2_ema_3b_fp8_e4m3fn.safetensors` | FP8, "good quality" | | 7B | `seedvr2_ema_7b_fp8_e4m3fn_mixed_block35_fp16.safetensors` | FP8 with the last block kept in FP16 to reduce artifacts |
The VAE is `ema_vae_fp16.safetensors`, the one the README names as default and recommended. In our tool the 7B model is the default, and users can switch to 3B.
Our node settings
These are the values in our two workflow files; the only difference between the 3B and 7B files is the checkpoint name.
| Setting | Our value | What it does (README) | | --- | --- | --- | | `resolution` | shortest edge x 2 (see below) | Target size of the shortest edge in pixels; aspect ratio is kept | | `max_resolution` | 0 | No limit on the longest edge | | `blocks_to_swap` | 12 | Moves that many transformer blocks off the GPU; saves VRAM, costs speed | | `swap_io_components` | on | Also offloads input/output embeddings and norms | | `offload_device` | CPU | Where swapped parts live | | VAE `encode_tiled` / `decode_tiled` | both on | Processes in tiles to reduce VRAM | | VAE tile size / overlap | 1024 / 128 | The README's defaults; larger overlap reduces seams | | `color_correction` | `lab` | The README calls it full perceptual matching with detail preservation | | `input_noise_scale` | 0 | Adds noise to the input to reduce artifacts at very high resolutions; off | | `latent_noise_scale` | 0.01 | Adds noise during diffusion; can soften excessive detail | | `attention_mode` | `sdpa` | Always-available default | | `batch_size` | 1 | One image per run (the video batch rule of 4n+1 allows 1) | | `seed` | 1 | Fixed | | `cache_model` | off | Models are not kept between jobs |
Our output is a JPEG at quality 90.
How the 2x is computed
We always upscale by a factor of 2. The workflow reads the image's width and height, takes the smaller of the two, and multiplies it by 2; that number goes into `resolution`. A 1,080 x 1,920 vertical image therefore becomes 2,160 x 3,840, and a 2,000 x 1,000 landscape image becomes 4,000 x 2,000. Because `resolution` is defined by the shortest edge, this keeps the aspect ratio and gives an exact 2x. The factor is fixed in code: the upscaler service ignores other values and returns 2.
Why these memory settings
The README's VRAM guidance is by tier: 8 GB or less should use GGUF Q4_K_M with block swapping and tiling; 12 to 16 GB should use FP8 with block swapping or tiling as needed; 24 GB or more can run FP16 without memory tricks. Our configuration, FP8 plus 12 swapped blocks plus tiled VAE, follows the middle tier. The README gives no VRAM figures in gigabytes for specific settings, and neither do we, because we did not record them.
If you run out of memory, the README's order of fixes is: turn on VAE tiling if the failure is in encoding or decoding, raise `blocks_to_swap` (it allows 1 to 32 for 3B and 1 to 36 for 7B), and as a last step switch to a GGUF checkpoint. Higher block swapping saves more VRAM but runs slower.
What about "sharp" vs "normal"?
People search for this, so here is what we can say. The README lists "sharp" variants of the 7B model (`seedvr2_ema_7b_sharp_*`) in addition to the standard ones. We do not use them and have not tested them, so we cannot say how they differ in practice. What we can say comes from our own 3B vs 7B comparison: the larger model's gains were clearest on wool and knit, and on denim "more texture" stopped looking right, so more sharpness is not automatically better on every fabric. If you test a sharp variant, compare it on materials that show texture and on materials that can look over-processed.
Settings worth trying
The README suggests trying `input_noise_scale` between 0.1 and 0.3 for artifacts at very high resolutions, and `latent_noise_scale` between 0.05 and 0.15 if the input noise does not help. Our `latent_noise_scale` of 0.01 is below that suggested range, and `input_noise_scale` is off, which is a conservative choice for 2x work. For colour, the README describes `lab` as the fidelity option and `wavelet` as frequency-based with natural colours; we have not run a controlled comparison between them.
What we have not measured
- Speed. We do not have clean per-image timings. The only job timings in our database come from batch jobs that also generate text and images, so they say nothing about upscaling speed. The README quotes a 20 to 40% DiT speedup from `torch.compile` but does not quantify the difference between FP16, FP8 and GGUF.
- VRAM. We did not record peak usage for our settings.
- Model loading cost. With `cache_model` off, each job reloads the weights. That is gentle on memory and costs load time on every job; we have not measured how much.
To measure your own setup, note the time ComfyUI prints for a run, record peak VRAM with `nvidia-smi` while it runs, and repeat on a few images of different sizes.
The settings above were read from `SeedVR2_3B_API.json` and `SeedVR2_7B_API.json` and from the upscaler service on 19 October 2026. Descriptions of what each setting does are taken from the node's README, not from our own experiments.