26O01a
전체 Stage 요약
| Stage | 핵심 질문 | 대표 검증 |
|---|---|---|
| Stage 1 | GPU 8장이 정상인가? | PCIe, NVLink, HBM, DCGM, NCCL, FP8/FP4, Stress |
| Stage 2 | Network/Storage가 충분히 빠르고 안정적인가? | NIC, LACP, iperf3, Optical, MinIO/AIStor, NVMe |
| Stage 3a | 실제 AI inference가 빠르고 안정적인가? | vLLM, TTFT, ITL, Throughput, KV Cache, Concurrency |
| 3a2~3a10 | 실서비스 환경에서도 최적/안정적인가? | Tuning, Mixed Load, Soak, Quantization, Scaling, RAG, MemKV |
각 단계 별 세부 테스트 항목
Stage 1 — GPU Hardware & System Health
| Step | 항목 | 주요 확인 내용 | 주요 도구/명령 | 결과/판정 |
|---|---|---|---|---|
| 0 | Persistence Mode / Fabric Manager | GPU Persistence Mode 활성화 및 Fabric Manager 정상 동작 확인 | nvidia-smi, systemctl status nvidia-fabricmanager | 8-GPU Fabric 정상 |
| 1 | GPU 인식 / Driver | GPU 8장 모두 인식되는지, GPU/Driver/CUDA 버전 호환성 확인 | nvidia-smi, nvidia-smi -q | GPU 8/8 인식, Driver 정상 |
| 2 | PCIe Link | GPU별 PCIe Bus, Slot, Link Width, Max/Current Gen 확인 | nvidia-smi -q, lspci -vv | 예상 PCIe Gen/Width와 실제 Link 일치 |
| 3 | NVLink / GPU Topology | GPU 간 NVLink 연결 및 GPU topology 확인 | nvidia-smi topo -m, nvidia-smi nvlink -s | NVLink 연결 정상, 예상 topology와 일치 |
| 4 | HBM ECC | Corrected / Uncorrected ECC Error 확인 | nvidia-smi -q, DCGM | 신규 Uncorrected Error 없음 |
| 5 | XID / Row Remapping | GPU XID Error 및 불량 메모리 Row Remapping 상태 확인 | dmesg, journalctl, nvidia-smi -q | 신규 XID 없음, 이상 Row Remap 없음 |
| 6 | DCGM Diagnostic | GPU, PCIe, Memory, NVLink 등 종합 진단 | dcgmi diag | 모든 진단 Test PASS |
| 7 | NCCL 8-GPU | 8 GPU 간 AllReduce/AllGather 등 실제 통신 성능 측정 | NCCL Tests | 예상 NVLink/NVSwitch 성능 달성 |
| 8 | FP8 / FP4 Compute | Tensor Core 기반 FP8/FP4 연산 성능 및 안정성 검증 | CUDA/TensorRT/NCCL 또는 자체 workload | GPU 간 성능 편차 및 오류 없음 |
| 9 | GPU Stress / Power | 8 GPU 동시 Full Load에서 전력/온도/안정성 확인 | gpu_burn, nvidia-smi | Crash/XID 없이 Stress 통과 |
| 10 | Post-Stress Check | Stress 전후 XID, ECC, Temperature, Power 등 비교 | nvidia-smi, dmesg, DCGM | Stress 후 신규 오류 없음 |
이 단계의 큰 그림: "GPU 8장이 진짜 정상 제품이고, 제대로 조립·연결됐는가"를 확인.
0. Persistence Mode / Fabric Manager 켜기
GPU는 안 쓰면 저절로 절전모드로 들어가는데, 이걸 꺼서 항상 "깨어있게" 만드는 작업임. Fabric Manager는 8장의 GPU가 서로 통신하는 통로(NVLink, 아래 3번 참고)를 관리해주는 프로그램인데, 이게 안 켜져 있으면 뒤 단계들이 다 이상하게 나옴. 그래서 제일 먼저 확인.
1. GPU가 다 인식되는지, 드라이버가 맞는지 확인
nvidia-smi라는 명령어로 "지금 이 컴퓨터가 GPU 몇 장을 인식하고 있나"를 확인. 드라이버가 이 최신 GPU를 지원하는 버전인지도 같이 확인.
2. PCIe 슬롯이 제대로 꽂혀있는지
PCIe는 GPU를 메인보드에 꽂는 슬롯/통로임. "Gen5"니 "Gen6" 등이 있고, GPU가 낼 수 있는 최대 속도와 지금 실제로 나오는 속도가 같은지 확인. 다르면 슬롯이 헐겁게 꽂혔거나 설정이 잘못된 것임.
3. NVLink(GPU끼리 직통 연결)가 잘 붙었는지
GPU 8장이 협업할 때는 PCIe보다 훨씬 빠른 전용 직통선(NVLink)으로 서로 대화함. 이게 하나라도 안 붙어서 일반 PCIe로 돌아가면(코드에서 SYS나 PHB로 표시) 속도가 확 떨어짐. 8장 전부 NVLink로 붙어있는지, 그 연결선에 통신 오류가 없는지 확인.
4. HBM(GPU 메모리)에 에러가 없는지
HBM은 GPU 전용 초고속 메모리임. 메모리 칩이 미세하게 불량이면 "에러"가 찍히는데, 스스로 고칠 수 있는 작은 에러(Corrected)와 못 고치는 심각한 에러(Uncorrected)가 있음. 후자가 하나라도 있으면 그 GPU는 불량 의심 대상임.
5. XID 에러 / 불량 메모리 자동 우회 확인
XID는 GPU가 "나 방금 이상했어"라고 컴퓨터 로그에 남기는 에러 코드임. Row-Remapping은 GPU가 불량난 메모리 한 줄을 스스로 발견해서 안 쓰는 곳으로 우회시킨 기록인데, 이게 쌓이고 있으면 그 GPU 수명이 걱정되는 신호임.
6. DCGM으로 종합 진단
DCGM은 엔비디아가 공식으로 만든 "건강검진 종합세트" 도구임. PCIe, 메모리, 연산 유닛 등을 한 번에 훑어서 합격/불합격을 판정해 줌.
7. NCCL로 GPU 8장 협업 속도 측정
NCCL은 GPU들이 서로 데이터를 주고받을 때 쓰는 통신 라이브러리임. All-Reduce는 "8장이 각자 계산한 결과를 모아서 합치고 다시 나눠주는" 대표적인 협업 패턴으로, 3번에서 "선이 잘 꽂혔는지"만 봤다면, 여기서는 "실제로 그 선으로 얼마나 빠르게 데이터가 오가는지" 진짜 속도를 확인함.
8. FP8/FP4 연산 부하 테스트
FP8, FP4는 숫자를 얼마나 정밀하게(몇 비트로) 표현하느냐를 뜻함(정밀도를 살짝 낮추는 대신 훨씬 빠르게 계산). B300 GPU는 이 저정밀도 계산에 특화된 전용 회로(텐서코어)가 핵심 강점인데, 앞의 7번까지는 이 회로를 전혀 테스트 안 했어서 따로 부하를 줘봄.
9. 전력/발열 스트레스 테스트 (gpu_burn)
GPU 8장을 동시에 최대로 굴려서 일부러 뜨겁게, 전력을 많이 먹게 만듬. 이때 죽거나(DIED) 멈추는 GPU가 있는지, 온도나 전력이 위험 수준까지 가는지 확인.
10. 스트레스 후 재점검
9번 테스트로 GPU를 혹사시킨 "직후"에 5번(XID)이랑 온도 경고를 다시 확인해서, "혹사시켰더니 새로 문제가 생겼는지" 전후 비교를 함.
Stage 2 — Network & Storage
| Step | 항목 | 주요 확인 내용 | 주요 도구/명령 | 결과/판정 |
|---|---|---|---|---|
| A0 | NVMe Inventory | NVMe 개수, 모델, 용량, PCIe 연결 상태 확인 | nvme list, lspci | 예상 NVMe 전체 인식 |
| A1 | NIC / PCIe / NUMA | NIC Link Speed, PCIe Link, NUMA 위치 및 GPU와의 affinity 확인 | ethtool, lspci, numactl, nvidia-smi topo -m | 100Gbps 및 예상 NUMA topology |
| A2 | Network Throughput | Single/Multi Stream에서 TX/RX throughput 측정 | iperf3 | Multi-stream에서 목표 50Gbps 수준 달성 |
| A3 | Bidirectional Traffic | TX/RX 동시 부하에서 throughput 및 packet loss 확인 | iperf3 -d | 양방향 성능 저하/packet loss 없음 |
| A4 | Optical / NIC Health | Optical signal, CRC, FEC, RX/TX Error 등 확인 | ethtool -m, ethtool -S | 신호/에러 정상 |
| B1 | MinIO / AIStor Access | 외부 Object Storage에 대한 실제 PUT/GET throughput 측정 | mc, aws s3, benchmark tool(warp) | Network + Storage 포함 목표 성능 달성 |
| C1 | NVMe SMART Baseline | 테스트 전 NVMe Health / SMART 정보 수집 | nvme smart-log, smartctl | Media Error 등 이상 없음 |
| C2 | Sequential Write | 대용량 연속 Write 성능 및 sustained throughput 확인 | fio | 초기/지속 성능 모두 기준 충족 |
| C3 | Sequential Read | 대용량 Sequential Read 성능 측정 | fio | 모델 Load에 필요한 Read 성능 확보 |
| C4 | NVMe SMART Post-Test | Disk Stress 이후 SMART/Health 재확인 | nvme smart-log, smartctl | 테스트 후 신규 오류 없음 |
| D | Result Summary | GPU/NIC/NVMe/MinIO 전체 결과 종합 | Benchmark 결과 수집 | 검수용 Summary Table 생성 |
이 단계의 큰 그림: "다른 서버들과 데이터를 주고받는 속도"와 "로컬 하드디스크(NVMe)에 파일을 읽고 쓰는 속도"를 확인.
A0. 로컬 NVMe 디스크 목록 확인
NVMe가 몇 개가 꽂혀 있는지 먼저 확인.
A1. 네트워크 카드 속도 및 위치 확인
서버가 다른 서버와 통신할 때 쓰는 네트워크 카드(NIC-ConnectX6)가 제 속도(100Gbps)로 붙어있는지 확인. NUMA는 "이 카드가 CPU 몇 번 소켓 옆에 붙어있나"인데, GPU랑 너무 멀리 떨어져 있으면 미세하게 느려질 수 있어서 위치도 같이 확인.
A2. 혼자 통신 vs 여럿이 동시에 통신 (단일/멀티 스트림)
기존 Cluster는 네트워크 선이 2개 묶여서(LACP 본딩, 마치 2차선 도로를 하나처럼 쓰는 것) 총 50Gbps를 내는 구조임. 그런데 연결을 1개만 열면 구조상 25Gbps(한 차선)에 묶이고, 여러개를 동시에 열어야 두 차선을 다 써서 50Gbps 가까이 나옴. 이걸 실제로 숫자로 증명하는 단계임. 현재 비대칭 구조여서 GPU Node 쪽은 단순 참고용으로 확인.
A3. 양방향 동시 테스트
데이터를 "보내기만" 또는 "받기만"이 아니라 동시에 보내고 받을 때도 속도가 잘 나오는지 확인(실운영에서는 업로드/다운로드가 동시에 일어나는 경우가 많음)
A4. 광케이블/신호 품질 확인
네트워크 카드가 광케이블로 연결됐다면, 그 광신호 자체가 깨끗한지(신호 세기, 에러 카운트) 확인. 이건 "속도가 빠른가"와 별개로 "신호 품질이 나빠서 나중에 문제 생길 씨앗이 있는가"를 미리 보는 것임.
B1. MinIO AIStor 접속 속도
순수 네트워크 속도(A2)와 달리, 여기는 "실제로 파일을 읽고 쓸 때"의 속도라 디스크 처리 부담까지 포함된 더 현실적인 숫자임 -> 해당 테스트는 개발서버 쪽과 우선 진행
C1~C4. 로컬 NVMe 디스크 심층 테스트
- C1 (SMART 상태): SMART는 디스크가 스스로 보고하는 건강 상태임. 테스트 전에 미리 확인.
- C2 (200GB 연속 쓰기): NVMe는 처음엔 엄청 빠르다가(SLC 캐시라는 임시 고속 저장공간 덕분) 용량이 어느 정도 차면 갑자기 느려지는 경우가 많음. 실제로 큰 파일(수백GB짜리 AI 모델)을 저장할 때의 "진짜" 속도를 보려면 크게 넣어 봐야 함.
- C3 (읽기 테스트): 모델을 처음 불러올 때(콜드 스타트)의 최대 읽기 속도를 확인.
- C4 (SMART 재확인): 이렇게 혹사시킨 다음에 디스크 건강 상태가 나빠졌는지 다시 확인.
Stage 3a — vLLM Inference Performance
| Step | 시나리오 | 주요 확인 내용 | 주요 측정 지표 | 목적 |
|---|---|---|---|---|
| 3a1 | Dense 70B BF16 | 70B 모델을 BF16으로 서빙하고 1K/32K Context 비교 | TTFT, ITL, Input/Output tok/s, GPU Memory | Baseline 성능 확보 |
| 3a1 | Dense 70B FP8 | 동일 모델을 FP8으로 서빙 | TTFT, ITL, tok/s, GPU Memory | FP8 성능 향상 및 비용 효과 확인 |
| 3a1 | Prefix Caching | 반복되는 동일 Prefix에 대한 Cache 효과 측정 | TTFT, Prefill Time, Cache Hit | Prefix Cache 효과 확인 |
| 3a1 | DeepSeek-R1 | 초대형 MoE 모델의 8-GPU 서빙 가능 여부 및 성능 확인 | TTFT, ITL, tok/s, GPU Memory | 대형 모델 실서비스 가능성 확인 |
| 3a1 | Small 8B | 8B 모델로 GPU의 고성능 inference capability 측정 | Output tok/s, GPU Utilization, ITL | GPU/Engine 상한 성능 확인 |
| 3a2 | Engine / Parallelism Tuning | vLLM 설정 및 TP8 vs TP4×2 등 비교 | Throughput, TTFT, ITL, Memory | 최적 serving configuration 탐색 |
| 3a3 | Mixed Context | Short/Long Context 요청 혼합 | TTFT, ITL, Queue Time | 서로 다른 workload 간 간섭 확인 |
| 3a4 | Soak Test | 일정 시간 지속적인 inference workload 수행 | Throughput, Latency, Memory, GPU Temp | 장시간 안정성 및 성능 저하 확인 |
| 3a5 | Quantization Quality | BF16 vs FP8의 성능뿐 아니라 출력 품질 비교 | Accuracy / Quality, TTFT, tok/s | 양자화에 따른 품질 영향 확인 |
| 3a6 | Concurrency / Saturation | 동시 요청 수를 단계적으로 증가 | Concurrency, TTFT, ITL, tok/s, Queue | 최대 처리점 및 Saturation Point 확인 |
| 3a7 | GPU Scaling | TP1/TP2/TP4/TP8 성능 비교 | tok/s, tok/s/GPU, TTFT, ITL | GPU scaling efficiency 확인 |
| 3a8 | Prefix Cache A/B | 동일 workload를 Cache ON/OFF로 각각 수행 | TTFT, Prefill, Cache Hit, tok/s | 순수 Prefix Cache 효과 정량화 |
| 3a9 | Realistic RAG | 실제 RAG와 유사하게 Context 길이를 다양화 | TTFT, ITL, E2E Latency, tok/s | 실제 workload 성능 확인 |
| 3a10 | MemKV / External KV | GPU HBM 외부 KV 저장소 활용 | TTFT, ITL, KV transfer, GPU Memory | External KV의 효과 및 overhead 확인 |
이 단계의 큰 그림: "AI 모델을 실제 서비스처럼 돌렸을 때 얼마나 빠르고, 몇 명까지 동시에 버틸 수 있는가"를 확인. vLLM은 대형 언어모델을 실제로 서비스(질문 받고 답 생성)할 수 있게 해주는 소프트웨어임.
먼저 자주 나오는 용어부터:
- TTFT (Time To First Token): 질문을 보낸 후 답변의 "첫 글자"가 나오기까지 걸리는 시간. 사람이 체감하는 "얼마나 빨리 반응하나"에 가장 직결됨.
- ITL (Inter-Token Latency): 답변이 시작된 후 한 글자(토큰)씩 나오는 간격. 이게 짧을수록 답변이 술술 나오는 느낌임.
- 동시성(Concurrency): 동시에 몇 명이 질문을 던지고 있는가.
- 양자화(Quantization, BF16/FP8): 위 Stage1의 8번과 같은 개념 — 계산 정밀도를 낮춰서 속도를 올리는 기법. BF16이 기본(더 정밀), FP8이 더 빠른 대신 살짝 부정확해질 수 있는 방식임.
기본 5개 시나리오
1. Dense70B, BF16, 짧은/긴 질문
70B(700억 개 파라미터, 모델의 "크기") 모델을 기본 정밀도로 돌려서 기준점을 잡음. 짧은 질문(1024토큰 입력)과 긴 질문(32768토큰, 예: 긴 문서 첨부)을 나눠서 보는 이유는, 짧은 질문은 "답변 생성 속도"가 중요하고 긴 질문은 "질문을 읽어들이는 속도(프리필)"가 병목이라 성격이 다르기 때문임.
2. Dense70B, FP8
같은 모델을 양자화(FP8)해서 돌려보고 1번과 비교. "정밀도를 낮췄더니 실제로 얼마나 빨라지나"를 실측.
3. Prefix Caching(같은 앞부분 재사용) 검증
챗봇은 보통 같은 시스템 설명(프롬프트)을 매번 반복해서 받음. Prefix Caching은 "어차피 같은 내용이니 처음 계산한 걸 저장해뒀다가 재사용"하는 기능임. 이걸 켜면 반복되는 긴 문서를 다시 계산 안 해도 되니 훨씬 빨라지는지 확인.
4. DeepSeek-R1 (초대형 모델)
70B보다 훨씬 큰(6710억 개 파라미터) 모델을 실제로 올려서 서빙되는지 확인. B300 GPU 8장이 가진 큰 메모리 용량을 제대로 활용할 수 있는지 증명하는 시나리오임.
5. 소형 8B 모델
아주 작은 모델(80억 개 파라미터)을 돌려서, "메모리가 병목이 아닐 때 이 GPU가 낼 수 있는 최고 속도"를 확인. 큰 모델 테스트만으로는 GPU의 순수 최고 속도를 알기 어렵기 때문임.
심화 검증(3a2~3a10)
기본 5개로는 "일단 돌아간다"까지만 확인되고, 실제로 서비스에 올리기 전에 더 봐야 할 것들로 구성.
| 단계 | 무엇을 보는가 | 왜 필요한가 |
|---|---|---|
| 3a2 | 서버 설정값(배치 크기 등)을 이것저것 바꿔보고, GPU 8장을 하나로 쓸지(TP8) 4장씩 두 묶음으로 쓸지(TP4x2) 비교 | 기본값이 최선이 아닐 수 있어서 최적 설정을 찾음 |
| 3a3 | 짧은 질문과 긴 질문이 동시에 섞여 들어올 때 서로 방해하는지 | 실제 운영에선 항상 섞여서 들어옴 |
| 3a4 | 몇 시간 계속 서비스를 돌려도 점점 느려지지 않는지(Soak, 장시간 부하테스트) | 짧은 테스트로는 서서히 나빠지는 문제를 못 잡음 |
| 3a5 | 양자화(FP8)했을 때 답변의 "정확도"가 떨어지는지 | 지금까지는 속도만 봤지 정답 품질은 한 번도 확인 안 했음 |
| 3a6 | 동시 사용자를 계속 늘렸을 때 어디서 무너지는지(포화점) | "몇 명까지 버티는지" 용량 산정에 필수 |
| 3a7 | GPU 1/2/4/8장으로 나눠 쓸 때 성능이 어떻게 변하는지 | GPU를 여러 장 묶을 때 생기는 통신 손실을 정량화 |
| 3a8 | Prefix Caching을 켰을 때 vs 껐을 때 정확히 비교 | 3번 시나리오는 "켰을 때"만 봤어서, 진짜 효과를 보려면 꼭 비교 필요 |
| 3a9 | RAG처럼 길이가 들쭉날쭉한 질문 | 지금까지 테스트는 길이가 항상 고정값이라 현실과 다름 |
| 3a10 | 내부(NVMe)와 외부 저장장치(MemKV)를 GPU 메모리의 보조 저장공간처럼 쓸 때 이득이 있는지 | GPU 메모리가 꽉 찼을 때 다시 계산 안 하고 불러오기만 할 수 있는지 확인 |
Stage 3a 주요 성능 지표
| 지표 | 의미 | 중요도 |
|---|---|---|
| TTFT | 요청 후 첫 Token까지 걸리는 시간 | ★★★★★ |
| ITL | Token 간 생성 간격 | ★★★★★ |
| Input tok/s | Prompt/Prefill 처리 속도 | ★★★★☆ |
| Output tok/s | Decode 처리 속도 | ★★★★★ |
| Total tok/s | 전체 Token 처리량 | ★★★★★ |
| tok/s/GPU | GPU 1장당 처리량 | ★★★★★ |
| Concurrency | 동시 처리 요청 수 | ★★★★☆ |
| Queue Time | 요청이 실제 처리되기 전 대기 시간 | ★★★★★ |
| KV Cache Utilization | KV Cache 사용률 | ★★★★★ |
| GPU Memory | HBM 사용량 | ★★★★★ |
| GPU Utilization | GPU 연산 사용률 | ★★★★☆ |
| HBM Bandwidth | HBM 메모리 대역폭 사용량 | ★★★★☆ |
| Power | GPU 전력 사용량 | ★★★☆☆ |
| Temperature | GPU 온도 | ★★★☆☆ |
| Error / OOM | CUDA/XID/OOM 등 오류 | ★★★★★ |
