26O05f

QK·4일 전

네. v13.1 기준으로는 아래 순서로 실행하는 것이 가장 안전합니다. Stage1→2→3a가 bare-metal acceptance, 그 다음 Stage6 K8s, 마지막으로 Stage7 실제 모델 qualification/production config 순서입니다.

0. 실행 전 필수 요건

먼저 다음이 준비되어 있어야 합니다.

B300 × 8가 nvidia-smi에서 모두 정상 인식
NVIDIA Driver / CUDA / Fabric Manager 정상
Python venv 및 vLLM 0.30.0
모델 checkpoint가 로컬 NVMe 등에 준비됨
테스트 결과 저장 경로 쓰기 가능
Local NVMe cache 경로 준비
remote_object 시험 시 MinIO/AIStor S3 endpoint 및 credential 준비
memkv_tcp 시험 시 실제 MemKV server :9900 + HMAC 인증 + 검증된 memkv-vllM/native connector 설정 준비
현재 RDMA 없음 → memkv_rdma는 N/A
K8s Stage6 실행 전에는 NVIDIA GPU Operator/Cilium 등 GPU cluster 기본 구성이 완료되어 있어야 함

특히 현재 환경에서는 KV tier를 다음처럼 해석해야 합니다.

none
local_nvme
remote_object → MinIO/AIStor, S3/TCP/TLS
memkv_tcp     → MemKV native :9900, TCP baseline
memkv_rdma    → N/A (향후 RDMA 도입 후)

remote_object 결과를 MemKV 결과로 기록하면 안 됩니다.

1. 패키지 압축 해제 및 환경설정

tar xzf b300_validation_common_env_v13_1.tar.gz
cd b300_validation_common_env_v13_1

가장 먼저 읽을 문서는:

cat 00_PREREQUISITES.md
cat 03_ACCEPTANCE_SCOPE_AND_RUN_ORDER.md
cat 04_ENVIRONMENT_VARIABLES_REFERENCE.md

입니다.

그 다음 공통 환경을 설정합니다.

vi validation_env.sh
source ./validation_env.sh

최소한 아래 값들은 실제 환경에 맞춰 확인하는 것이 좋습니다.

VALIDATION_ROOT=...
LOCAL_CACHE_DIR=...
LOCAL_MODEL_ROOT=...

VLLM_VENV=...
PYTHON_BIN=...
VLLM_BIN=...

MODEL_70B=...
MODEL_8B=...
MODEL_DEEPSEEK=...

그리고 vLLM 확인:

$VLLM_BIN --version

목표는:

0.30.0

입니다.

2. Stage 0 — Compatibility / 환경 확인

실제 GPU 부하 시험보다 먼저 compatibility check를 실행합니다.

./00_compatibility_check.sh

여기서 확인해야 할 핵심은:

OS / Driver
CUDA
GPU visibility
Python
vLLM == 0.30.0
필수 vLLM serve option
결과 디렉터리

입니다.

여기서 FAIL이면 Stage3a로 넘어가기보다 먼저 환경을 수정하는 것을 권장합니다.

3. Stage 1 — B300 Hardware Acceptance

그 다음 GPU 자체를 검증합니다.

대략적인 실행 순서는:

GPU inventory
 ↓
PCIe topology
 ↓
NVLink / NVSwitch topology
 ↓
ECC / XID
 ↓
DCGM diagnostics
 ↓
NCCL
 ↓
GPU compute / stress
 ↓
thermal / power / stability

입니다.

패키지의 Stage1 스크립트는 이름 순서대로 실행하는 방식이 가장 이해하기 쉽습니다.

ls -1 stage1*

을 먼저 확인하고 Stage1 스크립트를 순서대로 실행하십시오.

결과는 Excel의:

02_HW_Acceptance

에 기록합니다.

Stage1 통과 조건

최소한 다음이 깨끗해야 합니다.

8 GPU visibility
PCIe 이상 없음
NVLink/NVSwitch topology 정상
uncorrectable ECC 없음
XID 없음
DCGM PASS
NCCL 정상
stress 중 thermal/power 문제 없음

Stage1에 문제가 있으면 vLLM 성능 시험을 먼저 하지 않는 편이 좋습니다.

4. Stage 2 — Network / Local NVMe / Remote Object

Stage1 다음에 storage/network baseline을 측정합니다.

먼저:

ls -1 stage2*

로 실제 스크립트를 확인합니다.

중요한 v13.1 변경점은 Stage2c입니다.

Local / network baseline

기본 NIC/TCP 및 Local NVMe 검증을 먼저 수행합니다.

NIC
 ↓
TCP/IP
 ↓
Local NVMe

현재 환경은 RDMA를 전제로 하지 않습니다.

5. Stage2c — Remote Object Storage

v13.1에서는 이름을 명확하게 분리했습니다.

실제 Object Storage 시험은:

./stage2c_remote_object_wire_benchmark.sh

계열을 사용합니다.

대상은:

AIStor / MinIO
S3 API
TCP/TLS

입니다.

즉:

GPU Node
   │
   │ S3 / HTTPS
   ▼
