![[NPU 운영 가이드②] NPU 사용률은 낮은데 왜 자원이 부족할까](https://www.notion.so/image/notion%3A%2F%2Fcustom_emoji%2F47e97c56-fad2-49ef-a757-4c5b8458bc95%2F222ddf18-253e-80d8-81cf-007a46c77840?table=block&id=73a3bfd0-3a6c-4d23-b8b3-b0dc26b93a59&cache=v2&width=1200)
![[NPU 운영 가이드②] NPU 사용률은 낮은데 왜 자원이 부족할까](https://www.notion.so/image/attachment%3A545b95a8-db13-481a-ac12-8d2c83bfb4d0%3ANPU_Ops_Guide2.jpg?table=block&id=73a3bfd0-3a6c-4d23-b8b3-b0dc26b93a59&cache=v2&width=1200)
국산 NPU가 대규모 상용 서비스에 쓰이기 시작했습니다. 리벨리온은 2026년 9월 21일 자사 NPU가 SK텔레콤의 상용 AI 서비스 4개에 적용됐다고 밝혔습니다. 적용 대상은 에이닷 통화요약과 스트리밍 음성합성, AI 고객센터, 미끼문자 탐지 기능이며 리벨리온 인프라가 처리하는 트래픽은 하루 약 1,400만 건에 이릅니다.
SK텔레콤은 이 NPU를 서비스마다 따로 두지 않았습니다. NPU 수십 대와 가속 카드 수백 장을 연동해 NPU 팜을 구축하고 사내 여러 서비스가 이 자원을 함께 쓰는 풀 방식으로 운영하고 있습니다.
NPU를 이렇게 공유 자원으로 운영하면서 증설 판단은 더 까다로워졌습니다. 장치가 부족하다는 요청과 모니터링 화면의 수치가 서로 맞지 않는 경우가 생기기 때문입니다. 서비스를 운영하는 팀은 NPU 팜에서 배정받을 장치가 남아 있지 않으면 증설을 요청합니다. 그런데 정작 모니터링 화면의 NPU 사용률은 낮게 나오기도 합니다.
두 값이 어긋나는 것은 사용률과 할당률이 서로 다른 것을 나타내기 때문입니다. 사용률은 배정된 장치가 얼마나 바쁘게 동작하는지를 보여 주고 할당률은 전체 장치 가운데 워크로드에 배정된 장치의 비율을 보여 줍니다. 새 워크로드에 줄 장치가 남았는지는 할당률로 판단하므로 사용률이 낮아도 할당률이 높으면 장치는 부족합니다.
하지만 부족하다고 해서 바로 증설이 필요한 것은 아닙니다. 할당된 NPU 가운데 실제로는 쓰이지 않는 것이 있다면 회수해 새 워크로드에 배정할 수도 있습니다. 그래서 증설 요청이 들어오면 할당된 장치가 실제로 얼마나 쓰이는지부터 확인해야 합니다. 그래야 실제로 장치 증설이 필요한 상황인지, 기존에 할당된 NPU가 충분히 활용되지 않는 상황인지 구분할 수 있습니다.
1. 사용률은 낮은데 할당률은 높은 이유
사용률이 낮은데 할당률이 높아지는 것은 쿠버네티스가 NPU를 실제 사용량이 아니라 장치 개수로 할당하기 때문입니다. 리벨리온 NPU는 디바이스 플러그인이 노드에 rebellions.ai/npu라는 자원으로 등록하고 워크로드는 이 자원을 필요한 개수만큼 요청합니다. 쿠버네티스 디바이스 플러그인 문서에 따르면 이런 확장 자원은 정수 단위로만 요청할 수 있고 오버커밋이나 여러 컨테이너 간 공유도 되지 않습니다.
이렇게 배정된 NPU는 Pod가 종료될 때까지 다른 워크로드가 쓸 수 없습니다. 그동안 장치가 연산을 거의 하지 않더라도 스케줄러는 이 장치를 이미 할당된 자원으로 계산합니다. 할당률은 높게 유지되는데 사용률은 낮게 나오는 상황이 이렇게 만들어집니다.
할당률이 높아도 사용률은 낮을 수 있습니다. 할당률은 장치가 워크로드에 배정됐는지를, 사용률은 배정된 장치가 실제로 연산을 처리한 정도를 나타냅니다.
1-1. 추론 요청이 없어도 풀리지 않는 할당
할당은 남아 있는데 연산이 멈추는 대표적인 경우가 추론 서버입니다. 추론 서버 Pod는 요청이 없는 동안에도 다음 요청을 받기 위해 실행 상태를 유지합니다. 연산은 멈춰도 Pod가 실행 중이므로 NPU 할당도 풀리지 않습니다.
요청이 몰리는 시간과 뜸한 시간의 차이가 큰 서비스일수록 이렇게 기다리는 시간도 길어집니다. 이런 Pod가 늘어날수록 사용률은 낮은데 스케줄러 기준으로는 남은 장치가 없는 상황에 가까워집니다.
1-2. 장치 한 개 단위로만 나뉘는 할당
장치 개수로만 할당한다는 점은 또 다른 낭비도 만듭니다. 워크로드가 장치 하나를 다 쓰지 않아도 하나를 통째로 배정받으므로 쓰지 않는 연산 자원과 메모리까지 함께 묶입니다. GPU도 사정이 같습니다. 쿠버네티스에서
nvidia.com/gpu: 1은 GPU 한 장을 배정한다는 뜻일 뿐 그 안의 VRAM이나 연산을 얼마나 쓸지까지 정해 주지는 않습니다.장치째 배정된 가속기가 실제로 얼마나 쓰이는지는 쿠버네티스 비용 최적화 기업 Cast AI의 조사에서 가늠해 볼 수 있습니다. 2026 State of Kubernetes Optimization Report에 따르면 최적화를 적용하지 않은 클러스터의 평균 GPU 사용률은 5%에 그쳤습니다. 한 기업의 자체 분석이라 모든 환경에 그대로 적용할 수는 없지만 비용을 들여 확보한 가속기가 실제 연산에는 거의 쓰이지 않을 수 있다는 점은 참고할 만합니다.
문제는 이렇게 남는 자원이 쿠버네티스의 자원 정보에는 드러나지 않는다는 점입니다. 컨테이너 메모리는
memory: 4Gi처럼 필요한 용량을 지정해 관리하지만 VRAM이나 NPU 장치 메모리에는 같은 역할을 하는 표준 자원이 없습니다. 그래서 배정된 장치 안의 메모리를 어떤 프로세스가 얼마나 쓰는지는 nvidia-smi나 rbln-smi 같은 벤더 도구로 따로 확인해야 합니다.1-3. NPU 카드 수와 장치 수가 다른 이유
할당률을 제대로 보려면 분모인 전체 장치 수부터 정확히 세야 합니다. NPU는 이 수가 카드 수와 다를 수 있습니다. Red Hat이 공개한 리벨리온 ATOM 운영 가이드에 따르면 ATOM-Max 카드 한 장에는 칩 4개가 들어 있고 칩 하나가 NPU 장치 하나로 인식됩니다. 그래서 카드 2장을 장착한 서버는 쿠버네티스에 NPU 장치 8개로 등록됩니다.
즉 구매하고 관리하는 단위는 카드지만 쿠버네티스가 할당하는 단위는 장치입니다. ATOM-Max라면 쿠버네티스가 배정하는 장치 수는 카드 수의 4배입니다. 장비 현황표의 카드 수만 보고 할당률을 계산하면 실제로 배정할 수 있는 자원을 잘못 판단하게 됩니다.
2. 사용률 100%가 곧 포화는 아닌 이유
사용률이 높게 나온다고 해서 장치가 포화됐다고 단정할 수도 없습니다. 사용률이 무엇을 재는지에 따라 같은 100%도 뜻이 달라지기 때문입니다. 측정 방식이 공개된 GPU를 보면 이 차이를 분명히 알 수 있습니다. nvidia-smi 매뉴얼은 GPU 사용률을 샘플 구간 가운데 커널이 하나 이상 실행된 시간의 비율로 정의합니다. 이 정의대로라면 작은 커널 하나만 계속 실행돼도 사용률은 100%에 가깝게 나옵니다.
즉 이 값으로는 장치가 일한 시간만 알 수 있을 뿐 연산 자원을 얼마나 채워서 썼는지는 알 수 없습니다. 그래서 GPU에서는 연산 유닛을 얼마나 넓게 썼는지 보여 주는 지표를 따로 봅니다. NVIDIA의 GPU 관리 도구 DCGM이 제공하는 SM_ACTIVE가 대표적입니다. DCGM 공식 문서에 따르면 SM_ACTIVE는 각 SM(Streaming Multiprocessor)에서 작업이 활성 상태였던 시간을 전체 SM에 걸쳐 평균한 값입니다.
SM_ACTIVE는 엔진이 동작한 시간의 비율인 GR_ENGINE_ACTIVE와 함께 볼 때 쓸모가 분명해집니다. 두 값을 같이 보면 GPU가 일한 시간과 그동안 연산 유닛을 얼마나 넓게 썼는지를 나눠 확인할 수 있습니다. DCGM 문서는 SM_ACTIVE 0.8 이상을 GPU를 효과적으로 쓰기 위한 필요조건으로 제시하고 0.5 미만이면 비효율적으로 쓰이고 있을 가능성이 높다고 안내합니다. 따라서 사용률이 100%로 보이는 GPU라도 SM_ACTIVE가 낮다면 증설보다 작업을 합치는 방법을 먼저 검토할 수 있습니다.
GPU는 이렇게 측정 방식이 공개돼 있지만 NPU는 사용률의 정의부터 확인해야 합니다. 리벨리온 NPU용 명령줄 관리 도구인 rbln-smi의 문서는 nvidia-smi 매뉴얼과 달리 Util을 Utilization이라고만 적어 두었습니다. 이 값이 시간 비율인지 연산 엔진의 점유 비율인지에 따라 같은 수치도 해석이 달라지므로 알람 기준을 정하기 전에 벤더에 정의를 확인해 두는 편이 안전합니다. 대신 rbln-smi는 사용률과 함께 성능 상태(P-state)를 보여 줍니다.
P-state(Performance State)는 장치의 클럭과 전력 수준을 단계로 나눈 값입니다. rbln-smi에서는 Perf 열에 표시되며 숫자가 클수록 낮은 성능 단계를 뜻합니다.
성능 상태에 따라 같은 사용률도 다르게 읽어야 합니다. rbln-smi 문서의 상태표에 따르면 P2는 정상 클럭 단계이고 P10은 발열 때문에 클럭을 절반으로 낮춘 단계입니다. 클럭이 최소로 내려간 P12는 시스템 중단(Hang)을, 클럭이 꺼진 P14는 유휴 상태를 뜻합니다. P10에서 나온 사용률은 절반 클럭에서 측정된 값이므로 P2에서 나온 같은 수치와 같은 부하로 보기 어렵습니다. 그래서 사용률이 높은 장치라도 증설을 요청하기 전에 발열로 클럭이 낮아진 상태인지부터 확인해야 합니다.
3. 할당만 되고 쓰이지 않는 NPU를 찾는 방법
사용률과 성능 상태는 장치가 얼마나 일하는지를 보여 주지만 할당만 되고 쓰이지 않는 NPU를 찾으려면 그 장치를 어떤 프로세스가 점유하고 있는지까지 알아야 합니다. 이 정보는 rbln-smi를 옵션 없이 실행했을 때 장치 정보 아래에 나오는 컨텍스트 목록에 있습니다. rbln-smi는 NPU를 사용하는 프로세스를 컨텍스트 단위로 나눠 프로세스 이름과 PID, 컨텍스트 ID, 할당된 메모리(Memalloc), 상태(Status)를 보여 줍니다.
이 가운데 상태는 run과 idle로 표시되며 같은 장치 안에서도 컨텍스트마다 다를 수 있습니다. 그래서 장치 전체의 사용률이 높더라도 일부 컨텍스트는 연산 없이 메모리만 점유하고 있을 수 있습니다.
3-1. 사용률 98.7% 장치에서 확인되는 idle 컨텍스트
rbln-smi 공식 문서의 예시 출력에서도 이런 장치를 볼 수 있습니다.
예시 출력에서 장치 ID가 0인 NPU(Device 0)는 사용률이 98.7%라 거의 쉬지 않고 동작하는 장치로 보입니다. 하지만 이 장치에 있는 컨텍스트 3개 가운데 run 상태로 연산하는 것은 1.9GiB를 할당한 하나뿐입니다. 나머지 2개는 각각 468.0MiB와 88.0MiB의 메모리를 점유한 채 idle 상태로 남아 있습니다. 사용률 숫자만으로는 이 장치의 메모리 일부가 연산 없이 묶여 있다는 사실을 알 수 없습니다.
컨텍스트를 확인하면 할당만 되고 쓰이지 않는 NPU도 가려낼 수 있습니다. 사용률이 98.7%인 장치에서도 idle 컨텍스트가 보이는데 사용률이 낮고 idle 컨텍스트만 남아 있는 장치라면 그럴 가능성이 더 큽니다. 다만 idle 컨텍스트가 모두 회수 대상은 아닙니다. idle 컨텍스트는 요청이 잠시 끊겨 다음 요청을 기다리는 중일 수도 있고 작업이 끝난 뒤에도 정리되지 않고 남은 것일 수도 있습니다.
3-2. idle 컨텍스트를 만든 워크로드 찾기
idle 컨텍스트가 어느 쪽인지 가리려면 먼저 그 컨텍스트를 만든 워크로드를 찾아야 합니다. 쿠버네티스 문서에 따르면 kubelet의 PodResources API는 노드의 각 장치가 어느 Pod와 네임스페이스, 컨테이너에 배정됐는지 모니터링 에이전트에 제공합니다. rbln-smi의 컨텍스트 목록과 이 배정 내역을 장치 기준으로 대조하면 idle 컨텍스트를 만든 워크로드가 드러납니다. 워크로드를 알면 담당자에게 사용 여부를 확인해 회수할지 판단할 수 있습니다.
PodResources API의 배정 내역은 컨텍스트가 없는 장치를 볼 때도 필요합니다. 예시 출력의 Device 1은 사용률이 0.0%이고 성능 상태도 유휴를 뜻하는 P14이며 생성된 컨텍스트가 없어 비어 있는 장치처럼 보입니다. 하지만 rbln-smi는 장치를 사용하는 프로세스만 보여 줄 뿐 쿠버네티스의 할당 여부는 알려 주지 않습니다. 이 장치가 워크로드에 배정돼 있는지는 PodResources API로 따로 확인해야 합니다.
다만 이 API로 알 수 있는 것은 현재 배정 내역뿐입니다. 작업이 끝난 뒤 남은 점유인지 가리려면 언제 어느 컨테이너에 배정됐는지도 알아야 하는데 리벨리온 디바이스 플러그인은 이 할당 이력을 남길 수 있습니다. 공식 문서에 따르면 OpenTelemetry 추적을 켜면 할당 요청마다 어떤 장치와 장치 묶음(RSD 그룹)이 어느 컨테이너에 배정됐는지 기록됩니다. 다만 이 추적 기능은 기본값이 꺼져 있어 설치할 때 따로 켜야 합니다.
4. 증설 요청 전에 확인할 판정 기준
이처럼 할당률과 사용률, 컨텍스트 상태를 함께 보면 증설이 필요한 상황과 회수나 재배치로 해결할 수 있는 상황을 아래와 같이 나눌 수 있습니다.
전체 할당률 | 장치 사용률 | 컨텍스트 상태 | 판단 | 먼저 할 일 |
높음 | 대부분 높음 | run 위주 | 실제 포화 | 증설 검토, 우선순위 조정 |
높음 | 낮음 | idle이 오래 지속 | 유휴 점유 | 워크로드 담당자 확인 후 회수 |
높음 | 낮음 | idle과 run 반복 | 간헐적 요청 | 추론 서버 레플리카 수 조정 |
높음 | 일부 장치만 높음 | 장치마다 다름 | 부하 편중 | 워크로드 재배치 |
낮음 | 낮음 | 컨텍스트 적음 | 여유 | 증설 없이 새 워크로드 배정 |
5가지 경우 가운데 즉시 증설을 검토해야 하는 것은 실제 포화 한 가지뿐입니다. 나머지 4가지는 모두 기존 장치로 해결할 방법을 먼저 찾아볼 수 있습니다. 그래서 증설 요청이 들어오면 유휴 점유부터 확인하는 편이 비용을 줄이는 데 유리합니다.
표의 간헐적 요청은 앞에서 본 추론 서버 Pod가 많은 경우입니다. 요청이 없는 동안에도 Pod가 장치를 계속 점유하므로 레플리카 수를 실제 요청량에 맞춰 줄이면 묶여 있던 장치를 다른 워크로드에 배정할 수 있습니다.
회수하거나 재배치할 때 쓸 수 있는 수단은 GPU와 NPU가 다릅니다. NVIDIA GPU는 MIG로 한 장을 하드웨어 수준에서 여러 인스턴스로 나눌 수 있고 Time-Slicing을 쓰면 여러 워크로드가 시간을 나눠 쓰게 할 수도 있습니다. 그래서 사용률이 낮은 워크로드를 작은 단위로 옮겨 GPU 한 장을 통째로 비우는 방법을 쓸 수 있습니다.
반면 리벨리온 NPU의 RSD 그룹은 장치 여러 개를 하나로 구성해 큰 모델을 실행하는 기능이라 한 장을 쪼개는 데는 쓰이지 않습니다. 대신 리벨리온은 Rebellions Inference Platform 소개에서 DRA(Dynamic Resource Allocation) 드라이버로 멀티테넌트 추론을 지원한다고 밝혔습니다. 다만 나눠 쓸 수 있는 범위는 공개 자료로 확인되지 않습니다. 따라서 NPU에서는 필요한 장치 수를 처음부터 정확히 요청하고 유휴 점유를 빨리 찾아 회수하는 운영이 더 중요합니다.
5. 마치며
SK텔레콤의 NPU 팜처럼 여러 서비스가 NPU를 함께 쓰는 환경에서는 사용률 하나로 증설 여부를 판단하기 어렵습니다. 할당률과 사용률을 나눠 보고 성능 상태를 함께 확인해야 실제 포화와 유휴 점유를 구분할 수 있습니다.
여기에 장치의 컨텍스트 정보와 쿠버네티스의 할당 정보를 대조하면 할당됐지만 쓰이지 않는 자원을 워크로드 단위로 찾아낼 수 있습니다. 이런 자원을 먼저 회수하면 장치를 새로 들이지 않고도 배정을 기다리는 워크로드를 처리할 수 있는 경우가 있습니다.
그래서 공유 자원이 된 NPU에서는 사용률을 더 자주 확인하는 일보다 어떤 워크로드가 얼마나 점유하고 있는지를 함께 보는 일이 중요합니다.
출처
리벨리온 NPU, SKT 4대 상용 AI 서비스에 채택…'하루 40억 토큰' 처리 - ZDNet Korea (2026.09.21) RBLN Kubernetes Device Plugin - 리벨리온 Device Plugins - Kubernetes Cast AI's 2026 State of Kubernetes Optimization Report Reveals GPU Utilization at 5% - Cast AI (2026.04.21) Running AI inference on Rebellions ATOM NPU with Red Hat AI - Red Hat Developer (2026.05.27) nvidia-smi Manual - NVIDIA Feature Overview - NVIDIA DCGM Documentation Device Monitoring (rbln-smi) - 리벨리온 Time-Slicing GPUs in Kubernetes - NVIDIA GPU Operator Rebellions Inference Platform - 리벨리온
함께 보면 좋은 아티클
![[NPU 운영 가이드①] NPU 모니터링, 기존 도구로 어려운 이유 | 엑셈](https://www.notion.so/image/https%3A%2F%2Fex-em.com%2Fapple-icon.png%3Fd5f9e2f6269b07ff?table=block&id=5a6aa5ea-e9c8-402f-af8c-ad80319d783b&cache=v2&width=1200){kind=icon}
![[NPU 운영 가이드①] NPU 모니터링, 기존 도구로 어려운 이유 | 엑셈](https://www.notion.so/image/https%3A%2F%2Fstorage.ex-em.com%2Fv1%2Fblog%2Fthumbnail%2F74%2F2026%2F09%2F10%2F09-43-03-663%2FNPU%2520Ops%2520Guide1_1789000987311_c380.jpg?table=block&id=5a6aa5ea-e9c8-402f-af8c-ad80319d783b&cache=v2&width=1200)
