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

논문 링크

강점과 독창성, 핵심 알고리즘, 그리고 한계

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

📌 결론 요약

논문 ‘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을 통해 재샤딩 비용까지 효과적으로 줄입니다.

✅ 논문의 주요 기여

⚙️ 핵심 알고리즘: 동적 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)

🧠 논문의 독창성

⚠️ 한계점 및 제약

1. 재샤딩 오버헤드 존재

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

2. 메모리 사용 증가

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

3. 복잡한 아키텍처 구성

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

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

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

핵심 알고리즘을 예시로 따라가기

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

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

✅ 핵심 알고리즘 구성 요약

🎯 예시로 본 알고리즘 동작 (모델: 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 (버퍼 꽉 차면 전환) ─┘

🧠 정리

실험 결과와 다른 방법론과의 차이

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

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

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

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

🏆 특출난 점 (Compared to other methods)

📌 성능 개선을 유도한 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 환경에서 실질적인 성능 개선을 입증한 점이 산업적 가치가 큽니다.

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

입력 데이터와 추론 과정, 모델 구조와 자원 요구량

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

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

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

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

📌 예시 입력 (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. 모델 아키텍처 구성

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

모두 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가 병목

🧾 정리 요약

✅ 결론

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

한계를 넘으려는 연구 흐름

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

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

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

🔍 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 통합

🧠 종합 정리

📌 마무리 생각

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

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

좋은 질문입니다. 이 질문은 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)

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

📌 실행 예시 비교

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

Case 2: Decode with 128 steps

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

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

🧠 정리

• 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 오버헤드를 어떻게 완화하는지, 실제 추론 처리 과정에 따라 구체적으로 설명할 수 있는가?

아주 좋은 질문입니다. 이 질문은 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 급감

개선된 방식:

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

📊 효과: 병목 완화

📌 실제 추론 예시

환경:

• 시퀀스 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 손실 없이 대량 처리 가능

🧠 정리 요약