26S15a

QK·2026년 9월 15일

list

./config.json
./generation_config.json
./large_file_part_aa
./LICENSE
./model-00001-of-00004.safetensors
./model-00001-of-00004.safetensors_00
./model-00001-of-00004.safetensors_01
./model-00001-of-00004.safetensors_02
./model-00002-of-00004.safetensors
./model-00002-of-00004.safetensors_00
./model-00002-of-00004.safetensors_01
./model-00002-of-00004.safetensors_02
./model-00003-of-00004.safetensors
./model-00003-of-00004.safetensors_00
./model-00003-of-00004.safetensors_01
./model-00003-of-00004.safetensors_02
./model-00004-of-00004.safetensors
./model.safetensors.index.json
./original
./original/consolidated.00.pth
./original/consolidated.00.pth_00
./original/consolidated.00.pth_01
./original/consolidated.00.pth_02
./original/consolidated.00.pth_03
./original/consolidated.00.pth_04
./original/consolidated.00.pth_05
./original/consolidated.00.pth_06
./original/consolidated.00.pth_07
./original/consolidated.00.pth_08
./original/params.json
./original/tokenizer.model
./README.md
./special_tokens_map.json
./tokenizer_config.json
./tokenizer.json
./USE_POLICY.md

순수 git 명령어(예: git clone, git checkout) 자체로는 GitHub Release Asset을 직접 다운로드할 수 없습니다.

Release Asset은 git의 소스 코드 커밋 히스토리에 포함된 개체가 아니라, GitHub 플랫폼이 별도로 호스팅하는 첨부 파일(바이너리, 압축 파일 등)이기 때문입니다.

대신 리눅스 터미널에서는 1) GitHub 공식 CLI (gh), 2) `curl, 또는 3) wget`을 사용하는 것이 표준 방식입니다.

방법 1. GitHub CLI (`gh`) 사용 (가장 추천)

GitHub 공식 터미널 도구인 gh를 사용하면 명령어가 가장 직관적이며, Private 저장소 인증도 손쉽게 처리됩니다.

# 특정 저장소의 최신 릴리스에서 특정 파일 다운로드
gh release download <태그명_또는_생략> --repo <소유자>/<저장소> --pattern "<파일명>"

# 예시: 최신 릴리스의 tar.gz 파일 다운로드
gh release download --repo cli/cli --pattern "*.tar.gz"

방법 2. `curl` 사용

Public 저장소인 경우

GitHub 릴리스의 직접 다운로드 URL을 바로 넘겨받아 다운로드합니다 (-L 플래그로 리다이렉트를 반드시 따라가야 합니다).

curl -L -O https://github.com/<소유자>/<저장소>/releases/download/<태그>/<파일명>

Private 저장소인 경우 (Personal Access Token 필요)

Private 저장소의 Asset은 브라우저 URL로 접근하면 404가 발생하므로, GitHub API를 통해 다운로드해야 합니다.

# 1. 파일의 Asset ID 확인
ASSET_ID=$(curl -s -H "Authorization: token $GITHUB_TOKEN" \
  https://api.github.com/repos/<소유자>/<저장소>/releases/tags/<태그> \
  | grep -B 2 '"name": "<파일명>"' | grep '"id":' | head -n 1 | awk '{print $2}' | tr -d ',')

# 2. application/octet-stream 헤더로 실제 바이너리 다운로드
curl -L -H "Authorization: token $GITHUB_TOKEN" \
  -H "Accept: application/octet-stream" \
  https://api.github.com/repos/<소유자>/<저장소>/releases/assets/$ASSET_ID \
  -o <저장할_파일명>

방법 3. `wget` 사용 (Public 저장소)

wget https://github.com/<소유자>/<저장소>/releases/download/<태그>/<파일명>

===

엔비디아 Blackwell 아키텍처 기반의 B300 8장(카드당 288GB HBM3e, 8장 합산 약 2.3TB VRAM) 구성은 초거대 MoE 모델이나 FP4/FP8 기반 대규모 병렬 서빙 성능을 한계까지 밀어붙이기에 최적의 인프라입니다.

8B 모델(Llama 3.1 8B)은 단일 GPU의 극히 일부 메모리(약 16GB)만 쓰기 때문에 초기 환경 동작 확인(Sanity Check)용으로 적합하며, B300 8장의 진가를 검증하려면 소형(초고동시성/Throughput 테스트) $\to$ 중형(Dense 단일 노드 스케일링) $\to$ 대형 MoE(통신 대역폭/FP4 양자화 한계 검증) 단계로 벤치마크를 확장해야 합니다.

체급별 추천 벤치마크 모델

소형 (8B ~ 14B): Throughput & TTFT 극한 테스트

Llama 3.1 8B Instruct / Qwen 2.5 14B Instruct
추천 이유: 가중치 크기가 작으므로, B300의 광대한 메모리에 거대한 KV Cache를 잡고 수백~수천 동시 동시 요청(Concurrent Requests)을 밀어 넣어 vLLM/SGLang의 스케줄러 처리량과 TTFT(Time to First Token)를 검증하기에 적합합니다.

중형 (70B ~ 72B): 표준 고성능 Dense 모델 (TP2 ~ TP8 검증)

Llama 3.3 70B Instruct (Llama 3.1 70B 대비 발전된 70B 표준)
Qwen 2.5 72B Instruct (코딩, 추론, 한국어/다국어 능력이 뛰어난 범용 고성능 모델)
추천 이유: FP16/BF16 원본 가중치로도 B300 1~2장(TP2)에 온전히 올라가며, 8장 전체에 TP=8 또는 TP=4 + DP=2(파이프라인/데이터 병렬 혼합)를 걸어 NVLink 인터커넥트 통신 오버헤드와 연산 가속 성능을 측정하기 가장 좋습니다.

대형 MoE (200B ~ 600B+): B300 8장의 VRAM과 통신망을 풀로드하는 모델

DeepSeek V3 / R1 (671B MoE, 활성 37B)
Mixtral 8x22B (총 141B, 활성 39B)
추천 이유: B300 8장이 있어야 단일 노드 안에서 제대로 돌려볼 수 있는 영역입니다. 특히 DeepSeek V3/R1은 Blackwell의 FP8/FP4 네이티브 텐서 코어 성능과 MoE All-to-All 통신 병목을 스트레스 테스트하는 데 전 세계적으로 사실상 표준 벤치마크 모델로 쓰이고 있습니다.

모델별 비교 및 B300 8장 테스트 포인트

체급	모델명	파라미터 (활성/총)	권장 병렬 구성 (B300 8장 기준)	벤치마크 핵심 검증 포인트
소형	Llama 3.1 8B	8B (Dense)	단일 GPU × 8 인스턴스 (DP8)	• 서빙 엔진(vLLM/SGLang) 기본 통신 동작 확인• 배치 사이즈 극한 확장 시 Token Throughput
소·중형	Qwen 2.5 14B	14.7B (Dense)	TP=1 or TP=2 (DP4)	• 128k 롱컨텍스트 입력 시 KV Cache 확장성 및 속도
중형	Llama 3.3 70B	70B (Dense)	TP=4 or TP=8	• BF16 원본 서빙 시 Latency 및 ITL(Inter-Token Latency)• NVLink 간 All-Reduce 통신 효율 측정
중형	Qwen 2.5 72B	72.7B (Dense)	TP=4 (DP2) or TP=8	• 실무 프로덕션급 추론/코딩 성능 및 복잡한 추론 벤치
대형	Mixtral 8x22B	39B / 141B (MoE)	TP=4 or TP=8	• MoE 라우팅 오버헤드 측정• 고속 토큰 생성(Decode) 속도 검증
초대형	DeepSeek V3/R1	37B / 671B (MoE)	FP8/FP4 기반 TP=8	• Blackwell FP4/FP8 텐서 코어 연산 한계 테스트• 메모리 대역폭(HBM3e) 포화 테스트

테스트 진행 추천 로드맵

Step 1 (초기 구동 확인): Llama-3.1-8B-Instruct

