IEEE TPDS · January 2026
Joint Optimization of Resource Allocation and Request Batching for Multi-Tenant Inference Serving on GPU
논문 분석 정리 글 입니다.
들어가며
하나의 GPU를 여러 AI 모델이 동시에 나눠 쓸 때, 두 가지 핵심 결정이 필요합니다.
- 자원 할당: 각 모델에게 GPU의 몇 %를 줄 것인가
- 요청 배치: 그 자원에서 요청을 몇 개씩 묶어 처리할 것인가
기존 연구들은 이 두 문제를 분리해서 풀었습니다. 이 논문은 두 문제가 본질적으로 결합된 하나의 최적화 문제임을 명확히 제시하고, 이를 강화학습으로 동시에 푸는 시스템 DRS(Deep Reinforcement Scheduler) 를 제안합니다.
논문연구를 통해 이 시스템을 분석하면서, 특히 제조 AI 관점의 실무 적용 가능성까지 함께 검토해봤습니다.
핵심 성능 지표 (요약)
| 지표 | 개선 |
|---|---|
| Makespan (전체 요청 처리 시간) | 2.23배 감소 |
| JCT (요청 end-to-end 지연) | 최대 24배 감소 |
| DDPG 추론 오버헤드 | 9ms (서빙 부담 거의 없음) |
1. 배경 및 연구 동기
멀티테넌트 추론 서빙이란?
딥러닝 모델은 비전, 음성, 자연어, LLM까지 매우 다양해졌습니다. 클라우드 환경이라면 GPU를 충분히 투입할 수 있지만, 엣지·온프레미스·제조 현장처럼 GPU가 제한된 환경에서는 하나의 GPU를 여러 모델이 동시에 공유해야 합니다.
논문은 이런 환경을 멀티테넌트 추론 서빙이라고 정의합니다. 여기서 '테넌트'는 GPU를 공유하는 각각의 서비스(세입자)를 의미합니다.
왜 두 문제를 같이 풀어야 하는가?
기존 연구들은 자원 할당과 배치 크기를 따로따로 풀었습니다. 그러나 아래 실험 결과를 보면 이것이 왜 잘못된 접근인지 드러납니다.
GPU 파티션별 최적 배치 크기 (NVIDIA RTX A5000 실험)
| GPU 파티션 | BERT (Text) | ResNet50 (Image) | MobileNetV2 (Light) | DeepSpeech (Voice) |
|---|---|---|---|---|
| 20% | 32 | 8 | 128 | 128 |
| 40% | 64 | 8 | 256 | 256 |
| 60% | 128 | 16 | 512 | 512 |
| 80% | 256 | 32 | 1024 | 512 |
| 100% | 256 | 32 | 2048 | 1024 |
세 가지 핵심 인사이트가 드러납니다.
- 스케일 이질성: ResNet50의 최적 배치는 8~32, MobileNet은 128~2048 — 무려 60배 차이. 단일 휴리스틱으로 모든 테넌트를 커버할 수 없습니다.
- 곡선 형태가 제각각: BERT는 포화형, DeepSpeech는 계단형, MobileNet은 지수적 증가. 선형 규칙이 성립하는 모델이 없어 데이터 기반 학습이 필수입니다.
- 파티션 ↔ 배치 커플링: 파티션이 바뀌면 같은 모델도 최적 배치 크기가 즉시 바뀜. 두 결정을 함께 풀어야 한다는 실험적 근거입니다.
2. DRS 시스템 개요
DRS는 두 컨트롤러가 맞물려 동작하는 구조입니다.
[테넌트 요청] → [CPU 큐(FCFS)] → [GPU 추론] → [결과 반환]
↑ ↓
Memory Recap 시스템 상태(State)
(배치 크기 결정) ↓
↑ DDPG Controller
새 파티션 비율 + BS (파티션 비율 결정)
↑ ___________________↗
NVIDIA MPS (공간 분할 적용)전체 워크플로우 (7단계)
| 단계 | 설명 |
|---|---|
| ❶ Models Deployment | DRS가 모델 가중치 비율로 초기 파티션 산정 |
| ❷ Requests | 테넌트가 요청 전송 → CPU 큐에 FCFS 적재 |
| ❸ Batched Requests | Memory Recap이 정한 배치 크기로 묶어 GPU 전송 |
| ❹ Results | GPU 추론 수행 후 결과 반환 |
| ❺ Inference Info (State) | 큐 길이·Latency·Throughput·JCT를 DDPG state로 전달 |
| ❻ New Partition Ratio + Latency | DDPG Action을 받아 Memory Recap이 BS 테이블 갱신 |
| ❼ Partition Ratio (Action) | 같은 비율을 NVIDIA MPS 환경변수로 적용 → ❷로 순환 |
핵심: ❻과 ❼은 같은 결정의 두 출력입니다. DDPG 한 번의 추론 결과가 소프트웨어(BS 갱신)와 하드웨어(SM 분배)로 동시에 분기됩니다. 이 사이클이 2초 주기로 반복됩니다.
사용 기술
- NVIDIA MPS (Multi-Process Service): 단일 GPU를 공간적으로 분할 공유.
ACTIVE_THREAD_PERCENTAGE환경변수로 제어. - DDPG: Deep Deterministic Policy Gradient. 연속 행동 공간을 다루는 강화학습 알고리즘.
- Memory Recap: 파티션별 최적 배치 크기를 저장·조회하는 경량 캐시 테이블.
3. 핵심 구성요소 상세
Memory Recap — 배치 크기 결정자
파티션 구간(bin)별로 최적 배치 크기를 기록해두는 캐시 테이블입니다. 학습이 필요 없고 단순 기록·조회만 합니다.
동작 원리:
1. 파티션을 유한한 bin으로 이산화
2. 새 bin 진입 시 배치 크기 = 2부터 탐색 시작
3. 1건당 지연이 개선되면 배치를 2배씩 확장
4. 악화되면 이전 최적값으로 즉시 복귀
5. 학습 불필요 · 즉시 조회 가능
DDPG Controller — 자원 할당 결정자
Actor-Critic 구조의 강화학습 에이전트로 GPU 파티션 비율을 결정합니다.
왜 DDPG인가?
| 알고리즘 | 행동 공간 | 적합 사례 |
|---|---|---|
| DQN | 이산(discrete) | Atari 게임, 메뉴 선택 |
| DDPG | 연속(continuous) | 로봇 제어, 자원 분배, GPU 파티션 |
GPU 파티션 비율은 1%~100%의 연속값이므로, DQN 같은 이산 행동 알고리즘은 부적합합니다. Actor가 파티션 비율을 직접 출력하고, Critic이 그 행동의 가치를 평가해 Actor를 학습시킵니다.
Joint Optimization Loop
파티션 변경 → 배치 재선택 → 새 처리량 → 상태 관측 → 다음 파티션DDPG가 파티션을 바꾸면 Memory Recap이 맞는 배치 크기를 적용하고, 그 결과가 다시 DDPG의 입력 상태로 들어갑니다. 이 피드백 루프가 Joint Optimization의 본질입니다.
4. 강화학습 공식화 (MDP 정의)
DRS는 GPU 자원 분배 문제를 MDP(Markov Decision Process) 로 모델링합니다.
State (상태)
각 테넌트의 4가지 지표 (Min-Max 정규화 적용):
- 큐 길이 (Queue length)
- 추론 지연 (Inference latency)
- 처리량 (Throughput)
- JCT (Job Completion Time — 요청 도착부터 결과 수신까지의 end-to-end 지연)
Action (행동)
테넌트별 GPU 파티션 비율 벡터 (연속 벡터, Σ = 100%)
예: 3개 테넌트 → {30%, 40%, 30%}
Reward (보상)
- : 공유 환경에서의 실제 처리량
- : 단독 GPU 사용 시 최대 처리량
설계 의도: 각 테넌트가 "자기 최대 성능 대비 얼마나 잘 돌고 있는지"를 공정하게 합산합니다. 단순 처리량 합이었다면 경량 모델만 유리해졌을 것입니다.
5. 실험 결과
실험 환경: NVIDIA RTX A5000 24GB · ResNet50 / ViT / MobileNet / BERT / DeepSpeech / Qwen2.5-3B (6개 모델)
JCT 비교 (초)
| 모델 | 기본 (Origin) | Heuristic | DRS |
|---|---|---|---|
| ResNet50 | 8.31 | 1.92 | 0.34 |
| BERT | 6.78 | 1.55 | 0.42 |
| Qwen2.5-3B (LLM) | 12.4 | 4.15 | 0.52 |
왜 이렇게 큰 성능 향상이 나오는가?
기존 방식은 큐가 길어지는 무거운 모델에 자원을 더 줄 줄 모릅니다. DRS는 큐 길이와 JCT를 실시간 상태(State) 로 관찰하기 때문에, 뒤처지는 테넌트에게 자원을 재배분해 전체 균형을 맞춥니다.
특히 LLM(Qwen2.5-3B)에서 24배라는 큰 개선이 나온 이유도 여기에 있습니다.
6. 제조 AI 관점 — 현장 적용 가능성
논문연구를 진행하면서 DRS의 핵심 아이디어가 제조 검사 AI 영역에 그대로 매핑된다는 점이 가장 흥미로웠습니다.
DRS 개념 → 제조 현장 매핑
| DRS 핵심 개념 | 제조 현장 적용 |
|---|---|
| Multi-tenant on single GPU | 한 검사 라인의 다종 AI 모델 통합 운영 (결함 분류·OCR·치수 측정·이상감지) |
| Joint Optimization | 제품 다양성·생산량 변동 환경에서 GPU 자원과 배치 크기 동시 최적화 |
| DDPG 온라인 적응 | 피크/오프피크·제품 전환에 따라 자원을 자동 재분배 (수동 튜닝 제거) |
| NVIDIA MPS 공간 분할 | 단일 Edge GPU 서버로 여러 라인·스테이션 동시 서빙 → CAPEX 절감 |
4대 적용 후보 영역
① PCB 검사 AI
Bare PCB · Solder · AOI · Conformal Coating 단계별 다중 결함 분류 모델 통합 추론
② 2차전지 셀 조립
노칭·스태킹·용접·실링·전해액 주입 — 머신비전 AI 라인 통합 서버
③ 반도체 Fab 검사
Defect Review · CD-SEM · Overlay · Particle — AI 추론 통합 + Tool Matching 연동
④ FDC AI 추론 서버
챔버별 이상감지 모델을 단일 GPU에 다중 호스팅 — Line Scheduler 연동
3-Phase 도입 로드맵
| Phase | 기간 | 내용 |
|---|---|---|
| Phase 1 — PoC | 1~3개월 | 1개 라인·2~3개 모델, 수동 파티션 (MPS만 적용) |
| Phase 2 — DDPG 통합 | 3~6개월 | 온라인 적응 검증, 모델별 SLO 보장 |
| Phase 3 — 다중 라인 | 6~12개월 | 라인 간 GPU 풀 공유, MES/스케줄러 연동 |
기대 효과:
- GPU 서버 수 감소 → CAPEX 30~40% 절감 (논문 STP 33~44% gain 근거)
- 생산량 변동·제품 전환 자동 대응
- 검사 SLO 보장 + 자원 효율 향상
7. 제조 현장 맞춤 MDP 재설계
논문을 그대로 제조에 가져올 수 없는 핵심 이유는 Reward 함수입니다.
State 확장
| 요소 | 논문 원본 | PCB 현장 맞춤형 |
|---|---|---|
| State | 큐 길이·지연·처리량·JCT | + 불량 감지율·라인 UPH·제품 코드(one-hot) |
| Action | 테넌트별 SM 파티션 비율 | 검사 모델별 비율 |
| Reward | Σ(hᵢ/eᵢ) — 단순 throughput | α·Thru + β·SLO − γ·Defect_Miss − δ·Lat_Viol |
⚠️ 제조에서 불량 미검출은 throughput 이득을 지워버릴 만큼 치명적입니다. Defect Miss에 가장 큰 음수 가중치가 반드시 필요합니다.
3-Phase Safe Deployment 전략
Phase A (1~2개월) → Phase B (2~4주) → Phase C (Production)
[Offline 사전학습] [Shadow Mode] [Safe Exploration]
과거 로그 기반 DDPG 제안만· Noise 제한 +
시뮬레이터에서 수동 승인 Kill Switch
DDPG 수렴 확인 UPH·Miss Rate 비교Kill Switch 조건: Miss Rate 상승 감지 즉시 → 정적 파티션(default)으로 자동 회귀
마치며
이 논문의 핵심 기여는 두 가지입니다.
- GPU 자원 할당과 요청 배치가 결합된 문제임을 명확히 제시한 것
- 이를 온라인 강화학습(DDPG + Memory Recap)으로 동시에 푼 첫 시도
단일 GPU 환경에서 Makespan 2.23배, JCT 최대 24배 개선이라는 결과는, 기존 정적 분할 방식의 한계를 데이터로 증명했다는 점에서 의미가 있습니다.
논문연구를 통해 얻은 또 하나의 인사이트는, 이 접근이 제조 AI 플랫폼에 즉시 실험 가능한 가설로 가져갈 수 있다는 것입니다. PCB 검사·FDC·Wafer 분석·LLM 리포트가 한 GPU를 공유하는 제조 AI 서버에서, DRS식 동적 스케줄링은 실시간 SLO를 지키면서 GPU 활용률을 끌어올리는 실용적 해법이 될 수 있습니다.
다만 제조 현장 적용에는 Defect Miss 페널티 중심의 Reward 재설계와 Offline→Shadow→Production의 점진적 검증이 전제조건입니다. 똑똑해지는 것보다, 위험을 통제하면서 점진적으로 개선되는 것이 제조 AI의 핵심이니까요.
참고 논문: Joint Optimization of Resource Allocation and Request Batching for Multi-Tenant Inference Serving on GPU, IEEE Transactions on Parallel and Distributed Systems, January 2026
태그: #GPU #딥러닝 #강화학습 #DDPG #멀티테넌트 #추론서빙 #논문리뷰 #제조AI #MLOps #NVIDIAMPS
