현재 구축 예정인 B300 GPU 96개(12대 × 8 GPU), MinIO AIStor 55대, NDR400 InfiniBand Fabric을 기준으로 보면, 가장 중요한 것은 단순히 GPU와 스토리지를 400Gbps로 연결하는 것이 아닙니다.

AIStor → GPU 메모리까지 데이터를 전달하는 경로를 최적화하고, 학습·추론·체크포인트 각각의 I/O 특성에 맞게 데이터 배치를 설계하는 것이 핵심입니다.

제안하는 기본 방향은 다음과 같습니다.

권장 데이터 경로

MinIO AIStor — 55 nodes

S3 Object Storage · Dataset · Model · Checkpoints

NDR400 InfiniBand · RDMA 지원 경로 검증

GPU Node — 12 × Dell XE9780

2×400G active ConnectX-7 / node

Local NVMe cache / staging · CPU RAM

8× NVIDIA B300 / node

GPU HBM · Training · Inference · NCCL

RDMA를 사용한다고 해서 모든 S3 요청이 자동으로 GPU HBM에 직접 전달되는 것은 아닙니다. 실제 전송 경로는 AIStor 버전, 클라이언트, GPUDirect 지원 및 애플리케이션 구현에 따라 달라집니다.

우선순위를 정하면 ① AIStor RDMA 지원 방식 확인, ② NDR 공유 fabric의 트래픽 격리, ③ GPU local NVMe 활용, ④ 학습 데이터 형식 및 checkpoint 최적화, ⑤ GPU–Storage 통합 벤치마크 순서로 접근하는 것이 좋습니다.

1. 최신 AIStor에서 가장 중요한 변화: S3 over RDMA

2026년 10월 기준 MinIO 공식 문서에서 확인되는 중요한 기능은 S3 over RDMA와 AIStor 노드 간 RDMA입니다. 두 기능은 서로 독립적으로 구성할 수 있습니다.

image

MinIO AIStor Documentation

+1

기능	데이터 경로	활용
S3 over TCP	GPU Node ↔ AIStor Ethernet	일반 S3 API, 기존 애플리케이션
S3 over RDMA	GPU Node CX-7 ↔ AIStor CX-7	GPU 학습 데이터 로딩, 모델 로딩
Inter-node RDMA	AIStor ↔ AIStor CX-7	Erasure coding shard 전송
GPUDirect RDMA	NIC ↔ GPU 메모리	CPU 메모리 복사 감소

특히 S3 over RDMA는 현재 GetObject, PutObject, UploadPart에 RDMA 데이터 경로가 제공됩니다. 그 외의 S3 작업은 HTTP를 사용합니다. 따라서 S3 API 전체가 InfiniBand로 대체되는 방식이 아닙니다.

image

MinIO AIStor Documentation

+1

또한 일반적인 boto3/S3 클라이언트를 그대로 사용한다고 GPU 메모리 직접 전송이 활성화되지는 않습니다. MinIO 문서에는 RDMA 지원 minio-cpp, libminiocpp, NVIDIA cuObjClient 기반의 경로가 명시되어 있습니다.

추천: 기존 S3 endpoint는 유지하되, 고성능 학습용 DataLoader 또는 데이터 전송 계층에 RDMA 지원 클라이언트를 선택적으로 도입하세요. PyTorch 애플리케이션에서 실제 GPU 메모리까지 zero-copy에 가까운 경로가 만들어지는지는 통합 테스트로 확인해야 합니다.

2. 현재 NDR400 설계에서 가장 중요한 병목

현재 GPU 서버의 2×400G NDR은 서버당 최대 800Gbps, 이론적으로 약 100GB/s의 단방향 링크 대역폭입니다.

GPU 1대

100 GB/s

2×400G, 이론적 상한

GPU 12대

1.2 TB/s

24×400G, 이론적 상한

이 값은 실제 S3 처리량이 아닙니다. 프로토콜 오버헤드, Erasure Coding, RDMA 채널, GPU↔NIC 토폴로지 등에 따라 실효 성능은 낮아집니다.

