GPU를 밀도 있게 쓰는 방법 - 토스증권의 GPU 가상화(MIG) 도입기

모든 ML 태스크가 고성능, 고용량 GPU를 필요로 하는 것은 아니다.

이전 포스트에서 우리는 고성능 GPU 클러스터를 구축한 경험을 공유했습니다. 이러한 고성능 GPU 클러스터는 LLM 학습이나 파인튜닝(Fine-tuning) 작업에 필수적입니다. 하지만 모든 AI/ML 작업이 항상 고성능, 고용량 GPU를 요구하는 것은 아닌데요. 간단한 실험이나 PoC(Proof of Concept) 단계에서는 작은 모델로 충분한 경우가 많으며, 서비스 운영 단계에서도 상대적으로 작은 모델을 사용하는 경우가 흔합니다. 예를 들어 실시간 번역 서비스의 경우, 빠른 응답을 위해 애초부터 작은 모델을 학습시키거나 이미 훈련된 모델을 양자화(Quantization)하여 모델의 크기를 줄이는 전략을 활용합니다.

모델이 고성능·고용량 GPU(예: H100)에 배치될 경우 GPU 메모리를 충분히 활용하지 못하고 낭비하게 됩니다. 특히 작은 모델들도 응답 시간이 중요한 서비스에 활용될 때는 빠른 처리 속도가 필수적이기 때문에, 고성능 GPU를 완전히 배제할 수는 없습니다. 하지만, GPU 메모리 용량은 상대적으로 덜 필요합니다. 토스증권처럼 다양한 서비스를 빠르게 출시하고 지속적으로 테스트하는 환경에서는 이런 자원 낭비가 더 빈번하게 발생할 수 있습니다. 데이터 분석 결과, 전체 워크로드의 약 1/3은 GPU 자원을 1/4조차 활용하지 않고 있었습니다. 물론 이는 서비스 개발 주기나 비즈니스 상황에 따라 다를 수 있습니다.

이러한 낭비는 비용 측면에서도 심각한 문제입니다. 예를 들어 AWS 기준으로 H100 GPU 한 장의 하루 대여 비용은 약 38만 원(환율 1300원 기준)입니다. 이 GPU를 단지 1/4만 활용한다면 하루 약 28만 원의 손실이 발생하고, 월 단위(30일 기준)로 환산하면 약 840만 원의 비용이 낭비됩니다. 서버 한 대에 GPU가 8장 있다고 가정하면 단순 계산상 서버 당 월 6,700만 원이라는 상당한 손실이 생기게 되죠.

ML 엔지니어들에게 GPU 클러스터 운영은 식당 운영과 비슷합니다. 식당이 최대한 많은 손님을 받아 최대의 이윤을 내기 위해 빈 테이블을 최소화하듯, GPU 클러스터 역시 최대한 많은 태스크를 효율적으로 배치하여 GPU 자원의 낭비를 최소화하는 것이 핵심입니다.

이러한 문제를 어떻게 해결해볼수있을까요?

GPU 자원의 낭비를 최소화하기 위해서는 결국 태스크에 맞는 GPU를 제공해야 합니다. 이러한 환경을 제공하기 위해서는 보통 세 가지의 선택지가 있습니다. 첫 번째는 클라우드를 활용하는 방법이며, 두 번째는 다양한 GPU를 혼합하여 운용하는 방법, 마지막으로는 Nvidia에서 제공하는 GPU 가상화 기술(MPS, MIG 등)을 활용하는 방법입니다. 각 방법의 장단점을 차례로 살펴보겠습니다.

방법1. 클라우드 활용

클라우드를 활용한 GPU 운영은 빠르고 유연한 자원 확장성이라는 측면에서 큰 장점이 있습니다. 필요할 때만 자원을 할당받아 사용할 수 있어 초기 자본 투자 없이 다양한 실험을 빠르게 시도해볼 수 있습니다. 특히 PoC 단계나 일시적인 고부하 테스트에는 적합한 방식입니다.

