같은 GPU로 처리량 6배를 뽑아낸 SGLang 아키텍처 — PD Disaggregation과 HiCache

LLM 서빙을 처음 맡았을 때 가장 당황스러웠던 건 "GPU는 충분한데 왜 이렇게 느리지?"라는 질문이었습니다. 모니터링 대시보드를 보면 GPU 메모리는 빠듯하게 차 있고 연산은 계속 돌아가는 것 같은데, 실제 응답 속도는 기대에 한참 못 미쳤죠. 한동안 GPU를 추가로 사는 방향으로만 생각하고 있었는데, 알고 보니 문제의 원인은 아예 다른 곳에 있었습니다. Prefill(입력 전체 처리)과 Decode(토큰 한 개씩 생성)라는 성격이 완전히 다른 두 작업을 같은 GPU 풀 위에서 서로 싸우게 놓아뒀던 것입니다.

이 문제를 근본적으로 해결하는 방향으로 지금 업계 전체가 움직이고 있습니다. NVIDIA Dynamo, vLLM, Ray Serve LLM, llm-d 등 거의 모든 프로덕션 LLM 서빙 프레임워크가 PD 분리 구조를 채택하거나 통합 중이고, Hao AI Lab의 DistServe 연구에서 시작된 이 흐름은 이제 Moonshot AI의 Kimi 서비스, Together AI의 CPD(Cache-aware PD) 아키텍처로도 이어지고 있습니다. SGLang이 공식 지원을 시작한 PD Disaggregation(Prefill-Decode 분리)과 계층적 KV 캐시 시스템인 HiCache를 결합하면, 96개 H100 클러스터에서 동일 자원 대비 처리량 5배(PD 분리 단독), HiCache까지 더하면 최대 6배, TTFT(첫 번째 토큰까지의 시간)는 최대 84% 단축이라는 수치가 현실이 됩니다.

이 글은 LLM 서빙 경험이 있거나 관심 있는 백엔드·ML 엔지니어를 주요 독자로 씁니다. Tensor Parallelism 같은 기본 분산 추론 개념을 알고 있으면 더 수월하게 읽히지만, 처음 나오는 약어는 그때그때 설명하겠습니다. 이 글을 읽고 나면 왜 PD를 분리해야 하는지, HiCache가 어떻게 동작하는지, 그리고 자신의 환경에서 어떤 조합부터 시도해볼 수 있는지를 판단하는 기준이 생길 것입니다.

핵심 개념: Prefill과 Decode는 왜 함께 두면 안 되는가

둘은 하드웨어 관점에서 완전히 다른 짐승입니다

저도 한동안 Prefill과 Decode를 그냥 "앞 단계, 뒤 단계" 정도로 뭉뚱그렸습니다. 그런데 GPU 리소스 관점에서 보면 이 둘은 완전히 다른 종류의 작업입니다.

HBM (High Bandwidth Memory): GPU에 장착된 초고속 메모리입니다. 일반적으로 "GPU 메모리"라고 부르는 바로 그것으로, H100 기준 80GB의 HBM3를 탑재합니다. Decode처럼 메모리 집약적인 작업은 이 HBM의 대역폭이 핵심 병목이 됩니다.

Prefill은 입력 토큰 전체를 한꺼번에 처리하기 때문에 GPU 코어를 풀 가동하는 연산 집약 작업입니다. 반면 Decode는 이미 만들어진 KV 캐시를 반복해서 읽어가며 토큰을 한 개씩 생성하기 때문에 HBM 대역폭이 병목이 됩니다. 두 작업이 같은 GPU 풀을 공유하면 어느 쪽도 최적화하기 어렵습니다.

문제는 여기서 그치지 않습니다. 대용량 Prefill 배치가 들어오면 진행 중이던 Decode 스트림이 멈춥니다. 이것이 prefill interruption입니다. 사용자 입장에서는 응답이 뚝 끊기는 경험이죠. 거기다 데이터 병렬 처리 중 어텐션 연산 불균형(DP Attention Imbalance)까지 겹칩니다. 이 불균형은 긴 컨텍스트 요청이 특정 DP(Data Parallel) 랭크에 집중될 때 발생하는데, 나머지 랭크가 유휴 상태로 기다리는 동안 해당 랭크만 과부하가 걸려 레이턴시 스파이크가 예측 불가능하게 튑니다.

