LLM WikiAccess-protected knowledge portal
← 스터디 홈
101편 · 약 15분

TaiChi: PD 집약과 분리를 통합해 균형 SLO에서 처리량을 77% 높이는 LLM 서빙 아키텍처

요약

LLM 서빙 엔지니어에게 오랫동안 남아 있던 질문이 있다. Prefill-Decode(PD)를 같은 GPU에서 처리해야 하는가(집약), 아니면 다른 GPU로 분리해야 하는가(분리)? 수년 간의 논쟁은 "상황에 따라 다르다"는 결론으로 수렴했다. 집약은 TTFT(첫 토큰 지연)가 빡빡할 때 유리하고, 분리는 TPOT(토큰 생성 속도)가 중요할 때 유리하다. 균형 SLO, 즉 TTFT와 TPOT를 모두 일정 수준 이하로 유지해야 할 때는 어느 쪽도 최적이 아니었다.

TaiChi(arXiv:2508.01989)는 이 딜레마를 정면으로 다룬다. 집약과 분리를 선택하는 대신, 두 방식을 하나의 통합 아키텍처 안에서 병행하면서 SLO 조건에 따라 스스로 조정한다. 핵심 아이디어는 Latency Shifting — SLO를 이미 충족한 요청에서 자원을 빼 위험에 처한 요청으로 옮기는 것이다.

  • 균형 TTFT·TPOT SLO 조건에서 최대 77% 처리량(굿풋) 향상
  • 기존 최선 단일 방식 대비 뚜렷한 격차
  • arXiv:2508.01989 · 2026년 8월 공개

배경: 집약과 분리가 서로 다른 SLO에서 최선인 이유

Prefill 단계(입력 프롬프트 처리)와 Decode 단계(토큰 생성)는 GPU 연산 특성이 다르다.

특성PrefillDecode
연산 패턴대규모 행렬 곱 (compute-bound)소규모 반복 조회 (memory-bound)
GPU 활용높음 — 배치 프롬프트를 한번에 처리낮음 — 토큰 하나씩 반복 생성
요청 간 간섭Prefill이 길면 다른 요청의 Decode 지연Decode 부하가 많으면 다음 Prefill 지연

PD 집약: TTFT가 빡빡할 때 유리

동일 GPU에서 Prefill과 Decode를 함께 처리하면, Prefill이 완료되자마자 같은 GPU에서 Decode가 시작된다. KV 캐시 전송이 없으므로 TTFT는 짧다. 반면 Decode 단계가 Prefill과 경쟁하므로 TPOT가 늘어날 수 있다.

PD 분리: TPOT가 중요할 때 유리

Prefill 전용 GPU와 Decode 전용 GPU를 나누면 Decode 단계에서 Prefill의 간섭이 사라진다. TPOT는 개선되지만, Prefill 완료 후 KV 캐시를 Decode GPU로 전송해야 하므로 TTFT가 증가한다.

균형 SLO: 어느 쪽도 최적이 아닌 영역

실제 서비스에서 TTFT와 TPOT를 동시에 맞춰야 할 때, 집약도 분리도 굿풋을 최대화하지 못한다.

PD 집약
✅ TTFT 빡빡
🔶 TPOT 느슨
❌ TTFT+TPOT 균형
PD 분리
🔶 TTFT 느슨
✅ TPOT 빡빡
❌ TTFT+TPOT 균형
TaiChi
✅ TTFT 빡빡
✅ TPOT 빡빡
✅ TTFT+TPOT 균형: +77%
집약·분리·TaiChi의 SLO 영역별 최적성

TaiChi 아키텍처: 차별화 GPU 인스턴스 + 슬라이더

TaiChi의 핵심 설계는 두 종류의 GPU 인스턴스를 정의하는 것이다.

