HAMi 해설: GPU는 놀고 있는데 청구서는 줄지 않는 이유

Dynamic Resource Allocation과 그 알파 단계의 partitionable-device·consumable-capacity 확장이 나오기 전까지, Kubernetes는 GPU를 카드 전체 단위로만 스케줄링했으며 디바이스의 일부만 할당하는 네이티브 옵션이 없었습니다. 예를 들어 파드가 80 GB H100에서 4 GB만 필요하더라도, 파드의 생애 동안 GPU 전체를 점유합니다. 이는 공유 클러스터에서 값비싼 하드웨어의 심각한 저활용으로 이어집니다. 피크 트래픽에 맞춰 설계된 챗봇은 비피크 시간대에 전용 카드 위에서 놀고 있을 수 있고, 여러 추론 서비스가 낮은 사용량에도 불구하고 각각 별도의 GPU에서 실행되는 경우가 많으며, 모니터링 대시보드는 모든 GPU가 할당되었다고 보여주지만 nvidia-smi 같은 도구는 실제 사용률이 극히 낮다는 것을 드러내곤 합니다. 그 결과 클러스터가 가득 찬 것처럼 보이기 때문에 추가 GPU를 위한 새로운 예산 요청이 생겨납니다. DRA는 디바이스가 선언한 예산의 초과 커밋을 막음으로써 이 간극을 좁히지만, 파드가 일단 실행된 뒤에는 리소스 제한을 네이티브하게 강제하지 않으며, 그 일은 여전히 디바이스 드라이버의 몫입니다. 바로 여기서 HAMi가 가치를 제공합니다.

HAMi(Heterogeneous AI Computing Virtualization Middleware)는 파드가 GPU 메모리와 연산 자원의 정확한 몫을 요청할 수 있게 하고, 컨테이너 내부의 강제 계층이 그 한도를 지키게 함으로써 이 간극을 메웁니다. 애플리케이션이나 이미지에는 아무런 변경이 필요 없습니다. SNOW와 NIO 같은 기업이 프로덕션에서 HAMi를 운영하고 있으며, 프로젝트는 2026년 7월 CNCF Incubating 단계에 도달했습니다.

HAMi는 실제로 무엇인가?

HAMi는 Kubernetes를 위한 오픈소스 GPU 가상화 계층입니다. 파드가 메모리와 AI 가속기 연산 자원의 정확한 양을 요청하게 하고, 그만큼의 여유 용량이 있는 디바이스로 파드를 스케줄링한 뒤, 런타임에 그 슬라이스에 바인딩합니다. 같은 모델이 NVIDIA GPU, Cambricon MLU, Hygon DCU, Ascend NPU, Moore Threads, MetaX 등 여러 가속기에 걸쳐 적용되며, 각 가속기는 자체 device plugin과 격리 백엔드를 통해 지원됩니다. 예를 들어 NVIDIA에서는 HAMi가 기본 device plugin을 대체하고 컨테이너 내부에서 CUDA 드라이버 API를 가로채 메모리 상한을 강제하며, 다른 벤더들은 이에 상응하는 라이브러리 또는 하드웨어 수준의 격리를 제공합니다.

사용자 경험은 의도적으로 단순하게 설계되어 있습니다. 표준 디바이스 리소스 요청에 하나 이상의 제한을 추가하면, 스케줄러가 스케줄링 시점에 이를 읽어 충분한 여유 메모리와 연산 자원이 있는 카드를 찾습니다. NVIDIA에서는 기존처럼 nvidia.com/gpu를 요청하면서 그 옆에 두 개의 확장 리소스인 nvidia.com/gpumem과 nvidia.com/gpucores를 추가하면 됩니다.

resources:
  limits:
    nvidia.com/gpu: 1       
    nvidia.com/gpumem: 8000 
    nvidia.com/gpucores: 30 

