26S05a

기존 클러스터 노드들과 마찬가지로 외부망과 내부망이 모두 존재하는 환경에서, GPU 노드 인수 직후 OS/플랫폼 팀이 수행해야 할 1단계(HW 무결성 및 시스템 점검)의 상세 실행 절차입니다.

특히 GPU 노드는 고전력 소모, 복잡한 PCIe/NUMA 토폴로지, 그리고 고속 NIC(ConnectX-6 + Intel E810)가 혼재되어 있으므로 초기 HW 결함(불량 PCIe 레인, 메모리 비트 에러, 발열 이슈)을 걸러내는 작업이 필수적입니다.

1. 하드웨어 인식 및 PCIe 토폴로지 점검

GPU와 NIC가 스펙시트대로 전체 대역폭을 확보한 상태로 링크 협상(Negotiation)을 마쳤는지 확인합니다.

GPU 및 NIC 장치 인식 여부

# GPU 인식 수량 확인 (NVIDIA 벤더 ID: 10de)
lspci -nn | grep -i 3d

# NIC 인식 확인 (Mellanox: 15b3, Intel E810: 8086)
lspci -nn | grep -E "Mellanox|Ethernet controller.*810"

PCIe Link Speed 및 Width 다운그레이드 여부 확인
라이저 카드 불량, 소켓 결착 불량, 또는 보드 불량 시 Gen4/Gen5 x16이 x8이나 Gen3 이하로 다운그레이드되는 경우가 잦습니다.

# 각 디바이스의 LnkCap(스펙상 지원)과 LnkSta(현재 동작 상태) 비교
# LnkSta의 Speed(16GT/s: Gen4, 32GT/s: Gen5)와 Width(x16) 확인
for bdf in $(lspci -d 10de: -d 15b3: | awk '{print $1}'); do
    echo "=== Device $bdf ==="
    lspci -s $bdf -vvv | grep -E "LnkCap:|LnkSta:"
done

NUMA 노드 바인딩 토폴로지 분석
GPU와 네트워크 카드가 물리적으로 어떤 CPU 소켓(NUMA 노드)에 직결되어 있는지 파악해야 추후 vLLM 코어 핀닝 및 zero-copy 경로 최적화가 가능합니다.

# CPU 소켓별 NUMA 노드 구조
numactl -H

# 각 디바이스가 물려있는 NUMA 노드 확인
for dev in $(lspci -d 10de: -d 15b3: | awk '{print $1}'); do
    echo "Device $dev -> NUMA Node: $(cat /sys/bus/pci/devices/0000:$dev/numa_node)"
done

2. 하드웨어 에러 로그 및 시스템 건강 상태(Health) 전수 점검

OS 부팅 과정에서 발생한 메모리 비트 에러나 PCIe AER(Advanced Error Reporting) 이벤트를 확인합니다.

커널 하드웨어 에러 로그 점검

# PCIe corrected/uncorrectable 에러 및 하드웨어 결함 점검
dmesg -T | grep -iE "mce|edac|aer|pcie.*error|fail|corrupted"

(AER Corrected 에러가 수백 번 이상 반복 카운팅된다면 슬롯/라이저 결착 불량이거나 불량 케이블일 가능성이 높음)

IPMI/BMC 시스템 이벤트 로그(SEL) 확인
OS가 올라오기 전 BIOS 레벨에서 감지된 PSU, Fan, 센서 에러를 체크합니다.

ipmitool sel elist | tail -n 30
ipmitool sdr list | grep -iE "fan|temp|status"

3. CPU 및 메모리(RAM) 스트레스 테스트

GPU 번인에 앞서 호스트 시스템의 기본 연산 및 시스템 메모리의 안정성을 먼저 확인합니다.

메모리(ECC) 무결성 및 CPU 부하 테스트
stress-ng를 이용해 시스템 메모리의 약 80~85%를 할당하고 전체 vCPU 코어를 1시간 동안 포화 상태로 구동합니다.

# 전체 CPU 코어 수 확인 후 실행
stress-ng --cpu $(nproc) --vm 4 --vm-bytes 80% --verify --timeout 1h --metrics-brief

동시 모니터링 포인트 (백그라운드 터미널)
EDAC 메모리 정정 에러 카운터 증가 여부:

watch -n 1 'cat /sys/devices/system/edac/mc/mc*/ce_count'

CPU 코어 온도 및 Throttling 점검:

watch -n 2 'sensors | grep -i "Package id"'

4. 로컬 스토리지(OS/NVMe) 속도 및 SMART 상태 점검

vLLM 구동 시 대용량 모델 가중치(Checkpoint)를 로컬 캐시에 저장하고 로드해야 하므로, 로컬 NVMe의 성능과 상태가 중요합니다.

NVMe 드라이브 SMART 상태

# nvme-cli 설치 확인 후 상태 점검
nvme list
nvme smart-log /dev/nvme0n1

(Critical Warning이 0, Available Spare가 100%, Media and Data Integrity Errors가 0인지 확인)

로컬 디스크 Direct I/O 속도 측정

fio --name=nvme_write --filename=/tmp/test_fio --size=10G --rw=write --bs=1M --direct=1 --ioengine=libaio --runtime=30 --group_reporting
rm -f /tmp/test_fio

5. 네트워크 인터페이스(NIC) 물리 링크 및 펌웨어 정합성 점검

