SGLang EPD Disaggregation과 Pipeline Parallelism — Vision-Language Model 서빙을 3단계로 분리해 TTFT 최대 8배 단축하는 아키텍처

멀티모달 AI를 직접 서비스해본 경험이 없어도 상관없습니다. 요즘은 이미지를 입력받는 AI 기능이 워낙 빠르게 보편화되고 있어서, 조만간 누구든 Vision-Language Model(VLM) — 텍스트와 이미지를 함께 이해하는 AI 모델 — 을 서빙해야 할 상황이 찾아옵니다. 그리고 그 순간, 생각보다 훨씬 빨리 벽에 부딪히게 됩니다. "이미지 몇 장 더 붙었을 뿐인데 왜 이렇게 느리지?"

저도 처음 VLM 서빙을 구성할 때 이 문제를 겪었습니다. Prefill 노드의 GPU 사용률이 이미지 인코딩 때마다 뚝뚝 끊기는 걸 보고 한참 원인을 찾아 헤맸는데, 결국 문제는 이미지를 분석하는 Vision Transformer(ViT) 인코딩과 언어 모델 처리를 같은 GPU에 묶어두는 구조 자체였습니다. 기존 LLM 서빙의 표준이 된 PD(Prefill-Decode) 분리는 강력하지만, VLM에는 결정적인 맹점이 있었던 거죠.

EPD(Encoder-Prefill-Decode) Disaggregation은 이 세 단계를 완전히 독립된 서버 풀로 분리해, 멀티이미지 VLM 서빙에서 TTFT(첫 토큰 응답 시간)를 최대 6~8배 단축하는 아키텍처 전환입니다. 여기에 Pipeline Parallelism을 결합하면 DeepSeek-V3 같은 초대규모 모델도 멀티노드로 자연스럽게 확장됩니다. EPD가 왜 필요한지, 실제로 어떻게 구성하는지, 그리고 도입 전에 꼭 알아둬야 할 함정까지 함께 살펴보겠습니다.

핵심 개념

PD Disaggregation이 먼저 생긴 이유

EPD를 이해하려면 그 전신인 PD Disaggregation부터 짚어볼 필요가 있습니다. LLM 서빙에서 Prefill과 Decode는 계산 특성이 완전히 다릅니다.

Prefill: 입력 토큰 전체를 한꺼번에 처리하는 Compute-bound 작업 (연산 집약적)
Decode: 토큰을 하나씩 자동회귀 방식으로 생성하는 Memory-bound 작업 (메모리 대역폭 집약적)

이 두 작업을 같은 GPU에서 섞어 돌리면 서로 방해가 됩니다. 그래서 각각 전용 GPU 풀에서 분리해 실행하는 PD Disaggregation이 사실상 업계 표준이 됐습니다. Meta, LinkedIn, Mistral 등 주요 기업이 이미 프로덕션에서 이 구조를 쓰고 있습니다.

VLM에 PD만으로는 부족한 이유

문제는 VLM이 여기에 ViT(Vision Transformer) 인코딩을 하나 더 얹는다는 겁니다. ViT는 이미지나 비디오를 언어 모델이 이해할 수 있는 벡터(임베딩)로 변환하는 역할을 합니다. 이걸 Prefill 노드에서 함께 처리하면 세 가지 문제가 동시에 터집니다.

문제	내용
TP 확장 비효율	LLM 가속에 쓰는 Tensor Parallelism을 올려도 ViT 처리 속도는 거의 오르지 않음
LLM GPU 유휴	이미지 수가 늘수록 ViT 인코딩이 끝나길 기다리는 대기 시간이 폭증
메모리 잠식	인코더 메모리가 KV 캐시 공간과 배치 크기를 갉아먹음

TP 확장이 왜 ViT에 이득이 없는지 궁금하실 수 있는데요. Tensor Parallelism은 레이어 연산을 여러 GPU에 나눠서 처리하고, 그 결과를 동기화(all-reduce 통신)하는 방식입니다. ViT는 레이어당 시퀀스 길이가 입력 이미지 해상도에 따라 고정되고, 레이어 자체가 상대적으로 단순하기 때문에 이 통신 비용이 연산 절약분을 금방 잠식해버립니다. GPU를 늘려도 속도가 거의 안 오르는 상황이 되는 겁니다.

EPD 아키텍처 — 세 단계 완전 분리

EPD는 이 세 단계를 완전히 독립된 서버 풀로 분리해 해결합니다.