중요한 것은 현재 AIStor의 110×400G 총 44Tbps에 비해 GPU 측은 9.6Tbps라는 점입니다.

GPU가 AIStor 데이터를 읽는 워크로드만 놓고 보면 GPU 측 연결 대역폭이 먼저 상한을 형성합니다. 하지만 같은 NDR Fabric에서 NCCL과 AIStor inter-node RDMA도 동작하므로 다음 상황을 구분해야 합니다.

동시 워크로드	주요 위험
GPU → AIStor 대량 읽기	GPU CX-7 대역폭 및 GPUDirect 경로
GPU ↔ GPU NCCL	Collective 통신 지연 및 혼잡
AIStor ↔ AIStor Erasure Coding	Storage 내부 네트워크 사용량
세 가지 동시 실행	공유 Leaf/Spine 구간 혼잡

제안: NDR Fabric을 물리적으로 바로 분리하기보다는, 먼저 InfiniBand Service Level/VL, Adaptive Routing, P_Key, NCCL 및 AIStor RDMA 설정을 검토하고 실제 동시 부하 테스트를 진행하는 것이 좋습니다. P_Key는 접근 분리 수단이지 대역폭 보장 수단은 아닙니다.

3. AIStor RDMA 구축 시 꼭 확인할 버전과 설정

MinIO 공식 Kubernetes 문서에는 다음 조건이 명시되어 있습니다.

image

MinIO AIStor Documentation

+1

항목	확인 사항
AIStor Operator	Helm chart 6.0.0 이상
AIStor Server	일반 빌드가 아닌 RDMA 빌드
Kubernetes	RDMA 장치 접근 및 host networking
Multi-NIC	rdma-ip, rdma-ip2 노드 레이블
Inter-node RDMA	objectStore.rdma.internode
GPU Direct	GPU↔NIC peer-to-peer DMA 검증
RDMA 메모리	pinned memory 및 memlock

특히 AIStor 노드당 CX-7이 2개이므로, 두 장을 단순히 장착하는 것으로 끝내지 말고 Multi-NIC RDMA 경로가 실제 활성화되는지 확인해야 합니다.

최신 문서에는 secondary fabric address를 설정하는 방법이 있지만, 이것이 모든 S3 요청에 대해 두 NIC를 자동으로 800G까지 합산한다는 의미는 아닙니다. Inter-node와 client-to-server 경로를 각각 측정해야 합니다.

또한 기본 inter-node RDMA 버퍼 풀이 노드당 16GiB의 pinned memory를 사용할 수 있습니다. AIStor 서버 RAM 768GB에서는 용량 자체가 큰 문제는 아니지만, 55대 전체의 메모리 예약과 NUMA locality를 고려해야 합니다.

주의할 점은 RDMA 경로의 장애 처리도 다르다는 것입니다. MinIO 문서상 inter-node RDMA는 TCP fallback이 가능하지만, S3 over RDMA 요청은 클라이언트가 오류를 확인하고 HTTP로 재시도해야 하는 경우가 있습니다. 따라서 RDMA 장애 시에도 학습이 중단되지 않는 클라이언트 재시도 전략이 필요합니다.

4. B300과 ConnectX-7의 PCIe 토폴로지

이 부분은 반드시 Dell XE9780의 실제 하드웨어 구성으로 검증해야 합니다.

B300 8개가 NVLink로 연결되어 있더라도, 각 GPU에서 각 ConnectX-7까지의 PCIe 경로가 동일한 것은 아닙니다.

특히 다음을 확인해야 합니다.

• GPU↔CX-7의 PCIe root complex 및 NUMA locality
• GPUDirect RDMA 지원 여부와 ACS redirect 설정
• ConnectX-7 펌웨어, NVIDIA 드라이버, OFED/rdma-core 호환성
• GPU 메모리 등록, pinned memory 및 IOMMU 관련 제약
• 두 개의 활성 CX-7이 실제로 데이터 전송을 분산 처리하는지

MinIO 문서에서도 ACS redirect가 GPU↔NIC peer-to-peer DMA를 방해할 수 있다고 명시합니다.

image