현재 외부망은 Mellanox ConnectX-6, 내부망은 Intel E810입니다. 기존 클러스터(모두 E810 계열)와의 이종 구성을 감안하여 링크 레벨을 먼저 정리해야 합니다.

ConnectX-6 (외부망) 점검
Mellanox 드라이버(MLNX_OFED 또는 커널 인박스 mlx5_core) 로드 및 펌웨어 버전 확인:

ethtool -i <cx6_iface_name>

지원 링크 스피드(100G/200G 등) 정상 협상 여부 및 패킷 드랍 카운터:

ethtool <cx6_iface_name> | grep -E "Speed:|Duplex:|Link detected:"
ip -s link show <cx6_iface_name>

Intel E810 (내부망) 점검
E810 드라이버(ice) 및 펌웨어/DDP(Package) 버전 확인:

ethtool -i <e810_iface_name>
# driver: ice, version, firmware-version 확인

Intel E810 계열은 DDP(Dynamic Device Personalization) 펌웨어 버전 불일치 시 패킷 처리 이상이나 링크 플랩(Link Flap)이 발생할 수 있으므로 기존 클러스터 노드들의 ethtool -i 출력값과 펌웨어 버전을 일치시키는 작업이 권장됩니다.
내부망 스위치와 연결 전이라도 포트 LED 및 ethtool에서 NO-CARRIER 상태가 정상 유지되는지 확인합니다.

Phase 1 완료 판정 체크리스트 (Go/No-Go Criteria)

점검 항목	통과 기준 (Pass Criteria)	조치 사항 (Fail 시)
GPU/NIC PCIe 링크	전 장치 LnkSta = LnkCap (최대 Gen / x16 유지)	슬롯 재장착, Riser 카드 교체 요청
AER / MCE 로그	커널 로그 상 Uncorrectable 에러 0건	CPU/메모리/보드 점검 요청
CPU/RAM 부하	`stress-ng` 1시간 통과, EDAC 에러 0건, 스로틀링 없음	불량 메모리 모듈 교체
NVMe 상태	Critical Warning 0, 읽기/쓰기 스펙 속도 도달	NVMe 교체 또는 슬롯 점검
NIC 펌웨어	CX-6 최신 FW, E810 펌웨어/드라이버 기존 노드와 일치	펌웨어 업데이트 수행

이 단계가 모두 통과되면 HW 불량 이슈는 배제할 수 있으므로, 안심하고 Phase 2 (NVIDIA Driver / CUDA 설치 및 gpu-burn)로 진입하시면 됩니다.

===

2단계의 핵심 목표는 GPU 소프트웨어 스택(Driver, CUDA, Fabric Manager, Container Toolkit)을 안정적으로 배포하고, 실제 고부하 추론/학습 환경을 모사하여 전력 피크(Power Surge), 발열(Thermal Throttling), GPU 간 P2P 통신(NVLink/PCIe), VRAM 무결성을 사전에 검증하는 것입니다.

현재 노드는 외부망(ConnectX-6)만 연결되어 있으므로, 외부망을 통해 공식 리포지토리로부터 패키지를 내려받아 구성합니다.

Step 1. GPU 소프트웨어 스택 설치 및 베이스라인 구성

안정성이 검증된 Data Center(Production) 브랜치 드라이버와 CUDA 스택을 구성합니다.

사전 필수 패키지 및 기본 드라이버 충돌 방지

# Nouveau 비활성화 확인
lsmod | grep nouveau  # 아무것도 출력되지 않아야 함

# 커널 헤더 및 빌드 도구 설치
apt-get install -y build-essential linux-headers-$(uname -r) dkms
# (RHEL/Rocky 계열인 경우: dnf install -y kernel-devel-$(uname -r) kernel-headers gcc make)

NVIDIA Datacenter 드라이버 및 Fabric Manager 설치

HGX/SXM 계열(A100, H100 등 NVSwitch 탑재 모델)의 경우 nvidia-fabricmanager가 필수입니다. 드라이버 버전과 Fabric Manager 버전은 반드시 완전히 일치해야 합니다.

# 공식 NVIDIA 리포지토리 등록 후 드라이버 및 Fabric Manager 설치
apt-get install -y cuda-drivers-fabricmanager-550 nvidia-driver-550-server

# Fabric Manager 서비스 활성화 및 시작
systemctl enable --now nvidia-fabricmanager
systemctl status nvidia-fabricmanager

NVIDIA Container Toolkit 설치

vLLM을 컨테이너 기반으로 격리 배포하기 위해 Docker/Containerd에 런타임을 바인딩합니다.

apt-get install -y nvidia-container-toolkit
nvidia-ctk runtime configure --runtime=docker
systemctl restart docker

NVIDIA Persistence Daemon 활성화

드라이버 초기화 오버헤드 방지 및 절전 모드 진입 방지를 위해 상시 활성화합니다.

nvidia-smi -pm 1
systemctl enable --now nvidia-persistenced

Step 2. 기본 상태 및 P2P / NVLink 토폴로지 검증

드라이버가 로드된 후 GPU 간 통신 대역폭과 토폴로지 연결 상태를 점검합니다.

GPU 상태 및 링크 확인

nvidia-smi
# 전체 GPU 인식 수량, VRAM 용량, 드라이버/CUDA 버전 확인

# GPU 간 토폴로지 매트릭스 확인
nvidia-smi topo -m

