26O07d

About this offer

네. 지금까지의 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와 상당히 다른 결과가 나올 수 있습니다. 현재 계획을 기준으로 모델군을 최소한: 1 Ontology / Reasoning GLM-5.3 Qwen3.6-35B-A3B gpt-oss-20b 2 Online discovery DeepSeek-V4.1-Flash GLM-5.3-Flash 3 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용으로 1 실제 사용할 모델의 정확한 repo/revision, 2 각 모델의