MIG 프로파일 불일치, 스케줄은 왜 멈추나

이번 분석에서는 NVIDIA MIG(Multi-Instance GPU) 프로파일이 노드 단위에서 어긋날 때 쿠버네티스 스케줄러가 어떻게 GPU Pod를 무기한 Pending 상태로 묶어두는지 뜯어봤다. 결론부터 말하면 이 문제는 자원 부족이 아니라, 프로파일이라는 고정된 자원 형태를 드라이버·디바이스 플러그인·스케줄러가 서로 다르게 해석하는 데서 비롯된다. 동일 토폴로지를 요구하는 분산 학습 잡일수록 이 불일치에 더 취약하다.

MIG 프로파일 불일치는 왜 스케줄 실패로 이어지나?

핵심은 MIG 프로파일이 런타임에 유연하게 조정되는 자원이 아니라, 사전에 고정된 자원 형태라는 데 있다. 프로파일을 바꾸려면 기존 인스턴스를 제거하고 재생성해야 하며, 실행 중인 잡이 있으면 중단이나 재배치가 불가피하다. 이 때문에 한 노드에 1g, 2g, 3g 수요가 뒤섞이면 물리적으로는 여유 용량이 남아 있어도 잡이 배치되지 않는 stranded capacity가 생긴다 출처: servnetuk.com.

• 문제의 본질은 "자원 부족"이 아니라 "자원 형태 불일치"다.
• MIG와 풀 GPU가 섞인 노드, 드라이버 570.124.06~570.158.01 구간에서 GPU Pod가 무기한 Pending에 머문 사례가 공식 릴리스 노트에 기록돼 있다 출처: NVIDIA GPU Operator Release Notes.
• 같은 메모리 용량이라도 SM 수가 다르면 동일 자원으로 취급할 수 없다.
• 분산 학습은 MIG 인스턴스 간 P2P 제약 때문에 단일 GPU 내부로 범위가 좁혀진다.
• 활용률을 높이려 GPU를 잘게 쪼갤수록 대형 잡이 요구하는 동일 프로파일 묶음을 맞추기 어려워진다.

이 글이 다루는 범위는 NVIDIA GPU Operator 기반 쿠버네티스 환경에서 MIG 프로파일 구성·스케줄링·분산 학습 배치까지다. MIG 자체의 하드웨어 파티셔닝 원리나 특정 클라우드 벤더의 관리형 서비스 설정은 다루지 않는다.

프로파일은 왜 "유연한 조각"이 아니라 "고정된 틀"로 동작하나?

MIG 프로파일은 물리 GPU를 인스턴스 단위로 나누는 설정값이며, 한 번 생성되면 메모리와 SM이 묶인 고정 블록으로 존재한다. A100 80GB를 예로 들면 프로파일 조합은 다음과 같다 출처: kb.ekarisky.com.

표에서 보듯 1g.20gb와 2g.20gb는 메모리가 같은 20GB지만 SM이 14 대 28로 두 배 차이 난다. 메모리 요구량만 보고 "이 정도면 들어가겠지"라고 판단하면 컴퓨트 자원이 부족한 인스턴스에 잡을 배치하는 오류가 발생한다. 프로파일 변경은 인스턴스 재생성을 수반하므로, 운영 중인 노드에서 수요에 맞춰 즉시 조정하는 것도 불가능하다. 이 경직성이 스케줄 실패의 1차 원인이다.

드라이버와 디바이스 플러그인은 어디서 어긋나나?

노드가 MIG 슬라이스와 풀 GPU를 동시에 광고할 때, 드라이버·디바이스 플러그인·스케줄러 조합이 해당 노드의 GPU 리소스 형태를 제대로 해석하지 못하는 구간이 실제로 보고돼 있다. NVIDIA GPU Operator 릴리스 노트는 드라이버 570.124.06, 570.133.20, 570.148.08, 570.158.01에서 이런 혼합 노드에 GPU 워크로드를 스케줄할 수 없는 문제를 명시하며, 570.172.08로 업그레이드할 것을 권고한다 출처: NVIDIA GPU Operator Release Notes. 증상은 단순하다. GPU Pod가 이벤트 로그에 별다른 원인 없이 Pending으로 멈춘다. 리소스 요청량과 노드 가용량을 비교하는 선에서는 문제가 드러나지 않고, 디바이스 플러그인 로그와 드라이버 버전을 대조해야 비로소 원인이 보인다. 이는 자원 회계 계층(스케줄러)과 자원 노출 계층(디바이스 플러그인)이 서로 다른 전제로 동작할 때 생기는 전형적인 불일치 유형이다.

분산 학습은 MIG 위에서 왜 흔들리나?