SXM 구조라면 모든 GPU 간 연결이 NV# (NVLink)로 표시되어야 합니다.
PCIe 구조라면 PIX(단일 스위치), PXB(PCIe 브리지), 또는 SYS(호스트/CPU 경유)로 표시됩니다.

NVLink 상태 및 에러 카운터 점검 (SXM 모델 기준)

nvidia-smi nvlink -s
# 모든 NVLink 포트가 Active 상태인지 확인

nvidia-smi nvlink -e
# CRC 에러, 리플레이 에러가 0인지 확인

P2P 대역폭 및 Latency 실측 (p2pBandwidthLatencyTest)

NVIDIA CUDA Samples 컨테이너를 통해 GPU 상호 간 실제 메모리 복사 대역폭을 측정합니다.

docker run --rm --gpus all nvcr.io/nvidia/k8s/cuda-sample:vectorAdd-cuda12.5.0 \
    p2pBandwidthLatencyTest

검증 기준:
H100 SXM5: 단방향 약 450 GB/s, 양방향 약 900 GB/s 내외
A100 SXM4: 단방향 약 300 GB/s, 양방향 약 600 GB/s 내외
PCIe Gen4/Gen5: PCIe 버스 대역폭(약 25~50 GB/s) 수준 측정 확인

Step 3. VRAM 무결성 및 DCGM Level 3 진단

하드웨어 수준의 VRAM 비트 결함, 온보드 컨트롤러 결함을 조기에 발견하기 위해 NVIDIA DCGM(Data Center GPU Manager) 진단을 수행합니다.

DCGM 설치 및 서비스 기동

apt-get install -y datacenter-gpu-manager
systemctl enable --now nvidia-dcgm

DCGM Diagnostic Level 3 (Hardware Stress & Memory Test) 실행

메모리 대역폭, PCIe 대역폭, VRAM 무결성, E-Switch 진단을 심층 수행합니다 (약 15~30분 소요).

dcgmi diag -r 3

모든 테스트 항목(PCIe, Memory, Diagnostic, SM Stress)에서 PASS가 떨어지는지 확인합니다.
특히 Page Retirement나 Uncorrectable ECC Errors가 검출되는 카드는 즉시 HW 교체 대상입니다.

Step 4. 전체 GPU 풀 로드 Burn-In 테스트 (1~2시간 연속)

vLLM 구동 시 발생할 수 있는 최대 전력 피크(TDP Saturation)와 랙/서버 섀시 내 쿨링 성능을 한계치까지 검증합니다.

gpu-burn 도커 컨테이너 실행

8개(또는 장착된 전체) GPU를 동시에 100% 가동합니다.

docker run --rm --gpus all \
    -v /tmp:/tmp \
    wilic/gpu-burn:latest \
    3600  # 3600초 (1시간 구동)

동시 모니터링 포인트 (별도 세션)

GPU 전력, 온도, 스로틀링 추이 모니터링:

nvidia-smi dmon -s pucvmet -d 2

pwr: 각 GPU가 스펙상 최대 TDP(예: 400W, 700W) 근처까지 안정적으로 도달하는지 확인.
temp: GPU 온도가 쓰로틀링 임계치(통상 80~83℃ 이상)를 넘지 않고 안정적인 플래토(Plateau)를 형성하는지 점검.
clocks: 써멀 또는 파워 스로틀링으로 인해 클록이 급격히 튀거나(Drop) 다운되지 않는지 확인.

서버 섀시 전원 및 팬 속도 (IPMI):

watch -n 5 'ipmitool sensor | grep -iE "fan|psu|watt|temp"'

전원 공급 장치(PSU)가 서지 전류를 견디지 못하고 리셋되거나, 팬 속도가 100%로 회전해도 방열이 안 되는 이슈를 체크합니다.

Phase 2 완료 판정 체크리스트 (Go/No-Go Criteria)

점검 항목	통과 기준 (Pass Criteria)	실패 시 원인 및 조치
드라이버 & Fabric Manager	`nvidia-smi` 인식 정상, Fabric Manager `Active (running)`	버전 불일치 확인 후 재설치
NVLink / P2P 대역폭	모든 GPU 간 에러 0건, 스펙 대역폭 달성	NVSwitch 보드 결착 점검 / 드라이버 재적재
DCGM Level 3 진단	전체 테스트 항목 PASS, ECC Uncorrectable 0건	불량 GPU RMA 요청
gpu-burn (1시간)	연산 에러(`Faulty: 0`) 0건, 서버 리셋/전원 꺼짐 없음	PSU 용량 부족 또는 전원 레일 결함 점검
써멀 및 쿨링	풀 로드 상태에서 최대 동작 온도 이하 유지 (클록 강하 없음)	섀시 팬 불량, 써멀 구리스/방열판 밀착 불량

위 테스트를 통과하면 GPU 하드웨어와 기본 런타임의 신뢰성은 확보된 것이므로, 다음 단계인 Phase 3 (vLLM 설치 및 Compute Cluster 호출 연동)으로 진입하시면 됩니다.

===

Phase 3의 핵심 목표는 vLLM 서빙 환경을 안정적으로 구성하고, 아직 사설망(E810)이 개통되지 않은 과도기 상황에서 기존 Compute 클러스터 노드들과의 네트워크 통신 경로를 확보하여 실제 추론 API 호출 파이프라인을 검증하는 것입니다.