하지만 단점도 분명합니다. 첫째, 워크로드가 장기적이고 지속적인 경우 및 자체 클러스터가 구축된 환경에서는 오히려 비용이 더 발생할 수 있습니다. 둘째, 데이터 보안 및 컴플라이언스 문제로 인해 민감한 데이터를 다루는 환경에서는 사용이 제한되거나 별도의 보안 설계가 필요합니다. 셋째, 클라우드 환경에서 GPU 인스턴스를 원하는 방식으로 정밀하게 제어하거나 커스터마이징하기 어렵고, 지역별 가용성 이슈로 인해 자원을 확보하지 못하는 경우도 발생할 수 있습니다.

결론적으로, 소규모 조직이나 단발성 실험 위주의 환경에서는 클라우드가 비용과 유연성 측면에서 효과적인 선택이 될 수 있습니다. 그러나 자체 IDC를 운용하며 일정 수준 이상의 지속적 워크로드를 보유한 조직에서는 클라우드가 반드시 저렴하지 않으며, 온프레미스 환경이 더 안정적이고 비용 효율적인 대안이 될 수 있습니다. 또한, 금융·헬스케어 등 엄격한 컴플라이언스 요건이 있는 산업군에서는 클라우드 사용에 법적·보안적 제약이 뒤따를 수 있어, 온프레미스 환경이 정책적 측면에서도 유리할 수 있습니다.

방법2. 혼합 GPU 운영

혼합 GPU 운영이란, 메모리 용량이 서로 다른 GPU를 함께 구성해 사용하는 방식을 말합니다. 가장 큰 장점은 작업 특성에 따라 적절한 GPU를 유연하게 할당할 수 있다는 점입니다. 예를 들어, 경량 모델에는 저용량 GPU를, 대규모 학습이나 배치 추론처럼 메모리를 많이 요구하는 작업에는 고용량 GPU를 배정함으로써 비용 효율성을 높일 수 있습니다.

하지만 실제 운영에서는 다음과 같은 단점과 제약이 존재합니다.

첫째, 운영 정책이 복잡해지고 관리 부담이 커질 수 있습니다. 예를 들어, Hopper 세대에는 저용량 GPU가 없어 L40이나 A40 같은 이전 세대 GPU를 함께 써야 하는데, 이 경우 드라이버, CUDA 버전, 프레임워크 호환성 등이 달라져 통합 관리가 어려워집니다. 또한 GPU 간 메모리 차이에 따라 스케줄링 정책도 세밀하게 설계해야 하므로 운영 복잡도가 높아집니다.

둘째, GPU 수요를 예측하기 어렵고 자원 낭비로 이어질 수 있습니다. 시간이 지날수록 고용량 GPU에 대한 수요가 집중되면 저용량 GPU는 점점 활용도가 낮아지고 결국 유휴 자원이 될 수 있습니다. 초기에는 비용 절감을 기대하고 도입한 저용량 GPU가 오히려 방치되며 비효율을 초래하는 역설적인 상황이 발생할 수 있습니다.

결국 혼합 GPU 운영은 단기적인 유연성과 비용 절감의 가능성은 분명 존재하지만, 장기적으로는 수요 편중과 자원 낭비로 이어질 수 있는 리스크를 충분히 고려한 운영 전략이 필요합니다. 그렇지 않으면, 혼합 구성 자체가 오히려 전체 시스템의 비효율 요소가 될 수 있습니다.

방법3. GPU 가상화

GPU 가상화 기술(MIG, MPS 등)은 하나의 고성능 GPU를 논리적으로 여러 개의 독립적인 인스턴스로 나누어 활용하는 방식입니다. 이 방식의 장점은 명확합니다. 첫째, 자원 효율성을 극대화할 수 있습니다. 고성능 GPU를 세분화하여 작은 작업에도 효율적으로 자원을 배분할 수 있습니다. 둘째, 균일한 개발 및 배포 환경을 유지할 수 있어 일관된 작업 흐름과 효율성을 보장합니다. 셋째, 자원 할당의 유연성이 뛰어나, 작업의 변화에 따라 신속하게 자원을 재조정할 수 있습니다.

