요약
DeepSeek R1·V3 같은 거대 MoE 모델을 데이터센터 없이 자체 서버에서 운영하면 왜 클라우드 SLO를 맞추기 어려울까? OSDI 2026에서 발표된 이 논문은 그 원인을 소비자 GPU 한 장의 HBM 용량 부족에서 찾는다. 전문가(expert) 가중치 전체를 DRAM에 두고 순차적으로 적재하면 12K 이상 프롬프트에서 TTFT가 30초를 넘기고 디코딩 처리량이 20 tok/s에 못 미친다.
이 연구는 스트림-로딩 프리필(SLP)을 핵심 기법으로 제안한다. GPU 연산과 DRAM→GPU 전문가 가중치 전송을 서브레이어 단위로 파이프라인화해 전송 지연을 계산 뒤에 숨기는 방식이다. 이와 함께 AMD EPYC 듀얼소켓 CPU의 AVX-512 GEMV 커널로 디코드 연산을 가속하고, 노드 내 Prefill-Decode 분리로 동시성을 확보한다.
핵심 결과:
- RTX 5090 단일 GPU에서 SLP로 1,200 tok/s 프리필, 32K 프롬프트 30초 이내 완료
- 2× RTX 5090에 분산 SLP(DSLP) + SmallEP 전문가 병렬 적용 시 1,800 tok/s, 45K 프롬프트 30초 이내
- AVX-512 FP8 GEMV로 디코드 레이턴시 4–5배 감소
- OSDI '26 | Tsinghua University + Xingyun Integrated Circuits | arXiv:2606.10493
배경: 로컬 MoE 서빙의 네 가지 격차
DeepSeek-V3·R1은 671B 전체 파라미터 중 각 토큰에 37B만 활성화하는 MoE 구조다. 모델 가중치가 약 400GB를 넘어 단일 소비자 GPU(RTX 5090, HBM 96GB)에는 올라가지 않는다. 이를 해결하는 기존 방법들이 남기는 격차는 네 가지다.
| 격차 | 증상 | 기존 접근의 한계 |
|---|---|---|
| 용량 부족 | 압축·양자화 모델로 대체 | 정확도 저하 피할 수 없음 |
| 긴 프롬프트 TTFT | 12K+ 프롬프트에서 TTFT > 30초 | KTransformers 등 순차 적재 → 대기 발생 |
| 낮은 디코드 처리량 | < 20 tok/s | CPU GEMV 가속 미흡 |
| 동시성 부족 | 단일 요청만 처리 | 프리필·디코드 혼합 시 간섭 |
클라우드 SLO는 보통 32K 프롬프트 TTFT 30초 이내, 디코드 처리량 20 tok/s 이상을 요구한다. 이 논문은 압축 없이 원본 FP8·BF16 가중치로 이 기준을 달성하는 것을 목표로 삼는다.
SLP: 스트림-로딩 프리필의 파이프라인
문제: 순차 적재의 대기 시간
MoE 프리필에서 각 트랜스포머 레이어는 Attention 연산 후 FFN(Feed-Forward Network)에서 top-K 전문가를 선택해 계산한다. GPU HBM에 모든 전문가 가중치를 올릴 수 없으므로 레이어마다 DRAM에서 해당 전문가 가중치를 GPU로 전송해야 한다.
순차 방식은 다음과 같이 동작한다.
레이어 N: [DRAM→GPU 전송] → [GPU 연산] → [GPU→DRAM 반환]
레이어 N+1: [DRAM→GPU 전송] → [GPU 연산] → ...전송과 연산이 직렬이므로 긴 프롬프트에서 전송 시간이 그대로 TTFT로 쌓인다.
SLP의 핵심: 3-스레드 파이프라인
SLP는 이 직렬 처리를 세 스레드로 분해해 병렬화한다.
Loader 스레드: DRAM에서 다음 레이어의 전문가 가중치를 읽어 Pinned Memory를 경유해 GPU HBM으로 비동기 DMA 전송한다. 서브레이어 단위(Attention, FFN gate, FFN expert별)로 나눠 전송하므로 대용량 일괄 전송 대신 세밀한 파이프라인이 형성된다.
Model 스레드 (GPU 커널): 현재 레이어의 전문가 가중치가 HBM에 도착한 것을 CUDA Event로 확인하고 즉시 연산을 시작한다. Loader가 다음 레이어를 전송하는 동안 현재 레이어 연산이 진행되므로 두 작업이 중첩된다.
Unloader 스레드: 연산이 끝난 전문가 가중치를 HBM에서 해제해 다음 Loader 사이클에 쓸 슬롯을 확보한다.
세 스레드 간 동기화는 CUDA Event와 CPU 스레딩 이벤트의 조합으로 이뤄진다. CUDA Event는 GPU→CPU 신호를, CPU 스레딩 이벤트는 Loader↔Unloader 사이 순서를 보장한다.
CPU GEMV: 디코드 처리량의 새 경로
왜 CPU로 디코드를 계산하나
MoE 모델의 디코드 단계는 한 번에 토큰 하나씩 처리하는 메모리 집약(memory-bound) 연산이다. GPU는 배치가 클 때 강력하지만 토큰 하나에 대한 벡터-행렬 곱(GEMV)은 HBM 대역폭에 묶여 연산 자원을 충분히 쓰지 못한다.
반면 AMD EPYC 듀얼소켓 서버의 CPU는 AVX-512 SIMD 연산 유닛과 수백 GB/s에 달하는 DRAM 대역폭을 갖는다. 디코드에서 전문가 가중치가 이미 DRAM에 있다면, GPU로 옮기는 비용 없이 CPU에서 바로 GEMV를 수행하는 것이 유리하다.
이 논문은 FP8 정밀도 AVX-512 GEMV 커널을 구현해 CPU 병렬 스레드로 디코드를 처리한다. 결과적으로 DRAM 대역폭을 최대한 활용하면서 GPU→DRAM 전송 왕복 비용을 제거한다.
디코드 레이턴시 개선: 기존 접근 대비 4–5배 감소.
전체 구성: SLP + CPU GEMV + PD 분리
Loader / Model / Unloader 3스레드
전문가 가중치 스트리밍 적재
RTX 5090 단일 GPU
AMD EPYC 듀얼소켓
다중 스레드 DRAM 직접 접근
기존 대비
전문가 분담
전문가 분담
2× RTX 5090
노드 내 PD 분리: 프리필 요청과 디코드 요청을 각각 다른 리소스(GPU vs CPU)에 배치하므로, 두 단계가 서로 간섭하지 않는다. 이를 통해 여러 요청을 동시에 처리하는 동시성을 달성한다.
DSLP와 SmallEP: 2-GPU 확장
2× RTX 5090 환경에서는 분산 SLP(DSLP)와 SmallEP(Small Expert Parallelism)를 결합한다.
SmallEP: 전문가 가중치를 두 GPU가 분할 보유한다. GPU 0는 짝수 레이어 전문가, GPU 1은 홀수 레이어 전문가를 담당(예시)한다. 각 GPU는 자신이 담당하는 전문가만 DRAM에서 로딩하면 되므로 로딩 대역폭이 두 배로 늘어난다.
DSLP: 각 GPU에서 독립적인 SLP 파이프라인이 돌고, 레이어 연산 결과를 NVLink로 All-reduce한다. 두 GPU가 서로 다른 전문가를 동시에 로딩·연산하므로 단일 GPU 대비 처리량이 거의 두 배 향상된다.
결과: 1,800 tok/s 프리필, 45K 프롬프트를 30초 이내 처리.
클라우드 SLO 달성 요약
| 지표 | 클라우드 SLO | 기존 로컬 방식 | 본 논문 결과 |
|---|---|---|---|
| 32K 프롬프트 TTFT | ≤ 30초 | > 60초 (KTransformers 등) | 27초 (SLP, RTX 5090) |
| 프리필 처리량 | ≥ 1,000 tok/s | ~ 200–400 tok/s | 1,200 tok/s (1-GPU) |
| 디코드 레이턴시 | 20 tok/s 이상 | ~ 5–10 tok/s | 4–5배 향상 |
| 동시 요청 처리 | 지원 필요 | 불가(단일 요청) | PD 분리로 지원 |
기존 KTransformers나 llama.cpp 기반 접근들이 달성하지 못했던 클라우드 수준 SLO를 소비자 GPU + 저가 듀얼소켓 CPU 조합으로 달성한 점이 이 논문의 핵심 기여다.
기존 접근과 비교
| 시스템 | 핵심 방식 | TTFT 성능 | 한계 |
|---|---|---|---|
| KTransformers | 레이어별 순차 offloading | 느림 (순차 대기) | 전송-연산 직렬 |
| llama.cpp | CPU+GPU 혼합 (mmap) | 보통 | CPU GEMV 최적화 미흡 |
| ExpertPlex (OSDI '26, GPU 클러스터) | 데이터센터 MoE 모듈 분산 | 높음 | 소비자 GPU 비대상 |
| 본 논문 (SLP) | DRAM 스트리밍 파이프라인 + CPU GEMV | 1,200 tok/s | RTX 5090 + 듀얼소켓 EPYC 필요 |
운영 체크리스트
□ GPU: NVIDIA RTX 5090(권장) — HBM 96GB 이상, PCIe 5.0 대역폭 확인
□ CPU: AMD EPYC 듀얼소켓 (DRAM 512GB+ 권장) — AVX-512 지원 필수
□ DRAM 용량: DeepSeek-V3/R1 FP8 가중치 ~400GB 수용 가능 여부 확인
□ NVLink: 2-GPU DSLP 구성 시 GPU 간 NVLink 연결 확인
□ 소프트웨어: CUDA 이벤트 기반 동기화 오버헤드 프로파일링 권장
□ 1-GPU SLP: 32K 프롬프트 기준 TTFT 27초 안팎 기대
□ 2-GPU DSLP: 45K 프롬프트 30초 달성, NVLink 대역폭이 핵심 병목
□ 디코드: AVX-512 FP8 GEMV 활성화 확인, CPU 코어 수에 따라 스레드 수 조정
□ 압축 없는 원본 가중치 사용 시 정확도 유지됨 — 양자화 대체 불필요요점 정리
- DeepSeek 급 MoE 모델(671B)을 소비자 GPU로 서빙할 때 클라우드 SLO(32K TTFT ≤ 30초)를 달성하는 것은 기존 순차 offloading 방식으로는 불가능했다.
- SLP는 Loader·Model·Unloader 3-스레드 파이프라인으로 전문가 가중치 전송을 GPU 연산 뒤에 숨겨 이 한계를 깬다. CUDA Event + CPU threading event 조합으로 서브레이어 단위 정밀 동기화를 실현한다.
- AVX-512 FP8 GEMV 커널로 CPU DRAM 대역폭을 최대 활용해 디코드 레이턴시를 4–5배 줄이고, 노드 내 PD 분리로 동시성을 확보한다.
- RTX 5090 단일 GPU에서 1,200 tok/s, 2-GPU DSLP+SmallEP 구성에서 1,800 tok/s를 달성해 클라우드 SLO를 실측으로 증명한다.
- 소비자 GPU + 저가 서버 CPU 조합으로 "로컬 MoE 서빙의 클라우드 동급화"를 가능하게 한 OSDI 2026 최우수 시스템 논문 중 하나다.
References
- arXiv:2606.10493 — Achieving Cloud-Grade SLOs for Local MoE Inference: <https://arxiv.org/abs/2606.10493>
- USENIX OSDI '26 발표 페이지 (Jiang Yapeng et al.): <https://www.usenix.org/conference/osdi26/presentation/jiang-yapeng>
- OSDI 2026 accepted papers overview: <https://paper.lingyunyang.com/reading-notes/conference/osdi-2026>
- ETH Zurich OSDI '26 발표 소식: <https://systems.ethz.ch/news-and-events/news/2026/03/two-papers-accepted-at-osdi26.html>
- ExpertPlex (비교 대상, OSDI '26): <https://arxiv.org/abs/2607.18002>
- KTransformers (비교 대상): <https://github.com/kvcache-ai/ktransformers>
- MoE-Prefill (관련 연구): <https://arxiv.org/abs/2605.02960>