AIStor / MinIO

성능입니다.

중요한 주의

기존 이름:

stage2c_memkv_wire_benchmark.sh

을 MemKV benchmark로 사용하면 안 됩니다.

v13.1에서는 이 경로를 실제 MemKV benchmark로 오인하지 못하도록 처리했습니다.

6. MemKV를 사용할 경우 Preflight

MemKV는 별도로 수행합니다.

먼저:

./stage2c_memkv_native_preflight.sh

을 실행합니다.

확인 대상은 개념적으로:

MemKV server reachable
       ↓
:9900
       ↓
HMAC authentication
       ↓
native protocol
       ↓
vLLM/MemKV connector 준비

입니다.

현재 환경에서는:

memkv_tcp  → 테스트 가능
memkv_rdma → N/A

입니다.

따라서 RDMA 관련 시험을 acceptance FAIL로 기록하면 안 됩니다.

Excel에서는:

memkv_rdma = N/A

로 기록합니다.

7. Stage 3a — vLLM 기본 기능 시험

HW/storage baseline이 끝난 후 vLLM을 시작합니다.

순서는 매우 중요합니다.

vLLM start
 ↓
Server Ready
 ↓
Engine Warm-up
 ↓
Workload Warm-up
 ↓
Measurement

단순히:

sleep 30

후 benchmark를 시작하지 않는 것이 v13 계열의 원칙입니다.

권장 순서

Dense70B BF16 short
 ↓
Dense70B BF16 long
 ↓
FP8
 ↓
TP comparison
 ↓
Prefix Cache
 ↓
KV tier

각 TP를 바꿀 때는:

vLLM restart
→ Ready
→ Engine Warm-up
→ Workload Warm-up
→ Measurement

을 다시 수행합니다.

8. Stage3a8 — Prefix Cache

그 다음 prefix cache입니다.

중요한 순서는:

Engine warm-up
 ↓
Cold prefix measurement
 ↓
Warm prefix measurement

입니다.

Cold 측정 전에 동일 shared prefix를 workload warm-up에서 사용하면 안 됩니다.

결과에서 최소한:

cold TTFT
warm TTFT

prefix_cache_queries
prefix_cache_hits

를 비교합니다.

9. Stage3a10 — KV Tier

v13.1에서 가장 중요한 변경 부분입니다.

다음 순서로 비교하는 것을 권장합니다.

① none
   ↓
② local_nvme
   ↓
③ remote_object
   ↓
④ memkv_tcp
   ↓
⑤ memkv_rdma → N/A

① none

GPU HBM 중심 baseline입니다.

KV tier = none

이 기준점입니다.

② local_nvme

GPU
 ↓
CPU/offload
 ↓
Local NVMe

③ remote_object

GPU
 ↓
CPU/offload
 ↓
AIStor / MinIO
 ↓
S3 / TCP/TLS

입니다.

이 결과를 MemKV라고 부르면 안 됩니다.

④ memkv_tcp

먼저 앞서 설명한:

./stage2c_memkv_native_preflight.sh

가 성공해야 합니다.

그 후 Stage3a10에서:

vLLM
 ↓
native offloading connector
 ↓
MemKV native :9900
 ↓
TCP

를 측정합니다.

v13.1에서는 검증되지 않은 MemKV connector JSON을 임의로 생성하지 않습니다.

따라서 실제 설치된 memkv-vllm + vLLM 0.30.0 조합에서 확인된 --kv-transfer-config를 넣어야 합니다.

설정하지 않았다면:

SKIP / N/A

가 맞습니다.

⑤ memkv_rdma

현재 환경:

RDMA 없음

이므로:

N/A

입니다.

vendor RDMA benchmark 수치와 memkv_tcp 결과를 PASS/FAIL 비교하지 마십시오.

10. Stage3a Performance / TP Sweep

기능 시험이 끝나면 본격적인 TP/Concurrency sweep입니다.

기본 구조는:

TP1
 ├ C1
 ├ C8
 ├ C16
 ├ C32
 └ C64

TP2
 └ ...

TP4
 └ ...

TP8
 └ ...

입니다.

각 point에서 기록할 핵심 값은:

TTFT P50
TTFT P99

ITL P50
ITL P99

Request/s
Output token/s

Error rate

입니다.

Excel의:

04_Performance

시트가 이 결과를 기록하도록 만들어져 있습니다.

11. Stage 3a Soak

단기 성능 측정이 정상이어야 soak로 넘어갑니다.

12. Bare-metal 결과 Summary / Gate

여기까지 끝나면 먼저 bare-metal acceptance를 판정합니다.

Stage1
 +
Stage2
 +
Stage3a Function
 +
Stage3a Performance
 +
Soak
       ↓
Acceptance Summary

Excel에서는:

06_Result_Summary

가 자동 집계합니다.

그리고 패키지의 summary/gate 스크립트를 실행합니다.

13. Stage6 — Kubernetes GPU Serving

Bare-metal baseline을 확보한 다음 K8s로 넘어가는 것이 좋습니다.

