Seesaw: High-throughput LLM Inference via Model Re-sharding

작성일 | In , , |

논문 링크

Q : 이 논문을 아주 자세하게 읽고 논문의 강점과 독창적인 지점을 설명해주고 핵심 알고리즘을 예시 입력을 들어서 전체적인 과정을 설명해줘 추가적으로 논문의 한계점에 대해서도 알려줘

A :

📌 결론 요약

논문 ‘Seesaw: High-throughput LLM Inference via Model Re-sharding’은 LLM의 두 주요 단계인 prefill과 decode에서 병렬화 전략을 동적으로 변경하는 ‘model re-sharding’ 기법을 제안하여, 평균 1.36배, 최대 1.78배의 추론 처리량 개선을 달성합니다. 이 방식은 기존 vLLM처럼 고정된 병렬화 전략에 비해 throughput 최적화를 달성하며, tiered KV cache buffering과 transition-minimizing scheduling을 통해 재샤딩 비용까지 효과적으로 줄입니다.

✅ 논문의 주요 기여

구분 내용
문제점 prefill과 decode는 성격이 달라 동일한 병렬화 전략 사용 시 비효율 초래
해결책 병렬화 전략을 단계별로 동적으로 조정 (model re-sharding)
추가 기법 - tiered KV cache buffering (CPU 메모리 보조 저장소 사용)
- transition-minimizing scheduling (stage 전환 최소화)
효과 vLLM 대비 평균 1.36×, 최대 1.78× throughput 향상

⚙️ 핵심 알고리즘: 동적 Model Re-sharding 과정 예시

🔧 예시 입력

  • LLM: LLaMA2-13B
  • 시스템: 8 × L4 GPU (PCIe 연결)
  • 입력 요청 수: 16개
  • 병렬화 전략: prefill에 pipeline parallelism (PP4), decode에 tensor parallelism (TP4)

🔄 전체 추론 처리 흐름

  1. Prefill 단계 (PP4 적용):

    • 입력 전체 시퀀스가 GPU 4대에 pipeline 형태로 분배됨
    • 모델 레이어도 순차적으로 각 GPU에 나뉘어 처리
    • 통신 오버헤드 작음, weight loading 효율적임

  2. KV 캐시 생성 및 CPU로 오프로드:

    • 각 GPU는 자신의 shard KV를 CPU 공유 메모리에 저장

  3. 모델 weight와 KV cache 재샤딩:

    • pipeline 구조로 나뉘었던 모델 weight → tensor 구조로 재배치
    • KV 캐시도 TP 구조로 재분배됨 (CPU→GPU 비동기 전송)

  4. Decode 단계 (TP4 적용):

    • 모든 GPU가 동일 weight shard로 병렬 처리
    • 한 토큰씩 생성 → GPU 간 AllReduce 통신 발생
    • weight loading 병렬 처리로 효율성 극대화됨

  5. 비동기 처리 및 stage 전환 최적화:

    • CPU→GPU KV 전송은 prefetch thread로 비동기 수행
    • KV가 꽉 찰 때만 decode로 전환하여 재샤딩 횟수 최소화

📈 성능 비교 (vLLM vs Seesaw)

환경 모델 vLLM (req/s) Seesaw (req/s) 속도 향상 배수
A10, 4GPU 15B 1.0 (기준) 1.45 +45%
L4, 4GPU 15B 1.0 1.29 +29%
A100 (PCIe), 8GPU 70B 1.0 1.46 +46%
A100 (NVLink), 8GPU 70B 1.0 1.13 +13%

🧠 논문의 독창성

항목 Seesaw의 차별점
병렬화 전략 stage 별로 병렬화 전략을 바꿀 수 있도록 설계 (TP ↔ PP)
Re-sharding overhead 처리 CPU를 중간 저장소로 활용한 tiered buffering 도입
Scheduling 최적화 transition-minimizing scheduler 설계
적용 유연성 기존 시스템(vLLM, TensorRT-LLM)에도 쉽게 통합 가능

⚠️ 한계점 및 제약

  1. 재샤딩 오버헤드 존재

    • CPU↔GPU 사이의 데이터 이동은 여전히 병목 가능성 있음
    • 해결을 위해 비동기 prefetching 사용하지만 하드웨어 의존도 높음

  2. 메모리 사용 증가

    • CPU, GPU 모두에서 KV cache를 보관해야 하므로 더 많은 메모리 요구

  3. 복잡한 아키텍처 구성

    • worker-scheduler 구조와 동기화 필요로 인해 시스템 구현 복잡도 증가

  4. online-serving 환경에서는 덜 적합

    • offline throughput 중심 설계 → latency 민감한 시스템에는 부적절