TaiChi 통합 PD 아키텍처 TaiChi 스케줄러 Latency Shifting 엔진 슬라이더 기반 자원 조정 요청 유입 Prefill-Heavy 클러스터 빠른 프리필 · KV 캐시 전송 허용 Prefill 처리 (대규모 행렬 곱) 높은 GPU 활용률 · 청크 크기 ↑ Decode 보조 (간섭 허용) SLO 여유 있을 때만 실행 Length-Aware Prefill Scheduling Decode-Heavy 클러스터 낮은 간섭 디코드 · KV 캐시 수신 Decode 처리 (토큰 생성) TPOT 최적화 · 메모리 대역폭 ↑ Prefill 보조 (느린 처리 허용) Decode 여유 있을 때만 실행 Flowing Decode Scheduling KV 캐시 전송 (PH→DH) 슬라이더 3개: PH 비율 · DH 비율 · KV 전송 최대치 SLO 체계에 따라 자동 또는 수동 조정
TaiChi 통합 아키텍처: Prefill-Heavy와 Decode-Heavy GPU 클러스터

Prefill-Heavy(PH) 인스턴스

  • 주 역할: Prefill 처리. 대규모 배치로 묶어 행렬 곱 효율을 높인다.
  • 부 역할: Decode도 실행하지만, Prefill과의 간섭을 허용한다. SLO 여유가 있는 Decode 요청이 이 인스턴스에 배치된다.
  • 특징: 청크 크기를 키워 연속 배치 효율을 극대화한다.

Decode-Heavy(DH) 인스턴스

  • 주 역할: Decode 처리. Prefill 간섭 없이 TPOT를 최소화한다.
  • 부 역할: Prefill도 실행할 수 있지만 속도가 느리다. TPOT에 여유가 생길 때만 배치한다.
  • 특징: 메모리 대역폭 최적화. KV 캐시 조회 성능에 집중한다.

슬라이더 3개

슬라이더조정 대상효과
PH 비율전체 GPU 중 PH 인스턴스 비중TTFT 타이트할수록 PH 비율↑
DH 비율전체 GPU 중 DH 인스턴스 비중TPOT 타이트할수록 DH 비율↑
KV 전송 최대치PH→DH 간 KV 캐시 전송 허용량전송 대역폭 포화를 막는 안전 밸브

핵심 메커니즘: Latency Shifting

TaiChi의 가장 독창적인 기여는 Latency Shifting 개념이다.

왜 필요한가

트래픽이 불균일한 상황을 생각해보자. 어떤 시점에 TPOT가 SLO를 겨우 지키는 요청들이 있고, 동시에 TPOT에 여유가 있는 요청들이 함께 실행 중이다. 기존 시스템은 이 여유를 활용하지 못한다.

Latency Shifting은 여유 있는 요청에서 GPU 시간 슬롯을 빌려, 위험에 처한 요청에 재할당한다. 이때 여유 있는 요청의 TPOT가 약간 증가하더라도 전체 SLO 달성 요청 수(굿풋)는 늘어난다.

두 가지 스케줄링 메커니즘

1. Flowing Decode Scheduling (TPOT 제어)

Decode 단계의 처리량은 배치 크기에 크게 영향받는다. Flowing Decode Scheduling은 Decode 요청을 배치로 묶을 때 TPOT 여유를 실시간으로 계산해, 여유 있는 요청을 느린 배치에 포함하는 방식으로 흐름을 조절한다. "흐름을 조절한다(flowing)"는 이름은 여기서 나왔다.

2. Length-Aware Prefill Scheduling (TTFT 제어)

프롬프트 길이는 TTFT에 직접적인 영향을 준다. 짧은 프롬프트는 빠르게 처리되므로 TTFT 여유가 크다. Length-Aware Prefill Scheduling은 프롬프트 길이를 기준으로 우선순위를 동적으로 조정해, TTFT 위험 요청을 먼저 처리하고 여유 있는 요청을 뒤로 미룬다.

두 메커니즘의 상호작용

요청 A: TTFT 위험, TPOT 여유
  → Length-Aware Prefill이 우선 처리
  → TTFT 위험 해소

요청 B: TTFT 여유, TPOT 위험
  → Flowing Decode가 빠른 배치 배정
  → TPOT 위험 해소

요청 C: TTFT 여유, TPOT 여유
  → 여유분을 A, B에 재분배 (Latency Shifting)
  → 전체 굿풋 증가

