주식회사 텐 | 타임슬라이싱의 구조적 한계: GPU 활용률 30%를 공간분할로 해결하는 방법

GPU를 수억 원, 수십억 원에 도입했는데 활용률이 30~40%에 머물러 있다면, 원인은 GPU 수량이 아닙니다. 대부분의 경우 문제는 GPU를 여러 팀이나 서비스가 나눠 쓸 때 사용되는 분할 기술 자체에 있습니다.

현재 가장 널리 쓰이는 타임슬라이싱(시분할) 방식에는 구조적인 한계가 존재하며, 이것이 활용률 저하, 간섭, 빌링 부정확의 근본 원인이 됩니다.
이번 블로그에서는 타임슬라이싱의 한계를 구체적으로 짚고, 공간분할(블록분할)이 이 문제를 어떻게 해결하는지 비교 분석합니다.

GPU를 나눠 쓰는 두 가지 방식

여러 팀이나 서비스가 GPU를 공유하는 환경에서 자원을 분할하는 방식은 크게 두 가지로 나뉩니다.

타임슬라이싱 (Time-slicing)

타임슬라이싱은 GPU의 코어(Core)는 분할하지 않고, 메모리만 분할하는 방식입니다.
각 컨테이너가 전체 GPU 코어를 일정 시간 동안 번갈아 점유하면서 사용합니다.
예를 들어, 단위 시간을 1초로 가정하면 컨테이너 A가 0.25초, 컨테이너 B가 0.75초 동안 전체 코어를 사용하는 구조입니다.
문서상으로는 80:20으로 깔끔하게 나뉘는 것처럼 보이지만, 실제로는 이 경계가 정확히 지켜지지 않는 경우가 훨씬 많죠!

공간분할 (Spatial Partitioning)

공간분할(블록분할)은 ✔️GPU의 코어와 메모리를 모두 분할하는 방식 입니다.
각 컨테이너는 분할된 코어를 전용으로 할당받고, 해당 범위 안에서 제한 없이 활용합니다.
다른 컨테이너의 워크로드가 아무리 바빠져도 내 자원에는 영향이 없습니다.

---

타임슬라이싱의 실제 문제: 간섭율 8.15배

이론적인 차이보다 실측 데이터가 더 명확하게 보여줍니다.

AIPub의 내부 벤치마크 결과, 동일한 GPU에 2 개의 컨테이너 A(25% 할당)와 컨테이너 B(75% 할당)를 동시에 운영하며 벤치마크를 해 본 결과, 타임슬라이싱 방식은 공간분할 방식 대비 8.15배 높은 간섭율을 기록했습니다.

컨테이너 B의 워크로드가 증가하면, 타임슬라이싱 환경에서는 컨테이너 A의 프로세스 처리 속도가 최대 3배까지 느려지는 부분인 것이죠. 반면 공간분할 방식에서는 동일 조건에서 성능 변동이 거의 없었습니다.

좀 더 구체적으로 설명하면 이렇습니다:

타임슬라이싱에서 메모리는 컨테이너 A, B로 나누지만, 코어 부분은 시간 단위로만 번갈아 사용합니다. 여기서 문제가 생깁니다. 컨테이너 B가 평소보다 조금이라도 더 많이 GPU를 사용하기 시작하면, 그 순간 컨테이너 A에 간섭이 발생합니다. B가 A의 코어 점유 시간을 사실상 잠식하면서, A의 이터레이션 타임이 늘어나고 레이턴시가 발생합니다. 즉, A는 세팅된 값만큼의 자원을 보장받지 못하는 것입니다.
즉, 컨테이너 B를 많이 쓴다고 해서, 아무 관련 없는 컨테이너 A의 성능이 떨어지면 안 되는 건데, 타임슬라이싱 구조에서는 이것이 구조적으로 발생하게 되는 것이죠.

이 문제가 현실적으로 가장 크게 부각되는 두 가지 상황이 있습니다.

AI 서비스 운영 시 높은 간섭율로 인해 서비스의 일관적인 성능 확보가 어렵습니다.
특히 상업용 또는 내부 AI 서비스를 직접 운영하는 기업에서는 이러한 문제가 가장 먼저 드러납니다. 높은 간섭율로 인해 서비스의 일관적인 성능 확보가 어렵고, 여러 서비스를 하나의 GPU에 올리면 전반적인 성능 저하가 발생합니다. AI 인프라 매니저 입장에서는 더 현실적인 문제도 있습니다. 유저 팀별로 차기 연도 AI 인프라 예산을 편성하거나, 내부 부서 간 Chargeback을 적용해야 할 때, 실제 사용량과 체감 성능이 일치하지 않으면 현업 부서의 반발이 생길 수밖에 없습니다. "우리는 할당받은 자원을 제대로 쓰지도 못했는데 왜 같은 비용을 내야 하느냐"는 문제가 반복되면, 인프라 팀의 신뢰도 자체가 흔들리게 됩니다.
GPUaaS(네오클라우드 등) 공급 시 빌링 문제가 특히 심각합니다.
예를 들어 GPUaaS 사업자가 GPU 하나를 컨테이너별로 분할해서 서로 다른 고객사에 판매했다고 가정해보겠습니다. 컨테이너 A를 쓰는 고객사는 정상적으로 자기 비중만 사용하고 있는데, 컨테이너 B를 쓰는 고객사가 워크로드를 늘린 순간 A의 성능이 떨어집니다. 그런데 A 고객사는 동일한 비용을 지불하고 있습니다. 약속한 자원을 온전히 쓰지 못했는데도요.