TP/EP/DP/PP: LLM에서 흔히 쓰이는 분산 병렬화 전략들의 약어입니다. TP(Tensor Parallelism)는 가중치 행렬을 여러 GPU에 나눠 각 레이어를 병렬 연산하고, EP(Expert Parallelism)는 MoE 모델의 전문가 레이어를 분산하며, DP(Data Parallelism)는 같은 모델 복제본에 요청을 나눠 처리하고, PP(Pipeline Parallelism)는 레이어를 묶어 여러 GPU에 파이프라인으로 배치합니다.

PD Disaggregation: 물리적으로 갈라놓기

해법은 이름 그대로입니다. Prefill 서버 풀과 Decode 서버 풀을 분리하고, 각각에 최적화된 하드웨어와 병렬 전략을 독립적으로 적용하는 것입니다.

[클라이언트 요청]
       │
       ▼
[로드 밸런서]
       │
  ┌────┴────┐
  ▼         ▼
[Prefill    [Decode
 서버 풀]    서버 풀]
  │              ▲
  └──KV 캐시 전송─┘
     (RDMA/RoCE)

Prefill 서버는 입력 토큰 전체를 병렬 처리해 KV 캐시를 생성하고, 이를 RDMA 기반 고속 네트워크로 Decode 서버에 넘깁니다. Decode 서버는 받은 KV 캐시를 기반으로 토큰을 하나씩 생성합니다.

중요한 점은 각 서버 풀에 서로 다른 GPU를 붙일 수 있다는 겁니다. 예를 들어 Prefill 서버에는 연산 성능이 뛰어난 H100을 배치하고, Decode 서버에는 HBM 용량이 더 큰 A100을 배치하는 이기종 혼합 운용이 가능합니다. KV 캐시 전송이 전체 레이턴시의 약 25%를 차지하기 때문에, Prefill-Decode 간 네트워크는 InfiniBand 또는 RoCE(RDMA over Converged Ethernet) 기반이어야 합니다.

RDMA (Remote Direct Memory Access): CPU를 거치지 않고 네트워크를 통해 다른 서버의 메모리에 직접 접근하는 기술입니다. 수 GB에 달하는 KV 캐시를 낮은 레이턴시로 전송하는 데 사실상 필수입니다.

SGLang에서는 2025년 4월부터 Mooncake TransferEngine을 기반으로 이 구조를 공식 지원하기 시작했습니다.

HiCache: 에빅션된 KV 캐시도 버리지 않는 3계층 구조

RadixAttention에서 HiRadixTree로

솔직히 처음 HiCache 개념을 봤을 때 "이게 그냥 캐시 계층 아닌가?" 싶었는데, 제대로 이해하려면 먼저 SGLang의 RadixAttention을 알아야 합니다.

RadixAttention은 SGLang이 개발한 접두사(prefix) 공유 KV 캐시 기법입니다. 동일한 시스템 프롬프트나 컨텍스트를 공유하는 요청들이 KV 캐시를 재사용할 수 있도록 Radix 트리 구조로 관리합니다. 예를 들어 100개의 요청이 모두 같은 긴 시스템 프롬프트를 가지고 있다면, 그 프롬프트의 KV 캐시를 한 번만 계산하고 트리에서 재사용하는 방식입니다.

그런데 RadixAttention은 GPU HBM 위에서만 동작합니다. 메모리가 부족하면 캐시를 버리고, 같은 컨텍스트가 다시 들어오면 처음부터 재연산합니다. HiCache는 이 한계를 CPU의 3레벨 캐시 설계에서 착안해 다중 계층으로 확장한 것입니다. HiRadixTree가 페이지 테이블 역할을 맡아 각 KV 캐시 페이지가 현재 어느 계층에 있는지 추적하고, Cache Controller가 백그라운드에서 계층 간 데이터 이동을 자동으로 조율합니다.

3계층 구조와 GPU-assisted I/O

L1: GPU HBM        — 가장 빠름, 용량 제한 (수십 GB)
     ↕ cudaMemcpyAsync
L2: CPU DRAM       — L1의 수배 용량 (수백 GB)
     ↕ GPU-assisted I/O 커널
L3: 분산 스토리지   — 거의 무한 (Mooncake, Tair, 3FS...)