두 가지 비교를 통해 이 격리 모델을 맥락 속에서 볼 수 있습니다. MIG는 하드웨어 경계를 긋습니다. 각 인스턴스는 자체 SM과 함께 L2 캐시 슬라이스, 메모리 컨트롤러, DRAM 채널을 관통하는 전용 경로를 갖습니다. HAMi의 경계는 벽이 아니라 울타리입니다. 제한은 컨테이너 내부에서 소프트웨어로 강제되며, 워크로드를 예산 안에 안정적으로 붙잡아 두지만 디바이스 수준의 장애까지 가둘 수는 없습니다. 공유 카드에서 발생한 프로세스 행(hang), 드라이버 리셋, XID 에러는 여전히 그 카드의 모든 테넌트에게 영향을 미칩니다. 다만 둘은 서로 다른 계층에서 동작하며, 경쟁 관계가 아니라 상호 보완적일 수 있습니다. HAMi가 MIG를 직접 구동하는 방법은 뒤에서 다시 다루겠습니다.

반면 time-slicing과 비교하면 HAMi는 안정성 측면에서 상당한 개선을 제공합니다. Time-slicing은 단순히 하나의 카드를 여러 개의 스케줄 가능한 복제본으로 광고하고 연산 엔진에서 워크로드들을 교차 실행할 뿐, 복제본별 메모리 상한이나 격리는 제공하지 않습니다. 그래서 한 워크로드가 명목상의 몫을 넘어 메모리를 할당하고 다른 워크로드까지 함께 무너뜨리기가 위험할 정도로 쉽습니다. HAMi는 대신 초과 할당을 거부합니다. 다음 로그에서 PyTorch는 nvidia.com/gpumem으로 설정한 1000 MB 제한과 일치하는 총 용량을 보고합니다. 파드가 이를 초과하려 하자 할당자가 OOM 에러로 이를 막았고, 다른 vGPU 테넌트들은 영향을 받지 않았습니다.

(EngineCore pid=95) ERROR 07-11 21:15:46 [core.py:1231] torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 20.00 MiB. GPU 0 has a total capacity of 1000.00 MiB of which 12.00 MiB is free. Including non-PyTorch memory, this process has 1020.00 MiB memory in use. Of the allocated memory 864.68 MiB is allocated by PyTorch, and 41.32 MiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True to avoid fragmentation.  See documentation for Memory Management  (https://docs.pytorch.org/docs/stable/notes/cuda.html#optimizing-memory-usage-with-pytorch-cuda-alloc-conf)

공유 GPU 요청은 HAMi를 어떻게 통과하는가

매니페스트에서 강제되는 슬라이스에 이르기까지, 요청은 아래 다이어그램처럼 네 구성 요소의 손을 거칩니다. device plugin이 각 카드의 용량을 광고하고, mutating webhook이 파드를 HAMi의 스케줄러로 재라우팅하며, scheduler extender가 노드와 슬라이스를 고르고, 컨테이너 내부의 라이브러리가 런타임에 그 슬라이스를 강제합니다.

각 노드에서 DaemonSet으로 실행되는 device-plugin은 벤더의 관리 라이브러리(예: nvidia-smi를 구동하는 NVIDIA의 NVML)를 통해 30초마다 로컬 디바이스를 폴링합니다. 그런 다음 노드에 hami.io/node-<vendor>-register 어노테이션을 패치하는 방식으로 이 텔레메트리 데이터를 게시합니다.

kubectl get nodes gtrekter -o yaml
apiVersion: v1
kind: Node
metadata:
  annotations:
    hami.io/node-handshake: Requesting_2026-07-09 09:03:57
    hami.io/node-nvidia-register: '[{"id":"GPU-a2fd58d2-edbe-4cfd-4dbd-d4197b35431e","count":10,"devmem":6141,"devcore":100,"type":"NVIDIA GeForce RTX 4050 Laptop GPU","mode":"hami-core","health":true,"devicepairscore":{}}]'
    nvidia.com/gpu-driver-upgrade-enabled: "true"
  ...

파드가 생성되면 API 서버는 HAMi의 mutating webhook을 호출하고, webhook은 NVIDIA, Ascend, AWS Neuron 등 지원되는 디바이스 드라이버들에 대해 파드의 매니페스트를 검사합니다. 각 드라이버는 컨테이너의 resources.limits에서 인식 가능한 리소스 키를 확인합니다. 예를 들어 NVIDIA 드라이버는 nvidia.com/gpu, nvidia.com/gpumem, nvidia.com/gpucores를 찾고, Cambricon MLU 드라이버는 cambricon.com/vmlu를 매칭합니다. 호환되는 요청이 감지되는 즉시 HAMi는 파드의 schedulerName을 hami-scheduler로 업데이트하여, 파드가 기본 Kubernetes 스케줄러가 아니라 HAMi의 디바이스 인지 스케줄링 로직으로 처리되도록 보장합니다.

참고: HAMi에서는 nvidia.com/gpu: 1 요청이 더 이상 "카드 한 장 전체"가 아니라 "공유되는 물리 카드 한 장"을 의미하며, 메모리와 코어 제한이 정확한 슬라이스를 결정합니다. 다만 nvidia.com/gpumem을 생략한 파드는 구성된 기본값(카드 메모리의 100%)으로 폴백합니다.

kubectl logs -n hami-system deploy/hami-scheduler -c vgpu-scheduler-extender
I0710 13:51:38.552275  config.go:111] Initializing NVIDIA device
I0710 13:51:38.552355  config.go:248] All devices initialized successfully
...
I0710 14:02:14.161116  devices.go:647] "Resource requirements collected" pod="default/chat-qwen-64c4bd66f9-8qccs" requests=[{"NVIDIA":{"Nums":1,"Type":"NVIDIA","Memreq":4000,"MemPercentagereq":101,"Coresreq":60}}]

