26O12c
Multi-Cluster GPU 활용 아키텍처 및 구축 계획
현재 환경과 첨부된 분석을 종합하면, 기존 Compute·Storage 클러스터는 유지하고 GPU 전용 클러스터를 추가하되, Compute에서 GPU 자원을 원격으로 사용하는 구조를 권장합니다.
핵심은 GPU를 단순히 여러 클러스터에 공유하는 것이 아니라, 데이터 처리·학습·추론·스토리지의 역할을 분리하고 공통 인터페이스로 연결하는 것입니다.
1. 권장 아키텍처
사용자 / 애플리케이션 / Jupyter / 외부 API
인증: Keycloak · API: 내부 DNS/VIP
API 호출 · 작업 제출
Compute Cluster
기존 범용 CPU 클러스터
Spark / ETL / 전처리
Airflow / 워크플로
Trino / StarRocks
Jupyter / API 서비스
Cilium Native + BGP/ECMP + ClusterMesh
GPU Cluster
HPE GPU 노드 · NVIDIA GPU Operator
Inference Pool
vLLM · API Gateway
상주 추론 · 모델 캐시
Training Pool
PyTorch · Ray · Job
Kueue · NCCL / IB
초기에는 하나의 클러스터, 별도 노드풀/큐로 분리
S3 / Iceberg REST · Private Ethernet
Storage Cluster
MinIO AIStor
데이터셋 · 모델 · 체크포인트
Apache Polaris
Iceberg 카탈로그 · 메타데이터
위 구조는 첨부 분석을 바탕으로 정리한 권장 논리 아키텍처이며, 실제 네트워크 구성과 노드 수는 별도 확정이 필요합니다.
2. 클러스터별 역할 정의
| 영역 | 주요 역할 | 핵심 구성 |
|---|---|---|
| Compute | 일반 애플리케이션, API, Spark 전처리, 배치 및 분석 | Spark, Airflow, Trino, StarRocks |
| GPU Inference | LLM, RAG, 실시간 및 배치 추론 | vLLM, Gateway, LiteLLM(추후) |
| GPU Training | 모델 학습, 파인튜닝, 분산 학습 | PyTorch, Ray, Kueue |
| Storage | 원본 데이터, Iceberg, 모델 가중치 및 체크포인트 | AIStor, Polaris |
Compute를 처음부터 물리적으로 Batch/Interactive 클러스터로 나눌 필요는 없습니다. 현재의 혼합 워크로드를 유지하면서 노드풀, 우선순위, 리소스 쿼터로 격리하고, 병목이 발생하면 분리하는 방식이 적절합니다.
GPU 역시 초기부터 학습과 추론을 별도 클러스터로 만들기보다 하나의 GPU 클러스터에 학습·추론 노드풀을 분리하는 구성이 운영 부담을 줄입니다.
3. GPU 사용 방식은 세 가지로 표준화
A. 온라인 추론 — API 호출
Compute → 내부 Gateway → vLLM
사용자와 애플리케이션은 고정 URL만 사용합니다. 처음에는 vLLM과 Gateway로 시작하고, 이후 LiteLLM 및 Keycloak 연동을 확장합니다.
B. 학습 및 대규모 배치 — Job 제출
Airflow → GPU Kubernetes API → Kueue → Training Job
Spark가 Compute에서 전처리하고, GPU Job은 AIStor의 데이터를 직접 읽어 학습합니다. 초기에는 Airflow 직접 제출 방식을 권장합니다.
C. 인터랙티브 분석 — 원격 GPU 세션
Jupyter → Ray 또는 GPU 전용 Notebook
CPU 중심 데이터 탐색은 Compute에 유지하고, GPU가 필요한 실험만 GPU 클러스터에서 실행합니다.
Spark 자체도 GPU 클러스터에서 Spark RAPIDS로 실행할 수 있지만, 모든 Spark 워크로드를 GPU로 옮기는 것은 권장하지 않습니다. GPU 가속 효과가 검증된 작업만 이전합니다.
4. GPU 스케줄링 및 운영 정책
| 구분 | 초기 도입 | 확장 시 |
|---|---|---|
| 추론 | 전용 노드풀, 상주 vLLM | 복수 replica, 모델 인지 라우팅 |
| 학습 | Kueue LocalQueue | MultiKueue |
| GPU 배분 | 팀별 ResourceFlavor/Quota | 팀 간 유휴 용량 공유 |
| 배포 | Argo CD | GitOps 기반 복수 클러스터 |
| 오케스트레이션 | Airflow 직접 제출 | 다중 GPU 클러스터 선택 |
중요한 점은 Kueue가 상주 추론 서비스 자체의 GPU 사용량을 자동으로 통합 관리한다고 가정하면 안 된다는 것입니다. 초기에는 추론 노드풀을 예약하고 학습 Job을 Kueue로 관리하는 편이 명확합니다.
또한 추론과 학습이 동일 GPU를 시간대별로 공유해야 한다면, 별도 프로파일을 준비합니다.
- 주간: 추론 서비스 우선, 학습은 잔여 GPU에서 실행
- 야간: 일부 추론 replica 축소 후 학습 확대
- 전환: 처음에는 수동, 안정화 후 CronJob 또는 Argo CD 기반 자동화
GPU 수요는 기존 Stage7의 모델별 GPU/TP/DP/EP/HBM/KV/context/concurrency 측정 결과를 바탕으로 확정합니다.
5. 네트워크 및 AIStor 연동
첨부 분석에서 가장 중요한 수정 사항은 학습용 InfiniBand를 무조건 스토리지에도 사용하지 않는 것입니다.
| 통신 | 기본 경로 | 권장 정책 |
|---|---|---|
| Compute ↔ GPU API | Private Ethernet | Cilium, BGP/ECMP |
| GPU ↔ Polaris | Private Ethernet | REST, 접근 정책 |
| GPU ↔ AIStor | Private Ethernet | 일반 S3/TCP |
| GPU ↔ GPU 분산 학습 | InfiniBand | NCCL 우선 |
| GPU ↔ AIStor 고속 I/O | IB 선택 적용 | RDMA 지원 및 경합 검증 후 |
특히 학습 노드의 IB NIC가 NCCL과 스토리지 I/O를 공유하면 학습 처리량이 떨어질 수 있습니다.
따라서 기본 원칙은 다음과 같습니다.
학습 노드: IB는 NCCL 중심으로 사용하고, AIStor 접근은 Ethernet과 로컬 NVMe 캐시를 활용합니다.
추론 노드: 모델 가중치를 AIStor에서 로컬 NVMe로 미리 내려받아 사용합니다. IB 기반 S3 over RDMA는 별도 PoC 후 도입합니다.
S3 over RDMA는 일반 S3 요청에 태그만 추가하면 자동 적용되는 방식으로 가정해서는 안 됩니다. 지원되는 서버 구성, 클라이언트 SDK 및 데이터 경로가 필요합니다.
6. 로컬 NVMe 사용 계획
GPU 노드의 로컬 NVMe는 단순 모델 캐시 이상의 용도로 계획하는 것이 좋습니다.
| 용도 | 추론 | 학습 |
|---|---|---|
| 모델 가중치 캐시 | 필수 권장 | 필요 시 |
| 데이터셋 스테이징 | 제한적 | 중요 |
| 체크포인트 임시 저장 | 보통 불필요 | 중요 |
| 전처리/중간 산출물 | 배치 추론 시 | 중요 |
| 로그/임시 파일 | 필요 | 필요 |
영구 보관은 AIStor가 담당하며, 로컬 NVMe는 재생성 가능한 캐시와 임시 작업 공간으로 취급합니다. 체크포인트를 NVMe에 먼저 저장하더라도 AIStor 업로드가 완료되기 전까지는 장애 시 손실 위험이 있습니다.
7. 단계별 구축 로드맵
01
GPU 클러스터 기반 구성
NVIDIA GPU/Network Operator, Cilium Native+BGP, GPU 노드풀, AIStor 접근, NCCL 및 스토리지 성능 검증.
완료 기준: GPU 정상 인식, 멀티노드 NCCL, AIStor 읽기/쓰기 및 네트워크 격리 검증
02
추론 서비스 구축
vLLM, Gateway, 내부 DNS/VIP, 초기 API Key 인증, 모델별 Stage7 프로파일 적용.
완료 기준: Compute 애플리케이션에서 고정 URL로 인증된 추론 호출
03
학습 파이프라인 연결
Airflow → GPU Job, Kueue 큐/쿼터, Spark 전처리, Iceberg 스냅샷, AIStor 모델 저장, Argo CD 배포.
완료 기준: 전처리 → 학습 → 모델 저장 → 추론 배포까지 End-to-End 성공
04
운영 자동화 및 최적화
주간/야간 GPU 프로파일, 모니터링, Keycloak/LiteLLM, NVMe 캐시, 필요 시 RDMA PoC.
완료 기준: 사용자별 접근 제어, 성능 지표, 프로파일 전환 및 장애 복구 검증
05
GPU 클러스터 확장
학습 전용 클러스터 추가, MultiKueue, 토폴로지 인식 스케줄링, 필요 시 사이트 간 데이터 복제.
완료 기준: 기존 사용자 API와 학습 제출 인터페이스를 유지하면서 GPU 자원 확장
8. 지금 확정해야 할 설계 항목
설계 확정 체크리스트
0/8 완료
HPE GPU 노드의 학습/추론 노드풀 배분
Stage7 기반 모델별 GPU 수량 및 병렬화 설정
Compute → GPU 추론 Gateway의 고정 DNS/VIP
Airflow의 GPU 클러스터 접근 및 Kueue 큐 정책
GPU ↔ AIStor Ethernet 성능 기준선
IB NCCL 전용 여부 및 RDMA PoC 범위
AIStor 버킷, Polaris 권한, 모델 캐시 정책
주간/야간 프로파일 및 GPU 전환 정책
체크리스트 복사
최종 권고
현재 환경에서는 다음 구성이 가장 합리적인 출발점입니다.
Compute + Storage + 단일 GPU 클러스터(학습/추론 노드풀 분리)
- 추론: vLLM + 고정 Gateway URL
- 학습: Airflow + Kueue + GPU Job
- 데이터: AIStor + Polaris, 데이터 복사 최소화
- 네트워크: Cilium/BGP/ECMP 기반 Ethernet, 학습 NCCL은 IB
- 배포: Argo CD, 모델 아티팩트는 AIStor
- 확장: 필요해지면 MultiKueue 및 학습 전용 GPU 클러스터 추가
특히 초기 단계에서는 MultiKueue, Spark RAPIDS, S3 over RDMA, 복잡한 LLM 라우팅을 모두 동시에 도입하지 않는 것이 중요합니다. 먼저 기본적인 추론 API와 원격 학습 파이프라인을 완성한 뒤, 실측 병목에 따라 기능을 추가하는 것이 좋습니다.
이렇게 준비하면 기존 Compute/Storage 운영 구조를 크게 바꾸지 않으면서 GPU 학습·추론을 통합하고, 향후 GPU 노드나 클러스터가 늘어나더라도 사용자 인터페이스를 안정적으로 유지할 수 있습니다.