Step 1. 네트워크 통신 경로 확보 (사설망 개통 전 우회 전략)

Compute 클러스터(외부망 + 내부망 bond1 보유)와 GPU 노드(현재 외부망 ConnectX-6만 활성화) 간 통신을 위해 가장 현실적인 방식을 먼저 결정하고 경로를 엽니다.

방안 A (외부망 L3 통신 - 가장 권장)
Compute 클러스터 노드들의 외부망 인터페이스 IP $\leftrightarrow$ GPU 노드의 ConnectX-6 외부망 IP 간 통신.
사전 확인: 데이터센터/망 내부 방화벽(L4/ACL)에서 Compute 클러스터 외부 IP $\rightarrow$ GPU 노드 ConnectX-6 IP의 vLLM 포트(예: 8000) 인바운드 허용.

비대칭 라우팅(Asymmetric Routing) 방지 점검
향후 내부망(E810) 연결 준비 및 다중 NIC 환경에서 패킷 드랍을 방지하기 위해 커널 필터를 조정해 둡니다.

# 인입된 인터페이스와 나가는 인터페이스 불일치 시 드랍 방지 (Loose Reverse Path Filter)
sysctl -w net.ipv4.conf.all.rp_filter=2
sysctl -w net.ipv4.conf.default.rp_filter=2

L3/L4 도달 가능성(Reachability) 사전 검증
Compute 클러스터 워커 노드 중 1대에서 GPU 노드로 기본 통신 확인:

ping -c 3 <GPU_NODE_CX6_IP>
# 포트 오픈 여부 (임시 nc/python 서버 등으로 포트 열고 확인)
nc -zv <GPU_NODE_CX6_IP> 8000

Step 2. 로컬 NVMe 캐시 구성 및 모델 가중치 사전 배치

Phase 4(Storage 클러스터 연동) 전이므로, 검증용 모델을 GPU 노드의 로컬 고속 NVMe 디스크에 먼저 배치합니다.

로컬 고속 NVMe 마운트 경로 준비

mkdir -p /data/models /data/hf_home
export HF_HOME=/data/hf_home

테스트용 모델 다운로드 (외부망 ConnectX-6 활용)

파이프라인 검증용 경량 모델 1종과 멀티 GPU/텐서 병렬화(TP) 검증용 표준 LLM 1종을 준비합니다.
기능 검증용: meta-llama/Llama-3.1-8B-Instruct (단일 GPU TP=1)
토폴로지/TP 검증용: meta-llama/Llama-3.1-70B-Instruct 또는 Qwen2.5-72B-Instruct (8-GPU TP=8)

# huggingface-cli 이용 다운로드 (외부망 Direct)
huggingface-cli download meta-llama/Llama-3.1-8B-Instruct \
    --local-dir /data/models/Llama-3.1-8B-Instruct \
    --local-dir-use-symlinks False

Step 3. vLLM 엔진 구동 및 GPU 서빙 튜닝

vLLM을 공식 컨테이너 기반으로 기동하여 호스트 종속성을 최소화하고, 안정적인 서빙 옵션을 적용합니다.

vLLM 컨테이너 기동 (단일 GPU 기능 테스트: 8B 모델)

docker run -d --name vllm-test \
    --runtime nvidia \
    --gpus '"device=0"' \
    -v /data/models:/models \
    -p 8000:8000 \
    --ipc=host \
    --restart unless-stopped \
    vllm/vllm-openai:latest \
    --model /models/Llama-3.1-8B-Instruct \
    --served-model-name llama-3.1-8b \
    --port 8000 \
    --max-model-len 8192 \
    --gpu-memory-utilization 0.90 \
    --enforce-eager

주요 옵션 체크:
--ipc=host: 파이토치 및 vLLM 내부 공유 메모리(Shared Memory) 부족 에러(OOM/Crash) 방지.
--enforce-eager: 초기 테스트 시 CUDA Graph 컴파일 오버헤드를 배제하고 즉각적인 서빙 및 메모리 할당 검증.

vLLM 컨테이너 기동 (멀티 GPU Tensor Parallel 테스트: 70B 모델)

8-GPU 풀 노드 활용 시:

docker run -d --name vllm-tp-test \
    --runtime nvidia \
    --gpus all \
    -v /data/models:/models \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model /models/Llama-3.1-70B-Instruct \
    --served-model-name llama-3.1-70b \
    --tensor-parallel-size 8 \
    --gpu-memory-utilization 0.90 \
    --max-model-len 8192

컨테이너 로그(docker logs -f vllm-tp-test)에서 8개 rank의 NCCL 초기화 및 Weight Loading 완료 메시지 확인.

Step 4. 로컬 및 Compute Cluster 연동 검증

GPU 노드 로컬(Localhost) 루프백 테스트

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama-3.1-8b",
    "messages": [{"role": "user", "content": "Ping test"}],
    "max_tokens": 30
  }'

정상 JSON 응답 및 usage.total_tokens 반환 여부 확인.

Compute Cluster 워커 노드/Bastion에서의 원격 호출 테스트

Compute 클러스터 노드 셸에서 GPU 노드 외부망 IP로 직접 요청을 전송합니다.

curl -X POST http://<GPU_NODE_CX6_IP>:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama-3.1-8b",
    "messages": [{"role": "user", "content": "Explain Kubernetes pods in 2 sentences."}],
    "max_tokens": 100,
    "temperature": 0.7
  }'

