DEVOCEAN

인공지능 모델의 크기가 커지면서 인프라를 증설하는 방식도 달라졌습니다. 과거에는 중앙처리장치(CPU) 기반 가상 서버의 수량을 늘리고 부하를 분산하는 웹 아키텍처가 중심이었습니다. 반면 거대 언어 모델(LLM)과 확산 모델(Diffusion Model)을 다루는 현재의 워크로드는 개별 연산 칩의 사양만으로 처리량을 보장하기 어렵습니다. 연산 장치 사이에 오가는 텐서(Tensor, 다차원 배열 데이터)의 동기화 속도와 이를 물리 장비 위에서 공정하게 스케줄링하는 플랫폼이 인프라의 실질 처리량을 결정합니다.

이와 관련하여 두 가지 기록이 공개되었습니다. 하나는 kt cloud 기술 블로그에서 발표한 GPUaaS(GPU as a Service) 네트워크 경쟁 구조 분석입니다. 분산 학습 환경에서 GPU 간, 서버 간 연결 대역폭을 확보하기 위해 NVLink, InfiniBand, RoCE(RDMA over Converged Ethernet)가 어떤 역할을 수행하는지 다룹니다. 다른 하나는 NHN Cloud 기술 블로그의 GPU Live 운영 사례입니다. 고가의 하드웨어를 확보한 뒤에도 작업 할당, 환경 구성, 실행 이력 추적, 자원 회수가 체계적으로 통제되지 않으면 클러스터 운영이 마비된다는 실무 문제를 지적합니다. 이 두 소식은 대규모 AI 인프라가 네트워크 패브릭과 테넌트 통제 계층이라는 두 축으로 작동함을 보여줍니다.

GPU 간 통신 병목과 스케줄링의 부재가 초래하는 지연

많은 개발팀이 모델 학습이나 파인튜닝(Fine-tuning)을 진행할 때 GPU 장비의 단일 사양(TFLOPS)을 확인합니다. 하지만 70B 이상의 대규모 파라미터를 여러 노드에 걸쳐 분산 배치하는 순간, 연산 시간보다 그래디언트(Gradient, 기울기) 값을 교환하는 통신 시간이 전체 처리 시간을 지배하기 시작합니다.

통신 지연이 길어지면 그래픽 카드의 연산 코어는 다음 단계 계산을 진행하지 못하고 대기 상태(Idle)에 머뭅니다. 이 현상을 막으려면 노드 내부뿐 아니라 서버 랙(Rack) 사이를 잇는 스위치 패브릭의 지연 시간을 나노초 단위로 낮춰야 합니다.

동시에 조직 내부의 운영 병목도 발생합니다. 여러 명의 엔지니어와 연구원이 클러스터를 공유할 때 작업 큐(Queue)와 격리 정책이 없으면 특정 작업이 전체 GPU 메모리를 점유한 채 방치됩니다. 다른 연구원은 환경 구성 충돌을 겪거나 자원 할당 순서를 수동으로 조율하느라 시간을 허비합니다. 하드웨어 스펙이 높아도 이를 연결하는 전송망과 작업 배치 체계가 정교하지 못하면 실제 클러스터 가동률은 저하됩니다.

상호연결 패브릭의 위계: NVLink, InfiniBand, RoCE

kt cloud 기술 블로그의 분석은 분산 AI 학습의 성패를 가르는 핵심 요소로 GPU 간, 서버 간 네트워크 구조를 지목합니다. 단일 머신 내부와 서버 간 클러스터 단위 통신은 전혀 다른 하드웨어 프로토콜을 사용합니다.

서버 한 대 안에서는 NVLink와 NVSwitch가 통신을 전담합니다. 전통적인 PCIe 슬롯을 통한 데이터 전송은 CPU를 거쳐야 하므로 대역폭의 한계가 명확합니다. 반면 NVLink는 GPU 칩끼리 점대점(Point-to-Point)으로 직접 연결되어 초당 수백 기가바이트(GB/s) 단위의 양방향 대역폭을 제공합니다. 이를 통해 한 장비 안에 장착된 8장의 GPU가 마치 하나의 거대한 메모리 풀처럼 동작할 수 있습니다.

문제는 학습 규모가 커져 수십 대, 수백 대의 노드를 묶어야 하는 분산 학습 환경입니다. 노드 경계를 넘어설 때는 서버 간 인터커넥트 기술이 필요합니다. 원문은 이 영역에서 InfiniBand와 RoCE(RDMA over Converged Ethernet)가 수행하는 역할을 정리합니다.

RDMA(원격 직접 메모리 접근, Remote Direct Memory Access)는 네트워크 인터페이스 카드(NIC)가 운영체제 커널의 CPU 개입 없이 상대방 원격 서버의 메모리에 직접 데이터를 쓰고 읽는 기술입니다. 호스트 CPU의 컨텍스트 스위칭과 메모리 복사 오버헤드를 건너뛰기 때문에 지연 시간이 대폭 줄어듭니다.