vgpu-scheduler-extender는 클러스터의 모든 물리 GPU에 대한 실시간 사용량 맵을 구축합니다. 각 노드의 hami.io/node-nvidia-register 어노테이션에서 디바이스 메타데이터를 읽은 뒤, 해당 노드에 이미 할당된 파드들을 순회하며 소비된 GPU 메모리와 연산 용량을 계산합니다.

kubectl logs -n hami-system deploy/hami-scheduler -c vgpu-scheduler-extender
...
I0710 14:02:14.161182 node_policy.go:82] node node1 used 0, usedCore 0, usedMem 0,
I0710 14:02:14.161191 gpu_policy.go:104] device GPU-a2fd58d2-edbe-4cfd-4dbd-d4197b35431e user 0, userCore 0, userMem 0,
...
I0710 16:54:54.475656 node_policy.go:82] node node1 used 1, usedCore 60, usedMem 4000,
I0710 16:54:54.475667 gpu_policy.go:104] device GPU-a2fd58d2-edbe-4cfd-4dbd-d4197b35431e user 1, userCore 60, userMem 4000,

그다음 스케줄러는 용량이 부족한 노드를 걸러내고, 구성된 HAMi 스케줄링 정책(nodeSchedulerPolicy와 gpuSchedulerPolicy, 차트 기본값은 노드 수준 binpack과 GPU 수준 spread)에 따라 남은 노드들을 스코어링합니다. 선택된 노드와 GPU 슬라이스는 UUID,Type,memMB,cores 레코드의 쉼표 구분 목록 형태로 파드의 어노테이션(hami.io/vgpu-devices-allocated)에 기록됩니다.

$ kubectl describe pod -n default embed-bge-f84696cc9-7587j
Name:         embed-bge-f84696cc9-7587j
Labels:       hami.io/vgpu-node=node1
...
Annotations:  hami.io/vgpu-devices-allocated: GPU-a2fd58d2-edbe-4cfd-4dbd-d4197b35431e,NVIDIA,2000,30:;
              hami.io/vgpu-devices-to-allocate: ;;
              hami.io/bind-phase: success
              hami.io/bind-time: 1783702494
...

