26S21b

QK·2026년 9월 21일

좋습니다. RHEL 10.2 bare-metal 환경 기준으로, 지금까지 만든 스크립트들(Stage1~4)을 실제로 돌리기 위한 사용 설명서를 만들겠습니다. 5단계(클러스터 연동)는 말씀하신 대로 범위에서 제외하고 마지막에 예고만 남기겠습니다.

RHEL10 관련 최신 설치 경로를 확인하고 반영하겠습니다.RHEL 10.2 bare-metal 기준 사용 설명서를 만들었습니다. 핵심 구성은 이렇습니다.

  • 0~1절: 공통 사전 준비 — 서브스크립션/레포 등록, Blackwell 필수인 Open Kernel Module 드라이버 + NVSwitch Fabric Manager 설치, DCGM, Docker CE(+NVIDIA Container Toolkit), NGC 로그인까지 RHEL10 dnf 기준으로 정리
  • 2~5절: Stage1~4를 각각 "추가 설치 패키지 → 빌드/준비 → 실행 명령 → 결과 확인 포인트" 순서로 정리
  • 3.2절: 말씀하신 대로 클러스터 연동은 2단계로 미루되, Stage2의 네트워크/MinIO 테스트는 상대 노드가 최소한 필요하다는 점을 짚고, 원격 대상이 아직 없으면 로컬 NVMe(C섹션)만 먼저 돌리는 우회 경로를 안내했습니다
  • 6절: Stage5(클러스터 연동)는 의도적으로 상세 내용 없이 "추후 진행 예정"으로만 남겨뒀습니다
  • 7절: 지난번 gpu_burn DIED 사례를 일반화한 공통 트러블슈팅 표
  • 8절: 전체 실행 순서 요약

RHEL10용 정확한 드라이버 브랜치명(nvidia-driver:<branch>-open, nvlink-<branch>)과 Docker CE 레포 지원 여부는 문서에 캐치업 필요 주석을 남겨뒀으니, 실제 설치 직전에 NVIDIA 데이터센터 드라이버 릴리즈 노트로 한 번 더 확인하시는 걸 권합니다.

==

B300 8-GPU 노드 Bare-Metal 검증 사용 설명서 (RHEL 10.2)

범위: 이 문서는 Stage1(HW)~Stage4(학습) — 즉 단일 노드 bare-metal 검증만 다룹니다.
Stage5(기존 MinIO/Spark/Airflow 클러스터 연동, LiteLLM Gateway 방화벽 등)는
연동 테스트 2단계에서 별도 문서로 진행합니다. 이번 라운드에서는 설치/실행하지 않습니다.

0. 사전 확인 사항

cat /etc/redhat-release        # Red Hat Enterprise Linux 10.2 확인
uname -r                        # 커널 버전 확인 (드라이버 DKMS 빌드에 필요)
subscription-manager status     # 서브스크립션 등록 상태 확인

RHEL은 root 서브스크립션이 등록되어 있어야 AppStream/BaseOS/CodeReady Builder 레포를
열 수 있습니다. 미등록 상태면 subscription-manager register부터 먼저 진행하세요.

1. 공통 사전 준비 (전체 단계 공통, 최초 1회)

1.1 레포지토리 등록

# RHEL 기본 레포 활성화
sudo subscription-manager repos --enable=rhel-10-for-x86_64-appstream-rpms
sudo subscription-manager repos --enable=rhel-10-for-x86_64-baseos-rpms
sudo subscription-manager repos --enable=codeready-builder-for-rhel-10-x86_64-rpms

# EPEL (nvme-cli, sysstat 등 일부 패키지가 여기 있음)
sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-10.noarch.rpm

# dnf config-manager 플러그인 (아래 레포 추가에 필요)
sudo dnf install -y dnf-plugins-core

# NVIDIA CUDA 레포 (드라이버 + CUDA Toolkit)
sudo dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/rhel10/x86_64/cuda-rhel10.repo
sudo dnf clean all

1.2 커널 헤더 및 NVIDIA 드라이버 설치 (Blackwell 필수: Open Kernel Module)