[이미지/비디오 입력]
       ↓
┌─────────────────────────┐
│     Encoder Node        │  ← ViT 전용, 데이터 병렬 수평 확장, 임베딩 캐싱
└────────────┬────────────┘
             │ 비전 임베딩 전송 (ZMQ / Mooncake)
             ↓
┌─────────────────────────┐
│     Prefill Node        │  ← LLM 언어 사전충전, Compute-bound
└────────────┬────────────┘
             │ KV Cache 전송
             ↓
┌─────────────────────────┐
│     Decode Node         │  ← 토큰 자동회귀 생성, Memory-bound
└─────────────────────────┘

각 단계가 완전히 분리됐기 때문에 이미지 요청량이 늘면 Encoder 노드만 더 투입하고, 동시 세션이 많아지면 Decode 노드만 수평 확장하는 게 가능해집니다. ViT는 Tensor Parallelism 대신 Data Parallelism으로 확장하면 효과가 크다는 것도 이 분리 덕분에 자연스럽게 활용됩니다.

TP vs DP 한눈에 비교: Tensor Parallelism(TP)은 하나의 레이어를 여러 GPU에 쪼개는 방식이고, Data Parallelism(DP)은 동일한 모델 복사본을 여러 GPU에 올려 각자 다른 요청을 처리하게 하는 방식입니다. ViT는 TP에서 통신 오버헤드가 커지므로, DP로 요청 수 증가에 선형 대응하는 편이 훨씬 효율적입니다.

비전 임베딩과 KV Cache는 노드 간 전송이 필요합니다. SGLang은 이 전송에 ZMQ와 Mooncake 두 가지 백엔드를 지원합니다. 소규모 테스트나 단일 클러스터 환경에서는 ZMQ가 설정이 간단하고, InfiniBand(GPU 서버 간 초고속 통신 전용 네트워크)를 활용하는 고성능 프로덕션 환경에서는 Mooncake가 전송 처리량이 높습니다. vLLM은 유사한 역할을 하는 NIXL 전송 레이어를 사용합니다.

Pipeline Parallelism과의 결합 — 대규모 MoE 모델과 긴 컨텍스트를 위해

EPD와 별개로, SGLang은 2026년 초에 청크드 파이프라인 병렬성(Chunked Pipeline Parallelism)을 PD Disaggregation과 결합하는 기능을 발표했습니다.

DeepSeek-V3 같은 수백 억 파라미터의 대규모 MoE(Mixture-of-Experts) 모델은 단일 노드의 GPU 메모리에 전체 파라미터를 올리기 어렵습니다. Pipeline Parallelism은 모델의 레이어를 여러 노드에 파이프처럼 분산해서 단일 노드로는 불가능한 규모를 처리할 수 있게 합니다. 레이어가 여러 노드에 분산되면 각 노드의 KV 캐시도 분산돼, 단일 노드로는 감당 못할 길이의 컨텍스트까지 처리할 수 있게 되는 것입니다.

yaml

DeepSeek-V3.1 서빙 구성 (H20 클러스터, SGLang)
 
PP4 TP8 구성:
  - PP: 4개 노드에 레이어 파이프라인 분산
  - TP: 각 노드 내 8 GPU 텐서 병렬
  - 청크 크기: 12K 토큰
 
TP32 단일 구성 대비:
  - Prefill Throughput: +30.5%
  - TTFT: -67.9% (약 3.1배 단축)
  - Strong Scaling Efficiency: 82.8%

Strong Scaling Efficiency: 노드를 N배 늘렸을 때 처리량도 N배에 얼마나 가까운지를 나타내는 지표입니다. 이상적이면 100%이고, 실무에서 80%대는 상당히 우수한 수치입니다.

MoE(Mixture-of-Experts): 모델 파라미터 전체를 한 번에 활성화하지 않고, 입력마다 일부 "전문가(Expert)" 레이어만 선택적으로 사용하는 구조입니다. DeepSeek-V3는 이 MoE 구조 덕분에 파라미터 수 대비 연산량이 낮지만, 전체 파라미터를 여러 GPU에 분산해야 해서 EP(Expert Parallelism)가 필수입니다.

실전 적용

실전 예시를 세 가지로 나눠서 소개합니다. VLM 워크로드에서 EPD를 직접 활성화하는 경우, DeepSeek-V3 규모 모델을 멀티노드로 서빙하는 경우, vLLM을 사용하는 경우입니다. 각자 상황에 맞는 예시부터 보셔도 됩니다.

