3D 렌더링용 그래픽카드, 속도보다 VRAM부터 봐야 하는 이유

3D 렌더링용 그래픽카드를 고른다면 벤치마크 속도보다 VRAM 용량부터 확인하세요. 속도가 모자라면 렌더가 늦게 끝날 뿐이지만, VRAM이 모자라면 렌더러에 따라 아예 시작하지 못하거나 시스템 메모리를 빌려 쓰며 눈에 띄게 느려집니다. 뷰포트에서는 잘 돌던 씬이 최종 렌더에서 System is out of GPU memory나 [gpu] CUDA call failed : (2) out of memory를 띄우고 멈추는 장면이 바로 이 경우입니다.

그래서 순서는 이렇습니다. 지금 작업하는 씬 중 가장 무거운 것이 GPU 메모리를 얼마나 쓰는지 재고, 내 렌더러가 VRAM을 넘겼을 때 어떻게 동작하는지 확인한 다음, 그 기준을 넘는 카드들 안에서 속도를 비교합니다. 이 글은 특정 제품을 추천하지 않고, 그 기준을 스스로 세우는 방법을 다룹니다.

그래픽카드 속도와 VRAM은 모자랄 때 벌어지는 일이 다릅니다

GPU 렌더링은 렌더에 필요한 데이터를 그래픽카드 메모리, 즉 VRAM에 올려 두고 계산합니다. 여기에는 생각보다 많은 것이 들어갑니다. 렌더 시점에 서브디비전과 디스플레이스먼트로 불어난 지오메트리, 광선 추적을 빠르게 하려고 만드는 가속 구조(BVH), 압축을 푼 텍스처, 렌더 버퍼와 AOV, 렌더러의 작업 메모리입니다. 모니터를 같은 카드에 연결했다면 화면 표시와 뷰포트, 브라우저 같은 다른 프로그램도 같은 VRAM을 나눠 씁니다.

속도는 연속적인 값입니다. 절반 빠른 카드면 두 배 기다리면 됩니다. VRAM은 경계가 있는 값입니다. 씬이 들어가면 그 카드의 속도대로 렌더되고, 넘치는 순간부터는 렌더러의 대처 방식에 따라 결과가 갈립니다. 시스템 메모리로 넘겨 계속 렌더하거나(out-of-core), 오류를 내고 멈춥니다. 벤치마크 점수는 대개 VRAM에 넉넉히 들어가는 테스트 씬으로 잰 값이라, 내 씬이 넘치는 상황의 속도는 알려주지 않습니다.

GPU를 한 장 더 꽂는 것도 같은 구분으로 봐야 합니다. Blender 매뉴얼과 Arnold GPU FAQ 모두 여러 GPU를 써도 각 GPU는 자기 메모리만 쓴다고 설명합니다. 씬 전체가 카드마다 따로 올라가므로 속도는 늘지만 씬 한도는 늘지 않습니다. Arnold GPU FAQ는 용량이 다른 카드를 섞으면 가장 작은 카드가 한도가 된다고 적고 있습니다. NVLink로 연결한 NVIDIA 카드에서 메모리를 나눠 쓰는 경우(Blender의 Distributed Memory Across Devices, Redshift의 NVLink 옵션)가 예외입니다.

GPU 렌더링에서 씬이 VRAM에 안 올라가면: 렌더러별 out-of-core 차이

VRAM을 넘겼을 때의 동작은 렌더러마다 다릅니다. 아래는 각 렌더러의 공식 문서와 지원 자료에 적힌 내용을 정리한 것이고, 직접 벤치마크한 결과는 아닙니다. 버전에 따라 달라질 수 있으니 쓰는 버전의 문서를 한 번 더 확인하세요.

렌더러	VRAM이 넘치면	주의할 점
Blender Cycles	CUDA·OptiX·HIP·Metal 장치는 GPU 메모리가 차면 자동으로 시스템 메모리를 씀	성능 손해가 있지만 매뉴얼은 대개 CPU 렌더보다는 빠르다고 설명. 따로 켜는 옵션 없음
Redshift	지오메트리와 텍스처는 out-of-core로 시스템 메모리 사용	VDB 볼륨, Irradiance Cache·Irradiance Point Cloud 데이터는 넘기지 못해 VRAM 부족 오류
Octane	Out of Core를 켜면 텍스처와 지오메트리를 시스템 RAM에 둠	켜야 동작. 쓰는 RAM은 다른 프로그램이 못 쓰는 고정 메모리가 되고, 속도 손해가 클 수 있음
Arnold GPU	FAQ 기준 씬과 텍스처가 VRAM에 들어가야 함	넘치면 out of memory 오류. 텍스처는 필요할 때 읽어 들이므로 .tx가 메모리를 아낌. 안 되면 CPU로 전환