Q : 논문의 핵심알고리즘을 예시를 들어 아주 자세하게 설명해주고 정리해 줘

A :

논문 **“Seesaw: High-throughput LLM Inference via Model Re-sharding”**의 핵심 알고리즘은 다음 3가지 구성 요소로 요약됩니다:

✅ 핵심 알고리즘 구성 요약

구성 요소 역할
1. Dynamic Model Re-sharding Prefill 단계에선 Pipeline Parallelism (PP), Decode 단계에선 **Tensor Parallelism (TP)**을 사용하도록 모델 weight와 KV cache의 병렬화 전략을 동적으로 변경
2. Tiered KV Cache Buffering GPU 메모리 한계를 극복하기 위해 CPU 메모리를 활용하여 KV cache를 임시 저장
3. Transition-Minimizing Scheduling 자주 stage를 오가는 transition overhead를 줄이기 위해 일정 시점(버퍼가 가득 찼을 때)까지만 prefill 수행 후 decode로 전환

🎯 예시로 본 알고리즘 동작 (모델: LLaMA2-13B, GPU 4대 사용)

예시 입력

  • 총 요청: 16개의 sequence
  • Prefill 병렬화 전략: PP4 (Pipeline Parallelism with 4-way split)
  • Decode 병렬화 전략: TP4 (Tensor Parallelism with 4-way split)

🔄 전체 알고리즘 플로우

① Prefill 단계: Pipeline Parallelism 적용

  • 모델 레이어를 GPU 4개에 순차적으로 나눠서 배치 (L/4 레이어씩).
  • 16개의 시퀀스를 micro-batch로 나눠서 파이프라인에 투입.
  • 각 시퀀스는 한 번에 여러 토큰을 처리하므로 GPU compute 자원을 잘 활용함.
  • 이때 생성된 KV Cache는 GPU에 저장하지 않고 CPU 메모리로 오프로드함.
[GPU1] L1 | [GPU2] L2 | [GPU3] L3 | [GPU4] L4
       ↓         ↓         ↓         ↓
Sequence 1 → Sequence 2 → ... → Sequence 16

→ 각 시퀀스별 KV 캐시가 CPU 메모리에 저장됨

② KV Cache Tiered Buffering: GPU→CPU로 KV 이동

  • KV 캐시는 각 GPU에서 로컬 shard로 계산된 후 CPU 공유 메모리에 저장됨
  • HND(H, N, D) 포맷으로 저장 → TP에서 head 축 기준으로 효율적 접근 가능
  • CPU 메모리는 KV 캐시를 완전히 담을 수 있을 때까지 계속 채움

③ Model Re-sharding: 모델 weight 재구성

  • Prefill이 끝나면 다음 단계인 decode를 위해 model weight의 sharding 방식을 TP4로 변경
  • TP는 모든 GPU가 같은 레이어를 분산 계산하는 방식이므로, weight를 TP 기준으로 재배치해야 함
  • 기존 PP에서 분할된 weight를 CPU에서 다시 불러와 GPU에 TP 방식으로 로드

④ Decode 단계: Tensor Parallelism 적용

  • KV 캐시는 CPU로부터 GPU로 비동기적으로 로드됨 (prefetch thread 사용)
  • GPU들은 동일한 layer 전체를 병렬로 처리하며 토큰을 한 개씩 생성 (auto-regressive)
  • TP는 weight가 GPU간 분산되어 있어 한 번만 로딩해도 여러 시퀀스 처리 가능
  • 대량의 시퀀스를 동시에 처리 가능하여 throughput 극대화
[GPU1] --- TP → Layer Computation (1/4)
[GPU2] --- TP → Layer Computation (1/4)
[GPU3] --- TP → Layer Computation (1/4)
[GPU4] --- TP → Layer Computation (1/4)

→ CPU에서 KV shard를 받아서 TP 방식으로 Decode 수행

⑤ Transition-Minimizing Scheduling

  • 전환 조건: CPU KV cache가 가득 찼을 때만 prefill → decode로 전환
  • decode 중에는 prefetch thread가 미리 KV를 옮겨 놓음 → compute와 comm overlap
  • 이렇게 하면 frequent reshards를 방지하면서도 decode throughput을 유지