파드가 노드에 바인딩되면 Kubelet은 해당 노드의 HAMi device-plugin에서 Allocate를 호출합니다. 플러그인은 파드의 hami.io/vgpu-devices-to-allocate 어노테이션(플러그인이 소비한 뒤에는 비워지며, 위 describe 출력에서 비어 있는 이유가 바로 이것입니다)을 읽어 요청된 슬라이스를 해석하고, 대상 물리 디바이스와 정확한 연산·메모리 제한을 식별합니다. 그런 다음 컨테이너가 그 특정 슬라이스에 대해 실행되는 데 필요한 것들, 즉 환경 변수, 호스트 경로 마운트(강제 라이브러리 포함), 디바이스 핸들을 담은 응답을 반환합니다.

kubectl logs -n hami-system ds/hami-device-plugin -c device-plugin | grep -i 'Allocate Response'
...
I0710 16:54:54.499747  232069 server.go:719] Allocate Response [envs:{key:"CUDA_DEVICE_MEMORY_LIMIT_0" value:"2000m"} envs:{key:"CUDA_DEVICE_MEMORY_SHARED_CACHE" value:"/usr/local/vgpu/584ed76a-0856-40b3-8113-1ad696daa252.cache"} envs:{key:"CUDA_DEVICE_SM_LIMIT" value:"30"} envs:{key:"LIBCUDA_LOG_LEVEL" value:"1"} envs:{key:"NVIDIA_VISIBLE_DEVICES" value:"GPU-a2fd58d2-edbe-4cfd-4dbd-d4197b35431e"} mounts:{container_path:"/usr/local/vgpu/libvgpu.so" host_path:"/usr/local/vgpu/libvgpu.so.v2.9.0" read_only:true} mounts:{container_path:"/usr/local/vgpu" host_path:"/usr/local/vgpu/containers/1a5bac44-7888-4ea5-9382-3ef49ae1f1ba_tei"} mounts:{container_path:"/tmp/vgpulock" host_path:"/tmp/vgpulock"} mounts:{container_path:"/etc/ld.so.preload" host_path:"/usr/local/vgpu/ld.so.preload" read_only:true}]

Kubelet은 컨테이너 생성 시 이 응답을 컨테이너에 직접 적용합니다. 그 시점부터 HAMi의 프리로드된 제어 라이브러리가 애플리케이션과 벤더 드라이버 사이에 자리 잡고 프로세스 내부에서 슬라이스를 강제합니다. 이 라이브러리는 드라이버의 메모리 할당 호출을 가로채 각 요청을 슬라이스의 예산과 대조하고, 워크로드가 상한을 초과하려 하면 OOM 에러를 반환합니다. 또한 (nvidia-smi 같은) 드라이버 관리 쿼리도 가로채 재작성하여, 보고되는 총 용량이 할당된 제한을 반영하고 여유 용량이 그 제한에서 현재 사용량을 뺀 값을 반영하도록 보장합니다.

kubectl exec -n default chat-qwen-64c4bd66f9-8qccs -c vllm -- env
CUDA_VERSION=13.0.2
NVIDIA_VISIBLE_DEVICES=GPU-a2fd58d2-edbe-4cfd-4dbd-d4197b35431e
CUDA_DEVICE_MEMORY_LIMIT_0=4000m
CUDA_DEVICE_SM_LIMIT=60
CUDA_DEVICE_MEMORY_SHARED_CACHE=/usr/local/vgpu/5e999bc3-2dbf-46b0-ba81-cc479a1c11dd.cache
...
 
kubectl exec -n default chat-qwen-64c4bd66f9-8qccs -c vllm -- cat /etc/ld.so.preload
/usr/local/vgpu/libvgpu.so
 
kubectl exec -n default chat-qwen-64c4bd66f9-8qccs -c vllm -- nvidia-smi --query-gpu=memory.total --format=csv,noheader
4000 MiB
[HAMI-core Msg(272:133498069993280:multiprocess_memory_limit.c:703)]: Cleanup on exit for PID 272
[HAMI-core Msg(272:133498069993280:multiprocess_memory_limit.c:739)]: Exit cleanup complete for PID 272

청구서를 움직이는 스케줄링 정책

