26O01e

About this offer

A — B300 Multi-Model Serving Architecture 1. 목적 본 문서는 NVIDIA B300 8-GPU 단일 노드 환경에서 여러 LLM 모델을 동시에 서비스하기 위한 Multi-Model Inference Serving Architecture 를 정의한다. 대상 환경은 다음과 같다. NVIDIA B300 8-GPU 단일 서버 Kubernetes 기반 운영 NVIDIA GPU Operator / Device Plugin vLLM 기반 LLM inference 여러 모델의 동시 serving 여러 사용자 및 팀(tenant)의 공동 사용 Keycloak / Active Directory 기반 인증 LiteLLM 기반 LLM Gateway 및 quota 관리 Redis 기반 distributed rate limiting / state Prometheus / Grafana / DCGM 기반 observability Cilium Gateway API / Envoy 기반 Kubernetes network ingress 향후 여러 B300 노드 및 ClusterMesh 환경으로 확장 가능 핵심 설계 원칙은 다음과 같다. Kubernetes가 GPU 자원을 할당하고, vLLM이 GPU에서 inference를 수행하며, LiteLLM이 사용자/팀/모델 단위의 API 정책과 quota를 관리한다. 2. Architecture Overview 전체 논리 구조는 다음과 같다. flowchart TB U[Users / Applications] IDP[Keycloak / Active Directory] GW[Cilium Gateway API / Envoy] LL[LiteLLM Proxy] R[(Redis)] DB[(PostgreSQL)] subgraph B300["B300 8-GPU Kubernetes Node"] V70["vLLM 70B<br/>TP=4"] V32["vLLM 32B<br/>TP=2"] V8["vLLM 8B<br/>TP=1"] VE["Embedding / Reranker<br/>TP=1"] G0["GPU 0-3"] G1["GPU 4-5"] G2["GPU 6"] G3["GPU 7"] V70 --> G0 V32 --> G1 V8 --> G2 VE --> G3 end PROM[Prometheus] DCGM[DCGM Exporter] GRAF[Grafana] U -->|OIDC / JWT| IDP U -->|API Request| GW IDP -->|Identity / Claims| GW GW --> LL LL --> R LL --> DB LL -->|model=70b| V70 LL -->|model=32b| V32 LL -->|model=8b| V8 LL -->|embedding/reranker| VE DCGM --> PROM V70 --> PROM V32 --> PROM V8 --> PROM VE --> PROM PROM --> GRAF 이 구조에서 각 계층의 책임을 명확하게 분리한다. 계층 주요 컴포넌트 책임 Identity Keycloak / AD 사용자 및 서비스 인증 Network Gateway Cilium Gateway API / Envoy TLS, JWT 검증, network/L7 policy AI Gateway LiteLLM Model routing, tenant quota, RPM/TPM, concurrency State Redis Distributed rate-limit 및 shared state Persistence PostgreSQL 사용자/팀/API key/budget 등의 영속 데이터 Inference vLLM Model execution, batching, KV Cache, TP GPU Resource NVIDIA GPU Operator GPU allocation 및 device management Hardware Monitoring DCGM Exporter GPU utilization, HBM, power, temperature, NVLink Platform Monitoring Prometheus/Grafana 통합 모니터링 및 dashboard 3. B300 GPU Resource Partitioning 3.1 기본 원칙 8-GPU B300 노드는 여러 inference instance가 동시에 동작할 수 있는 하나의 GPU resource pool이다. 예시적인 초기 partition은 다음과 같다. B300 Node │ ├── GPU 0 ─┐ ├── GPU 1 │ ├── GPU 2 ├── vLLM 70B / TP=4 ├── GPU 3 ─┘ │ ├── GPU 4 ─┐ ├── GPU 5 ─┘── vLLM 32B / TP=2 │ ├── GPU 6 ──── vLLM 8B / TP=1 │ └── GPU 7 ──── Embedding / Reranker / Spare 이는 초기 serving profile의 예시 이며 고정된 최적 배치로 간주하지 않는다. 실제 배치는 다음 항목의 benchmark 결과를 기준으로 결정한다. GPU memory usage KV Cache capacity TTFT ITL output token throughput request concurrency GPU utilization NVLink traffic CPU/NUMA locality model size context length workload mix 3.2 Tensor Parallelism 후보 TP 구성은 다음과 같다. Model class 후보 TP GPU 수 용도 Lightweight model TP=1 1 7B~14B, embedding, reranker Mid-size LLM TP=2 2 32B급 Large LLM TP=4 4 70B급 Very large model TP=8 8 대형 MoE / full-node serving TP 크기를 1/2/4/8 과 같이 구성하면 운영 및 benchmark matrix를 단순화할 수 있다. 다만, TP는 반드시 2의 거듭제곱이어야 한다는 절대적인 규칙은 아니다. 실제 B300/NVLink topology와 모델의 communication pattern에 따라 TP=2/4/8 각각을 benchmark하여 결정한다. 4. Kubernetes GPU Allocation GPU 자원 할당의 책임은 LiteLLM이나 vLLM이 아니라 Kubernetes + NVIDIA Device Plugin 에 둔다. 예: resources: requests: nvidia.com/gpu: "4" limits: nvidia.com/gpu: "4" 70B TP4 instance: Kubernetes │ │ nvidia.com/gpu = 4 ▼ vLLM Pod │ └── tensor-parallel-size = 4 32B: resources: requests: nvidia.com/gpu: "2" limits: nvidia.com/gpu: "2" 8B: resources: requests: nvidia.com/gpu: "1" limits: nvidia.com/gpu: "1" 중요한 운영 원칙 GPU 번호를 운영자가 직접 다음과 같이 고정하는 방식은 기본 설계로 사용하지 않는다. CUDA_VISIBLE_DEVICES=0,1,2,3 대신 Kubernetes GPU resource allocation을 기준으로 한다. CUDA_VISIBLE_DEVICES 는 컨테이너 내부에서 NVIDIA runtime이 할당된 GPU를 노출하기 위한 실행 환경의 결과로 취급한다. 5. vLLM Instance Architecture 각 모델은 독립적인 vLLM deployment/service로 관리한다. flowchart LR subgraph K8s["Kubernetes"] S70["Service<br/>vllm-70b"] S32["Service<br/>vllm-32b"] S8["Service<br/>vllm-8b"] V70["vLLM 70B<br/>TP=4"] V32["vLLM 32B<br/>TP=2"] V8["vLLM 8B<br/>TP=1"] S70 --> V70 S32 --> V32 S8 --> V8 end G70["GPU x4"] G32["GPU x2"] G8["GPU x1"] V70 --> G70 V32 --> G32 V8 --> G8 각 vLLM instance는 다음을 독립적으로 관리한다. Model weights CUDA context Tensor Parallelism KV Cache Continuous batching Request scheduling Maximum context Maximum concurrent sequences Prefix Cache Prometheus metrics 6. vLLM Resource Configuration 예시: apiVersion: apps/v1 kind: Deployment metadata: name: vllm-70b namespace: llm spec: replicas: 1 selector: matchLabels: app: vllm-70b template: metadata: labels: app: vllm-70b model: llama-70b spec: nodeSelector: accelerator: b300 containers: - name: vllm image: vllm/vllm-openai:<validated-version> args: - "meta-llama/Llama-3.1-70B-Instruct" - "--tensor-parallel-size" - "4" - "--gpu-memory-utilization" - "0.90" - "--max-model-len" - "32768" ports: - containerPort: 8000 resources: requests: cpu: "16" memory: "64Gi" nvidia.com/gpu: "4" limits: cpu: "32" memory: "128Gi" nvidia.com/gpu: "4" gpu-memory-utilization 0.85~0.90 은 초기 tuning 범위로 사용할 수 있지만 모든 모델에 적용되는 고정 권장값은 아니다. 최종값은 다음 결과를 기반으로 결정한다. Model + Context Length + Concurrency + KV Cache + Prefix Cache ↓ GPU Memory Requirement ↓ OOM / latency / throughput benchmark 7. CPU / NUMA Affinity GPU inference는 GPU memory만 고려해서는 안 된다. 다음 자원의 locality를 함께 고려한다. GPU │ ├── PCIe topology ├── NVLink topology ├── CPU socket ├── NUMA node ├── NIC └── memory 예시: CPU NUMA 0 ├── CPU cores ├── Memory └── GPU 0-3 CPU NUMA 1 ├── CPU cores ├── Memory └── GPU 4-7 Kubernetes에서는 다음 기능을 함께 검토한다. CPU Manager Topology Manager NVIDIA Device Plugin Node Feature Discovery Guaranteed QoS CPU pinning NUMA alignment 예를 들어 특정 serving workload에서는: resources: requests: cpu: "16" memory: "64Gi" nvidia.com/gpu: "4" limits: cpu: "16" memory: "64Gi" nvidia.com/gpu: "4" 처럼 CPU request/limit을 동일하게 설정하여 Guaranteed QoS를 사용하는 방식을 검토할 수 있다. 8. Model Serving Gateway 모든 vLLM Service를 외부에 직접 노출하지 않는다. 권장 구조: Client │ ▼ Cilium Gateway API / Envoy │ ▼ LiteLLM │ ├── llama-70b ──> vllm-70b ├── qwen-32b ──> vllm-32b ├── llama-8b ──> vllm-8b └── embedding ──> embedding service 클라이언트는 backend의 IP/port를 알 필요가 없다. 예: client = OpenAI( base_url="https://llm.example.internal/v1", api_key="..." ) response = client.chat.completions.create( model="llama-70b", messages=[ {"role": "user", "content": "Hello"} ] ) 9. LiteLLM as AI Gateway LiteLLM은 GPU scheduler가 아니다. 역할을 다음과 같이 정의한다. LiteLLM │ ├── Model routing ├── Deployment routing ├── User / Team identification ├── API key management ├── RPM ├── TPM ├── Budget ├── Max concurrent requests ├── Model access control ├── Fallback └── Usage accounting 반면 vLLM은: vLLM │ ├── Model execution ├── Tensor Parallelism ├── Continuous batching ├── KV Cache ├── Prefix Cache └── GPU scheduling inside inference engine 을 담당한다. 10. LiteLLM Model Deployment 예: model_list: - model_name: llama-70b litellm_params: model: openai/llama-70b api_base: http://vllm-70b.llm.svc.cluster.local:8000/v1 api_key: dummy max_parallel_requests: 8 - model_name: qwen-32b litellm_params: model: openai/qwen-32b api_base: http://vllm-32b.llm.svc.cluster.local:8000/v1 api_key: dummy max_parallel_requests: 16 - model_name: llama-8b litellm_params: model: openai/llama-8b api_base: http://vllm-8b.llm.svc.cluster.local:8000/v1 api_key: dummy max_parallel_requests: 32 여기서 max_parallel_requests 는 GPU 메모리를 직접 제한하는 값이 아니다. 예: LiteLLM max_parallel_requests = 8 │ ▼ vLLM request scheduler │ ▼ GPU KV Cache / batching 따라서 LiteLLM concurrency와 vLLM의 sequence/concurrency 설정은 별도로 benchmark하여 결정한다. 11. Multi-Deployment Routing 향후 동일 모델의 replica가 증가하면 하나의 logical model에 여러 deployment를 연결할 수 있다. model = llama-70b │ LiteLLM Router / \ / \ ▼ ▼ vLLM-70B-A vLLM-70B-B TP4 TP4 GPU 0-3 GPU 4-7 이 구조에서는 LiteLLM이 다음과 같은 routing을 수행할 수 있다. Load balancing Least-loaded deployment 선택 RPM/TPM-aware routing Retry Fallback Deployment health 기반 제외 따라서 향후 B300 여러 대로 확장할 때도 동일한 논리 구조를 유지할 수 있다. 12. Authentication Architecture 기업 환경에서는 사용자 인증의 중심을 Keycloak / AD에 둔다. 권장 흐름: sequenceDiagram participant U as User / Application participant K as Keycloak / AD participant E as Envoy Gateway participant L as LiteLLM participant V as vLLM U->>K: OIDC authentication K-->>U: Access Token (JWT) U->>E: API request + JWT E->>E: JWT signature / issuer / audience validation E->>L: Authenticated request L->>L: User / Team / Model policy L->>L: RPM / TPM / concurrency check L->>V: OpenAI-compatible request V-->>L: Inference response L-->>E: Response E-->>U: Response 13. Keycloak / AD Claims JWT에는 다음과 같은 정보를 사용할 수 있다. { "sub": "user-1234", "preferred_username": "user-a", "groups": [ "ai-research", "data-platform" ], "roles": [ "llm-user" ] } 이를 다음과 같이 policy에 연결한다. JWT │ ├── sub │ ↓ │ User │ ├── groups │ ↓ │ Team │ └── roles ↓ Permission 예: ai-research ├── llama-70b ├── qwen-32b └── llama-8b general-users ├── qwen-32b └── llama-8b 14. Tenant / User / Model Quota 사용자에게 GPU를 직접 할당하기보다는 API capacity를 할당 한다. 권장 policy hierarchy: Organization │ ▼ Team │ ▼ User │ ▼ API Key / Client │ ▼ Model 예: Team 70B TPM 32B TPM 8B TPM Max Concurrent AI Research 30K 50K 100K 10 AI Engineering 10K 30K 50K 5 General - 10K 30K 3 이러한 quota는 GPU의 물리적 할당과 독립적이다. 15. Rate Limit LLM workload에서는 RPM만으로는 충분하지 않다. 최소한 다음을 고려한다. 항목 의미 목적 RPM Requests/minute Request burst 제어 TPM Tokens/minute 실제 inference load 제어 TPD Tokens/day 장기 사용량 제어 Budget 비용/사용량 팀별 resource accounting Concurrency 동시 request Backend queue 보호 Context limit 요청당 최대 context KV Cache 보호 Output limit 최대 생성 토큰 장시간 generation 방지 16. Noisy Neighbor Protection 멀티테넌트 환경에서 가장 중요한 보호 장치 중 하나다. 예: User A │ └── 200K token request │ ▼ KV Cache pressure │ ▼ User B latency ↑ 따라서 다음과 같은 다단계 제한을 적용한다. Client │ ▼ ┌────────────────┐ │ Gateway │ │ JWT / Auth │ └───────┬────────┘ │ ┌───────▼────────┐ │ LiteLLM │ │ RPM / TPM │ │ Team quota │ │ concurrency │ └───────┬────────┘ │ ┌───────▼────────┐ │ vLLM │ │ context limit │ │ sequence limit │ │ KV Cache │ └───────┬────────┘ │ ▼ GPU 특히 --max-model-len 은 단일 요청이 과도한 KV Cache를 사용하는 것을 방지하기 위한 중요한 보호 장치다. 17. Prefix Caching 동일한 system prompt 또는 반복되는 prefix가 많은 workload에서는 vLLM Prefix Ca