📌 전체 동작 흐름 요약 다이어그램

[시작] → Prefill(PP) → KV Cache(CPU에 저장) → Model Re-shard(TP) → Decode(TP) → 끝
            ↑                                                   ↓
            └─────── Transition-minimizing (버퍼 꽉 차면 전환) ─┘

🧠 정리

단계 병렬화 전략 장점 단점
Prefill Pipeline Parallelism 낮은 통신 비용, 토큰 병렬 처리 micro-batch overhead
Decode Tensor Parallelism 빠른 weight loading, 높은 throughput AllReduce 통신 비용
KV 저장 Tiered Buffering GPU 메모리 한계 극복 CPU↔GPU 전송 속도 병목
스케줄링 Transition-Minimized re-shard 횟수 최소화 복잡한 스케줄러 로직 필요

Q : 이 논문에서 제시한 결과를 자세하게 보고 다른 방법론에 비하여 특출난 점과 논문에서 제기하는 어떠한 방법이 이러한 결과를 도출하게 되었는지 논문에서 제시하는 이유와 너의 생각을 알려줘

A :

논문 Seesaw: High-throughput LLM Inference via Model Re-sharding은 다양한 하드웨어 및 모델 설정에서 SOTA 추론 엔진인 vLLM 대비 최대 1.78×, 평균 1.36×의 throughput 향상을 보여줍니다. 이 성과는 단일 병렬화 전략에 고정된 기존 엔진들과 차별되는 **동적 병렬화 전략 조합 (PP + TP)**과 transition-aware scheduling 덕분입니다.

📊 Seesaw 성능 결과 정리 (논문 6장 기준)

모델 GPU vLLM Throughput Seesaw Throughput 개선 배수 설명
LLaMA3-15B 4 × A10 1.0 (baseline) 1.45 +45% chunked prefill 조합보다 우수
CodeLLaMA-34B 8 × A10 1.0 1.78 +78% prefill/decoding stage 분리로 이득 극대화
LLaMA2-70B 8 × A100 PCIe 1.0 1.46 +46% TP에서 발생하는 all-reduce 병목 완화
LLaMA2-70B 8 × A100 NVLink 1.0 1.13 +13% NVLink 환경에서도 여전히 개선 확인

※ chunked prefill을 사용한 vLLM (TP2+PP2) 대비 Seesaw가 우수하다는 점은 눈여겨볼 포인트입니다.

🏆 특출난 점 (Compared to other methods)

비교 대상 한계 Seesaw의 우수한 점
vLLM 단일 병렬화 전략만 사용 가능 (ex. TP-only, PP-only) stage별 병렬화 전략 동적 변경 (PP → TP)
DistServe / Mooncake (분리 배치 기반) prefill/decode 처리량 불균형, resource 낭비, GPU duplication 같은 리소스 내에서 stage 간 병렬화 방식 전환
Chunked Prefill (Sarathi, DeepSpeed-FastGen) chunk 사이 decode-only 단계 발생, 최적 chunk size 찾기 어려움 prefill과 decode를 완전히 분리하여 더 큰 batching 가능
기존 hybrid parallelism 병렬화 방식 조합은 고정적이고 stage-aware가 아님 Seesaw는 각 stage별 최적 병렬 전략을 동적으로 선택

📌 성능 개선을 유도한 Seesaw의 방법론과 논문 내 근거

1. Dynamic Model Re-sharding

  • 근거: prefill은 communication-bound → pipeline이 유리, decode는 weight-loading-bound → tensor가 유리
  • 논문 실험: Figure 1, Figure 3, 12에서 보여지듯 각각의 병렬화 방식이 stage에 따라 유불리가 다름
  • 내 생각: 기존 LLM inference 프레임워크는 통일된 병렬화 방식을 사용해 suboptimal 전략으로 성능을 낭비했음. Seesaw는 이런 “병렬화 전략 선택 문제”를 stage-aware 관점에서 재정의한 점이 혁신적.

2. Tiered KV Cache Buffering

  • 근거: GPU 메모리 한계를 CPU 메모리로 offload 하여, prefill 시 대규모 시퀀스를 처리 가능
  • 논문 실험: Figure 6, 7에서 Tiered KV 캐시 구조 및 swap-in/out 동작 설명. GPU에 decode 캐시를 미리 prefetch함
  • 내 생각: 이 구조 덕분에 GPU에서 “prefill batching → decode batching” 간에 병목 없이 부드럽게 넘어갈 수 있음. 특히 PCIe 환경에서는 필수적

