GPU 플랫폼

Device plugin(장치 자원 제공기): node의 장치를 kubelet에 알리고 container에 장치 접근 정보를 제공하는 확장 구성요소입니다.

host driver가 GPU를 발견하는 단계, device plugin이 kubelet에 resource를 광고하는 단계, scheduler가 Pod request를 맞추는 단계, runtime이 device node를 주입하는 단계는 분리되어 있습니다.

vendor extended resource는 capacity와 allocatable에 정수로 나타나고 일반적으로 overcommit되지 않습니다. label·taint·affinity는 placement를 좁히지만 실제 GPU health와 topology를 자동 검증하지 않습니다.

Pending Pod를 보고 GPU가 없다고 단정하지 않습니다. nvidia-smi, plugin DaemonSet, node allocatable, Pod request, event, runtime allocation을 순서대로 확인합니다.

교육 사례에서 nvidia-smi는 GPU 8개를 보이지만 node allocatable에는 GPU가 없습니다. host driver 인식과 Kubernetes 자원 광고는 별도 경계입니다. device plugin 상태와 kubelet 등록을 확인한 뒤 resource request와 실제 Pod 배치를 대조합니다. request를 적지 않은 Pod가 우연히 GPU에 접근한 사실을 scheduling 보장으로 해석하지 않습니다.

왜 이런가

vendor extended resource는 capacity와 allocatable에 정수로 나타나고 일반적으로 overcommit되지 않습니다. label·taint·affinity는 placement를 좁히지만 실제 GPU health와 topology를 자동 검증하지 않습니다.

언제 문제가 되는가

capacity·request·runtime 불일치 조건이면 진행 근거가 부족합니다.

초보자가 자주 하는 오해

GPU device file을 hostPath로 직접 주입해 scheduler를 우회하지 않습니다. 자원 회계와 격리, health 처리가 깨집니다.

직접 확인하는 방법

host의 GPU UUID와 health를 먼저 확인합니다. device plugin Pod와 kubelet registration log를 확인합니다.

MIG(Multi-Instance GPU, GPU 하드웨어 분할): 지원 GPU를 정해진 compute·memory profile로 나누는 기능이며 지원 제약을 확인해야 합니다.

exclusive GPU는 단순한 운영 모델과 예측 가능성을, time-slicing은 높은 평균 사용률을, Multi-Instance GPU(MIG)는 지원 GPU에서 hardware partition과 독립 resource profile을 제공합니다. 셋은 성능·격리·유연성·운영 복잡도가 다릅니다.

time-slicing workload는 같은 GPU의 memory/compute pressure를 경쟁할 수 있고 한 tenant의 오류가 다른 workload에 영향을 줄 수 있습니다. MIG profile은 고정된 compute/memory slice를 제공하지만 workload 크기와 P2P/NCCL 제약을 확인해야 합니다.

공유 정책은 utilization만으로 정하지 않습니다. tenant 신뢰, model memory, latency SLO, burst, preemption, telemetry와 reconfiguration maintenance를 함께 평가합니다.

교육 사례에서 model이 필요한 peak memory는 12GiB인데 할당 profile의 표기 용량은 10GB입니다. 단위도 다르고 용량도 부족하므로 utilization이 낮아도 배치할 수 없습니다. time slicing으로 GPU 접근을 공유해도 각 workload의 memory 요구가 없어지는 것은 아닙니다. 격리 수준, profile 실제 용량과 동시 부하에서의 지연을 함께 검증합니다.

왜 이런가

time-slicing workload는 같은 GPU의 memory/compute pressure를 경쟁할 수 있고 한 tenant의 오류가 다른 workload에 영향을 줄 수 있습니다. MIG profile은 고정된 compute/memory slice를 제공하지만 workload 크기와 P2P/NCCL 제약을 확인해야 합니다.

언제 문제가 되는가

profile 부족·tenant 경계·SLO 미검증 조건이면 진행 근거가 부족합니다.

초보자가 자주 하는 오해

MIG mode나 profile 변경은 실행 workload와 관리 daemon에 영향을 줄 수 있습니다. node cordon·drain과 지원 matrix, rollback을 갖춘 maintenance에서 수행합니다.

직접 확인하는 방법

model peak memory와 compute duty cycle, latency SLO를 측정합니다. exclusive·MIG·time-slicing별 failure impact와 noisy neighbor를 적습니다.

Rank(분산 작업 참여 번호): world size로 정한 참여 process 집합 안에서 각 process를 구분하는 번호입니다.

분산 학습과 serving은 rank·world size·rendezvous, GPU/NIC topology, collective library와 fabric가 동시에 맞아야 합니다. 한 rank의 느린 data path나 retry는 barrier에서 전체 job을 지연시킵니다.

collective는 topology와 message size에 따라 ring/tree 등 algorithm을 사용합니다. scheduler placement가 rank를 서로 다른 slow path에 두거나 NIC 선택이 틀리면 GPU는 높게 보이면서도 communication wait가 늘 수 있습니다.

성공 여부뿐 아니라 rank별 hostname·GPU UUID·NIC·NUMA·log와 collective 분포를 run ID로 묶습니다. 실패 rank가 사라지기 전에 Pod와 node event를 보존합니다.

교육 사례에서 rank 7만 Socket transport를 선택하고 나머지는 IB transport를 사용했습니다. rank 수가 모두 맞아도 통신 경로가 같지 않으므로 collective 시간이 늘 수 있습니다. log의 transport 선택과 GPU·NIC 배치를 rank별로 연결합니다. network 변경 전 job 설정을 보존하고 같은 message 크기와 참여 수로 재시험해야 비교가 성립합니다.

왜 이런가

collective는 topology와 message size에 따라 ring/tree 등 algorithm을 사용합니다. scheduler placement가 rank를 서로 다른 slow path에 두거나 NIC 선택이 틀리면 GPU는 높게 보이면서도 communication wait가 늘 수 있습니다.

언제 문제가 되는가

rank 누락·topology 편차·retry 증가 조건이면 진행 근거가 부족합니다.

초보자가 자주 하는 오해

분산 시험은 fabric와 GPU를 크게 사용합니다. production queue와 분리하고 duration·message size·node 범위를 승인받습니다.

직접 확인하는 방법

job revision·world size·rank/hostname mapping을 저장합니다. rank별 GPU UUID·NIC·NUMA와 NCCL topology를 수집합니다.