B300(Blackwell/Blackwell Ultra)은 반드시 Open Kernel Module 드라이버를 써야 하며,
NVSwitch 8-GPU 구성이므로 Fabric Manager(nvlink 패키지)도 함께 설치해야 합니다.

sudo dnf install -y kernel-headers-$(uname -r) kernel-devel-$(uname -r)

# CUDA Toolkit 설치
sudo dnf install -y cuda-toolkit

# Blackwell(4세대 NVSwitch) 전용: -open 드라이버 + nvlink 패키지
sudo dnf module install -y nvidia-driver:open-dkms      # 배포판에 따라 nvidia-driver:<branch>-open 형태일 수 있음
sudo dnf install -y nvlink-fabricmanager                # 실제 패키지명은 드라이버 버전에 따라 nvlink-<branch> 형태

sudo systemctl enable --now nvidia-persistenced
sudo systemctl enable --now nvidia-fabricmanager

sudo reboot

재부팅 후 확인:

nvidia-smi                       # 8장 인식 확인
nvidia-smi -q -d COMPUTE          # Compute Capability 확인
nvcc --version                    # CUDA 버전 확인 (12.8+ 권장, Blackwell Ultra 정식 지원 버전)

주의: 정확한 드라이버 브랜치/패키지명(nvidia-driver:<branch>-open, nvlink-<branch>)은
B300 조달 시점의 최신 데이터센터 드라이버 릴리즈 노트를 반드시 재확인하세요. 버전이 안 맞으면
드라이버 로딩 자체는 되어도 XID 에러나 커널 미지원(지난번 gpu_burn DIED 원인 중 하나)으로 이어집니다.

1.3 DCGM (진단 도구) 설치

sudo dnf install -y datacenter-gpu-manager
sudo systemctl enable --now nvidia-dcgm

1.4 컨테이너 런타임 (Stage3의 Triton/TRT-LLM에 필요)

RHEL10은 Podman이 기본이지만, 이번 스크립트들은 docker run 기준으로 작성되어 있어
Docker CE를 별도 설치합니다.

sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo systemctl enable --now docker

RHEL10용 docker-ce 레포가 아직 없다고 나오면 RHEL9(rhel/9) 경로로 임시 대체 가능한 경우가
많지만, 정식 지원 여부는 Docker 공식 문서로 재확인하세요. Docker 대신 Podman + CDI로
대체하려면 아래처럼 NVIDIA Container Toolkit만 설치하고 스크립트의 docker run --gpus all을
podman run --device nvidia.com/gpu=all로 바꿔야 합니다.

NVIDIA Container Toolkit (Docker/Podman 공통):

curl -s -L https://nvidia.github.io/libnvidia-container/stable/rpm/nvidia-container-toolkit.repo | \
  sudo tee /etc/yum.repos.d/nvidia-container-toolkit.repo
sudo dnf install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# 확인
docker run --rm --gpus all nvidia/cuda:12.8.0-base-ubi9 nvidia-smi

1.5 NGC 로그인 (Stage3b Triton 이미지 pull용)

docker login nvcr.io
# Username: $oauthtoken
# Password: <NGC API Key>

1.6 공용 로그 디렉터리

sudo mkdir -p /var/log/b300_validation /mnt/local-nvme-cache
sudo chown -R $(whoami) /var/log/b300_validation /mnt/local-nvme-cache

1.7 스크립트 배치

전달받은 스크립트 전체를 한 디렉터리에 모아두고 실행 권한을 부여합니다.

mkdir -p ~/b300-validation && cd ~/b300-validation
# (모든 stage*.sh, stage*.py, ds_config*.json, 00_PREREQUISITES.md, README.md 복사)
chmod +x stage*.sh

2. Stage 1 — 하드웨어 무결성 검증

2.1 추가 설치 패키지

sudo dnf install -y gcc gcc-c++ make git numactl pciutils

2.2 gpu-burn / nccl-tests 빌드

git clone https://github.com/wilicc/gpu-burn.git /tmp/gpu-burn
cd /tmp/gpu-burn && make && sudo cp gpu_burn /usr/local/bin/

git clone https://github.com/NVIDIA/nccl-tests.git /tmp/nccl-tests
cd /tmp/nccl-tests && make CUDA_HOME=/usr/local/cuda MPI=0