B300 드라이버, CUDA 툴킷, vLLM 컨테이너가 정상적으로 GPU를 인식하고 에러 없이 서빙되는지 확인합니다.

Step 2 (NVLink 스케일링 & 롱컨텍스트): Llama-3.3-70B-Instruct

Tensor Parallelism(TP=4, TP=8)을 바꿔가며 통신 스케일링 효율과 동시 요청 처리량을 측정합니다.

Step 3 (플래그십 MoE 스트레스 테스트): DeepSeek-V3 또는 R1 (FP8)

8장의 2.3TB VRAM을 적극적으로 활용하여 초대형 모델의 FP8/FP4 양자화 서빙과 분산 통신 한계를 벤치마크합니다.

===

B300 8장(카드당 288GB HBM3e, 노드 총합 약 2,304GB VRAM)은 671B 총 파라미터를 가진 DeepSeek-V3 / R1 (FP8)을 단일 노드 안에서 온전히 서빙하고도 거대한 KV Cache 공간을 확보할 수 있는 환경입니다.

1. 메모리 사이징 분석 (B300 8장 기준)

순수 모델 가중치 (FP8):
총 파라미터 671B $\times$ 1 Byte(FP8) $\approx$ 약 671GB ~ 700GB
TP=8로 분할 시 GPU당 약 85GB ~ 90GB 점유

활성화 및 런타임 오버헤드 (e.g. CUDA context, MoE 버퍼):
GPU당 약 10GB ~ 15GB

KV Cache 가용 메모리:
B300 1장의 가용 메모리: 288GB
모델 가중치 + 기본 오버헤드 $\approx$ 약 105GB
GPU당 순수 KV Cache 가용량: 약 170GB ~ 180GB (8장 합산 1.4TB 이상)

결론: H100 8장(80GB $\times$ 8 = 640GB) 환경에서는 단일 노드에 가중치조차 다 올라가지 않아 multi-node가 강제되었지만, B300은 단일 노드 8장만으로 128k 풀 컨텍스트 및 수백 동시 요청(Concurrent Batch)을 여유롭게 수용할 수 있습니다.

2. vLLM 실행 설정 (`vllm serve`)

DeepSeek V3/R1은 고유의 MLA(Multi-head Latent Attention)와 MoE 아키텍처를 사용하므로, vLLM 최신 버전에서 지원하는 최적화 플래그를 함께 설정해야 합니다.

vllm serve deepseek-ai/DeepSeek-V3 \
  --tensor-parallel-size 8 \
  --pipeline-parallel-size 1 \
  --dtype bfloat16 \
  --quantization fp8 \
  --kv-cache-dtype fp8 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.92 \
  --enforce-eager \
  --trust-remote-code \
  --port 8000

DeepSeek-R1 서빙 시: 모델 경로만 deepseek-ai/DeepSeek-R1로 변경하면 구조와 가중치 규격이 동일하므로 세팅은 100% 동일합니다.

3. 핵심 플래그별 가이드

--tensor-parallel-size 8
B300 8장의 NVLink 패브릭을 활용해 단일 노드 내에서 TP=8로 텐서 및 MoE 연산을 분산합니다.

--quantization fp8 & `--kv-cache-dtype fp8`
DeepSeek 공식 체크포인트는 기본적으로 FP8(W8A8)로 릴리스되어 있습니다.
KV Cache까지 FP8로 설정하면 MLA의 캐시 압축과 결합되어 동일 VRAM 대비 수용 가능한 동시 토큰 수가 약 1.8~2배 증가합니다.

--max-model-len 32768 (또는 65536 / 131072)
초기 검증 시에는 32k(32,768)로 시작하고, 롱컨텍스트 추론 성능을 확인할 때 128k(131,072)까지 늘려가며 OOM 여부와 TTFT를 측정하는 것을 권장합니다.

--enforce-eager (권장: 초기 테스트용)
671B 규모 모델은 CUDA Graph를 캡처하는 데만 수십 분이 걸리거나 메모리 스파이크로 기동 중 OOM이 발생할 수 있습니다. 초기 구동 검증 시에는 eager 모드로 먼저 정상 서빙을 확인한 뒤 필요에 따라 튜닝합니다.

--gpu-memory-utilization 0.92
288GB의 92%(약 265GB)를 vLLM에 할당하여 가중치를 얹고 남은 약 175GB를 전부 KV Cache 풀로 밀어 넣습니다.

4. B300 환경 구동 전 필수 사전 점검

Host Memory (시스템 RAM) 및 HugePages:

671GB의 모델 가중치를 디스크에서 읽어 각 GPU로 분산 로딩하는 과정에서 호스트 시스템 RAM이 최소 1TB 이상(권장 1.5TB~2TB) 확보되어 있어야 로딩 중 프로세스 kill(OOM Killer)을 피할 수 있습니다.

NVLink 대역폭 점검:

MoE 라우팅 특성상 Expert 간 All-to-All 통신량이 많습니다.
nvidia-smi nvlink -s 명령어로 8개 GPU 간 통신 링크가 정상 활성화(NVLink Link status: Up)되어 있는지 확인하세요.

vLLM 공식 벤치마크 도구인 benchmark_serving.py를 활용해 서빙 중인 DeepSeek V3(8000번 포트)의 TTFT(Time to First Token), TPOT(Time per Output Token), Throughput(토큰/요청 처리량)을 단계별로 측정하는 스크립트입니다.

1. 벤치마크 사전 준비

vLLM 공식 벤치마크 스크립트와 표준 평가용 데이터셋(ShareGPT)을 다운로드합니다.

# vLLM 벤치마크 스크립트 다운로드
wget https://raw.githubusercontent.com/vllm-project/vllm/main/benchmarks/benchmark_serving.py

# ShareGPT 데이터셋 다운로드 (실제 사용자 대화 패턴 반영)
wget https://huggingface.co/datasets/anon8231489123/ShareGPT_Vicuna_unfiltered/resolve/main/ShareGPT_V3_unfiltered_cleaned_split.json

2. 종합 성능 측정 벤치마크 스크립트 (`run_benchmark.sh`)

동시 요청 수(Concurrency)와 요청 생성률(Request Rate)을 단계별로 올려가며 성능 포화 지점을 찾는 실행 스크립트입니다.

#!/usr/bin/env bash
set -e

MODEL_NAME="deepseek-ai/DeepSeek-V3"
API_URL="http://localhost:8000"
DATASET_PATH="./ShareGPT_V3_unfiltered_cleaned_split.json"
OUTPUT_DIR="./benchmark_results"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)

mkdir -p "${OUTPUT_DIR}"

echo "=== 1. Health Check ==="
curl -s -f "${API_URL}/v1/models" > /dev/null || { echo "vLLM 서버가 응답하지 않습니다. (포트 8000 확인)"; exit 1; }
echo "vLLM 서빙 정상 확인 완료."

# ---------------------------------------------------------
# 시나리오 1: 단일 요청 Baseline 레이턴시 (TTFT 및 최소 TPOT 측정)
# ---------------------------------------------------------
echo "=== 2. Baseline Latency Test (1 Request, Concurrency=1) ==="
python3 benchmark_serving.py \
  --backend vllm \
  --base-url "${API_URL}" \
  --model "${MODEL_NAME}" \
  --dataset-name sharegpt \
  --dataset-path "${DATASET_PATH}" \
  --num-prompts 50 \
  --request-rate inf \
  --max-concurrency 1 \
  --save-result \
  --result-dir "${OUTPUT_DIR}" \
  --result-filename "baseline_latencies_${TIMESTAMP}.json"

# ---------------------------------------------------------
# 시나리오 2: 동시성 부하 테스트 (Concurrency = 8, 32, 64, 128)
# B300 8장의 KV Cache 풀로드 및 TP=8 통신 스케일링 측정
# ---------------------------------------------------------
for CONCURRENCY in 8 32 64 128; do
  echo "=== 3. Throughput Test (Concurrency: ${CONCURRENCY}) ==="
  python3 benchmark_serving.py \
    --backend vllm \
    --base-url "${API_URL}" \
    --model "${MODEL_NAME}" \
    --dataset-name sharegpt \
    --dataset-path "${DATASET_PATH}" \
    --num-prompts 500 \
    --request-rate inf \
    --max-concurrency "${CONCURRENCY}" \
    --save-result \
    --result-dir "${OUTPUT_DIR}" \
    --result-filename "concurrency_${CONCURRENCY}_${TIMESTAMP}.json"
