DP, DPA와 SGLang DP 라우터

DP, DPA와 SGLang DP 라우터

이 문서는 데이터 병렬(Data Parallelism, DP), DP Attention(DPA), 그리고 프로덕션급 DP 배포를 위한 SGLang Model Gateway(SMG) 의 차이를 정리해요. 각각을 올바르게 활성화하는 방법까지 살펴볼게요.

데이터 병렬 (DP)

데이터 병렬(DP) 은 가장 흔한 병렬화 전략으로, 모델 전체를 여러 GPU 세트에 복제하고 서로 다른 요청 배치를 병렬로 처리해요. 각 GPU 세트는 독립적인 요청을 처리하죠. 뒤에서 소개할 SGLang Model Gateway의 적절한 라우팅 알고리즘을 쓰면, 서빙 시스템의 throughput을 거의 선형적으로 늘릴 수 있어요.

핵심 특징

• 각 복제본(replica)이 모델 전체 사본을 가짐
• 요청이 복제본들에 분산됨
• 단일 요청 추론 중 복제본 간 통신이 없음 (단순 DP 기준)

DP Attention (DPA)

DP Attention(DPA) 은 고급 병렬화 전략이에요. DPA가 가장 큰 이점을 주는 모델은 Multi-Head Latent Attention(MLA) 모델(DeepSeek, MiniMax, Kimi-K2 등)이지만, Qwen 같은 표준 attention 모델도 지원해요.

MLA 모델에서 텐서 병렬의 문제

추론에서 가장 흔한 병렬화 전략은 텐서 병렬(TP) 이에요. 하지만 TP가 모든 모델에 가장 효율적인 건 아니에요. 예를 들어 DeepSeek 모델은 MLA를 쓰고 KV 헤드가 하나뿐이에요. 8개 GPU에서 텐서 병렬을 쓰면 다음과 같은 문제가 생겨요:

• 모든 GPU에 KV 캐시 중복
• 배치 크기를 제한하는 불필요한 메모리 사용
• 메모리 제약으로 인한 throughput 감소

DPA는 어떻게 작동하나

DPA는 attention 구성요소에만 데이터 병렬을 적용해서 이런 한계를 해결해요.

각 DP 복제본:

• 서로 다른 배치를 독립적으로 처리 (프리필, 디코드, 또는 유휴 같은 서로 다른 forward 모드 가능)
• 자체 KV 캐시를 유지 (중복 없음)
• 메모리 절감으로 상당히 더 큰 배치 크기 가능

DPA + EP의 통신 패턴:

• All2All (Dispatch): 게이팅 결정에 따라 토큰을 expert 하위 그룹으로 라우팅
• All2All (Combine): 계산된 결과를 expert에서 원래 토큰 위치로 수집

DPA의 핵심 이점

1. KV 캐시 메모리 대폭 감소: 각 DP 복제본은 자기 배치의 KV 캐시만 저장
2. 더 큰 배치 크기: 메모리 절감으로 더 큰 배치 가능
3. 디코딩 throughput 향상: MLA 기반 모델에서 상당한 throughput 이득
4. 독립적인 forward 모드: 각 DP 복제본은 서로 다른 forward 모드(프리필, 디코드, 유휴)일 수 있고, attention 연산 중 자기 배치를 독립적으로 처리

MoE를 위한 DPA + Expert Parallelism

DeepSeek 같은 MoE 모델에서 DPA는 최적 throughput을 위해 종종 Expert Parallelism(EP)과 함께 쓰여요. 하지만 DPA는 EP를 요구하지 않아요: expert 샤딩이 필요 없는 배포라면 EP 없이 DPA만 켤 수 있어요.

• 256개 이상의 expert 가중치를 GPU들에 분산 (단일 GPU에 못 들어감)
• DeepEP로 효율적인 all-to-all 토큰 라우팅
• 대규모 클러스터로 확장 (바닐라 TP 대비 최대 5배 throughput 향상)

DeepSeek 권장 설정

python -m sglang.launch_server \
    --model-path deepseek-ai/DeepSeek-V3 \
    --tp 8 \
    --dp-size 8 \
    --ep 8 \
    --enable-dp-attention \
    --moe-a2a-backend deepep \
    --moe-runner-backend deep_gemm

참고: --enable-dp-attention을 쓸 때는 --dp-size를 반드시 명시해야 해요. dp_size가 1(기본값)이면 DPA가 비활성화돼요.

자세한 EP 설정(DeepEP, Two-Batch Overlap, EPLB)은 Expert Parallelism을 참고하세요.

대상 모델

