모델을 NAS에 두면 로딩이 4배 느려진다 — NFS vs 로컬 디스크 실측

모델을 NAS로 옮기고 나서 첫 로딩이 눈에 띄게 느려진 게 계속 걸렸습니다. 손해인 건 알겠는데 얼마나인지를 몰라서 재봤습니다. 찾아봐도 국내 자료에 숫자가 없더군요.

결론

같은 6.94GB 체크포인트인데 로컬 17.8초, NFS 73.2초. 4배 넘게 납니다.
순차 읽기는 로컬 1.45GB/s, NFS 114MB/s로 13배 차이입니다.
로드 시간은 파일크기 ÷ 처리량 + 13초로 거의 그대로 나옵니다. 오차 1.7%.
13초는 스토리지와 무관한 고정비라, 작은 모델은 옮겨봐야 이득이 별로입니다.
반대로 영상 모델 세트(31GB)는 NFS에서 5분 가까이 걸립니다. 여기선 얘기가 다릅니다.

환경

Radeon AI PRO R9700, ROCm 7.2.4, ComfyUI 0.28.0, Proxmox VM(16코어/94GB RAM), Ubuntu 24.04.

로컬 — VM 가상 디스크(Proxmox 호스트 NVMe 백엔드), 123GB
NFS — Synology NAS, nfs4.1, rsize=wsize=131072, proto=tcp, hard, 1TB

얼마나 빠른가 — 순차 읽기

RAM이 94GB라 그냥 재면 스토리지가 아니라 메모리를 재게 됩니다. dd에 iflag=direct를 줘서 페이지 캐시를 우회했습니다.

대상	1회	2회	3회
NFS (2GiB씩)	113 MB/s	114 MB/s	114 MB/s
로컬 (4GiB씩)	1.45 GB/s	1.45 GB/s	1.46 GB/s

편차가 1% 안입니다. NFS 쪽 114MB/s는 1GbE 실효 상한(118MB/s쯤)에 거의 붙어 있고요. 랜선이 한계라는 뜻인데, 이건 아래에서 따로 확인했습니다.

실제 로드 — 마침 딱 맞는 비교군이 있었다

자주 쓰는 모델만 로컬에 두고 나머지는 NAS에 두는 구조로 쓰는데, 크기가 거의 같은 SDXL 체크포인트가 양쪽에 하나씩 있더군요. 6,938,078,334 바이트와 6,939,105,596 바이트. 0.015% 차이입니다.

모델	크기	위치	첫 실행	로드만
sd_xl_base_1.0	6,938,078,334 B	로컬	23.06 s	17.8 s
novaAnimeXL_ilV190	6,939,105,596 B	NFS	78.5 s	73.2 s

"로드만"은 첫 실행에서 웜 생성 시간 5.3초를 뺀 값입니다. 4.1배. 같은 NAS 위의 다른 체크포인트도 76초, 89초로 같은 대역이었습니다.

숫자가 맞아떨어지나

위 처리량으로 로드 시간을 예측해봤습니다.

NFS   6.94 GB ÷ 113.5 MB/s = 61.1 s
로컬  6.94 GB ÷ 1.45 GB/s  =  4.8 s
예측 차이                   = 56.4 s
실측 차이  73.2 - 17.8      = 55.4 s   (오차 1.7%)

차이가 IO로 전부 설명됩니다. 로컬 쪽에 남는 17.8 - 4.8 = 13.0초가 스토리지와 상관없는 고정비고요. safetensors 파싱, dtype 처리, GPU로 올리는 시간. 정리하면 이렇게 됩니다.

로드 시간 ≈ 파일 크기 ÷ 스토리지 처리량 + 13초

그래서 얼마 버나

위 식으로 계산한 값입니다. 실측한 6.94GB 두 건만 굵게 뒀습니다.

모델	크기	NFS	로컬	절약
SD1.5	2.13 GB	31.8 s	14.5 s	17 s
SDXL 체크포인트	6.94 GB	73.2 s	17.8 s	55 s
FLUX.1-dev Q8_0	12.71 GB	125 s	21.8 s	103 s
WAN 2.2 T2V 세트	30.99 GB	286 s	34.4 s	252 s

WAN 세트는 익스퍼트 12GB 두 개에 텍스트 인코더 6.7GB, VAE 0.25GB를 더한 값입니다. 오늘 이걸 NAS에서 처음 올렸는데 374초 걸리더군요. 로딩만 317초. 프롬프트 걸어놓고 딴짓하다 왔습니다. 예측 286초보다 조금 더 나온 건 파일이 4개라 파싱 비용이 더 붙어서로 보입니다.

작은 모델은 옮겨도 별 이득이 없습니다. 13초 고정비가 다 먹으니까요. 반대로 영상처럼 수십 GB 읽는 작업은 스토리지만 바꿔도 5분을 법니다.