하지만 GPU 가상화 역시 몇 가지 한계를 지니고 있습니다. 가장 큰 단점은 지원되는 GPU 모델의 제약입니다. Nvidia의 MIG 기술은 최신 세대의 GPU(A100, H100 등)에서만 지원되므로 도입할 수 있는 환경이 한정됩니다. 또한 GPU를 분할하고 관리하는 과정에서 관리 복잡성이 증가할 수 있으며, 최대로 나누었을 때 일부 코어 및 NVLink 같은 네트워크 인터페이스가 비활성화 됨에 따라 일부 작업에서는 성능 저하 가능성도 존재합니다.

결론적으로 GPU 가상화는 명확한 장점이 있지만, 적용 가능한 환경과 관리 역량을 고려하여 신중하게 선택해야 하는 기술입니다.

비교 테이블

토스증권의 선택 - GPU 가상화

지금까지 살펴본 것처럼, 클라우드, 혼합 GPU 운용, GPU 가상화는 각각의 장단점이 뚜렷합니다. 실제로 모든 조직에 GPU 가상화가 무조건 정답이 되진 않습니다. 선택은 결국 각자의 상황과 요구사항에 달려 있습니다.

토스증권 머신러닝 플랫폼팀은 다음과 같은 이유로 GPU 가상화를 선택했습니다.

또한, 대부분 H100/H200 GPU를 기반으로만 클러스터를 구성하고 있었기 때문에, MIG 지원이 가능한 상황이었습니다. MPS는 관리 부담이 크고 격리가 어려워 운영 리스크가 컸던 반면, MIG는 하드웨어 수준에서 자원이 격리되며 운영이 단순하고 안정적이었습니다.

정리하면, GPU 가상화(MIG)는 아래 표와 같이 우리의 핵심 조건들을 대부분 충족했습니다.

이러한 이유로 저희는 GPU 가상화 방식을 채택했으며, 그중에서도 MIG 기반 가상화가 저희 환경에 가장 적합한 해법이라고 판단했습니다.

토스증권은 Kubernetes 기반 GPU 클러스터를 운영하고 있기 때문에, GPU 설정 뿐만 아니라 Kubernetes 및 모니터링 관련 설정까지 함께 고려해야 합니다. 만약 별도의 플랫폼 없이 장비에 직접 접속하여 사용하는 환경이라면, 이 문서의 1단계(GPU 설정)까지만 진행 하셔도 충분합니다.

1단계에서는 모든 환경에서 공통적으로 수행해야 하는 GPU 관련 설정을 다룹니다. MIG가 정상적으로 적용되었는지 확인하는 방법도 함께 소개합니다.

2단계에서는 Kubernetes 기반으로 GPU 클러스터를 운영하는 환경을 위한 설정을 다룹니다. nvidia-device-plugin과 같은 컴포넌트를 어떻게 재배포해야 Kubernetes가 MIG를 올바르게 인식하는지 설명합니다.

마지막 3단계에서는 가상화된 GPU 리소스를 어떻게 모니터링할 수 있는지에 대해 소개합니다. MIG 환경에서 유의해야 할 모니터링 포인트와 그 방법을 중심으로 설명합니다.

1단계 : GPU 설정

장비에 직접 접속하는 환경이나 그렇지 않은 환경 모두 GPU에 MIG를 활성화 해주어야 합니다. NVIDIA 공식 문서를 기반으로 MIG 설정을 진행했고, 그 과정에서 쌓은 저희의 경험과 노하우를 함께 정리했습니다.

GPU 설정은 다음의 세부 단계로 진행됩니다:

A. GPU 확인 - MIG 비활성화 상태 확인

MIG가 비활성화된 상태에서 nvidia-smi를 실행하면, 다음과 같이 각 GPU의 MIG 모드(MIG M.) 항목이 Disabled로 표시됩니다.

출력 예시는 다음과 같습니다:

만약 NVLink가 구축된 장비라면, nvidia-smi topo -m 명령어를 통해 아래 처럼 GPU 간 연결 상태가 NVXX의 형태로 나타는 것을 확인하실 수 있습니다.

(아래 스크린샷에서 ‘18’의 의미는 GPU간 18개의 링크로 연결되어 있다는 뜻입니다. 이는 NVLink 구성을 어떻게 하느냐에 따라 다르게 보여질 수 있습니다)