done

# ---------------------------------------------------------
# 시나리오 3: 고정 인풋/아웃풋 길이 합성 데이터 테스트 (1k Prompt -> 512 Output)
# ---------------------------------------------------------
echo "=== 4. Synthetic Fixed-Length Test (Input: 1024, Output: 512) ==="
python3 benchmark_serving.py \
  --backend vllm \
  --base-url "${API_URL}" \
  --model "${MODEL_NAME}" \
  --dataset-name random \
  --random-input-len 1024 \
  --random-output-len 512 \
  --num-prompts 300 \
  --max-concurrency 64 \
  --save-result \
  --result-dir "${OUTPUT_DIR}" \
  --result-filename "synthetic_1k_512_${TIMESTAMP}.json"

echo "=== 모든 벤치마크 완료: ${OUTPUT_DIR} 확인 ==="

3. 결과 분석 시 핵심 확인 지표

스크립트 실행 후 출력되는 리포트에서 다음 항목들을 중점적으로 확인합니다.

TTFT (Time to First Token):
Prefill 단계의 속도입니다. Concurrency가 낮을 때는 수십~100ms 내외여야 정상이며, 동시성이 128 이상으로 급증할 때 Chunked Prefill로 인해 TTFT P99가 완만하게 증가하는지 확인합니다.

TPOT (Time per Output Token):
토큰당 생성 지연 시간입니다. 통상 사용자가 "빠르다"고 느끼는 기준은 20~40ms/token(초당 25~50 토큰) 수준입니다.

Token Throughput (Tokens/s):
Output token throughput: B300 8장의 실제 초당 생성 토큰 수입니다.
Concurrency를 8 $\to$ 32 $\to$ 64 $\to$ 128로 올릴 때 이 수치가 선형적으로 증가하다가 특정 지점에서 포화(Saturate)되는 최적 처리량 지점을 확인해야 합니다.

GPU 모니터링 병행:
벤치마크 도중 다른 터미널에서 watch -n 1 nvidia-smi를 띄워 8장 GPU의 Power Draw, Volatile GPU-Util, HBM 점유율이 균등하게 90% 이상 유지되는지 점검합니다.

B300 8장(총 약 2.3TB VRAM) 환경의 높은 HBM 대역폭과 거대한 메모리를 최적으로 활용할 수 있도록 구성한 체급별 vLLM 서빙 표준 명령어입니다.

1. Mixtral 8x22B Instruct (대형 MoE, 총 141B / 활성 39B)

8장의 B300에 TP=8로 분산 배치하여 NVLink 기반 All-to-All 통신 대역폭과 빠른 디코딩 속도를 극대화합니다.

vllm serve mistralai/Mixtral-8x22B-Instruct-v0.1 \
  --tensor-parallel-size 8 \
  --pipeline-parallel-size 1 \
  --dtype bfloat16 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90 \
  --max-num-seqs 256 \
  --port 8000

포인트: 원본 BF16 가중치(약 280GB)를 TP=8로 나누면 GPU당 약 35GB만 차지하므로, 남는 250GB 이상의 VRAM을 32k 롱컨텍스트와 대규모 동시성(KV Cache) 확보에 집중할 수 있습니다.

2. Qwen 2.5 72B Instruct (플래그십 중형 Dense, 72.7B)

Dense 모델 특성상 통신 오버헤드와 연산 속도의 균형이 뛰어난 TP=8 구성이 단일 노드 서빙에 가장 적합합니다.

vllm serve Qwen/Qwen2.5-72B-Instruct \
  --tensor-parallel-size 8 \
  --pipeline-parallel-size 1 \
  --dtype bfloat16 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90 \
  --trust-remote-code \
  --port 8000

포인트: 모델 가중치는 약 145GB(GPU당 약 18GB)를 차지합니다. 128k 컨텍스트 지원 모델이므로 긴 입력을 다룰 경우 --max-model-len 65536 또는 131072로 늘려 테스트할 수 있습니다.

3. Llama 3.3 70B Instruct (표준 고성능 Dense, 70B)

표준 70B 모델로, TP=8 단일 인스턴스로 서빙하거나 초고동시성을 위해 TP=4 인스턴스 2개(DP2)로 나누어 올릴 수 있습니다. 표준 권장인 TP=8 설정입니다.

vllm serve meta-llama/Llama-3.3-70B-Instruct \
  --tensor-parallel-size 8 \
  --pipeline-parallel-size 1 \
  --dtype bfloat16 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90 \
  --port 8000

포인트: Llama 3 계열의 GQA(Grouped Query Attention, 8 KV heads) 구조상 TP=8을 줄 때 Attention 연산이 정확하게 분할되어 최적의 All-Reduce 효율을 냅니다.

4. Qwen 2.5 14B Instruct (소·중형 Dense, 14.7B)

14B 모델은 가중치가 약 30GB에 불과하므로, 8장의 GPU를 모두 쓰려면 GPU 2장씩 묶어 TP=2로 4개 인스턴스(DP4)를 띄우거나, 단일 인스턴스 빠른 검증 시 TP=2 또는 TP=4를 사용합니다.

# 단일 인스턴스 검증 (GPU 0, 1번 사용: TP=2)
CUDA_VISIBLE_DEVICES=0,1 vllm serve Qwen/Qwen2.5-14B-Instruct \
  --tensor-parallel-size 2 \
  --dtype bfloat16 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90 \
  --trust-remote-code \
  --port 8000

포인트: B300 1장의 288GB VRAM이면 14B 모델은 TP=1로도 128k 풀 컨텍스트를 올리고 대규모 배치를 감당할 수 있습니다. Throughput 벤치마크 시에는 노드 1대에서 포트를 다르게 하여 4~8개의 독립 인스턴스를 띄우는 것이 유리합니다.

5. Llama 3.1 8B Instruct (소형 경량 Dense, 8B)

환경 세팅 검증 및 기본 파이프라인(Sanity Check)용으로, TP=1(단일 GPU) 서빙이 표준입니다.

# 단일 인스턴스 검증 (GPU 0번 사용: TP=1)
CUDA_VISIBLE_DEVICES=0 vllm serve meta-llama/Meta-Llama-3.1-8B-Instruct \
  --tensor-parallel-size 1 \
  --dtype bfloat16 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90 \
  --port 8000

포인트: 가중치가 16GB 내외이므로 B300 GPU 1장(288GB)에 올려두면 수천 개의 동시 요청 큐를 밀어 넣어도 VRAM 부족 없이 극한의 Throughput 테스트가 가능합니다.

모델별 권장 서빙 전략 요약

모델	권장 TP 구성 (B300 8장)	GPU당 가중치 점유	권장 용도
Mixtral 8x22B	TP = 8	약 35 GB	MoE 라우팅 및 NVLink 패브릭 스트레스 벤치마크
Qwen 2.5 72B	TP = 8	약 18 GB	프로덕션급 고성능 추론 및 롱컨텍스트 평가
Llama 3.3 70B	TP = 8 (또는 TP=4 $\times$ 2)	약 18 GB	표준 70B 벤치마크 및 최소 지연시간(Latency) 측정
Qwen 2.5 14B	TP = 2 $\times$ 4 인스턴스	약 15 GB	고효율 동시성 처리 및 경량 고성능 서빙
Llama 3.1 8B	TP = 1 $\times$ 8 인스턴스	약 16 GB	인프라 초기 구동 검증(Sanity Check) 및 최대 QPS 측정

B300 8장 환경에서 모델별(8B부터 671B MoE까지) 추론 성능을 객관적으로 비교하고 병목을 찾아내려면, 단계별 부하 테스트 워크플로우와 3계층(인프라-엔진-서비스) 모니터링 파이프라인을 갖춰야 합니다.