Blender Cycles는 가장 관대한 편입니다. Blender 매뉴얼의 GPU Rendering 문서는 CPU로는 되는데 GPU로는 안 되는 가장 흔한 이유로 VRAM 부족을 들고, CUDA·OptiX·HIP·Metal에서는 GPU 메모리가 가득 차면 자동으로 시스템 메모리를 쓴다고 설명합니다. 그래도 시스템 메모리까지 모자라면 렌더는 실패합니다. 목록에 oneAPI(Intel Arc)는 빠져 있으니 Intel 카드라면 이 동작을 기대하지 않는 편이 안전합니다.

Redshift는 처음부터 out-of-core를 내세운 렌더러입니다. Maxon 지원 문서에 따르면 지오메트리와 텍스처는 VRAM을 넘겨도 시스템 메모리로 이어서 렌더합니다. 특히 텍스처는 out-of-core에서도 성능 손해가 작은 편이라고 설명합니다. 대신 VDB 볼륨처럼 넘길 수 없는 데이터가 있어, 연기·폭발 볼륨을 많이 쓰는 작업이라면 그 데이터는 VRAM 안에 들어가야 합니다. 렌더 로그의 statistics 아래 GPU memory 항목을 보면 이번 프레임이 out-of-core로 갔는지 확인할 수 있습니다.

Octane은 기능이 있지만 꺼져 있을 수 있습니다. Cinema 4D용 Octane이라면 Live Viewer 설정의 Out of Core 탭에서 켜고 RAM Usage Limit을 정합니다. OTOY 문서는 이 RAM이 다른 프로그램이 쓸 수 없는 고정 메모리가 되고, 속도 손해가 상당할 수 있다고 경고합니다.

Arnold GPU는 가장 엄격합니다. Arnold 사용자 가이드의 GPU FAQ는 씬과 텍스처가 GPU 메모리에 들어가야 한다고 답합니다. 다만 텍스처는 필요할 때 읽어 들이므로, 타일과 밉맵이 들어 있는 .tx 파일을 쓰면 필요한 해상도만 올라가 메모리를 아낄 수 있습니다. Autodesk 지원 문서가 안내하는 out of memory 대처도 텍스처 크기 줄이기, 디스플레이스먼트·서브디비전 낮추기, 일부 메시 숨기기, CPU로 바꿔 렌더하기입니다.

out-of-core는 보험이지 추가 용량이 아닙니다. 렌더가 멈추지 않게 해 줄 뿐, 넘친 만큼 느려지는 폭은 씬과 장비에 따라 다릅니다. 매 프레임 넘치는 씬이라면 느린 속도가 기본값이 되는 셈이니, 그래픽카드를 고를 때는 넘치지 않는 쪽을 목표로 두세요.

내 씬에 필요한 VRAM 가늠하는 법

카드 스펙표보다 지금 작업 파일이 더 정확한 답을 줍니다. 최근 작업 중 가장 무거운 씬 하나를 골라, 최종 렌더와 같은 해상도와 설정으로 렌더하면서 메모리 사용량을 봅니다.

• Blender Cycles: 렌더 창 위쪽 정보줄의 Mem과 Peak 값을 봅니다. Peak가 이번 렌더에서 Cycles가 잡은 최대 메모리입니다. 뷰포트나 Blender 자체가 쓰는 메모리는 여기에 다 포함되지 않습니다.
• Redshift: 렌더 로그의 statistics 부분에 있는 GPU memory 항목을 봅니다. Redshift는 기본값으로 사용 가능한 VRAM의 90%를 미리 잡아 두기 때문에, 작업 관리자에서는 씬이 가벼워도 VRAM이 거의 찬 것처럼 보일 수 있습니다.
• Arnold GPU: 렌더 로그와 Render Settings의 Diagnostics에서 켤 수 있는 통계·리포트로 메모리 사용량을 봅니다. Autodesk 지원 문서는 렌더 중 NVIDIA-SMI나 작업 관리자로 VRAM을 확인하라고 안내합니다.
• 공통: Windows 작업 관리자의 성능 > GPU에서 전용 GPU 메모리를 봅니다. 카드 전체 사용량이라 다른 프로그램 몫까지 섞여 있으니, 렌더 전과 렌더 중 값을 비교합니다.

지금 카드로는 VRAM이 넘쳐서 측정 자체가 어렵다면 텍스처부터 따로 계산해 봅니다. 압축을 풀어 통째로 올리는 경우 텍스처 한 장의 메모리는 가로 × 세로 × 채널 수 × 채널당 바이트입니다. 디스크의 JPG·PNG 크기는 압축된 크기라서 이 값과 전혀 다릅니다.

텍스처	계산	메모리
4K RGBA 8bit	4096 × 4096 × 4 × 1바이트	약 64MB
4K RGBA 16bit half	4096 × 4096 × 4 × 2바이트	약 128MB
4K RGBA 32bit float	4096 × 4096 × 4 × 4바이트	약 256MB
8K RGBA 8bit	8192 × 8192 × 4 × 1바이트	약 256MB