MinIO AIStor Documentation

+1

구축 시 최소한 다음 결과를 확보하세요.

nvidia-smi topo -m
nvidia-smi -q
ibv_devinfo -v
ibstat
lspci -tv

특히 CX-7 4장 중 2장만 연결하는 설계가 B300 8개에 적합한지는 Dell/NVIDIA 측의 공식 topology 검증과 NCCL 벤치마크로 확정하는 것이 좋습니다.

또한 NVIDIA GPUDirect Storage(GDS)의 cuFile 경로와 MinIO의 S3 over RDMA는 동일한 API가 아닙니다. S3 over RDMA를 활성화했다고 기존 cuFile 애플리케이션이 자동으로 AIStor에 직접 연결되는 것은 아닙니다.

image

MinIO AIStor Documentation

+1

5. AIStor의 NVMe 구성과 Erasure Coding

AIStor 55대에는 각각 30.72TB NVMe 24개가 있습니다.

항목	구성
AIStor 노드	55
NVMe/node	24
전체 NVMe	1,320
Raw capacity	약 40.55PB
NDR/node	2×400G
RAM/node	768GB

MinIO는 고성능 환경에서 NVMe의 직접 연결, JBOD, XFS 및 Kubernetes 환경의 로컬 디스크 프로비저닝을 권장합니다.

image

MinIO AIStor Documentation

+1

여기서 중요한 것은 55대 전체를 하나의 거대한 저장소로 본다고 해서 모든 오브젝트 요청이 55대 전체의 대역폭을 균등하게 활용하는 것은 아니라는 점입니다.

Erasure Set의 크기, 데이터/패리티 shard 구성, 오브젝트 크기, 읽기/쓰기 동시성이 실제 처리량에 영향을 줍니다.

특히 체크포인트는 대량 쓰기이므로, GPU에서 들어온 데이터뿐 아니라 AIStor 내부 shard 전송도 NDR 대역폭을 소비합니다.

설계 단계에서 Erasure Set 배치와 failure domain을 먼저 확정하고, 그 구성으로 벤치마크해야 합니다.

6. 데이터셋·모델·체크포인트를 서로 다르게 처리

AIStor의 최신 AI workload 기능에는 S3 over RDMA 외에도 AIStor Tables(Apache Iceberg REST catalog), Bucket Inventory, Versioning/Object Lock, Lifecycle Management가 포함됩니다.

image

MinIO AIStor Documentation

+1

각 워크로드에는 다음 전략을 권합니다.

데이터	권장 저장·접근 방식
학습 원본 데이터	AIStor S3, 버전 관리
학습용 샤드 데이터	AIStor → GPU NVMe staging 또는 S3 over RDMA
반복 사용하는 모델 가중치	GPU 로컬 NVMe model-cache
대규모 Checkpoint	AIStor S3 Multipart/병렬 업로드
임시 Checkpoint	GPU local NVMe 후 비동기 업로드
학습 메타데이터/Feature Tables	AIStor Tables/Iceberg 검토
사용자 작업공간/POSIX	PowerScale

특히 GPU 로컬 NVMe는 단순 모델 캐시 외에도 dataset shard cache, checkpoint staging, 전처리 중간 결과, 임시 파일 용도로 사용할 가치가 큽니다.

다만 checkpoint를 로컬 NVMe에만 두면 GPU 노드 장애 시 유실될 수 있으므로, AIStor 업로드 완료 시점과 복구 가능 시점을 명확히 구분해야 합니다.

7. Kubernetes 3개 클러스터 구성에서의 주의점

현재 계획처럼 GPU Cluster와 AIStor Cluster를 분리하는 것은 가능합니다.

다만 최신 AIStor RDMA Operator 문서에서는 Object Store Pod가 hostNetwork, RDMA 장치 접근, privileged 권한 등을 필요로 하는 구성을 설명합니다.

image

MinIO AIStor Documentation

+1

따라서 다음처럼 역할을 분리하겠습니다.

GPU Kubernetes Cluster

Cilium Native Routing + BGP/ECMP

GPU Operator · RDMA device access · NCCL · AI workloads

