요약
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 연산 특성이 다르다.
| 특성 | Prefill | Decode |
|---|---|---|
| 연산 패턴 | 대규모 행렬 곱 (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를 동시에 맞춰야 할 때, 집약도 분리도 굿풋을 최대화하지 못한다.
🔶 TPOT 느슨
✅ TPOT 빡빡
TaiChi 아키텍처: 차별화 GPU 인스턴스 + 슬라이더
TaiChi의 핵심 설계는 두 종류의 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