LLM WikiAccess-protected knowledge portal

WIKI

Prefill-Decode 분리 추론: LLM 서빙에서 TTFT와 처리량을 독립적으로 제어하는 방법

왜 지금 이 아키텍처를 봐야 하나 2026년 초를 지나면서 LLM 서빙의 사실상 표준이 바뀌었다. DeepSeek, Google Gemini, Meta, LinkedIn, Mistral, HuggingFace가 동시에 같은 방향으로 움직였다. Prefill과 Decode를 물리적으로 분리된 GPU 풀에서 실행한다 는 것이다. 단일 GPU 서버에서 두 단계를 함께 실행하던 구조 co located serving 가 왜 한계에 부

경로human/study/content/ai-frontier/23-vllm-disaggregated-prefill-decode-kv-transfer.md
카테고리Study
태그#ai-review #decode #disaggregated #prefill #study #transfer #vllm

왜 지금 이 아키텍처를 봐야 하나

2026년 초를 지나면서 LLM 서빙의 사실상 표준이 바뀌었다. DeepSeek, Google Gemini, Meta, LinkedIn, Mistral, HuggingFace가 동시에 같은 방향으로 움직였다. Prefill과 Decode를 물리적으로 분리된 GPU 풀에서 실행한다는 것이다.

단일 GPU 서버에서 두 단계를 함께 실행하던 구조(co-located serving)가 왜 한계에 부딪혔는지, 분리 구조가 어떻게 동작하는지, 그리고 실제 운영에서 무엇을 고려해야 하는지를 이 글에서 정리한다.

Prefill과 Decode: 하드웨어 요구사항이 반대다

LLM 추론은 두 단계로 이루어진다.

Prefill 단계는 입력 프롬프트(P개의 토큰)를 한 번의 forward pass로 처리한다. 모든 토큰의 어텐션이 동시에 계산되므로 행렬 연산 규모가 크다. 연산량(FLOP)이 모델 크기 × P에 비례하기 때문에 GPU의 ALU 처리량(compute-bound) 이 병목이다.

Decode 단계는 토큰을 한 번에 하나씩 자동회귀(autoregressive) 방식으로 생성한다. 매 스텝마다 모든 모델 가중치와 지금까지 생성된 토큰의 KV 캐시를 HBM에서 불러온다. 연산은 적지만 메모리 접근이 많다. GPU HBM 대역폭(memory-bandwidth-bound) 이 병목이다.

Prefill 단계
입력: P개 토큰 전체
처리: 1회 forward pass (병렬)
병목: GPU ALU (TFLOP/s)
특징: compute-bound
최적 하드웨어: 신형 GPU (높은 FLOP 밀도)
≠
Decode 단계
입력: 직전 토큰 1개씩
처리: 매 스텝 반복
병목: HBM 대역폭 (TB/s)
특징: memory-bandwidth-bound
최적 하드웨어: HBM 용량·대역폭 높은 GPU
Prefill과 Decode의 하드웨어 특성 비교

두 단계를 같은 GPU에서 실행하면, 하드웨어 특성이 반대인 작업이 한 자원을 놓고 경쟁한다.

Co-located 서빙의 두 가지 간섭 문제

단일 GPU 풀에서 두 단계를 함께 실행할 때 운영 현장에서 나타나는 문제는 명확하다.

문제 1: Prefill이 Decode를 막는다

큰 배치의 프롬프트가 들어오면 prefill이 GPU를 독점한다. 이 시간 동안 진행 중인 decode 요청들은 다음 토큰을 생성하지 못하고 대기한다. 사용자 입장에서는 생성이 갑자기 멈추는 것처럼 보인다. TBT(Time-Between-Tokens)가 급증한다.

문제 2: Decode 배치 크기가 Prefill 처리량을 제한한다

Decode 요청이 HBM을 가득 채우고 있으면, 새 prefill 요청을 처리할 GPU 메모리가 부족해진다. 큰 배치 prefill이 지연되면 TTFT(Time-to-First-Token)가 나빠진다.

결국 co-located 서빙에서 TTFT와 TBT는 동시에 좋아지기 어렵다. Prefill 배치를 늘리면 TBT가 나빠지고, Decode 배치를 늘리면 TTFT가 나빠진다.