S3 API / Ethernet + RDMA / InfiniBand

AIStor Kubernetes Cluster

AIStor Operator 6.x · RDMA Server · Local NVMe/XFS

Inter-node RDMA · S3 over RDMA endpoints

Cilium은 Kubernetes 기본 IP 네트워크를 담당하고, NDR은 별도의 RDMA 데이터 경로로 운영하는 구조입니다. ClusterMesh가 없어도 GPU↔AIStor 데이터 통신을 구성할 수 있습니다.

한 가지 더 중요합니다. RDMA 데이터 경로는 일반적인 HTTPS S3 경로와 동일한 암호화 특성을 갖지 않습니다. MinIO 문서에서도 RDMA 전송 자체는 암호화되지 않는다고 설명하므로, 별도 IB partition과 접근 제어, 네트워크 격리 및 저장 데이터 암호화 정책을 설계해야 합니다.

image

MinIO AIStor Documentation

+1

8. 구축 전 반드시 진행할 성능 검증

제가 권장하는 PoC는 다음과 같습니다.

단계	테스트	확인할 사항
1	CX-7 ib_write_bw / ib_read_bw	단일 링크 400G 실효 성능
2	AIStor S3 over TCP	기존 방식 baseline
3	AIStor S3 over RDMA	RDMA 전송 성능 및 CPU 사용량
4	GPU HBM 직접 전송	GPUDirect 동작 검증
5	AIStor Inter-node RDMA	Erasure shard 전송 개선
6	NCCL multi-node	GPU 분산학습 성능
7	NCCL + AIStor 동시 부하	NDR 혼잡과 tail latency
8	Checkpoint 저장/복구	전체 학습 중단·복구 시간
9	Leaf/Spine 장애	성능 저하, 경로 복구, 재시도

단순히 최대 GB/s만 측정하지 말고 GPU utilization, data-loader stall time, time-to-first-batch, checkpoint duration, NCCL latency, CPU 사용률, RDMA retransmission/error counter를 함께 수집해야 합니다.

특히 GPU가 데이터를 기다리는 시간이 줄어드는지를 최종 성공 기준으로 삼는 것이 좋습니다.

9. 현재 구성에 대한 권장 우선순위

P0 — RDMA 지원 버전 및 실제 데이터 경로 검증

AIStor RDMA build, Operator 6.x, NVIDIA cuObjClient, GPU↔CX-7 GPUDirect 호환성을 먼저 검증합니다.

P0 — 공유 NDR Fabric 성능 검증

GPU NCCL과 AIStor RDMA를 동시에 실행하여 현재 1.20:1 Leaf-Spine oversubscription의 영향을 측정합니다.

P1 — GPU Local NVMe 캐시 설계

모델 캐시, dataset shard, checkpoint staging을 분리하고 캐시 재사용률을 측정합니다.

P1 — 장애·복구 및 보안

RDMA 실패 시 TCP fallback, AIStor 데이터 보호, 체크포인트 복구와 접근 제어를 검증합니다.

최종 제안

현재 하드웨어는 AIStor S3 over RDMA와 B300 기반 고성능 학습 환경을 구축하기에 적합한 출발점입니다. 특히 최신 MinIO AIStor가 InfiniBand NDR과 GPU 메모리 직접 전송을 공식적으로 지원한다는 점은 중요한 장점입니다.

하지만 96개 B300 GPU에 24개의 활성 CX-7 포트만 제공하는 구성이 충분한지는 아직 검증되지 않았습니다. 그리고 GPU NCCL과 AIStor의 RDMA 트래픽이 동일한 6대의 IB 스위치를 공유한다는 점도 중요합니다.

따라서 제 권장안은 AIStor RDMA를 도입하되 처음부터 모든 학습 작업에 강제하지 않고, TCP baseline → S3 over RDMA → GPUDirect → NCCL 동시 부하 순서로 성능을 검증한 뒤 활성화 범위를 확대하는 것입니다.

참고한 최신 공식 자료는 MinIO AI Workloads, S3 over RDMA 개발자 문서, Kubernetes RDMA 설정입니다.