InfiniBand는 무손실(Lossless) 전송을 하드웨어 수준에서 보장하는 전용 패브릭입니다. 크레딧 기반 흐름 제어를 지원하여 패킷 손실이 발생하지 않고 지연 시간이 매우 낮지만, 전용 스위치와 케이블을 갖춰야 하므로 구축 단가가 높습니다.

반면 RoCE는 기존에 널리 쓰이던 고속 Ethernet 스위치 인프라 위에서 RDMA를 구현합니다. 전용 장비를 전부 새로 구성하지 않아도 되므로 비용 효율이 높지만, 이더넷 특유의 패킷 손실을 방지하기 위해 스위치 계층에서 PFC(Priority-based Flow Control)와 ECN(Explicit Congestion Notification) 설정을 정밀하게 튜닝해야 합니다.

여기서부터는 DEVOTEE의 해석입니다. 네트워크 구조를 결정할 때 중요한 것은 학습 작업에 적용하는 병렬화 기법입니다. 텐서 병렬화(Tensor Parallelism)처럼 레이어 내부의 연산을 쪼개어 실시간으로 빈번한 통신이 발생하는 단계는 노드 내부의 NVLink 버스에 국한시켜야 합니다. 반면 배치 단위로 데이터를 쪼개는 데이터 병렬화(Data Parallelism)나 파이프라인 병렬화(Pipeline Parallelism)는 비교적 통신 빈도가 낮으므로 노드 간 RoCE나 InfiniBand 패브릭으로 분산시키는 토폴로지 설계가 필수적입니다. 이 위계 구조를 무시하고 텐서 병렬화를 이더넷 경계 너머로 확장하면 통신 지연으로 인해 전체 클러스터 성능이 급격히 저하됩니다.

하드웨어 위의 작업 통제: GPU Live의 멀티테넌트 운영

물리 네트워크와 GPU 장비가 구성되었다고 해서 인프라 준비가 끝나는 것은 아닙니다. NHN Cloud 기술 블로그는 GPU 클러스터를 운영할 때 자원을 누구에게 배분하고, 학습 작업을 어떻게 실행하며, 사용 이력을 어떻게 추적하고 회수할 것인가의 문제를 다룹니다.

원문에 따르면 하드웨어 풀을 갖춘 조직도 실행 환경 구성, 작업 실행 및 모니터링, 결과 저장, 자원 회수 단계에서 다양한 병목을 마주합니다. 엔지니어마다 서로 다른 PyTorch, CUDA, 드라이버 버전을 요구하기 때문에 베어메탈 서버나 정적 가상 머신 환경에서는 라이브러리 충돌이 빈번하게 일어납니다. 또한 학습 작업이 끝났음에도 컨테이너나 인스턴스가 반환되지 않아 유휴 상태로 과금이 이어지는 일도 발생합니다.

이를 해결하기 위해 NHN Cloud는 GPU Live 플랫폼을 통해 자원 할당부터 작업 수명 주기(Lifecycle)를 통제하는 솔루션을 제시합니다. 개발자는 복잡한 환경 설정 대신 미리 구성된 컨테이너 이미지를 선택하고, 필요한 GPU 수량을 지정하여 작업을 제출합니다. 플랫폼은 클러스터 내부의 유휴 자원을 탐색하여 분산 학습 작업을 스케줄링하고, 실행이 완료되면 즉시 자원을 회수하여 다른 테넌트가 사용할 수 있도록 반환합니다.

인프라 관리 관점에서 달라지는 핵심은 작업 매니페스트의 표준화입니다. 엔지니어가 임의로 SSH에 접속하여 백그라운드 프로세스로 학습을 구동하는 방식 대신, 쿠버네티스(Kubernetes) 기반의 배치 작업이나 선언적 명세서를 통해 인프라 제어 계층에 작업을 위임해야 합니다.

다음은 쿠버네티스 환경에서 고속 분산 학습을 위해 RoCE 기반의 RDMA 네트워크 장치(rdma/roce)와 GPU 자원을 함께 요구하는 워크로드 정의 예시입니다. 단일 노드 안에서 작업을 고립시키지 않고, 호스트의 고속 패브릭 장치를 컨테이너 내부로 안전하게 바인딩하는 설정입니다.

apiVersion: batch/v1
kind: Job
metadata:
  name: distributed-training-worker
  namespace: ml-platform
spec:
  template:
    spec:
      restartPolicy: OnFailure
      containers:
      - name: torchrun-trainer
        image: nvcr.io/nvidia/pytorch:26.04-py3
        command: ["torchrun"]
        args:
          - "--nproc_per_node=8"
          - "--nnodes=2"
          - "--rdzv_id=job_1024"
          - "--rdzv_backend=c10d"
          - "--rdzv_endpoint=training-master.ml-platform:29500"
          - "train.py"
          - "--batch-size=64"
        resources:
          limits:
            nvidia.com/gpu: "8"
            rdma/roce: "1"
            memory: "256Gi"
            cpu: "64"
          requests:
            nvidia.com/gpu: "8"
            rdma/roce: "1"
            memory: "128Gi"
            cpu: "32"
        securityContext:
          capabilities:
            add: ["IPC_LOCK"]
        volumeMounts:
        - mountPath: /dev/shm
          name: dshm
      volumes:
      - name: dshm
        emptyDir:
          medium: Memory
          sizeLimit: 64Gi

