최신 텐서 코어가 아무리 강력해도 데이터가 제때 도착하지 않으면 연산 엔진은 멈추게 됩니다. AI 인프라의 승패는 이제 GPU 스펙이 아니라 스토리지가 GPU 메모리에 데이터를 전달하는 속도에서 결정됩니다.
1. GPU 연산력 100% 활용을 가로막는 I/O 병목의 진실
수십억 원을 들여 최신 GPU 클러스터를 구축하고도 정작 모니터링 대시보드에서 GPU 연산 유휴율이 50%를 넘나드는 광경을 마주할 때가 있습니다. 현업에서 수많은 AI 엔지니어와 인프라 아키텍트들이 겪는 이 현상의 주원인은 연산 능력 부족이 아닙니다. GPU 연산 코어에 데이터를 전송하는 스토리지 입출력(I/O) 서브시스템의 지연 때문입니다.
엔비디아의 H100, H200, 그리고 최신 Blackwell B200에 이르기까지 GPU의 부동소수점 연산 성능(FLOPs)은 세대마다 3배에서 5배씩 비약적으로 도약했습니다. 반면 스토리지를 연결하는 호스트 인터페이스와 전통적인 운영체제 커널의 I/O 경로는 여전히 과거 범용 서버 구조에 묶여 있습니다.
이 구조적 괴리는 AI 데이터 파이프라인 전반에서 3대 I/O 병목 지점을 만들어냅니다.
1.
대규모 멀티모달 학습 데이터의 무작위 인제스천: 수억 장의 이미지, 동영상, 토큰화된 텍스트 파일을 끊임없이 GPU로 읽어 들이는 과정에서 파일 시스템 메타데이터 조회와 소형 블록 I/O 지연이 발생합니다.
2.
초대형 모델 체크포인트의 동시 덤프 및 복원: 수천억 개 파라미터를 가진 분산 학습 도중 장애에 대비해 수백 GB에서 수 TB에 달하는 가중치와 옵티마이저 상태를 기록할 때, 스토리지 쓰기 대역폭이 부족하면 수천 장의 GPU가 연산을 멈춘 채 대기하는 '배리어 동기화 정체'가 일어납니다.
3.
초장문(Long-context) LLM 추론 시의 동적 KV 캐시 교체: 128k 토큰 이상의 긴 문맥을 처리하는 환경에서 GPU VRAM 부족으로 인해 호스트 스토리지와 GPU 사이에서 빈번한 캐시 스왑이 발생하며 추론 응답 지연시간이 급격히 증가합니다.
현업에서 흔히 시도하는 '단순 고속 NVMe SSD 증설'로는 이 문제를 풀 수 없습니다. 병목의 근본 원인이 저장 매체 자체의 순수 성능보다는 운영체제 커널의 페이지 캐시와 호스트 CPU를 거치는 전송 경로 자체에 있기 때문입니다.
2. NVIDIA GPUDirect Storage(GDS): 바운스 버퍼를 제거한 DMA 혁신
2.1 레거시 Linux POSIX I/O의 구조적 한계
기존 리눅스 환경에서 스토리지의 데이터를 GPU 메모리(HBM/VRAM)로 불러오는 과정은 호스트 시스템 메모리(DRAM)를 징검다리로 삼는 '바운스 버퍼(Bounce Buffer)' 방식을 따랐습니다.
이 전통적인 방식은 세 가지 치명적인 비효율을 수반합니다.
•
이중으로 발생하는 데이터 복사: 데이터가 스토리지 컨트롤러에서 호스트 DRAM으로 1차 복사된 뒤, 다시 cudaMemcpy를 통해 GPU HBM으로 2차 복사됩니다. 동일한 데이터가 호스트 시스템 버스를 두 번 통과하므로 시스템 메모리 대역폭을 심각하게 소모합니다.
•
호스트 CPU 코어 고갈: 수십 GB/s에 달하는 고속 데이터 스트림을 처리하기 위해 수십 개의 CPU 코어가 메모리 복사 작업에 100% 투입됩니다. 이로 인해 데이터 전처리(DataLoader)나 분산 노드 간 통신(NCCL) 스케줄링에 사용되어야 할 CPU 자원이 완전히 고갈됩니다.
•
지연시간 스파이크 및 지터(Jitter): 운영체제 커널 공간과 사용자 공간 사이의 잦은 컨텍스트 스위칭, 페이지 폴트(Page Fault), 커널 락 경합으로 인해 꼬리 지연시간(Tail Latency)이 불안정해집니다.
2.2 GDS 직접 DMA(Direct Memory Access) 아키텍처
NVIDIA Magnum IO GPUDirect Storage(GDS)는 호스트 CPU와 시스템 DRAM을 데이터 이동 경로에서 완전히 제외하여 이 문제를 해결합니다.
GDS의 핵심 메커니즘은 제어 경로(Control Path)와 데이터 경로(Data Path)의 명확한 분리입니다.
•
제어 경로 (Control Path): CPU는 파일 열기, 메타데이터 조회, I/O 큐 제출 등 가벼운 제어 작업만 처리합니다.
•
데이터 경로 (Data Path): 실제 데이터 블록은 스토리지 디바이스(로컬 NVMe 또는 NVMe-oF NIC)에서 PCIe 스위치를 거쳐 GPU HBM으로 직접 전송(Zero-Copy DMA)됩니다.
이를 구현하는 핵심 소프트웨어 스택은 다음과 같습니다.
•
사용자 공간 cuFile API (libcufile.so): POSIX 표준 입출력(pread, pwrite)을 대체하여 GPU 메모리 포인터와 파일 디스크립터 간의 직접 입출력을 처리합니다.
•
커널 모듈 nvidia-fs.ko: 리눅스 가상 파일 시스템(VFS) 계층과 NVMe 드라이버 사이에서 동작하는 브리지 드라이버입니다. GPU 가상 메모리 주소를 PCIe 물리 주소로 변환하고 스토리지 컨트롤러를 위한 DMA 디스크립터(Scatter-Gather List)를 생성합니다.
•
O_DIRECT 비버퍼링 플래그: 파일 열기 시 커널 페이지 캐시를 건너뛰고 스토리지와 GPU 간 직접 전송합니다.
•
BAR1 (Base Address Register 1) 및 ReBAR (Resizable BAR): 외부 PCIe 디바이스가 GPU HBM에 직접 접근할 수 있도록 주소 공간을 개방합니다. 최신 시스템에서는 ReBAR 기술을 통해 전체 GPU 메모리를 단일 주소 창으로 노출하여 윈도우 스위칭 오버헤드를 없앱니다.
실제 cuFile API를 사용하는 C/C++ 코드 패턴은 직관적입니다.
#include <fcntl.h>
#include <unistd.h>
#include <cuda_runtime.h>
#include "cufile.h"
// 1. GDS 드라이버 초기화
CUfileError_t status = cuFileDriverOpen();
// 2. O_DIRECT 모드로 데이터 파일 오픈
int fd = open("/mnt/nvme/model_weights.bin", O_RDONLY | O_DIRECT);
// 3. cuFile 파일 핸들 등록
CUfileDescr_t descr;
memset(&descr, 0, sizeof(descr));
descr.handle.fd = fd;
descr.type = CU_FILE_HANDLE_TYPE_OPAQUE_FD;
CUfileHandle_t cf_handle;
status = cuFileHandleRegister(&cf_handle, &descr);
// 4. GPU 메모리 할당 및 GDS 버퍼 등록 (물리 DMA 주소 고정)
void* d_buf = nullptr;
size_t io_size = 1024 * 1024 * 128; // 128MB 청크
cudaMalloc(&d_buf, io_size);
status = cuFileBufRegister(d_buf, io_size, 0);
// 5. 직접 DMA 읽기 수행 (호스트 CPU 및 DRAM 바이패스)
ssize_t bytes_read = cuFileRead(cf_handle, d_buf, io_size, 0, 0);
// 6. 리소스 안전 해제
status = cuFileBufDeregister(d_buf);
cudaFree(d_buf);
cuFileHandleDeregister(cf_handle);
close(fd);
cuFileDriverClose();2.3 PCIe 하드웨어 토폴로지 분석: PIX, PHB, NODE
GDS의 성능을 온전히 끌어내기 위해서는 서버 내부의 PCIe 연결 토폴로지가 최적 경로로 구성되어 있는지 반드시 확인해야 합니다.
1.
동일 PCIe 스위치 하위 (PIX): NVMe 드라이브(또는 RDMA NIC)와 GPU가 동일한 PCIe 스위치(Broadcom PEX, Microchip Switchtec 등)에 직결된 상태입니다. 트래픽이 CPU 루트 컴플렉스로 올라가지 않고 스위치 내부에서 직접 루프백되므로 PCIe Gen5 x16 기준 회선 속도(Line-Rate, 약 63 GB/s)의 95% 이상을 뽑아냅니다.
2.
동일 루트 컴플렉스 하위 (PHB): 서로 다른 PCIe 스위치에 분기되어 있으나 동일한 CPU 소켓의 루트 포트에 연결된 구조입니다. 데이터가 루트 컴플렉스를 통과해야 하므로 루트 포트 경합이 발생하여 대역폭이 회선 속도의 80~90% 수준으로 소폭 저하될 수 있습니다.
3.
Cross-Socket NUMA 링크 경유 (NODE / SYS): NVMe와 GPU가 서로 다른 CPU 소켓에 물려 있는 경우입니다. 데이터가 소켓 간 인터커넥트(Intel UPI, AMD Infinity Fabric)를 횡단하므로 지연시간이 2배 이상 늘어나고 대역폭이 급감합니다. 메인보드 설정에 따라 P2P DMA가 차단되기도 합니다.
토폴로지 확인은 nvidia-smi topo -m 명령어로 진단합니다. 스토리지 디바이스와 GPU 간의 관계가 PIX 또는 PXB로 표시되는지 확인해야 하며, NODE나 SYS로 표시된다면 PCIe 슬롯 재배치나 NUMA 바인딩을 조정해야 합니다.
2.4 정량 벤치마크 지표
GDS 적용 시 얻을 수 있는 성능 개선 효과는 매우 명확합니다.
I/O 블록 크기 | 레거시 POSIX I/O 지연시간 | GDS (cuFile) 지연시간 | 지연시간 개선 배율 |
4 KB (Random Read) | 85.4 µs | 11.2 µs | 약 7.6배 개선 |
64 KB (Random Read) | 142.0 µs | 18.5 µs | 약 7.7배 개선 |
1 MB (Sequential Read) | 420.0 µs | 58.0 µs | 약 7.2배 개선 |
16 MB (Sequential Read) | 3,850.0 µs | 510.0 µs | 약 7.5배 개선 |
•
CPU 점유율 절감: 50 GB/s 대역폭 부하 기준, 레거시 POSIX I/O는 128개 CPU 코어를 100% 점유하며 시스템을 마비시키지만, GDS는 CPU 점유율을 2.8%로 낮춥니다. 남는 CPU 자원은 데이터 토큰화와 전처리 연산에 오롯이 투입할 수 있습니다.
•
처리량 확장성: 8장의 H100과 8개의 400Gb/s InfiniBand NIC로 구성된 DGX H100 시스템에서 레거시 I/O는 약 82.0 GB/s에 머무르는 반면, GDS는 네트워크 회선 한계에 근접한 378.0 GB/s(4.6배 향상)를 달성합니다.
2.5 실무 구성 및 설정 파일(/etc/cufile.json) 튜닝
GDS 런타임의 안정적인 운영을 위해서는 /etc/cufile.json 파일의 파라미터를 정확히 설정해야 합니다.
{
"logging": {
"dir": "/var/log/cufile",
"level": "INFO"
},
"execution": {
"max_io_threads": 4,
"max_io_queue_depth": 128,
"parallel_io": true,
"min_io_threshold_size_kb": 4
},
"properties": {
"max_direct_io_size_kb": 16384,
"allow_compat_mode": false
},
"fs": {
"generic": {
"posix_unaligned_writes": false
}
}
}여기서 가장 중요한 설정은 allow_compat_mode: false입니다. 이 값이 true이면 하드웨어 구성 오류나 드라이버 불일치, 정렬되지 않은 블록 접근 시 경고 없이 기존 레거시 바운스 버퍼 모드로 자동 폴백됩니다. 성능 저하의 원인을 빠르게 파악하려면 이 값을 반드시 false로 지정하여 비정상 경로 발생 시 즉각 에러를 반환하도록 구성해야 합니다.
3. LLM 서빙과 VRAM의 한계: NVMe 기반 가중치 및 KV 캐시 오프로딩
3.1 컨텍스트 확장과 VRAM 고갈 메커니즘
LLM 추론 환경에서 컨텍스트 윈도우가 32k에서 128k, 나아가 1M 토큰으로 늘어나면서 서빙 시스템의 핵심 병목은 연산 속도에서 GPU VRAM 용량 한계로 전환되었습니다.
LLM의 자기회귀(Autoregressive) 생성 과정에서 과거 모든 토큰의 Key, Value 텐서를 보관하는 KV 캐시의 토큰당 크기는 다음 공식으로 계산됩니다.
\text{KV Cache Size per Token (Bytes)} = 2 \times n_{\text{layers}} \times n_{\text{kvheads}} \times d_{\text{head}} \times b
•
2: Key 텐서와 Value 텐서 2개 세트
•
n_layers: 트랜스포머 레이어 수
•
n_kvheads: KV 어텐션 헤드 수 (GQA 적용 시 쿼리 헤드보다 적음)
•
d_head: 어텐션 헤드 차원 크기
•
b: 데이터 정밀도 바이트 수 (FP16 = 2 Bytes, FP8 = 1 Byte)
시퀀스 길이 S와 동시 처리 배치 크기 B를 반영한 총 KV 캐시 메모리 요구량은 다음과 같습니다.
\text{Total KV Cache (Bytes)} = B \times S \times \left( 2 \times n_{\text{layers}} \times n_{\text{kvheads}} \times d_{\text{head}} \times b \right)
모델 아키텍처 | 레이어 수 | KV 헤드 수 | 헤드 차원 | 토큰당 크기 | 32k 단일 요청 | 128k 단일 요청 | 128k 동시 요청 (배치 16) |
Llama-3-8B | 32 | 8 (GQA) | 128 | 131.07 KB | 4.19 GB | 16.78 GB | 268.44 GB |
Llama-3-70B | 80 | 8 (GQA) | 128 | 327.68 KB | 10.49 GB | 41.94 GB | 671.09 GB |
Llama-3.1-405B | 126 | 8 (GQA) | 128 | 516.10 K | 16.52 GB | 66.06 GB | 1,056.96 GB |
Llama-3-70B(FP16) 환경에서는 단 1개의 128k 요청이 41.94 GB의 VRAM을 소모합니다. 8장의 H100(총 640 GB) 노드에서 가중치(FP8 기준 70 GB)를 적재하고 남은 메모리에 128k 요청을 올리면 동시 수용 가능한 사용자 수는 13명에 불과합니다.
메모리가 고갈되어 진행 중인 요청의 캐시를 비우면(Eviction), 나중에 이를 다시 처리할 때 처음부터 프롬프트를 재연산(Prefill Recomputation)해야 하므로 막대한 GPU 자원 낭비와 응답 지연이 발생합니다.
3.2 가중치(Weights) vs KV 캐시(KV Cache) 오프로딩 I/O 패턴 비교
모델 가중치 오프로딩과 KV 캐시 오프로딩은 데이터 특성과 입출력 접근 패턴이 근본적으로 다릅니다.
비교 항목 | 모델 가중치 오프로딩 (Weight Offloading) | KV 캐시 오프로딩 (KV Cache Offloading) |
데이터 특성 | 정적(Static), 불변(Immutable) 데이터 | 동적(Dynamic), 토큰 생성마다 증가하는 가변 데이터 |
접근 패턴 | 결정론적 순차 접근 (Layer 0 $\rightarrow$ Layer $N-1$) | 비연속 가상 블록 기반 랜덤 접근 (Block Table 매핑) |
주요 I/O 크기 | 대용량 순차 읽기 (레이어당 수백 MB ~ 수 GB 단위) | 세밀한 청크 읽기/쓰기 (블록당 16~64 토큰, 수 MB 단위) |
I/O 작업 종류 | 읽기 전용 (Read Only) | 읽기 및 쓰기 (Read & Write, 빈번한 스왑 인/아웃) |
연산 중첩 기법 | 더블 버퍼링(Double Buffering) 및 레이어 프리페치 | 비동기 DMA 스트림, 연속 배치 스왑, 청크 프리페치 |
핵심 요구 성능 | 지속적인 대용량 순차 대역폭 | 높은 랜덤 IOPS, 깊은 큐 깊이, 안정적인 p99 지연시간 |
가중치 오프로딩은 토큰 1개를 생성할 때마다 전체 레이어 가중치를 스토리지에서 다시 읽어와야 하므로 인터랙티브 서빙에서는 처리 속도가 크게 떨어집니다. 반면 KV 캐시 오프로딩은 가중치를 GPU HBM에 고정해 두고 비활성 세션의 캐시 블록만 고속 스토리지로 교체하므로 서빙 처리량을 수 배 이상 끌어올릴 수 있습니다.
3.3 4계층 메모리 레이턴시 래더 (Latency Ladder)
AI 서빙 인프라의 메모리 계층 구조는 비용과 지연시간의 균형을 맞추기 위해 4단계 계층으로 구성됩니다.
계층 (Tier) | 저장 매체 | 인터페이스 | 실효 대역폭 | 접근 지연시간 | 일반적 구성 용량 | 적합한 데이터 역할 |
Tier 0 | GPU HBM3 / HBM3e | On-Die 1024-bit Bus | 2.0 ~ 8.0 TB/s | 10 ~ 20 ns | 80 ~ 192 GB | 현재 디코딩 중인 활성 토큰, 모델 가중치 |
Tier 1 | Host DRAM / CXL | DDR5 Multi-Channel | 100 ~ 400 GB/s | 100 ~ 200 ns | 512 GB ~ 2TB | 웜(Warm) 세션 캐시, 1차 스왑 완충 버퍼 |
Tier 2 | Local NVMe SSD | PCIe Gen5 x4 Direct | 7 ~ 14 GB/s (드라이브당) | 10 ~ 50 µs | 15 ~ 120 TB | 콜드(Cold) 세션 캐시, 긴 접두사(Prefix) 저장 |
Tier 3 | NVMe-oF Fabric | RoCEv2 InfiniBand | 25 ~ 100 GB/s (NIC당) | 15 ~ 80 µs | 수백 TB ~ 페타바이트 | 클러스터 공유 접두사 캐시 풀, 무중단 노드 복구 |
3.4 최신 오프로딩 엔진 및 스케줄러
•
vLLM PagedAttention: 운영체제의 가상 메모리 페이징 기법을 차용하여 KV 캐시를 16토큰 또는 32토큰 단위의 물리 블록으로 관리합니다. 메모리 단편화를 제거하고 OffloadingConnector를 통해 GPU HBM과 호스트 메모리 간 비동기 블록 스왑을 지원합니다.
•
LMCache: vLLM 및 SGLang의 상위 캐시 계층으로 동작합니다. GDS 라이브러리(libugds.so)를 연동하여 CPU 개입 없이 로컬 NVMe SSD(L1 Fast Tier)와 GPU 메모리 간 직접 DMA 스왑을 수행하며, 분산 네트워크 스토리지(L2 Persistent Tier)로 캐시를 영속화합니다.
•
Mooncake: Kimi 서비스를 위해 개발된 아키텍처로, 사전 연산(Prefill) 클러스터와 토큰 생성(Decode) 클러스터를 물리적으로 분리했습니다. 대규모 분산 NVMe-oF 풀을 공유 캐시로 활용하여 장기 세션의 프롬프트 재연산을 완전히 제거했습니다.
3.5 스토리지 I/O 요구 규격 정량 계산
오프로딩 과정에서 GPU 연산 유닛이 데이터 전송을 기다리며 멈추는 현상(Stall)을 막으려면 스토리지 대역폭이 엄격한 기준을 충족해야 합니다.
\text{전송 시간} = \frac{\text{KV 캐시 용량 (GB)}}{\text{스토리지 실효 읽기 대역폭 (GB/s)}}
스토리지 구성 환경 | 실효 읽기 대역폭 | 32k 세션 (10.5 GB) 로드 시간 | 128k 세션 (41.9 GB) 로드 시간 | GPU 연산 중첩 가능 여부 |
단일 PCIe Gen4 NVMe (x4) | 약 6.0 GB/s | 1.75초 | 6.98초 | 불가 (GPU Stall 발생) |
단일 PCIe Gen5 NVMe (x4) | 약 12.0 GB/s | 0.88초 | 3.49초 | 중첩 가능 (제한적) |
4x PCIe Gen5 NVMe (RAID0) | 약 48.0 GB/s | 0.22초 (220 ms) | 0.87초 (870 ms) | 중첩 가능 (권장) |
400Gbps NVMe-oF (RoCEv2) | 약 45.0 GB/s | 0.23초 (233 ms) | 0.93초 (931 ms) | 중첩 가능 (권장) |
•
IOPS 및 큐 깊이: 16토큰 블록 기준 다수의 세션을 동시에 스왑할 때 최소 500,000 IOPS(권장 1,000,000 IOPS 이상)와 Queue Depth 64~128을 지원해야 NVMe 대역폭을 한계까지 활용할 수 있습니다.
•
테일 지연시간 예산: GPU의 1개 토큰 디코딩 스텝은 15~30ms 내외입니다. 스토리지에서 블록을 읽어오는 p99 지연시간이 5ms 이하로 유지되어야 연속 배치(Continuous Batching) 스케줄러의 파이프라인 버블을 예방할 수 있습니다.
4. 3대 주요 제조사 AI 스토리지 아키텍처 심층 비교: Dell vs Pure Storage vs NetApp
단일 노드의 고속 NVMe 스토리지를 넘어 수백 대의 GPU 서버를 연결하는 엔터프라이즈 환경에서는 스토리지 제조사의 아키텍처와 데이터 관리 능력이 인프라 전체의 안정성을 좌우합니다.
4.1 3대 제조사별 AI 스토리지 포트폴리오
1) Dell Technologies: PowerScale, PowerStore, PowerMax
•
PowerScale (OneFS 기반 Scale-Out NAS): 단일 네임스페이스 안에서 최대 252개 노드까지 선형 확장할 수 있는 대표적인 분산 파일 시스템입니다. 업계 최초로 이더넷(RoCEv2) 기반 NVIDIA DGX SuperPOD 인증을 획득했으며, NFS over RDMA와 GDS를 지원하여 멀티모달 학습 데이터 레이크하우스 구축에 널리 활용됩니다.
•
PowerStore: Active-Active ALUA 구조의 통합 All-Flash 스토리지로, 스토리지 내부에서 직접 가상 머신을 구동하는 AppsON 기능을 제공합니다.
•
PowerMax: 다이렉트 패브릭 기반의 하이엔드 스토리지로, 3,000만 이상의 IOPS와 엔터프라이즈 검증을 마친 SRDF 복제 기술을 통해 초고신뢰성 AI 트랜잭션 DB를 지원합니다.
2) Pure Storage: FlashBlade, DirectFlash, FlashArray
•
FlashBlade//S & FlashBlade//E: 연산 블레이드와 스토리지 블레이드를 분리 확장하는 파일/오브젝트(UFFO) 전용 스케일아웃 스토리지입니다. DGX SuperPOD 인증 및 AIRI 참조 아키텍처를 보유하고 있습니다.
•
DirectFlash 모듈 (DFM): 범용 SSD의 자체 플래시 변환 계층(FTL)을 제거하고, Purity 운영체제가 낸드 플래시 블록을 직접 소프트웨어로 중앙 제어합니다. SSD 내부의 비동기 가비지 컬렉션으로 인한 쓰기 증폭과 지연시간 스파이크(Tail Latency)를 사전에 차단하여 극도로 균일한 응답 속도를 유지합니다.
•
FlashArray//XL: ActiveCluster 기술을 통해 별도 제3사이트 비용 없이 RPO=0 동기 복제를 제공하는 초저지연 블록 스토리지입니다.
3) NetApp: ONTAP 기반 AFF, FlexGroup, StorageGRID
•
AFF A-Series (AFF A90, A1K): 전 구간 엔드투엔드 NVMe(NVMe/TCP, NVMe over RoCE)와 PCIe Gen5를 탑재한 초고성능 All-Flash 스토리지로 DGX SuperPOD 인증을 획득했습니다.
•
NetApp FlexGroup: 단일 네임스페이스 아래 다수의 볼륨에 걸쳐 수십억 개의 파일과 페타바이트급 데이터를 자동으로 분산 배치하여 AI 데이터 로딩 시 발생하는 메타데이터 병목을 해소합니다.
•
StorageGRID: 지리적으로 분산된 다중 사이트 환경을 지원하는 오브젝트(S3) 스토리지로 대규모 원시 데이터 아카이빙을 전담합니다.
4.2 3사 다차원 비교 매트릭스
비교 항목 | Dell Technologies | Pure Storage | NetApp |
제품군 (대표) | PowerScale F910 / F710 PowerMax 8500 | FlashBlade//S500 FlashBlade//E | AFF A90 / AFF A1K FlexGroup |
확장 아키텍처 | Scale-Out (OneFS 최대 252노드) | Scale-Out (연산/스토리지 블레이드 분리형) | Scale-Out (최대 24 노드) |
플래시 제어 방식 | 표준 NVMe SSD 및 전용 인클로저 | DirectFlash Module (DFM, FTL 제거) | 표준 NVMe SSD 및 최적화 쉘프 |
지원 프로토콜 | NFSv3, NFSv4, NFS over RDMA, S3, NVMe-oF | NFSv3, NFSv4.1, NFS over RDMA, S3, NVMe-oF | NFSv3, NFSv4, NFS over RDMA, NVMe-oF, S3 |
NVIDIA GDS 지원 | 지원 (cuFile API, OneFS 전용 드라이버) | 지원 (NFS over RDMA / Purity GDS 연동) | 지원 (NFS over RDMA / ONTAP GDS 검증) |
DGX SuperPOD 인증 | 획득 (PowerScale F710 등) | 획득 (FlashBlade//S500, AIRI) | 획득 (AFF A90, AFX, EF600) |
압축 효율 (AI 데이터) | 1.0:1 ~ 1.2:1 (인라인/후처리 선택) | 1.0:1 ~ 1.1:1 (하드웨어 가속 인라인 처리) | 1.0:1 ~ 1.2:1 (인라인 제로 탐지 및 압축) |
고 가용성 | OneFS N+M 보호 SRDF 동기·비동기 | ActiveCluster (Symmetric Active-Active) | MetroCluster SyncMirror SnapMirror |
차별화 | 방대한 단일 클러스터 규모와 엔터프라이즈 신뢰성 | DFM 기반 낮은 전력·안정적 지연시간, 단순성 | ONTAP 기반의 정교한 데이터 거버넌스 및 클라우드 연계 |
4.3 AI 데이터셋의 데이터 절감(중복 제거/압축) 메커니즘 한계 분석
스토리지 제조사들이 기존 VDI나 가상화 환경에서 홍보하는 3:1 ~ 5:1의 데이터 중복 제거(Deduplication) 및 압축(Compression) 비율은 AI 데이터셋 앞에서는 작동하지 않습니다.
[ AI 데이터셋의 압축 및 중복 제거 한계 ]
가중치 텐서 (FP16/BF16/FP8) : [0.1284719, -0.982314, 0.003412 ...] ──> 고엔트로피 난수 비트열
중복 블록 탐지 시도 : 해시 일치 확률 0% 수렴 ──> 실제 절감율 1.0:1 ~ 1.1:1 (압축 불가)1.
부동소수점(FP16/BF16/FP8) 텐서의 고엔트로피 특성: 모델 가중치와 임베딩 벡터 데이터는 소수점 아래 미세한 차이를 가지는 무작위 비트 패턴을 이룹니다. 가수부(Mantissa) 비트열이 난수에 가깝게 분산되어 있어 고정/가변 블록 중복 제거 엔진이 동일한 해시 블록을 찾을 확률이 0에 수렴합니다.
2.
사전 압축 포맷의 비정형 데이터: Parquet, WebDataset, JPEG, H.264 등 학습 데이터는 이미 애플리케이션 레벨에서 최적화된 압축 형식입니다.
3.
실무 권장안: AI 전용 볼륨에 인라인 압축이나 중복 제거를 적용하면 스토리지 컨트롤러의 CPU 사이클만 낭비되어 전체 I/O 대역폭이 저하됩니다. AI 전용 스토리지 영역은 데이터 절감 기능을 비활성화하고, 용량 산정 시 물리 용량을 1:1 기준으로 보수적으로 계산해야 용량 부족 사태를 예방할 수 있습니다.
5. 엔터프라이즈 고가용성(HA)과 복원력: 무중단 AI 인프라의 조건
5.1 Active-Active vs Active-Passive 다중화 아키텍처
스토리지 컨트롤러를 이중으로 구성할 때 채택하는 다중화 방식은 장애 발생 시 AI 서비스가 지속되는지 여부를 가르는 핵심 요인입니다.
•
Active-Passive ALUA 방식: 특정 볼륨의 I/O 소유권이 주 컨트롤러(Active)에만 할당되고 보조 컨트롤러는 대기 상태로 머뭅니다. 주 컨트롤러 장애 시 볼륨 소유권을 넘겨받는 과정에서 5초에서 30초의 I/O 정체(I/O Freeze)가 발생합니다. 이 짧은 정체 시간 동안 LLM 추론 클라이언트에서 HTTP 504 게이트웨이 타임아웃이 발생하거나 분산 학습 노드의 하트비트가 끊겨 전체 작업이 중단될 수 있습니다.
•
대칭형 Active-Active (Symmetric Active-Active) 방식: 모든 컨트롤러가 동일한 볼륨에 대해 동시에 읽기/쓰기 I/O를 처리합니다. 한 컨트롤러에 장애가 발생하더라도 볼륨 전환 절차 없이 잔여 컨트롤러가 서브밀리초 수준에서 즉시 I/O를 지속 처리하므로 상위 GPU 애플리케이션의 세션이 유지됩니다.
5.2 동기 복제(Sync) vs 비동기 복제(Async) 메커니즘과 물리적 지연시간 한계
•
동기 복제 (Synchronous Replication, RPO=0): 주 스토리지와 원격지 스토리지에 모두 데이터가 기록된 후 호스트에 쓰기 완료(ACK)를 반환합니다. 데이터 유실은 없지만 물리적 광케이블 거리의 제약을 받습니다.
◦
유리 광섬유 내부에서 빛의 속도는 초당 약 200,000km입니다.
◦
신호의 왕복 시간(RTT)은 1km당 약 10µs가 소요됩니다.
◦
50km 떨어진 데이터센터 간 복제 시 순수 광케이블 왕복 지연시간만 0.5ms가 추가되며, 스위치 홉과 I/O 처리 시간을 합산하면 쓰기 지연시간이 1~2ms 이상으로 튑니다.
◦
따라서 동기 복제는 지연시간 민감도를 고려하여 100km 이내의 메트로(Metro) 데이터센터 환경으로 적용이 제한됩니다.
•
비동기 복제 (Asynchronous Replication, RPO>0): 로컬 캐시/NVRAM에 기록되는 즉시 호스트에 응답하고 원격지 복제는 백그라운드 저널링으로 처리합니다. 수천 km 떨어진 대륙 간 원거리 DR을 지원합니다.
5.3 스플릿 브레인(Split-Brain) 방지 아키텍처
액티브-액티브 클러스터에서 두 사이트 간 하트비트 통신 링크가 끊겼을 때 양쪽 스토리지 노드가 모두 단독 쓰기 작업을 수행하면 데이터가 양갈래로 쪼개져 복구 불가능한 오염이 발생합니다.
이를 방지하기 위해 두 사이트와 지리적으로 격리된 제3의 위치(퍼블릭 클라우드 인스턴스 등)에 클라우드 쿼럼 위트니스(Cloud Quorum Witness / Mediator)를 배치합니다.
통신 장애 발생 시 위트니스 서버에 선착순으로 락을 요청하여 먼저 승인을 얻은 사이트만 액티브 상태를 유지하고, 실패한 사이트는 자체적으로 볼륨 접근을 동결(Fencing)함으로써 데이터 정합성을 보호합니다.
5.4 AI 워크로드별 실무 RTO / RPO 설계 기준
AI 인프라에서는 워크로드의 특성에 따라 요구되는 가용성 목표가 달라집니다.
구분 (워크로드) | RPO (목표 복구 시점) | RTO (목표 복구 시간) | 스토리지 복제 및 HA 설계 전략 |
대규모 분산 학습 (Training) | |||
'BLOGGER' की सदस्यता लें
साइट को सब्सक्राइब करने पर आप नए पोस्ट आदि के नवीनतम अपडेट सबसे पहले नोटिफिकेशन और ईमेल से प्राप्त कर सकते हैं.
Slashpage में शामिल हों और 'BLOGGER' को सब्सक्राइब करें!
Slashpage में शामिल हों और 'BLOGGER' को सब्सक्राइब करें!
सदस्यता लें