기대 사용량과 실 사용량 간 차이가 이렇게 벌어지면, 분할 GPU에 대한 정확한 과금(Pay-as-you-go) 자체가 불가능</u>해집니다. 빌링의 기반이 구조적으로 흔들리는 것이죠.

공간분할 방식은 이 문제가 발생하지 않습니다. 코어와 메모리를 모두 물리적으로 분리하기 때문에, 컨테이너 B가 아무리 바빠져도 컨테이너 A의 자원에는 영향을 주지 않습니다. 빌링도 각 블록이 실제로 사용한 만큼 정확하게 산정됩니다.

AIPub의 접근: GPU 1개를 100개 블록으로

TEN의 AIPub은 GPU 1개의 코어와 메모리를 1% 단위로 분할해 최대 100개 블록으로 나눕니다.

이 구조의 핵심은 세 가지입니다.

멀티 서비스와 멀티 유저(멀티테넌시) 환경 모두에서 간섭 없이 동작합니다.
하지만 서비스 간 리소스 사용 침해를 막아 안정성을 확보합니다. 각 블록은 독립적으로 할당되기 때문에, 한 서비스의 부하가 다른 서비스에 영향을 주지 않습니다. 멀티 서비스/멀티 유저(멀티테넌시) 환경 모두에 적합합니다. 여러 유저가 GPU 인프라를 공유하는 개발 환경에서도, 개발이 완료된 멀티 서비스를 하나의 GPU에서 서빙하는 운영 환경에서도 간섭 없이 안정적으로 동작합니다.
Kubernetes 기반 스케줄링과 호환되면서, 기본 스케줄러를 넘어서는 GPU 제어를 제공합니다.
블록 단위로 분할된 GPU 자원이 Kubernetes의 기본 스케줄링 체계에 자연스럽게 통합됩니다. 다만, AIPub은 여기서 멈추지 않고, 공간분할 기반의 자원 격리와 운영자 수준의 우선순위 제어까지 지원합니다. 자세한 스케줄러 비교는 아래에서 다룹니다.
MIG도 함께 지원합니다.
NVIDIA의 MIG(Multi-Instance GPU) 기술은 하드웨어 수준에서 최대 7개까지 분할하는 방식입니다. AIPub은 이 MIG 옵션도 제공하면서, 동시에 소프트웨어 기반 100분할까지 지원합니다. 워크로드 특성에 따라 관리자가 노드별로 MIG, Full GPU, Block 분할 방식을 선택할 수 있습니다.

세계 최초, 공간분할에서 동적할당을 구현하다

타임슬라이싱에서는 쉽지만, 공간분할에서는 어려운 동적 할당

GPU를 잘게 나눠도, 실제로 사용하지 않는 시간이 발생하면 자원은 여전히 낭비됩니다. AIPub은 공간분할 기술을 기반으로 한 동적 할당(Dynamic Allocation)을 세계 최초로 구현해 이 문제를 해결합니다.

타임슬라이싱은 단순히 사용시간을 조정함으로써 쉽게 동적할당을 적용할 수 있는데 비해, 공간분할에서는 동적할당에 대한 개발 난이도가 확연히 다릅니다. (이 부분은 다음 컨텐츠에서 더 자세히 이야기 나눠보도록 하죠!)

AIPub의 동적할당 프로세스는 실시간으로 유휴 자원을 탐지해서, 현재 사용 중인 컨테이너의 점유 비율에 따라 남는 자원을 자동으로 재분배합니다. 신규 워크로드가 추가되면 필요한 만큼 자원을 반환하고 재분배하는 과정이 자동으로 이뤄집니다.

예를 들어, 컨테이너 A(20%)와 B(20%)가 GPU를 사용 중이고 60%가 유휴 상태라면, AIPub은 이 60%를 A와 B에 자동으로 분배합니다. 이후 새로운 컨테이너 C가 추가되면 필요한 만큼 자원이 자동 반환되고 재분배됩니다.

스케줄러 비교: 왜 AIPub 스케줄러가 다른가