gpu-burn의 Makefile에 B300 Compute Capability(sm_100/103 등)가 -gencode에 빠져있으면
지난번처럼 DIED가 발생합니다. nvidia-smi --query-gpu=compute_cap --format=csv로 확인한
값이 Makefile의 gencode 목록에 있는지 미리 대조하세요.

2.3 FP8/FP4 스트레스용 PyTorch 설치

python3 -m venv ~/hw-check-env
source ~/hw-check-env/bin/activate
pip install torch --index-url https://download.pytorch.org/whl/cu128   # CUDA 버전에 맞게 조정

2.4 실행

cd ~/b300-validation
source ~/hw-check-env/bin/activate
sudo -E ./stage1_hw_validation.sh
# 장기 소크 테스트가 필요하면:
SOAK_SECONDS=14400 sudo -E ./stage1_hw_validation.sh   # 4시간

sudo -E로 실행해야 가상환경(PATH) 값이 sudo 이후에도 유지됩니다.

2.5 결과 확인 포인트

  • 01_gpu_summary.txt — 8장 전부 인식됐는지
  • 02_pcie_warnings.txt — 비어있어야 정상 (Max=Current)
  • 03_nvlink_status.txt, 03_nvlink_errors.txt — 전부 NV# 연결, 에러 카운트 0
  • 05_xid_before.txt vs 10_xid_after.txt — diff 결과로 스크립트가 자동 경고
  • 06_dcgm_diag_r3.txt(또는 r4) — 전 컴포넌트 Pass
  • 08_fp8_fp4_stress.log — 8장 모두 approx_TFLOPS 출력됐는지
  • 09_gpu_burn.log, 10_throttling_detected.txt — DIED 없이 완주, 쓰로틀 플래그 없음

3. Stage 2 — 네트워크 & 스토리지 심층 검증

3.1 추가 설치 패키지

sudo dnf install -y iperf3 fio jq ethtool sysstat nvme-cli
sudo dnf install -y mstflint infiniband-diags || true   # Mellanox 진단 도구, 미지원 시 스킵

# MinIO warp / mc
curl -LO https://github.com/minio/warp/releases/latest/download/warp_Linux_x86_64.tar.gz
tar -xvf warp_Linux_x86_64.tar.gz && sudo mv warp /usr/local/bin/
curl -LO https://dl.min.io/client/mc/release/linux-amd64/mc
chmod +x mc && sudo mv mc /usr/local/bin/

3.2 네트워크/스토리지 대상(Peer) 준비 — 중요

말씀하신 대로 기존 클러스터 연동은 2단계에서 진행하지만, Stage2의 A/B 섹션(iperf3,
MinIO 벤치마크)은 통신 상대(iperf3 서버, MinIO 엔드포인트)가 최소한 테스트용으로라도
붙어있어야 결과가 나옵니다. 이번 라운드에서 상대 노드가 전혀 준비 안 됐다면:

  • C섹션(로컬 NVMe 심층: SLC소진/발열/SMART)은 지금 바로 실행 가능 — 원격 의존성 없음
  • A/B섹션(네트워크/MinIO)은 iperf3 서버 하나만 임시로 띄워도 됩니다 (아래) — 정식 클러스터
    연동 없이도 "링크 자체의 물리적 한계치"는 미리 검증할 수 있습니다

임시 테스트 상대가 있다면 그 노드에서:

iperf3 -s -D          # iperf3 서버 데몬 모드로 백그라운드 기동

3.3 실행

export STORAGE_NODE_IP="192.168.10.50"       # 실제 iperf3/MinIO 서버 IP로 교체
export MINIO_ENDPOINT="http://192.168.10.50:9000"
export MINIO_ACCESS_KEY="minioadmin"
export MINIO_SECRET_KEY="minioadminpassword"
export LOCAL_CACHE_DIR="/mnt/local-nvme-cache"

sudo -E ./stage2_net_storage_validation.sh

MinIO 서버(B섹션)가 아직 없다면, A/B 관련 라인은 스크립트 주석 처리 후 C섹션(NVMe)만
먼저 돌리셔도 됩니다.