앞서 언급했듯이 스케줄러는 먼저 용량이 부족한 노드를 걸러냅니다. 남은 후보들에 대해 HAMi는 노드 수준과 GPU 수준이라는 두 개의 별개 스케줄링 계층을 사용해 최적의 배치를 결정합니다. 현재 HAMi는 각 계층에서 두 가지 주요 전략을 지원합니다. binpack(작업을 최대한 밀도 있게 채우기)과 spread(작업을 최대한 넓게 분산하기)입니다.

metadata:
  annotations:
    hami.io/node-scheduler-policy: "binpack"
    hami.io/gpu-scheduler-policy: "binpack"

두 정책 모두 뚜렷한 운영적·재무적 트레이드오프를 동반합니다.

노드 수준 전략

노드 수준에서 binpack 정책은 워크로드를 가능한 한 적은 수의 머신에 밀도 있게 채웁니다. 이 접근은 클러스터 오토스케일러가 빈 노드를 빠르게 드레인하고 내릴 수 있게 하여 클라우드 인프라 청구서를 직접적으로 줄입니다. 하지만 이 밀도는 테넌트를 집중시키므로, 단일 노드나 드라이버 장애의 폭발 반경이 훨씬 커지고, 대역폭 헤드룸이 줄어들어 경합이 증가합니다.

반대로 spread 정책은 워크로드를 사용 가능한 모든 노드에 고르게 분산합니다. 노드별 경합을 낮춰 예기치 않은 트래픽 스파이크에 대비한 헤드룸을 제공하고 장애 도메인을 안전하게 분산하는 데는 성공하지만, 모든 노드를 "웜(warm)" 상태로 유지합니다. 그 결과 오토스케일러가 클러스터를 축소할 수 없어, 유휴 용량에 대한 비용을 계속 지불하게 됩니다.

GPU 수준 전략

GPU 수준에서 binpack 정책은 하나의 물리 카드를 완전히 채운 뒤에야 다음 카드에 워크로드를 스케줄링합니다. 이는 분할되지 않은 리소스가 필요한 대형 모델을 위해 완전히 비어 있는 GPU를 보존하고, 하나의 카드를 공유하는 작은 슬라이스의 수를 최대화합니다. 본질적인 트레이드오프는 카드를 최대한 밀도 높게 만든다는 점으로, "시끄러운 이웃(noisy-neighbor)" 압력을 극대화하고 많은 수의 테넌트를 단일 카드 XID 장애에 노출시킵니다.

다른 선택지인 spread 정책은 사용 가능한 모든 카드에 워크로드를 고르게 배분합니다. 연산과 메모리 대역폭 경합을 최소화하므로 지연에 민감한 추론 워크로드에는 더 나은 선택입니다. 단점은 클러스터 전반에 걸쳐 가용 메모리를 파편화한다는 점으로, 이후 크고 연속적인 메모리가 필요한 대형 작업은 클러스터 전체의 여유 메모리 총량이 기술적으로는 충분하더라도 스케줄링에 실패할 수 있습니다.

이들은 배치 시점에만 적용되는 정책입니다. HAMi는 새 파드가 도착할 때 스코어링할 뿐, 실행 중인 워크로드를 능동적으로 마이그레이션하지 않습니다. 따라서 재무적 절감은 파드가 교체되면서 실현되며, binpack은 탄력성이 높은 추론 플릿에서는 공격적으로 효과를 내지만, 수명이 길고 고정된 파드에서는 그 효과가 훨씬 덜합니다.

HAMi와 MIG: 상호 보완적인 계층

울타리와 벽은 서로 다른 계층에서 동작하며, 클러스터마다 하나만 골라야 하는 것도 아닙니다. HAMi는 하나의 풀에서 둘 다 관리할 수 있습니다. 동적 MIG를 활성화하면 HAMi가 nvidia-mig-parted를 구동해 들어오는 작업에 맞게 MIG 지오메트리를 분할하고 다시 분할하며, 수동 nvidia-smi mig 작업과 미리 확정된 슬라이스 레이아웃을 없애줍니다. 파드는 이전과 똑같이 nvidia.com/gpu와 nvidia.com/gpumem을 요청하면 됩니다. 기본적으로 스케줄러는 이를 hami-core 슬라이스나 MIG 인스턴스 중 어느 쪽으로든 충족할 수 있으며, 강한 격리가 필요한 워크로드는 nvidia.com/vgpu-mode: "mig" 어노테이션으로 자신을 벽 쪽에 고정할 수 있습니다. 트레이드오프는 세분성입니다. MIG 배치는 허용되는 가장 가까운 지오메트리로 올림됩니다(A100-40GB에서 8 GB 요청은 2g.10gb 인스턴스에 배치됩니다). hami-core라면 요청한 만큼만 정확히 울타리를 쳐주었을 것입니다.