그럼 다 로컬로 옮기면

그럴 수가 없습니다. 로컬은 123GB고 NAS는 1TB인데 모델은 금방 수백 GB가 되니까요. 백업이랑 다른 기기에서 갖다 쓰는 것도 NAS 쪽이 편하고요.

ComfyUI는 extra_model_paths.yaml에 경로를 여러 개 등록할 수 있어서 섞어 씁니다.

nfs:
    base_path: /mnt/ai-assets/comfyui/models/
    is_default: true          # 다운로더가 받는 곳
    checkpoints: checkpoints/
    diffusion_models: |
        diffusion_models/
        unet/
    ...

기준은 주에 몇 번 이상 쓰면 로컬, 가끔 쓰는 대용량은 NAS 정도로 잡고 있습니다. 영상 모델은 애매한데, 한 세션에서 여러 번 돌릴 거면 첫 로드 5분을 한 번만 치르는 셈이라 NAS에 둬도 참을 만합니다.

NAS를 SSD로 바꾸면 빨라지나

위에서 "랜선이 한계"라고 썼는데 그건 추론이었습니다. 확인해봤습니다.

NAS 자체 RAM에 들어갈 만한 작은 파일(wan_2.1_vae, 253,815,318 B)을 O_DIRECT로 다섯 번 연속 읽었습니다. 클라이언트 쪽 캐시는 O_DIRECT가 막고, NAS는 두 번째부터 자기 RAM에서 꺼내줄 크기입니다.

회차	1	2	3	4	5
처리량	114 MB/s	114 MB/s	114 MB/s	114 MB/s	114 MB/s

다섯 번 다 114입니다. 편차 0.4%. NAS가 디스크를 안 거치고 RAM에서 주는데도 114면 디스크는 병목이 아닙니다. 애초에 HDD 한 대도 순차로 150~250MB/s는 나오니 이미 114를 넘고요. 지금 구성에서 디스크는 놀고 있는 셈입니다.

순서가 반대인 거죠. 네트워크 먼저, 디스크는 그다음.

링크	실효 상한	디스크가 병목이 되나	WAN 세트(31GB)
1GbE (현재)	~114 MB/s	아니오. HDD로 충분	286 s
2.5GbE	~285 MB/s	HDD가 한계에 닿기 시작 → SSD 의미 생김	~122 s
10GbE	~1.1 GB/s	예. SSD/NVMe 필요	~41 s
로컬 디스크	1.45 GB/s	—	34 s

아래 세 줄은 링크 상한으로 계산한 값이라 실측이 아닙니다. 그래도 10GbE면 로컬과 거의 붙는다는 건(41초 vs 34초) 눈여겨볼 만합니다. 거기까지 가면 모델을 어디 둘지 고민할 이유가 별로 없어지니까요.

링크 그대로 두고 SSD NAS만 사는 건 돈이 아깝습니다. 114에서 똑같이 막힙니다.
2.5GbE는 비교적 싸게 가는데, 그때부터 HDD가 발목을 잡으니 SSD랑 세트로 가야 이득이 온전합니다.
10GbE는 NIC·스위치·NAS 기종이 다 받쳐줘야 합니다. 시놀로지는 모델마다 갈리고요.
돈 안 쓰는 방법은 위에 적은 핫 모델만 로컬에 두는 구조입니다. 0원으로 4배 가져가는 셈입니다.

한계

페이지 캐시를 비울 root 권한이 없어서 drop_caches를 못 했습니다. 대신 처리량은 O_DIRECT로 캐시를 우회했고, 로드 쪽은 NFS 실측치가 NFS 처리량과 맞아떨어지는 걸로 캐시에 없었다고 봤습니다. 캐시에 있었으면 훨씬 빨랐을 겁니다.
거꾸로 말하면 한 번 읽은 모델은 RAM에 남습니다. 94GB 머신에서는 두 번째 로드부터 NFS 비용이 상당 부분 사라집니다. 이 글 숫자는 부팅 후 그 모델을 처음 쓸 때의 값입니다.
VM 가상 디스크라 베어메탈 NVMe와는 다를 수 있습니다.
1GbE 환경입니다. 10GbE나 SMB, iSCSI는 못 재봤습니다.

같이 재주실 분

재는 건 한 줄이면 됩니다. 캐시만 우회하면 돼요.

dd if=/경로/큰모델.safetensors of=/dev/null bs=8M count=256 iflag=direct

10GbE 쓰시는 분 숫자가 제일 궁금합니다. 링크가 한계라면 10GbE에서는 격차가 확 줄어야 하는데 정말 그런지 보고 싶어서요. NAS 기종이나 프로토콜(SMB/iSCSI)에 따라 다르면 그것도 알려주시면 좋겠습니다.