3.4 결과 확인 포인트

  • A2_iperf_single.json vs A2_iperf_multi.json — 단일 스트림 ~25Gbps, 멀티(x8) ~45,000Mbps 근접
  • A4_nic_phy_stats.txt — rx_crc_errors, fec_uncorrectable_blocks = 0
  • C2_fio_sustained_write.json — 200GB 지속 쓰기 후에도 급격한 속도 하락 없는지
  • C4_nvme_smart_after.txt — media_errors = 0
  • stage2_summary.txt — 최종 요약

4. Stage 3 — 추론 서빙 벤치마크

4.1 Python 가상환경 및 공통 패키지

python3 -m venv ~/vllm-bench-env
source ~/vllm-bench-env/bin/activate
pip install --upgrade pip
pip install vllm aiohttp requests pandas tabulate matplotlib
pip install nvidia-modelopt[torch] llmcompressor      # FP8/FP4 양자화 도구
pip install "sglang[all]"                              # Stage3c(선택) 대비
pip install aiperf                                      # Stage3d

4.2 모델 준비

export HF_HOME="/mnt/local-nvme-cache/huggingface"
mkdir -p "${HF_HOME}"
huggingface-cli login --token "hf_..."     # Llama-3.1 게이트 모델 접근 토큰

디스크 용량 확인 (필수):

df -h /mnt/local-nvme-cache
# Llama-3.1-70B(bf16 ~140GB) + DeepSeek-R1(fp8 ~700GB) + Llama-3.1-8B(~16GB)
# + TRT-LLM 엔진 빌드 산출물(수십~수백GB) 감안 → 여유 1.5TB 이상 권장

4.3 Stage3a — vLLM 실행

cd ~/b300-validation
source ~/vllm-bench-env/bin/activate
sudo -E ./stage3a_vllm_benchmark.sh

DeepSeek-R1(시나리오4) 로딩에 시간이 오래 걸릴 수 있습니다. 처음엔 시나리오 1~3(70B)만
따로 떼어 돌려보고, 안정화 후 4~5번을 추가하는 것도 방법입니다.

4.4 Stage3b — Triton + TensorRT-LLM 실행

엔진 빌드는 NGC 컨테이너 내부에서:

docker run --gpus all --ipc=host --ulimit memlock=-1 --ulimit stack=67108864 \
  -v /mnt/local-nvme-cache:/mnt/local-nvme-cache \
  -p 8000:8000 -p 8001:8001 -p 8002:8002 \
  --name triton-trtllm -it nvcr.io/nvidia/tritonserver:24.08-trtllm-py3 bash

# 컨테이너 내부에서:
export MODEL_DIR="/mnt/local-nvme-cache/huggingface/.../Meta-Llama-3.1-70B-Instruct/snapshots/<HASH>"
bash stage3b_triton_trtllm_benchmark.sh

엔진 빌드 후 Triton 모델 저장소 구성 → tritonserver 기동 → 호스트(컨테이너 밖)에서:

./stage3b_genai_perf_runner.sh ensemble_bf16
# BF16 종료 후 FP8 엔진으로 Triton 재기동한 뒤
./stage3b_genai_perf_runner.sh ensemble_fp8

4.5 Stage3c — SGLang (선택)

MoE/에이전트/RAG 서빙 계획이 있을 때만:

sudo -E ./stage3c_sglang_benchmark.sh

4.6 Stage3d — AIPerf 통합 비교

3a~3c 중 기동해둔 엔진이 있는 상태에서 마지막에 실행:

sudo -E ./stage3d_aiperf_unified_benchmark.sh