예시 1: SGLang EPD로 멀티이미지 VLM 서빙 (Qwen2-VL)

요청당 4~8개 이미지를 처리하는 VLM 워크로드가 있다고 가정해보겠습니다. SGLang EPD를 활성화하면 Encoder, Prefill, Decode 서버를 별도로 띄우게 됩니다. 아래 명령어는 SGLang v0.4.x 기준이며, 버전에 따라 파라미터명이나 라우터 엔트리포인트가 달라질 수 있으니 공식 문서의 epd_disaggregation.md를 함께 확인해보시면 좋습니다.

bash

# 1. Encoder 서버 시작 (ViT 전용, 이미지 요청량에 따라 --dp-size 수평 확장)
python -m sglang.launch_server \
  --model-path Qwen/Qwen2-VL-7B-Instruct \
  --port 30000 \
  --role encoder \
  --tp-size 1 \
  --dp-size 4
 
# 2. Prefill 서버 시작
python -m sglang.launch_server \
  --model-path Qwen/Qwen2-VL-7B-Instruct \
  --port 30001 \
  --role prefill \
  --tp-size 4 \
  --disagg-prefill-port 40001 \
  --encoder-server-url http://localhost:30000
 
# 3. Decode 서버 시작
python -m sglang.launch_server \
  --model-path Qwen/Qwen2-VL-7B-Instruct \
  --port 30002 \
  --role decode \
  --tp-size 4 \
  --disagg-decode-port 40002
 
# 4. 라우터(Proxy) 기동
# 엔트리포인트와 파라미터는 SGLang 버전마다 다를 수 있습니다
# 공식 epd_disaggregation.md의 명령어를 우선 참고해주세요
python -m sglang.launch_server \
  --role router \
  --prefill http://localhost:30001 \
  --decode http://localhost:30002 \
  --port 8000

클라이언트 코드는 일반 OpenAI SDK를 그대로 쓸 수 있어서, 기존 코드를 거의 바꾸지 않아도 됩니다. 처음 EPD를 도입할 때 예상보다 훨씬 편했던 부분입니다.

python

import openai
 
client = openai.Client(base_url="http://localhost:8000/v1", api_key="none")
 
response = client.chat.completions.create(
    model="Qwen2-VL-7B-Instruct",
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "image_url", "image_url": {"url": "https://example.com/img1.jpg"}},
                {"type": "image_url", "image_url": {"url": "https://example.com/img2.jpg"}},
                {"type": "image_url", "image_url": {"url": "https://example.com/img3.jpg"}},
                {"type": "text", "text": "이 세 이미지의 공통점은 무엇인가요?"},
            ],
        }
    ],
)

구성 요소	역할	확장 전략
`--role encoder`	ViT만 실행, 비전 임베딩 반환	`--dp-size` 늘려 수평 확장
`--role prefill`	언어 모델 사전충전만 담당	`--tp-size` 늘려 연산 가속
`--role decode`	토큰 자동회귀 생성	동시 세션 수에 맞게 노드 추가
라우터(Proxy)	요청 라우팅 및 흐름 조율	라우터 자체는 가볍게 유지

예시 2: SGLang Pipeline Parallelism으로 DeepSeek-V3 규모 서빙

DeepSeek-V3/R1 같은 대규모 MoE 모델은 단일 노드 TP만으로는 GPU 메모리가 부족합니다. Pipeline Parallelism을 PD Disaggregation과 함께 구성하면 멀티노드로 자연스럽게 확장됩니다.

bash

# Prefill 서버 — PP4 TP8 구성 (4개 노드, 노드당 8 GPU)
# --node-rank는 각 노드마다 0, 1, 2, 3으로 다르게 지정해서 실행
python -m sglang.launch_server \
  --model-path deepseek-ai/DeepSeek-V3 \
  --role prefill \
  --tp-size 8 \
  --pp-size 4 \
  --chunked-prefill-size 12288 \
  --dist-init-addr "node0:29500" \
  --node-rank 0 \
  --nnodes 4
 
# Decode 서버 — EP32 대규모 Expert Parallelism 포함
# node4~node7에서 실행, 각 노드의 --node-rank도 0~3으로 지정
python -m sglang.launch_server \
  --model-path deepseek-ai/DeepSeek-V3 \
  --role decode \
  --tp-size 8 \
  --ep-size 32 \
  --dist-init-addr "node4:29500" \
  --node-rank 0 \
  --nnodes 4

