핵심 요약
1
큰 파일 첫 읽기는 네트워크 볼륨 1,066MB/s, 글로벌 볼륨 178.9MB/s(EU-RO-1), 104.3MB/s(US-NC-2)였습니다.
2
LLM cold 대기 가운데 값은 네트워크 볼륨 157초, 글로벌 볼륨 376초, 볼륨 없이 HF 다운로드 269초였습니다.
3
H3 첫 영상은 네트워크 볼륨 171–240초, 글로벌 볼륨 780초와 1회 실패(25분 제한)였습니다.
4
워커가 떠 있을 때는 세 경우 모두 0.4초로 같았습니다.
Runpod 네트워크 볼륨은 만들 때 데이터센터를 하나 고르고, 그 데이터센터의 Pod와 서버리스 워커에만 붙습니다. 그 데이터센터에 원하는 GPU 재고가 없으면 볼륨째 다른 곳으로 옮길 수 없죠. 베타로 나온 글로벌 볼륨은 데이터센터를 고르지 않고 만들고, 어느 데이터센터의 Pod나 서버리스 워커에도 붙일 수 있습니다.
갈아타기 전에 같은 모델 파일을 두 볼륨에 넣고 재 봤습니다. 볼륨 사이 복사 시간, 새 Pod에서 처음 읽는 속도, 서버리스 워커가 0개일 때 첫 요청이 끝나기까지 기다리는 시간입니다. 결론부터 말하면, 저는 글로벌 볼륨도 네트워크 볼륨도 아닌 Runpod 모델 캐시를 계속 쓰기로 했습니다.
이 글은 OMG 7편 영상의 측정 내용을 정리한 것입니다. 영상에서 다루지 않은 작은 파일 읽기와 복사할 때 주의할 점도 함께 적었습니다.
같은 모델, 두 볼륨으로 맞춘 비교 조건
모델은 두 개를 썼습니다. 4편에서 서빙했던 Qwen3.8-27B-NVFP4(20.61GB, 파일 16개)와, 영상 모델 MiniMax H3 Ref2VA Turbo4(46.56GB, 파일 6개)입니다.
서버리스 엔드포인트는 RTX PRO 6000 96GB 한 장, min 0 / max 1, idle 30초, FlashBoot 끔으로 맞췄습니다. LLM 워커는 Hub의
worker-vllm v2.28.0, 영상 워커는 제가 만든 H3 ComfyUI 이미지입니다. 측정은 모두 2026년 10월 22일에 했습니다.글로벌 볼륨에 모델 넣기와 복사 시간
글로벌 볼륨은 콘솔 Storage → New volume에서 종류를 Global volume으로 고르면 만들어집니다. 데이터센터와 용량을 고르는 칸이 없고, 넣은 만큼 늘어납니다.
네트워크 볼륨에 있던 모델은 Pod 하나에 두 볼륨을 같이 붙여서 옮겼습니다. 공식 문서는
rsync --archive를 안내하는데요. --archive에 들어 있는 파일 시각 복사(-t)를 글로벌 볼륨이 저장하지 못해서, rsync가 오류 코드 23으로 끝났습니다. 그래서 다음처럼 복사했습니다.rsync -rl --inplace --exclude=.cache /workspace/models/ /workspace-global/models/이렇게 해도 디렉터리 권한·시각 경고는 남았지만, 복사 뒤 SHA-256 검증은 네 건 모두 통과했습니다.
글로벌 볼륨은 오브젝트 스토리지 기반이라 파일 잠금, 원자적 rename, 하드 링크, 권한 설정이 안 됩니다. 볼륨에는 모델 파일만 두고, ComfyUI나 파이썬 환경은 도커 이미지에 넣는 게 안전합니다. 서버리스 엔드포인트에서는 Advanced 설정에서 Global Volume을 고르면 되고, 네트워크 볼륨과 같은
/runpod-volume 경로에 보이므로 핸들러를 고칠 필요가 없었습니다. 엔드포인트 하나에는 네트워크 볼륨과 글로벌 볼륨 중 하나만 붙일 수 있습니다.첫 읽기 속도, 같은 데이터센터에서도 6분의 1
회차마다 새 Pod를 띄워
dd bs=16M of=/dev/null로 큰 모델 파일을 처음 읽는 속도를 쟀습니다. 같은 Pod에서 같은 파일을 두 번 읽으면 메모리 캐시에서 읽게 되므로, 회차마다 Pod를 새로 만들고 지웠습니다.값은 모두 3회 중 가운데 값입니다. 같은 EU-RO-1에서 글로벌 볼륨은 네트워크 볼륨의 약 6분의 1, 미국 US-NC-2에서는 약 10분의 1이었습니다. 작은 파일이 많을수록 차이가 더 벌어져서, 미국에서는 1,000개를 읽는 데 3분 40초가 넘게 걸렸습니다. 글로벌 볼륨 데이터가 실제로 어디에 저장되는지는 공개돼 있지 않아서, 미국에서 더 느린 원인은 추정하지 않았습니다.
LLM 첫 요청, 매번 Hugging Face에서 받는 것보다 느렸다
워커가 0개인지
/health로 확인하고 Qwen에 첫 요청을 보냈습니다. 대기 시간은 Runpod 응답의 delayTime이고, 워커 기동과 모델 로딩이 여기에 들어갑니다.글로벌 볼륨은 세 번 모두 볼륨 없이 매번 Hugging Face에서 받는 것보다도 느렸습니다. 다만 글로벌 볼륨 워커는 세 번 다 US-PA-1, 네트워크 볼륨 워커는 EU-RO-1에 떠서, 워커 위치가 다른 상태의 비교라는 점은 감안해야 합니다.
워커가 떠 있는 상태의 요청은 세 경우 모두 실행 시간 가운데 값 0.4초로 같았습니다. 느린 건 모델을 처음 읽을 때뿐입니다.
영상 모델 첫 요청, 느린 읽기가 두 번 붙는다
H3 워커는 기동할 때 모델 파일 46.56GB의 SHA-256을 모두 계산해서 확인하고, 첫 영상을 만들 때 ComfyUI가 볼륨에서 모델을 다시 읽습니다. 그래서 글로벌 볼륨의 느린 읽기가 기동과 첫 생성에 두 번 붙었습니다. 해시 확인 단계는 측정을 위해 일부러 넣은 것으로, ComfyUI 기본 동작이 아닙니다.
글로벌 볼륨 cold 2회는 두 번 다 네트워크 볼륨과 같은 EU-RO-1에 떴습니다. 실패한 회차는 모델을 읽느라 첫 스텝까지 15분 35초가 걸렸고, 25분째에 핸들러가 생성을 중단했습니다. 같은 워커가 이어서 받은 다음 요청은 206초로 네트워크 볼륨과 비슷했습니다. 비용 때문에 글로벌 볼륨 H3는 cold 2회만 쟀습니다. cold 대기 중 가장 길었던 1,443초는 대부분 GPU 배정 대기여서 볼륨 속도로 보지 않았습니다.
그래서 Runpod 모델 캐시를 쓴다
글로벌 볼륨이 데이터센터에 묶이지 않는 건 분명한 장점입니다. 하지만 서버리스는 워커가 내려갔다 다시 뜰 때마다 모델을 처음부터 읽고, 그때마다 글로벌 볼륨의 느린 첫 읽기를 그대로 기다려야 합니다. 그렇다고 네트워크 볼륨으로 가면 처음 문제였던 데이터센터 종속이 그대로 남습니다.
그래서 저는 지금처럼 Runpod 모델 캐시를 계속 쓰기로 했습니다. 엔드포인트 설정의 Model 칸에 Hugging Face 저장소를 넣으면, Runpod이 워커가 뜰 서버에 모델을 미리 받아 둡니다. 볼륨을 따로 만들 필요가 없고, 문서에 따르면 모델을 받는 시간은 과금되지 않습니다. 6편의 H3 엔드포인트도 비공개 Hugging Face 저장소와 모델 캐시로 돌렸습니다. 다만 모델 캐시는 이번에 같은 조건으로 재지 않았습니다.
글로벌 볼륨이 맞는 경우도 있을 수 있습니다. 워커를 오래 띄워 두는 서비스라면 첫 읽기 비용은 한 번뿐이고, 여러 데이터센터의 Pod에서 같은 데이터를 공유해야 하는 작업이라면 데이터센터에 묶이지 않는 점이 더 클 수 있습니다. 베타라서 속도가 앞으로 바뀔 수 있다는 점도 함께 적어 둡니다.
만드는 순서와 상황별로 무엇을 고를지는 Runpod Korea User Group의 정리 글에 짧게 모아 두었습니다.
같은 조건으로 다시 재 보기
측정 스크립트와 결과는 OMG Runpod Media 레시피 storage/01에 있습니다. 글의 근거를 나중에도 확인할 수 있도록 병합 커밋에 고정한 링크입니다.
read_bench.sh: Pod 안에서 복사 시간, 큰 파일 첫 읽기, 작은 파일 1,000개, SHA-256 검증을 잽니다.step2_round.py: 회차마다 새 Pod를 만들고 결과를 모은 뒤 지웁니다.step3_create.py·step3_run.py: 엔드포인트를 만들고 cold·warm 요청을 보냅니다.results/: 이 글의 개별 실행값입니다. Pod·워커·작업 ID는 지웠습니다.
H3 워커 이미지와 모델을 옮겨 둔 저장소는 공개하지 않았고, 환경변수로 넣도록 했습니다. 이번 측정에는 Pod 약 $1.80(청구액)과 서버리스 실행 시간 기준 약 $15–17(추정)이 들었습니다. 글로벌 볼륨은 저장량과 요청 수로 과금되고, 계정 잔액이 $0이 되면 15일 뒤 볼륨이 삭제됩니다. 측정이 끝나면 엔드포인트와 볼륨을 모두 지우세요.
자주 묻는 질문
Runpod 글로벌 볼륨은 네트워크 볼륨보다 얼마나 느린가요?
2026년 10월 22일 측정에서 큰 파일 첫 읽기는 같은 EU-RO-1에서 네트워크 볼륨 1,066MB/s, 글로벌 볼륨 178.9MB/s로 약 6분의 1이었습니다. US-NC-2에 붙인 글로벌 볼륨은 104.3MB/s였습니다. 글로벌 볼륨은 베타라 속도가 바뀔 수 있습니다.
글로벌 볼륨을 서버리스에 붙이면 콜드 스타트가 얼마나 걸리나요?
Qwen3.8-27B NVFP4 기준 cold 대기 가운데 값이 글로벌 볼륨 376초, 네트워크 볼륨 157초, 볼륨 없이 Hugging Face에서 받을 때 269초였습니다. 글로벌 볼륨 워커는 US-PA-1, 네트워크 볼륨 워커는 EU-RO-1에 떴습니다.
네트워크 볼륨의 모델을 글로벌 볼륨으로 어떻게 옮기나요?
Pod 하나에 두 볼륨을 같이 붙이고 rsync -rl --inplace로 복사했습니다. 공식 문서의 rsync --archive는 글로벌 볼륨이 파일 시각을 저장하지 못해 오류 코드 23으로 끝났습니다. H3 46.56GB를 옮기는 데 215.4초가 걸렸습니다.
워커가 이미 떠 있으면 차이가 있나요?
없었습니다. Qwen 요청의 실행 시간 가운데 값은 볼륨 없음, 네트워크 볼륨, 글로벌 볼륨 모두 0.4초였습니다. H3도 같은 워커의 다음 요청은 206초로 네트워크 볼륨 warm 가운데 값 190초와 비슷했습니다.