CPU와 메모리 모니터링 도구는 Kubernetes에서 GPU로 동일한 방식으로 쉽게 이전되지 않는다. 플랫폼은 일반적으로 컨테이너 또는 Pod 수준의 사용량 지표를 제공하지만, GPU를 공유할 때 플랫폼 팀은 데이터 수집부터 각 팀의 비용 분담 산정에 이르기까지 가시성과 할당에 필요한 대부분의 계층을 직접 구축해야 한다.
이 문제가 중요한 이유는 GPU가 일반적으로 인프라 청구서에서 가장 비싼 항목이기 때문이다. 분석에 따르면 운영 비용은 노드 가격에만 국한되지 않고, 측정 격차를 보완하고 수치의 정확성을 검증하며 워크로드가 Kubernetes가 할당한 범위를 초과하지 않도록 하는 데 필요한 엔지니어링 시간도 포함한다.
일반적인 지표만으로는 충분하지 않은 이유
많은 운영자가 가장 먼저 사용하는 NVIDIA DCGM exporter는 기본적으로 실제 장치 수준의 데이터를 제공한다. Pod가 GPU 전체를 보유한 경우에는 충분할 수 있지만, time-slicing 또는 MPS를 사용해 장치를 공유하면 상황이 달라진다. 이 경우 GPU 하나를 사용하는 각 Pod에 동일한 값이 표시될 수 있어, 실제로 존재하지 않는 하나의 GPU를 세 개의 워크로드가 300% 사용한 것처럼 보일 수 있다.
문제는 기본 데이터가 소비자를 실제로 구분하지 못하는데도 그래프가 정상적으로 보일 수 있다는 점이다. 따라서 팀은 소비자를 실질적으로 구분하지 못하는 수치를 바탕으로 완전한 보고서와 대시보드를 구축할 수 있다.
플랫폼 팀에 실질적으로 달라지는 점
GPU는 리소스 할당 모델에서도 CPU와 다르다. Kubernetes에서 GPU는 일반적으로 nvidia.com/gpu: 1과 같은 정수 리소스로 표시되며, 스케줄러는 CPU에서처럼 소수 단위를 일반적인 방식으로 처리할 수 없다. 실제 공유는 time-slicing, MPS 또는 MIG를 통해 스케줄러 수준 아래에서 이루어지므로, 워크로드가 요청한 것과 사용한 것을 비교하기가 더 복잡해진다.
또한 팀은 Kubernetes가 할당된 것으로 기록한 내용이 애플리케이션이 실제로 접근할 수 있는 범위와 일치하는지 확인하기 위한 독립적인 제어 기능도 필요하다. 적절한 설정으로 재정의되지 않으면 NVIDIA_VISIBLE_DEVICES 환경 변수가 컨테이너에 노드의 모든 GPU가 보이도록 만들 수 있으며, 스케줄러가 GPU 하나만 할당한 경우에도 마찬가지다.
또한 “GPU 사용률 80%”라는 표현이 반드시 하나의 의미만 갖는 것은 아니다. 샘플링 구간의 일부 동안 코어가 작동했는지만 측정할 수 있으며, 계산 능력이나 메모리 대역폭의 소비량은 설명하지 않을 수 있다. vLLM과 같은 일부 프레임워크에서는 시작 시 GPU 메모리 대부분을 예약할 수 있으므로, 일반적인 사용률 수치보다 메모리 또는 대역폭이 더 중요한 지표가 될 수 있다.
과금: 메모리가 컴퓨팅보다 할당하기 쉽다
NVIDIA NVML 라이브러리는 각 process가 보유한 메모리 양을 표시한 뒤 해당 프로세스를 담당 Pod 및 팀과 연결할 수 있다. 다만 드라이버가 자체적으로 보유하는 부분 때문에 값의 합계가 카드의 전체 메모리와 같지는 않다.
반면 병렬로 실행되는 워크로드 간 컴퓨팅 시간을 할당하는 정확도에는 한계가 있다. 두 워크로드가 각각 90%의 활성 상태인 것처럼 보일 수 있지만, 어떤 워크로드가 처리 능력의 70%를 소비하고 다른 워크로드가 30%를 소비했는지는 지표가 설명하지 못할 수 있다. 따라서 분석은 GPU 메모리 사용량을 내부 과금을 위한 실용적인 기준으로 사용하고, 컴퓨팅 측정값은 정확한 과금 기준이 아닌 운영 지표로 다룰 것을 제안한다.
공유 모델의 선택이 계산을 바꾼다
GPU 공유가 하나의 모델을 의미하는 것은 아니다. time-slicing은 격리 없이 장치를 번갈아 사용하고, MPS는 서로 다른 프로세스의 커널을 동시에 실행할 수 있게 하며, MIG는 하드웨어를 고정된 부분으로 나눈다. 그럼에도 클라우드 서비스는 일부만 사용하더라도 물리적 GPU 전체에 요금을 부과할 수 있으며, 자료에 따르면 A100 및 H100급 카드는 최대 7개의 인스턴스로 분할할 수 있다.
Dynamic Resource Allocation (DRA)은 리소스 관리를 위한 미래의 경로가 될 전망이지만 아직 성숙 단계에 있으며, Karpenter와 같은 확장 도구를 비롯한 관련 도구들도 이러한 발전을 따라가고 있다.
이 소식이 중요한 이유
AWS에서 A100급 MIG 호환 GPU 중 가장 저렴한 제품의 가격은 시간당 약 22달러이며, 스팟 요금을 사용하면 약 14달러다. 반면 자료에 따르면 CPU만 사용하는 비교 가능한 인스턴스는 시간당 약 5달러다. 따라서 사용량 할당의 오류는 작은 회계 문제가 아니라 용량 및 비용 결정과 팀 간 비용 부담의 공정성에 직접 영향을 줄 수 있다.
편집상의 결론은 Kubernetes에서 GPU를 운영하려면 CPU 및 메모리 모델과는 다른 운영 모델이 여전히 필요하다는 것이다. 플랫폼 팀은 무엇을 정확히 측정할 수 있는지 정하고, 비용 배분을 위한 명확한 규칙을 마련하며, 실제 소비량을 설명하지 못하는 일반적인 GPU 지표를 바탕으로 회계 결정을 내리는 일을 피해야 한다. 한편 소식통은 DRA의 성숙과 하드웨어 분할이 이러한 격차를 점차 줄일 수 있다고 지적하지만, 그 시점과 현재 도구의 한계는 여전히 열려 있는 질문으로 남아 있다.
뉴스 출처
The New Stack - Software Development
원문 보기 ↗