아래는 LMSYS 리포트 기준의 실제 처리량 수치입니다. "52,300 tokens/sec"라는 숫자가 감이 오지 않을 수 있는데, DeepSeek 공식 배포에서 발표한 수치와 거의 동일한 수준으로, 오픈소스 서빙으로서는 상당히 놀라운 결과였습니다.

python

# 96개 H100 GPU 구성 처리량 (LMSYS 리포트, 2000토큰 입력 기준)
performance_h100 = {
    "입력_처리량": "52,300 tokens/sec",  # DeepSeek 공식 수치와 동등한 수준
    "출력_처리량": "22,300 tokens/sec",
}
 
# 64개 H200 GPU 구성 (단일 노드 TP 대비 개선 폭)
performance_h200 = {
    "처리량_향상": "3.8배",
    "TTFT_단축":  "3.5배 (약 71% 감소)",
}

예시 3: vLLM에서 인코더 분리 활성화

vLLM v0.11.1부터는 네이티브 인코더 분리가 지원됩니다. LLaVA-OneVision 같은 모델을 서빙할 때 CLI 옵션 하나로 활성화됩니다. ViT에 TP를 올려봤자 이득이 없다는 건 위에서 설명드린 통신 비용 때문이라, --encoder-tensor-parallel-size는 1로 두는 게 기본 전략입니다.

bash

# vLLM CLI 서버 실행 — NIXL 전송 레이어와 함께
vllm serve llava-hf/llava-onevision-qwen2-7b-ov-hf \
  --tensor-parallel-size 4 \
  --encoder-tensor-parallel-size 1 \
  --kv-transfer-config '{"kv_connector":"NixlConnector"}' \
  --port 8000

python

# Python API로 직접 호출하는 경우
from vllm import LLM, SamplingParams
 
llm = LLM(
    model="llava-hf/llava-onevision-qwen2-7b-ov-hf",
    tensor_parallel_size=4,
    max_num_seqs=256,
    gpu_memory_utilization=0.9,
)

장단점 분석

EPD를 실제로 도입하기 전에 한 가지를 먼저 확인해보시면 좋습니다. 요청당 평균 이미지 수가 2장 미만이라면 EPD 효과가 제한적입니다. 텍스트 중심 워크로드에 무리하게 도입하면 운영 복잡도만 높아질 수 있습니다. Prometheus·Grafana로 현재 Prefill 노드의 GPU 사용률과 유휴 시간 비율을 먼저 측정해보시면 도입 우선순위 판단에 도움이 됩니다.

장점

항목	내용
TTFT 단축	멀티이미지 워크로드(요청당 4~~8장 기준)에서 최대 6~~8배 단축
처리량 향상	엔드투엔드 처리량 최대 57% 증가
메모리 효율	인코딩 단계 GPU 메모리 최대 15배 절감, 배치 크기 22배 확대 가능
독립 스케일링	Encoder/Prefill/Decode를 워크로드 특성에 맞게 각각 수평 확장
임베딩 캐싱	반복 등장하는 이미지의 ViT 연산을 인코더 서버에서 캐싱해 재사용
대규모 모델 서빙	PP 결합 시 단일 노드로 불가능한 규모도 멀티노드로 확장 가능

단점 및 주의사항

항목	내용	대응 방안
고속 네트워크 필수	비전 임베딩·KV 캐시를 노드 간 전송 — 일반 이더넷으로는 오버헤드가 이득을 상쇄 가능	InfiniBand 또는 400GbE 이상 확보, Mooncake/NIXL 활용
운영 복잡성 증가	세 개의 독립 서버 풀을 각각 관리해야 함	워크로드 특성에 맞게 Encoder:Prefill:Decode 비율 사전 프로파일링
청크 크기 민감성	Pipeline Parallelism의 청크 크기가 모델마다 다름	DeepSeek-V3.1: 12K, Qwen3-235B: 6K — 모델별 벤치마크 필요
역할 전환 오버헤드	워크로드 변화 시 노드 간 역할 재배분 비용 발생	가능하다면 동적 스케줄러나 오토스케일링 정책 도입 검토
모델 지원 범위	SGLang EPD는 LLaVA-OneVision, Qwen2-VL, LLaVA-Video 등 주요 모델 지원	비지원 모델은 vLLM-Omni 로드맵 확인 또는 어댑터 개발 필요