DPA는 다음 모델 아키텍처를 지원해요:

• MLA (Multi-Head Latent Attention) 모델 — DPA가 가장 큰 이점을 주는 곳:

  • DeepSeek 계열 (DeepSeek-V2, DeepSeek-V3, DeepSeek-R1)
  • MiniMax 모델
  • Kimi-K2
  • MLA 아키텍처를 쓰는 다른 모델

• 표준 attention 모델 — 역시 지원:

  • Qwen 모델 (PR #6121 참조)

Llama처럼 표준 GQA를 쓰는 모델은 표준 DP 또는 TP를 보통 권장해요.

DPA를 켜려면 서버 시작 커맨드에 --enable-dp-attention을 추가하면 돼요.

활성화 로직

DPA는 서버 인자(CLI 또는 설정)로 명시적으로 활성화돼요. --dp-size와 --enable-dp-attention 둘 다 설정해야 해요:

python -m sglang.launch_server \
    --model-path deepseek-ai/DeepSeek-V3 \
    --tp 8 \
    --dp-size 8 \
    --enable-dp-attention

중요: DPA가 작동하려면 --dp-size가 1보다 커야 해요. dp_size == 1(기본값)이면 --enable-dp-attention이 자동으로 비활성화돼요. tp_size % dp_size == 0 제약도 충족해야 해요.

all-to-all을 쓰는 TP LMHead

dp-lm-head는 전체 가중치를 유지하고 로컬 배치를 계산해서, 랭크당 배치 크기가 작을 때 gemm이 비효율적이에요. 기존 tp-lm-head는 gemm 효율성을 높이지만 전체 어휘에 대한 무거운 allgather 통신을 유발해요.

따라서 랭크당 배치 크기가 작을 때 gemm 효율성을 유지하면서 무거운 allgather를 없애려면 all-to-all을 적용할 수 있어요. 각 랭크는 샤딩된 어휘의 로컬 행만 보내고 받으므로 더 가벼워요.

이 최적화는 기본적으로 decode 노드와 순수 DPA에서 활성화돼요. --no-enable-tp-lm-head-all-to-all로 옵트아웃하거나 --enable-tp-lm-head-all-to-all로 강제 활성화할 수 있어요.

python -m sglang.launch_server \
    --model-path MODEL_PATH \
    --disaggregation-mode decode \
    --tp 8 \
    --dp-size 8 \
    --enable-dp-attention

Prefill/콜로케이션 워커는 allgather와 함께 TP LMHead로 폴백하고, 다른 병렬 전략도 마찬가지예요. 자세한 내용은 PR #32313에서 확인할 수 있어요.

MLA 모델의 표준 DP

MLA 모델도 당연히 DP를 지원해요. MLA 모델에 표준 DP를 켜고 싶다면, 먼저 각 MLA 모델 복제본을 독립적으로 띄워요. DPA를 켠 채로 복제본을 하나씩 띄울 수 있어요. 각 MLA 복제본을 띄운 뒤 SMG를 띄워 모든 복제본을 SMG에 연결해요. SMG의 자세한 설명은 아래에 이어져요.

현대적인 데이터 병렬: SGLang Model Gateway (SMG)

네이티브 DP 모드

SGLang의 네이티브 DP(내장 데이터 병렬)는 단일 SGLang 인스턴스 안에 여러 워커 프로세스를 만들며, DataParallelController가 dp-size 런칭 파라미터로 제어해요.

# 네이티브 DP 모드
python -m sglang.launch_server \
    --model-path meta-llama/Meta-Llama-3.1-8B-Instruct \
    --dp-size 4

제한사항:

• 내장된 인-프로세스 로드 밸런싱만 지원 (예: round_robin, total_requests, total_tokens)
• 캐시 인지 라우팅 없음
• 제한된 관측 가능성과 메트릭
• 장애 허용 또는 회로 차단기 없음
• 프로덕션 워크로드에 부적합

⚠️ 네이티브 DP는 지금 당장 사용을 강력히 비권장해요. 일부 오래된/구식 RL 프레임워크에서만 쓰여요. 어떤 유스케이스든 SGLang Model Gateway(SMG)로 데이터 병렬을 강화할 수 있어요.

SMG 기반 DP (권장)

2024년 9월부터 SGLang Model Gateway, 즉 SMG(이전 이름: SGLang DP Router)는 Rust로 구축된 프로덕션 준비 DP 라우팅 시스템으로 만들어졌어요. DP 라우팅에서 시작했지만, 이후 RL, PD 분리, 기타 시나리오 조정으로 범위를 확장했어요. 이 문서는 DP 라우팅에서의 SMG 사용만 다뤄요. 다른 용도는 SGLang Model Gateway 문서를 참고하세요.

최상의 프로덕션급 라우팅 성능을 얻고 오버헤드를 극한까지 줄이기 위해, Python이 결코 충분히 빠르지 않기 때문에 SMG를 Python이 아닌 Rust로 구축했어요.

프로덕션급 데이터 병렬에는 SGLang Model Gateway(SMG)를 강력히 권장해요. SMG는 네이티브 DP 모드보다 상당한 이점을 제공해요.

# SMG 기반 DP 모드 (권장)
python -m sglang_router.launch_server \
    --model-path meta-llama/Meta-Llama-3.1-8B-Instruct \
    --dp-size 4

⚠️ SMG와 네이티브 DP는 같은 런칭 파라미터 --dp-size를 공유해요. 하지만 네이티브 DP의 진입점은 python -m sglang.launch_server이고, SMG의 진입점은 python -m sglang_router.launch_server예요.

SMG 기반 DP의 장점:

기능	네이티브 DP	SMG 기반 DP
로드 밸런싱	내장 인-프로세스 방식	고급 정책 (캐시 인지, power-of-two 등)
캐시 인지	❌ 없음	✅ 있음 — 캐시 히트율이 훨씬 높음
Throughput	기준선	상당한 향상
멀티 노드 지원	제한적	✅ 완전 지원
워커 헬스 모니터링	기본	✅ 회로 차단기, 헬스체크
신뢰성	기본	✅ 재시도, 레이트 리밋, 큐잉
관측 가능성	기본 메트릭	✅ 40개 이상 Prometheus 메트릭, OpenTelemetry
핫 워커 추가/제거	❌ 없음	✅ 있음

SMG의 성능

SMG의 캐시 인지 라우팅 정책은 공유 프리픽스가 있는 워크로드에서 성능을 크게 개선해요:

메트릭	캐시 인지 없음	캐시 인지 SMG
Throughput (token/s)	82,665	158,596 (+92%)
캐시 히트율	20%	75% (+275%)

벤치마크 출처: SGLang v0.4 블로그, 여러 긴 프리픽스 그룹 워크로드, 8x A100 80GB GPU, dp-size=8

언제 무엇을 쓸까

네이티브 DP는 언제 쓰나:

• 네이티브/Naive DP는 거의 쓰지 마세요
• DP 라우팅 학습 자료용

SMG 기반 DP는 언제 쓰나:

• DP가 필요하다고 생각되는 어떤 경우든
• 프로덕션 배포
• 멀티 노드 분산 환경
• 공유 프리픽스가 있는 워크로드 (높은 캐시 재사용 가능성)
• 높은 가용성·신뢰성 기능이 필요할 때
• 상세한 관측 가능성과 메트릭이 필요할 때
• 고효율 RL 롤아웃 시스템을 원할 때

RL 롤아웃 시스템에는 SMG 기반 DP가 네이티브 DP 라우팅보다 훨씬 나은 결정적인 네 가지 이유가 있어요. 자세한 내용은 RL의 로드 밸런싱 라우터에서 확인할 수 있어요.

SMG 빠른 시작

설치

pip install sglang-router
# 또는
pip install "sglang[all]"

옵션 A: 워커와 SMG 함께 띄우기 (가장 간단)

시작하는 가장 쉬운 방법이에요 — SMG와 워커가 함께 띄워져요:

python -m sglang_router.launch_server \
    --model-path meta-llama/Meta-Llama-3.1-8B-Instruct \
    --dp-size 4 \
    --host 0.0.0.0 \
    --port 30000

옵션 B: 별도 띄우기 (멀티 노드)

여러 머신에 걸친 분산 배포용:

1. 각 노드에서 워커 띄우기

# Node 1
python -m sglang.launch_server \
    --model-path meta-llama/Meta-Llama-3.1-8B-Instruct \
    --port 8000

# Node 2
python -m sglang.launch_server \
    --model-path meta-llama/Meta-Llama-3.1-8B-Instruct \
    --port 8000

2. 워커를 가리키는 SMG 띄우기

python -m sglang_router.launch_router \
    --worker-urls http://node1:8000 http://node2:8000 \
    --policy cache_aware \
    --host 0.0.0.0 \
    --port 30000

옵션 C: 동적 워커 등록

워커를 동적으로 추가/제거할 수 있는 탄력적 배포용:

# SMG 먼저 띄우기
python -m sglang_router.launch_router \
    --policy cache_aware \
    --host 0.0.0.0 \
    --port 30000

# 워커 동적 등록
curl -X POST http://localhost:30000/workers \
    -H "Content-Type: application/json" \
    -d '{"url": "http://worker1:8000"}'

curl -X POST http://localhost:30000/workers \
    -H "Content-Type: application/json" \
    -d '{"url": "http://worker2:8000"}'

로드 밸런싱 정책

SMG는 여러 로드 밸런싱 정책을 지원해요:

정책	설명	가장 적합한 곳
cache_aware	캐시 지역성과 로드 밸런싱 결합	대부분의 워크로드에 권장
round_robin	워커를 순서대로 순환	단순하고 예측 가능한 분산
random	랜덤 워커 선택	기준선, 테스트
power_of_two	두 워커 샘플링 후 더 가벼운 쪽 선택	저지연 요구

캐시 인지 정책 (기본, 권장)

캐시 인지 정책은 대부분의 워크로드에서 최상의 성능을 제공해요:

python -m sglang_router.launch_router \
    --worker-urls http://worker1:8000 http://worker2:8000 \
    --policy cache_aware \
    --cache-threshold 0.5 \
    --balance-abs-threshold 32 \
    --balance-rel-threshold 1.5 \
    --eviction-interval-secs 120 \
    --max-tree-size 67108864

작동 방식:

1. 요청 이력 기반으로 각 워커에 대한 근사 radix 트리 유지
2. 접두사 매칭(캐시 히트)이 가장 높은 워커로 요청 라우팅
3. 로드가 불균형하면 최단 큐 라우팅으로 폴백
4. 메모리 오버플로를 막기 위해 오래된 항목 자동 퇴거

모범 사례

1. cache_aware 정책으로 시작 — 대부분의 워크로드에 캐시 지역성과 로드 분산의 최상의 균형 제공
2. 프로덕션에 SMG 사용 — 더 나은 신뢰성·관측 가능성을 위해 sglang.launch_server보다 sglang_router.launch_server 선호
3. 헬스체크 활성화 — --router-health-check-interval-secs로 비정상 워커를 자동 감지·제거

모범 사례가 적용된 권장 커맨드:

python -m sglang_router.launch_server \
    --model-path meta-llama/Meta-Llama-3.1-8B-Instruct \
    --dp-size 4 \
    --router-policy cache_aware \
    --router-health-check-interval-secs 30 \
    --router-prometheus-port 10001 \
    --host 0.0.0.0 \
    --port 30000

고급 설정(회로 차단기, 재시도, Prometheus 메트릭, K8s 통합)은 SGLang Model Gateway 문서를 참고하세요.

트래픽 분산 검증

SMG를 띄운 뒤 트래픽이 올바르게 분산되는지 확인해요:

1. 워커 상태 확인:

curl http://localhost:30000/workers

2. 로드 분산 확인:

curl http://localhost:30000/get_loads

3. 메트릭 모니터링 (Prometheus 활성화 시):

# 확인할 주요 메트릭
smg_router_requests_total{model="..."}
smg_worker_requests_active{worker="..."}
sglang_cache_hit_rate{source="..."}

상세 메트릭과 모니터링 설정은 SGLang Model Gateway 문서를 참고하세요.

참고

전략	유스케이스	핵심 이점
네이티브 DP (--dp-size)	사용 금지	이해하기 쉬움, Rust 기반 아님
SMG 기반 DP	프로덕션 (권장)	캐시 인지 라우팅, 높은 가용성
DPA (--dp-size N --enable-dp-attention)	DeepSeek/MLA 모델	KV 캐시 중복 제거, throughput 향상
DPA + EP	DeepSeek MoE 모델	바닐라 TP 대비 상당한 throughput 향상

DeepSeek 권장 프로덕션 설정:

1. attention 레이어에 DPA 활성화 (--dp-size 8 --enable-dp-attention)
2. MoE 레이어에 EP 활성화 (--ep 8 --moe-a2a-backend deepep)
3. SMG를 cache_aware 정책으로 사용

관련 문서:

• Expert Parallelism — DeepEP, Two-Batch Overlap, EPLB
• SGLang Model Gateway 문서 — SMG 설정 & 트러블슈팅
• 대규모 EP 블로그 — 96 GPU 배포 가이드

더 알아보기 (Learn more)

• Expert Parallelism — MoE 전문가 병렬의 심화 내용
• SGLang Model Gateway — SMG 라우팅 정책과 고급 설정
• 하이퍼파라미터 튜닝 — 배치·메모리 파라미터로 throughput 최적화