26O01a

About this offer

전체 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 등 오류 ★★★★★