KV Cache 전송: Prefill 서버에서 계산한 Key-Value 행렬(어텐션의 메모리)을 Decode 서버로 넘기는 과정입니다. 이 전송 속도가 병목이 되면 분리 이득이 반감되므로 고속 인터커넥트가 전제 조건입니다.

실무에서 가장 흔한 실수

네트워크 대역폭을 간과하고 EPD를 도입하는 경우 — 일반 이더넷 환경에서 임베딩·KV 전송 오버헤드가 TTFT 이득을 상쇄할 수 있습니다. InfiniBand 또는 400GbE 이상의 환경인지 먼저 확인해보시는 것을 권장합니다.
청크 크기를 기본값으로 두는 경우 — Pipeline Parallelism의 청크 크기는 모델 구조와 시퀀스 길이에 따라 최적값이 크게 달라집니다. 동일한 모델이라도 입력 분포가 다르면 재튜닝이 필요할 수 있습니다.
Encoder:Prefill:Decode 비율을 고정해두는 경우 — 낮 시간대는 이미지 요청 비율이 높고, 밤에는 긴 텍스트 요청이 많아지는 패턴이 흔합니다. 비율을 고정하면 한쪽이 유휴 상태가 되므로, 가능하다면 동적 스케줄러나 오토스케일링 정책을 함께 고려해보시는 것을 권장합니다.

마치며

솔직히 말씀드리면, 모든 VLM 서빙에 EPD가 필요하다고 생각하지 않습니다. 요청당 이미지가 1~2장 이하라면 세 개의 서버 풀을 관리하는 운영 복잡도를 감수할 만한 이득이 나오지 않을 수 있습니다. 하지만 이미지 요청 비중이 높아지고, 특히 요청당 4장 이상 이미지를 처리하는 상황이 된다면 EPD는 선택지가 아니라 필수에 가깝습니다. 이 글을 읽고 나서 자신의 서빙 환경에 EPD가 필요한지 아닌지를 스스로 판단할 수 있게 됐다면, 그게 가장 의미 있는 수확일 것 같습니다.

EPD Disaggregation은 VLM 서빙의 패러다임을 2단계에서 3단계로 전환하는 아키텍처 변화로, 이미지 요청이 많아질수록 그 가치가 기하급수적으로 커집니다. 지금 바로 시작해볼 수 있는 방법들을 정리하면:

✓ SGLang v0.4.x로 단일 머신 EPD 테스트 — pip install sglang[all] 후 Qwen2-VL-7B 같은 비교적 작은 VLM으로 Encoder/Prefill/Decode 서버를 로컬에서 각각 띄워볼 수 있습니다. 공식 문서의 epd_disaggregation.md에 단계별 명령어가 정리되어 있습니다.

✓ 현재 워크로드의 이미지 요청 비율 측정 — Prometheus·Grafana로 현재 Prefill 노드의 GPU 사용률과 유휴 시간 비율을 먼저 측정해보시면 도입 우선순위 판단에 도움이 됩니다. 요청당 평균 이미지 수가 2장을 넘는 시점부터 EPD 효과가 명확하게 나타납니다.

✓ 단계적으로 도입 — InfiniBand 또는 고속 이더넷이 확보된 노드 쌍부터 PD Disaggregation을 먼저 적용하고, 안정성을 확인한 뒤 Encoder 분리를 추가하는 순서로 리스크를 줄일 수 있습니다.

참고 자료

#EPD-Disaggregation#VLM#SGLang#PipelineParallelism#TensorParallelism#KVCache#ViT#LLM서빙#MoE#TTFT

SGLang EPD Disaggregation과 Pipeline Parallelism — Vision-Language Model 서빙을 3단계로 분리해 TTFT 최대 8배 단축하는 아키텍처 | DEV BAK - 기술블로그

SGLang EPD Disaggregation과 Pipeline Parallelism — Vision-Language Model 서빙을 3단계로 분리해 TTFT 최대 8배 단축하는 아키텍처

핵심 개념

PD Disaggregation이 먼저 생긴 이유

EPD를 이해하려면 그 전신인 PD Disaggregation부터 짚어볼 필요가 있습니다. LLM 서빙에서 Prefill과 Decode는 계산 특성이 완전히 다릅니다.

Prefill: 입력 토큰 전체를 한꺼번에 처리하는 Compute-bound 작업 (연산 집약적)
Decode: 토큰을 하나씩 자동회귀 방식으로 생성하는 Memory-bound 작업 (메모리 대역폭 집약적)

