26O06c

Об этом предложении

지금 구조라면 GPU node를 기존 Compute Cluster에 그냥 추가하기보다는, GPU 전용 Kubernetes Cluster를 하나 더 만들고 기존 Compute / Storage / Admin과 역할을 분리 하는 안을 우선 추천합니다. 즉 최종적으로는 4-cluster architecture 입니다. ┌──────────────────────────────┐ │ Admin Cluster │ │ │ │ CI/CD / GitOps │ │ Keycloak / SSO │ │ Cluster Management │ │ Registry / Helm Repo │ │ Monitoring / Logging(*) │ └──────────────┬───────────────┘ │ Management / GitOps / API │ ┌───────────────────────────┼───────────────────────────┐ │ │ │ ▼ ▼ ▼ ┌────────────────────┐ ┌────────────────────┐ ┌────────────────────┐ │ Compute Cluster │ │ GPU Cluster │ │ Storage Cluster │ │ │ │ │ │ │ │ CPU workload │ │ B300 GPU nodes │ │ AIStor │ │ API / Backend │ │ vLLM / inference │ │ MinIO/S3 │ │ preprocessing │ │ training │ │ durable dataset │ │ application │ │ OCR/VLM(*) │ │ model/checkpoint │ └─────────┬──────────┘ └─────────┬──────────┘ └─────────┬──────────┘ │ │ │ └──────────────────────────┼───────────────────────────┘ │ Cilium ClusterMesh BGP / Native Routing │ Ethernet L3 Fabric 여기서 중요한 것은 ClusterMesh는 service/workload connectivity를 제공하는 계층이고, AIStor의 대용량 S3 data path나 GPU의 NDR/IB fabric까지 무조건 ClusterMesh에 태우자는 의미는 아닙니다. 1. 각 Cluster 역할 저라면 경계를 다음처럼 잡겠습니다. Cluster Node 핵심 역할 넣지 않을 것 Admin 일반 CPU GitOps, CI/CD, Keycloak, Registry, cluster lifecycle, observability AI workload Compute CPU Compute API/backend, preprocessing, orchestration, 일반 application 대형 GPU serving GPU B300 vLLM, LLM/VLM inference, training, GPU batch AIStor Storage Storage node AIStor/S3, model/dataset/checkpoint application/GPU workload 현재 Compute와 Storage가 이미 ClusterMesh라면: 현재 Compute Cluster │ │ Cilium ClusterMesh │ Storage Cluster 여기에 GPU cluster를: Compute / \ / \ / \ GPU ───── Storage ClusterMesh 로 참여시키는 것입니다. Admin cluster까지 반드시 동일한 ClusterMesh에 넣을 필요는 없습니다. 오히려 저는 Admin은 management plane으로 분리 하는 쪽을 선호합니다. 2. Admin Cluster는 ClusterMesh와 분리하는 게 좋다 Admin cluster 역할을 보면: Admin ├── Argo CD / GitOps ├── CI/CD ├── Keycloak ├── Registry ├── Helm repository ├── Cluster management └── Monitoring 이므로 application data plane과 성격이 다릅니다. 따라서: Admin Cluster │ Management Network │ ┌───────────────┼──────────────┐ ▼ ▼ ▼ Compute GPU Storage 로 관리하고, ClusterMesh는: ┌──── Compute ────┐ │ │ │ ClusterMesh │ │ │ GPU ───────── Storage 정도로 제한하는 것이 좋습니다. 이렇게 하면 GPU/Compute/Storage data plane에 문제가 발생해도 관리 plane의 blast radius를 줄일 수 있습니다. 3. GPU Cluster를 별도로 만드는 이유 기존 Compute Cluster에 GPU node를 추가하는 것도 기술적으로 가능합니다. Compute Cluster CPU node CPU node CPU node GPU B300 GPU B300 GPU B300 하지만 지금 정도 규모/구조라면 추천하지 않습니다. GPU node에는 다음처럼 일반 Compute와 상당히 다른 node-level 설정이 들어가기 때문입니다. GPU Node RHEL 10 │ ├─ NVIDIA Driver ├─ Container Toolkit ├─ GPU Operator ├─ NVIDIA Device Plugin ├─ DCGM ├─ NFD │ ├─ CPU Manager = static ├─ Topology Manager = restricted │ ├─ HugePages(optional) │ ├─ NVLink / NVSwitch ├─ NCCL │ ├─ NDR InfiniBand ├─ RDMA │ └─ NVMe x8 local cache 운영 lifecycle 자체가 CPU compute node와 다릅니다. 특히 GPU driver/CUDA/NCCL/GPU Operator upgrade 때문에 GPU cluster의 maintenance cycle을 Compute와 독립시키는 가치가 큽니다. 4. GPU Cluster 내부 구성 저라면 GPU cluster는 최소 다음과 같이 만듭니다. GPU Kubernetes Cluster ┌────────────────────────────┐ │ Control Plane x3 │ │ │ │ 일반 CPU server/VM │ │ GPU 없음 │ └──────────────┬─────────────┘ │ Kubernetes API │ ┌───────────────┼─────────────────┐ │ │ │ ▼ ▼ ▼ GPU Node 01 GPU Node 02 GPU Node N B300 x8 B300 x8 B300 x8 NVMe x8 NVMe x8 NVMe x8 RAID0 RAID0 RAID0 XFS XFS XFS /model-cache /model-cache /model-cache Control Plane을 B300 node 위에 올리는 것은 피합니다. 5. GPU node network는 최소 3가지 성격으로 분리 여기가 특히 중요합니다. GPU Node │ ┌──────────────────┼───────────────────┐ │ │ │ ▼ ▼ ▼ Management Ethernet Data NDR IB Network Network Fabric K8s API Cilium/BGP NCCL SSH/OOB ClusterMesh GPU↔GPU monitoring AIStor/S3 RDMA inference API 논리적으로: Ethernet GPU │ ├── Pod Network ├── Service Network ├── Cilium ├── BGP ├── ClusterMesh │ ├── Compute ↔ GPU └── GPU ↔ AIStor 현재 사용하는 Cilium native routing + BGP + ECMP 를 이쪽에 그대로 확장하는 것이 자연스럽습니다. InfiniBand/NDR GPU Node 1 │ NDR │ GPU Node 2 │ NDR │ GPU Node N 여기는 ClusterMesh traffic용이 아니라 우선: NCCL MPI GPU collective RDMA 전용으로 봅니다. 6. GPU Pod에서는 multi-network가 필요해질 수 있다 일반 serving Pod: vLLM Pod │ eth0 │ Cilium │ Compute/API 만 있으면 됩니다. 하지만 multi-node GPU workload라면: GPU Pod ┌─────┴─────┐ │ │ eth0 ib0 │ │ Cilium NDR │ │ API/S3 NCCL/RDMA 형태가 좋습니다. 따라서 GPU cluster에는 Multus + NVIDIA Network Operator / RDMA device plugin 계열 을 검토할 가치가 있습니다. 즉: Primary CNI ──────────── Cilium │ └─ application/service traffic Secondary Network ───────────────── Multus │ └─ IB/RDMA │ └─ NCCL 입니다. Cilium을 없애고 IB를 쓰는 게 아니라 용도가 다른 두 network를 Pod에 제공 하는 구조입니다. 7. Compute → GPU inference path 예를 들어 Compute cluster의 backend가 GPU cluster의 vLLM을 호출한다면: Compute Cluster Application Pod │ │ HTTP/gRPC ▼ Cilium │ │ ClusterMesh ▼ GPU Cluster │ ▼ Inference Service │ ▼ vLLM Pod │ ▼ B300 가 됩니다. ClusterMesh를 이미 운영 중이라면 이 구조가 자연스럽습니다. 서비스 이름도 global service/discovery 전략을 정해서: llm-serving.gpu... 같은 논리 endpoint로 노출할 수 있습니다. 다만 모든 GPU Pod를 Compute에서 직접 접근시키기보다 GPU cluster에 Gateway/API 계층을 두는 것 을 권합니다. Compute │ ▼ GPU Gateway / LB │ ├── DeepSeek service ├── GLM service ├── Qwen service └── OCR service │ ▼ GPU Pod 이렇게 해야 backend가 GPU topology/Pod 배치를 몰라도 됩니다. 8. GPU → Storage path는 조금 다르게 봐야 한다 여기서 중요한 설계 포인트가 있습니다. 논리적으로는: GPU Pod │ ClusterMesh │ AIStor Service 라고 만들 수 있습니다. 하지만 대규모 model/dataset/checkpoint S3 traffic까지 ClusterMesh service path에 의존할 필요는 없습니다. 저라면: GPU Cluster │ │ Ethernet L3 │ │ S3/HTTPS ▼ AIStor VIP / LB │ Storage Cluster 형태의 직접 routed data path 를 우선 검토합니다. 즉: Small/control/service traffic Compute ←── ClusterMesh ──→ GPU ↘ Storage Bulk storage traffic GPU =======================> AIStor L3 Ethernet / S3 입니다. Cilium/BGP를 사용하고 있으므로 underlay routing을 잘 설계하면 이 방식과 궁합이 좋습니다. 9. Storage Cluster도 역할을 매우 좁게 유지 Storage cluster는: Storage Kubernetes Cluster Control Plane x3 AIStor Node ├ NVMe ├ NVMe ├ ... └ high-speed Ethernet AIStor Node ├ NVMe └ ... AIStor Node └ ... 로 유지합니다. 여기에 GPU workload나 일반 application을 넣지 않습니다. 그리고 bucket 역할은: AIStor s3://models/ s3://datasets/ s3://checkpoints/ s3://artifacts/ 정도로 분리합니다. 10. Local NVMe와 AIStor 관계 GPU node에는 앞에서 정한: NVMe x8 │ RAID0 │ XFS │ /model-cache 를 둡니다. 전체 storage hierarchy는: AIStor durable / source │ │ S3 ▼ GPU Local NVMe 8× RAID0 + XFS cache/stage │ ▼ CPU RAM │ ▼ GPU HBM │ ┌────┴────┐ │ │ Weight KV 가 됩니다. AIStor = source of truth , local NVMe는 언제든 재생성 가능한 cache라는 원칙을 유지합니다. 11. Admin Cluster에서는 GitOps로 네 cluster를 통제 Air-gap이므로 이 구조가 특히 중요합니다. Admin Cluster │ ┌─────────────────┼─────────────────┐ │ │ │ Git Repo OCI Registry Keycloak │ │ │ └─────────────────┼─────────────────┘ │ GitOps │ ┌─────────────────┼──────────────────┐ ▼ ▼ ▼ Compute GPU Storage Private registry에는: NVIDIA GPU Operator NVIDIA Network Operator NVIDIA driver container DCGM exporter vLLM NCCL Cilium AIStor application images 등 필요한 모든 artifact를 mirror합니다. GPU cluster가 인터넷을 직접 볼 필요가 없도록 합니다. 12. Observability도 Admin 쪽으로 집계 각 cluster에는 exporter/agent를 두고: Compute Prometheus agent ─┐ GPU DCGM exporter ────┼──> Admin Observability Prometheus agent ─┤ Storage metrics agent ────┘ 형태로 중앙 집계하는 게 좋습니다. GPU에서는 특히: GPU utilization HBM usage GPU temperature/power NVLink traffic PCIe traffic ECC XID error GPU throttling CPU NUMA local NVMe throughput NCCL IB/RDMA counters model latency TTFT TPOT tokens/sec KV-cache utilization 까지 같이 봐야 합니다. 그래야 GPU utilization이 떨어졌을 때: AIStor? ↓ Ethernet? ↓ NVMe? ↓ CPU/DataLoader? ↓ GPU? ↓ NVLink/NCCL? 중 어디가 병목인지 찾을 수 있습니다. 13. 최종적으로 제가 권하는 전체 구조 현재 환경을 크게 뜯어고치지 않고 GPU를 추가한다면 이 형태가 가장 자연스럽습니다. ADMIN CLUSTER ┌──────────────────────────┐ │ CI/CD / GitOps │ │ Keycloak │ │ Registry / Helm │ │ Cluster Management │ │ Observability │ └────────────┬─────────────┘ │ Management Plane │ ┌─────────────────────┼─────────────────────┐ │ │ │ ▼ ▼ ▼ ┌───────────────┐ ┌────────────────┐ ┌───────────────┐ │ COMPUTE │ │ GPU CLUSTER │ │ STORAGE │ │ CLUSTER │ │ │ │ CLUSTER │ │ │ │ B300 x8/node │ │ │ │ CPU workload │ │ │ │ AIStor │ │ backend │ │ vLLM │ │ S3 │ │ API │ │ LLM/VLM │ │ model │ │ preprocess │ │ training │ │ dataset │ │ │ │ │ │ checkpoint │ └───────┬───────┘ └───────┬────────┘ └───────┬───────┘ │ │ │ │ Cilium ClusterMesh │ └─────────────────────┼──────────────────────┘ │ Ethernet Fabric BGP + ECMP + L3 │ ┌─────────────┴────────────┐ │ │ Service traffic S3 bulk │ GPU ↔ AIStor Separate NDR IB Fabric GPU Node ───────── GPU Node │ │ └──── NDR IB ─────┘ NCCL/RDMA 여기서 제가 특히 설계 원칙으로 고정할 것 은 Admin=Management , Compute=CPU application , GPU=accelerated workload , Storage=durable object storage 의 4-way separation입니다. 그리고 Cilium ClusterMesh는 Compute/GPU/Storage의 서비스 연결 , Ethernet L3 fabric은 AIStor 같은 bulk data path, NDR IB는 GPU collective/RDMA 라는 식으로 네트워크 역할도 분리합니다. 추가로 GPU cluster kubelet은 앞에서 이야기한 CPU Manager=static , Topology Manager=restricted , scope=pod 를 baseline으로 하고, GPU Operator/NFD/DCGM 및 필요 시 Network Operator+Multus/RDMA를 얹는 구조가 좋습니다. 이 정도면 이후 B300 증설이나 GPU driver/CUDA 업그레이드가 기존 Compute/Storage cluster에 미치는 영향도 상당히 줄일 수 있습니다. === 가능합니다. 지금 요구사항이면 GPU Cluster 안에 “Inference Platform” 계층을 하나 만드는 것 이 좋습니다. 사용자는 개별 vLLM Pod를 직접 호출하지 않고, 항상 Inference Gateway 를 통해 접근하게 합니다. 핵심 구조는 아래처럼 잡겠습니다. ┌──────────────────────────────┐ │ Admin Cluster │ │ │ │ Keycloak / GitOps / CI/CD │ │ Model Schedule / Policy │ │ Observability / Registry │ └──────────────┬───────────────┘ │ configuration / identity │ ▼ ┌──────────────────────────────── GPU Cluster ───────────────────────────────┐ │ │ │ Users / Compute Cluster │ │ │ │ │ ▼ │ │ ┌─────────────────────┐ │ │ │ Inference Gateway │ │ │ │ │ │ │ │ OIDC / Keycloak │ │ │ │ API Key │ │ │ │ User/Team Quota │ │ │ │ RPM / TPM Limit │ │ │ │ Model ACL │ │ │ │ Routing │ │ │ └──────────┬──────────┘ │ │ │ │ │ ┌──────┴────────────────────────────────┐ │ │ │ Model Router │ │ │ │ │ │ │ │ model alias → active deployment │ │ │ └──────┬────────────────────────────────┘ │ │ │ │ │ ┌────────┴────────────────────────────────────────────────────────┐ │ │ │ GPU Serving Pool │ │ │ │ │ │ │ │ DeepSeek GLM Qwen gpt-oss PaddleOCR │ │ │ │ vLLM vLLM vLLM vLLM VLM │ │ │ │ │ │ │