L2↔L1 구간은 표준 cudaMemcpyAsync를 사용하지만, L3↔L2 구간에는 GPU-assisted I/O 커널이 개입합니다. 일반적인 방식은 CPU가 스토리지에서 데이터를 읽어 GPU로 복사하는 과정을 조율하는데, GPU-assisted I/O는 CPU가 개입하지 않고 GPU의 DMA(Direct Memory Access) 엔진이 직접 스토리지에서 읽어옵니다. 이 차이 덕분에 L3 접근 처리량이 최대 3배까지 향상됩니다.

L1에서 에빅션되는 캐시도 버리는 것이 아니라 L2나 L3에 보존되어, 같은 컨텍스트가 다시 들어오면 비용이 큰 재연산 없이 불러올 수 있습니다.

Mooncake Store: Moonshot AI가 개발한 KVCache 중심 분산 스토리지 시스템입니다. RDMA와 zero-copy 기술로 고대역폭 저레이턴시 전송을 지원하며, FAST 2025 Best Paper를 수상했습니다. SGLang HiCache의 L3 백엔드로 가장 많이 사용됩니다.

두 기술이 만나면

PD Disaggregation이 Prefill 서버의 GPU 컴퓨팅 부하를 격리한다면, HiCache는 그 Prefill 서버에서 연산된 KV 캐시를 계층에 보존해 반복 요청에서 재연산을 방지합니다. 멀티턴 대화나 에이전틱 워크로드처럼 같은 긴 컨텍스트가 반복되는 시나리오에서 이 조합은 특히 강력하고, 이 두 기술을 결합한 벤치마크에서 처리량 최대 6배, TTFT 최대 84% 감소라는 수치가 나옵니다.

장단점 분석

코드 예시를 보기 전에 자신의 환경에 적합한지 먼저 판단해볼 수 있도록 이 섹션을 앞에 배치했습니다.

장점

TPOT (Time Per Output Token): 토큰 하나를 생성하는 데 걸리는 시간입니다. TTFT(첫 토큰까지의 시간)와 함께 LLM 서빙 품질을 측정하는 핵심 지표로, Decode 단계의 안정성이 직접 영향을 줍니다.

단점 및 주의사항

프로덕션 적용 가능 여부를 조합별로 정리하면 아래와 같습니다.

실무에서 가장 흔한 실수

1. 일반 이더넷으로 KV 캐시 전송을 시도하는 것

저도 처음에 "일단 10GbE로 테스트해보자"며 시작했다가 레이턴시가 두 배 가까이 뛰는 걸 보고 나서야 RDMA의 필요성을 체감했습니다. 수 GB에 달하는 KV 캐시를 일반 이더넷으로 전송하면 PD 분리의 이점이 오버헤드에 그대로 상쇄됩니다. Prefill-Decode 간 네트워크에는 InfiniBand 또는 RoCE를 갖추지 않으면 도입 자체를 다시 생각해볼 필요가 있습니다.

2. Prefill:Decode 비율을 1:1로 고정하는 것

LMSYS의 DeepSeek-R1 배포에서 쓴 Prefill:Decode = 1:3 비율이 자주 인용되다 보니, 이것을 범용 비율로 오해하는 경우가 있습니다. 이 비율은 DeepSeek-R1의 긴 추론 출력, 즉 Decode 부하가 극단적으로 큰 특성에 최적화된 것입니다. 컨텍스트가 짧고 배치가 크면 Prefill 부하가 높고, 반대로 스트리밍 요청이 많으면 Decode 부하가 높습니다. 실제 트래픽 패턴을 먼저 프로파일링하고 비율을 결정하는 것이 좋습니다.

3. HiCache L3를 켰는데 왜 오히려 느려졌지 하는 상황

HiCache는 시스템 프롬프트나 RAG 문서처럼 반복되는 긴 공통 prefix가 있는 워크로드에서 진가를 발휘합니다. 요청마다 완전히 다른 컨텍스트가 들어오는 워크로드라면 L3 접근 비용만 추가될 뿐입니다. HiCache를 적용하기 전에 현재 워크로드의 캐시 히트율을 먼저 측정해두면, L3까지 투자할 필요가 있는지 바로 판단이 됩니다.

실전 적용

예시 1: PD Disaggregation 기본 설정

