26O07e

About this offer

네. 이 경우에는 처음부터 LiteLLM/자동 전환까지 한꺼번에 검증하기보다, “각 모델의 B300 최적 vLLM 설정을 찾는 Stage 1 → 실제 주/야간 모델 세트를 검증하는 Stage 2 → 전환 자동화를 검증하는 Stage 3” 순서가 좋습니다. 특히 지금 가장 먼저 알아야 하는 것은 각 모델에 대해 몇 GPU가 필요한지, TP/DP/EP를 어떻게 잡아야 하는지, HBM 중 weight와 KV에 각각 얼마를 쓰는지가 최적인지 입니다. vLLM도 single-node에서는 모델이 1 GPU에 들어가면 single GPU, 그렇지 않으면 TP를 늘리는 접근을 기본 가이드로 제시하고 있습니다. MoE에서는 EP를 별도로 실험할 가치가 있습니다. vLLM 1. 전체 테스트를 이렇게 나누겠습니다 Stage 1 모델별 단독 Characterization │ │ GPU / TP / EP / KV 최적값 탐색 ▼ Stage 2 주간/야간 Model-set 동시 구동 │ │ GPU allocation / 간섭 / capacity 검증 ▼ Stage 3 AIStor → NVMe → HBM 전환 테스트 │ │ cold/warm start 측정 ▼ Stage 4 Day ↔ Night 자동 전환 │ │ prefetch → load → warmup → switch → drain ▼ Stage 5 LiteLLM + multi-user 부하 │ ▼ Production baseline 처음부터 LiteLLM을 넣지 않는 것이 포인트입니다. Stage 1~3에서는 vLLM endpoint를 직접 때려서 GPU serving 자체를 먼저 검증 하는 편이 원인 분석이 쉽습니다. 2. Stage 1 — 모델별 단독 테스트 우선 모델 하나만 B300 node에 올립니다. 예를 들어 Qwen 계열 MoE라면 다음과 같은 matrix를 만들겠습니다. Test GPU TP DP EP 목적 Q1 1 1 1 OFF 1 GPU 수용 가능 여부 Q2 2 2 1 OFF TP baseline Q3 2 1 2 ON EP 효과 Q4 4 1 4 ON EP scaling Q5 4 2 2 ON TP+EP 조합 Q6 8 1 8 ON full-node EP 중요한 점은 최신 vLLM에서 --enable-expert-parallel 을 켠 경우 expert layer의 EP size가 TP×DP로 구성 된다는 것입니다. 예를 들어 TP=2, DP=4이면 8 GPU에서 expert layer는 EP=8이고 attention layer는 각 DP group 안에서 TP=2가 됩니다. vLLM 따라서 앞에서 이야기했던 TP/DP/EP 를 완전히 독립적인 세 숫자로 생각하기보다는 실제 사용하는 vLLM 버전의 구현에 맞춰 test matrix를 작성 해야 합니다. 3. 각 모델에서 찾고 싶은 최종 결과 모델마다 결국 아래 한 줄을 만드는 것이 목표입니다. Qwen3.x-35B-A3B GPU 2 TP 1 DP 2 EP enabled (effective EP=2) max-model-len 32K KV HBM xx GiB/GPU GPU memory xx % CPU 24 cores NUMA 0 Throughput xxxx tok/s TTFT P50/P95 xx / xx ms TPOT P50/P95 xx / xx ms Max concurrency xx NVMe→HBM load xx sec 이게 만들어지면 나중에 Kubernetes Deployment YAML을 만드는 것은 상대적으로 쉽습니다. 4. 테스트 지표는 tokens/sec만 보면 안 됩니다 LLM serving은 최소한 다음을 같이 봐야 합니다. Performance ──────────────────── Request throughput Input tokens/sec Output tokens/sec Latency ──────────────────── TTFT Time To First Token TPOT Time Per Output Token E2E latency P50 / P95 / P99 Capacity ──────────────────── Concurrent requests Queue depth KV cache usage Prefix cache hit GPU ──────────────────── GPU utilization HBM usage NVLink traffic Power PCIe traffic System ──────────────────── CPU utilization NUMA remote access RAM NVMe read throughput Network vLLM은 /metrics 에서 production metrics를 노출하므로 Prometheus로 수집하는 게 좋습니다. vLLM 그리고 online benchmark에는 vllm bench serve 를 사용할 수 있습니다. request rate, input/output length, prompt 수 등을 바꿔 serving throughput을 측정할 수 있습니다. vLLM vLLM Benchmark CLI 문서 5. Context length를 반드시 여러 개 테스트 이 workload에서는 이게 상당히 중요합니다. 제가 baseline을 잡는다면: Short input 1K output 256 Medium input 8K output 1K Long input 32K output 2K Very Long input 64K+ output 2K 정도로 나눕니다. Wizard/문서 처리에서 생성되는 context가 DeepSeek/GLM으로 넘어간다면 32K~64K 이상 workload가 실제로 나올 가능성 도 고려해야 합니다. 그리고 concurrency: 1 2 4 8 16 32 64 ... 를 올립니다. 즉 한 모델당: GPU topology × context length × concurrency matrix입니다. 6. 중요한 것은 Saturation point를 찾는 것 예를 들어 결과가: Concurrency tok/s P95 TTFT 1 150 80 ms 2 290 90 ms 4 550 110 ms 8 980 180 ms 16 1300 350 ms 32 1400 1200 ms 64 1420 4000 ms 라면 throughput만 보면 64가 가장 좋아 보입니다. 하지만 실제 서비스라면: 16 → 32 throughput +8% TTFT +243% 같은 상태일 수 있습니다. 따라서 16 정도를 serving capacity로 잡는 식입니다. 이걸 각 모델마다 찾아야 합니다. 7. MoE 모델은 EP ON/OFF를 반드시 비교 현재 목록은 MoE 모델 비중이 높으므로 중요합니다. 예를 들어 같은 8 GPU에서: Test A TP=8 EP=OFF vs Test B TP=1 DP=8 EP=ON vs Test C TP=2 DP=4 EP=ON 을 비교해볼 가치가 있습니다. vLLM은 MoE에서 EP를 지원하고, 현재는 --all2all-backend 로 여러 communication backend도 선택할 수 있습니다. EP workload는 expert token 분포가 치우칠 수 있어서 EPLB(Expert Parallel Load Balancer)도 제공합니다. vLLM 처음부터 EPLB까지 튜닝하지 말고 : EP OFF ↓ EP ON ↓ all-to-all backend 비교 ↓ 필요 시 EPLB 순서가 좋습니다. 8. Stage 2 — 실제 “주간 세트”를 동시에 올려보기 개별 모델 최적값을 찾았으면 그다음부터가 진짜 중요한 테스트입니다. 첨부하신 주간 workload를 그대로 재현합니다. DAY DeepSeek-V4.1-Flash GLM-5.3-Flash PaddleOCR-VL Docling layout Docling models Figure classifier 예를 들어 B300 node 여러 대가 있다면 실제 production 후보 배치 그대로 올립니다. GPU Node 01 ┌──────────────────────────┐ │ DeepSeek Flash │ │ GPU 0~7 │ └──────────────────────────┘ GPU Node 02 ┌──────────────────────────┐ │ GLM Flash │ │ GPU 0~7 │ └──────────────────────────┘ Compute / Small GPU ┌──────────────────────────┐ │ PaddleOCR / Docling │ └──────────────────────────┘ 실제 Stage 1 결과에 따라 4 GPU씩 들어간다면: GPU Node GPU0 ─┐ GPU1 │ DeepSeek GPU2 │ GPU3 ─┘ GPU4 ─┐ GPU5 │ GLM GPU6 │ GPU7 ─┘ 도 테스트합니다. Stage 1 결과를 보기 전에는 어느 쪽이 맞다고 고정하지 않는 게 좋습니다. 9. OCR/Docling → LLM까지 실제 pipeline test도 필요 각 모델을 독립적으로 때리는 것만으로는 부족합니다. 실제 주간 workflow가: PDF/Image │ ▼ PaddleOCR │ ▼ Docling │ ├── layout ├── figure └── context extraction │ ▼ DeepSeek / GLM │ ▼ response 라면 end-to-end workload 도 만들어야 합니다. 그래야 GPU serving benchmark에는 안 나타나는: OCR bottleneck CPU preprocessing object download context serialization network tokenization LLM queue 등을 찾을 수 있습니다. 10. Stage 3 — AIStor/local NVMe까지 포함 그다음에는 model loading을 별도 테스트합니다. 세 가지 시간을 측정합니다. Case A — Cold AIStor │ │ S3 ▼ NVMe │ ▼ RAM │ ▼ HBM T_cold = ? 두 번째는: Case B — Warm NVMe NVMe │ ▼ RAM │ ▼ HBM T_warm = ? 세 번째: Case C — Already loaded HBM │ ▼ ready T_ready = ? 이 결과가 주간↔야간 전환 시간을 결정 합니다. 예를 들어: AIStor → NVMe 6 min NVMe → model ready 2 min warmup 1 min total cold 9 min 이면 22:00 전환을 위해 21:30부터 준비하는 게 충분한지 판단할 수 있습니다. 11. Stage 4 — 실제 Day → Night 전환 야간에는 첨부하신 세 모델을 실제로 올립니다. DAY ────────────────────────── DeepSeek-V4.1-Flash GLM-5.3-Flash PaddleOCR/Docling │ │ prefetch ▼ 21:xx AIStor → NVMe │ ▼ NIGHT LOAD GLM-5.3 Qwen3.x-35B-A3B gpt-oss-20b │ ▼ health/warmup │ ▼ traffic switch 여기서는 전환시간 자체가 테스트 결과 입니다. 측정값을: Prefetch time Model load time Warm-up time Route switch time Drain time 총 전환시간 전환 중 실패 request 전환 중 P95/P99 latency 로 남깁니다. 12. 이 단계에서야 LiteLLM을 붙이는 것이 좋음 여기까지 통과하면: Keycloak │ ▼ Users ───────── LiteLLM │ ┌───────┼────────┐ ▼ ▼ ▼ GLM Qwen DeepSeek │ │ │ ▼ ▼ ▼ vLLM vLLM vLLM 으로 바꿉니다. 그 후 실제 사용자 패턴을 만들어: Team A 50 users Team B 20 users Batch 5 jobs RPM TPM Concurrency model quota 를 적용한 부하 테스트를 합니다. 이 단계에서 LiteLLM overhead와 quota가 의도대로 작동하는지 를 별도로 측정하면 됩니다. 13. MemKV도 마지막 쪽에서 A/B test MemKV도 처음부터 켜면 원인 분석이 어려워집니다. Test A vLLM └── HBM KV only Test B vLLM ├── HBM KV └── MemKV 동일한 workload를 사용해서: TTFT TPOT throughput KV hit rate HBM usage RDMA traffic 를 비교합니다. 특히: Shared system prompt Repeated RAG context Multi-turn conversation Long context 를 따로 만들어야 합니다. random prompt만 사용하면 external KV cache의 효과를 제대로 측정하지 못할 수 있습니다. 제가 추천하는 실제 테스트 순서 GPU/node validation — nvidia-smi , topology, NVLink/NVSwitch, NCCL, HBM, CPU NUMA부터 검증합니다. 모델 하나씩 vLLM에 올리기 — 일단 “실행된다”를 확인합니다. GPU/TP/DP/EP matrix — 각 모델 최적 parallelism을 찾습니다. Context × concurrency sweep — 최대 처리량이 아니라 SLA를 만족하는 saturation point를 찾습니다. 주간 모델 세트 동시 실행 — 실제 GPU capacity와 interference를 측정합니다. 야간 모델 세트 동시 실행 — 같은 방식으로 측정합니다. AIStor → NVMe → HBM — cold/warm startup 시간을 측정합니다. Day ↔ Night 전환 — prefetch/warm-up/drain까지 포함해 검증합니다. LiteLLM + 사용자 quota — 실제 multi-user traffic을 재현합니다. MemKV A/B — KV reuse가 높은 workload에서만 효과를 검증합니다. 여기서 가장 먼저 만들 산출물은 모델별 Test Matrix 입니다. 예를 들어 각 모델마다 precision × GPU수 × TP × DP × EP × max-model-len × concurrency × gpu-memory-utilization 을 바꾸면서 HBM / KV capacity / TTFT P95 / TPOT P95 / tok/s 를 자동 수집하고, 마지막에 “이 모델의 B300 권장 vLLM parameter” 한 줄을 자동으로 뽑는 테스트 패키지 를 만드는 게 좋습니다. 지금 진행 중인 Stage7의 목적이 바로 “실제 사용 모델별 설정값 찾기”였으므로, 이 테스트를 기존 Stage7에 7a 모델 적재 → 7b TP/EP sweep → 7c context/concurrency sweep → 7d day-set → 7e night-set → 7f AIStor/NVMe cold-warm → 7g 전환 으로 넣는 방식 이 현재 프로젝트 구조와 가장 잘 맞습니다. vLLM === 테스트가 끝나 각 모델의 GPU/TP/DP/EP/HBM/KV/context/concurrency 값이 확정됐다고 보면, 실제 서비스는 “모델 Pod들을 띄운다”보다 하나의 Inference Platform으로 운영 하는 게 좋습니다. 제가 현재 환경이라면 아래 구조를 목표로 하겠습니다. ┌──────── ADMIN CLUSTER ────────┐ │ │ │ Keycloak │ │ GitOps / CI-CD │ │ Private Registry │ │ Model/Profile Repository │ │ Prometheus / Grafana │ └──────────────┬────────────────┘ │ Management │ ▼ ┌──────────────────────────── GPU CLUSTER ─────────────────────────────┐ │ │ │ Compute Cluster / Users │ │ │ │ │ ▼ │ │ ┌───────────────────────┐ │ │ │ LiteLLM │ ← 인증: Keycloak │ │ │ │ │ │ │ API Key / Team │ │ │ │ Model ACL │ │ │ │ RPM / TPM / Quota │ │ │ │ Usage Accounting │ │ │ │ Logical Model Name │ │ │ └───────────┬───────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────────────┐ │ │ │ Inference Routing Layer │ ← replica 증가 시 │ │ │ Gateway API + EPP │ │ │ └────────────┬─────────────┘ │ │ │ │ │ ┌──────┴─────────────────────────────────────────┐ │ │ │ │ │ │ │ vLLM Serving Pools │ │ │ │ │ │ │ │ DeepSeek │ GLM │ Qwen │ gpt-oss │ OCR/VLM │ │ │ │ │ │ │ └───────────────────┬────────────────────────────┘ │ │ │ │ │ B300 GPU / HBM │ │ │ │ │ KV L1 / Prefix Cache │ │ │ │ │ MemKV (*) │ │ │ │ ┌──────────────────────────────────────────────────────────────────┐ │ │ │ Node Local NVMe │ │ │ │ 8 NVMe RAID0 + XFS │ │ │ │ /model-cache │ │ │ └────────────────────────────┬─────────────────────────────────────┘ │ └──────────────────────────────┼───────────────────────────────────────┘ │ S3 / Ethernet ▼ ┌──── STORAGE CLUSTER ────┐ │ │ │ AIStor │ │ │ │ models/ │ │ datasets/ │ │ checkpoints/ │ │ artifacts/ │ │ AIMem (*) │ └─────────────────────────┘ 여기서 중요한 운영 원칙은 LiteLLM / vLLM / Kubernetes / AIStor의 책임을 섞지 않는 것 입니다. 1. 모델마다 ServingProfile 을 고정 Stage7 테스트 결과를 그대로 운영 configuration으로 승격합니다. 예를 들어: model: glm-5.3-flash runtime: vllm gpu: count: 4 tensorParallel: 2 dataParallel: 2 expertParallel: true memory: gpuMemoryUtilization: 0.90 maxModelLen: 32768 cpu: cores: 32 memory: 256Gi cache: localNVMe: true prefixCaching: true memkv: false limits: maxConcurrency: 16 이 값은 사람이 production에서 즉흥적으로 바꾸지 않고 Git으로 관리합니다. 즉: Stage7 benchmark │ ▼ Approved Serving Profile │ ▼ Git │ ▼ GitOps │ ▼ vLLM Deployment 으로 연결합니다. 이렇게 하면 Stage7 결과가 production configuration의 근거 가 됩니다. 2. 모델별 Deployment를 완전히 분리 하나의 거대한 vLLM에서 모델을 계속 갈아끼우는 것보다: glm-5.3-flash │ └── Deployment/ServingPool deepseek-v4.1-flash │ └── Deployment/ServingPool qwen │ └── Deployment/ServingPool 처럼 모델 단위 serving pool 로 가져가는 것을 권합니다. 그러면 모델별로: GPU TP/DP/EP CPU memory max-model-len KV replica SLA 를 독립적으로 설정할 수 있습니다. 장애 격리도 훨씬 쉽습니다. 3. 사용자에게는 실제 모델 Deployment를 노출하지 않음 외부에서는: /v1/chat/completions model = glm model = deepseek model = qwen m