ZView Space 운영 ComfyUI 워크플로 파일(노드 버전 2.5.24)을 2026년 10월 19일에 읽은 내용과 SeedVR2 노드 README를 바탕으로 합니다. 정지 이미지 2배 업스케일을 다루며, 영상은 다루지 않습니다.
SeedVR2 워크플로를 검색하면 설명 없는 노드 스크린샷이 대부분입니다. 우리는 이미지 업스케일러 뒤에서 SeedVR2 3B와 7B를 매일 돌립니다. 그래서 이 글은 우리 워크플로의 정확한 설정을 나열하고, 각 설정이 하는 일을 노드 README 에 따라 설명하며, 무엇을 측정했고 무엇을 측정하지 않았는지를 분명히 밝힙니다. 결과를 나란히 보고 싶다면 [의상 인물 사진 3B vs 7B 비교](/articles/seedvr2-3b-vs-7b-outfit-portrait-upscaling-en/ko)를 참고하세요.
우리가 불러오는 두 모델
노드 README 는 여러 DiT 체크포인트를 나열합니다. FP16(최고 품질), FP8 e4m3fn(좋은 품질), GGUF 4비트·8비트(허용~좋은 품질)이며, VRAM 사용량은 FP16 > FP8 > GGUF 순입니다. 우리는 두 크기 모두 FP8 을 씁니다.
| 변형 | 우리 워크플로의 체크포인트 파일 | README 가 말하는 형식 | | --- | --- | --- | | 3B | `seedvr2_ema_3b_fp8_e4m3fn.safetensors` | FP8, "좋은 품질" | | 7B | `seedvr2_ema_7b_fp8_e4m3fn_mixed_block35_fp16.safetensors` | 아티팩트를 줄이려고 마지막 블록을 FP16 으로 둔 FP8 |
VAE 는 README 가 기본값이자 권장으로 지목한 `ema_vae_fp16.safetensors` 입니다. 우리 도구에서는 7B 가 기본 모델이고 사용자가 3B 로 바꿀 수 있습니다.
우리 노드 설정
두 워크플로 파일의 값입니다. 3B 와 7B 파일의 유일한 차이는 체크포인트 이름입니다.
| 설정 | 우리 값 | 하는 일(README) | | --- | --- | --- | | `resolution` | 짧은 변 x 2 (아래 참조) | 짧은 변의 목표 픽셀 크기. 종횡비 유지 | | `max_resolution` | 0 | 긴 변 제한 없음 | | `blocks_to_swap` | 12 | 해당 개수의 트랜스포머 블록을 GPU 밖으로 옮김. VRAM 절약, 속도 손해 | | `swap_io_components` | 켬 | 입출력 임베딩과 정규화 층도 밖으로 옮김 | | `offload_device` | CPU | 옮겨진 부분이 있는 곳 | | VAE `encode_tiled` / `decode_tiled` | 둘 다 켬 | 타일 단위로 처리해 VRAM 절약 | | VAE 타일 크기 / 겹침 | 1024 / 128 | README 기본값. 겹침을 키우면 이음새가 줄어듦 | | `color_correction` | `lab` | README 는 디테일을 보존하는 완전한 지각적 매칭이라고 설명 | | `input_noise_scale` | 0 | 매우 높은 해상도에서 아티팩트를 줄이려고 입력에 노이즈를 더함. 꺼 둠 | | `latent_noise_scale` | 0.01 | 확산 중 노이즈를 더함. 과한 디테일을 부드럽게 할 수 있음 | | `attention_mode` | `sdpa` | 항상 쓸 수 있는 기본값 | | `batch_size` | 1 | 한 번에 이미지 한 장(영상 배치 규칙 4n+1 에서 1 허용) | | `seed` | 1 | 고정 | | `cache_model` | 끔 | 작업 사이에 모델을 유지하지 않음 |
출력은 품질 90 의 JPEG 입니다.
2배는 어떻게 계산하나
우리는 항상 2배로 업스케일합니다. 워크플로가 이미지의 가로·세로를 읽고 더 작은 쪽에 2를 곱한 값을 `resolution` 에 넣습니다. 그래서 1,080 x 1,920 세로 이미지는 2,160 x 3,840 이 되고, 2,000 x 1,000 가로 이미지는 4,000 x 2,000 이 됩니다. `resolution` 이 짧은 변 기준이므로 종횡비가 유지되고 정확히 2배가 됩니다. 배율은 코드에 고정되어 있습니다. 업스케일러 서비스는 다른 값을 무시하고 2를 돌려줍니다.
이 메모리 설정의 이유
README 의 VRAM 안내는 구간별입니다. 8GB 이하는 GGUF Q4_K_M 에 블록 스왑과 타일링, 12~16GB 는 필요에 따라 블록 스왑이나 타일링을 쓴 FP8, 24GB 이상은 메모리 요령 없이 FP16 입니다. 우리 구성인 FP8 + 12블록 스왑 + 타일 VAE 는 가운데 구간을 따릅니다. README 는 특정 설정의 VRAM 을 GB 로 제시하지 않고, 우리도 기록하지 않아서 제시하지 않습니다.
메모리가 부족하면 README 의 해결 순서는 이렇습니다. 인코딩이나 디코딩 단계에서 실패하면 VAE 타일링을 켜고, `blocks_to_swap` 을 올리고(3B 는 1~32, 7B 는 1~36), 마지막으로 GGUF 체크포인트로 바꿉니다. 블록 스왑을 높일수록 VRAM 은 더 아끼지만 느려집니다.
"sharp" 와 "normal" 은?
많이 검색하는 질문이라 말할 수 있는 만큼만 적습니다. README 는 표준 모델 외에 7B 의 "sharp" 변형(`seedvr2_ema_7b_sharp_*`)도 나열합니다. 우리는 이를 쓰지 않고 테스트하지도 않았으므로 실제 차이를 말할 수 없습니다. 우리가 말할 수 있는 것은 자체 3B vs 7B 비교에서 나온 내용입니다. 큰 모델의 이점은 울과 니트에서 가장 뚜렷했고, 데님에서는 "더 많은 질감"이 더는 자연스럽게 보이지 않았습니다. 즉 더 선명한 것이 모든 소재에서 자동으로 낫지는 않습니다. sharp 변형을 시험한다면 질감이 드러나는 소재와 과하게 처리돼 보일 수 있는 소재 양쪽에서 비교하세요.
시도해 볼 설정
README 는 매우 높은 해상도의 아티팩트에는 `input_noise_scale` 을 0.1~0.3 으로, 입력 노이즈가 도움이 되지 않으면 `latent_noise_scale` 을 0.05~0.15 로 시험해 보라고 제안합니다. 우리 `latent_noise_scale` 0.01 은 그 제안 범위보다 낮고 `input_noise_scale` 은 꺼져 있습니다. 2배 작업에 보수적인 선택입니다. 색 보정에서는 README 가 `lab` 을 충실도 옵션, `wavelet` 을 자연스러운 색의 주파수 기반 옵션으로 설명합니다. 우리는 둘을 통제 비교하지 않았습니다.
우리가 측정하지 않은 것
- 속도. 이미지 한 장 단위의 깨끗한 소요 시간이 없습니다. 우리 데이터베이스에 있는 작업 시간은 텍스트와 이미지도 함께 만드는 일괄 작업의 것이라 업스케일 속도에 대해서는 아무것도 말해 주지 않습니다. README 는 `torch.compile` 로 DiT 가 20~40% 빨라진다고 하지만 FP16, FP8, GGUF 의 속도 차이는 수치로 제시하지 않습니다.
- VRAM. 우리 설정의 최대 사용량을 기록하지 않았습니다.
- 모델 로딩 비용. `cache_model` 을 끄면 작업마다 가중치를 다시 불러옵니다. 메모리에는 부담이 적지만 매 작업 로딩 시간이 들며, 그 크기는 측정하지 않았습니다.
여러분의 환경을 재려면 ComfyUI 가 출력하는 실행 시간을 적고, 실행 중 `nvidia-smi` 로 최대 VRAM 을 기록하고, 크기가 다른 이미지 몇 장으로 반복하세요.
위 설정은 2026년 10월 19일 `SeedVR2_3B_API.json`, `SeedVR2_7B_API.json` 과 업스케일러 서비스에서 읽었습니다. 각 설정이 하는 일에 대한 설명은 우리 실험이 아니라 노드 README 에서 가져왔습니다.