3. Transition-minimizing Scheduling

  • 근거: frequent reshards는 오버헤드 유발 → decode 전환은 CPU 버퍼가 가득 찼을 때만 발생
  • 논문 실험: Figure 2(a~c), ablation 실험 (Section 6.3)에서 re-shard 횟수 줄이면서도 decode throughput 유지됨
  • 내 생각: 기존 scheduling은 latency 최소화를 중심으로 설계되어 throughput에는 적합하지 않았음. Seesaw는 이를 오히려 throughput-maximizing 관점에서 재설계한 점이 강력한 차별점.

🧠 추가 분석 및 한계

  • Seesaw는 ‘offline batch inference’에는 탁월하지만 ‘interactive online’ inference에는 latency 증가 위험 존재

    • decode batch가 충분히 커야 성능 이점이 극대화됨

  • re-shard의 CPU↔GPU 전송이 NVLink 없을 경우 bottleneck이 될 수도 있음

    • 논문에서도 PCIe vs NVLink 성능 차이를 분명히 제시 (A100 실험에서 46% → 13%로 감소)

🔚 결론

Seesaw는 “LLM 추론 단계별로 병렬화 전략을 맞춤 최적화”한다는 개념을 최초로 고안하고, 이를 tiered memory + intelligent scheduler와 결합하여 기존 추론 시스템들의 단점을 해결한 설계입니다. 특히 대규모 오프라인 처리, resource constraint 환경에서 실질적인 성능 개선을 입증한 점이 산업적 가치가 큽니다.

한 줄 요약: 단순한 병렬화 조합이 아니라, “언제” 그 병렬화 전략을 쓰느냐가 중요하다는 점을 실험과 이론 모두에서 강력히 입증한 논문입니다.

Q : 이 논문의 입력데이터와 추론 과정에 대해서 예시를 들어 아주 자세하게 설명해 주겠니? 추가적으로 모델아키텍처의 구성 및 모델을 구성하는 연산과 메모리 요구량 컴퓨팅 요구량 대해서도 설명해줘

A :

좋습니다. 아래는 논문 Seesaw의 전체 입력–추론–모델 구조–리소스 사용에 대한 상세 설명입니다. 예시와 함께 단계별로 구성했습니다.

🧪 1. 입력 데이터 구조 및 예시

논문에서는 두 가지 대표적인 throughput-oriented inference workload를 사용했습니다:

데이터셋 설명 Input 길이 Output 길이
ShareGPT 대화 기록 기반 32~256 토큰 32~512 토큰
arXiv summarization 논문 요약 태스크 최대 3000 토큰 32~128 토큰

📌 예시 입력 (arXiv summarization 기반)

{
  "input": "In this paper, we propose a novel model...",
  "max_output_tokens": 128
}

→ 하나의 sequence가 만들어지고, inference 시스템에는 다음과 같이 요청이 들어갑니다:

  • prompt length = 2048 tokens
  • max decode length = 128 tokens
  • 총 1 sequence = 2048 + 128 = 2176 tokens (단, decode는 1 token씩 step-by-step 생성)

🧠 2. 추론(inference) 과정의 단계별 처리

Seesaw는 inference를 다음 두 단계로 나누어 처리합니다.

▶ Step 1: Prefill 단계

  • **모든 입력 토큰(2048개)**을 한 번에 transformer로 forward pass 함.
  • 각 attention layer에서 **Query, Key, Value(QKV)**를 계산하고, KV는 캐시로 저장됨.
  • 병렬화 전략: Pipeline Parallelism (PP) 적용 → 레이어를 여러 GPU에 분산.

▶ Step 2: Decode 단계

  • 토큰을 1개씩 반복적으로 생성함 (auto-regressive).
  • 이전 단계에서 저장한 KV 캐시를 사용하여 Q와 Attention만 계산
  • 병렬화 전략: Tensor Parallelism (TP) 적용 → weight sharding 및 AllReduce.

🔄 전체 예시 추론 흐름

입력: 2048 토큰 논문 텍스트 → [Prefill with PP4]
→ 각 GPU는 일부 레이어만 담당 (ex. 4개 레이어 중 GPU1: L1, GPU2: L2 ...)
→ Q, K, V 계산 → KV는 CPU에 저장