분리 추론 아키텍처: 기본 구조

Disaggregated Prefill-Decode 서빙은 두 역할을 물리적으로 분리한다.

Prefill-Decode 분리 추론 아키텍처 클라이언트 API / 라우터 Prefill Pool compute-bound · 신형 GPU P-Node 1 vLLM instance KV producer P-Node 2 vLLM instance KV producer prefill 완료 → KV 캐시 생성 KV 전송 NIXL Transport RDMA / RoCE TCP fallback Decode Pool memory-bandwidth-bound · HBM 대용량 D-Node 1 vLLM instance KV consumer D-Node 2 vLLM instance KV consumer KV 수신 → 토큰 생성 반복 응답 스트리밍 생성 토큰 → 라우터 → 클라이언트 LMCache (선택 구성) Prefill 결과 KV를 공유 캐시에 보관 → Decode 노드 pull 방식으로 가져감 동일 프리픽스 KV 재사용으로 중복 prefill 제거 가능 KV 캐시 KV 캐시
Prefill-Decode 분리 추론 아키텍처

요청 흐름은 이렇다.

  1. 클라이언트 요청이 라우터에 도착한다.
  2. 라우터가 빈 Prefill 노드에 요청을 배정한다.
  3. Prefill 노드가 전체 프롬프트를 처리하고 KV 캐시를 생성한다.
  4. NIXL 등 KV 전송 레이어가 KV 캐시를 Decode 노드로 옮긴다.
  5. Decode 노드가 KV 캐시를 받아 토큰 생성을 시작한다.
  6. 생성된 토큰 스트림이 클라이언트에게 전달된다.

KV 캐시 전송: NIXL과 커넥터 인터페이스

Prefill이 완료되면 모든 레이어의 Key/Value 텐서를 Decode 노드로 옮겨야 한다. KV 캐시 크기는 2 × 레이어 수 × 토큰 수 × 헤드 수 × 헤드 차원 × 데이터 타입 크기로 결정된다. 70B 모델에서 1024 토큰의 KV 캐시는 수 GB에 달한다.

NIXL (NVIDIA Inference Xfer Library)

NIXL은 이 전송을 담당하는 표준 라이브러리다. vLLM과 NVIDIA Dynamo 양쪽에서 기본 KV 전송 메커니즘으로 사용된다.

지원하는 백엔드:

vLLM 커넥터 인터페이스

vLLM은 전송 방식을 추상화하는 KVConnector 인터페이스를 제공한다. Prefill 노드는 KV producer, Decode 노드는 KV consumer로 동작한다. 현재 사용 가능한 커넥터 구현체:

커넥터 선택은 클러스터 네트워크 환경과 KV 재사용 정책에 따라 달라진다.

LMCache: KV 캐시를 공유 레이어로 올리기

LMCache는 Prefill과 Decode 인스턴스 사이에 놓이는 별도의 KV 캐시 서비스다. 기본 NIXL 전송과 달리 push 대신 pull 방식으로 동작한다.

Prefill 노드가 KV를 LMCache 서버에 저장해두면, Decode 노드가 필요할 때 꺼내간다. 이 구조의 추가 이점은 동일 프리픽스 KV 재사용이다. 같은 시스템 프롬프트나 few-shot 예시가 반복되는 요청에서, Prefill 노드가 이미 계산된 KV를 다시 계산하지 않아도 된다.

vLLM에서 LMCache를 활성화하면 다음 설정이 필요하다.

# vLLM 서버 기동 시 (prefill 인스턴스)
--kv-transfer-config '{"kv_connector": "LMCacheConnector",
                        "kv_role": "kv_producer",
                        "kv_connector_extra_config": {
                          "lmcache_port": 8200}}'

# vLLM 서버 기동 시 (decode 인스턴스)
--kv-transfer-config '{"kv_connector": "LMCacheConnector",
                        "kv_role": "kv_consumer",
                        "kv_connector_extra_config": {
                          "lmcache_port": 8200}}'

성능 트레이드오프: TTFT, TBT, Throughput

분리 추론이 풀어주는 지표와 새로 생기는 비용을 정확히 이해해야 한다.

