26O07d
네. 지금까지의 acceptance 흐름에서 Stage7은 Stage1/Stage6와 목적이 완전히 다릅니다.
- Stage1: B300 HW 자체를 신뢰할 수 있는가?
- Stage3a: bare-metal vLLM의 serving 특성은 어떤가?
- Stage6: Kubernetes로 옮겨도 GPU/NCCL/network/vLLM 특성이 유지되는가?
- Stage7: 실제로 사용할 각 모델을 B300 환경에서 어떤 설정으로 운영해야 가장 효율적인가?
따라서 Stage7의 최종 산출물은 단순 PASS/FAIL이 아니라 모델별 Production Profile이어야 합니다.
1. Stage7의 최종 목표
예를 들어 최종적으로 이런 표를 만드는 단계라고 보면 됩니다.
| Model | Precision | TP | max-model-len | max-num-seqs | gpu-mem-util | Prefix | Concurrency | Replica | SLO |
|---|---|---|---|---|---|---|---|---|---|
| GLM-5.3 | FP8 | 8 | ... | ... | ... | ON | ... | 1 | ... |
| Qwen3.6-35B-A3B | FP8 | 2 | ... | ... | ... | ON | ... | 2 | ... |
| gpt-oss-20b | ... | 1 | ... | ... | ... | ... | ... | ... | ... |
| DeepSeek-V4.1-Flash | ... | ... | ... | ... | ... | ... | ... | ... | ... |
| PaddleOCR-VL-1.6 | ... | ... | ... | ... | ... | ... | ... | ... | ... |
여기에 단순 vLLM parameter만 있는 것이 아니라:
GPU / replica
TP
precision / quantization
max-model-len
max-num-seqs
gpu-memory-utilization
chunked prefill
prefix cache
KV strategy
concurrency limit
RPM / TPM
TTFT / ITL SLO
Output TPS
local model cache requirement
startup time까지 포함하는 것이 좋습니다.
그리고 이 결과가 나중에:
Stage7
│
├── vLLM Deployment values
├── InferencePool/EPP
├── LiteLLM model config
├── LiteLLM RPM/TPM/concurrency quota
└── capacity / replica planning으로 연결됩니다.
2. Stage7 실행 전 필수 전제조건
Stage7은 Stage6가 끝나지 않은 상태에서 시작하지 않는 것을 권합니다.
최소 Gate는:
Stage1 PASS
↓
Stage3a baseline 확보
↓
Stage6 preflight PASS
├ GPU Operator
├ GPU 1/8 smoke
├ topology
└ DCGM
↓
Stage6c PASS
↓
Stage6a NCCL PASS
↓
Stage6b Network PASS
↓
Stage6e AIStor PASS
↓
Stage6k basic/mixed/saturation PASS
↓
Stage7입니다.
6h/6i 같은 NetworkPolicy/Hubble은 production readiness 측면에서는 필요하지만, 모델 parameter 탐색 자체를 시작하기 위한 hard prerequisite까지는 아닙니다.
6f resilience 역시 Stage7 전에 할 필요 없습니다.
3. 가장 중요한 전제: 모델을 고정해야 함
Stage7에서는 단순히:
GLM-5.3만 기록하면 부족합니다.
반드시:
model
repository
revision / commit
weight format
quantization
tokenizer revision
vLLM version
CUDA
driver
container image digest를 고정해야 합니다.
예:
model:
name: GLM-5.3
repository: ...
revision: ...
tokenizer_revision: ...
runtime:
vllm: 0.30.0
image: ...
image_digest: sha256:...
precision:
dtype: ...
quantization: ...Stage7 도중 모델 revision이나 container가 바뀌면 이전 결과와 이후 결과를 같은 dataset으로 취급하면 안 됩니다.
4. 모델 파일은 먼저 local NVMe에 준비
Stage7 benchmark 중 모델 다운로드 시간을 섞지 않는 것이 중요합니다.
권장 구조는:
AIStor / MinIO
│
│ source of truth
▼
B300 local NVMe
/mnt/local-nvme-cache/models/
│
├ GLM-5.3/
├ Qwen3.6-35B-A3B/
├ gpt-oss-20b/
├ DeepSeek-V4.1-Flash/
└ ...
│
▼
vLLM Pod입니다.
Stage7 performance test에서는 기본적으로 warm local model cache를 사용합니다.
AIStor → NVMe cold model load 성능은 별도 storage/startup test로 분리하는 편이 좋습니다.
5. 모델별 실제 workload를 먼저 정의
Stage7에서 가장 흔히 생기는 문제가 모든 모델에:
input=1024
output=512
concurrency=64를 똑같이 넣고 성능을 비교하는 것입니다.
그렇게 하면 실제 production capacity와 상당히 다른 결과가 나올 수 있습니다.
현재 계획을 기준으로 모델군을 최소한:
① Ontology / Reasoning
GLM-5.3
Qwen3.6-35B-A3B
gpt-oss-20b
② Online discovery
DeepSeek-V4.1-Flash
GLM-5.3-Flash
③ Document / Vision
PaddleOCR-VL-1.6
docling-layout-heron
docling-models
DocumentFigureClassifier로 나누는 것이 좋습니다.
그리고 각각에 production workload profile을 만들어야 합니다.
예를 들어 LLM이면:
interactive-short
input P50/P95
output P50/P95
long-context
input P50/P95
output P50/P95
mixed
short : long 비율
prefix-reuse
예상 shared prefix 길이
예상 reuse ratio를 정의합니다.
Document/VLM 계열은 token benchmark와 별개로:
pages/document
image resolution
PDF size
pages/sec
documents/sec
batch size
GPU memory
end-to-end latency가 중요합니다.
즉 Stage7 LLM test와 Document/VLM test harness는 같으면 안 됩니다.
6. Stage7에서 처음부터 모든 parameter 조합을 brute-force하지 않음
예를 들어:
TP 1/2/4/8
precision BF16/FP8/FP4
concurrency 1~2048
max-num-seqs 여러 값
gpu-mem-util 여러 값
context 여러 값을 Cartesian product로 돌리면 시험량이 폭발합니다.
대신 coarse → fine 탐색이 좋습니다.
Model qualification
↓
Precision
↓
TP
↓
Memory parameters
↓
Concurrency
↓
Workload
↓
Feature
↓
Soak순으로 후보를 계속 줄입니다.
7. Stage7-1 — 모델 Functional Qualification
가장 먼저 각 모델이 현재 runtime에서 제대로 뜨는지 확인합니다.
Model load
↓
Ready
↓
single request
↓
short input
↓
long input
↓
expected output
↓
no CUDA error
↓
no XID/ECC이 단계에서는 성능 최적화를 하지 않습니다.
목표는:
이 모델/version이 현재 vLLM/B300 환경에서 정상적으로 실행 가능한가?
입니다.
실패하는 모델은 parameter search 대상에서 제외합니다.
8. Stage7-2 — Precision 결정
그다음 모델별 precision 후보를 찾습니다.
예:
BF16
↓
FP8
↓
FP4 (지원되는 모델/runtime일 경우)비교할 것은 단순 TPS만이 아닙니다.
model load success
HBM
TTFT
ITL
Output TPS
quality
error
kernel/runtime stability를 같이 봅니다.
예를 들어:
BF16
HBM 150GB
TPS 1.0x
quality baseline
FP8
HBM 90GB
TPS 1.5x
quality acceptable
FP4
HBM 55GB
TPS 1.9x
quality degradation이라면 production 후보는 FP8이 될 수 있습니다.
Stage7에서는 quality gate가 반드시 필요합니다.
Stage1 FP8/FP4는 hardware/kernel sanity였고, Stage7 FP8/FP4는 해당 모델의 품질 + 성능 선택 문제입니다.
9. Stage7-3 — 최소 TP 탐색
그다음 가장 중요한 parameter가 TP입니다.
가능하면:
TP1
↓
TP2
↓
TP4
↓
TP8순서로 모델이 들어가는 최소 TP부터 시작합니다.
목표는 무조건 TP8이 아닙니다.
예를 들어:
Qwen model
TP1
OOM
↓
TP2
PASS
↓
TP4
PASS
↓
TP8
PASS라면 TP2/4/8을 비교합니다.
왜냐하면:
TP8 × replica 1보다:
TP2 × replica 4가 production aggregate throughput에서 훨씬 유리할 수도 있기 때문입니다.
따라서 Stage7에서는:
가장 빠른 TP
보다
SLO를 만족하면서 GPU당 throughput이 가장 좋은 TP
를 찾는 것이 중요합니다.
10. TP 평가 metric
TP마다 최소:
TTFT P50/P95/P99
ITL P50/P95/P99
Output TPS
Request/s
HBM/GPU
GPU util
power
NCCL traffic을 기록합니다.
그리고:
Output TPS / GPU도 계산하세요.
예:
TP2 = 1,000 tok/s
→ 500 tok/s/GPU
TP4 = 1,600 tok/s
→ 400 tok/s/GPU
TP8 = 2,200 tok/s
→ 275 tok/s/GPU라면 TP8이 절대 TPS는 가장 높지만 cluster capacity 관점에서는 TP2가 더 효율적일 수 있습니다.
11. Stage7-4 — Memory/runtime parameter 탐색
Precision과 TP 후보가 정해지면:
gpu-memory-utilization
max-model-len
max-num-seqs
chunked-prefill등을 조정합니다.
예를 들어:
gpu-memory-utilization
0.80
↓
0.85
↓
0.90
↓
0.92
↓
0.95처럼 탐색할 수 있습니다.
목표는 0.95를 쓰는 것이 아니라:
충분한 KV capacity
+
OOM safety margin
+
stable latency사이의 적정점을 찾는 것입니다.
Production에서는 acceptance benchmark 최대값보다 약간의 여유를 두는 것이 좋습니다.
12. Stage7-5 — Saturation search
여기서 Stage3a6/Stage6k saturation 방법을 그대로 재사용하면 됩니다.
예:
C1
C2
C4
C8
C16
C32
C64
C128
...또는 모델 특성에 맞는 범위로 시작합니다.
관찰:
TTFT
ITL
Output TPS
request/s
vllm:num_requests_running
vllm:num_requests_waiting
vllm:kv_cache_usage_perc
GPU util
HBM그리고:
Throughput
│
│ ______
│ /
│ /
│ /
│_______/____________ Concurrency
↑
knee point을 찾습니다.
13. 최대 concurrency와 production concurrency를 구분
Stage7에서 매우 중요합니다.
예를 들어:
C256
TPS 1000
TTFT P99 2.5s
C384
TPS 1250
TTFT P99 4.0s
C512
TPS 1300
TTFT P99 8.5s
C768
TPS 1310
TTFT P99 20s라면 실행 가능한 최대치는 C768일 수 있지만 production 설정은 C384 정도가 될 수 있습니다.
즉:
max executable concurrency ≠ production concurrency입니다.
Stage7 결과에는 둘을 별도로 기록하세요.
14. Stage7-6 — 실제 workload mix
이제 synthetic saturation에서 끝내지 않고 실제 traffic 형태를 넣습니다.
예:
short interactive 60%
medium 25%
long context 10%
very-long 5%같은 분포입니다.
Stage3a3에서 만든 balanced crossover 방식도 여기서 매우 유용합니다.
특히:
long request가 들어왔을 때
short request TTFT가 얼마나 악화되는가?를 모델별로 확인합니다.
15. Stage7-7 — Prefix Cache
실제 서비스에서 system prompt, ontology, agent context 등이 반복된다면 매우 중요합니다.
Stage6k-prefix와 동일하게:
Cold
↓
same exact prefix
↓
Warm을 테스트합니다.
그리고:
prefix_cache_queries
prefix_cache_hits
cold TTFT
warm TTFT
hit rate를 측정합니다.
단순히:
--enable-prefix-caching을 켜면 빠를 것이라고 가정하면 안 됩니다.
실제 workload의 prefix reuse가 낮으면 오히려 production sizing에서 중요한 feature가 아닐 수도 있습니다.
16. Stage7-8 — KV tier
KV offload가 필요한 모델만 수행합니다.
우선순위는 현재 환경에서는:
HBM
↓
local NVMe
↓
remote tier입니다.
비교:
none
local_nvme
remote_object
memkv_tcp다만 AIStor/MinIO remote_object와 native MemKV TCP는 계속 별개의 tier로 유지합니다.
측정:
TTFT
ITL
TPS
KV hit
restore latency
restore bandwidth
network traffic그리고 remote tier가 실제 이득이 없으면 굳이 production architecture에 넣지 않습니다.
17. Stage7-9 — Soak
최종 후보 설정만 장시간 테스트합니다.
모든 조합을 soak할 필요 없습니다.
예:
GLM candidate #1
Qwen candidate #1
gpt-oss candidate #1
...만 대상으로:
2h / 4h / 필요 시 8h운영합니다.
관찰:
TTFT drift
ITL drift
TPS drift
GPU temp
clock
power
HBM
ECC
XID
Pod restart
OOM
request error첫 5~10분은 measurement에서 제외합니다.
18. 최종적으로 replica 계산
예를 들어 Stage7 결과가:
Qwen
TP2
production concurrency = 64
output TPS = 500
SLO PASS라면 B300 8 GPU node에서:
GPU0-1 replica A
GPU2-3 replica B
GPU4-5 replica C
GPU6-7 replica D즉:
TP2 × 4 replicas를 후보로 계산할 수 있습니다.
반면 GLM이 TP8을 요구한다면:
GPU0~7
↓
GLM replica 1이 됩니다.
그래서 Stage7 결과가 바로 주간 모델 배치 / 야간 모델 전환 설계로 연결됩니다.
19. LiteLLM 설정까지 연결
예를 들어 Stage7에서 Qwen의 production-safe concurrency가 64라고 나왔다고 합시다.
그러면 LiteLLM/Gateway에서 무작정 200 request를 backend에 보내는 것이 아니라:
Users
↓
LiteLLM
├─ auth
├─ team quota
├─ RPM
├─ TPM
└─ concurrency admission
↓
Inference Gateway / EPP
↓
Qwen replicas
↓
vLLM처럼 Stage7 capacity를 admission control에 반영합니다.
즉 Stage7은 benchmark 보고서를 만드는 단계라기보다 production control-plane parameter를 만드는 단계입니다.
20. Document 모델은 별도 Track 권장
PaddleOCR/Docling 계열을 LLM과 같은 Stage7 script에 억지로 넣지 않는 것을 권합니다.
예를 들어:
Stage7-LLM
├ precision
├ TP
├ context
├ concurrency
├ prefix
└ KV
Stage7-Document
├ image resolution
├ pages/document
├ batch size
├ GPU concurrency
├ pages/sec
├ document latency
├ HBM
└ CPU preprocessing으로 분리합니다.
Document pipeline에서는 GPU보다:
PDF decode
↓
CPU preprocessing
↓
image transfer
↓
GPU inference
↓
postprocessing중 CPU preprocessing이 병목일 수도 있기 때문입니다.
21. 실제 수행 절차
제가 현재 환경에서 실행한다면 다음 순서로 합니다.
Stage6 Gate
│
▼
┌────────────────────┐
│ Stage7-0 │
│ Model Inventory │
│ revision/image 고정│
└─────────┬──────────┘
▼
┌────────────────────┐
│ Stage7-1 │
│ Functional │
│ Qualification │
└─────────┬──────────┘
▼
┌────────────────────┐
│ Stage7-2 │
│ Precision Search │
│ BF16/FP8/FP4 │
└─────────┬──────────┘
▼
┌────────────────────┐
│ Stage7-3 │
│ TP Search │
│ 1 → 2 → 4 → 8 │
└─────────┬──────────┘
▼
┌────────────────────┐
│ Stage7-4 │
│ Memory / Runtime │
│ Parameter Search │
└─────────┬──────────┘
▼
┌────────────────────┐
│ Stage7-5 │
│ Saturation Search │
│ production C 찾기 │
└─────────┬──────────┘
▼
┌────────────────────┐
│ Stage7-6 │
│ Real Workload Mix │
└─────────┬──────────┘
▼
┌────────────────────┐
│ Stage7-7 │
│ Prefix Cache │
└─────────┬──────────┘
▼
┌────────────────────┐
│ Stage7-8 │
│ KV Tier(optional) │
└─────────┬──────────┘
▼
┌────────────────────┐
│ Stage7-9 │
│ Soak │
└─────────┬──────────┘
▼
Production Profile핵심은 앞 단계에서 후보를 줄이고 다음 단계로 넘기는 것입니다. 예를 들어 precision에서 BF16보다 FP8이 품질 기준을 만족하면서 명확히 우수하면 이후 TP/concurrency search는 FP8 중심으로 진행해서 시험량을 줄입니다.
Stage7을 시작하기 전에 지금 준비해야 할 것
현재 상황에서는 Stage6 완료와 별개로 Stage7용으로 ① 실제 사용할 모델의 정확한 repo/revision, ② 각 모델의 실제 workload 특성(input/output/context 또는 document 특성), ③ 서비스별 TTFT/ITL 또는 처리시간 SLO, ④ 품질 acceptance 기준, ⑤ 예상 동시 사용자/트래픽을 먼저 정의하는 게 중요합니다.
특히 SLO가 없으면 Stage7 saturation 결과에서 C384와 C768 중 무엇을 production concurrency로 선택해야 하는지 객관적으로 결정할 수 없습니다.
그리고 현재 8×B300 한 노드라는 조건에서는 Stage7 결과를 단순히 “모델 X의 최고 TPS”로 정리하기보다 TPS/GPU + SLO-compliant concurrency + 필요한 GPU 수 + 가능한 replica 수까지 같이 계산하는 것이 이후 주간/야간 모델 배치 설계에 훨씬 직접적으로 사용할 수 있습니다.