→ [Transition & re-shard to TP4]
→ Decode 시작: 토큰 1개 생성 → 다음 토큰 생성 ...
→ 반복적으로 CPU에서 KV를 GPU로 가져와 decode

🏗️ 3. 모델 아키텍처 구성

논문 실험에는 다음 모델이 사용됩니다:

모델명 크기 아키텍처
LLaMA3 15B GQA 기반 decoder-only
CodeLLaMA 34B GQA 기반 decoder-only
LLaMA2 70B GQA 기반 decoder-only

모두 transformer decoder-only 구조로 되어 있으며, 핵심 구성은 아래와 같습니다:

🔹 한 Layer 구성

  1. LayerNorm
  2. Multi-head Attention (QKV 계산, GQA 구조)
  3. Residual Add
  4. FeedForward Network (2~4× hidden size)
  5. 또 다른 LayerNorm + Residual

⏱️ 4. 연산량 및 메모리 요구량 분석

1) Prefill 단계:

  • 연산량:

    • Attention: O(n²d) → n은 sequence length, d는 hidden dim
    • FFN: O(n·d²)

  • 메모리:

    • Activations + KV Cache 모두 필요
    • GPU당 model weight shard + 중간 활성값 저장

  • 병목:

    • **Communication (AllReduce)**보다 computation이 우세 (이유: 긴 시퀀스)
    • → PP가 유리

2) Decode 단계:

  • 연산량:

    • Attention: O(n·d) (n은 과거 토큰 수 → 증가)
    • FFN: O(d²)

  • 메모리:

    • GPU 메모리당 KV Cache 저장 필요
    • Activations는 매우 작음 (1 step)

  • 병목:

    • weight loading 및 broadcasting
    • → TP가 유리 (shard로 나눠서 weight 사용 가능)

📦 실제 계산 예 (LLaMA2-70B 기준)

  • 모델 파라미터 수: 70B
  • hidden dim: 약 8192
  • layer 수: 80
  • FFN 비율: 4× → FFN dim ≈ 32768

⛽ 추론 연산량 (1개 시퀀스)

  • Prefill (2048 토큰):

    • Attention: 2048²×8192 ≈ 34B FLOPs/layer
    • FFN: 2048×8192×32768 ≈ 549B FLOPs/layer
    • 전체: (34B + 549B) × 80 layers = 46.8 TFLOPs

  • Decode (128 steps):

    • 각 step에서 Attention + FFN = ~6.5B FLOPs/layer
    • 전체: ~6.5B × 128 × 80 = 66.5 TFLOPs

→ decode는 step-by-step이지만 전체 FLOP 합산은 prefill보다 많음 → 하지만 병렬성이 낮아, 실제 throughput에선 prefill이 빠름, decode가 병목

🧾 정리 요약

항목 Prefill Decode
병렬화 전략 Pipeline (PP) Tensor (TP)
처리 단위 Prompt 전체 (수천 토큰) 1 토큰 반복
계산량 매우 큼 (O(n²)) 작음 (O(nd))
병목 통신 (AllReduce) weight loading
캐시 없음 → 생성 KV cache 활용
최적화 PP가 효율적 TP가 효율적

✅ 결론

이 논문에서 처리하는 입력 데이터는 평균적으로 수천 토큰의 prompt + 수백 토큰의 생성으로 구성되어 있으며, 이 구조적 특성을 반영하여 prefill과 decode의 병렬화 전략을 다르게 적용하는 것이 핵심입니다. Seesaw는 이 차이를 정확히 분석하고, 동적 re-sharding + 계층적 캐시 + 스케줄링으로 이를 효과적으로 구현했기에, 기존 static-parallelism 방식 대비 탁월한 throughput 향상을 이뤘습니다.

Q : 이 논문의 한계를 극복하기 위한 방법으로 어떤 연구흐름이 있는지 정리해서 자세하게 설명해 줘

A :

논문 **“Seesaw: High-throughput LLM Inference via Model Re-sharding”**은 고정 병렬화 전략의 비효율성을 극복했지만, 여전히 시스템적, 알고리즘적 한계점이 존재합니다. 이에 따라 이 한계를 극복하려는 후속 연구 흐름은 크게 4가지 방향으로 발전하고 있습니다:

✅ 요약: 한계점과 대응 연구 흐름