지표Co-locatedDisaggregated이유
TTFT (짧은 프롬프트)빠름느려질 수 있음KV 전송 지연 추가
TTFT (긴 프롬프트, 고동시성)느림개선Prefill 전용 노드가 대기 없이 처리
TBT불안정 (Prefill 간섭)안정Decode 전용 노드가 방해받지 않음
집계 처리량기준+50–100%독립 스케일링, 자원 최적화
운영 복잡도낮음높음풀 분리, KV 전송, 연결 관리
GPU 비용낮음높음별도 풀 유지

KV 전송이 TTFT에 추가 지연을 만든다는 점은 운영상 중요하다. 짧은 프롬프트(< 100 토큰)에서는 co-located serving 또는 chunked prefill 방식이 더 나은 TTFT를 준다. 분리 추론은 긴 컨텍스트, 높은 동시성, 배치 처리량이 중요한 환경에서 이득이 크다.

프로덕션 도입 현황

2026년 상반기를 기점으로 주요 프로바이더의 LLM 서빙 인프라가 분리 추론으로 전환됐다.

DeepSeek: 자체 프로덕션 클러스터에서 Prefill-Decode 분리를 운영 중이며, 이 구조 위에서 DSpark 최적화가 동작한다.

Google Gemini: Google 내부 서빙 인프라에서 분리 추론을 사용한다.

NVIDIA Dynamo: 분리 추론과 광역 전문가 병렬화(wide expert parallelism)를 결합해 Blackwell(GB200 NVL72) 하드웨어에서 7배 처리량 향상을 측정했다(GTC 2026 발표).

vLLM은 2026년 4월 공식 블로그를 통해 분리 추론 설정 가이드를 공개했다. 현재 v0.8.0 이상에서 NIXL 및 LMCache 커넥터가 공식 지원된다.

vLLM 설정 핵심 파라미터

1P1D(1 Prefill, 1 Decode) 기본 구성 예시.

Prefill 노드 기동

vllm serve meta-llama/Llama-3-70b-instruct \
  --port 8100 \
  --max-model-len 16384 \
  --kv-transfer-config '{"kv_connector": "NixlConnector",
                          "kv_role": "kv_producer"}'

Decode 노드 기동

vllm serve meta-llama/Llama-3-70b-instruct \
  --port 8200 \
  --max-model-len 16384 \
  --kv-transfer-config '{"kv_connector": "NixlConnector",
                          "kv_role": "kv_consumer",
                          "kv_ip": "<prefill_node_ip>",
                          "kv_port": 14579}'

라우터 (별도 프로세스로 배포)

vLLM은 공식 disaggregated 라우터 구현체를 제공한다. 요청을 Prefill 노드로 보내고, Prefill 완료 시 Decode 노드로 전달하는 역할을 한다.

최신 연구 동향 (2026년 7월 기준)

분리 추론 방식도 여전히 발전 중이다.

부분 분리(Intra-GPU disaggregation, arXiv:2507.06608 "Nexus"): 단일 GPU 안에서 Prefill과 Decode를 시간 분할하는 방식. 추가 GPU 없이 간섭을 줄이는 접근이다.

멀티턴 편향(PPD, arXiv:2603.13358): 멀티턴 대화에서 Turn 2 이상의 요청은 Decode 노드로 직접 편향시킨다. 짧은 후속 입력에 Prefill 노드 왕복을 생략해 TTFT를 단축한다.

부하 인식 편향(arXiv:2607.02043): Prefill 노드 부하 상태를 실시간으로 보고, 바쁜 Prefill 노드 대신 Decode 노드에서 직접 Prefill을 처리하는 유연한 편향 방식이다.

운영자를 위한 판단 기준

분리 추론이 유리한 조건

Co-located 서빙이 더 적합한 조건

도입 전 확인사항

이 아키텍처를 한 문장으로 요약하면

Prefill-Decode 분리 추론은 LLM 서빙의 두 단계가 서로 다른 하드웨어 병목을 가진다는 사실을 인프라 설계에 반영한 것이다.

2026년 상반기에 주요 프로바이더들이 동시에 이 방향으로 전환한 것은, 단일 GPU 풀에서의 간섭이 규모가 커질수록 피할 수 없는 문제임을 보여준다. 운영 복잡도가 올라가는 것은 맞지만, 그 복잡도가 TTFT와 TBT를 독립적으로 제어할 수 있는 능력과 교환된다.

References