ADR 0003: DGX Spark multi-node LLM에 Spark Stacking 사용¶

1. 상태¶

Proposed

2. 결정 요약¶

DGX Spark 여러 대를 이용해 단일 LLM workload를 실행해야 하는 경우, DGX Spark의 ConnectX-7 기반 Spark Stacking을 우선 검토한다.

Kubernetes의 역할은 GPU node와 workload lifecycle을 관리하는 것이다. 여러 DGX Spark의 GPU를 하나의 LLM 실행 단위로 묶는 것은 Kubernetes CNI나 GPU Operator가 아니라, ConnectX-7 고속 네트워크와 NCCL/MPI 같은 distributed runtime 계층이 담당한다.

Cilium은 RKE2 cluster의 primary CNI로 유지한다. 다만 Cilium만으로 Spark Stacking, RoCE, RDMA, NCCL 통신이 자동 구성되는 것은 아니다. 고속 GPU 간 통신은 host network 또는 별도 secondary/RDMA network 설계로 분리해서 다룬다.

3. 배경¶

DGX Spark는 단일 장비에서도 LLM 개발과 추론을 실행할 수 있지만, 더 큰 모델이나 더 높은 처리량이 필요하면 여러 DGX Spark를 연결해 distributed workload로 실행하는 시나리오가 필요하다.

NVIDIA DGX Spark 문서는 이 시나리오를 Spark Stacking으로 설명한다. DGX Spark 두 대를 QSFP/CX7 cable로 연결하고, Grace Blackwell GPU 간 distributed workload를 MPI와 NCCL로 실행하는 흐름이다. NVIDIA의 Spark playbook도 두 장비 사이에 200GbE direct connection을 구성하고 NCCL을 검증하는 절차를 제공한다.

이때 계층은 다음처럼 나뉜다.

DGX Spark nodes
  |
  v
ConnectX-7 QSFP / 200GbE link
  |
  v
Ethernet / RoCE / high-speed interconnect
  |
  v
NCCL / MPI
  |
  v
distributed LLM runtime

GPU Operator는 이 문제를 해결하지 않는다. GPU Operator는 각 node의 GPU를 Kubernetes resource로 노출하고, driver/runtime/device plugin/telemetry를 관리하는 계층이다. gpu-01, gpu-02의 GPU가 Kubernetes에 보이도록 만드는 것이 GPU Operator의 책임이고, 두 node의 GPU를 하나의 LLM workload가 함께 쓰게 만드는 것은 distributed runtime의 책임이다.

4. 선택 기준¶

이 결정에서 중요하게 본 기준은 다음과 같다.

DGX Spark가 제공하는 공식 multi-node 연결 방식과 맞을 것
RKE2/Cilium/GPU Operator의 책임과 충돌하지 않을 것
LLM inference 또는 fine-tuning runtime이 NCCL/MPI 기반으로 확장 가능할 것
병원 내부망의 일반 management traffic과 GPU interconnect traffic을 분리할 수 있을 것
Kubernetes 안에서 실행할 경우에도 network namespace, RDMA device, GPU resource 할당 경계가 명확할 것
처음부터 복잡한 RDMA Kubernetes 구성을 강제하지 않고, host-level 검증에서 Kubernetes workload로 단계적으로 확장할 수 있을 것

5. 결정¶

DGX Spark multi-node LLM은 Spark Stacking을 우선 경로로 검토한다.

초기 운영 모델은 다음 순서로 둔다.

1. RKE2 cluster 구성
2. NVIDIA GPU Operator로 nvidia.com/gpu resource 노출
3. DGX Spark 간 ConnectX-7 QSFP link 구성
4. host level에서 NCCL/MPI 통신 검증
5. Kubernetes workload에서 hostNetwork 또는 secondary network로 재검증
6. LLM runtime 선택 후 distributed serving/training manifest 작성

즉 Kubernetes cluster가 먼저 안정적으로 구성되어야 하고, GPU resource가 먼저 노출되어야 한다. 그 다음 DGX Spark 간 고속 네트워크를 검증하고, 마지막으로 LLM runtime을 Kubernetes workload로 올린다.

5-1. Cilium과의 관계¶

Cilium은 primary CNI로 유지한다. Cilium은 RKE2 cluster의 Pod-to-Pod connectivity, service traffic, network policy, observability를 담당한다.

하지만 Cilium은 Spark Stacking 자체를 구성하지 않는다. Cilium을 설치했다고 해서 ConnectX-7 QSFP link, RoCE/RDMA device, NCCL interface selection, MPI hostfile, distributed rank 구성이 자동으로 준비되는 것은 아니다.

따라서 Cilium에 대한 판단은 다음과 같다.

일반 Kubernetes pod/service traffic에는 Cilium을 사용한다.
GPU interconnect traffic은 별도 고속 network path로 취급한다.
host-level NCCL 검증 단계에서는 Cilium을 통하지 않는다.
Kubernetes workload 안에서 고속 network를 사용해야 하면 hostNetwork 또는 secondary network 구성을 검토한다.
RDMA/RoCE device를 pod 안에 노출해야 하면 NVIDIA Network Operator, RDMA Shared Device Plugin, SR-IOV 또는 Multus 기반 secondary network를 별도 ADR로 다룬다.