VLM에 PD만으로는 부족한 이유

문제	내용
TP 확장 비효율	LLM 가속에 쓰는 Tensor Parallelism을 올려도 ViT 처리 속도는 거의 오르지 않음
LLM GPU 유휴	이미지 수가 늘수록 ViT 인코딩이 끝나길 기다리는 대기 시간이 폭증
메모리 잠식	인코더 메모리가 KV 캐시 공간과 배치 크기를 갉아먹음

EPD 아키텍처 — 세 단계 완전 분리

EPD는 이 세 단계를 완전히 독립된 서버 풀로 분리해 해결합니다.

[이미지/비디오 입력]
       ↓
┌─────────────────────────┐
│     Encoder Node        │  ← ViT 전용, 데이터 병렬 수평 확장, 임베딩 캐싱
└────────────┬────────────┘
             │ 비전 임베딩 전송 (ZMQ / Mooncake)
             ↓
┌─────────────────────────┐
│     Prefill Node        │  ← LLM 언어 사전충전, Compute-bound
└────────────┬────────────┘
             │ KV Cache 전송
             ↓
┌─────────────────────────┐
│     Decode Node         │  ← 토큰 자동회귀 생성, Memory-bound
└─────────────────────────┘

TP vs DP 한눈에 비교: Tensor Parallelism(TP)은 하나의 레이어를 여러 GPU에 쪼개는 방식이고, Data Parallelism(DP)은 동일한 모델 복사본을 여러 GPU에 올려 각자 다른 요청을 처리하게 하는 방식입니다. ViT는 TP에서 통신 오버헤드가 커지므로, DP로 요청 수 증가에 선형 대응하는 편이 훨씬 효율적입니다.

Pipeline Parallelism과의 결합 — 대규모 MoE 모델과 긴 컨텍스트를 위해

EPD와 별개로, SGLang은 2026년 초에 청크드 파이프라인 병렬성(Chunked Pipeline Parallelism)을 PD Disaggregation과 결합하는 기능을 발표했습니다.

yaml

DeepSeek-V3.1 서빙 구성 (H20 클러스터, SGLang)
 
PP4 TP8 구성:
  - PP: 4개 노드에 레이어 파이프라인 분산
  - TP: 각 노드 내 8 GPU 텐서 병렬
  - 청크 크기: 12K 토큰
 
TP32 단일 구성 대비:
  - Prefill Throughput: +30.5%
  - TTFT: -67.9% (약 3.1배 단축)
  - Strong Scaling Efficiency: 82.8%

Strong Scaling Efficiency: 노드를 N배 늘렸을 때 처리량도 N배에 얼마나 가까운지를 나타내는 지표입니다. 이상적이면 100%이고, 실무에서 80%대는 상당히 우수한 수치입니다.

MoE(Mixture-of-Experts): 모델 파라미터 전체를 한 번에 활성화하지 않고, 입력마다 일부 "전문가(Expert)" 레이어만 선택적으로 사용하는 구조입니다. DeepSeek-V3는 이 MoE 구조 덕분에 파라미터 수 대비 연산량이 낮지만, 전체 파라미터를 여러 GPU에 분산해야 해서 EP(Expert Parallelism)가 필수입니다.

실전 적용

예시 1: SGLang EPD로 멀티이미지 VLM 서빙 (Qwen2-VL)

bash

# 1. Encoder 서버 시작 (ViT 전용, 이미지 요청량에 따라 --dp-size 수평 확장)
python -m sglang.launch_server \
  --model-path Qwen/Qwen2-VL-7B-Instruct \
  --port 30000 \
  --role encoder \
  --tp-size 1 \
  --dp-size 4
 
# 2. Prefill 서버 시작
python -m sglang.launch_server \
  --model-path Qwen/Qwen2-VL-7B-Instruct \
  --port 30001 \
  --role prefill \
  --tp-size 4 \
  --disagg-prefill-port 40001 \
  --encoder-server-url http://localhost:30000
 
# 3. Decode 서버 시작
python -m sglang.launch_server \
  --model-path Qwen/Qwen2-VL-7B-Instruct \
  --port 30002 \
  --role decode \
  --tp-size 4 \
  --disagg-decode-port 40002
 
