왜 자원 프로파일링이 필요한가
GPU 클러스터를 운영하다 보면 동일한 “GPU Job”이라도 학습(Training)과 추론(Inference) 워크로드의 특성이 크게 다릅니다.
- Training Job은 장시간 실행, 대규모 GPU 및 CPU 동시 활용, 빈번한 AllReduce 통신이 특징입니다.
- Inference Job은 짧은 응답 시간, 소규모 GPU 사용, 배치 처리보다는 대화형 성격이 강합니다.
이 차이를 무시하고 동일한 스케줄링 정책을 적용하면 학습 Job은 추론 요청에 밀려 지연되고, 반대로 추론 Job은 대규모 학습에 막혀 SLA를 만족하지 못합니다. 따라서 운영자는 **Job 자원 프로파일링(Resource Profiling)**을 기반으로 스케줄링 정책을 차별화해야 합니다.
Training과 Inference의 자원 특성 비교
| 구분 | Training | Inference |
| GPU 활용 | 다수 GPU 병렬 처리 (8~1000+) | 소수 GPU, 단일 GPU도 빈번 |
| CPU 사용량 | 데이터 로딩/전처리로 CPU 사용률 높음 | 상대적으로 낮음 |
| 메모리 | GPU HBM/VRAM 대규모 점유, CPU 메모리도 중요 | GPU 메모리 사용량은 작지만 응답 지연에 민감 |
| 통신 패턴 | 집단 통신(Collective Communication, AllReduce) | 단일 요청 단위, 낮은 통신량 |
| 실행 시간 | 수시간~수주 | ms~분 단위 |
| SLA 관점 | Throughput(전체 처리량) 중요 | Latency(응답 시간) 중요 |
Slurm에서의 자원 프로파일링 기반 Scheduling
Slurm은 기본적으로 Job 제출 시 다양한 파라미터를 통해 자원 요구를 명시할 수 있습니다. 운영자는 Job 성격을 기준으로 QoS, Partition, Constraint 등을 구분해 정책을 달리 적용할 수 있습니다.
# Training 전용 Partition
sacctmgr add qos training priority=100 GrpTRES=gres/gpu=512 MaxWall=48:00:00
# Inference 전용 Partition
sacctmgr add qos inference priority=200 GrpTRES=gres/gpu=64 MaxWall=02:00:00이와 같이 Partition과 QoS를 구분하면, Training Job은 장시간 대규모 자원을, Inference Job은 짧은 응답과 우선순위를 보장할 수 있습니다.
Kubernetes/Volcano에서의 Scheduling
쿠버네티스 환경에서는 Pod Label, Node Selector, PriorityClass 등을 활용하여 Training과 Inference를 분리합니다. Volcano 스케줄러와 연계하면 Job 성격에 맞는 Placement가 가능합니다.
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: inference-priority
value: 1000
globalDefault: false
description: "Priority for inference jobs"이렇게 PriorityClass를 정의하면 Inference Job은 높은 우선순위를 가져 즉시 처리되도록 보장할 수 있습니다. 반면 Training Job은 더 낮은 Priority로 배치되어 장기 실행 중심으로 운영됩니다.
실제 적용 사례
- 대학 AI 연구실: 학생들의 Inference 실험 요청이 학습 Job에 밀리지 않도록 Inference 전용 Partition을 만들어 응답 시간을 단축했습니다.
- 클라우드 GPU 서비스: 고객 SLA를 충족하기 위해 Inference Job은 Preemption 불가 QoS로 운영하고, Training Job은 Checkpoint 기반 Preemption을 허용했습니다.
- 제조 기업 HPC: 생산 공정 품질 검사에 Inference Job을 사용하고, 연구 부서 학습 Job과 분리된 정책을 적용하여 생산 환경 SLA를 보장했습니다.
장점과 단점
장점
- Job 특성에 맞는 최적의 배치를 통해 성능과 SLA를 동시에 만족합니다.
- 대규모 Training과 단기 Inference 간 충돌을 방지합니다.
- 정책 기반으로 운영하면 관리자가 개입하지 않아도 안정적입니다.
단점
- Job 프로파일링을 잘못 정의하면 오히려 비효율이 발생합니다.
- 분리 정책이 복잡해지면 운영자가 관리하기 어렵습니다.
- 워크로드 특성이 변화할 경우 정책을 자주 업데이트해야 합니다.
실무 팁과 주의사항
- 워크로드 모니터링 필수
- Prometheus, Grafana, Slurm Accounting 데이터를 활용하여 Training과 Inference Job의 자원 사용 패턴을 지속적으로 분석해야 합니다.
- Checkpoint/Preemption 전략
- Training Job은 Checkpoint를 필수화하여 Inference Job이 들어올 경우 안전하게 선점할 수 있도록 해야 합니다.
- 분리된 Queue/Partition 운영
- Training 전용, Inference 전용 Partition을 분리하여 혼잡도를 줄이는 것이 효과적입니다.
- 클라우드 GPUaaS 연계
- On-Prem 환경이 과부하되면 Inference Job만 클라우드 GPUaaS로 오프로딩(offloading)하는 전략도 가능합니다.
- 자동화 정책 반영
- Airflow, Kubeflow 등 Workflow Orchestrator와 연계하여 Job 성격에 따른 Partition/QoS를 자동 적용하면 운영 효율성이 높아집니다.
정리하며
자원 프로파일링 기반 Scheduling은 HPC/GPU 클러스터 운영에서 Training과 Inference라는 이질적인 워크로드를 조화롭게 운영하는 핵심 기법입니다. Training Job은 Throughput 중심, Inference Job은 Latency 중심이라는 특성을 이해하고, Partition·QoS·Priority를 활용해 정책을 차별화해야 합니다. 이를 통해 운영자는 자원 활용률을 높이는 동시에 사용자 SLA를 만족시킬 수 있습니다.