들어가며: 랙 스케일 하드웨어와 스케줄러의 괴리

NVIDIA GB200 NVL72, GB300 NVL72 시스템은 단일 랙 안에 18개의 컴퓨트 트레이가 빽빽하게 들어찬 랙 스케일 슈퍼컴퓨터입니다. NVLink 스위치로 연결된 GPU 패브릭, 노드 간 공유 메모리를 가능하게 하는 IMEX 도메인 등 하드웨어 성능은 인상적이지만, 실제 운영자의 고민은 ‘이걸 어떻게 스케줄러가 알게 하지?’에서 시작됩니다.

기존 Slurm이나 Kubernetes는 GPU를 평평한 풀(flat pool)로 바라봅니다. 같은 NVLink 도메인에 속한 GPU끼리 통신해야 성능이 극대화된다는 사실을 스케줄러는 모릅니다. 이 글에서는 NVIDIA Mission Control, Slurm topology/block 플러그인, Kubernetes ComputeDomain, NVIDIA Run:ai가 이 문제를 어떻게 해결하는지 실제 코드와 함께 살펴보겠습니다.

참고 자료: 이 글은 NVIDIA 공식 블로그의 내용을 기반으로 실무 관점에서 재구성했습니다.

NVIDIA Blackwell rack-scale supercomputer with NVLink fabric topology diagram System Abstract Visual

핵심 개념: Cluster UUID와 Clique ID

NVLink 토폴로지를 스케줄러가 이해하려면 하드웨어 정보를 소프트웨어가 읽을 수 있는 식별자로 추상화해야 합니다. NVIDIA는 이를 위해 두 가지 식별자를 제공합니다.

  • Cluster UUID: NVLink 도메인(즉, 물리적으로 같은 랙에 속하는지)을 나타냅니다. 같은 NVL72 랙의 모든 GPU는 동일한 Cluster UUID를 가집니다.
  • Clique ID: NVLink 파티션(논리적 분할)을 나타냅니다. 같은 랙 안에서도 GPU 그룹을 나누면 Clique ID가 달라집니다.

이 식별자들은 Slurm의 topology/block 플러그인, Kubernetes의 ComputeDomain, Run:ai의 자동 레이블링에서 핵심적인 역할을 합니다.

Slurm에서의 활용

Slurm에서 NVLink 파티션을 블록(block)으로 매핑하면, 같은 NVLink 도메인 안에서만 작업이 배치되도록 강제할 수 있습니다.

# slurm.conf 예시 (NVLink 파티션을 블록으로 정의)
# 각 랙을 하나의 블록으로, 또는 랙 내 파티션을 여러 블록으로 구성
# 예: 2개의 NVL72 랙 → 2개의 블록

# topology.conf
SwitchName=rack0 Nodes=node[0-17] Weight=1
SwitchName=rack1 Nodes=node[18-35] Weight=10

# slurm.conf
TopologyPlugin=topology/block
TopologyParam=TopoOptional

이렇게 설정하면 Slurm은 기본적으로 같은 블록(같은 NVLink 도메인) 내에 작업을 배치하고, 블록을 넘어서는 배치가 필요할 때만 가중치(Weight)를 고려합니다.

IMEX 관리: Slurm에서의 per-job 격리

IMEX는 멀티 노드 CUDA 작업이 공유 메모리 모델을 사용할 수 있게 해주는 시스템 레벨 데몬입니다. Mission Control은 IMEX가 정확히 작업에 참여하는 컴퓨트 트레이에서만 실행되고, 작업 종료 후 정리되도록 보장합니다.

# Mission Control CLI를 통한 IMEX 도메인 생성 예시
# (실제 명령어는 NVIDIA Mission Control Administrator Guide 참조)
mc imex create --domain my-job-domain --trays tray-0,tray-1,tray-2
# Slurm prolog/epilog 스크립트에서 호출하여 작업 단위로 격리

이렇게 하면 서로 다른 작업 간 IMEX 채널이 간섭하지 않아 안정성이 크게 향상됩니다.

AI workload scheduling flow from Slurm partition to NVLink domain placement Technical Structure Concept

Kubernetes + Run:ai: ComputeDomain으로 NVLink 인식하기

Kubernetes는 기본적으로 NVLink를 모릅니다. NVIDIA DRA(Dynamic Resource Allocation) 드라이버가 이 갭을 메웁니다. ComputeDomain CRD를 사용하면 NVLink/MNNVL 도메인을 Kubernetes 리소스로 표현할 수 있습니다.

# ComputeDomain 리소스 예시 (NVLink 도메인에 18개 노드 할당)
apiVersion: resource.nvidia.com/v1beta1
kind: ComputeDomain
metadata:
  name: compute-domain
