We Built a Blender Render Farm Out of Four Laptops
노트북 네 대로 Blender 렌더 팜을 만들었습니다
Blender 렌더 팜 소프트웨어 Flamenco와 Tailscale, Samba를 이용해 서로 다른 장소의 노트북 네 대를 연결했지만, 원격 파일 전송과 GPU 설정 문제가 렌더 시간을 잡아먹었습니다. 작성자는 렌더 팜의 병목이 GPU 수보다 장면 파일 배포와 네트워크 업로드에 있었다고 설명합니다.
- 주제
에디터 노트
이번 실험에서 확인한 병목은 GPU 개수가 아니라 장면 파일을 각 워커에 전달하는 속도였습니다. 직접 연결도 초당 0.65MB인 업로드 회선을 넘어서지 못했고, 릴레이 문제를 손봐도 전송 용량은 늘지 않았습니다. 원격 워커마다 GPU 선택과 파일 경로까지 맞춰야 했다는 점도 가정용 노트북을 모으는 방식의 비용으로 드러납니다. 다만 결과를 Flamenco의 한계로 일반화할 필요는 없습니다. 글에서도 Flamenco는 NAS와 빠른 LAN을 둔 스튜디오 환경을 전제로 하며, 이번 구성은 서로 다른 가정용 회선을 공유 저장소로 묶었습니다. 결국 소프트웨어가 작업을 나누는 일과 작업에 필요한 데이터를 효율적으로 배포하는 일은 별개이며, 이 실험은 후자가 렌더링 성능을 좌우한 사례입니다.
AI 요약
Blender로 약 4분 분량의 영상을 만들던 작성자는 혼자 렌더링할 때 걸리는 시간을 줄이려고 토요일 저녁 노트북 네 대로 렌더 팜을 꾸렸습니다. 초안은 360p와 EEVEE로 렌더링해 GTX 1650에서 프레임당 약 1초가 걸렸지만, 목표 화질인 1080p EEVEE는 영상 전체에 10~22시간, Cycles는 프레임당 76~90초가 예상됐습니다. 로컬에서 Blender 프로세스를 여러 개 띄우자 두 개는 1.3배 빨라지는 데 그쳤고 세 개는 오히려 느려졌습니다. 프레임마다 장면을 다시 설정하지 않도록 애니메이션 렌더 호출을 바꾸자 단일 워커에서 약 22% 빨라졌지만, 더 큰 개선에는 GPU가 필요했습니다.
Flamenco와 공유 파일 구성
Blender가 공개한 Flamenco는 작업을 큐에 넣고 프레임 범위별 태스크로 나누는 Manager와, 태스크를 받아 Blender를 실행하는 Worker로 구성됩니다. 워커는 작업을 마치면 다음 태스크를 가져오며, 실패한 태스크는 다른 워커에서 재시도합니다. 같은 작업에서 세 번 실패한 워커는 해당 작업에서 제외됩니다. 두 프로그램은 Go 단일 바이너리로 실행하며, 데이터베이스나 Kubernetes를 따로 준비하지 않아도 됩니다.
Flamenco는 장면 파일을 워커에 전송하지 않습니다. Manager와 모든 Worker가 같은 경로에서 파일을 읽을 수 있도록 공유 저장소를 마련해야 합니다. 작성자는 Samba 공유 폴더를 만들고 Tailscale 사설망을 연결했습니다. Windows와 Linux에서 같은 파일이 보이는지 확인한 뒤 Blender 프로젝트의 외부 에셋 경로 31개를 점검했습니다. 이 중 25개가 작성자 컴퓨터의 절대 경로를 가리켜 다른 운영체제에서 열리지 않았습니다. 경로를 Blender 상대 경로인 //assets/...로 바꿔 세 프로젝트 파일에서 절대 경로를 없앴습니다.
운영체제마다 공유 폴더 경로가 달라 Flamenco의 양방향 변수를 설정했습니다. Linux 워커는 모두 /mnt/spidey를 사용하고 Windows는 드라이브 문자인 D:\\spidey를 사용했습니다. Windows에서는 네트워크 공유의 UNC 경로 대신 드라이브 문자가 필요했고, Linux 워커끼리는 마운트 경로가 같아야 했습니다. Windows 워커가 Blender를 찾지 못한 문제는 PATH가 아니라 .blend 파일 연결 프로그램을 확인하는 방식에서 생겼습니다. 빈 .blend 파일의 연결 프로그램을 지정하자 Blender 5.2.2 LTS를 인식했습니다.
작동은 했지만 파일을 읽는 데 오래 걸렸습니다
작성자는 노트북 네 대에서 360p 영상 60프레임을 20프레임씩 나눠 렌더링했습니다. 세 워커가 각자 작업을 받아 프레임을 공유 폴더에 저장했고, 서로 다른 컴퓨터에서 만든 결과 프레임은 동일했습니다. 하지만 작성자의 컴퓨터는 115MB 장면 파일을 빠르게 읽고 프레임당 약 0.4초에 렌더링한 반면, Tailscale 릴레이를 거친 노트북 두 대는 렌더링 전에 파일을 여는 데 3분 이상 걸렸습니다. 짧은 청크는 파일의 일부만 내려받는 단위가 아니었습니다. 각 청크가 장면 전체를 열기 때문에 청크를 작게 나누면 전체 파일을 더 자주 읽게 됩니다.
Windows 워커는 파일을 읽은 뒤 Blender의 "Missing DNA block" 오류로 종료됐습니다. 파일 크기는 114,783,416바이트였고 SHA-256 해시도 원본과 같았습니다. 작성자는 .blend 파일 끝부분에 들어 있는 DNA1 블록이 Blender의 데이터 구조 정보를 담는다고 설명합니다. 파일을 끝까지 읽지 못하면 이 블록을 찾지 못해 해당 오류가 날 수 있습니다. Windows에서 반복해서 발생한 오류는 워커를 WSL로 옮기자 사라졌지만, GPU를 쓰지 못한 듯 프레임당 약 50초가 걸렸습니다.
반복 읽기에서는 운영체제 캐시 효과도 확인했습니다. ASUS 노트북은 첫 파일 읽기에 3분 2초가 걸렸고, 다음 청크에서는 31초가 걸렸습니다. 반면 pop-os 노트북은 프레임당 약 2.3초로 작성자의 컴퓨터보다 느렸습니다. 이 노트북에는 NVIDIA GTX 1650 Mobile과 AMD Radeon Vega 내장 GPU가 있었지만 기본 OpenGL은 AMD GPU를 사용했습니다. 작성자는 PRIME render offload 환경 변수를 설정해 Blender가 NVIDIA GPU를 쓰도록 하는 방법을 제시합니다.
네트워크 경로보다 업로드 용량이 병목이었습니다
Tailscale은 기기 간 직접 WireGuard 연결을 우선 시도하고, NAT 환경에서 직접 연결이 실패하면 DERP 릴레이를 거칩니다. 작성자의 pop-os와 ASUS 노트북은 벵갈루루의 릴레이를 사용했고, 지연 시간은 58~415ms까지 변했습니다. NAT 매핑이 목적지마다 달라지는 환경에서는 UDP 홀 펀칭이 실패할 수 있으며, 작성자는 라우터 포트 포워딩을 검토했습니다.
하지만 직접 연결된 WSL 워커도 파일을 읽는 데 약 6분이 걸렸습니다. 작성자 컴퓨터의 업로드 속도는 초당 0.65MB, 약 5Mbit였습니다. 모든 워커가 작성자의 컴퓨터에서 장면 파일을 읽으므로 직접 연결도 릴레이 연결도 이 업로드 속도를 공유했습니다. 두 워커가 동시에 파일을 받으면 전송 시간이 더 늘었습니다. 더 빠른 Wi-Fi에서 업로드 속도를 초당 2.15MB로 높이자 원격 워커의 첫 파일 읽기는 약 1분 30초로 줄었지만, 작성자 컴퓨터가 여섯 청크 중 네 개를 먼저 끝냈습니다.
작성자는 파일을 각 컴퓨터에 미리 복사하거나, 각 라우터와 GPU 설정을 따로 해결하거나, 장시간 전원과 Wi-Fi 연결을 유지하는 일이 필요하다고 정리합니다. 오후 9시 52분에 실험을 종료했고, Flamenco와 Samba, Tailscale을 중단했습니다. 글의 마지막에서는 여러 노트북이 아니라 여러 클라우드 제공업체에 작업을 나눠 영상 렌더링을 마쳤다고 밝혔습니다.
원문: dev.to / 번역·요약: Trawling