Seesaw의 한계점 대응하는 연구 흐름 핵심 아이디어
① 빈번한 re-sharding overhead Layer-level Adaptive Re-sharding 세분화된 weight migration, 또는 re-shard-free execution
② CPU ↔ GPU 간 KV cache 전송 병목 KV Cache Compression & Prefetch Optimization 압축 + 비동기 prefetch의 최적화
③ offline inference 전용 → online에는 부적합 Latency-aware Scheduling & Prefetching online + offline hybrid 처리 가능한 스케줄러
④ statically configured 병렬 조합 Reinforcement Learning 기반 Auto-parallelism 시점별 최적 병렬화 전략을 학습 기반으로 탐색

🔍 1. Re-sharding Overhead 완화: Adaptive Sharding

Seesaw의 한계

  • stage 간 전환 시 model weight, KV cache를 GPU 간 재배치해야 하며,
  • 이는 memory copy + data layout transformation이 필요하여 latency 증가

대응 연구

  • Splitwise (ISCA 2024): phase splitting 기법 제안

    • 한 번의 shard 재배치로 여러 단계 처리 가능하도록 layer 배치를 조정

  • Dynamic Layer Migration: 자주 변하지 않는 layer는 고정, 나머지만 shard 이동

미래 방향

  • layer-level granularity에서 sharding-free hybrid execution 설계
  • GPU-local한 KV cache reuse 방식 연구

🔍 2. KV 캐시 메모리 병목 극복: Compression & Scheduling

Seesaw의 한계

  • CPU에서 GPU로 KV cache를 옮길 때 **PCIe bandwidth (16GB/s 수준)**가 병목
  • 대량 시퀀스를 한번에 decode 시 prefetch가 제때 도착하지 않으면 stall 발생

대응 연구

  • FastDecoder (2024): 8-bit quantization을 적용한 KV 캐시 압축
  • NanoFlow (2024): swap-in/swap-out 타이밍을 token-level prefetch로 세분화
  • DistAttention (2024): multi-level attention cache hierarchy 제안 (L2-like KV cache)

미래 방향

  • LRU 기반 cache eviction 정책이 적용된 GPU KV cache 관리자
  • 압축률 ↔ latency tradeoff에 최적화된 adaptive 압축 알고리즘

🔍 3. 온라인/인터랙티브 환경 부적합 문제: Hybrid Scheduling

Seesaw의 한계

  • offline-only 시스템으로 설계됨 → prompt latency 고려 안 함
  • interactive workload (ex. chatbot)의 경우 delay가 증가할 수 있음

대응 연구

  • Sarathi-Serve (2024): chunked prefill과 decode를 섞는 piggyback scheduling
  • Slice-level Scheduling (Cheng et al., 2024): GPU 내 idle slice 단위로 prefill/decoding 분배

미래 방향

  • multi-objective scheduling (throughput + latency) 가능하도록 heuristic 스케줄러 고도화
  • request priority 기반 prompt-to-decode dispatch routing 시스템

🔍 4. 정적인 병렬화 구성의 한계: Auto-parallelism 탐색

Seesaw의 한계

  • 병렬화 조합 (PPx → TPy)은 사람이 실험적으로 찾음 → 최적화 불완전
  • workload distribution, token length, output ratio에 따라 최적 조합이 바뀜

대응 연구

  • AutoServe (가칭, 아직 미발표): workload 특성을 실시간으로 감지하여 병렬 조합을 조정
  • RL 기반 Controller: inference latency / throughput을 reward로 하는 병렬화 탐색기

미래 방향

  • token 길이, memory usage 예측 → 병렬화 전략을 동적으로 자동 적용하는 system compiler + scheduler 통합

🧠 종합 정리

카테고리 기존 한계 향후 보완 가능 방향
Re-sharding 통째 shard 이동 partial migration, layer-adaptive
KV cache PCIe 병목, 전송 지연 압축 + L2-style 캐시 계층화
Scheduling offline only, prefill-decode 고정 latency-aware, priority-aware hybrid
병렬화 전략 수동 튜닝 AutoML 또는 RL 기반 동적 조정

📌 마무리 생각

Seesaw는 확실한 구조적 기여를 했지만, 여전히 “통신/메모리 병목” 및 “실행 환경 다양성”에서 완전한 해법은 아닙니다. 위에서 정리한 후속 연구들은 Seesaw의 핵심 설계를 기반으로 더 정교하고 범용적인 고성능 추론 시스템으로 확장하고자 하는 흐름입니다.

