모든 GPU와 모든 GPU 워크로드를 보고,나눠 쓰고, 격리하고, 우선순위를 정합니다.
GPU와 GPU 워크로드를 먼저 보이게 만들고, 그다음 나눠 쓸 수 있게 만드는 운영 계층입니다. 지금 쓰고 계신 GPU 클러스터에서 그대로 시작합니다.
NVIDIA 기본 디바이스 플러그인. 워크로드 하나가 카드 한 장을 통째로 씁니다.
카드 한 장을 여러 워크로드가 나눠 씁니다. 여기까지는 오픈소스입니다. Dynamia의 HAMi Enterprise는 오버커밋, 우선순위, 터보, 탄력 메모리를 더합니다.
카드는 한 장, 작업도 하나. 나머지는 아무도 못 씁니다.
Kubernetes는 GPU를 정수 단위로만 배정합니다. GPU를 하나 요청한 작업은 카드를 통째로 가져가고, 그 작업이 카드의 일부만 쓰더라도 나머지에는 아무도 손을 대지 못합니다. 대부분의 팀은 이 일이 벌어지는 것을 보지 못합니다. 어떤 워크로드가 어느 카드에 올라가 있는지, 배정되었다고 표시된 카드가 실제로 일하고 있는지, 어느 카드가 고장이고 어느 카드가 비어 있는지. 그래서 카드를 더 삽니다.
약속한 메모리 29,000 MiB. 카드에 들어가지 않는 5,972 MiB는 서버 메인 메모리가 받습니다.
두 막대는 같은 물리 카드이며 같은 폭으로 그렸습니다. KServe 환경에서 NVIDIA A10G 한 장으로 측정했습니다. 이 숫자는 카드 종류와 워크로드에 따라 달라집니다. 칸 크기는 도식이며 실제 요구량은 모델마다 다릅니다.
MIG, 타임 슬라이싱, MPS는 카드가 가진 메모리 안에서만 나눕니다
NVIDIA는 카드 한 장에 여러 워크로드를 올리는 방법을 이미 세 가지 제공합니다. 셋 다 카드가 물리적으로 가진 메모리 안에서만 나눕니다.
MIG는 카드를 고정된 하드웨어 구획으로 나눕니다. 타임 슬라이싱은 워크로드마다 카드 전체를 번갈아 내줍니다. MPS는 여러 프로세스가 동시에 카드에 작업을 보내게 합니다.
표를 옆으로 밀면 모든 열을 볼 수 있습니다.
| 무엇을 할 수 있나 | 순수Kubernetes | MIG | 타임 슬라이싱 | MPS | HAMi Enterprise+ Wave GPU |
|---|---|---|---|---|---|
| 카드 한 장을 여러 워크로드가 나눠 쓰기 | – | ✓최대 7개 · 프로파일 고정 | ✓제한 없음 | ✓최대 48개 | ✓MiB 단위오픈소스 |
| 한 워크로드의 메모리를 다른 워크로드로부터 보호 | –해당 없음 | ✓ | –없음 | ✓CUDA 11.4+ · 상한 설정 필요 | ✓하드 격리오픈소스 |
| 하나가 죽어도 나머지는 살아남기 | ✓ | ✓ | ✓ | ●제약 있음 | ✓오픈소스 |
| 쓸 수 있는 카드 | ✓전부 | ●Ampere 이후 데이터센터 카드만 | ✓Pascal 이후 | ✓대부분 | ✓NVIDIA, Ascend, Cambricon 등 여섯 개 계열오픈소스 |
| 카드에 없는 메모리까지 워크로드에 배정 | – | – | – | – | ✓쉬는 모델을 호스트 메모리로 |
| 중요한 워크로드를 먼저 보내기 | – | – | – | – | ✓뒤로 밀린 작업은 죽지 않고 멈춤 |
| 실행 중에 메모리 한도 바꾸기 | –재시작 필요 | –재시작 필요 | – | – | ✓재시작 없음 |
마지막 열에서 “오픈소스”라고 표시한 행은 HAMi 오픈소스 프로젝트에 들어 있습니다. 표시가 없는 세 행은 HAMi Enterprise가 필요합니다.
NVIDIA 공식 문서 기준입니다. Improving GPU Utilization in Kubernetes, MIG User Guide, MPS 문서. MIG는 Ampere 이후 데이터센터 카드가 필요하므로 L40S, L4, A10G에서는 쓸 수 없습니다. 셋 다 카드의 물리 용량 안에서만 나누고, 우선순위 개념이 없으며, 실행 중에 한도를 바꾸지 못합니다.
두 단계입니다. 첫 단계는 아무것도 설치하지 않습니다.
지금 쓰는 GPU 클러스터 위의 네 화면입니다. NVIDIA 기본 디바이스 플러그인, 카드 단위 배정, 새로 설치하는 것 없음. 모든 카드, 모든 워크로드, 29가지 점검, 그리고 측정한 수요로 교정한 예약값.
카드 한 장을 여러 워크로드가 나눠 쓰되, 물리적으로 들어가는 한계를 넘어섭니다. 메모리 오버커밋, 작업 우선순위, 터보 모드, 탄력 메모리. 이 페이지의 측정 결과가 나온 자리입니다.
순서가 중요합니다. 우리 클러스터의 숫자를 먼저 보고, 카드를 나눠 쓸 만한지 그다음에 판단합니다.
지금 쓰는 클러스터 위의 네 화면
Wave GPU는 클러스터가 이미 내보내고 있는 정보를 읽어 네 개의 화면으로 만듭니다. 네 화면 모두 카드 공유를 설치하지 않아도 됩니다.
클러스터의 모든 카드를 한 화면에서
카드 하나에 타일 하나, 클러스터의 지도입니다. 순수 GPU 클러스터에서는 카드마다의 상태와 그 위의 워크로드를 보여주고, 카드를 나눠 쓰는 클러스터에서는 워크로드에 약속한 메모리까지 보여줍니다.
카드가 통째든 나뉘어 있든, 사용 중 · 유휴 · 결함 · 빈 카드를 카드마다 표시합니다. 초록은 실행 중, 회색은 유휴, 빨강은 느려짐입니다.
지도를 벗어나지 않고 상세가 열립니다. 물리 용량, 약속한 메모리, 실제로 올라가 있는 양, 호스트 메모리로 넘어간 양, 그리고 카드 상태 점검까지 한 패널에서 봅니다.
카드를 나눠 쓰면, 워크로드에 약속한 메모리와 물리 한계선, 그리고 그 한계를 넘겨 약속한 양을 그대로 그립니다. 사용량만 보여주는 대시보드에는 없는 숫자입니다.
“GPU가 지금 어떤 상태인가”에 카드 → 분할 → 약속 → 워크로드의 사슬로 답합니다.
GPU 워크로드가 실제로 무엇을 하고 있는지
클러스터의 모든 GPU 워크로드를 한 테이블에서 봅니다. 무엇을 쓰는지, 어떻게 실행되는지, 어떻게 배치되었는지.
메모리와 연산의 사용량 대비 예약량, 지난 24시간의 패턴, 그리고 현재 상태. 워크로드가 느려졌을 때는 원인이 되는 워크로드까지 표에서 지목합니다.
Deployment, Job, InferenceService 같은 객체 종류. vLLM 같은 실행 런타임. 그리고 Pod들이 한 묶음으로 함께 떠야 하는지 여부.
배치한 스케줄러(HAMi, Volcano, KAI)와 거쳐 온 큐(Kueue). 여러 스케줄러가 함께 도는 클러스터에서도 배치 경로가 계속 보입니다.
“GPU 워크로드가 잘 돌고 있나”에 표 하나로 답합니다.
29가지 점검: 하드웨어 12가지, 공유 계층 17가지
GPU 장애는 두 갈래에서 옵니다. 하드웨어의 고장과 공유 계층의 고장은 원인도 조치도 다르기 때문에, 나눠서 점검합니다.
XID 오류, ECC 메모리 오류, 온도, PCIe, 스로틀링을 DCGM 신호로 읽어 점검합니다. 카드를 나눠 쓰든 아니든 모든 GPU 클러스터에서 동작합니다.
이 17가지는 카드를 나눠 쓸 때만 해당합니다. 격리, 어드미션 webhook, 디바이스 플러그인, 설정 드리프트, 라이선스를 다룹니다. 발견마다 원인과 영향받는 Pod를 원문 그대로 인용해 함께 보여줍니다.
레이블 재적용처럼 안전한 수리는 자동으로 적용합니다. Pod 재시작은 준비만 해두고 승인을 기다립니다.
조용히 꺼진 격리를 사람이 알아차리기 전에 찾아냅니다.
추측으로 잡은 GPU 예약을 측정으로 교정합니다
GPU 예약은 대부분 추측으로 시작합니다. GPU Sizing은 워크로드가 실제로 얼마나 쓰는지 재고, 거기에 맞는 예약값을 제안합니다.
워크로드가 GPU를 실제로 얼마나 쓰는지 재고 예약값과 비교합니다. 차이가 크면 더 작은 값을 제안합니다.
메모리는 그 워크로드가 도달했던 최고점 아래로는 절대 깎지 않습니다. 메모리 한도를 넘으면 프로세스가 종료되기 때문입니다. 이미 알맞은 워크로드에는 제안하지 않습니다.
스스로 바꾸는 것은 없습니다. 화면에서 승인하거나 풀 리퀘스트로 내보냅니다. 적용 뒤에 워크로드가 한도를 넘으면 이전 값으로 되돌립니다.
예약이 측정값에 맞으면, 같은 카드에 더 많은 워크로드가 안전하게 들어갑니다.
지금 쓰는 클러스터에서 그대로 동작합니다
위의 네 화면은 이미 운영 중인 GPU 클러스터 말고는 아무것도 설치하지 않습니다. NVIDIA 기본 디바이스 플러그인, 워크로드 하나에 카드 한 장, 공유 계층 없음. 다시 쓸 것이 없습니다.
Wave GPU는 위에 얹는 계층입니다. 쓰던 스케줄러를 바꾸지 않습니다.
Kubeflow, Kueue, KServe를 쓰는 클러스터에 그대로 들어갑니다.
PyTorch, TensorFlow, vLLM 워크로드가 지금 그대로 실행됩니다.
위의 네 화면은 이미 운영 중인 GPU 클러스터 말고는 아무것도 설치하지 않습니다. 아래부터가 두 번째 단계, 카드를 나눠 쓰는 이야기입니다.
Dynamia의 HAMi Enterprise로 카드 한 장을 여러 워크로드가 나눠 씁니다
HAMi는 Dynamia가 만든 Kubernetes용 공유 계층입니다. 기본 공유 기능은 HAMi 오픈소스 프로젝트에 들어 있습니다. 네 가지 기능이 HAMi Enterprise에서 더 열립니다. 오버커밋, 우선순위, 터보, 탄력 메모리입니다. Wave GPU는 이 다섯 가지를 모두 운영합니다. 어디까지 나눠 써도 안전한지 측정하고, 설정을 제안하고, 적용한 뒤에 무슨 일이 일어나는지 지켜봅니다.
카드 한 장을 여러 워크로드가 안전하게 나눠 씁니다
“GPU 0.5개”를 요청하지 않습니다. 매니페스트에 MiB 숫자를 적으면, 컨테이너에는 정확히 그만큼만 보입니다.
PyTorch와 TensorFlow가 코드 변경 없이 실행됩니다. 인프라 계층에서만 동작합니다.
NVIDIA, Huawei Ascend, Cambricon, Hygon, Iluvatar, Moore Threads를 같은 방식으로 다룹니다.
표준 Kubernetes 위에 얹는 미들웨어입니다. 스케줄러는 있던 자리에 그대로 둡니다.
resources:
limits:
nvidia.com/gpu: 1
nvidia.com/gpumem: 10000 # MiB · 하드 상한
nvidia.com/gpucores: 30 # % · 경합할 때의 몫쉬는 모델을 호스트 메모리로 내려 일하는 모델이 카드를 쓰게 합니다
오버커밋은 카드가 물리적으로 가진 것보다 더 많은 메모리를 워크로드에 약속하는 것입니다.
일정 시간 요청이 없는 추론 모델은 GPU 메모리에서 서버 메인 메모리로 내려갑니다. 사람이 정리하지 않습니다.
새 요청이 들어오면 모델은 다시 GPU 메모리로 올라옵니다. 호출하는 쪽은 이 과정을 알지 못합니다.
메모리 한도를 물리 용량보다 크게 잡을 수 있어, 오버커밋 없이 카드를 나눠 쓸 때와 견주어 같은 카드에 추론 서비스가 2배에서 3배 들어갑니다. 카드를 전혀 나누지 않은 상태와 견주면 마지막 섹션의 결과가 더 큽니다.
비싼 GPU 메모리가 고정 저장소이기를 그만둡니다. 지금 일하고 있는 것을 위한 빠른 저장소가 됩니다.
네 워크로드 모두 자기가 살아 있다고 봅니다. 자기가 둘 중 어디에 앉아 있는지는 아무도 알지 못합니다.
모든 모델이 동시에 바쁘면 이것은 성립하지 않습니다. 모델들이 PCIe 구간을 오르내리며 전체가 느려집니다. 값은 가끔씩만 쓰는 모델 묶음에서 나옵니다. 안전한 배율은 Wave GPU가 노드마다 계산해 권고합니다.
운영 서비스를 먼저 보내되, 뒤로 밀린 작업을 죽이지 않습니다
실시간 추론처럼 늦으면 안 되는 워크로드가 요청하는 즉시 연산을 가져갑니다.
낮은 우선순위 작업은 CUDA 커널 경계에서 멈춥니다. GPU 작업 한 단위와 다음 단위 사이의 안전한 지점입니다. 강제 종료가 아닙니다.
멈춘 작업은 상태를 GPU 메모리에 그대로 두고, 카드가 다시 비면 그 자리에서 이어서 갑니다.
운영 서비스가 한가한 구간을 배치 작업이 채웁니다. 운영 응답시간은 그대로입니다.
낮은 우선순위 작업을 죽이지 않습니다. 안전한 지점에서 멈췄다가 카드가 비면 이어서 갑니다. 하던 작업은 그동안 계속 GPU 메모리에 남아 있습니다.
켜는 것은 어노테이션 한 줄, nvidia.com/priority입니다. 워크로드 코드는 바뀌지 않습니다. 어느 워크로드를 높은 쪽으로 둘지는 Wave GPU가 지난 경합 기록을 보고 제안합니다.
메모리 격리는 켜 둔 채, 나누지 않은 카드에 가까운 속도로
카드를 나눠 쓰려면 엔진이 모든 GPU 호출을 한 번씩 들여다봐야 합니다. 워크로드가 작은 연산을 많이 보낼수록 이 비용이 쌓입니다.
메모리 격리는 그대로 유지됩니다. 연산 쪽 검사만 우회합니다. 격리를 포기하는 것이 아닙니다.
밀도보다 속도가 먼저인 LLM 서빙과 실시간 추론에 씁니다.
환경 변수로 켭니다. 코드 수정은 없습니다.
공유 계층이 없는 같은 카드와 견준 속도 손실입니다. 낮을수록 좋습니다. NVIDIA A10G 한 장에서, 작은 연산을 연달아 보내는 워크로드로 측정했습니다.
작은 연산을 연달아 보내는 워크로드로 측정했습니다. 큰 행렬 연산으로 이루어진 워크로드는 전체 시간에서 검사가 차지하는 비중이 작아, 차이도 그만큼 작아집니다.
트래픽이 튀면 컨테이너를 재시작하는 대신 한도를 올립니다
컨테이너를 재시작하지 않고, 처리 중인 요청도 끊지 않은 채 GPU 메모리 한도를 바꿉니다.
트래픽이 튀어 메모리가 순간 뛰면, 워크로드가 노드에 아직 남아 있는 메모리를 잠시 빌려 씁니다.
부하가 가라앉으면 한도가 다시 내려가고, 그 메모리는 같은 노드의 다른 워크로드에게 돌아갑니다.
재시작에 쓰는 시간이 곧 서비스가 답하지 못하는 시간인 장시간 LLM 서빙에 씁니다.
급증이 지나가면 한도가 다시 내려가고, 그 메모리는 같은 노드의 다른 워크로드에게 돌아갑니다.
고정 한도만 있는 구성에서는 급증 구간에 프로세스가 종료되고, 다시 뜨는 동안 그 서비스는 응답하지 못합니다.
카드 한 장에 워크로드가 몇 개 들어가나
같은 카드에 더 많은 워크로드를 올립니다. 카드를 더 사지 않습니다. 세 열은 같은 시험을 세 가지 방식으로 돌린 것이라, 서로 직접 견주어 읽을 수 있습니다.
23,028 MiB짜리 NVIDIA A10G 한 장에서, 같은 클러스터의 같은 워크로드로 2026년 6월과 7월에 측정했습니다. 결과는 카드 종류와 워크로드에 따라 달라지므로, 3주 파일럿에서 고객사 클러스터 기준으로 다시 측정합니다.