즉 Cilium은 이 결정과 충돌하지 않지만, Cilium만으로 충분하지도 않다.

5-2. Kubernetes 안에서 실행할 때의 경계¶

Kubernetes 안에서 multi-node LLM을 실행하려면 workload가 여러 pod 또는 process rank로 나뉘어야 한다.

예시는 다음과 같다.

LLM workload
  rank 0 -> gpu-01 -> nvidia.com/gpu: 1
  rank 1 -> gpu-02 -> nvidia.com/gpu: 1
  rank 2 -> gpu-03 -> nvidia.com/gpu: 1

rank 간 통신 -> NCCL/MPI over ConnectX-7 network

Kubernetes scheduler는 각 pod에 GPU resource를 할당할 수 있다. 하지만 rank 간 통신, rendezvous, NCCL interface 선택, tensor parallelism, pipeline parallelism은 LLM runtime과 job launcher가 책임진다.

따라서 이 ADR은 LLM runtime까지 결정하지 않는다. vLLM, TensorRT-LLM, SGLang, PyTorch DDP, Ray, MPI Operator, Kubeflow Training Operator, Kueue/Volcano 같은 선택지는 별도 workload ADR 또는 운영 가이드에서 다룬다.

5-3. 초기 검증 범위¶

초기 검증은 Kubernetes보다 host-level Spark Stacking 검증을 먼저 수행한다.

확인할 항목은 다음과 같다.

QSFP/CX7 cable 연결 상태
ConnectX-7 interface link up
interconnect용 static IP 또는 route
nvidia-smi
NCCL test
MPI 기반 multi-node 실행

host-level 검증이 끝난 뒤 Kubernetes workload로 옮긴다. 이 순서를 두는 이유는 CNI, pod network namespace, service discovery 문제와 순수 Spark Stacking 문제를 분리하기 위해서다.

6. 대안¶

6-1. Cilium만으로 처리¶

Cilium은 primary CNI로 유지할 가치가 있다. network policy와 observability 측면에서 병원 현장 cluster에 적합하다.

하지만 Cilium은 DGX Spark의 ConnectX-7 link나 NCCL/MPI topology를 구성하지 않는다. RDMA/RoCE device를 pod에 노출하거나 secondary interface를 붙이는 문제도 Cilium만의 책임으로 보기 어렵다.

결정: Cilium은 primary CNI로 사용하지만, Spark Stacking 구현 수단으로 보지는 않는다.

6-2. Kubernetes 밖에서만 실행¶

DGX Spark playbook을 따라 host OS에서 NCCL/MPI 기반 LLM을 직접 실행할 수 있다.

이 방식은 초기 검증에는 가장 단순하다. 그러나 병원 현장에서 workload lifecycle, 배포 이력, resource scheduling, observability를 Kubernetes/Argo CD와 연결하기 어렵다.

결정: 초기 검증에는 사용하지만, 장기 운영 모델로 고정하지 않는다.

6-3. NVIDIA Network Operator를 즉시 도입¶

NVIDIA Network Operator는 Kubernetes cluster에서 fast networking, RDMA, GPUDirect 관련 구성요소를 관리하기 위한 Operator다. RDMA Shared Device Plugin, SR-IOV Network Device Plugin, secondary network, Multus 같은 구성요소와 함께 쓰일 수 있다.

하지만 DGX Spark에서 필요한 multi-node LLM 경로가 hostNetwork로 충분한지, secondary RDMA network가 필요한지는 아직 검증되지 않았다. 또한 DGX Spark의 GPUDirect RDMA 지원 범위도 별도로 확인해야 한다.

결정: 즉시 도입하지 않는다. host-level Spark Stacking과 Kubernetes workload 검증 후 필요하면 별도 ADR로 다룬다.

7. 결과¶

긍정적 영향:

GPU Operator와 Spark Stacking의 책임 경계가 명확해진다.
Cilium을 primary CNI로 유지하면서 GPU interconnect를 별도 계층으로 다룰 수 있다.
host-level NCCL/MPI 검증과 Kubernetes workload 검증을 단계적으로 분리할 수 있다.
LLM runtime 선택을 뒤로 미루고 network substrate 결정을 먼저 정리할 수 있다.

부정적 영향:

Kubernetes만으로 multi-node LLM이 자동으로 구성되지는 않는다.
host-level network 설정, NCCL 설정, Kubernetes workload 설정을 모두 검증해야 한다.
secondary network나 RDMA device plugin이 필요해지면 운영 복잡도가 커진다.

중립적 영향:

Cilium은 일반 pod networking에는 계속 사용한다.
GPU interconnect traffic은 Cilium의 primary pod network와 별도로 볼 수 있다.
NVIDIA Network Operator는 후속 검토 대상이다.

8. 후속 작업¶

DGX Spark 간 QSFP/CX7 cable 연결과 ConnectX-7 interface 이름을 문서화한다.
interconnect용 IP 대역과 netplan 설정을 정리한다.
host-level NCCL/MPI test 절차를 운영 문서에 추가한다.
Kubernetes workload에서 hostNetwork 기반 multi-node NCCL test를 검증한다.
secondary RDMA network가 필요하면 NVIDIA Network Operator 도입 ADR을 별도로 작성한다.
사용할 LLM runtime을 결정하고 distributed serving/training 배포 방식을 별도 문서로 작성한다.