26O07a

Об этом предложении

좋습니다. 지금까지 구성한 B300 ×8 bare-metal acceptance 관점 에서 보면 Stage1과 Stage3a는 역할이 명확히 다릅니다. Stage1 = “GPU 서버 하드웨어 자체를 믿을 수 있는가?” Stage3a = “그 하드웨어 위에서 vLLM inference가 실제 서비스에 사용할 만큼 정상적으로 동작하는가?” 따라서 Stage1을 통과하고 Stage3a에서 문제가 생기면 HW 고장보다는 vLLM 설정, workload 특성, KV cache, concurrency, scheduler, 모델/TP 구성 쪽으로 원인 범위를 크게 좁힐 수 있습니다. 1. 전체 구조부터 보면 B300 × 8 Acceptance │ ┌──────────────────┴──────────────────┐ │ │ Stage1 Stage3a Hardware 검증 vLLM Serving 검증 │ │ ┌─────────┼──────────┐ ┌───────────┼────────────┐ │ │ │ │ │ │ GPU/HBM Stress NVLink/NCCL Basic Mixed Saturation │ │ │ Inference Workload │ │ │ │ │ │ │ ECC/XID 장시간 GPU↔GPU TTFT/ITL 간섭 영향 최대 동시성 온도/전력 안정성 통신 │ │ │ │ │ │ └─────┬─────┘ │ │ │ │ │ │ └─────────┴──────────┘ Prefix Cache ───── KV Tier │ ▼ "HW를 믿어도 되는가?" "서비스 가능한가?" 이 관점으로 각 step을 이해하면 훨씬 쉽습니다. 2. Stage1 — GPU 하드웨어 검증 Stage1의 목적은 단순히 nvidia-smi 에서 GPU 8장이 보이는지를 확인하는 것이 아닙니다. “B300 8장이 장시간 inference 서비스를 받아도 계산 오류, GPU reset, ECC, thermal throttling, GPU 간 통신 이상 없이 안정적으로 동작하는가?” 를 검증하는 단계입니다. Stage1 항목 무엇을 시험하나 목적 실제 운영에서 문제라면 나타나는 현상 GPU 기본 인식 B300 8장, driver/CUDA/Fabric Manager 서버 기본 구성 정상 확인 GPU 누락, Pod GPU 할당 실패 DCGM diagnostics GPU/HBM/PCIe 등 진단 HW 초기 불량 탐지 CUDA error, GPU unhealthy GPU Burn 8 GPU 장시간 고부하 지속 부하 안정성 inference 중 GPU reset/XID FP8 실제 FP8 연산 AI inference precision path 확인 FP8 모델에서 crash/성능 이상 FP4 실제 FP4 연산 가능 여부 B300 저정밀 inference path 확인 FP4 모델/커널 실행 문제 Telemetry clock/temp/power/throttle 열/전력 안정성 시간이 지나며 TPS 하락 ECC/XID GPU 오류 counter HW 오류 탐지 랜덤 inference 실패 Row Remapper HBM defect/remap 메모리 열화 확인 HBM 관련 불안정 NVLink GPU 간 link 8 GPU 연결 상태 확인 TP 모델 성능 저하 NCCL collective 통신 실제 GPU↔GPU 통신 검증 TP2/4/8 성능 저하/timeout Stage1에서 특히 중요한 관계 예를 들어 운영 중 이런 문제가 있다고 합시다. 처음에는 inference가 잘 됨 ↓ 30분 후 TPS 감소 ↓ 간헐적으로 latency spike Stage1 telemetry에서: GPU temperature ↑ GPU clock ↓ thermal throttle = YES 였다면 vLLM 문제가 아니라 냉각/전력/HW 문제 일 가능성이 높습니다. 반대로: GPU Burn 4h PASS DCGM PASS ECC = 0 XID = 0 Throttle = 0 인데 vLLM에서만 문제가 발생한다면 Stage3a 영역을 먼저 의심할 수 있습니다. 3. FP8 / FP4 테스트를 따로 넣은 이유 이번에 개선한 부분이 특히 중요합니다. 기존 FP8 시험은 GPU를 순차적으로 실행해서 실제 GPU당 부하 시간이 짧았고 FP4도 포함되지 않았습니다. 개선한 시험은 개념적으로: GPU0 ─ FP8 ┐ GPU1 ─ FP8 │ GPU2 ─ FP8 │ ... ├── 동시에 지속 부하 GPU7 ─ FP8 ┘ ↓ 동일하게 FP4 입니다. 이것은 실제 inference가 BF16만 사용하는 환경과 달리 FP8/FP4 Tensor Core path가 정상인가 를 확인하기 위한 것입니다. 특히 앞으로: BF16 ↓ FP8 ↓ FP4 quantization을 통해 GPU당 처리량을 높일 계획이라면 중요합니다. 다만 FP4가 환경의 실제 library/kernel에서 지원되지 않으면 BF16으로 몰래 대체해서 PASS시키면 안 되고 UNSUPPORTED/FAIL 로 구분해야 합니다. 4. NVLink/NCCL이 중요한 이유 8개의 B300으로 큰 모델을 TP8로 서비스한다고 생각하면: 하나의 요청 │ ┌─────────┴─────────┐ │ Tensor Parallel 8 │ └─────────┬─────────┘ │ GPU0 ↔ GPU1 ↔ GPU2 ↔ ... ↔ GPU7 NVLink 이 됩니다. 따라서 GPU 자체가 아무리 정상이어도 GPU 간 통신에 문제가 있으면: TP1 정상 TP2 약간 이상 TP4 느림 TP8 매우 느림 같은 현상이 생길 수 있습니다. 그래서 NVLink 상태 확인 → NCCL 실제 collective test → Stage3a TP inference 가 연결됩니다. 5. Stage3a — vLLM 실제 inference 검증 Stage1을 통과한 다음에는 질문이 바뀝니다. “GPU가 정상인가?” 에서 “이 GPU를 vLLM inference 서비스로 실제 사용할 수 있는가?” 가 됩니다. Stage3a는 그래서 단순 benchmark가 아니라 serving behavior qualification 에 가깝습니다. 6. Stage3a 기본 inference 가장 먼저 확인하는 것은 정상적인 request/response입니다. Client │ ▼ vLLM OpenAI API │ ▼ Llama 70B │ ▼ B300 ×8 여기서 기본적으로 확인하는 것이: 요청 성공 여부 TTFT ITL Request throughput Output tokens/sec GPU utilization HBM/KV 상태 입니다. TTFT와 ITL은 의미가 다릅니다. 요청 ─────────────── 첫 token ← TTFT → 첫 token → token → token → token ←ITL→ TTFT 가 나쁘면 사용자는 “답변을 시작하지 않는다”고 느끼고, ITL 이 나쁘면 답변 생성 자체가 끊기거나 느리다고 느낍니다. 7. Short / Long Context 시험 Inference workload는 prompt 길이에 따라 성격이 크게 달라집니다. Short prompt 1K tokens ↓ 상대적으로 가벼운 prefill Long prompt 32K tokens ↓ 큰 prefill ↓ KV cache 소비 증가 ↓ TTFT 증가 실제 서비스에서는 특히 문서 분석/RAG에서 long context가 많이 발생할 수 있으므로 중요합니다. Stage3a에서 short만 빠르다고 실제 서비스가 빠른 것은 아닙니다. 8. Stage3a3 — Mixed Workload 이번에 많이 개선한 시험입니다. 목적은 간단합니다. 긴 요청이 들어올 때 짧은 interactive 요청이 얼마나 피해를 받는가? 예를 들어 실제 서비스에서는: 사용자 A "간단히 요약해줘" │ │ short ▼ vLLM ▲ │ 32K document │ 사용자 B "이 문서 분석해줘" 가 동시에 발생합니다. 우리가 알고 싶은 것은: Short alone TTFT = 45 ms Long request와 같이 실행 Short TTFT = ? 입니다. 9. Stage3a3에서 Crossover를 넣은 이유 기존 시험에서 -80% 같은 이상한 결과가 나왔습니다. 즉: isolated보다 mixed가 훨씬 빠름 이라는 결과였습니다. 이는 workload interference라기보다 warm-up/order effect 가능성이 컸습니다. 그래서 현재는: R0 ISO → MIX discard R1 MIX → ISO retain R2 ISO → MIX retain R3 MIX → ISO retain R4 ISO → MIX retain 으로 바꿨습니다. 그리고 각 round마다: (MIX TTFT - ISO TTFT) --------------------- × 100 ISO TTFT 를 계산합니다. 최종적으로는 단순 평균보다 paired degradation median 을 중요하게 봅니다. 10. Stage3a3의 Stability가 중요한 이유 예를 들어: Round1 -2% Round2 +11% Round3 -1% Round4 +12% 이면 median 하나만 계산해서: 약 +5% 라고 하는 것은 위험합니다. 실제로는 결과 방향이 계속 뒤집히기 때문입니다. 그래서 현재는: paired degradation direction consistency AB degradation BA degradation AB/BA order delta 까지 확인합니다. 결과가 불안정하면: UNSTABLE REVIEW_REQUIRED 로 처리합니다. 이것은 실제 운영에서도 중요합니다. 평균 성능은 좋아도 요청마다 latency가 크게 흔들리는 서비스는 사용자 입장에서는 좋지 않은 서비스 이기 때문입니다. 11. Stage3a6 — Saturation Test 이 시험은 실서비스 capacity planning과 가장 직접적으로 연결되는 시험 중 하나입니다. 질문은: “이 서버가 동시 사용자를 어디까지 정상적으로 감당하는가?” 입니다. 현재 개선된 시험은: C64 ↓ 128 ↓ 192 ↓ 256 ↓ 384 ↓ 512 ↓ 768 ↓ 1024 ↓ 1536 ↓ 2048 까지 필요에 따라 자동 확장합니다. 하지만 중요한 것은 C1024가 실행됐다고 C1024를 서비스할 수 있다는 뜻이 아니라는 점 입니다. 12. Saturation에서 Running / Waiting을 보는 이유 예를 들어 C1024 요청을 넣었는데: Client concurrency = 1024 vLLM ├─ running = 380 └─ waiting = 644 일 수 있습니다. 즉 GPU가 실제로 1024 request를 동시에 처리하는 것이 아닙니다. 그래서: C512 Output TPS = 19,500 Waiting = 100 C768 Output TPS = 19,700 Waiting = 370 C1024 Output TPS = 19,650 Waiting = 620 이면 C768/1024는 capacity 증가가 아니라 queue 증가 입니다. 그래서 개선된 Stage3a6는: SLO_CLIFF THROUGHPUT_PLATEAU QUEUE_SATURATION 을 구분합니다. 실제 LiteLLM 등의 concurrency limit를 정할 때도 maximum executable concurrency 보다 maximum SLO-compliant concurrency 가 훨씬 중요한 값입니다. 13. Stage3a8 — Prefix Cache 이것도 이번에 개선한 핵심 시험입니다. 실제 서비스에서 다음과 같은 요청이 반복된다고 생각하면 됩니다. 32K 공통 문서 + 질문 A 32K 공통 문서 + 질문 B 32K 공통 문서 + 질문 C 공통 32K를 매번 GPU가 다시 prefill하는 것은 낭비입니다. Prefix Cache가 정상이라면: Request #1 32K Prefix ↓ KV 생성 ↓ Cache Request #2 같은 32K Prefix ↓ Cache HIT ↓ prefill 일부 생략 ↓ TTFT 감소 가 됩니다. 14. 기존 Prefix Cache 시험의 한계 기존 결과가: OFF 202.7 ms ON 194.7 ms 약 4% 개선 이었다고 해서 바로 Prefix Cache PASS라고 할 수 없었습니다. 왜냐하면: 정말 cache hit가 발생해서 빨라진 것인가? 아니면 단순 measurement variation인가? 를 구분하지 못했기 때문입니다. 그래서 개선한 Stage3a8은 실제 vLLM counter를 봅니다. vllm:prefix_cache_queries vllm:prefix_cache_hits 시험 전후: queries_before hits_before ↓ requests queries_after hits_after 를 측정해서: hit rate = Δhits -------- × 100 Δqueries 를 계산합니다. 15. Prefix Cache는 Functional과 Performance를 분리 이것도 acceptance에서 중요합니다. 예를 들어: Hit Rate = 80% TTFT 개선 = 4% 라면: Functional PASS Performance LOW / small benefit 입니다. 반대로: TTFT 개선 = 10% Hit count = 0 이면: Functional FAIL 또는 REVIEW_REQUIRED Performance INCONCLUSIVE 입니다. 즉 “기능이 동작한다”와 “성능 효과가 크다”를 같은 PASS로 묶지 않습니다. 16. Stage3a10 — KV Cache Tier Prefix Cache와 KV Tier는 비슷해 보여도 질문이 다릅니다. Prefix Cache는: "이전에 계산한 prefix KV를 재사용할 수 있는가?" 이고 KV Tier는: "GPU HBM에 다 못 두는 KV를 다른 저장 계층으로 내렸다가 효율적으로 복원할 수 있는가?" 입니다. 현재 환경에서는: GPU HBM │ ▼ Local NVMe │ ▼ AIStor / MinIO object TCP/TLS 관점으로 보는 것이 적절합니다. MemKV native TCP는 별도 qualification이고 RDMA MemKV는 현재 환경에서는 N/A입니다. 17. KV Tier가 실서비스에서 중요한 경우 동시 세션이 많아지거나 context가 길어지면: 사용자 증가 ↓ KV 증가 ↓ GPU HBM 압박 ↓ eviction ↓ recompute / restore ↓ TTFT 증가 가 발생할 수 있습니다. 따라서 Stage3a10은 단순 storage benchmark가 아니라 KV pressure가 실제 inference latency/capacity에 미치는 영향 을 보는 시험입니다. 18. Stage1 ↔ Stage3a를 연결하면 장애 원인 분석이 쉬워집니다 실제 운영 장애를 아래처럼 매핑할 수 있습니다. 실제 증상 먼저 볼 시험/지표 의심 영역 GPU가 간헐적으로 죽음 Stage1 Burn/ECC/XID HW/driver 장시간 후 성능 저하 Stage1 telemetry 온도/전력/throttle TP8만 유독 느림 Stage1 NVLink/NCCL GPU interconnect FP8 모델만 이상 Stage1 FP8 precision/kernel FP4 모델만 실패 Stage1 FP4 FP4 SW/kernel/HW path 첫 token이 느림 Stage3a TTFT prefill/scheduler/KV 생성 속도가 느림 Stage3a ITL decode/GPU scheduling 긴 문서만 느림 Long-context test prefill/KV pressure 긴 요청이 들어오면 chat 느림 Stage3a3 mixed workload interference 사용자 증가 시 latency 폭증 Stage3a6 saturation/queue C768 이후 TPS 그대로 Stage3a6 throughput plateau waiting만 계속 증가 Stage3a6 scheduler/queue saturation 반복 문서인데 TTFT 안 줄음 Stage3a8 prefix cache prefix hit=0 Stage3a8 prefix mismatch/cache config context 많을 때 HBM 부족 Stage3a10 KV capacity NVMe KV는 좋은데 remote가 느림 Stage3a10/Stage2c storage/network 19. Acceptance 관점에서는 이렇게 이해하면 가장 쉽습니다 Stage1은 다음 질문에 답합니다. 1 GPU 8장이 모두 정상인가? 2 HBM이 정상인가? 3 장시간 부하를 견디는가? 4 FP8/FP4 계산 path가 정상인가? 5 열/전력 문제가 없는가? 6 NVLink/NCCL이 정상인가? ↓ Hardware PASS? Stage3a는 그 다음 질문입니다. 1 inference가 정상 동작하는가? 2 TTFT/ITL은 정상인가? 3 long context도 처리되는가? 4 short + long이 섞여도 안정적인가? 5 concurrency를 어디까지 올릴 수 있는가? 6 prefix cache가 실제 hit하는가? 7 KV pressure/tiering이 정상인가? ↓ Serving PASS? 그리고 그 다음 Stage7에서 비로소: GLM-5.3 Qwen3.6 gpt-oss DeepSeek PaddleOCR Docling ... 실제 운영 모델을 올려 “우리 서비스 workload에서 얼마만큼의 capacity가 나오는가?” 를 검증합니다. 즉 전체 흐름은: Stage1 "HW 정상?" │ ▼ Stage2 "Network / NVMe / Storage 정상?" │ ▼ Stage3a "vLLM serving 정상?" │ ▼ Stage6 "Kubernetes 위에서도 동일하게 정상?" │ ▼ Stage7 "실제 운영 모델/워크로드 capacity는?" │ ▼ Production Profile TP / concurrency / quota / replica / SLO 라고 이해하면 됩니다. 특히 Stage1은 HW 불량을 걸러내는 시험, Stage3a는 serving engine의 병목과 한계를 찾는 시험 이라는 구분이 가장 중요합니다. Stage3a에서 숫자가 높게 나오는 것 자체보다, 왜 느려지는지 , 어디서 saturation되는지 , 결과가 반복 가능한지 까지 밝혀내는 것이 실제 운영 장애 예방에 더 큰 가치가 있습니다. ===