운영의 현실

• HAMi는 device plugin을 대체한다. HAMi device plugin과 표준 nvidia-device-plugin은 둘 다 nvidia.com/gpu를 소유하려 합니다. 같은 노드에서 둘을 함께 실행하면 리소스 등록을 두고 서로 다투게 되어 실제 카운트와 가상화된 카운트 사이에 용량 간극이 생기고, GPU 할당은 마지막에 등록한 플러그인이 처리하게 되어 HAMi의 격리를 조용히 우회합니다. GPU Operator를 운영한다면 드라이버, 컨테이너 툴킷, DCGM 용도로는 유지하되, HAMi가 관리하는 노드에서는 그 device plugin을 비활성화하세요. gpu=on 노드 라벨로 HAMi의 범위를 제한하고, 첫날부터 클러스터 전체가 아니라 풀 단위로 하나씩 배포하세요.

• 스케줄러 이미지는 컨트롤 플레인을 따라간다. hami-scheduler는 기본 kube-scheduler 이미지를 감싸고 있으며, 현재 차트는 설치 시점에 API 서버 버전에서 그 태그를 결정합니다. 즉, Kubernetes를 업그레이드해도 다음 Helm 업그레이드 전까지는 이전 스케줄러가 조용히 계속 실행됩니다. scheduler.kubeScheduler.image.tag를 Kubernetes 업그레이드 런북에 추가하세요. 그러지 않으면 6개월쯤 뒤에 발목을 잡힐 것입니다.

• gpucores는 스로틀링할 뿐 예약하지 않는다. 스케줄러는 배치 시점에 몫을 장부에 기록해 두지만, 런타임에 그 몫은 상한일 뿐 결코 하한이 아닙니다. 제한기는 하드웨어 파티션이 아니라 커널 런치 시점에 검사되는 토큰 버킷입니다. 목표치 주변의 진동, 카드가 유휴 상태일 때 몫을 넘는 버스트, 버스트 도중 이웃이 도착했을 때 제한이 다시 걸리기까지 몇 초간의 겹침을 예상해야 합니다(제한기를 항상 켜두려면 GPU_CORE_UTILIZATION_POLICY=force를 설정하세요). SLO를 확정하기 전에 시끄러운 이웃이 있는 상태에서 p99를 벤치마크하세요.

실무적 권고

GPU 플릿이 A100/H100급이고, 여러 팀이 공유하며, 사용률 대시보드를 재무 리뷰에서 보여주기 민망한 수준이라면, 이번 주에 추론 노드 풀 하나에서 HAMi를 파일럿해 보세요. 설치는 한 오후면 끝낼 수 있습니다. 노드 두 개에 gpu=on 라벨을 붙이고, helm install을 실행하고, 과다 프로비저닝된 추론 Deployment 하나를 gpumem/gpucores 슬라이스로 전환한 뒤, 일주일 동안 돌리면서 할당량을 DCGM 사용률과 대조해 지켜보세요. 검증하려는 산수는 단순합니다. 8-GPU H100 노드는 클라우드와 리전에 따라 온디맨드로 연간 약 $290,000에서 $480,000이 들기 때문에, bin-packing이 비워내는 노드 하나하나가 실제 돈으로 돌아옵니다. 자체 보유 하드웨어라면 H100 한 장에 약 $25–30k이므로, 1,000-GPU 플릿에서 지속 사용률 10%포인트마다 $2.5–3M의 자본 지출이 놀지 않고 일하게 되는 셈입니다.