B. GPU에 MIG 모드 활성화

MIG 모드 설정은 루트(root) 권한이 필요하며, -i 옵션을 이용해 GPU 개별 단위로 설정 가능합니다. 즉, GPU가 8개인 경우 일부 GPU에만 MIG를 설정할 수도 있습니다. 참고로 hopper 세대 부터는 대부분 MIG 활성화 이후 GPU 리셋이 필요가 없습니다.

활성화 후 nvidia-smi 명령어에서 MIG 상태가 Enabled로 바뀐 것을 확인할 수 있습니다.

앞서 언급했듯이 MIG를 활성화한 GPU는 다른 GPU와의 NVLink 연결이 끊기고 SYS (PCIe 기반)로 변경됩니다. 이는 MIG 구조상 불가피한 제약입니다.

다만 MIG를 도입하는 경우는 보통 하나의 GPU를 온전히 다 쓰지 않는 상황이기 때문에, 여러 GPU 간의 통신이 필요한 경우는 드뭅니다.

C. GPU 인스턴스(GI) 생성

GPU에 MIG 모드를 활성화한 이후, 가장 먼저 해야 할 일은 GPU 인스턴스를 생성하는 것입니다. 이 인스턴스는 MIG를 통해 물리 GPU를 논리적으로 분할한 단위이며, 실제로 워크로드가 올라갈 수 있는 기반이 됩니다.

생성 가능한 인스턴스 유형은 다음 명령어를 통해 확인할 수 있습니다:

출력 예시는 위와 같으며, 각 인스턴스는 Ng.Mgb 형식으로 표기됩니다. 여기서 N은 SM 단위(GPU 코어 수), M은 메모리 크기(GB 단위)를 의미합니다.

예를 들어, 1g.10gb는 GPU 전체를 7등분 했을 때 그중 하나에 해당하는 인스턴스이며, 10GB의 메모리와 1/7의 SM을 제공합니다. H100 기준으로는 SM을 최대 7개까지 나눌 수 있습니다. 각 인스턴스 타입의 오른쪽에는 Free/Total 개수가 표기되어 있어 현재 사용 가능한 인스턴스 개수를 확인할 수 있습니다.

다음 명령어는 3g.40gb MIG 인스턴스(Profile ID 9)를 0번 GPU에 생성하는 명령어입니다.

• -cgi 9는 MIG 프로파일 ID 9, 즉 3g.40gb를 의미합니다.
• -i 0은 0번 GPU에 인스턴스를 생성하겠다는 뜻입니다.

이처럼 GPU 0에 3g.40gb 인스턴스가 생성됩니다.

또한, GPU 인스턴스는 최대 7개까지 생성할 수 있으며, 서로 다른 프로파일(예: 1g.10gb, 2g.20gb 등)로도 구성 가능합니다.

조합 예시

• 3g.40gb: 최대 2개 생성 가능
• 4g.40gb: 최대 1개 생성 가능
• 3g.40gb + 4g.40gb 조합은 동시에 사용 가능 (총 SM이 7이기 때문)

즉, 인스턴스를 어떤 순서로 생성하느냐에 따라 남는 자원이 달라질 수 있으므로 주의해야 합니다. 보통은 다음 두 가지 방식으로 많이 나뉘어 사용됩니다.

1. 1g.10gb 인스턴스 7개 생성 (7-way 분할)
2. 3g.40gb + 4g.40gb 인스턴스 조합 (2-way 분할)

구체적인 워크로드 요구사항에 따라 어떤 방식이 적합할지는 다를 수 있습니다. 아래 그림은 H100 기준 모든 조합 가능한 형태를 보여주고 있습니다.

출처 : https://docs.nvidia.com/datacenter/tesla/pdf/MIG_User_Guide.pdf

D. 컴퓨트 인스턴스(CI) 생성

GPU 인스턴스(GI)를 생성한 이후에는 반드시 해당 GI 위에 컴퓨트 인스턴스(CI)를 생성해야 실제 연산 작업이 가능한 환경이 완성됩니다.