Q : Seesaw에서 prefill과 decode 단계의 병렬화 전략을 각각 다르게 선택하는 것이 throughput 향상에 어떻게 기여하며, 이를 위해 어떤 조건에서 pipeline parallelism 또는 tensor parallelism이 유리한지 수식이나 실행 예시를 통해 설명할 수 있는가?

A :

좋은 질문입니다. 이 질문은 Seesaw의 핵심 설계철학인 **“단계별 병렬화 전략 분리”**가 왜 필요한가, 그리고 어떤 경우에 TP 또는 PP가 유리한가를 수학적이고 시스템적으로 설명할 수 있어야 합니다.

✅ 결론부터 말하면

Prefill 단계는 **pipeline parallelism(PP)**이 유리하고, Decode 단계는 **tensor parallelism(TP)**이 유리합니다.

Seesaw는 이 두 병렬화 전략을 stage별로 나눠서 적용하고, 이를 통해 전반적인 throughput을 1.36~1.78× 향상시킵니다.

🔍 왜 단계별로 병렬화 전략을 나눠야 할까?

▶ Prefill 단계의 특징:

  • Prompt 전체 시퀀스 (n ≈ 512~3000)를 한 번에 처리
  • Token 수가 많아서 연산량이 O(n²) (self-attention)
  • GPU compute 자원이 꽉 차게 활용됨 → communication이 병목

→ ⇒ compute-heavy + communication-bound → PP가 유리

▶ Decode 단계의 특징:

  • 1 token씩 순차 생성 → 연산량 적고 O(n) 수준
  • Token 수 적고, 반복적 → weight loading overhead가 상대적으로 큼
  • 작은 연산량 → load → compute → idle → load 반복됨

→ ⇒ memory-transfer-bound → TP가 유리

🧮 수식 기반 설명 (논문 Appendix A 기반)

논문에서는 다음과 같은 throughput inverse 모델을 제안합니다:

throughput⁻¹ ∝ T_linear_dm / TP + (T_attn_dm + T_comp) / (DP · TP · PP) + T_comm(TP) / (DP · PP)

항목 의미
T_linear_dm weight loading 시간
T_attn_dm KV cache 전송 시간
T_comp compute 시간
T_comm AllReduce 등 통신 시간

이 식에서 중요한 건 TP 증가 → T_linear_dm 감소 (→ TP는 decode에 좋음), 하지만 TP 증가 → T_comm 증가 (→ PP는 prefill에 좋음)

📌 실행 예시 비교

Case 1: Prefill with 2048 tokens (LLaMA2-13B)

전략 특징 예상 성능
TP4 weight loading은 빠름, 하지만 all-reduce 많음 ❌ 느림
PP4 레이어를 4 GPU에 나눠 순차 처리, 통신 적음 ✅ 빠름

Case 2: Decode with 128 steps

전략 특징 예상 성능
TP4 weight shard를 나눠 가짐 → 반복 loading 없이 처리 ✅ 빠름
PP4 매 step마다 pipeline 시작해야 하므로 오버헤드 큼 ❌ 느림

→ Seesaw는 prefill엔 PP, decode엔 TP를 각각 선택 → 최적 조합

📊 실험 결과로 본 실제 차이 (논문 Figure 12)

전략 Prefill 속도 Decode 속도 Total 시간
TP4 느림 빠름 느림
PP4 빠름 느림 느림
Seesaw(PP→TP) 빠름 빠름 ✅ 가장 빠름

🧠 정리

  • prefill은 계산량이 많고 all-reduce cost가 dominant → pipeline 병렬화로 통신 오버헤드 감소
  • decode는 연산량 적고 weight 반복 로딩이 병목 → tensor 병렬화로 weight shard 활용
  • Seesaw는 이를 runtime에서 stage-aware하게 판단하고, 동적으로 re-shard함으로써 throughput을 향상시킴

Q : Tiered KV cache buffering과 transition-minimizing scheduling이 어떻게 작동하며, 이러한 설계가 CPU↔GPU 전송 병목과 re-sharding 오버헤드를 어떻게 완화하는지, 실제 추론 처리 과정에 따라 구체적으로 설명할 수 있는가?

A :