# 4. 라우터(Proxy) 기동
# 엔트리포인트와 파라미터는 SGLang 버전마다 다를 수 있습니다
# 공식 epd_disaggregation.md의 명령어를 우선 참고해주세요
python -m sglang.launch_server \
  --role router \
  --prefill http://localhost:30001 \
  --decode http://localhost:30002 \
  --port 8000

python

import openai
 
client = openai.Client(base_url="http://localhost:8000/v1", api_key="none")
 
response = client.chat.completions.create(
    model="Qwen2-VL-7B-Instruct",
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "image_url", "image_url": {"url": "https://example.com/img1.jpg"}},
                {"type": "image_url", "image_url": {"url": "https://example.com/img2.jpg"}},
                {"type": "image_url", "image_url": {"url": "https://example.com/img3.jpg"}},
                {"type": "text", "text": "이 세 이미지의 공통점은 무엇인가요?"},
            ],
        }
    ],
)

구성 요소	역할	확장 전략
`--role encoder`	ViT만 실행, 비전 임베딩 반환	`--dp-size` 늘려 수평 확장
`--role prefill`	언어 모델 사전충전만 담당	`--tp-size` 늘려 연산 가속
`--role decode`	토큰 자동회귀 생성	동시 세션 수에 맞게 노드 추가
라우터(Proxy)	요청 라우팅 및 흐름 조율	라우터 자체는 가볍게 유지

예시 2: SGLang Pipeline Parallelism으로 DeepSeek-V3 규모 서빙

bash

# Prefill 서버 — PP4 TP8 구성 (4개 노드, 노드당 8 GPU)
# --node-rank는 각 노드마다 0, 1, 2, 3으로 다르게 지정해서 실행
python -m sglang.launch_server \
  --model-path deepseek-ai/DeepSeek-V3 \
  --role prefill \
  --tp-size 8 \
  --pp-size 4 \
  --chunked-prefill-size 12288 \
  --dist-init-addr "node0:29500" \
  --node-rank 0 \
  --nnodes 4
 
# Decode 서버 — EP32 대규모 Expert Parallelism 포함
# node4~node7에서 실행, 각 노드의 --node-rank도 0~3으로 지정
python -m sglang.launch_server \
  --model-path deepseek-ai/DeepSeek-V3 \
  --role decode \
  --tp-size 8 \
  --ep-size 32 \
  --dist-init-addr "node4:29500" \
  --node-rank 0 \
  --nnodes 4

python

# 96개 H100 GPU 구성 처리량 (LMSYS 리포트, 2000토큰 입력 기준)
performance_h100 = {
    "입력_처리량": "52,300 tokens/sec",  # DeepSeek 공식 수치와 동등한 수준
    "출력_처리량": "22,300 tokens/sec",
}
 
# 64개 H200 GPU 구성 (단일 노드 TP 대비 개선 폭)
performance_h200 = {
    "처리량_향상": "3.8배",
    "TTFT_단축":  "3.5배 (약 71% 감소)",
}

예시 3: vLLM에서 인코더 분리 활성화

bash

# vLLM CLI 서버 실행 — NIXL 전송 레이어와 함께
vllm serve llava-hf/llava-onevision-qwen2-7b-ov-hf \
  --tensor-parallel-size 4 \
  --encoder-tensor-parallel-size 1 \
  --kv-transfer-config '{"kv_connector":"NixlConnector"}' \
  --port 8000

python

# Python API로 직접 호출하는 경우
from vllm import LLM, SamplingParams
 
llm = LLM(
    model="llava-hf/llava-onevision-qwen2-7b-ov-hf",
    tensor_parallel_size=4,
    max_num_seqs=256,
    gpu_memory_utilization=0.9,
)

장단점 분석

장점

항목	내용
TTFT 단축	멀티이미지 워크로드(요청당 4~~8장 기준)에서 최대 6~~8배 단축
처리량 향상	엔드투엔드 처리량 최대 57% 증가
메모리 효율	인코딩 단계 GPU 메모리 최대 15배 절감, 배치 크기 22배 확대 가능
독립 스케일링	Encoder/Prefill/Decode를 워크로드 특성에 맞게 각각 수평 확장
임베딩 캐싱	반복 등장하는 이미지의 ViT 연산을 인코더 서버에서 캐싱해 재사용
대규모 모델 서빙	PP 결합 시 단일 노드로 불가능한 규모도 멀티노드로 확장 가능

단점 및 주의사항