컴퓨트 인스턴스는 GPU 인스턴스(GI) 위에서 실제 연산이 수행되는 실행 단위로, MIG 구성을 논리적으로 완성하는 마지막 단계입니다. CI를 통해 하나의 GI를 여러 개의 CI로 세분화하여 동시에 서로 다른 워크로드를 올릴 수 있지만, 실무에서는 대부분 GI와 CI를 1:1로 생성하고 사용하는 경우가 일반적입니다. 구성 복잡도가 증가하고 활용 빈도도 낮기 때문에, 명시적으로 분리할 필요가 없을 경우 단순하게 생성하는 것이 운영상 효율적입니다.

아래와 같이 -C 옵션을 통해 GPU 인스턴스와 CI를 한 번에 생성 할 수 있습니다. (-cgi 9 는 MIG 3g.40gb 를 의미)

생성된 MIG 인스턴스 확인

생성된 인스턴스는 nvidia-smi -L 명령어로 확인할 수 있습니다:

GPU 0과 1에는 MIG 인스턴스가 설정되어 있으며, GPU 2와 3은 아직 MIG 모드를 활성화하거나 인스턴스를 생성하지 않은 상태입니다. 따라서 기본 단일 GPU로 인식됩니다.

MIG는 GPU당 한 번만 활성화하면 되지만, 인스턴스 구성은 워크로드에 따라 유동적으로 변경할 수 있습니다. 다만 이미 실행 중인 프로세스가 있는 상태에서는 인스턴스를 삭제하거나 재생성할 수 없으며, 시도 시 에러가 발생합니다. 따라서 인스턴스 구성은 작업 전 충분히 계획하고 신중하게 수행하는 것이 중요합니다.

2단계 : Kubernetes 컴포넌트 재배포

Kubernetes를 활용해 GPU 클러스터를 운영할 때는 nvidia-device-plugin을 반드시 재배포해야 합니다. 이는 Kubernetes가 GPU 리소스를 정확히 인식하고, MIG(Multi-Instance GPU) 구성이 변경되었을 때 이를 반영하기 위해 필요합니다. 참고로 nvidia-device-plugin은 NVIDIA에서 제공하는 디바이스 플러그인으로, GPU를 Kubernetes의 리소스로 노출하고 스케줄링 가능하게 만들어줍니다.

MIG 적용 전 상태 확인

노드의 리소스를 조회해보면 다음과 같이 GPU 리소스가 nvidia.com/gpu 단일 항목으로 보입니다.

MIG를 적용해도 플러그인을 재배포하지 않으면 위처럼 여전히 GPU가 여전히 통째로 노출되어, 위처럼 MIG 인스턴스가 Kubernetes에 인식되지 않습니다.

MIG 활성화를 위한 재배포 방법

nvidia-device-plugin의 환경 변수에 다음과 같이 MIG_STRATEGY를 설정해준 후 재배포해야 합니다 (참고)

• none: MIG 비활성화 상태. GPU 전체가 하나로 인식됨
• single: MIG 인스턴스를 개별 리소스로 인식하지만, 동일한 유형만 사용할 경우. 즉, 7 등분하였을때 각각을 nvidia.com/mig-1g.10gb 가 아닌 하나의 GPU(nvidia.com/gpu: 1)로 인식. 스케쥴링 방식 등을 변경하지 않아도 되는 장점이 있음
• mixed: 서로 다른 유형의 MIG 인스턴스를 동시에 사용할 수 있음 (예: 1g.10gb, 3g.40gb 혼용)

재배포 후 다시 확인해보면, 다음과 같이 nvidia.com/mig-로 시작하는 리소스들이 추가된 것을 볼 수 있습니다. 이는 MIG가 정상적으로 인식되었음을 의미합니다.

MIG 구성 변경 시 처리 방법

MIG 인스턴스 구성을 변경하면 (예: 7등분 → 통합 → 2등분), nvidia-device-plugin이 이를 자동으로 반영하지 않습니다. 하지만 플러그인을 재배포할 필요는 없고, 단순히 파드를 재시작하면 새로운 구성이 반영됩니다:

3단계 : 모니터링 셋업