MIG 인스턴스 간 통신은 풀 GPU 간 통신과 같은 경로를 보장하지 않는다. 검색된 기술 자료에 따르면 드라이버 R570 기준으로 동일 물리 GPU 내부 MIG 인스턴스 간 P2P만 지원되며, 서로 다른 GPU에 속한 MIG 인스턴스 간, 또는 MIG와 비-MIG GPU 간 P2P는 지원되지 않는다 출처: akash.network. 이 자료는 2026년 9월 업데이트 기준이므로, 적용 시 실제 사용 중인 드라이버·NCCL 버전과 반드시 재대조해야 한다.

결과적으로 여러 MIG 인스턴스에 분산 학습 랭크를 나눠 배치해도 NCCL이 기대하는 GPU 간 직접 통신 경로가 보장되지 않는다. 통신이 PCIe나 호스트 메모리를 경유하게 되면 확장성이 떨어지거나 초기화 단계에서 실패할 수 있다. MIG는 멀티테넌시·소형 추론·전처리 잡에는 자원 분리라는 강점을 제공하지만, 여러 GPU에 걸친 동일 형상을 요구하는 학습 잡에는 구조적으로 맞지 않는다 출처: servnetuk.com.

실제로 보고된 실패는 어떤 조건에서 재현됐나?

보고된 실패는 두 갈래로 나뉜다. 하나는 노드 구성 문제, 다른 하나는 프로파일 자체의 결함이다. 첫째, 드라이버 570.124.06·570.133.20·570.148.08·570.158.01에서 MIG 슬라이스와 풀 GPU가 섞인 노드에 GPU 워크로드 스케줄이 불가능했고, NVIDIA는 570.172.08로 업그레이드하라고 명시했다. 둘째, GH200에서 MIG 설정을 all-balanced로 구성했을 때 1g.12gb 프로파일이 예상대로 작동하지 않는 문제가 같은 릴리스 노트에 기록돼 있다 출처: NVIDIA GPU Operator Release Notes. 두 사례 모두 "메모리 용량이 맞으니 배치 가능하다"는 판단만으로는 부족하다는 점을 보여준다. GPU 세대, 보드 유형, MIG 모드, 프로파일 조합, 드라이버 버전까지 함께 확인해야 재현 가능한 실패와 우연한 성공을 구분할 수 있다.

다만 이번 검색 결과에서는 "MIG 프로파일 불일치로 활용률이 몇 퍼센트 하락했다"는 식의 재현 조건을 갖춘 1차 벤치마크 수치는 확인되지 않았다. 2025년 공개된 GPU-Virt-Bench는 오버헤드, 격리, LLM 성능, 메모리 대역폭, 스케줄링 효율 등 56개 지표와 10개 범주로 GPU 가상화 시스템을 평가하도록 설계됐지만, 검색된 범위 안에서는 특정 프로파일·GPU 모델·드라이버·NCCL·동시 잡 수 조합에 따른 처리량 수치까지는 확인되지 않는다 출처: GPU-Virt-Bench. 따라서 이 글에서는 활용률·학습 속도·스케줄 지연시간을 임의의 숫자로 제시하지 않는다.

mixed와 single 중 무엇을 얻고 무엇을 잃나?

NVIDIA GPU Operator 환경에서 노드별 MIG 구성 전략은 mixed와 single 두 가지로 나뉘며, 이 선택은 활용률과 스케줄 안정성 사이의 트레이드오프다 출처: khimananda.com.

mixed는 한 노드에 서로 다른 MIG 프로파일을 함께 배치해 다양한 크기의 잡을 수용한다. 얻는 것은 자원 활용률이다. 작은 추론 잡과 중간 크기 학습 잡을 같은 노드에서 소화할 수 있다. 잃는 것은 단순성이다. 리소스 회계와 스케줄링 조건이 복잡해지고, 앞서 다룬 혼합 노드 Pending 사례처럼 드라이버·플러그인·스케줄러 간 해석 불일치가 발생할 여지가 커진다.

single은 GPU별 구성을 통일해 노드 간 자원 형태를 단순화한다. 얻는 것은 예측 가능성이다. 프로파일 불일치로 인한 stranded capacity나 Pending 문제를 구조적으로 줄인다. 잃는 것은 유연성이다. 노드 하나가 특정 프로파일에 고정되므로, 다른 크기의 수요가 들어오면 다른 노드로 보내야 한다. 이 둘 중 하나가 항상 우월하지 않다. 노드 수가 적고 잡 종류가 다양한 환경일수록 mixed의 복잡성 비용이 커지고, 노드 수가 많고 워크로드가 분리 가능한 환경일수록 single의 단순성이 이득으로 돌아온다.

MIG는 언제 쓰고 언제 피해야 하나?

