Runpod 네트워크 볼륨을 써 봤다면 한 번쯤 겪으셨을 텐데요. 볼륨을 만들 때 고른 데이터센터에 원하는 GPU가 없으면, 볼륨째 다른 곳으로 옮길 수가 없습니다. 베타로 나온 글로벌 볼륨은 이 문제를 풀겠다고 나온 기능입니다. 데이터센터를 고르지 않고 만들고, 어느 데이터센터의 Pod나 서버리스 워커에도 붙습니다.
그래서 갈아탈 만한지, 같은 모델 파일을 두 볼륨에 넣고 재 봤습니다. 짧게 답하면 서버리스에서는 아직 아니었습니다. 같은 데이터센터에서도 모델을 처음 읽는 속도가 약 6분의 1이라, 워커가 새로 뜰 때마다 기다리는 시간이 두 배 넘게 늘었거든요.
이 글은 직접 써 보려는 분을 위해 만드는 법, 쓸 때 주의할 점, 결과 요약, 고르는 기준을 정리했습니다. 회차별 값과 측정 방법은 Oh My GPU의 전체 측정 글에, 화면으로 보는 설명은 OMG 7편 영상에 있습니다.
글로벌 볼륨과 네트워크 볼륨, 무엇이 다른가
| 네트워크 볼륨 | 글로벌 볼륨 (베타) | |
|---|---|---|
| 만들 때 고르는 것 | 데이터센터, 용량 | 없음 (넣은 만큼 늘어남) |
| 붙일 수 있는 곳 | 같은 데이터센터의 Pod·워커 | 어느 데이터센터의 Pod·워커 |
| Pod에서 보이는 경로 | /workspace |
/workspace-global (네트워크 볼륨과 함께 붙였을 때) |
| 서버리스에서 보이는 경로 | /runpod-volume |
/runpod-volume |
| 파일 시스템 | fuse |
fuse.geesefs (오브젝트 스토리지 기반) |
| 안 되는 것 | 없음 | 파일 잠금, 원자적 rename, 하드 링크, 권한 설정, 파일 시각 저장 |
서버리스에서는 두 볼륨 모두 /runpod-volume에 보이므로, 쓰던 핸들러는 경로를 고치지 않고 그대로 쓸 수 있습니다. 다만 엔드포인트 하나에는 둘 중 하나만 붙일 수 있습니다.
만들고 모델 옮기기
- 콘솔 Storage → New volume에서 종류를 Global volume으로 고릅니다. 데이터센터와 용량 칸은 없습니다.
- 이미 네트워크 볼륨에 모델이 있다면, Pod 하나에 두 볼륨을 같이 붙이고 복사합니다.
- 서버리스 엔드포인트의 Advanced 설정에서 Global Volume을 고릅니다.
복사할 때 하나 주의할 점이 있습니다. 공식 문서는 rsync --archive를 안내하지만, 글로벌 볼륨은 파일 시각을 저장하지 못해서 --archive에 들어 있는 시각 복사(-t) 때문에 rsync가 오류 코드 23으로 끝났습니다. 아래처럼 -rl --inplace로 복사했습니다.
rsync -rl --inplace --exclude=.cache /workspace/models/ /workspace-global/models/이렇게 해도 디렉터리 권한·시각 경고는 남습니다. 경고만 보고 실패로 판단하지 말고, 복사가 끝나면 SHA-256으로 파일을 확인하는 걸 권합니다. 이번에는 네 건 모두 통과했고, H3 모델 46.56GB를 옮기는 데 215.4초가 걸렸습니다.
파일 잠금·하드 링크·권한이 안 되니 볼륨에는 모델 파일만 두는 게 안전합니다. ComfyUI나 파이썬 환경은 도커 이미지에 넣습니다.
숫자 세 개로 본 결과
같은 모델(Qwen3.8-27B NVFP4 20.61GB, MiniMax H3 46.56GB)을 두 볼륨에 넣고, 서버리스는 RTX PRO 6000 한 장, min 0 / max 1, FlashBoot 끔으로 맞췄습니다. 측정은 2026년 10월 22일 하루, 값은 3회 중 가운데 값입니다.
| 항목 | 네트워크 볼륨 | 글로벌 볼륨 |
|---|---|---|
| 큰 파일 첫 읽기 (EU-RO-1) | 1,066MB/s | 178.9MB/s |
| LLM 첫 요청 대기 (워커 0개에서) | 157초 | 376초 |
| H3 첫 영상 생성 | 171–240초 | 780초, 1회는 25분 제한에 걸려 실패 |
| 워커가 떠 있을 때 LLM 요청 | 0.4초 | 0.4초 |
눈에 띄는 건 두 가지였습니다. 글로벌 볼륨에서 LLM 첫 요청은 볼륨 없이 매번 Hugging Face에서 받는 것(269초)보다도 느렸습니다. 그리고 워커가 한 번 뜨고 나면 차이가 없었습니다. 느린 건 모델을 처음 읽는 순간에 몰려 있습니다.
미국 US-NC-2 Pod에 붙인 글로벌 볼륨은 첫 읽기가 104.3MB/s로 더 느렸습니다. LLM 측정에서는 글로벌 볼륨 워커가 US-PA-1, 네트워크 볼륨 워커가 EU-RO-1에 떠서 위치가 다른 비교라는 점도 감안해 주세요. 이런 조건과 회차별 값은 전체 측정 글에 모두 적었습니다.
언제 무엇을 고를까
| 상황 | 추천 | 이유 |
|---|---|---|
| 서버리스, min 0으로 자주 내렸다 올림 | Runpod 모델 캐시 | 워커가 뜰 때마다 첫 읽기를 기다리지 않고, 데이터센터에도 묶이지 않음 |
| 공개된 Hugging Face 모델이 아님 | 비공개 HF 저장소 + 모델 캐시 | OMG 6편의 H3 엔드포인트가 이 방식 |
| 워커나 Pod를 오래 켜 두는 서비스 | 글로벌 볼륨도 고려 | 첫 읽기 비용이 한 번뿐이라 느린 단점이 작아짐 |
| 여러 데이터센터의 Pod에서 같은 데이터를 공유 | 글로벌 볼륨 | 데이터센터에 묶이지 않는 장점이 가장 큼 |
| 한 데이터센터에서 빠른 읽기가 가장 중요 | 네트워크 볼륨 | 같은 EU-RO-1에서 약 6배 빨랐음 |
저는 서버리스에서는 지금처럼 Runpod 모델 캐시를 계속 쓰기로 했습니다. 엔드포인트의 Model 칸에 Hugging Face 저장소를 넣으면 워커가 뜰 서버에 모델을 미리 받아 두고, 문서에 따르면 받는 시간은 과금되지 않습니다. 다만 모델 캐시는 이번에 같은 조건으로 재지 않았으니, 위 표의 모델 캐시 줄은 측정값이 아니라 제 선택 기준입니다. 글로벌 볼륨은 베타라 속도가 바뀔 수 있습니다.
따라 해보기
측정 스크립트와 결과는 OMG Runpod Media 레시피 storage/01에 있습니다. 글의 근거를 나중에도 확인할 수 있도록 병합 커밋에 고정한 링크입니다.
README.md에서 측정 조건과 비용을 확인합니다. 이번 측정에는 Pod 약 $1.80(청구액), 서버리스 약 $15–17(실행 시간 기준 추정)이 들었습니다.- Pod 안에서
read_bench.sh로 복사 시간, 큰 파일 첫 읽기, SHA-256 검증을 잽니다. step2_round.py가 회차마다 새 Pod를 만들고 결과를 모은 뒤 지웁니다. 같은 Pod에서 다시 읽으면 메모리 캐시에서 읽기 때문입니다.step3_create.py·step3_run.py로 엔드포인트를 만들고 cold·warm 요청을 보냅니다.
측정이 끝나면 엔드포인트와 볼륨을 모두 지우세요. 글로벌 볼륨은 저장량과 요청 수로 과금되고, 계정 잔액이 $0이 되면 15일 뒤 볼륨이 삭제됩니다.
글로벌 볼륨을 다르게 써 본 경험이나 잘 맞았던 쓰임새가 있다면 Discord에서 나눠 주세요.