두 메커니즘은 독립적으로 동작하는 것이 아니라, 전체 굿풋을 최대화하는 공동 목표 아래 조율된다.


성능 결과

균형 SLO에서 77% 굿풋 향상

비교 대상굿풋 (균형 SLO 기준)
TaiChi+77% (최고 기준선 대비)
PD 집약기준선
PD 분리기준선 ±유사
Chunked Prefill기준선보다 소폭 향상

TTFT-빡빡 SLO에서는 TaiChi가 PD 집약에 수렴한다. TPOT-빡빡 SLO에서는 PD 분리에 수렴한다. 두 조건이 균형을 이룰 때 격차가 최대 77%로 벌어진다.

슬라이더 조정에 따른 자동 적응

실험에서 TaiChi는 TTFT가 지배적인 SLO 체계에서 PH 비율을 자동으로 높이고, TPOT가 지배적이면 DH 비율을 높인다. 이 자동 적응이 "슬라이더 기반 통합"의 핵심 가치다.


운영 시사점: 언제 TaiChi가 필요한가

지금 당장 달라지는 것은 없다

arXiv 논문 단계이므로 vLLM이나 SGLang에 즉시 배포할 수 있는 구현은 아직 없다. 하지만 TaiChi가 제시하는 설계 원칙은 지금도 유효하다.

운영 결정에 적용할 수 있는 TaiChi의 통찰

1. SLO를 먼저 정의하라

TaiChi가 풀려는 문제의 전제는 TTFT와 TPOT를 별개의 SLO로 명시하는 것이다. 단순히 "응답이 빠르면 좋다"는 수준의 목표는 어떤 PD 전략이 최적인지 결정하는 데 아무 도움이 안 된다.

  • 챗봇 인터페이스: TTFT < 1초, TPOT < 100ms — TTFT 우선 → PD 집약 또는 TaiChi PH 비중↑
  • 배치 코드 생성: TTFT < 10초, TPOT < 50ms — TPOT 우선 → PD 분리 또는 TaiChi DH 비중↑
  • 에이전트 루프: TTFT < 3초, TPOT < 80ms — 균형 → TaiChi 하이브리드

2. GPU 동질성을 가정하지 마라

TaiChi의 PH/DH 구분은 클라우드 환경에서 이미 실행 가능하다. Prefill에 적합한 인스턴스(compute-bound GPU)와 Decode에 적합한 인스턴스(memory-bandwidth GPU)를 별도로 프로비저닝하면, TaiChi의 원리를 수동으로 적용할 수 있다.

3. Chunked Prefill 설정을 워크로드에 맞게 조정하라

TaiChi의 Length-Aware Prefill Scheduling의 핵심 파라미터 중 하나는 청크 크기다. vLLM의 --enable-chunked-prefill--max-num-batched-tokens를 워크로드의 평균 프롬프트 길이에 맞게 튜닝하면 TTFT 개선 효과를 지금도 볼 수 있다.


요점 정리

TaiChi의 핵심 메시지는 단순하다. 집약과 분리는 선택이 아니라 스펙트럼이다. 어느 한 방식을 전체 클러스터에 강제하는 대신, GPU 인스턴스 유형 비율을 조절하면서 SLO 조건에 맞춰 지속적으로 최적점을 찾는 것이 더 나은 전략이다.

균형 TTFT·TPOT SLO에서 77%라는 수치는 단순한 성능 숫자가 아니다. 이 격차는 지금까지의 PD 전략 논쟁이 잘못된 이분법 위에 있었음을 보여준다.


References

  • arXiv:2508.01989 — "Prefill-Decode Aggregation or Disaggregation? Unifying Both for Goodput-Optimized LLM Serving" (2026.08)
  • arXiv:2401.09670 — DistServe: 원조 PD 분리 제안 논문
  • arXiv:2507.06608 — Nexus: 인트라-GPU PD 분리 (2026.07)
  • arXiv:2508.06133 — LLM Serving Optimization with Variable Prefill and Decode Lengths (2026.08)
  • vLLM Chunked Prefill 문서: https://docs.vllm.ai/en/latest/features/chunked_prefill.html
  • SGLang 공식 문서: https://sgl-project.github.io