MIG는 소형 추론, 전처리, 개발·실험용 노트북 세션처럼 GPU 하나를 여러 테넌트가 나눠 쓰는 멀티테넌시 시나리오에 적합하다. 각 인스턴스가 메모리와 컴퓨트를 격리해 가지므로 테넌트 간 간섭을 줄일 수 있다.

반면 여러 GPU에 걸친 분산 학습, 특히 NCCL 기반의 데이터 병렬·모델 병렬 학습에는 적용 경계를 명확히 둬야 한다. MIG 인스턴스 간 P2P가 동일 물리 GPU 내부로 제한되는 조건에서는, 여러 MIG 인스턴스를 엮어 하나의 분산 학습 토폴로지를 구성하는 접근 자체가 통신 경로 문제를 안고 시작한다. 실무적으로는 분산 학습용 노드를 풀 GPU 또는 동일 프로파일로 고정하고, 소형 추론·개발 잡을 별도 MIG 풀로 분리하는 구성이 문제를 격리하는 데 유리하다. 이 권고는 mixed·single 운영 특성에서 도출한 설계 판단이며, 특정 벤치마크 수치에 근거한 것은 아니다.

2026년 기준으로 이런 구성을 점검할 때는 다음 항목을 함께 확인하는 것이 안전하다: GPU 모델과 보드 유형, 드라이버·GPU Operator 버전, nvidia-smi mig -lgip로 확인한 실제 인스턴스 구성, mig.strategy 설정값(single/mixed), 각 잡의 요구 프로파일과 실제 할당 프로파일, 분산 학습 시 GPU 간 토폴로지와 NCCL 초기화 로그, 혼합 MIG·풀 GPU 노드 여부, Pod Pending 이벤트와 디바이스 플러그인 로그, 프로파일 변경 시 노드 드레인 여부.

핵심 정리

• MIG 프로파일 불일치로 인한 스케줄 실패는 자원 부족이 아니라 자원 형태 해석 불일치 문제다.
• 드라이버 570.124.06~570.158.01 구간에서 MIG·풀 GPU 혼합 노드가 GPU Pod를 무기한 Pending에 묶는 사례가 공식 릴리스 노트에 기록돼 있으며, 570.172.08로 해결된다.
• 같은 메모리 용량이라도 SM 수가 다르면 다른 자원이므로, 메모리 기준 판단만으로는 배치 가능 여부를 확정할 수 없다.
• 분산 학습은 MIG 인스턴스 간 P2P가 동일 물리 GPU 내부로 제한되는 조건 때문에 구조적으로 불리하다.
• mixed는 활용률을, single은 스케줄 예측 가능성을 얻는 트레이드오프이며, 분산 학습 노드와 소형 MIG 풀을 분리하는 것이 문제 격리에 유리하다.

자주 묻는 질문

MIG 프로파일을 바꾸면 기존에 실행 중인 잡은 어떻게 되나?

프로파일 변경은 기존 인스턴스 제거와 재생성을 수반하므로, 해당 인스턴스에서 실행 중인 잡은 중단되거나 다른 노드로 재배치돼야 한다. 운영 중에는 변경 전 노드 드레인과 잡 이관 절차를 먼저 계획해야 한다.

GPU Pod가 Pending 상태일 때 가장 먼저 확인해야 할 로그는 무엇인가?

Pod 이벤트의 Pending 사유와 디바이스 플러그인 로그를 먼저 확인해야 한다. 리소스 요청량과 노드 가용량만 비교해서는 드라이버·플러그인 해석 불일치가 드러나지 않으므로, 드라이버 버전과 GPU Operator 버전을 함께 대조하는 절차가 필요하다.

분산 학습 노드에서는 MIG를 아예 쓰지 말아야 하나?

MIG 인스턴스 간 P2P가 동일 물리 GPU 내부로 제한되는 조건에서는 여러 노드·여러 GPU에 걸친 분산 학습 토폴로지를 MIG로 구성하는 것은 통신 경로 문제를 안고 시작한다. 대안으로 분산 학습 노드는 풀 GPU 또는 동일 프로파일로 고정하고, MIG는 소형 추론·개발 워크로드 전용 풀로 분리하는 구성이 실무적으로 거론된다.

mixed와 single 중 하나를 고를 때 가장 먼저 봐야 할 기준은 무엇인가?

노드 수와 워크로드 종류의 다양성이다. 노드 수가 적고 다양한 크기의 잡이 섞여 들어오면 mixed의 활용률 이득이 복잡성 비용을 상쇄할 수 있다. 반대로 노드 수가 충분해 워크로드별로 노드를 분리할 수 있다면 single로 스케줄 예측 가능성을 확보하는 편이 안전하다.

더 알아보기

GPU 스케줄링과 학습 오케스트레이션: 희소 자원을 어떻게 분배할 것인가 — 이 주제의 종합 가이드