응답 시간(Latency), HTTP 200 수신, 스트리밍("stream": true) 모드 시 Chunk 수신 정상 여부 점검.

Compute Cluster K8s Pod 기반 연동 테스트

추후 애플리케이션 서비스가 K8s 파드 형태로 배포되므로, Compute 클러스터의 Pod 내부에서 GPU 노드로 나가는 Egress 트래픽을 검증합니다.

apiVersion: v1
kind: Pod
metadata:
  name: vllm-client-test
  namespace: default
spec:
  containers:
  - name: curl-client
    image: curlimages/curl:latest
    command: ["sleep", "3600"]

Pod 진입 후 호출:

kubectl exec -it vllm-client-test -- curl http://<GPU_NODE_CX6_IP>:8000/v1/models

체크 포인트: K8s Calico/Cilium 등의 CNI Egress NAT(IP 마스커레이딩)를 타고 나갈 때 외부 방화벽에서 차단되지 않는지 확인.

Step 5. 기본 동시성 및 리소스 모니터링 검증

Phase 5(본격 성능 테스트)로 넘어가기 전, Compute 노드에서 단시간 경량 동시 호출을 날려 vLLM의 PagedAttention 및 큐잉 동작을 확인합니다.

동시 5~10 req 테스트 (Python / Shell)

for i in {1..10}; do
  curl -s http://<GPU_NODE_CX6_IP>:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "llama-3.1-8b", "messages": [{"role": "user", "content": "Count from 1 to 50"}], "max_tokens": 100}' &
done; wait