GPU 사용률을 모니터링할 때 가장 흔히 사용하는 도구는 nvidia-smi입니다. 하지만 MIG를 활성화하면 nvidia-smi의 출력 구조가 바뀝니다. 이전까지는 GPU 단위로 전력 사용량, 메모리 사용량, GPU 사용률(GPU Utilization) 등을 확인할 수 있었지만, MIG가 활성화되면 더 이상 GPU 전체에 대한 단일 사용률이 유효하지 않게 됩니다. 이는 하나의 GPU가 여러 개의 MIG 인스턴스로 분할되어, 논리적으로는 여러 개의 독립된 가상 GPU처럼 동작하게 되기 때문입니다. ‘GPU 단위’의 사용률 정보는 이러한 분할 구조에서는 더 이상 의미가 없습니다.

실제로 nvidia-smi를 실행해보면 GPU Util. 필드가 N/A로 나타나는 것을 볼 수 있습니다. 이는 단순히 측정이 되지 않는다는 의미가 아니라, 측정 기준 자체가 기존의 GPU 단위에서 MIG 인스턴스 단위로 바뀌었기 때문입니다. GPU가 여러 개의 MIG 인스턴스로 나뉘면, 전체 GPU의 연산 사용률을 하나의 값으로 표현하는 것이 의미를 잃게 됩니다. 반면, 메모리는 MIG 인스턴스에 고정 할당되기 때문에, 각 인스턴스의 사용량을 여전히 정확하게 추적할 수 있습니다. nvidia-smi에서도 각 MIG 인스턴스별 메모리 사용량이 사용 중 메모리 / 총 할당 메모리 형식으로 출력 됩니다.

GPU Util. 지표는 보이지 않지만 메모리 사용량은 확인할 수 있어서 불편하게 느껴질 수 있습니다. 하지만 실제 운영 관점에서 더 중요한 건 메모리 사용량 입니다. GPU 메모리는 초과하면 OOM(Out of Memory)이 발생해 작업이 즉시 중단되기 때문입니다. 반면, GPU Util은 100%를 초과한다고 해서 문제가 발생하진 않으며, 단지 성능이 일시적으로 저하될 수 있는 수준입니다. 결국 중요한 건 메모리 한도를 넘기지 않는 범위 내에서 GPU를 최대한 활용하는 것 입니다.

각 MIG 인스턴스 옆에는 SM(Streaming Multiprocessor) 수가 함께 표시됩니다. 앞서 설명한 것처럼 하나의 GPU는 수십에서 수백 개의 SM으로 구성되어 있습니다. 예를 들어 A100은 108개, H100은 132개의 SM을 갖고 있습니다. MIG를 적용하면 이러한 SM 자원 역시 여러 인스턴스로 나뉘어 할당되며, 각 인스턴스는 독립적으로 연산을 수행하게 됩니다.

물론 GPU 메모리 사용량은 OOM을 방지하기 위해 반드시 체크해야 하는 핵심 지표지만, GPU Util 역시 매우 중요한 지표 중 하나입니다. 그렇다면 MIG 환경에서 GPU Util 정보를 확인하려면 어떻게 해야 할까요?

정답은 dcgm-exporter를 활용하는 것입니다. Kubernetes 기반으로 GPU 클러스터를 운영 중이라면, 대부분 dcgm-exporter를 통해 GPU 상태를 모니터링하고 있을 것입니다. dcgm-exporter는 NVIDIA에서 공식 제공하는 Prometheus Exporter로, GPU의 온도, 전력, 메모리 사용량 등 다양한 상태 정보를 Prometheus 지표 형식으로 수집해주는 컴포넌트입니다.

하지만 기본 설정 상태에서는 dcgm-exporter도 GPU 단위의 지표(예: GPU Utilization)만 수집합니다. 따라서 앞서 설명한 nvidia-device-plugin과 마찬가지로, MIG 환경에서도 개별 인스턴스를 인식하고 지표를 분리 수집할 수 있도록 설정을 변경한 후 재배포해야 합니다.

이를 위해 dcgm-exporter의 컨테이너 실행 시 다음과 같이 인자를 추가해주어야 합니다. (출처)