가장 단순한 형태부터 시작해볼 수 있습니다. 이 예시는 Mooncake 클러스터가 사전에 설치 및 설정돼 있다고 가정합니다. Mooncake 없이 시작하고 싶다면 --disaggregation-transfer-backend nixl로 NVIDIA NIXL을 사용하거나, 단일 머신 내 다른 GPU 간 전송으로 개념을 먼저 확인해볼 수 있습니다.

# Prefill 서버 실행 (GPU 0 사용)
python -m sglang.launch_server \
  --model-path meta-llama/Llama-3.1-70B-Instruct \
  --disaggregation-mode prefill \
  --disaggregation-transfer-backend mooncake \
  --host 0.0.0.0 \
  --port 30000
 
# Decode 서버 실행 (GPU 1,2,3 사용)
# prefill 모드 서버는 Decode 서버 없이 단독으로 요청을 완결할 수 없습니다.
# KV 캐시를 받아줄 Decode 서버가 반드시 함께 있어야 합니다.
python -m sglang.launch_server \
  --model-path meta-llama/Llama-3.1-70B-Instruct \
  --disaggregation-mode decode \
  --disaggregation-transfer-backend mooncake \
  --host 0.0.0.0 \
  --port 30001
 
# 로드 밸런서 실행 — Prefill/Decode 서버를 묶어주는 프록시
python -m sglang.launch_router \
  --prefill-server http://prefill-host:30000 \
  --decode-server http://decode-host:30001 \
  --port 8080

예시 2: HiCache L2/L3 계층 활성화

HiCache는 기본값으로 L1(GPU HBM)만 사용합니다. CPU 메모리와 외부 스토리지를 함께 쓰려면 다음 설정을 추가하면 됩니다.

# CLI로 L2 (CPU DRAM) + L3 (Mooncake) 활성화
python -m sglang.launch_server \
  --model-path meta-llama/Llama-3.1-70B-Instruct \
  --enable-hierarchical-cache \
  --cpu-offload-gb 64 \
  --kv-cache-store-backend mooncake \
  --kv-cache-store-url mooncake://mooncake-cluster:8080

# Python API 방식 (sglang_server_config.py)
# 주의: ServerArgs의 파라미터명은 SGLang 버전에 따라 달라질 수 있습니다.
# CLI --help 출력이나 설치된 버전의 공식 문서와 일치 여부를 반드시 확인하세요.
from sglang import ServerArgs
 
args = ServerArgs(
    model_path="meta-llama/Llama-3.1-70B-Instruct",
    enable_hierarchical_cache=True,
    cpu_offload_gb=64,
    kv_cache_store_backend="mooncake",
    kv_cache_store_url="mooncake://your-mooncake-cluster:8080",
)

예시 3: DeepSeek-R1 규모의 멀티노드 배포 참고 구성

아래는 LMSYS 팀이 12노드(96× H100)에 배포한 구성의 핵심 비율을 개념적으로 표현한 것입니다. 실행 가능한 설정 파일이 아니라 구성 비율 참고용 의사 코드입니다.

# 개념적 참고 구성 (실행 불가 — 실제 배포는 각 컴포넌트의 공식 문서 참고)
prefill_nodes:
  count: 3          # 전체의 25%, TP=8 (Tensor Parallelism)
  gpus_per_node: 8
  role: compute-bound 작업 담당
 
decode_nodes:
  count: 9          # 전체의 75%, EP+DP (Expert Parallelism + Data Parallelism)
  gpus_per_node: 8
  role: memory-bound 작업 담당
 
network:
  backend: InfiniBand  # RDMA 필수
  kv_transfer_latency_budget: 전체 레이턴시의 25% 이하
 
결과:
  input_tps: 52300    # 입력 토큰/초
  output_tps: 22300   # 출력 토큰/초/노드
  cost: "$0.20 / 1M 출력 토큰"

Prefill:Decode = 1:3 비율은 DeepSeek-R1의 긴 추론 출력 특성에 맞춰 선택된 것입니다. 실제로는 워크로드 특성(컨텍스트 길이, 배치 크기, 요청 패턴)에 따라 달라지기 때문에, 이 수치를 출발점으로 삼고 프로파일링 결과에 맞게 조정하는 것이 좋습니다.

예시 4: Alibaba Cloud Tair를 L3 백엔드로 연동 (에이전틱 워크로드)