4.7 결과 확인 포인트

  • vllm_report.md, sglang_report.md — TTFT/ITL/처리량 표
  • BF16 vs FP8 시나리오 비교 — FP8이 유의미하게 빠른지
  • stage3d_aiperf_* 폴더의 plots/*.png — 엔진 간 동일 조건 비교 그래프

5. Stage 4 — 분산 학습 벤치마크

5.1 패키지 설치

python3 -m venv ~/train-bench-env
source ~/train-bench-env/bin/activate
pip install --upgrade pip
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu128
pip install transformers datasets accelerate deepspeed peft s3fs boto3 tabulate pandas
pip install flash-attn --no-build-isolation

torch 버전은 2.4 이상이어야 FSDP2(fully_shard)를 쓸 수 있습니다.

5.2 실행

cd ~/b300-validation
source ~/train-bench-env/bin/activate
export MINIO_ENDPOINT="http://192.168.10.50:9000"   # 3.2절과 동일한 임시/정식 MinIO
export AWS_ACCESS_KEY_ID="minioadmin"
export AWS_SECRET_ACCESS_KEY="minioadminpassword"

sudo -E ./stage4_run_train_benchmark.sh

MinIO가 아직 없다면 오케스트레이터의 remote_s3 케이스(2번째 실행)는 주석 처리하고
local 케이스(LoRA/Full-FT/FSDP2)만 먼저 돌리셔도 Stage4의 핵심(TFLOPS/MFU, HBM 사용률)은
검증됩니다.

5.3 결과 확인 포인트 (MFU 중심)

  • stage4_training_report.md — 시나리오별 처리량 + 달성 TFLOPS/GPU + MFU(%)
  • --peak_tflops_bf16 기본값(2,250 TFLOPS/GPU)이 실제 B300 스펙시트와 맞는지 먼저 확인
  • Full-FT 시나리오의 Peak GPU Mem이 288GB에 근접하는지 (LoRA는 낮게 나오는 게 정상)
  • DeepSpeed 로그(stdout) 내 flops_profiler 출력값과 리포트의 MFU를 교차검증

6. Stage 5 — 클러스터 연동 (이번 범위 제외, 추후 진행)

stage5a_model_cold_load.sh, stage5b_distributed_load_test.py,
stage5c_checkpoint_lifecycle.sh, stage5d_co_tenancy_test.sh,
stage5e_monitoring_setup.sh는 기존 MinIO/Spark/Airflow 클러스터, LiteLLM Gateway와의
실제 연동 시점(2단계)에 별도로 안내드리겠습니다. 방화벽 규칙, LiteLLM API 키,
Prometheus/Grafana 배포 등은 그때 함께 준비하시면 됩니다.

7. 공통 트러블슈팅 체크리스트

증상우선 확인
nvidia-smi에서 GPU 일부만 인식dmesg -T \| grep -i xid, PCIe 슬롯 재장착, Fabric Manager 상태
gpu-burn 등 CUDA 커널 실행 시 즉시 실패(DIED 등)nvcc --version/드라이버 버전, Makefile -gencode에 실제 Compute Capability 포함 여부, fp8_fp4_stress.py 단독 실행으로 CUDA 자체 문제인지 구분
DCGM 진단 실패systemctl status nvidia-dcgm, 라이선스(Level 4) 필요 여부
iperf3/MinIO 결과 0 또는 실패상대 노드 iperf3/MinIO 서버 기동 여부, 방화벽, STORAGE_NODE_IP 값
vLLM/Triton/SGLang 서버 기동 실패포트 충돌(fuser -k 8000/tcp), HF 토큰/모델 접근 권한, GPU 메모리 잔여량(nvidia-smi)
DeepSpeed/FSDP2 OOMper_device_batch_size 축소, --tune_mode lora로 우선 검증 후 full 시도
Docker에서 --gpus all 인식 안 됨nvidia-ctk runtime configure --runtime=docker 후 systemctl restart docker 재확인

8. 실행 순서 요약

1. 공통 사전 준비(드라이버/CUDA/DCGM/Docker/NGC 로그인)
2. stage1_hw_validation.sh              (+ 필요시 SOAK_SECONDS 장기 소크)
3. stage2_net_storage_validation.sh     (원격 대상 없으면 C섹션만 우선)
4. stage3a_vllm_benchmark.sh
5. stage3b_triton_trtllm_benchmark.sh (컨테이너 내부) → stage3b_genai_perf_runner.sh (호스트, bf16/fp8 각 1회)
6. (선택) stage3c_sglang_benchmark.sh
7. stage3d_aiperf_unified_benchmark.sh
8. stage4_run_train_benchmark.sh
9. (2단계 진행 예정) stage5a ~ stage5e
profile
QK
engineer
이전 포스트

26S21a

다음 포스트

26S21c

0개의 댓글