동시 모니터링:
GPU 노드에서 nvidia-smi를 통해 VRAM 사용률 고정 여부(PagedAttention 블록 테이블 확보) 확인.
vLLM /metrics 엔드포인트(http://<GPU_NODE_CX6_IP>:8000/metrics)를 스크랩하여 Prometheus 메트릭(vllm:num_requests_running, vllm:num_requests_waiting) 출력 확인.

Phase 3 완료 판정 체크리스트 (Go/No-Go Criteria)

점검 항목	통과 기준 (Pass Criteria)	조치 사항 (Fail 시)
외부망 도달성	Compute 노드 $\rightarrow$ GPU 노드 8000 포트 지연 없이 통신 성공	인프라/보안팀 방화벽 정책 확인
K8s Egress 연동	Compute 클러스터 내부 Pod에서 API 호출 성공	CNI Egress NAT 대역 방화벽 등록
단일/멀티 GPU 서빙	TP=1 및 TP=8 모델 구동 시 NCCL 오류 없이 구동 완료	`nvidia-fabricmanager` 상태 및 GPU 토폴로지 재점검
스트리밍 응답	Server-Sent Events(SSE) 스트리밍 토큰 유실 없이 수신	프록시/방화벽의 HTTP 버퍼링/타임아웃 옵션 점검

이 단계가 완료되면 Compute 클러스터 애플리케이션 관점에서 GPU 노드는 서빙 가능한 상태가 되며, 이어지는 Phase 4 (Storage Cluster $\leftrightarrow$ GPU Node 연동 및 가중치 직접 로딩)로 진입할 수 있습니다.

===

Phase 4의 핵심 목표는 Storage 클러스터(S3/NFS/Ceph/AIStor 등)와 GPU 노드 간의 데이터 파이프라인을 연결하고, 수십~수백 GB에 달하는 대규모 LLM 모델 가중치를 병목 없이 초고속으로 전송·로딩할 수 있는지 검증하는 것입니다.

기존 Storage 클러스터는 내부망 bond1에 연결되어 있으므로, GPU 노드 측의 네트워크 경로 설정과 MTU 일치 작업이 선행되어야 합니다.

Step 1. 스토리지 네트워크 경로 및 L2/L3 통신 구성

사설망(E810) 정식 구성 전후 상태에 따라 스토리지와의 통신 경로를 확보합니다.

인터페이스 및 라우팅 설정

케이스 A (E810 사설망 임시/정식 개통 시 - 권장):
E810 포트에 스토리지 내부망 대역과 통신 가능한 사설 IP 할당.
스토리지 서브넷 전용 정적 라우팅(Static Route) 추가 (기본 게이트웨이는 외부망 CX-6 유지):

# 스토리지 클러스터 대역이 10.100.0.0/16 인 경우
ip route add 10.100.0.0/16 dev <E810_IFACE> proto static

케이스 B (사설망 미개통 시 - 외부망 우회):
Storage 클러스터의 외부망 인터페이스 또는 L3 라우터를 경유하여 ConnectX-6을 통해 접근하도록 방화벽 및 ACL 오픈.

MTU(Jumbo Frame) 정합성 확인

고속 스토리지 전송 환경에서는 통상 MTU 9000이 적용되어 있습니다. 경로 상의 MTU가 어긋나면 대용량 전송 중 패킷 단편화(Fragmentation) 또는 연결 드랍이 발생합니다.

# E810 인터페이스 MTU를 기존 노드 및 스토리지와 동일하게 설정 (예: 9000)
ip link set dev <E810_IFACE> mtu 9000

# Don't Fragment 플래그를 걸고 실제 점보 패킷(8972 bytes = 9000 - 28바이트 헤더) 왕복 검증
ping -M do -s 8972 <STORAGE_ENDPOINT_IP>

Step 2. 네트워크 대역폭 및 TCP 전송 계층 벤치마크

스토리지 애플리케이션 레벨로 넘어가기 전, GPU 노드 $\leftrightarrow$ Storage 노드 간 순수 네트워크 대역폭을 먼저 확인합니다.

iperf3 병렬 스트림 대역폭 실측

Storage 노드(또는 게이트웨이)를 iperf3 서버(iperf3 -s)로 두고, GPU 노드에서 8~16개 멀티 스트림으로 테스트:

iperf3 -c <STORAGE_IP> -P 8 -t 30 -O 3

확인 기준: NIC 링크 스펙(예: 25G, 100G)에 근접한 유효 전송 속도(Line Rate의 85~95% 이상) 달성 여부 및 재전송(Retr) 횟수 0에 수렴하는지 확인.

커널 TCP 버퍼 튜닝 점검 (필요시)

고속 네트워크에서 단일 TCP 세션의 윈도우 크기 한계로 속도가 저하되지 않도록 조정:

sysctl -w net.core.rmem_max=67108864
sysctl -w net.core.wmem_max=67108864
sysctl -w net.ipv4.tcp_rmem="4096 87380 33554432"
sysctl -w net.ipv4.tcp_wmem="4096 65536 33554432"

Step 3. 스토리지 프로토콜별 I/O 벤치마크 (S3 API vs POSIX/NFS)

스토리지 구성 방식(오브젝트 스토리지 S3 API 또는 공유 파일시스템 NFS/CephFS)에 맞춰 실측 테스트를 수행합니다.

Option A. S3 오브젝트 스토리지 환경인 경우

LLM 모델 가중치는 Safetensors 파일(수 GB ~ 수십 GB 크기의 단일 오브젝트 수십 개) 형태로 구성되므로, 멀티파트 동시 읽기(Multipart Concurrent Read) 성능이 핵심입니다.

S3 벤치마크 툴 (warp 또는 s3-benchmark) 실행

MinIO Warp 또는 s3-benchmark를 활용하여 대용량 객체 Get Throughput 측정:

# 예: 10GB 오브젝트 기준 동시 Get Throughput 측정 (Warp 활용 예시)
warp get --host=<S3_ENDPOINT> --access-key=<KEY> --secret-key=<SECRET> \
    --bucket=model-weights --obj.size=10GiB --concurrent=8 --duration=1m

실제 모델 체크포인트 풀 다운로드 시간 측정

70B 파라미터 모델(약 140GB 가중치)을 고속 S3 CLI(aws s3 cp with multi-threading, 또는 s3cmd, mc)로 로컬 NVMe에 다운로드:

# 멀티스레드 다운로드 설정 후 시간 측정
time aws s3 cp s3://model-weights/Llama-3.1-70B-Instruct/ /data/models/Llama-3.1-70B-Instruct/ \
    --recursive --endpoint-url http://<STORAGE_S3_ENDPOINT>

기대 속도: 100Gbps 망 기준 140GB 모델이 약 15~25초 내에 다운로드 완료되는지 확인 (디스크 쓰기 병목 및 네트워크 대역폭 포화 수준 확인).

Option B. 네트워크 파일시스템(NFS / Shared POSIX) 환경인 경우

스토리지 볼륨을 GPU 노드에 직접 마운트하여 사용할 경우입니다.

마운트 옵션 최적화

# NFS v4.2, rsize/wsize 1M, TCP 옵션 적용
mount -t nfs -o vers=4.2,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noatime <STORAGE_IP>:/models /mnt/models

FIO Direct I/O 순차 읽기 벤치마크

모델 로딩 동작을 모사한 1MB 블록 순차 읽기(Sequential Read):

fio --name=storage_seq_read \
    --directory=/mnt/models \
    --rw=read \
    --bs=1M \
    --size=50G \
    --numjobs=8 \
    --iodepth=16 \
    --ioengine=libaio \
    --direct=1 \
    --group_reporting

Step 4. vLLM 모델 직접 로딩 및 Cold-Start 검증

실제 스토리지에 적재된 대형 모델 가중치를 기반으로 vLLM 엔진이 기동되는 전체 파이프라인(Cold Start)을 검증합니다.

NFS/공유 스토리지 Direct Mount 로딩 테스트

스토리지를 직접 컨테이너에 마운트하여 vLLM을 기동하고, 엔진 초기화 시간 및 가중치 읽기 속도를 측정합니다.

time docker run --rm \
    --runtime nvidia \
    --gpus all \
    -v /mnt/models:/models \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model /models/Llama-3.1-70B-Instruct \
    --tensor-parallel-size 8 \
    --enforce-eager

체크 포인트: 모델 로드 중 네트워크 버퍼 지연으로 인한 NCCL Timeout (NCCL_ASYNC_ERROR_HANDLING=1, Timeout 30분 기본값) 발생 여부 점검.

S3 동기화 방식(Local Cache Sync) 로딩 테스트

스토리지가 S3인 경우: 컨테이너 기동 전 Init 스크립트가 S3에서 로컬 고속 NVMe(/data/models)로 동기화한 뒤 vLLM을 올리는 패턴 검증.
첫 기동(Cold Start) 시간 vs 이후 로컬 캐시 히트(Warm Start) 기동 시간 비교 분석.

Phase 4 완료 판정 체크리스트 (Go/No-Go Criteria)

점검 항목	통과 기준 (Pass Criteria)	조치 사항 (Fail 시)
L2/L3 도달성 & MTU	`ping -M do -s 8972` 무손실 통과	스위치 포트 및 인터페이스 MTU 9000 재구성
원시 전송 대역폭 (iperf3)	E810 링크 스펙의 85% 이상 대역폭 확보	TCP 윈도우 튜닝 및 인터페이스 링 버퍼(`ethtool -G`) 점검
I/O 처리량 (FIO / S3)	로컬 NVMe 쓰기 한계치 또는 스토리지 링크 한계치 도달	스토리지 노드 I/O 병목 또는 멀티파트 세션 수 증설
vLLM Cold Start	70B 모델 기준 1분~2분 이내 Weight Load 완료 후 Serving 준비 완료	로딩 전략 변경 (직접 마운트 $\rightarrow$ 로컬 NVMe 캐싱)

===

Phase 5는 vLLM 서빙 엔진의 실무 한계치(Saturation Point)와 서비스 수준 목표(SLO)를 도출하고, 실제 다중 사용자 워크로드가 Compute 클러스터에서 유입될 때의 처리량(Throughput), 지연 시간(TTFT/ITL), 동시성(Concurrency), 리소스 병목을 정량화하는 단계입니다.

에어갭 환경이므로 외부 네트워크 의존 없이 내부 데이터셋과 오프라인 벤치마크 도구를 활용해 4개 하위 단계로 진행합니다.

1. 테스트 환경 및 핵심 측정 메트릭 정의

LLM 서빙 성능 평가는 일반 HTTP 처리량과 달리 토큰 생성 특성을 반영한 4대 핵심 지표를 측정합니다.

TTFT (Time To First Token): 첫 번째 출력 토큰이 반환되기까지 걸리는 시간 (Prompt Prefill 단계의 지연시간, 체감 반응속도 결정).
ITL (Inter-Token Latency) / TPOT (Time Per Output Token): 첫 토큰 이후 후속 토큰이 생성되는 간격 (Decoding 단계 속도, 초당 생성 토큰 수와 직결).
Throughput (Tokens/sec):
Input/Prompt Throughput: 초당 처리한 입력 토큰 수.
Output/Generation Throughput: 초당 생성한 출력 토큰 수.

GPU 리소스 포화도: VRAM 블록 점유율, KV Cache 사용률, SM 연산 포화도, 전력 스로틀링 유무.

2. 워크로드 시나리오 설계 (트래픽 프로파일)

실제 엔터프라이즈 업무 환경을 반영하여 3가지 대표 시나리오를 구성합니다.

시나리오	입력 토큰 (Input)	출력 토큰 (Output)	대표 업무 유형	성능 특징
A. 대화형 챗봇 (Interactive)	~512	~256	질의응답, 에이전트 대화	ITL(TPOT) 중심 검증, 동시 세션 처리
B. RAG / 문서 요약 (Heavy Prefill)	~4,096	~512	문서 검색 후 요약, 로그 분석	Prefill 병목, TTFT 및 KV Cache 압박
C. 코드 생성 / 장문 생성 (Heavy Decode)	~1,024	~2,048	코드 생성, 리포트 작성	Decode 병목, Throughput 및 VRAM 대역폭 포화

3. 단계별 벤치마크 실행 절차

Step 5-1. 엔진 자체 서빙 벤치마크 (vLLM Internal Benchmark)

Compute 클러스터 트래픽 유입 전, GPU 노드 로컬에서 vLLM 내장 도구(benchmark_serving.py)를 이용해 엔진 본연의 베이스라인 성능을 측정합니다.

오프라인 데이터셋 준비 (ShareGPT 기반):
에어갭 내부 Bastion에 사전 반입된 ShareGPT_V3_unfiltered_cleaned_split.json 활용.
실행 명령 (동시 동적 요청 주입: RPS 스위프):

# vLLM 컨테이너 내부 또는 Python 가상환경에서 실행
python3 -m vllm.entrypoints.openai.benchmark_serving \
    --backend vllm \
    --model /models/Llama-3.1-70B-Instruct \
    --dataset-name sharegpt \
    --dataset-path /data/benchmarks/ShareGPT_V3_unfiltered_cleaned_split.json \
    --num-prompts 1000 \
    --request-rate 10 \
    --max-concurrency 64 \
    --save-result \
    --result-filename /tmp/vllm_result_tp8_concur64.json

Step 5-2. Compute Cluster 발(發) 분산 부하 테스트 (Concurrency Test)

실제 운영 환경을 모사하여 Compute 클러스터의 여러 워커 노드/Pod에서 GPU 노드로 동시 요청을 부하시킵니다.

부하 도구: locust (분산 모드) 또는 k6 컨테이너를 Compute 클러스터의 Pod 4~8개로 분산 배포.
부하 단계별 Concurrency 계단식 증가 (Ramp-up):
단계 1 (Cold-up): Concurrency = 1, 4, 8 (기저 Latency 및 단일 요청 기준 성능 측정)
단계 2 (Normal Load): Concurrency = 16, 32, 64 (정상 운영 목표 부하 구간)
단계 3 (Stress & Saturation): Concurrency = 128, 256 (큐잉 발생 시점 및 KV Cache 포화 한계치 파악)

K6 분산 부하 스크립트 예시 (vllm_load.js):

import http from 'k6/http';
import { check } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 16 },
    { duration: '3m', target: 64 },
    { duration: '3m', target: 128 },
    { duration: '2m', target: 0 },
  ],
};