멀티턴 대화나 에이전트 워크로드처럼 같은 긴 시스템 프롬프트가 반복되는 경우, Redis 호환 스토어를 L3로 사용하는 방식도 있습니다. 이 예시의 Prefill 서버 역시 별도의 Decode 서버와 로드 밸런서가 함께 구성돼 있어야 완전히 동작합니다.

# Tair를 L3 백엔드로 사용하는 Prefill 서버 설정
python -m sglang.launch_server \
  --model-path Qwen/Qwen2.5-72B-Instruct \
  --enable-hierarchical-cache \
  --cpu-offload-gb 128 \
  --kv-cache-store-backend tair \
  --kv-cache-store-url redis://tair-endpoint:6379 \
  --disaggregation-mode prefill

이 구성에서 동일 클러스터 내 여러 SGLang 인스턴스가 Tair의 KV 캐시를 공유하게 됩니다. 에이전트가 동일한 긴 컨텍스트(툴 설명, 히스토리 등)를 반복해서 처리할 때 TTFT가 크게 줄어드는 효과를 볼 수 있습니다.

마치며

PD Disaggregation과 HiCache의 결합은 "GPU를 더 사는 것"이 아니라 "있는 GPU를 제대로 쓰는 것"에 대한 이야기입니다. 동일 인프라 위에서 처리량 최대 6배, TTFT 84% 단축이라는 수치가 2025~2026년 사이에 현실이 됐고, 직접 실험해보면서 가장 큰 인사이트가 "비율과 캐시 히트율 측정"에서 나온다는 걸 느꼈습니다. 아키텍처를 먼저 이해하고 실제 워크로드를 측정해본 뒤 도입 여부를 결정하는 것이 가장 빠른 길입니다.

지금 바로 시작해볼 수 있는 3단계를 소개합니다.

1. 로컬 환경에서 단일 머신 PD Disaggregation 실험: Python 3.10+ 환경에서 pip install "sglang[all]" 후, 동일 머신의 다른 GPU에 Prefill 서버와 Decode 서버를 각각 다른 포트로 띄워보시면 좋습니다. InfiniBand 없이도 NVLink 또는 PCIe 대역폭으로 개념 검증이 가능합니다. SGLang 공식 PD Disaggregation 문서에 단계별 예시가 잘 정리돼 있습니다.

2. HiCache L2(CPU 오프로드)부터 적용: L3 분산 스토리지 없이 --enable-hierarchical-cache --cpu-offload-gb 64 옵션만으로도 GPU HBM에서 에빅션된 KV 캐시를 CPU 메모리에 보존할 수 있습니다. 멀티턴 대화 워크로드가 있다면 TTFT 변화를 바로 측정해 볼 수 있습니다.

3. 실제 워크로드 프로파일링 후 비율 결정: SGLang에 내장된 공식 벤치마킹 도구인 sglang.bench_serving이나 커스텀 스크립트로 현재 트래픽의 평균 입력 토큰 수, 출력 토큰 수, 캐시 히트율을 먼저 측정해보시면 좋습니다. 이 수치가 Prefill:Decode 비율 결정과 HiCache 계층 투자 우선순위를 정하는 가장 확실한 근거가 됩니다.

참고 자료

• SGLang 공식 PD Disaggregation 문서 | sglang.ai
• DeepSeek Deployment with PD Disaggregation on 96 H100 GPUs | LMSYS
• SGLang HiCache 공식 발표 | LMSYS
• EPD Disaggregation for Vision-Language Models | LMSYS
• Pipeline Parallelism in SGLang - Million-Token Contexts | LMSYS
• SGLang HiCache System Design 문서 | sglang.io
• Mooncake x SGLang HiCache System Design | kvcache-ai
• Mooncake HiCache 통합 완성 가이드 | kvcache-ai
• NVIDIA NIXL Disaggregated Inference 가이드 | spheron.network
• SGLang으로 MI300X에서 Prefill-Decode Disaggregation | AMD ROCm
• NVIDIA Dynamo SGLang Disaggregation 문서 | nvidia.com
• Disaggregated Inference 18개월 회고 | Hao AI Lab
• Cache-aware Prefill-Decode Disaggregation (CPD) | Together AI
• Mooncake 논문 (FAST 2025 Best Paper) | arXiv
• Alibaba Cloud Tair + SGLang HiCache 사례 | alibabacloud.com