1. 모델별 성능 테스트 수행 방법 (3단계 로드맵)

모든 모델에 대해 동일한 3가지 패턴으로 부하를 주어 지표를 수집하고 비교 매트릭스를 만듭니다.

1단계: Baseline 레이턴시 측정 (Concurrency = 1)

동시 요청 없이 단일 요청만 보냈을 때 모델 본연의 생성 지연시간을 측정합니다.
목적: 최소 TTFT(Time to First Token)와 순수 Decode 속도(TPOT: Time per Output Token) 측정.

2단계: 동시성(Concurrency) 스위핑 (Concurrency = 4 $\to$ 16 $\to$ 64 $\to$ 128 $\to$ 256)

요청 수를 2배수/4배수로 늘려가며 vLLM 스케줄러와 B300 HBM이 감당하는 한계치를 측정합니다.
목적: 초당 총 생성 토큰 수(Token Throughput)가 꺾이는 포화 지점(Saturation Point) 파악.

3단계: 입력 길이(Context Length)별 스트레스 테스트 (1k, 8k, 32k, 64k)

출력 길이는 512토큰으로 고정하고, 프롬프트 입력 길이를 늘려갑니다.
목적: 긴 입력 처리 시 Prefill 연산 지연시간(TTFT 급증 여부)과 KV Cache 점유율 변화 추적.

자동화 벤치마크 실행 예시 (vLLM 내장 툴 활용)

# 모델별로 동시성을 1부터 128까지 순회하며 JSON 결과 생성
for C in 1 8 32 64 128; do
  python3 benchmark_serving.py \
    --backend vllm \
    --base-url http://localhost:8000 \
    --model <서빙중인_모델명> \
    --dataset-name sharegpt \
    --dataset-path ./ShareGPT_V3_unfiltered_cleaned_split.json \
    --num-prompts 300 \
    --max-concurrency $C \
    --save-result \
    --result-dir ./results \
    --result-filename "${MODEL_NAME}_c${C}.json"
done

2. 모니터링 구축 방안 (3계층 파이프라인)

단순히 nvidia-smi를 쳐다보는 방식으로는 NVLink 대역폭 병목이나 KV Cache 프리엠션을 잡기 어렵습니다. Prometheus + Grafana 기반의 자동화 모니터링이 표준입니다.

[B300 8장 GPU Hardware] ----> [NVIDIA DCGM Exporter :9400] \
                                                               ===> [Prometheus] ===> [Grafana Dashboard]
[vLLM Inference Engine]  ----> [vLLM Metrics Endpoint :8000] /

계층 A: GPU 하드웨어 메트릭 (NVIDIA DCGM Exporter)

B300 8장의 물리적 상태와 NVLink 통신 상태를 감시합니다.

배포: docker run -d --gpus all --net=host nvcr.io/nvidia/k8s/dcgm-exporter:latest (포트 9400 노출)
핵심 지표:
DCGM_FI_DEV_GPU_UTIL: 연산 코어 활용률 (%)
DCGM_FI_DEV_MEM_COPY_UTIL: HBM3e 메모리 대역폭 활용률 (Decode 단계 병목 판단의 핵심)
DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL: NVLink 송수신 처리량 (DeepSeek V3, Mixtral 같은 MoE 서빙 시 통신 포화 여부 확인)
DCGM_FI_DEV_POWER_USAGE / TEMP: 전력 소비량(W) 및 발열 스로틀링 여부

계층 B: vLLM 서빙 엔진 메트릭 (vLLM `/metrics` 엔드포인트)

