요약
LLM 서빙 시스템은 요청 처리를 두 단계로 나눈다. Prefill은 입력 토큰 전체를 한 번에 처리해 KV 캐시를 채우는 연산 집약 단계이고, Decode는 한 번에 토큰 하나씩 생성하는 메모리 대역폭 집약 단계다. 두 단계를 같은 GPU에서 섞으면 간섭이 생기고, 분리하면 GPU 활용률이 떨어진다. 이 트레이드오프를 풀기 위해 ASPLOS '26에서 발표된 MuxWise는 단일 GPU 안에서 SM(Streaming Multiprocessor)을 분할해 Prefill과 Decode를 물리적으로 격리하면서도 동시에 실행한다. 결과는 베이스라인 대비 평균 2.20배, 최대 3.06배 처리량 향상이다.
배경: Disaggregated Serving의 한계
Prefill-Decode 분리의 이유
초기 LLM 서빙은 Prefill과 Decode를 같은 GPU에서 순차 실행했다. 이 방식에서 Decode 작업 도중 긴 Prefill 요청이 끼어들면 TTFT(Time-To-First-Token)가 급격히 나빠진다. 반대로 Prefill을 먼저 끝내려 하면 Decode 배치 크기가 작아져 GPU 활용률이 떨어진다.
이 문제의 해결책으로 Disaggregated Serving이 등장했다. Prefill 전용 인스턴스(P 노드)와 Decode 전용 인스턴스(D 노드)를 물리적으로 분리하고, Prefill이 끝나면 KV 캐시를 네트워크로 전송해 Decode 노드로 넘긴다.
분리해도 남는 문제
| 문제 | 내용 |
|---|---|
| 버블(Bubble) | P 노드와 D 노드 간 속도 불일치 → 한쪽이 대기하는 유휴 시간 발생 |
| KV 전송 오버헤드 | 네트워크로 KV 캐시를 옮기는 지연이 TTFT에 가산 |
| 노드 수 배증 | GPU 자원을 P/D 각각 확보해야 해 총 비용 상승 |
| 불균형 부하 | 요청 패턴이 바뀌면 P/D 비율 조정이 어려움 |
핵심 병목은 버블이다. Prefill이 끝나도 Decode 노드가 KV를 받기 전까지 P 노드는 놀고, Decode가 느리면 P 노드 결과가 쌓인다.
MuxWise의 핵심 아이디어
MuxWise의 통찰은 단순하다. "P 노드와 D 노드를 네트워크로 연결할 필요 없이, GPU 하나의 SM을 분할해 Prefill 파티션과 Decode 파티션을 동시에 돌리면 된다."
NVIDIA GPU는 수천 개의 SM으로 구성된다. 일반 CUDA 커널은 전체 SM을 독점한다. MuxWise는 CUDA의 스트림·커널 설정 API를 활용해 SM을 두 파티션으로 나누고 각각에 Prefill 커널과 Decode 커널을 동시 배치한다.
세 가지 핵심 구성 요소
1. Bubble-less Multiplex Engine
기존 Disaggregated Serving에서 버블이 생기는 이유는 P 노드와 D 노드가 순차적으로 커뮤니케이션하기 때문이다. MuxWise의 멀티플렉스 엔진은 같은 GPU 안에서 두 파티션이 완전히 독립적으로 실행되므로 P 파티션이 끝날 때까지 D 파티션이 대기할 이유가 없다.
핵심 메커니즘은 CUDA Persistent Kernel과 SM 마스크다. Persistent Kernel은 GPU에 상주하면서 워크를 계속 받아 처리한다. SM 마스크를 커널 실행 설정에 지정하면 지정된 SM에서만 커널이 실행된다. 두 기술을 조합해 Prefill 커널은 SM 0~N에, Decode 커널은 SM N+1~끝에 고정된다.
이로 인해:
- P 완료 후 D 파티션 대기 → 제거
- KV 네트워크 전송 지연 → 제거 (공유 HBM)
- 두 커널이 하드웨어 타임라인에서 겹쳐 실행
2. Contention-tolerant Estimator
SM을 절반씩 나누면 단순하지만, 실제로는 요청 크기·배치 크기에 따라 최적 SM 비율이 달라진다. Prefill 요청이 긴 경우 SM을 더 많이 줘야 하고, Decode 배치가 크면 메모리 대역폭이 병목이므로 SM 비율보다 HBM 압력이 중요하다.
Estimator는 두 파티션이 서로의 자원을 실시간으로 경합(Contention)할 때 성능 저하를 예측한다. HBM 대역폭 경합 모델과 L2 캐시 경합 모델을 조합해 파티션 비율별 예상 처리량을 추산한다. 측정 기반이 아닌 모델 기반이므로 새로운 요청이 들어오는 즉시 예측 가능하다.
3. SLO-aware Dispatcher
Estimator가 예측한 성능 수치를 바탕으로 Dispatcher는 각 요청을 어디에 보낼지 결정한다. 목표는 두 가지다.
- TTFT SLO 준수: Prefill 요청이 너무 오래 대기하면 TTFT가 SLO를 넘는다. Dispatcher는 Prefill 파티션의 큐 깊이와 예상 실행 시간을 추적해 SLO 위반 직전에 요청을 우선 처리한다.
- TBT(Time-Between-Tokens) 안정화: Decode 파티션이 너무 많은 요청을 받으면 TBT가 늘어난다. Dispatcher는 Decode 배치 크기를 모니터링해 TBT SLO가 위협받으면 신규 Decode 요청 수용을 제한한다.
두 SLO 사이의 트레이드오프는 설정 파라미터(ttft_weight, tbt_weight)로 조절한다.
왜 CUDA MPS/MIG 대신 SM 파티셔닝인가
NVIDIA는 이미 다중 프로세스를 GPU에서 공유 실행하는 기술을 제공한다.
| 기술 | 격리 단위 | 한계 |
|---|---|---|
| CUDA MPS | 프로세스 수준 | MPS 서버 통해 시리얼화 → 커널이 동시 실행 안 됨 |
| MIG | GPU 파티션(물리) | 파티션 크기가 고정 (1/7, 1/4 등) → 동적 조정 불가 |
| MuxWise SM 파티셔닝 | SM 수준 (소프트웨어) | 동적 비율 조정, 커널 진짜 동시 실행, 단일 프로세스 |
MuxWise는 단일 프로세스 안에서 CUDA 스트림과 커널 설정만으로 SM을 분할하기 때문에 MPS/MIG의 프로세스 격리 오버헤드나 파티션 고정 문제가 없다.
성능 결과
논문 실험 환경: A100 80GB, vLLM 기반 베이스라인, Llama-2-13B / Llama-2-70B 모델.
처리량 개선
| 설정 | 베이스라인 대비 향상 |
|---|---|
| Sharegpt 분포, 13B | 2.20× 평균 |
| 최대 관측 | 3.06× |
| TTFT SLO P99 준수 | 유지 |
| TBT SLO P99 준수 | 유지 |
버블 제거 효과
Disaggregated Serving 베이스라인에서 GPU 유휴 시간(버블)이 전체 시간의 15~30%를 차지했다. MuxWise는 P/D 파티션이 물리적으로 공존하므로 이 유휴 시간이 실질적으로 0에 가깝게 줄었다.
SM 비율 민감도
Estimator 없이 고정 50:50 비율로 실행하면 처리량이 최적 대비 최대 40% 하락한다. Estimator가 워크로드에 맞게 비율을 조정해야 이득이 충분히 실현된다.
운영 시 고려사항
적용이 유리한 상황
- 단일 고가 GPU를 최대한 활용해야 하는 온프레미스 환경
- 긴 Prefill과 짧은 Decode가 혼재하는 채팅·코딩 어시스턴트 워크로드
- 네트워크 KV 전송 지연이 크거나 노드 간 InfiniBand 대역폭이 부족한 환경
주의사항
- 모델이 단일 GPU에 올라갈 수 있어야 한다. 70B 모델을 단일 A100에 FP16으로 올리면 140GB가 필요해 불가능하다. 대형 모델은 여전히 다중 GPU가 필요하다.
- SM 파티셔닝은 비율 조정이 실시간으로 이뤄지더라도 커널 재컴파일 없이 가능한가? 논문에서는 Persistent Kernel 내부 스케줄링으로 처리한다고 명시한다.
- 이기종 GPU에서는 SM 수와 HBM 대역폭이 달라 Estimator 모델을 재캘리브레이션해야 한다.
다른 접근법과 비교
| 방식 | 핵심 아이디어 | MuxWise와 차이 |
|---|---|---|
| Sarathi-Serve | Chunked Prefill (같은 배치에 P/D 혼합) | 여전히 순차 실행 |
| DistServe | 물리 노드 분리 P/D | KV 네트워크 전송 |
| Liger | 파이프라인 병렬화로 P/D 오버랩 | 노드 수준, 인트라-GPU 아님 |
| MuxWise | 인트라-GPU SM 파티셔닝 | 단일 GPU, 진짜 동시 실행 |
요점 정리
- LLM Disaggregated Serving의 핵심 비효율은 P/D 노드 간 버블과 KV 네트워크 전송이다.
- MuxWise는 이 문제를 단일 GPU SM 파티셔닝으로 해결한다. Prefill과 Decode가 물리적으로 분리된 SM에서 동시에 실행된다.
- Bubble-less 멀티플렉스 엔진 + Contention-tolerant Estimator + SLO-aware Dispatcher의 세 구성 요소가 처리량 최적화와 SLO 준수를 동시에 달성한다.
- 베이스라인 대비 평균 2.20배, 최대 3.06배 처리량 향상이 ASPLOS '26 실험으로 검증됐다.
- 단일 GPU에 모델이 올라가는 규모라면 Disaggregated Serving의 자원 비용 없이 유사한 처리량 이득을 얻을 수 있다.
References
- MuxWise paper (arXiv:2504.14489, April 2026): <https://arxiv.org/abs/2504.14489>
- ASPLOS 2026 proceedings: <https://asplos-conference.org/>
- vLLM documentation (Disaggregated Serving): <https://docs.vllm.ai/en/latest/serving/disagg_prefill.html>
- Sarathi-Serve (Chunked Prefill): <https://arxiv.org/abs/2308.16369>
- DistServe (P/D Disaggregation): <https://arxiv.org/abs/2401.09670>
- NVIDIA CUDA Multi-Process Service (MPS): <https://docs.nvidia.com/deploy/mps/index.html>
- NVIDIA MIG documentation: <https://docs.nvidia.com/datacenter/tesla/mig-user-guide/>