위 설정에서 resources.limits에 지정된 rdma/roce 자원은 컨테이너 런타임에 호스트의 RDMA 전용 네트워크 인터페이스를 컨테이너 네임스페이스로 직접 노출하도록 지시합니다. 또한 NCCL(NVIDIA Collective Communications Library)이 프로세스 간 공유 메모리를 원활히 활용할 수 있도록 /dev/shm 마운트 크기를 메모리 기반의 64GiB로 확장했습니다. 이처럼 물리 네트워크 디바이스의 권한을 컨테이너에 정밀하게 매핑하고 메모리 락(IPC_LOCK) 권한을 부여해야 패브릭의 성능을 낭비 없이 끌어낼 수 있습니다.

스케줄링 플랫폼은 이러한 매니페스트를 받아 노드 간 토폴로지를 계산하고, 가장 물리적으로 인접한 랙과 스위치에 위치한 노드들을 그룹화하여 작업을 배치합니다. 작업이 완료되면 할당되었던 가속기와 네트워크 인터페이스는 즉각 해제되어 대기 중인 다른 작업으로 전환됩니다.

두 기술에 대한 실무적 판단

네트워크 구조와 플랫폼 관리 계층에 대해 각각 다음과 같이 판단합니다.

첫째, RoCE 및 InfiniBand 기반 초고속 패브릭 구축은 조건부로 유효합니다. 매개변수 크기가 70B 이상인 거대 모델을 다중 노드로 분산 학습하거나, 노드 간 통신 대기 시간이 모델 수렴 속도에 직접 영향을 미치는 대규모 사전 학습(Pre-training) 환경에는 필수적인 투자입니다. 반면 단일 노드 안에서 8장의 GPU로 해결 가능한 가벼운 미세조정(LoRA)이나 독립된 추론 API 서빙 중심의 환경이라면 고가의 스위치 패브릭 구축 비용 대비 얻는 성능 이점이 크지 않습니다. 워크로드의 멀티 노드 텐서 교환 빈도를 먼저 실측해야 합니다.

둘째, 작업 할당과 수명 주기를 제어하는 GPU 운영 플랫폼 도입은 지금 써볼 만합니다. 연구원과 엔지니어가 3명 이상 클러스터를 공유하는 시점부터는 수동 작업 관리가 실패하기 쉽습니다. 유휴 장비의 방치로 인한 클라우드 비용 누수와 라이브러리 버전 충돌로 인한 시간 낭비를 감안하면, 작업 스케줄링과 자동 자원 회수 기능이 제공하는 운영 효율성은 인프라 도입 초기부터 명확한 이점을 제공합니다.

도입 전 확인할 것

대규모 가속기 인프라와 관리 플랫폼을 도입하기 전에 엔지니어링 팀은 다음 세 가지 기술적 전제 조건을 검토해야 합니다.

1. 워크로드의 통신 패턴 프로파일링: 팀에서 주로 수행하는 작업이 노드 간 통신을 대량으로 유발하는 분산 학습인지, 단일 인스턴스 안에서 완결되는 독립적인 추론·배치 작업인지 분석하세요. PyTorch Profiler나 NCCL 환경 변수(NCCL_DEBUG=INFO)를 통해 올리듀스(All-Reduce) 단계의 네트워크 통신 병목 시간을 먼저 측정해야 인프라 스펙을 과도하게 산정하지 않습니다.
2. 이더넷 스위치의 무손실 패킷 전송 지원 여부: RoCE를 채택하고자 한다면 보유 중이거나 임대하려는 데이터센터 스위치가 PFC와 ECN 흐름 제어를 완벽하게 지원하는지 확인해야 합니다. 이더넷 환경에서 흐름 제어가 어긋나 패킷 재전송이 발생하면 RDMA를 적용하더라도 전송 속도가 급격히 떨어집니다.
3. 선언적 작업 정의와 자동 회수 메커니즘 구축: 인프라 관리 플랫폼을 도입하기 전, 팀 내 학습 스크립트가 컨테이너 기반으로 격리되어 실행될 수 있는지, 종료 시 체크포인트를 원격 스토리지(S3, Ceph 등)로 내보내고 정상 종료 코드를 반환하는 구조를 갖추었는지 점검하세요. 비정상 종료 시에도 자원을 반환하는 타임아웃 정책이 스케줄러에 설정되어 있어야 인프라 낭비를 막을 수 있습니다.

그 밖의 소식

• 사내 지식으로 Agentic RAG 만들기 (2/3) : 검색을 얹기, LightRAG와 Navigator — 원문
• Eurydice로 Rust를 읽기 쉬운 C로 컴파일하기 — 원문
• 쉐도잉 검증 개선기 — 원문
• 자기회귀 확산으로 시장 데이터를 생성할 수 있을까? — 원문