순서는 대략:

GPU Operator
 ↓
GPU scheduling
 ↓
Cilium
 ↓
NCCL
 ↓
vLLM Pod
 ↓
startupProbe
 ↓
readinessProbe
 ↓
Warm-up Job
 ↓
Benchmark Job

입니다.

특히 비교해야 하는 것은:

Bare-metal vLLM
       vs
Kubernetes vLLM

입니다.

같은:

model
TP
dtype
input/output
concurrency
warm-up

조건을 사용해야 합니다.

14. Stage7 — 실제 Production Model Qualification

플랫폼 acceptance가 끝난 다음 실제 모델을 qualification합니다.

현재 대상은 예를 들면:

GLM-5.3
Qwen3.6-35B-A3B
gpt-oss-20b

DeepSeek-V4.1-Flash
GLM-5.3-Flash

입니다.

Stage7 흐름은:

Compatibility
 ↓
TP candidate sweep
 ↓
Adaptive concurrency
 ↓
SLO
 ↓
Capacity
 ↓
Headroom
 ↓
Minimum acceptable TP

입니다.

즉 단순 최고 TPS 모델을 고르는 것이 아니라:

SLO 만족
AND
Concurrency headroom 만족
AND
RPS headroom 만족
        ↓
가장 작은 GPU/TP

를 production candidate로 선택하는 구조입니다.

15. Stage7 Production Config 생성

Stage7 selection까지 정상적으로 끝나면 마지막으로 production configuration을 생성합니다.

v13 계열의 최종 흐름은:

Stage7
 ↓
TP / Capacity / SLO
 ↓
model-production-profile.yaml
 │
 ├─ vllm-helm-values.yaml
 ├─ inferencepool.yaml
 ├─ httproute.yaml
 └─ litellm-model-team-capacity.yaml

입니다.

통합 generator는:

./stage7_generate_full_production_bundle.sh \
  <model-key> \
  <stage7-run-dir> \
  ./stage7_production_evidence_example.yaml \
  <output-dir>

형태로 실행합니다.

단, REVIEW_REQUIRED 상태인데 deployment manifest가 활성화되는지 반드시 확인하십시오.

정상적인 경우:

Stage7 PASS
Quality PASS
Soak PASS
K8s PASS
Capacity PASS
SLO PASS
Headroom PASS
       ↓
Production output enabled

이어야 합니다.

전체 실행 순서를 한 번에 보면

[0] Prerequisites
      ↓
validation_env.sh
      ↓
00_compatibility_check.sh
      ↓
[1] Stage1 Hardware
      ↓
GPU / PCIe / NVLink / DCGM / NCCL / Stress
      ↓
[2] Stage2 Network + NVMe
      ↓
Stage2c remote_object
AIStor/MinIO S3
      ↓
MemKV 사용 시 native preflight
      ↓
[3] Stage3a vLLM Function
      ↓
Ready
→ Engine Warm-up
→ Workload Warm-up
      ↓
BF16 / FP8
      ↓
Prefix Cache
      ↓
Stage3a10
 none
 local_nvme
 remote_object
 memkv_tcp
 memkv_rdma=N/A
      ↓
Performance / TP Sweep
      ↓
Soak
      ↓
Bare-metal Acceptance Gate
      ↓
[6] Kubernetes Revalidation
      ↓
Stage6 Gate
      ↓
[7] Real Model Qualification
      ↓
TP Sweep
→ Adaptive Saturation
→ SLO
→ Capacity
→ Headroom
      ↓
Production TP Selection
      ↓
model-production-profile.yaml
      ↓
vLLM Helm
InferencePool
HTTPRoute
LiteLLM capacity config

현장에서 실제로 진행한다면 먼저 00 → Stage1 → Stage2 → Stage3a까지만 수행해서 B300 장비 자체의 인수 여부를 확정하고, K8s Stage6와 실제 서비스 모델 Stage7은 그 다음 단계로 분리하는 것이 가장 관리하기 좋습니다.

engineer

이전 포스트

26O05e

다음 포스트

26O05f

0. 실행 전 필수 요건

1. 패키지 압축 해제 및 환경설정

2. Stage 0 — Compatibility / 환경 확인

3. Stage 1 — B300 Hardware Acceptance

Stage1 통과 조건

4. Stage 2 — Network / Local NVMe / Remote Object

Local / network baseline

5. Stage2c — Remote Object Storage

중요한 주의

6. MemKV를 사용할 경우 Preflight

7. Stage 3a — vLLM 기본 기능 시험

권장 순서

8. Stage3a8 — Prefix Cache

9. Stage3a10 — KV Tier

① none

② local_nvme

③ remote_object

④ memkv_tcp

⑤ memkv_rdma

10. Stage3a Performance / TP Sweep

11. Stage 3a Soak

12. Bare-metal 결과 Summary / Gate

13. Stage6 — Kubernetes GPU Serving

14. Stage7 — 실제 Production Model Qualification

15. Stage7 Production Config 생성

전체 실행 순서를 한 번에 보면

26O05e

26O05g

0개의 댓글