«AI 팩토리»는 단일 모델이나 독립된 Kubernetes 클러스터 하나가 아니라, 서로 다른 목적을 가진 여러 팀이 동시에 사용하는 GPU 그래픽 처리 장치 풀이다. 용도에는 파인튜닝, 추론 실행, 평가가 포함된다. CNCF 블로그에 게재된 기사에 따르면, 진정한 엔터프라이즈 과제는 더 이상 모델을 학습하는 것만이 아니라, GPU 활용률을 높게 유지하고 비용을 측정할 수 있게 하면서 각 팀에 동일한 하드웨어에 대한 안전하고 격리된 접근 권한을 제공하는 것이다.
이 글은 CNCF Ambassador이자 vCluster의 Platform Advocate인 Hrittik Roy가 작성했으며, Kubernetes 위에 이러한 환경을 구성하는 방법을 실무적으로 설명한다. 기사의 핵심 주장은 Kubernetes가 컨테이너, RBAC, 자동 확장, 정책을 위한 성숙한 기반을 제공하지만, 동일한 노드에서 가속기를 다루고 테넌트 간 격리를 구현하려면 추가 생태계가 필요하다는 것이다.
병목은 추론 속도만이 아니라 활용률이다
GPU는 AI 인프라에서 가장 큰 자본 지출을 차지하므로, 활용률은 단일 실행에서 최고 속도를 기록하는 것보다 더 중요한 경제적 지표가 된다. 이 기사는 두 가지 핵심 문제인 리소스 할당 모델과 격리 모델을 제시한다.
기존 device plugin 모델에서는 워크로드가 예를 들어 nvidia.com/gpu: 1을 요청하고, 실제로 10%만 사용하더라도 GPU 전체를 예약한다. 반면 Kubernetes 1.34에서 일반적으로 사용할 수 있게 된 Dynamic Resource Allocation 또는 DRA는 스케줄러가 가속기를 특성, 메모리, 토폴로지를 가진 장치로 다룰 수 있게 한다. 그러나 DRA가 GPU를 자동으로 여러 할당량으로 나누는 것은 아니다. 밀도는 장치 계층에서 제공되며, 그 예로 CNCF의 Incubating 단계 프로젝트인 HAMi가 있다. HAMi는 컨테이너 수준에서 메모리와 연산에 소프트웨어 제한을 적용하고 여러 가속기 공급업체를 지원한다.
반대로 각 팀에 별도의 하드웨어를 할당하면 강력한 격리를 제공할 수 있지만, 용량의 상당 부분이 사용되지 않은 채 남는다. 따라서 이 기사는 신뢰 경계가 엄격할 때는 GPU 전체를 할당하고, 동일한 신뢰 영역 안에서는 밀도를 높이기 위해 GPU를 분할하는 방식을 구분한다. NVIDIA MIG는 하드웨어 수준에서 메모리 및 장애 격리를 제공하지만, 적대적인 테넌트 간 경계로 사용하는 것은 여전히 논쟁의 대상이라고 기사는 지적한다. 따라서 신뢰도가 낮은 경우에는 GPU 전체를 할당하는 것이 보수적인 선택으로 남는다.
베어메탈부터 워크로드까지 이어지는 팩토리 계층
시스템은 원시 하드웨어의 프로비저닝에서 시작한다. 노드를 발견하고 GPU, ECC 메모리 상태, 네트워크 카드의 식별자를 검사한 뒤, GPU 드라이버와 CUDA 및 NCCL 라이브러리가 포함된 운영체제 이미지를 설치한다. 그다음 적절한 BIOS 설정을 적용하고, 전체 대역폭에서 GPU 간 연결이 가능한지 확인하기 위해 노드에 스트레스 테스트와 NCCL 테스트를 수행한다. 이후 결과를 NetBox 같은 기준 정보 소스에 기록한다. 이 과정은 공급업체 전용 하드웨어 관리자나 Metal3와 Ironic 또는 vMetal 같은 오픈소스 도구를 사용해 구축할 수 있다.
할당 이후에는 KAI Scheduler와 Volcano 같은 도구가 집단 및 토폴로지 인식 스케줄링을 담당하고, Kueue가 대기, 수락, 할당량을 관리한다. 워크로드 계층에서는 추론 엔진에 vLLM을, 표준 엔드포인트 제공과 자동 확장에 KServe를 사용할 수 있으며, 더 큰 환경에서는 NVIDIA Dynamo와 llm-d를 분리형 추론에 사용할 수 있다. Gateway API는 라우팅을 제공하고, LiteLLM은 OpenAI API와 호환되는 게이트웨이를 추가한다.
플랫폼은 컨테이너에만 국한되지 않는다. 이 기사는 학습 환경이 SchedMD의 Slinky를 통해 Slurm을 사용할 수 있다고 설명한다. Slinky는 Slurm 서비스를 전용 리소스로 표현하고 GPU Operator 및 DRA와 통합한다. 또한 KubeVirt는 가상 머신을 Kubernetes 워크로드로 실행할 수 있게 하므로, 동일한 풀에서 통합된 권한과 할당량으로 가상 머신과 컨테이너를 관리할 수 있다.
격리는 단순한 네임스페이스가 아니다
이 기사는 격리 문제를 두 수준으로 나눈다. 제어 수준에서 tenant cluster 패턴은 각 팀에 API 서버, 전용 리소스, 독립적인 승인 규칙과 RBAC를 포함하는 가상 Kubernetes 인터페이스를 제공하며, 이를 하나의 기본 클러스터 위에서 워크로드로 실행한다. vCluster가 그 예이며, 독점 확장 기능 없이 kubectl, Helm, Argo CD 같은 익숙한 도구를 사용할 수 있다.
데이터 수준에서는 네트워크, 스토리지, 할당량, 실행 환경을 격리해야 한다. CNI와 정책에는 Cilium을, 고속 경로에는 Multus와 SR-IOV를 사용할 수 있으며, 노드 간 GPU 트래픽 전송에는 InfiniBand 또는 RoCEv2를 사용할 수 있다. 또한 VXLAN과 EVPN을 통해 별도의 VPC를 사용하거나 InfiniBand의 파티션 키를 사용할 수 있다. NVIDIA BlueField 또는 AMD Pensando 같은 DPU는 격리와 암호화 기능의 일부를 호스트 CPU에서 분리해 처리한다. 기사는 진정한 클라우드의 기준이 필요할 때 하드웨어가 강제하는 격리이지, 네임스페이스만에 의존하는 것이 아니라고 강조한다.
무엇이 풀을 클라우드 서비스로 바꾸는가?
편집자 해설: 이 주장의 실질적인 가치는 논의를 «어떤 모델이 더 빠른가?»에서 인프라 자체를 어떻게 운영할 것인가라는 질문으로 옮기는 데 있다. 플랫폼은 GPU를 모아 놓는 것만으로 클라우드 서비스가 되는 것이 아니다. 테넌트가 API, Terraform 또는 GitOps를 통해 클러스터를 생성하고 삭제할 수 있으며, 리소스가 Flux 또는 Argo CD가 관리하는 선언적 형식으로 정의되고, OIDC ID와 RBAC 권한이 제공될 때 비로소 클라우드 서비스가 된다.
서비스에는 이해하기 쉬운 측정과 과금도 필요하다. 이 기사는 DCGM 데이터를 사용해 GPU 초를 계산한 뒤 OpenCost를 통해 이를 테넌트에 배분할 것을 제안한다. 모니터링과 신뢰성도 운영상의 부가 기능이 아니라 제품의 일부다. DCGM은 성능 저하를 모니터링하고, Node Problem Detector는 장애 신호를 노드 상태로 변환한다. 처리 주기는 의심스러운 노드를 격리하고 새 워크로드가 스케줄링되기 전에 비운다. 보안 계층에는 OIDC를 통한 Keycloak, External Secrets Operator와 함께 사용하는 OpenBao, 제어를 위한 Kyverno 또는 OPA, 실행 및 공급망 보안을 위한 Falco와 Trivy 같은 도구가 포함된다.
가장 어려운 검증은 데모에서 대규모 프로덕션으로 전환하는 일이다. 분할된 GPU 하나에서 두 팀과 두 모델을 실행하는 예만으로는 수백 개의 노드와 여러 데이터센터에서 설계가 유효하다는 것을 입증할 수 없다. 이 기사는 NVIDIA AI Cluster Runtime과 Kubernetes 1.35와 함께 소개된 Kubernetes AI Conformance 프로그램 같은 검증 도구의 역할을 언급하지만, 장애 반경, 테넌트 간 격리 한계, NVIDIA DSX OS 패키지를 선택할지 오픈소스 계층을 조합할지에 관한 운영상의 질문은 열어 둔다.
결론적으로 «AI 팩토리»의 성공은 하드웨어 토폴로지를 고려하면서 밀도, 격리, 과금을 결합하는 데 달려 있다. 여기에는 NVLink 또는 NVSwitch를 기준으로 한 GPU 위치, InfiniBand 또는 RoCE 네트워크와의 연결, NUMA 노드에서의 GPU, NIC, CPU 배치가 포함된다. 이러한 정보를 고려하지 않고 워크로드를 스케줄링하면 소프트웨어 수준에서는 플랫폼이 정상적으로 보여도 집단 통신 작업이 가장 느린 링크에서 지연될 수 있다.