위와 같이 dcgm-exporter를 재배포하면, 이제 더 이상 DCGM_FI_DEV_GPU_UTIL 지표는 수집되지 않고, 대신 DCGM_FI_PROF_SM_ACTIVE라는 지표가 수집됩니다. 이 지표는 기존의 GPU 사용률 지표처럼 0부터 100 사이의 숫자로 표현되며, MIG 인스턴스별 SM 사용률(SM Active Ratio)을 나타냅니다. 예를 들어 GPU 0번을 두 개의 MIG 인스턴스로 분할한 경우, 각각은 gpu_instance ID를 기준으로 구분됩니다. Prometheus에서는 다음과 같이 각 인스턴스의 SM 사용률이 별도의 지표로 나타납니다:

이처럼 GPU를 분할해 사용하는 상황에서도, 각 인스턴스 단위로 연산 부하를 모니터링할 수 있습니다.

한편 메모리 사용량은 기존과 동일한 DCGM_FI_DEV_FB_USED 지표를 그대로 사용할 수 있습니다. 다만, MIG 환경에서는 이 역시 인스턴스 단위로 구분되어 출력됩니다

정리하자면, MIG 환경에서는 GPU 단위가 아닌 MIG 인스턴스 단위로 지표가 세분화됩니다.

연산 사용률은 DCGM_FI_PROF_SM_ACTIVE, 메모리 사용량은 DCGM_FI_DEV_FB_USED, DCGM_FI_DEV_FB_FREE, DCGM_FI_DEV_FB_TOTAL 지표를 기반으로 모니터링할 수 있습니다.

이러한 지표들을 활용해 Grafana 대시보드를 구성하면, MIG 환경에서도 기존과 동일한 수준의 GPU 모니터링이 가능합니다.

스케쥴링

개인 장비에서 직접 GPU에 접근해 개발하거나 연구하는 경우, GPU 설정만 완료하면 곧바로 MIG를 사용할 수 있습니다. 하지만 Kubernetes 환경에서 GPU 클러스터를 운영하는 경우, GPU 설정뿐 아니라 Kubernetes 컴포넌트 재배포와 모니터링 설정까지 함께 수행해야 MIG가 정상적으로 동작합니다. 이 모든 과정을 마치면 MIG 사용을 위한 준비가 완료됩니다.

사용 방법 자체는 복잡하지 않습니다. 기존에 nvidia.com/gpu: 1처럼 리소스를 요청하던 자리에, 원하는 MIG 인스턴스 스펙을 그대로 지정하면 됩니다. 예를 들어 nvidia.com/mig-1g.10gb: 1처럼 작성하면 됩니다.

다만 이러한 값을 사용자가 직접 입력하게 되면 혼란이나 실수가 발생할 수 있기 때문에, 토스증권에서는 GUI를 통해 원하는 인스턴스를 손쉽게 선택할 수 있도록 시스템을 구성했습니다. (아래 : 예시)

이번 포스트에서는 MIG를 활용해 고성능 GPU를 더 효율적으로 운영하는 방법에 대해 다뤄보았습니다. 물론 MIG가 모든 상황에 완벽한 해결책은 아닙니다. 한계도 있고, 단점도 분명 존재합니다. 하지만 단일 GPU를 유연하게 분할해 사용할 수 있다는 점은 큰 강점이며, 특히 다양한 규모의 워크로드가 혼재하는 환경에서는 매우 실용적인 선택이 될 수 있습니다.

설정이나 운영 측면에서는 다소 시간이 걸리는 작업일 수 있기에, 토스증권의 실제 경험을 바탕으로 최대한 실질적이고 구체적인 내용으로 정리해보았습니다. MIG 도입을 고민 중인 엔지니어분들, 혹은 MIG가 정확히 어떤 기술인지 궁금했던 개발자분들께 이 글이 조금이나마 도움이 되었기를 바랍니다.

혹시 설정 과정에서 막히는 부분이 있거나 궁금한 점이 있다면, 댓글로 남겨주시면 확인 후 답변드리겠습니다.

긴 글 읽어 주셔서 감사합니다.