export default function () {
  const payload = JSON.stringify({
    model: 'llama-3.1-70b',
    messages: [{ role: 'user', content: 'Explain distributed data lakehouse architecture in detail.' }],
    max_tokens: 512,
    stream: false
  });

  const params = { headers: { 'Content-Type': 'application/json' }, timeout: '60s' };
  const res = http.post('http://<GPU_NODE_IP>:8000/v1/chat/completions', payload, params);
  check(res, { 'status is 200': (r) => r.status === 200 });
}

Step 5-3. 스트리밍(SSE) 및 TTFT 정밀 검증 (Python 비동기 클라이언트)

사용자 UI 연동 시 체감 성능인 TTFT를 정확히 추출하기 위해 스트리밍 청크 단위 타임스탬프를 기록합니다.

# benchmark_ttft.py (Compute Cluster의 Pod/Bastion에서 실행)
import asyncio, time, httpx

API_URL = "http://<GPU_NODE_IP>:8000/v1/chat/completions"
CONCURRENCY = 32

async def send_streaming_request(client, prompt_id):
    payload = {
        "model": "llama-3.1-70b",
        "messages": [{"role": "user", "content": "Tell me a comprehensive history of computing."}],
        "max_tokens": 256,
        "stream": True
    }
    t0 = time.perf_counter()
    first_token_time = None
    total_tokens = 0
    
    async with client.stream("POST", API_URL, json=payload, timeout=60.0) as resp:
        async for chunk in resp.aiter_lines():
            if chunk.startswith("data: ") and not chunk.endswith("[DONE]"):
                if first_token_time is None:
                    first_token_time = time.perf_counter()
                total_tokens += 1
                
    end_time = time.perf_counter()
    ttft = (first_token_time - t0) * 1000 if first_token_time else 0
    tpot = ((end_time - first_token_time) / total_tokens * 1000) if total_tokens > 0 else 0
    return {"ttft": ttft, "tpot": tpot, "tokens": total_tokens}