GPU 분할 방식만큼 중요한 것이 스케줄러입니다. 아무리 잘 나눠도 작업을 적재적소에 배치하지 못하면 효율은 떨어집니다.
현재 Kubernetes 생태계에서 사용되는 주요 스케줄러를 비교하면 차이가 명확해집니다.

Kubernetes 기본 스케줄러(kube-scheduler): 순차적 Pod 단위 스케줄링을 수행합니다. GPU 인지 스케줄링이나 세밀한 GPU 자원 제어가 제한적이고, 순차 스케줄링으로 인한 교착 상태와 무한 대기 위험이 존재합니다.
Volcano: 갱 스케줄링(Gang Scheduling) 특화 스케줄러로, 하나의 작업에 속한 모든 Pod를 동시에 할당합니다. 다만 자원이 부족하면 전체가 대기 상태가 되는 All-or-Nothing 방식이라 효율성이 낮고, 운영자 수준의 수동 우선순위 재조정 기능이 없습니다.
KAI 스케줄러(NVIDIA/Run:ai 오픈소스): 타임슬라이싱 기반 GPU 공유를 지원합니다. 그러나 코어 분리 없는 시분할 방식의 경우 GPU 내 자원 간섭을 유발하여 성능과 지연 시간의 변동성이 매우 높습니다. 엄격한 SLA가 필요한 프로덕션 환경에는 권장되지 않습니다.
AIPub 스케줄러(✅TEN 자체 개발): 공간분할 기반 GPU 파티셔닝에 최적화되어 있습니다. 워크로드 간 간섭 방지를 위한 자원 격리에 특화되어 있고, 갱 스케줄링도 지원합니다. 가장 큰 차별점은 운영자에 의한 우선순위 변경 및 강제 자원 회수가 가능하다는 점입니다.
또한, 선점(preemption) 기능은 개발은 완료되어 있지만 AIPub에는 의도적으로 지원하지 않고 있는데요.
이는 서비스 운영 환경에서 예측 가능성과 안정성을 최우선으로 하는 TEN의 제품 방향성 때문입니다. 또한 6월 말에는 위에 소개한 모든 스케줄러(kube-scheduler, Volcano, KAI 등)를 AIPub 플랫폼 위에서 워크로드 성격에 따라 자유롭게 선택해서 사용할 수 있는 기능이 추가될 예정입니다.

GPU 활용률 문제의 본질

GPU 활용률이 기대치에 미치지 못하는 원인은 GPU가 부족해서가 아닙니다.

타임슬라이싱은 메모리만 나누고 코어는 시간 단위로 공유하는 구조적 한계를 가지고 있습니다. 이 방식에서는 한쪽 워크로드가 늘어나면 다른 쪽에 간섭이 발생하고, 성능 예측이 불가능해지며, 정확한 빌링도 어렵습니다. 자원을 나눠놓고도 제대로 쓸 수 없는 구조인 것이죠. 특히 서비스 운영 안정성이 비즈니스에 직결되는 산업에서 이 문제는 단순한 효율 저하를 넘어 사고로 이어질 수 있습니다.

금융 분야에서 AI 기반 이상거래 탐지 서비스가 간섭으로 인해 응답이 지연되면 실시간 차단이 실패할 수 있고,
제조 라인에서 불량 검출 AI의 추론 레이턴시가 불안정해지면 불량품이 그대로 출하될 수 있습니다.
국방이나 의료처럼 단 한 번의 지연도 허용되지 않는 환경에서는 타임슬라이싱의 간섭 문제가 곧 운영 리스크가 됩니다.

✅ 공간분할(블록분할)은 이 문제를 근본적으로 해결합니다. 코어와 메모리를 모두 물리적으로 분리하기 때문에 워크로드 간 간섭이 발생하지 않고, 블록 단위로 사용량이 정확히 추적되어 빌링과 Chargeback의 신뢰도를 확보할 수 있습니다. 여기에 세계 최초로 구현된 공간분할 기반 동적 할당까지 더해지면, 유휴 자원까지 자동으로 회수하고 재분배하는 체계가 완성됩니다.

🔎 GPU를 추가 구매하기 전에,
지금 가진 우리 팀의 GPU가 어떤 방식으로 분할되고 운영되고 있는지부터 점검해보세요.

AIPub은 GPU 활용률 극대화를 위한 공간 분할, 동적 할당, 스케줄링, 모니터링을 하나의 플랫폼에서 제공합니다. GPU 인프라를 새로 도입하는 단계라면, RA:X의 벤치마킹 기반 컨설팅을 통해 어떤 GPU를 얼마나 도입해야 하는지까지 데이터로 확인할 수 있습니다.

👉 AIPub 자세히 보기
👉RA:X 컨설팅 문의하기
📩 전문가와 직접 상담하기

🗂️ 함께 읽어보면 좋은 글