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 spikeStage1 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
↓
FP4quantization을 통해 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은 다음 질문에 답합니다.
① GPU 8장이 모두 정상인가?
② HBM이 정상인가?
③ 장시간 부하를 견디는가?
④ FP8/FP4 계산 path가 정상인가?
⑤ 열/전력 문제가 없는가?
⑥ NVLink/NCCL이 정상인가?
↓
Hardware PASS?Stage3a는 그 다음 질문입니다.
① inference가 정상 동작하는가?
② TTFT/ITL은 정상인가?
③ long context도 처리되는가?
④ short + long이 섞여도 안정적인가?
⑤ concurrency를 어디까지 올릴 수 있는가?
⑥ prefix cache가 실제 hit하는가?
⑦ 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되는지, 결과가 반복 가능한지까지 밝혀내는 것이 실제 운영 장애 예방에 더 큰 가치가 있습니다.
===