4K 8bit 텍스처 20장이면 약 1.3GB, 같은 20장을 32bit float EXR로 쓰면 약 5GB입니다. UDIM은 타일 수만큼 곱해집니다. 이 계산은 상한선에 가깝습니다. Arnold의 .tx처럼 타일과 밉맵으로 필요한 부분만 올리는 방식, Redshift의 텍스처 캐시, Blender 5.2 LTS에 추가된 Cycles의 Texture Cache(.tx)를 쓰면 실제 사용량은 이보다 적을 수 있습니다.

지오메트리는 렌더 시점의 폴리곤 수로 봅니다. 서브디비전은 한 단계마다 면 수가 약 네 배로 늘어나므로, 뷰포트에서 레벨 1로 보던 모델을 렌더에서 레벨 3으로 올리면 면 수는 약 16배가 됩니다. 같은 나무를 복사본 1,000개로 두면 1,000개 분량이 올라가고, 인스턴스로 두면 원본 하나에 위치 정보만 더해집니다. 헤어, 파티클, VDB 볼륨도 이 몫에 들어갑니다.

측정한 Peak에 여유분을 더한 값이 기준선입니다. 화면 표시와 뷰포트, 함께 띄워 두는 Substance Painter나 브라우저가 같은 카드를 쓰고, 다음 프로젝트의 씬은 대개 지금보다 커집니다. 얼마를 더할지는 작업 방식마다 다르지만, 측정값이 카드 용량에 딱 붙는다면 그 카드는 이미 한계라고 보는 편이 맞습니다.

그래픽카드 메모리로 먼저 거르고, 속도는 그다음에 비교합니다

1. 기준선 정하기: 가장 무거운 씬의 Peak에 여유분을 더합니다.
2. 렌더러로 엄격함 정하기: Arnold GPU라면 기준선이 VRAM 안에 들어가야 합니다. Redshift에서 볼륨을 많이 쓴다면 볼륨 데이터가 들어가야 합니다. Cycles·Octane·Redshift의 일반 씬은 넘쳐도 렌더는 되지만 느려지므로, 자주 넘친다면 한 단계 큰 용량을 봅니다.
3. 통과한 카드끼리 속도 비교: 같은 렌더러의 벤치마크로 비교합니다. Cycles라면 Blender 매뉴얼이 안내하는 Blender Open Data가 있습니다. 같은 GPU 칩에 VRAM 용량만 다른 모델이 있다면 속도는 비슷해도 넘치는 지점은 다릅니다.
4. 여러 장을 쓸 계획이면: 카드마다 기준선을 넘어야 합니다. 작은 카드를 섞으면 그 카드가 한도가 됩니다.
5. 시스템 메모리도 확인: out-of-core는 시스템 RAM을 빌려 쓰므로 RAM이 부족하면 보험도 작동하지 않습니다.

당장 VRAM이 부족하다면 줄이는 순서

카드를 바꾸기 전에, 또는 바꿀 수 없을 때는 메모리를 크게 먹는 순서대로 줄여 봅니다. 원본 씬은 복제해 두고 시험하세요.

첫째, 텍스처 해상도입니다. 화면에서 작게 보이는 에셋까지 4K·8K일 필요는 없습니다. 어느 에셋에 얼마만큼의 해상도가 필요한지는 화면에서 차지하는 크기와 UV 면적으로 판단할 수 있고, 이 기준은 텍셀 밀도와 UV 크기 글에서 정리했습니다. Blender에서는 Render Properties의 Simplify 패널에 있는 Texture Size Limit(4.x에서는 Texture Limit)로 텍스처를 한꺼번에 줄여 렌더가 되는지 먼저 시험해 볼 수 있습니다. Arnold는 .tx 변환이 먼저입니다.

둘째, 렌더 시점의 지오메트리입니다. 렌더용 서브디비전 레벨과 디스플레이스먼트 세분을 한 단계씩 낮춰 보고, 반복되는 소품은 인스턴스로 바꿉니다. Blender의 Simplify에 있는 Max Subdivision도 같은 시험에 쓸 수 있습니다.

셋째, 볼륨입니다. 쓰지 않는 VDB 그리드를 지우고 카메라 밖의 영역을 잘라 냅니다. Redshift에서는 볼륨이 out-of-core로 넘어가지 않으므로 이 단계가 특히 중요합니다.

넷째, 같은 카드를 쓰는 다른 프로그램을 닫고, 마지막으로 CPU 렌더를 씁니다. Arnold와 Cycles는 같은 씬을 CPU로 렌더할 수 있고, CPU는 시스템 RAM을 씁니다.

한 줄 정리

3D 렌더링용 그래픽카드는 내 가장 무거운 씬의 메모리 Peak로 먼저 거르고, 그 기준을 넘는 카드들 사이에서만 속도를 비교하세요.