spec:
  numNodes: 18
  channel:
    resourceClaimTemplate:
      name: compute-domain-resource-claim

# 워크로드 배포 시 ComputeDomain 연결
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-workload
  labels:
    app: test-workload
spec:
  replicas: 18
  selector:
    matchLabels:
      app: test-workload
  template:
    metadata:
      labels:
        app: test-workload
    spec:
      containers:
      - name: ctr
        image: ubuntu:22.04
        command: ["test-workload"]
        resources:
          limits:
            nvidia.com/gpu: 4
          claims:
          - name: compute-domain
      resourceClaims:
      - name: compute-domain
        resourceClaimTemplateName: compute-domain-resource-claim

NVIDIA Run:ai는 이 ComputeDomain을 자동으로 생성하고, 노드 레이블링을 통해 NVLink 도메인 멤버십을 관리합니다. 사용자는 단순히 GPU 수를 요청하면 되고, Run:ai가 최적의 노드에 배치합니다.

Topograph: 토폴로지 자동 탐지

수동으로 NVLink 도메인을 정의하는 것은 대규모 환경에서 확장 불가능합니다. NVIDIA의 오픈소스 도구 Topograph가 이 문제를 해결합니다. Topograph는 노드 메타데이터를 수집해 NVLink 도메인, 랙 경계, 네트워크 계층을 자동으로 탐지하고, 스케줄러가 소비할 수 있는 API를 제공합니다.

# Topograph CLI 예시 (가상)
topograph discover --cluster my-cluster --output topology.json
# 출력: 각 노드의 Cluster UUID, Clique ID, 스위치 연결 정보

이 정보는 Slurm의 topology.conf 생성이나 Kubernetes 노드 레이블링에 자동으로 활용됩니다.

Kubernetes ComputeDomain resource claim YAML example for multi-node GPU training IT Technology Image

국내 AI 인프라 환경에서의 적용 맥락

국내 대기업 AI 센터나 HPC 클러스터를 운영해보신 분들은 아시겠지만, ‘하드웨어는 좋은데 스케줄러가 못 따라온다’는 이야기를 자주 듣습니다. 특히 Slurm을 사용하는 연구소 환경에서는 --gres=gpu:8 같은 단순 요청이 실제로는 서로 다른 NVLink 도메인에 걸쳐 GPU를 할당해 성능이 반토막 나는 경우가 많습니다.

이 글에서 소개한 topology/block 플러그인과 ComputeDomain 방식을 도입하면:

  • GPU 할당의 성능 예측 가능성이 높아집니다.
  • 사용자(연구자/엔지니어)가 NVLink 토폴로지를 몰라도 최적 배치가 보장됩니다.
  • 클러스터 전체 GPU 활용률이 향상됩니다.

이 기술의 한계와 주의사항

  • 초기 설정 복잡도: Mission Control, Topograph, DRA 드라이버 설치 및 연동에 상당한 엔지니어링 시간이 필요합니다. 특히 기존 Slurm 클러스터에 topology/block을 도입하면 기존 작업 큐의 동작이 변경될 수 있으므로 충분한 테스트가 필수입니다.
  • 벤더 종속성: NVIDIA 전용 하드웨어(NVLink, IMEX)에 의존하므로 AMD나 Intel GPU 클러스터에는 적용할 수 없습니다.
  • 오버헤드: ComputeDomain을 작업마다 생성/삭제하면 etcd에 부하가 갈 수 있습니다. 대규모 클러스터(수천 노드)에서는 DRA 리소스 클레임 관리에 주의가 필요합니다.

함께 보면 좋은 글

다음 단계 학습 방향

  1. Mission Control 실습: NVIDIA LaunchPad에서 Grace Blackwell NVL72 환경을 체험해보세요.
  2. Topograph 오픈소스 기여: GitHub에서 Topograph 리포지토리를 포크해 자신의 클러스터에 맞게 확장해보세요.
  3. Slurm topology/block 심화: Slurm 공식 문서의 topology.conf 작성 가이드를 참고해 다양한 토폴로지 패턴을 실험해보세요.

AI 인프라 운영자로서, 하드웨어 성능을 100% 뽑아내는 것은 단순히 GPU 숫자를 늘리는 것이 아니라, 스케줄러와 하드웨어가 대화하게 만드는 데 달려 있습니다. 이 글이 그 첫걸음이 되길 바랍니다.

본 콘텐츠는 신뢰할 수 있는 출처를 바탕으로 AI 도구를 활용하여 초안이 작성되었으며, 편집자의 검토를 거쳐 발행되었습니다. 전문가의 조언을 대체하지 않습니다.