async def main():
    limits = httpx.Limits(max_connections=100, max_keepalive_connections=50)
    async with httpx.AsyncClient(limits=limits) as client:
        tasks = [send_streaming_request(client, i) for i in range(CONCURRENCY)]
        results = await asyncio.gather(*tasks)
    
    avg_ttft = sum(r["ttft"] for r in results) / len(results)
    avg_tpot = sum(r["tpot"] for r in results) / len(results)
    print(f"[Concurrency {CONCURRENCY}] Avg TTFT: {avg_ttft:.2f} ms | Avg TPOT (ITL): {avg_tpot:.2f} ms")

asyncio.run(main())

4. 동시 인프라 관제 및 모니터링 수집 항목

부하 인가 중 GPU 노드에서 아래 지표들을 1~2초 주기로 수집하여 병목 원인을 규명합니다.

vLLM 내부 큐 및 캐시 메트릭 (http://<GPU_NODE_IP>:8000/metrics)
vllm:num_requests_running: 동시 처리 중인 요청 수 (배치 크기).
vllm:num_requests_waiting: 대기 큐(Queue)에 쌓인 요청 수 (0보다 크면 서빙 용량 포화).
vllm:gpu_cache_usage_factor: GPU KV Cache 메모리 점유율 (1.0 도달 시 요청 선점/Preemption 또는 큐잉 발생).

NVIDIA DCGM / GPU 메트릭
DCGM_FI_DEV_GPU_UTIL: GPU SM 사용률 (Compute 병목 여부).
DCGM_FI_DEV_MEM_COPY_UTIL: HBM/VRAM 메모리 대역폭 활용률 (LLM Decoding 시 주된 병목 지점).
DCGM_FI_DEV_POWER_USAGE: TDP 대비 실제 소비 전력 (스로틀링 검증).

5. Phase 5 완료 판정 기준 및 SLO 도출 (Acceptance Criteria)

평가 항목	목표 성능 지표 (70B 모델, 8-GPU TP=8 기준 예시)	이상 징후 발생 시 점검 사항
TTFT (Latency)	P95 기준 < 1.5초 (입력 1k 토큰 기준)	`--gpu-memory-utilization` 상향, Chunked Prefill 활성화 여부 점검
ITL / TPOT	평균 < 30ms/token (초당 30 token 이상 생성 체감)	KV Cache 스왑 발생 여부, Tensor Parallel 통신 지연(NVLink) 점검
동시성 처리	동시 32개 세션 인가 시 에러율(5xx/Timeout) 0%	vLLM `--max-num-seqs` 조정 및 Compute 노드 HTTP Timeout 설정 검토
안정성 (VRAM)	Concurrency 포화 상태에서도 OOM 크래시 없이 대기 큐 정상 소화	`--max-model-len` 및 PagedAttention 블록 크기 최적화

위 기준을 바탕으로 얻은 최종 Throughput-Latency 커브 데이터를 토대로 Compute 클러스터의 API 게이트웨이 및 HPA(또는 Rate Limiting) 임계값을 설정하시면 전체 노드 도입 및 서비스 연동 절차가 완료됩니다.

Young-Kyoo Kim

engineer

이전 포스트

26S03d

다음 포스트