항목	내용	대응 방안
고속 네트워크 필수	비전 임베딩·KV 캐시를 노드 간 전송 — 일반 이더넷으로는 오버헤드가 이득을 상쇄 가능	InfiniBand 또는 400GbE 이상 확보, Mooncake/NIXL 활용
운영 복잡성 증가	세 개의 독립 서버 풀을 각각 관리해야 함	워크로드 특성에 맞게 Encoder:Prefill:Decode 비율 사전 프로파일링
청크 크기 민감성	Pipeline Parallelism의 청크 크기가 모델마다 다름	DeepSeek-V3.1: 12K, Qwen3-235B: 6K — 모델별 벤치마크 필요
역할 전환 오버헤드	워크로드 변화 시 노드 간 역할 재배분 비용 발생	가능하다면 동적 스케줄러나 오토스케일링 정책 도입 검토
모델 지원 범위	SGLang EPD는 LLaVA-OneVision, Qwen2-VL, LLaVA-Video 등 주요 모델 지원	비지원 모델은 vLLM-Omni 로드맵 확인 또는 어댑터 개발 필요

KV Cache 전송: Prefill 서버에서 계산한 Key-Value 행렬(어텐션의 메모리)을 Decode 서버로 넘기는 과정입니다. 이 전송 속도가 병목이 되면 분리 이득이 반감되므로 고속 인터커넥트가 전제 조건입니다.

실무에서 가장 흔한 실수

네트워크 대역폭을 간과하고 EPD를 도입하는 경우 — 일반 이더넷 환경에서 임베딩·KV 전송 오버헤드가 TTFT 이득을 상쇄할 수 있습니다. InfiniBand 또는 400GbE 이상의 환경인지 먼저 확인해보시는 것을 권장합니다.
청크 크기를 기본값으로 두는 경우 — Pipeline Parallelism의 청크 크기는 모델 구조와 시퀀스 길이에 따라 최적값이 크게 달라집니다. 동일한 모델이라도 입력 분포가 다르면 재튜닝이 필요할 수 있습니다.
Encoder:Prefill:Decode 비율을 고정해두는 경우 — 낮 시간대는 이미지 요청 비율이 높고, 밤에는 긴 텍스트 요청이 많아지는 패턴이 흔합니다. 비율을 고정하면 한쪽이 유휴 상태가 되므로, 가능하다면 동적 스케줄러나 오토스케일링 정책을 함께 고려해보시는 것을 권장합니다.

마치며

참고 자료

#EPD-Disaggregation#VLM#SGLang#PipelineParallelism#TensorParallelism#KVCache#ViT#LLM서빙#MoE#TTFT

핵심 개념

PD Disaggregation이 먼저 생긴 이유

VLM에 PD만으로는 부족한 이유

EPD 아키텍처 — 세 단계 완전 분리

Pipeline Parallelism과의 결합 — 대규모 MoE 모델과 긴 컨텍스트를 위해

실전 적용

예시 1: SGLang EPD로 멀티이미지 VLM 서빙 (Qwen2-VL)

예시 2: SGLang Pipeline Parallelism으로 DeepSeek-V3 규모 서빙

예시 3: vLLM에서 인코더 분리 활성화

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

마치며

참고 자료

핵심 개념

PD Disaggregation이 먼저 생긴 이유

VLM에 PD만으로는 부족한 이유

EPD 아키텍처 — 세 단계 완전 분리

Pipeline Parallelism과의 결합 — 대규모 MoE 모델과 긴 컨텍스트를 위해

실전 적용

예시 1: SGLang EPD로 멀티이미지 VLM 서빙 (Qwen2-VL)

예시 2: SGLang Pipeline Parallelism으로 DeepSeek-V3 규모 서빙

예시 3: vLLM에서 인코더 분리 활성화

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

마치며

참고 자료

추천 포스트

96개 H100에서 DeepSeek-V3 서빙이 가능한 이유: SGLang Expert Parallelism의 통신 최적화와 메모리 단편화 해법

XGrammar-2: 구조화 출력을 80배 빠르게 만든 설계 원리

FP4 양자화 + Blackwell GPU: H100 대비 4배 처리량이 가능한 조건과 쓰면 안 되는 상황

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

SGLang RadixAttention KV Cache Hit Rate: Prometheus 모니터링과 운영 튜닝으로 히트율을 3%에서 78%로 올린 방법 — 심화편

vLLM에서 SGLang으로 LLM 추론 마이그레이션: RAG·멀티턴 워크로드에서 처리 속도 6배 차이가 나는 이유