아주 좋은 질문입니다. 이 질문은 Seesaw 논문의 성능 핵심 엔진인 Tiered KV Cache Buffering과 Transition-minimizing Scheduling의 작동 방식과 그 효과를 실제 흐름 중심으로 이해해야 답할 수 있습니다.

✅ 결론 요약

Tiered KV Cache Buffering은 CPU 메모리를 KV Cache의 보조 저장소로 사용하여 GPU 메모리 한계를 극복하고, Transition-minimizing Scheduling은 prefill↔decode 사이의 전환 빈도를 최소화하여 re-sharding 비용을 줄입니다.

이 두 설계는 CPU↔GPU 간 데이터 병목과 잦은 re-shard 비용이라는 두 가지 병목을 구조적으로 완화합니다.

🧠 왜 이 설계가 필요했는가?

기존 continuous batching 문제:

  • prefill과 decode를 번갈아 수행해야 하므로 → **stage 전환(re-sharding)**이 자주 발생

  • stage 전환마다:

    • model weight 재배치
    • KV cache re-sharding (layout 변경)
    • GPU↔CPU 데이터 이동

→ 전환이 잦을수록 전체 throughput은 급감 (Figure 2a 참조)

🔄 Tiered KV Cache Buffering: 어떻게 작동하는가?

기본 아이디어:

  • KV Cache를 GPU에 저장하지 않고 CPU 메모리에 Tiered 방식으로 저장
  • Prefill은 연속적으로 수행하고, 그 결과(KV)를 모두 CPU에 저장
  • Decode는 이 CPU 버퍼에서 필요한 KV만 비동기로 불러옴

실제 작동 흐름:

[Prefill Stage]
1. Input Sequence → Prefill 실행 (PP 방식)
2. 각 GPU가 자기 shard의 KV 계산
3. GPU→Pinned Memory→CPU Shared Memory 로 KV 캐시 저장

[Decode Stage]
4. Scheduler는 CPU buffer에서 decode용 시퀀스를 선택
5. Worker는 Prefetch Thread로 GPU에 필요한 shard만 비동기로 Load
6. Load 완료된 시퀀스부터 TP 기반 Decode 실행

핵심 장치: Shared CPU memory 구조를 활용하여 GPU 간 KV 이동 없이 재shard 가능

⏱️ Transition-minimizing Scheduling: 어떻게 작동하는가?

문제점

  • 기존 스케줄러는 decode가 끝나자마자 prefill 시작 → 매번 stage 전환
  • → weight 이동 + KV 캐시 이동이 너무 자주 발생 → throughput 급감

개선된 방식:

조건 스케줄러 동작
CPU KV 버퍼가 가득 찼을 때만 prefill → decode 전환
CPU KV 버퍼가 비었을 때만 decode → prefill 전환

→ 한번에 많은 시퀀스를 prefill한 후에 decode만 연속 수행함 → decode 수행 중에는 새 prefill을 하지 않음

📊 효과: 병목 완화

항목 기존 방식 Seesaw 방식
GPU memory 제한 decode 중 메모리 부족 발생 CPU로 분산 저장 가능
stage 전환 수 수백 회 가능 수십 회로 줄임
re-shard 시간 전환마다 발생 전환 횟수를 줄여 amortize
GPU idle 시간 frequent swapping continuous compute 가능

📌 실제 추론 예시

환경:

  • 시퀀스 128개
  • prefill: PP4, decode: TP4

스케줄 동작:

  1. Scheduler는 128개 시퀀스를 prefill stage로 연속 처리
  2. 각 시퀀스의 KV 캐시는 GPU → CPU로 이동
  3. CPU 버퍼가 가득 차면 prefill 중단 → re-shard 실행
  4. TP4로 모델 weight shard 재배치
  5. Worker는 CPU buffer에서 시퀀스 하나씩 GPU로 비동기 로딩
  6. decode가 끝난 시퀀스는 GPU에서 KV 해제
  7. CPU buffer가 다 비워지면 다시 prefill로 전환

→ 전환은 단 1회, throughput 손실 없이 대량 처리 가능

🧠 정리 요약

요소 효과
Tiered KV Buffering GPU 메모리 한계 극복, 대규모 prefill 가능
Transition-minimizing Scheduling re-shard 횟수 감소, 전체 처리량 증가
Prefetch Thread CPU→GPU 전송 지연을 compute와 overlap 처리
Shared Memory 기반 KV 캐시 TP/PP 간 re-shard를 빠르게 처리 가능