vLLM이 자체적으로 노출하는 메트릭을 Prometheus로 긁어옵니다 (http://localhost:8000/metrics).

핵심 지표:
vllm:num_requests_running / vllm:num_requests_waiting: 현재 실행 중인 요청 수 vs VRAM/스케줄러 큐에 대기 중인 요청 수 (Waiting이 급증하면 용량 포화)
vllm:gpu_cache_usage_perc: KV Cache 메모리 점유율 (100% 도달 시 선점(Preemption) 발생 위험)
vllm:num_preemptions_total: 메모리 부족으로 디코딩 중 쫓겨난 요청 수 (0이어야 정상)
vllm:time_to_first_token_seconds_bucket: TTFT 히스토그램 (P50, P90, P99 지연시간 분석)
vllm:time_per_output_token_seconds_bucket: TPOT 히스토그램 (사용자 체감 생성 속도)

계층 C: OS & 호스트 시스템 메트릭 (Node Exporter)

모델 가중치(특히 671GB의 DeepSeek) 로딩 시 호스트 RAM 고갈 여부(node_memory_MemAvailable_bytes)와 PCIe/디스크 I/O 속도를 추적합니다.

3. 병목 원인 진단 가이드 (Troubleshooting Matrix)

벤치마크 실행 중 다음과 같은 지표 패턴이 나타나면 즉시 해당 설정을 튜닝해야 합니다.

관측 증상	메트릭 이상 징후	주요 원인	조치 방안
TTFT(첫 토큰 지연) 급증	`waiting_requests` 증가,

GPU_UTIL 중간 | Memory Bandwidth Bound (메모리 대역폭 한계) | 자연스러운 LLM Decode 특성이며 배치를 더 묶거나 양자화 도입 |

4. 모델 간 최종 비교 분석 틀

테스트가 끝난 후 아래와 같은 매트릭스로 정리하면 단일 B300 노드의 워크로드별 수용 능력을 한눈에 비교할 수 있습니다.

최대 Throughput (Tokens/s): 단위 시간당 생성 가능한 최대 토큰 수
최적 Concurrency: Throughput이 피크를 치면서 TPOT가 허용 범위(예: 30ms 이내)를 유지하는 동시 사용자 수
P99 TTFT / TPOT: 시스템 부하 시 가장 느린 1% 요청의 지연시간
GPU당 VRAM 잔여량 (Idle 시): 모델 가중치 제외 순수 KV Cache로 할당 가능한 VRAM 여유율

benchmark_serving.py는 vLLM 오픈소스 진영에서 공식 제공하는 스크립트라 가장 널리 쓰이지만, 업계 유일의 표준은 아니며 실무에서는 더 정교한 오픈소스 부하/벤치마크 프레임워크들을 병행해서 사용합니다.

1. `benchmark_serving.py` 외에 주로 쓰이는 LLM 벤치마크 도구

GenAI-Perf (Triton / NVIDIA 공식 도구)

NVIDIA 공식 도구로, vLLM의 OpenAI 호환 API 엔드포인트에 붙여서 정밀한 지연시간 분포(P90, P95, P99), TTFT, ITL(Inter-Token Latency), Throughput을 측정하고 아티팩트(그래프/CSV)를 자동 생성해 줍니다. 프로덕션 검증용으로 가장 신뢰도가 높습니다.

Locust / k6 (범용 부하 테스트 툴)

단순 토큰 처리량뿐 아니라 실제 웹 서비스 아키텍처 관점의 스트레스 테스트에 적합합니다. 유저 증가 시나리오(Ramp-up), 세션 유지, HTTP 커넥션 풀 고갈 여부 등을 커스텀 파이썬/JS 코드로 시뮬레이션할 수 있습니다.

GuideLLM (Neural Magic 제공)

목표 레이턴시(예: "TTFT 100ms 이하 유지")를 입력하면, 해당 조건을 만족하는 최대 Throughput과 최적의 동시성(Concurrency) 한계점을 자동으로 탐색해 주는 스위핑 도구입니다.

2. 클라이언트에서 UI를 보려면 방화벽을 꼭 열어야 할까?

아닙니다. 외부 공인 IP 방화벽을 직접 열지 않는 것이 보안상 훨씬 안전하며, 실무에서도 방화벽 오픈은 권장하지 않습니다.

Prometheus(9090)나 Grafana(3000) 포트를 퍼블릭 인터넷에 그대로 노출하면 브루트포스 공격이나 미인증 메트릭 탈취 위험에 노출됩니다. 다음 3가지 방법 중 하나를 선택하면 방화벽을 열지 않고도 안전하게 접속할 수 있습니다.

대안 1: SSH Local Port Forwarding (가장 간단하고 권장됨)

로컬 PC(노트북) 터미널에서 SSH 터널링을 뚫어두고 브라우저로 접근하는 방식입니다.

# 로컬 PC 터미널에서 실행 (GPU 노드의 SSH 22번 포트만 열려 있으면 가능)
ssh -N -L 3000:localhost:3000 -L 9090:localhost:9090 user@<GPU_노드_PUBLIC_IP>

위 명령어를 켜둔 채로 로컬 브라우저에서 http://localhost:3000(Grafana), http://localhost:9090(Prometheus)으로 접속하면 터널을 통해 안전하게 열립니다.

대안 2: 특정 관리자 IP만 허용 (White-list 방화벽)

0.0.0.0/0 전체 개방 대신, 현재 접속 중인 사무실/자택의 고정 공인 IP에 대해서만 UFW나 클라우드 Security Group에서 허용합니다.

sudo ufw allow from <내_공인_IP> to any port 3000 proto tcp

대안 3: 앞단에 Nginx + Basic Auth / Tailscale

노드에 경량 Nginx를 두고 SSL(HTTPS) 인증서 적용 및 비밀번호 인증(htpasswd)을 걸어서 포워딩하거나,
노드에 Mesh VPN인 Tailscale을 설치하여 개인 기기들끼리만 폐쇄망 사설 IP로 묶어서 웹 콘솔에 접근하는 방법도 널리 쓰입니다.

RHEL 기반 베어메탈 환경에서 Prometheus, Grafana, 그리고 3가지 Exporter(Node Exporter, NVIDIA DCGM Exporter, vLLM)를 Systemd 서비스로 구성하고 연동하는 전체 절차입니다.

포트 구성 요약

Prometheus: 9090
Grafana: 3000
Node Exporter: 9100 (OS/호스트 리소스)
DCGM Exporter: 9400 (B300 GPU 하드웨어/NVLink 메트릭)
vLLM Engine: 8000 (추론 엔진 /metrics)

1. Prometheus 설치 및 Systemd 등록

# 1. Prometheus 시스템 계정 및 디렉터리 생성
sudo useradd --no-create-home --shell /bin/false prometheus
sudo mkdir -p /etc/prometheus /var/lib/prometheus

# 2. 바이너리 다운로드 및 배치 (최신 버전 확인 권장)
cd /tmp
curl -LO https://github.com/prometheus/prometheus/releases/download/v2.54.1/prometheus-2.54.1.linux-amd64.tar.gz
tar -xvf prometheus-2.54.1.linux-amd64.tar.gz
cd prometheus-2.54.1.linux-amd64

sudo cp prometheus promtool /usr/local/bin/
sudo cp -r consoles console_libraries /etc/prometheus/
sudo chown -R prometheus:prometheus /usr/local/bin/prom* /etc/prometheus /var/lib/prometheus

# 3. Systemd 서비스 파일 생성
sudo tee /etc/systemd/system/prometheus.service << 'EOF'
[Unit]
Description=Prometheus Server
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/var/lib/prometheus/ \
  --web.listen-address=127.0.0.1:9090 \
  --storage.tsdb.retention.time=15d

Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

2. Node Exporter 설치 (호스트 OS 메트릭)

CPU, 호스트 RAM(대형 모델 로딩 모니터링), 디스크 I/O를 수집합니다.

sudo useradd --no-create-home --shell /bin/false node_exporter

cd /tmp
curl -LO https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz
tar -xvf node_exporter-1.8.2.linux-amd64.tar.gz
sudo cp node_exporter-1.8.2.linux-amd64/node_exporter /usr/local/bin/
sudo chown node_exporter:node_exporter /usr/local/bin/node_exporter

sudo tee /etc/systemd/system/node_exporter.service << 'EOF'
[Unit]
Description=Node Exporter
After=network.target

[Service]
User=node_exporter
Group=node_exporter
Type=simple
ExecStart=/usr/local/bin/node_exporter --web.listen-address=127.0.0.1:9100

Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now node_exporter

3. NVIDIA DCGM Exporter 설치 (베어메탈 네이티브)

B300 8장의 GPU 사용률, 메모리 대역폭, 전력, 그리고 NVLink 통신 메트릭을 수집합니다.

# 1. NVIDIA 공식 패키지 저장소 등록 (RHEL 계열)
sudo dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/rhel9/x86_64/cuda-rhel9.repo

# 2. DCGM 및 datacenter-gpu-manager 설치
sudo dnf install -y datacenter-gpu-manager datacenter-gpu-manager-exporter

# 3. DCGM 엔진 서비스 실행
sudo systemctl enable --now nvidia-dcgm

# 4. DCGM Exporter 서비스 실행 (기본 포트 9400)
sudo systemctl enable --now dcgm-exporter

(검증: curl -s http://localhost:9400/metrics | grep DCGM_FI_DEV_GPU_UTIL 실행 시 8개 GPU 메트릭 출력 확인)

4. Prometheus 설정 (`/etc/prometheus/prometheus.yml`)

vLLM(포트 8000), DCGM(포트 9400), Node Exporter(포트 9100)를 수집 대상으로 등록합니다.

sudo tee /etc/prometheus/prometheus.yml << 'EOF'
global:
  scrape_interval: 2s         # LLM 벤치마크 시 급격한 메트릭 스파이크 감지를 위해 2초 권장
  evaluation_interval: 2s

scrape_configs:
  # 1. 호스트 시스템 리소스
  - job_name: 'node_exporter'
    static_configs:
      - targets: ['127.0.0.1:9100']

  # 2. B300 GPU 하드웨어 & NVLink
  - job_name: 'dcgm_exporter'
    static_configs:
      - targets: ['127.0.0.1:9400']

  # 3. vLLM 추론 엔진
  - job_name: 'vllm'
    metrics_path: /metrics
    static_configs:
      - targets: ['127.0.0.1:8000']
EOF

sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml
sudo systemctl daemon-reload
sudo systemctl enable --now prometheus

(검증: systemctl status prometheus)

5. Grafana 설치 및 기동

# 1. Grafana 공식 YUM 저장소 등록
sudo tee /etc/yum.repos.d/grafana.repo << 'EOF'
[grafana]
name=grafana
baseurl=https://rpm.grafana.com
repo_gpgcheck=1
enabled=1
gpgcheck=1
gpgkey=https://rpm.grafana.com/gpg.key
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
EOF

# 2. Grafana 설치 및 서비스 기동
sudo dnf install -y grafana
sudo systemctl daemon-reload
sudo systemctl enable --now grafana-server

6. Grafana 대시보드 연동 및 시각화

로컬 PC에서 SSH 포트 포워딩 연결 (외부 방화벽 열지 않음):

ssh -N -L 3000:localhost:3000 -L 9090:localhost:9090 <계정>@<B300_서버_IP>

Grafana 접속: 로컬 브라우저에서 http://localhost:3000 (초기 계정: admin / admin)
Data Source 추가:

Connections $\to$ Data sources $\to$ Add data source $\to$ Prometheus
URL에 http://localhost:9090 입력 후 Save & test

추천 공식 대시보드 Import (Dashboard ID 입력):

NVIDIA DCGM Exporter: Dashboard ID 12239 (8개 GPU의 Utilization, HBM Bandwidth, Power를 한눈에 모니터링)
Node Exporter Full: Dashboard ID 1860 (Host CPU, 메모리, 네트워크 인터페이스 모니터링)
vLLM 공식 대시보드: vLLM 공식 레포지토리(examples/grafana.json) JSON 파일을 복사하여 Import하면 TTFT, TPOT(Time per Output Token), KV Cache Usage, Running/Waiting Requests 패널이 바로 구성됩니다.

폐쇄망(Air-gap) 환경에서는 외부 저장소에 직접 접근할 수 없으므로, 인터넷이 연결된 동일 OS(RHEL 9 또는 10) 환경의 PC/서버에서 의존성 RPM 패키지들을 통째로 다운로드하여 압축 반입한 뒤 로컬 레포지토리(Local Repository)를 구성해 설치하는 것이 표준 절차입니다.

Step 1. 외부망(인터넷 가능 PC/서버)에서 작업

dnf download를 활용해 DCGM 및 Exporter의 의존성 패키지까지 한 번에 수집합니다.

# 1. 필수 도구 설치
sudo dnf install -y dnf-plugins-core createrepo

# 2. NVIDIA 공식 CUDA 레포지토리 등록
sudo dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/rhel9/x86_64/cuda-rhel9.repo

# 3. 패키지 다운로드용 디렉터리 생성
mkdir -p ./dcgm_airgap_pkgs
cd ./dcgm_airgap_pkgs

# 4. DCGM 및 Exporter 의존성 포함 전체 다운로드 (--alldeps, --resolve 플래그)
sudo dnf download --resolve --alldeps datacenter-gpu-manager datacenter-gpu-manager-exporter

# 5. 오프라인 메타데이터 생성 (createrepo)
cd ..
createrepo dcgm_airgap_pkgs/

# 6. 아카이브 압축 (B300 서버 반입용)
tar -czvf dcgm_airgap_bundle.tar.gz dcgm_airgap_pkgs/

생성된 dcgm_airgap_bundle.tar.gz 파일을 보안 인가된 저장매체(USB, 사설 파일 전송망 등)를 통해 Air-gap B300 노드로 반입합니다.

Step 2. Air-gap B300 노드(폐쇄망)에서 작업

반입한 패키지로 로컬 YUM/DNF 저장소를 등록한 뒤 설치를 진행합니다.

# 1. 압축 해제 및 디렉터리 배치
tar -xzvf dcgm_airgap_bundle.tar.gz
sudo mv dcgm_airgap_pkgs /opt/local-repo-dcgm

# 2. 폐쇄망 로컬 저장소(.repo) 파일 생성
sudo tee /etc/yum.repos.d/local-dcgm.repo << 'EOF'
[local-dcgm]
name=Local DCGM Repository
baseurl=file:///opt/local-repo-dcgm
enabled=1
gpgcheck=0
EOF

# 3. 로컬 캐시 갱신 및 설치 (외부 저장소 참조 없이 로컬만 지정)
sudo dnf clean all
sudo dnf --disablerepo="*" --enablerepo="local-dcgm" install -y datacenter-gpu-manager datacenter-gpu-manager-exporter

Step 3. 서비스 기동 및 검증

설치 후 Systemd 서비스 활성화 및 메트릭 출력 확인은 기존과 동일합니다.

# DCGM 엔진 및 Exporter 데몬 기동
sudo systemctl enable --now nvidia-dcgm
sudo systemctl enable --now dcgm-exporter

# 메트릭 수집 검증
curl -s http://localhost:9400/metrics | grep DCGM_FI_DEV_GPU_UTIL

💡 팁: 사내 사설 Harbor/컨테이너 레지스트리가 있는 경우

베어메탈 RPM 설치 대신 사내 레지스트리를 쓸 수 있다면, 외부망에서 공식 컨테이너 이미지를 docker save $\to$ 폐쇄망 반입 $\to$ docker load(또는 Podman)로 띄우는 것이 라이브러리 충돌 없이 훨씬 간편합니다.

외부망: docker pull nvcr.io/nvidia/k8s/dcgm-exporter:latest $\to$ docker save -o dcgm-exporter.tar nvcr.io/nvidia/k8s/dcgm-exporter:latest
폐쇄망: docker load -i dcgm-exporter.tar 후 host network 모드로 실행

폐쇄망(Air-gap) 환경에서 Grafana를 베어메탈에 설치하는 가장 확실한 방법은 공식 RPM 단일 패키지를 외부망에서 받아 반입한 뒤 설치하거나, 바이너리(tar.gz) 아카이브를 풀어 직접 실행하는 것입니다. Grafana는 단일 바이너리/패키지 구조라 DCGM에 비해 의존성 패키지가 거의 없어 절차가 매우 간단합니다.

방법 1. 독립 실행형 RPM 패키지 반입 및 설치 (권장)

Grafana Enterprise/OSS RPM은 핵심 런타임과 라이브러리가 정적 포함되어 있어 추가 의존성 없이 단일 파일로 설치됩니다.

1. 외부망(인터넷 가능 PC)에서 다운로드

# 공식 RPM 다운로드 (x86_64 기준 최신 안정 버전)
curl -LO https://dl.grafana.com/oss/release/grafana-11.1.0-1.x86_64.rpm

다운로드한 grafana-*.rpm 파일을 보안 승인 매체를 통해 폐쇄망 B300 노드로 반입합니다.

2. 폐쇄망 B300 노드에서 설치 및 서비스 기동

# 외부 저장소 참조 없이 로컬 패키지만 설치
sudo dnf install -y ./grafana-11.1.0-1.x86_64.rpm

# 서비스 등록 및 시작
sudo systemctl daemon-reload
sudo systemctl enable --now grafana-server

(상태 확인: sudo systemctl status grafana-server)

방법 2. 바이너리 압축 파일(`.tar.gz`) 사용 (패키지 관리자 미사용 시)

시스템 패키지 설치(dnf) 권한이나 의존성 검사를 아예 거치지 않고 특정 디렉터리에 깔끔하게 올려 관리하고 싶을 때 유용합니다.

1. 외부망에서 다운로드

curl -LO https://dl.grafana.com/oss/release/grafana-11.1.0.linux-amd64.tar.gz

해당 파일을 폐쇄망으로 반입합니다.

2. 폐쇄망 노드에서 압축 해제 및 서비스 등록

# 1. 디렉터리 배치
sudo tar -xzvf grafana-11.1.0.linux-amd64.tar.gz -C /usr/local/
sudo ln -s /usr/local/grafana-v11.1.0 /usr/local/grafana

# 2. 전용 계정 생성 및 권한 부여
sudo useradd --no-create-home --shell /bin/false grafana
sudo chown -R grafana:grafana /usr/local/grafana /usr/local/grafana-v11.1.0

# 3. Systemd 서비스 등록
sudo tee /etc/systemd/system/grafana-server.service << 'EOF'
[Unit]
Description=Grafana Instance
After=network.target

[Service]
User=grafana
Group=grafana
Type=simple
WorkingDirectory=/usr/local/grafana
ExecStart=/usr/local/grafana/bin/grafana server --homepath=/usr/local/grafana
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now grafana-server

폐쇄망 환경 추가 확인 사항: 기본 플러그인 & 포트 접근

기본 포트: 3000 (서비스 기동 후 로컬 확인: curl -I http://localhost:3000)
데이터소스: Prometheus 연동은 기본 내장 코어 플러그인이므로 폐쇄망에서도 인터넷 연결 없이 http://localhost:9090을 바로 추가해 사용할 수 있습니다.
접속 방법: 노드의 3000번 방화벽을 외부에 열지 않고, 관리자 PC에서 ssh -N -L 3000:localhost:3000 user@<노드IP> 터널링을 열어 브라우저(http://localhost:3000, 기본 계정 admin / admin)로 접속하는 방식을 권장합니다.

폐쇄망(Air-gap) 환경에서는 외부 허브로 직접 연결할 수 없으므로, 인터넷이 되는 외부 환경에서 모델 가중치(Safetensors)를 내려받아 보안 매체나 사내 전송망을 통해 B300 노드로 반입한 뒤 vLLM에서 로컬 디렉터리 경로를 지정해 구동해야 합니다.

1. 외부망에서 모델 다운로드하기

Hugging Face 공식 CLI인 huggingface-cli를 사용하는 것이 가장 빠르고 무결성 검증에 유리합니다.

필수 준비: Hugging Face 토큰 발급 및 라이선스 동의

Llama 계열(Llama 3.1 8B, Llama 3.3 70B): Hugging Face 웹사이트에서 모델 페이지(Gated Model)에 접속해 이용 약관에 동의(동의 승인은 보통 수 분 내 자동 처리됨)해야 다운로드가 가능합니다.
DeepSeek, Qwen, Mixtral: 오픈 라이선스로 별도 사전 승인 없이 즉시 다운로드 가능합니다.

다운로드 명령어 (외부망 환경)

대용량 파일 전송 중단 시 이어받기가 기본 지원되는 hf_transfer 기반 다운로드를 권장합니다.

# 1. 도구 설치 및 고속 다운로더 활성화
pip install -U "huggingface_hub[cli]" hf_transfer
export HF_HUB_ENABLE_HF_TRANSFER=1

# 2. 토큰 로그인 (Llama 등 승인 모델 다운로드 시 필수)
huggingface-cli login --token <YOUR_HF_TOKEN>

# 3. 모델별 다운로드 (로컬 특정 경로 지정: --local-dir)
# 예: Llama 3.3 70B (~140GB)
huggingface-cli download meta-llama/Llama-3.3-70B-Instruct \
  --local-dir /data/models/Llama-3.3-70B-Instruct \
  --local-dir-use-symlinks False

# 예: Qwen 2.5 72B (~145GB)
huggingface-cli download Qwen/Qwen2.5-72B-Instruct \
  --local-dir /data/models/Qwen2.5-72B-Instruct \
  --local-dir-use-symlinks False

# 예: DeepSeek V3 (FP8 체크포인트, ~680GB)
huggingface-cli download deepseek-ai/DeepSeek-V3 \
  --local-dir /data/models/DeepSeek-V3 \
  --local-dir-use-symlinks False

주의: --local-dir-use-symlinks False 옵션을 주어야 캐시 심볼릭 링크가 아닌 실제 파일로 저장되므로 폐쇄망 이관 시 파일 유실을 막을 수 있습니다.

2. 폐쇄망 B300 노드로 반입 및 배치

가중치 파일(.safetensors), 토크나이저 설정(tokenizer.json, tokenizer_config.json), 모델 설정(config.json) 등이 누락 없이 포함된 폴더 전체를 B300 노드의 대용량 스토리지(예: /data/models/)로 복사합니다.

폴더 구조 검증 예시

/data/models/Llama-3.3-70B-Instruct/
├── config.json
├── generation_config.json
├── model-00001-of-00030.safetensors
├── ...
├── model.safetensors.index.json
├── tokenizer.json
└── tokenizer_config.json

3. 폐쇄망 B300에서 로컬 경로로 vLLM 서빙

모델 식별자 대신 로컬 절대 경로를 인자로 넘겨주면, vLLM이 외부 인터넷(Hugging Face Hub) 조회를 시도하지 않고 즉시 로컬 디스크에서 가중치를 읽어와 GPU 메모리에 올립니다.

# Llama 3.3 70B (TP=8)
vllm serve /data/models/Llama-3.3-70B-Instruct \
  --tensor-parallel-size 8 \
  --dtype bfloat16 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90 \
  --port 8000

# DeepSeek V3 (FP8, TP=8)
vllm serve /data/models/DeepSeek-V3 \
  --tensor-parallel-size 8 \
  --dtype bfloat16 \
  --quantization fp8 \
  --kv-cache-dtype fp8 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.92 \
  --enforce-eager \
  --trust-remote-code \
  --port 8000

4. 사내 모델 레지스트리/오브젝트 스토리지가 있는 경우 (권장)

노드 디스크로 직접 외장 하드를 물리 연결해 복사하기 어려운 폐쇄망 환경이라면, 사내에 구축된 MinIO, S3 호환 오브젝트 스토리지, 또는 사내 사설 허브(Hugging Face Local Mirror)에 모델 폴더를 업로드해 두고, B300 노드에서 내부 고속망을 통해 로컬 NVMe로 복사해 서빙하는 방식이 가장 효율적입니다.

네, 맞습니다. Hugging Face CLI가 업데이트되면서 기존의 길었던 huggingface-cli 대신 훨씬 간결한 hf 명령어가 표준으로 자리 잡았으며, 옵션 체계도 한층 직관적으로 정돈되었습니다.

최신 hf CLI 문법을 반영한 다운로드 및 폐쇄망 반입 절차입니다.

1. 도구 설치 및 고속 전송 모드 활성화 (외부망)

hf 바이너리 단축 명령어는 최신 huggingface_hub 패키지에 기본 내장되어 있습니다.

# 최신 huggingface_hub 및 고속 병렬 다운로더(hf_transfer) 설치
pip install -U "huggingface_hub[cli]" hf_transfer

# 초고속 다운로드 활성화 (Rust 기반 hf_transfer 백엔드)
export HF_HUB_ENABLE_HF_TRANSFER=1

2. 로그인 (Gated 모델용)

Llama 3.1 / 3.3 같은 접근 승인 모델 다운로드를 위해 토큰을 등록합니다.

hf login --token <YOUR_HF_TOKEN>

3. 최신 `hf` 다운로드 명령어 (`hf download`)

기존의 복잡했던 --local-dir-use-symlinks False 옵션 없이도, --local-dir을 지정하면 실제 파일 형태로 바로 복사되어 폐쇄망 이관 시 링크가 깨지는 문제가 없습니다.

# 1. Llama 3.3 70B (~140GB)
hf download meta-llama/Llama-3.3-70B-Instruct \
  --local-dir /data/models/Llama-3.3-70B-Instruct

# 2. Qwen 2.5 72B (~145GB)
hf download Qwen/Qwen2.5-72B-Instruct \
  --local-dir /data/models/Qwen2.5-72B-Instruct

# 3. DeepSeek V3 (FP8 체크포인트, ~680GB)
hf download deepseek-ai/DeepSeek-V3 \
  --local-dir /data/models/DeepSeek-V3

# 4. 소형 모델 (Llama 3.1 8B, Qwen 2.5 14B)
hf download meta-llama/Meta-Llama-3.1-8B-Instruct \
  --local-dir /data/models/Meta-Llama-3.1-8B-Instruct

💡 유용한 최신 `hf` 플래그

특정 포맷/파일만 골라 받기 (--include / --exclude):
불필요한 .bin 파일이나 원본 가중치를 제외하고 순수 safetensors 파일만 경량화해서 내려받을 때 유용합니다.

hf download meta-llama/Llama-3.3-70B-Instruct \
  --include "*.safetensors" "*.json" "*.txt" \
  --local-dir /data/models/Llama-3.3-70B-Instruct

백그라운드 세션 추천:
DeepSeek V3나 70B 모델은 파일 크기가 수백 GB에 달하므로, 터미널 세션이 끊기지 않도록 tmux나 screen 내부에서 실행하는 것을 권장합니다.

4. 폐쇄망 B300 노드에서 vLLM 구동

외부망에서 내려받은 /data/models/<모델명> 폴더를 폐쇄망 노드로 반입한 후, 로컬 경로를 직접 넘겨주면 이전과 동일하게 외부 통신 없이 즉각 GPU로 적재됩니다.

# vLLM 로컬 경로 서빙 예시
vllm serve /data/models/Llama-3.3-70B-Instruct \
  --tensor-parallel-size 8 \
  --dtype bfloat16 \
  --port 8000

각 모델을 hf download로 내려받을 때 필요한 디스크 용량(순수 다운로드 크기)과 폐쇄망 반입 시 권장 여유 공간입니다.

가중치 정밀도(BF16/FP8)에 따라 실제 파일 크기가 결정됩니다.

모델명	기본 정밀도	디스크 다운로드 크기 (Safetensors 기준)	권장 디스크 여유 공간 (임시 파일/반입 고려)	비고
Meta-Llama-3.1-8B-Instruct	BF16 (16-bit)	약 16 GB	약 25 GB	4개 내외 safetensors 샤드
Qwen 2.5 14B Instruct	BF16 (16-bit)	약 29 ~ 30 GB	약 45 GB	8개 내외 샤드
Llama 3.3 70B Instruct	BF16 (16-bit)	약 138 ~ 140 GB	약 180 GB	약 30개 분할 샤드
Qwen 2.5 72B Instruct	BF16 (16-bit)	약 144 ~ 146 GB	약 190 GB	약 37개 분할 샤드
Mixtral 8x22B Instruct	BF16 (16-bit)	약 265 ~ 280 GB	약 350 GB	총 141B 파라미터 원본 가중치
DeepSeek V3 / R1	FP8 (8-bit)	약 680 ~ 700 GB	약 850 GB ~ 1 TB	671B 총 파라미터 (FP8 체크포인트)

다운로드 및 반입 시 주의할 점

전체 모델 일괄 반입 시 필요 용량:
위 모델들을 전부 받아 폐쇄망 스토리지로 넘기려면 순수 가중치만 약 1.3 TB ~ 1.4 TB에 달합니다.
다운로드 중 생성되는 임시 캐시(.cache/huggingface)와 압축 아카이브(tar 등) 생성을 감안하면, 다운로드 작업 서버에는 최소 2 TB 이상의 고속 NVMe/SSD 여유 공간이 확보되어 있어야 합니다.

DeepSeek V3 다운로드 시간:
700GB 단일 모델은 1Gbps 망 기준 약 1.5~2시간, 10Gbps 망 기준 10~15분 이상 소요되므로 반드시 tmux나 screen 세션에서 실행하세요.

1. AIStor(오브젝트 스토리지) 내 모델 저장 구조 (Best Practice)

Hugging Face Hub의 원본 구조를 유지하면서 조직/제공자 $\to$ 모델명 $\to$ 포맷/정밀도 $\to$ 버전(Git Commit 태그 또는 날짜) 체계로 버킷 및 Prefix를 설계하는 것이 가장 확장성이 높고 자동화하기 편합니다.

s3://ai-models/
├── hub/                          # Hugging Face Mirror 구조 (호환성 최우선)
│   ├── meta-llama/
│   │   └── Llama-3.3-70B-Instruct/
│   │       ├── v1.0/             # 또는 Commit Hash (예: a6c5e...)
│   │       │   ├── config.json
│   │       │   ├── tokenizer.json
│   │       │   ├── tokenizer_config.json
│   │       │   ├── model.safetensors.index.json
│   │       │   └── model-00001-of-00030.safetensors
│   │       └── latest -> (v1.0 Prefix 복사 또는 메타데이터 관리)
│   ├── deepseek-ai/
│   │   └── DeepSeek-V3/
│   │       └── fp8/
│   │           ├── config.json
│   │           └── model-00001-of-00163.safetensors
│   └── Qwen/
│       └── Qwen2.5-72B-Instruct/
│           ├── bf16/
│           └── awq/              # 양자화 포맷별 분리
│
└── fine-tuned/                   # 사내 파인튜닝 / LoRA 어댑터 가중치
    └── llama-3.3-70b-corp-qa/
        ├── run-20260915/
        │   ├── adapter_config.json
        │   └── adapter_model.safetensors
        └── checkpoints/          # 학습 도중 중간 체크포인트

구조 설계 핵심:
HF Hub 호환 유지: config.json, tokenizer.json, *.safetensors 파일들의 상대 경로를 Hugging Face 원본 그대로 유지해야, 노드에서 s3 sync나 mc mirror로 내려받았을 때 vLLM/SGLang이 추가 변환 없이 즉시 로딩합니다.
정밀도/포맷 명시: 동일 모델이라도 bf16, fp8, awq, gptq 등 서빙 엔진 옵션에 따라 필요한 포맷이 다르므로 서브 디렉터리로 명확히 분리합니다.

2. GPU 노드가 2대 이상이면 오브젝트 스토리지가 필수인가?

기술적으로 "필수(Must)"는 아니지만, 실무 운영(DevOps/MLOps) 관점에서는 "사실상 필수(De facto standard)"입니다.

오브젝트 스토리지가 없을 때 대안과 한계는 다음과 같습니다.

대안 1: 공유 파일시스템 (NFS / CephFS / Lustre 등)
모든 GPU 노드가 동일한 마운트 포인트(/mnt/shared-models)를 바라보게 구성할 수 있습니다.
문제점: 수백 GB의 대형 모델(DeepSeek 700GB, 70B 모델 등)을 여러 노드가 동시에 파이프라인/텐서 병렬로 읽어 들일 때 네트워크 파일시스템의 메타데이터 락(Lock)과 I/O 병목이 심하게 발생하여 기동 시간이 기하급수적으로 늘어납니다.

대안 2: 노드 로컬 스토리지에 각각 수동 복사 (SCP, Rsync)
노드가 2~3대일 때는 버틸 수 있지만, 노드가 10대, 20대로 늘어나거나 노드가 장애로 재부팅/재프로비저닝될 때마다 수 TB의 모델을 일일이 복사하는 것은 관리가 불가능합니다.

오브젝트 스토리지(AIStor)를 쓰는 이유:
단일 진실 공급원(Single Source of Truth): 모델의 원본은 안전한 중앙 스토리지(AIStor)에 두고, 노드가 뜨거나 Pod가 뜰 때 Init Container나 로컬 캐시 데몬이 AIStor에서 각 노드의 고속 로컬 NVMe로 병렬 프리패치(S3 Multipart Download)하는 구조가 가장 빠르고 안정적입니다.

3. 오브젝트 스토리지에는 모델 외에 어떤 것들이 저장되는가?

AI 인프라에서 오브젝트 스토리지는 단순 "모델 저장소"를 넘어 전체 AI 수명주기의 핵심 데이터 레이크로 활용됩니다.

분류	저장되는 세부 항목	설명
1. 모델 & 가중치	• 사전학습 모델 원본 (Base Model)

• LoRA / QLoRA 어댑터 가중치

• 양자화 모델 (FP8, INT4, AWQ) | 서빙 엔진이 읽어가는 최종 배포 산출물 |
| 2. 학습 체크포인트 | • Optimizer States (Adam 상태값)

• 중간 가중치 (Epoch/Step별 체크포인트)

• Gradient 상태 | 분산 학습 중 노드 장애 시 복구(Fault Tolerance)를 위해 수시로 덤프 |
| 3. 원천 데이터 & 가공셋 | • Raw 텍스트/문서/코드 (Parquet, JSONL)

• 토크나이징 완료된 바이너리 데이터셋

• RAG용 벡터 임베딩 청크 원본 | 데이터 레이크하우스 및 전처리 파이프라인의 입출력 데이터 |
| 4. 토크나이저 & 메타데이터 | • tokenizer.json, vocab.json

• 모델 아키텍처 config.json

• 모델 카드(README), 라이선스 텍스트 | 추론 엔진이 입출력 텍스트를 인코딩/디코딩하기 위한 필수 설정 |
| 5. 평가 & 벤치마크 결과 | • 벤치마크 JSON/CSV 로그 (TTFT, TPOT)

• 모델 성능 평가 지표 (MMLU, HumanEval 점수)

• 서빙 프로파일러 트레이스 파일 | 버전 간 성능 비교 및 감사(Audit)용 데이터 |
| 6. 서빙 런타임 캐시 | • 컴파일된 커널 캐시 (vLLM/Triton 캐시)

• Prefix Caching 스냅샷 | 노드 재기동 시 초기 컴파일 오버헤드를 줄이기 위한 공용 캐시 |

실무 권장 패턴: "S3 as Hub + Local NVMe as Cache"

저장(Storage): 모든 가중치와 데이터셋은 신뢰성이 보장된 AIStor(MinIO)에 중앙 보관합니다.
배포(Serving): GPU 노드에서 vLLM을 띄울 때 S3 FUSE로 직접 스트리밍해서 읽으면 I/O 지연이 크므로, 노드 로컬의 초고속 NVMe(/data/cache)로 S3 동기화(mc mirror 또는 s5cmd)를 고속으로 마친 뒤 로컬 경로를 지정해 VRAM으로 로딩하는 2단계 파이프라인이 정석입니다.

https://github.com/prometheus/prometheus/releases

https://github.com/prometheus/node_exporter/releases/

Edition Grafana OSS
Version 13.2.2

engineer

이전 포스트

26S14y

다음 포스트