Duplex: A Device for Large Language Models with Mixture of Experts, Grouped Query Attention, and Continuous Batching

논문 링크

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

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

📌 결론 요약

논문 *“Duplex: A Device for Large Language Models with Mixture of Experts, Grouped Query Attention, and Continuous Batching”*은 저연산량(Op/B)이 지배적인 MoE 및 GQA 기반 LLM 추론을 위한 하드웨어 아키텍처 Duplex를 제안하며, GPU 단독 대비 최대 2.67×의 추론 속도와 42.03%의 에너지 절감 효과를 보여줍니다. 핵심은 xPU (GPU 수준 고성능 연산기)와 Logic-PIM (로직 다이에 탑재된 저 Op/B 특화 연산기)를 동시에 활용하여 MoE와 Attention Layer를 공동 처리(co-processing)하는 방식입니다.

📘 논문의 강점 및 독창성

⚙️ 핵심 알고리즘 및 구조 예시로 설명

🔧 예시 입력 조건

• 모델: Mixtral-47B, MoE Layer의 expert 수 \( N_{ex} = 8 \), top-2 routing
• 요청 수: 4개 (Req0~Req3), 각 요청의 토큰 수: 512
• Attention: GQA (deg_grp = 4)
• Stage: decoding-only

① Expert Co-processing 과정

② Attention Co-processing 과정

• Prefill vs Decoding 요청 분리:
  • Prefill Attention: 고 Op/B → xPU
  • Decoding Attention: 저 Op/B → Logic-PIM
• 각 헤드는 별도 KV 공유 없이 독립 → request-level 병렬성 + head-level 병렬성 활용

📈 실험 결과 요약 (정량적 수치)

⚠️ 한계점 및 고려사항

✅ 정리

Duplex는 LLM의 연산량 불균형(Op/B 기반)에 최적화된 하드웨어-알고리즘 동시 설계 사례로, 특히 MoE+GQA+Continuous batching 조합에서 GPU 대비 확연한 성능 및 에너지 효율 개선을 달성합니다. 향후 이러한 hybrid device 설계가 GPU 대체 혹은 보완 구조로 점점 중요해질 가능성이 크며, Logic-PIM의 실리콘 구현이나 프레임워크 통합에 대한 후속 연구가 기대됩니다.

필요하다면 주요 Figure나 Table의 시각화 정리, 각 하드웨어 구성 요소별 UML/구조도 등도 도와드릴 수 있어요. 추가 요청 주세요.

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

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

Duplex 논문의 핵심 알고리즘은 “expert and attention co-processing”입니다. 이는 LLM의 Mixture-of-Experts (MoE) 및 Grouped-Query Attention (GQA) 계층에서 xPU와 Logic-PIM을 동시에 사용하여 연산을 병렬 처리하는 방식입니다. 이 알고리즘을 단순히 Layer 분리 수준이 아니라 fine-grained 수준에서 co-processing하는 것이 논문의 핵심 기여입니다.

✅ 개념 정리: Co-processing이 필요한 이유

이로 인해 기존 GPU는 연산량(Op/B)이 낮은 이 Layer들에서 11% 이하 활용률, 낮은 throughput, 높은 지연과 에너지 낭비 문제 발생.

🧠 핵심 아이디어: Expert & Attention Co-processing

구조

• xPU: GPU 수준 연산장치 (고 Op/B 전용)
• Logic-PIM: DRAM logic die에 탑재된 연산기 (저 Op/B 전용)

각 Layer의 연산량(Op/B)에 따라 적절한 연산기로 분배하여 병렬 수행 (co-processing)

📌 예시 기반 전체 프로세스 설명

🧪 입력 조건 (Mixtral 모델 기준)

• Batch size: 4개 요청 (Req0 ~ Req3)
• 각 요청 토큰 수: 512
• MoE layer: 8 experts, top-2 선택
• Attention: GQA (deg_grp=4)
• Stage: Mixed (Req0~2는 decoding, Req3는 prefill)

① MoE Co-processing - 예시 기반 단계

1. Gate Projection 실행 (xPU)

   • 각 토큰이 top-2 experts 선택됨
   • 예:
     • Req0: 토큰 512개 중 → Expert 0: 120개, Expert 1: 80개
     • Req1: Expert 0: 90개, Expert 2: 100개 등

2. Expert별 토큰 수 계산
   → Expert별로 처리할 토큰 수 상이함 → 불균형 발생

3. 작업 분배 (정책 기반)

   • xPU: 많은 토큰 할당된 expert (e.g., Expert 0, 2, 5)
   • Logic-PIM: 적은 토큰 expert (e.g., Expert 1, 3, 6)

4. 연산 수행

   • 각 연산기에서:
     • Up-Projection (GEMM)
     • Activation (e.g., SiLU)
     • Down-Projection (GEMM)

5. 결과 합산 (xPU)

   • 각 Logic-PIM과 xPU가 계산한 output을 all-reduce하여 최종 MoE output 생성
   • 이 단계는 xPU가 수행함

✅ 이 방식은 토큰 수 불균형을 활용해 각 연산기의 utilization을 높임

② Attention Co-processing - 예시 기반 단계

1. Request 분류

   • Req3 (Prefill): Q 512개 / KV 512개 → GEMM, Op/B 높음
   • Req0~2 (Decoding): Q 1개씩 / KV 많음 → GEMV, Op/B 낮음

2. 연산기 분배

   • Prefill attention: xPU
   • Decoding attention: Logic-PIM

3. Attention 계산

   • GQA이므로 각 group head는 동일한 KV를 공유 → DRAM 접근량 절감
   • 각 request 간 독립 → Logic-PIM에서 Request-level 병렬, Head-level 병렬 수행

🔄 알고리즘 흐름 요약 (혼합 스테이지 기준)

[Input] → Embedding → LayerNorm
   ↓
[MHA/GQA] → Logic-PIM (decoding) + xPU (prefill)
   ↓
[MoE Layer]
   ├─ Expert 0, 2, 5 → xPU
   └─ Expert 1, 3, 6 → Logic-PIM
   ↓
[AllReduce (MoE output)] → xPU
   ↓
[Projection, Residual, LayerNorm] → xPU

🔄 속도 향상을 위한 추가 기술: Lookup Table 기반 Expert 분배

• 사전에 각 expert에 대해 “n개 토큰 처리 시 xPU/Logic-PIM 소요 시간”을 측정하여 LUT 구축
• 실시간 실행 시:
  • 각 expert별 토큰 수 집계
  • 최소 실행 시간 조합을 탐색하여 분배
• 이 방식은 overhead가 negligible 수준

🧩 정리

이 알고리즘은 앞으로 MoE 기반 LLM이 점점 커지면서 단일 GPU로는 감당하기 어려운 low Op/B 연산을 효율적으로 처리하기 위한 핵심 기술이 될 수 있습니다.

필요하시면 LUT 구성 방식, 또는 expert 분배 알고리즘의 의사코드 수준으로도 풀어드릴 수 있어요.

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

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

좋습니다. Duplex 논문은 Mixture-of-Experts (MoE), Grouped Query Attention (GQA), 그리고 Continuous Batching으로 구성된 최신 LLM 환경에서 GPU가 가진 낮은 연산 활용률과 메모리 병목 문제를 해결하고자 xPU + Logic-PIM 기반 이기종 연산 구조를 제안합니다. 이 구조로 기존 GPU 및 기타 PIM 기반 구조 대비 탁월한 성능/에너지 효율을 달성하였습니다.

📊 논문에서 제시한 주요 실험 결과

🔁 평가 모델: Mixtral, GLaM, Grok1, LLaMA3, OPT
⚙️ 테스트 조건: (Lin, Lout) ∈ [256–4096], Batch size ∈ [32–128]

🧩 어떤 방식이 이런 성능 향상을 이끌었는가?

1. 💡 Logic-PIM 아키텍처 설계

• 기존 PIM (e.g., Bank-PIM, BankGroup-PIM)은 DRAM 다이에 연산 유닛을 직접 집적하여 Op/B < 1 수준에 특화
• 논문은 “Op/B 1~32” 수준이 실제 MoE, GQA 연산에 해당됨을 관찰 → 기존 PIM 비효율
• Logic-PIM은 DRAM 아래 Logic die에 고성능 연산 유닛을 배치하고 TSV를 증설하여 고대역폭 연결

→ 결과:
연산 밀도는 낮고 메모리 접근량이 많은 Layer (MoE, GQA)를 PIM이 효율적으로 분산 처리

2. 🔀 Expert / Attention Co-processing

• 기존 방식은 Layer 단위로 연산 분배함 (GPU ↔ PIM)
• Duplex는 Fine-grained 연산 분배:
  • MoE: Expert별 토큰 수에 따라 GPU ↔ Logic-PIM에 분할 배정
  • Attention: Prefill은 GPU, Decoding은 Logic-PIM으로 분리

→ 결과:
✔️ 연산 리소스 활용률 증가
✔️ Co-processing을 통해 병렬 처리로 latency 감소
✔️ batching 효과 손실 없이 throughput 증가

3. 📈 연산량 (Op/B)에 따른 스케줄링 최적화

• 각 layer의 Op/B를 동적으로 측정하여:
  • Op/B ↑: GPU(xPU)
  • Op/B ↓: Logic-PIM

예시:

• GQA (deg_grp = 4~8): Op/B ≈ 4~8 → Logic-PIM이 적합
• MoE (top-k=2, Nex=64): Op/B ≈ 1~5 → Logic-PIM 대상
• FC Layer: Op/B ≫ 32 → GPU 대상

4. 🔄 Continuous Batching 구조 최적화

• Continuous batching은 request를 stage 단위로 lock-step batching 처리
• Decoding-only stage가 전체의 80% 이상
  ⇒ Op/B 낮음 ⇒ Logic-PIM을 활용한 빠른 처리 효과적

🧠 저자의 주장 vs 나의 해석

🔬 다른 방법론과 차별점 요약

✅ 결론 요약

Duplex의 뛰어난 성능은 단순히 하드웨어 추가 때문이 아니라,
🔹 Op/B-aware 연산 분배 전략,
🔹 intra-layer 수준의 fine-grained co-processing,
🔹 HBM logic die를 활용한 Logic-PIM 구조 설계,
🔹 그리고 continuous batching에 최적화된 실행 스케줄링
이 유기적으로 작동한 결과입니다.

“단순히 더 많은 연산 자원을 사용하는 것이 아니라, 더 똑똑하게 분산하고 배치하는 것”이 Duplex가 특출난 이유입니다.

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

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

좋습니다. 이 논문에서 다루는 Duplex 구조는 LLM 추론 (inference)의 연산 병목을 해결하기 위한 하드웨어적 접근이며, 논문 전반에서 Mixtral, GLaM, Grok1 같은 MoE 기반 디코더-중심 LLM 구조를 대상으로 성능을 분석합니다. 아래는 예시 기반으로 입력 데이터와 추론 경로, 그리고 모델 아키텍처 구조 및 각 연산의 메모리·컴퓨팅 요구량을 상세하게 설명한 내용입니다.

1. 🧪 예시 기반 입력 데이터와 추론 경로

📌 예시 설정

2. 🧠 모델 아키텍처 구성 (MoE + GQA 기반 디코더)

▼ 구조 요약

[Embedding]
   ↓
[Decoder Block × N]  ← 32~80 layers
   ├── LayerNorm
   ├── Grouped Query Attention (GQA)
   ├── Residual Add
   ├── MoE Layer (Gate + FFN experts × N_ex)
   └── Residual Add
[LM Head]

3. 🔄 추론 과정 상세 예시

▶ Stage 1: Prefill (Req3)

• 입력: 512개 토큰

• 수행 내용:

  1. Token → Embedding vector (FP16, e.g., 4096-dim)
  2. Embedding → GQA → Key, Value → KV cache로 저장
  3. GQA 결과 + Residual → MoE → FFN 결과 합산
  4. 최종 hidden → LM Head → 다음 token 생성 (첫 token)

• 특이점:

  • GQA: K/V는 512개의 context 토큰에서 만들어짐
  • Q는 512개의 토큰 → GEMM 형태
  • Op/B: 높음 (~16) → xPU에서 처리

▶ Stage 2: Decoding (Req0~2)

• 입력: 이전 단계의 마지막 token (1개)

• 수행 내용:

  1. 1-token → Embedding → 1×4096 벡터
  2. Q만 새로 생성 + 이전 KV와 Attention 수행 (GQA)
  3. MoE Layer: 각 token → top-2 experts 선택 → FFN 통과
  4. LM Head에서 다음 token 생성

• 특이점:

  • Q: 1개 token → K/V는 기존 512개와 매칭 → GEMV 형태
  • MoE는 분기돼서 병렬 expert 처리 (토큰마다 다른 expert)
  • Op/B: 낮음 (~1~4) → Logic-PIM에서 처리 효율적

4. ⚙️ 각 연산별 요구 자원 분석

※ d: hidden dim (예: 4096), d_int: intermediate dim (예: 14336), V: vocab size (예: 50K)

5. 📦 Memory 요구량 (in decoding stage)

6. ⚡ Computing 요구량 (per stage)

→ 연산량 자체는 prefill이 크지만, 전체 요청 수 대비 decoding-only stage가 80% 이상을 차지
→ Op/B 낮은 decoding 단계에서 Logic-PIM이 매우 유효함

✅ 정리

한계를 넘으려는 연구 흐름

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

좋습니다. Duplex 논문은 Logic-PIM과 xPU의 연산 특성을 활용하여 LLM의 MoE+GQA 구조를 고속으로 추론하는 뛰어난 설계입니다. 그러나 여전히 몇 가지 설계적/시스템적 한계를 가지고 있으며, 이를 극복하기 위한 후속 연구 흐름을 정리해보면 다음과 같습니다.

✅ 1. 한계 요약 및 대응 연구 흐름

🔍 2. 관련 후속 연구 흐름 상세

🔸 A. Reinforcement Learning 기반 Co-processing Scheduler

• 문제: 현재 Duplex는 LUT 기반으로 처리기를 정적 할당
• 대안: DeepRL을 활용해 각 stage의 Op/B, batch size, latency SLA 등을 state로 받아서 전문가, attention 연산의 분배 결정을 강화학습으로 학습
• 예시:
  • Action: expert 0~7 중 Logic-PIM에 할당할 subset
  • Reward: TBT latency 감소량, throughput 증가량

🔸 B. DRAM-aware Memory Allocation

• Duplex는 Bank Bundle 분할을 통해 xPU와 Logic-PIM 병렬 접근을 보장하지만, bank-level conflict는 런타임 복잡도를 유발

• 대응 연구:

  • DRAM-aware allocators: allocation 시 bank/index-aware placement
  • Compile-time placement: expert weight, KV cache 등을 bank bundle index 기준으로 mapping

🔸 C. KV 캐시 압박 대응 (PagedAttention 등)

• 논문에서 언급한 방식:

  • Cache가 넘치면 migration to CPU memory or recomputation

• 대응 흐름:

  1. PagedAttention (Yu et al., OSDI’23):
     • 캐시를 CPU에 페이징하고 필요시 GPU로 스와핑
     • swap 비용을 latency SLA 기반으로 조절
  2. Sparse-KV Cache:
     • 일부 Layer의 KV만 저장하고 나머지는 recompute
     • LRU 기반 eviction 등 가능

🔸 D. Unified Reconfigurable Architecture (PIM-XPU Fusion)

• 문제: xPU, Logic-PIM이 고정된 역할만 수행
• 대응:
  • Elastic Processing Pool 형태로 하나의 연산기를 MoE or Attention or FC에 할당 가능
  • 예시: Tile-based processing unit (TPU/TPGRA 스타일), 동적으로 연산기 재구성

🔸 E. Weight Duplication 회피

• Splitwise 등 시스템은 prefill/decoding 분리 구조로 MoE weight 중복
• 대안 흐름:
  • Expert weight streaming (on-demand load)
  • Expert compression: quantized format 저장 후 필요시 decompress
  • Expert recomputation: decoder layer를 recompute하고 weight는 저장하지 않음 (activation-based replay)

🔸 F. Expert Skew 대응

• Switch Transformer (Fedus et al., 2021)에서 언급된 문제

  • Gate가 특정 expert에 집중 → GPU load imbalance

• 대응 기술:

  • Balanced Router: top-k 선택 시 diversity 보장 (e.g., entropy regularization)
  • Load-aware gating: 전문가의 current load를 반영하여 Gate Softmax 조정
  • Token Re-routing: 예측 단계에서 라우팅을 수정하여 Skew 완화

📌 정리: Duplex의 확장을 위한 연구 흐름 지도

 ┌──────────────┐
 │ Duplex 구조  │
 └────┬─────────┘
      ▼
┌───────────────────────────────────────────────┐
│ 1. Co-processing Sched. → Reinforcement-based │
│ 2. Memory mapping        → DRAM-aware runtime │
│ 3. KV Cache 문제         → PagedAttention, SparseCache │
│ 4. Weight duplication     → Streaming, Recomputation │
│ 5. Expert skew            → Balanced Router / Load-Aware Gate │
│ 6. Elastic HW 활용        → Reconfigurable / Unified PIM │
└───────────────────────────────────────────────┘

✅ 마무리

Duplex는 우수한 하드웨어 구조와 알고리즘을 설계했지만, 실시간 부하 변화, 불균형 expert 트래픽, 메모리 스케줄링 복잡성, 캐시 압박 등은 여전히 미해결 과제로 남아 있습니다. 이에 대한 연구는 동적 실행환경 적응성과 스케일러블 모듈성이라는 두 축을 중심으로 발전하고 있으며, 앞으로의 LLM serving 시스템에서 필수 요소로 자리잡을 것입니다.

물론입니다. Duplex 논문을 깊이 있게 이해하기 위해 다음 세 가지 질문을 중심으로 생각해보시면 매우 효과적입니다. 복사 붙여넣기 쉽게 포맷했습니다.

Q : Duplex는 왜 기존 PIM 구조(예: Bank-PIM, BankGroup-PIM)보다 Logic-PIM 구조를 선택했으며, 이 구조가 실제로 MoE와 GQA 연산에서 어떤 방식으로 Op/B 효율성과 연산 병렬성을 개선하는가?

좋은 질문입니다. 이 질문은 Duplex 논문의 설계 근거와 아키텍처 선택이 성능에 어떤 영향을 주었는지를 깊이 파악하는 핵심입니다. 아래에서 논문 내용과 함께 제 해석을 통합하여 정리하겠습니다.

✅ 왜 기존 PIM(Bank-PIM, BankGroup-PIM)이 아닌 Logic-PIM인가?

1. 기존 PIM 구조의 한계

• DRAM die에 연산기를 내장하면 면적, 공정, 발열 측면에서 scaling이 매우 제한적
• 대부분의 LLM 연산(MoE FFN, GQA)은 Op/B가 1~32 범위에 위치 (논문 Fig. 4b Roofline 참고)
• Bank-PIM은 low Op/B 연산에서는 좋지만, MoE나 GQA처럼 연산 밀도가 조금만 올라가면 연산기 병목 발생

2. Logic-PIM 구조의 장점

(1) 연산 밀도 (Op/B)

• Logic-PIM은 연산기를 DRAM logic die에 배치
• 논문 기준 Logic-PIM은 GEMM 연산에서 Op/B가 8~32인 경우 가장 낮은 EDAP (energy-delay-area product)를 기록 (논문 Fig. 8)

(2) 연산 확장성

• TSV (Through Silicon Via) 밀도를 증가시켜 logic die ↔ DRAM die 간 내부 대역폭을 4× 향상
• 이로 인해 DRAM bandwidth 병목 없이 연산기를 더 많이, 더 빠르게 사용 가능

(3) 연산 병렬성 확보

• DRAM bank bundle 단위로 병렬 read 수행
• 각 Logic-PIM unit은 독립적으로 GEMM, softmax, activation 처리 가능
• → MoE expert 간 병렬성, attention head/request 간 병렬성을 그대로 활용

⚙️ MoE와 GQA 연산에서 Logic-PIM의 구체적 역할

1. MoE Layer (Top-k FFN)

• 각 토큰은 top-2 expert로 라우팅됨 → 각 expert의 처리 토큰 수는 상이
• Logic-PIM은 적은 토큰을 할당받은 expert를 처리, xPU는 많은 토큰 expert를 처리 (expert co-processing)
• 각 Logic-PIM에서:
  • Up-Projection (GEMM)
  • Gated Activation
  • Down-Projection (GEMM)
• 이후 xPU에서 all-reduce로 결과 병합

→ token-level imbalance를 활용한 병렬 분산 실행

2. GQA Layer (Grouped Query Attention)

• GQA는 deg_grp개의 head가 K/V를 공유
• decoding 단계의 attention 연산은 GEMV 형태 (낮은 Op/B)
• Logic-PIM은 request-level, head-level 병렬로 각 attention 연산을 수행

→ GQA 연산의 메모리 접근량이 높고 연산량이 적은 특성을 잘 맞춤

📊 성능 수치 요약 (논문 결과)

🧠 결론 및 제 해석

Duplex는 기존 PIM 구조가 근본적으로 가지는 공정 제약, 연산기 확장 한계, 메모리 병목 문제를 피하기 위해 Logic-PIM을 채택했습니다. 이 구조는:

• MoE와 GQA처럼 낮지만 1 이상인 Op/B 연산에 가장 잘 맞고,
• 병렬성과 bandwidth 모두를 고려한 연산기 설계 전략이라는 점에서 매우 현실적이며,
• 향후 TSV 기반 logic-in-memory 설계의 상용화 가능성을 보여주는 모델로 평가할 수 있습니다.

필요하시면 Logic-PIM의 DRAM 다이 구조나 연산 경로를 그림으로 도식화해서 설명드릴 수도 있어요.

Q : Expert와 Attention Co-processing에서 각 연산을 xPU와 Logic-PIM에 어떻게 동적으로 분배하고, 이 과정에서 연산량 불균형(Token 수 차이, GQA 구조 등)을 어떻게 활용하여 성능을 높이는가?

이 질문은 Duplex의 핵심 설계 아이디어를 깊이 이해하는 데 매우 중요합니다. Duplex는 단순히 Layer를 처리 유닛에 정적으로 배정하는 것이 아니라, MoE와 Attention 연산을 Fine-grained 수준에서 xPU와 Logic-PIM에 동적으로 분배하여 연산 병렬성과 리소스 활용률을 극대화합니다.

✅ 개념 요약: Expert & Attention Co-processing

1. 🧠 Expert Co-processing: MoE Layer 처리

💡 왜 필요한가?

• MoE는 입력 토큰마다 top-k experts (보통 2개)를 선택
• 실시간 request에서 각 expert가 처리하는 token 수가 비대칭적 (skewed)
  → 어떤 expert는 100개, 어떤 expert는 10개 처리
• Logic-PIM은 낮은 Op/B에서 효율적이지만, 처리 능력이 제한적
  → 큰 expert는 xPU, 작은 expert는 Logic-PIM에 분산

📦 분배 알고리즘

1. Gate-projection FC를 통해 각 토큰 → top-2 expert 라우팅
2. 각 expert가 맡은 token 수를 집계
3. 논문이 제안한 LUT 기반 연산 시간 추정표를 사용:
   • 각 expert 처리 시간 (token 수 기준) in xPU vs Logic-PIM
4. 목표: 전체 실행 시간이 최소가 되도록 expert를 할당

✨ 성능 향상 요인

• 모든 expert를 xPU에서 처리하면 load imbalance로 xPU under-utilization
• 모든 expert를 Logic-PIM에서 처리하면 연산 병목 발생
• 적절히 분배하면 MoE Layer 실행 시간 최대 1.36× 단축, throughput 최대 2.67× 상승

2. 🔄 Attention Co-processing: GQA 처리

💡 왜 필요한가?

• Attention layer는 prefill vs decoding 단계별로 Op/B 차이가 큼
  • Prefill: 전체 토큰 사용 → Op/B 높음 (GEMM)
  • Decoding: 토큰 1개 vs KV 전체 → Op/B 낮음 (GEMV)

📦 분배 정책

• Q/K/V 생성은 공통적으로 xPU에서 수행
• Logic-PIM은 request-level, head-level 병렬 처리로 Attention 연산

✨ 성능 향상 요인

• Attention layer는 전체 추론에서 latency 병목 요소 중 하나
• Decoding 단계에서 대부분의 시간 소비됨 → Logic-PIM을 통해 latency 58.3% 감소

3. 🔀 분배 시 고려되는 “연산량 불균형"의 활용

A. Expert skew

• 실제 상황: 특정 expert에 token이 몰림 (e.g., expert 0이 전체 token의 30% 차지)
• → 가장 토큰이 많은 expert들만 xPU에 할당
• token 수 기준 정렬 → 상위 N개를 xPU에 할당하고 나머지는 Logic-PIM에서 처리

B. GQA 구조의 그룹화 특징

• deg_grp = 4~8로 구성되면 KV 공유 증가 → 연산 Op/B 증가
• Prefill의 GQA는 deg_grp 단위 GEMM → xPU에 적합
• Decoding은 Q 1개 → GEMV → Logic-PIM이 오히려 적합

🧪 실험 결과로 본 효과

✅ 결론 요약

Duplex는 단순한 계층 분할이 아닌, 토큰 수 기반 Expert 분배 + 요청 유형 기반 Attention 분할이라는 fine-grained Co-processing 전략을 도입합니다. 이 전략은 다음을 실현합니다:

• 연산 리소스 활용률 극대화
• MoE 및 GQA에서 발생하는 불균형을 적극 활용
• 낮은 latency와 높은 throughput을 동시에 달성

필요하시면 이 Co-processing 알고리즘을 의사코드나 그림으로 시각화해서 정리해드릴 수도 있어요.

Q : Duplex 아키텍처는 continuous batching 기반 LLM 추론에 최적화되어 있다고 주장하는데, 구체적으로 어떤 시나리오나 실험 결과가 이러한 주장의 근거가 되며, 반대로 어떤 조건에서 이 구조가 비효율적일 수 있는가?

Duplex가 Continuous Batching 기반 LLM 추론에 최적화되어 있다는 주장은 논문 전체에서 반복적으로 강조되는 핵심입니다. 이를 뒷받침하는 구체적인 시나리오와 실험 결과를 정리하고, 반대로 Duplex가 비효율적일 수 있는 조건도 함께 분석해보겠습니다.

✅ Duplex가 Continuous Batching에 최적화된 이유

📌 Continuous Batching 이란?

• LLM inference를 prefill (전체 입력) + 반복 decoding (토큰 생성) 단계로 분리
• 기존처럼 request-level이 아닌 stage-level batching 적용
• 새로운 request가 오면 mixed stage로 포함시켜 wait time 감소, throughput 극대화

1. 📈 실험 결과 기반 정량적 근거

A. Stage 비중 분석 (논문 Fig. 5a)

→ 대부분의 연산이 decoding-only stage에서 발생하며, 이 구간이 low Op/B 연산 위주로 구성됨
→ Logic-PIM 최적 적용 대상

B. Throughput & Latency 성능 향상 (논문 Fig. 11, 12, 13)

→ continuous batching에서 dominant stage인 decoding-only를 Logic-PIM으로 빠르게 처리함으로써
→ 전체 system-level latency와 throughput을 동시에 향상시킴

C. 실시간 요청 시나리오 (Fig. 13, QPS 실험)

• QPS (Queries per Second) 증가에 따른 latency 변화

→ 낮은 TBT 유지 + 높은 최대 처리량(QPS) 보장
→ Duplex는 Continuous Batching 환경에서의 serving 안정성도 우수

2. 💡 Continuous Batching 구조와 Duplex 설계의 Alignment

⚠️ Duplex가 비효율적일 수 있는 조건

1. Prefill 중심 요청 비중이 높을 때 (e.g., 단발형 Q&A)

• Continuous Batching의 이점이 크지 않음 → 대부분 mixed stage
• Prefill 연산 (GQA, FC 등)은 high Op/B → GPU가 더 효율적

→ 이 경우 Duplex의 Logic-PIM 리소스가 놀거나 under-utilized 될 수 있음

2. Expert 간 토큰 분포가 균등할 때

• Co-processing은 expert 간 load imbalance를 활용하는 구조
• 모든 expert가 같은 수의 토큰을 처리하는 경우 → 병렬 분배 어려움 → xPU 단일 처리와 유사

→ Co-processing 이점이 희석됨

3. Sequence length가 너무 짧은 경우

• Op/B 자체가 높아지고, KV 캐시도 적어져 Logic-PIM 활용 가치가 낮아짐
• DRAM TSV 확장, Logic-PIM area overhead 대비 성능 향상이 적음

→ Duplex의 구조적 투자 대비 실익이 줄어듦

✅ 정리

Duplex는 continuous batching에서 decoding-only stage가 성능 병목이 되는 구조적 특성을 정확히 포착하여,

• Logic-PIM으로 low Op/B 연산을 처리하고
• Co-processing으로 xPU와 동시 활용을 통해
  → latency + throughput + 에너지 효율을 동시에 끌어올리는 아키텍처입니다.

하지만, prefill 비중이 과도하게 높거나, token 분포가 균등하거나, sequence가 짧은 경우에는 Duplex의 구조적 장점이 약화될 수 있습니다.

결론적으로 Duplex는 “LLM Serving 환경에서 대화형 continuous generation 추론에 최적화된 구조”라고 평가할 수 있습니다.

필요하시면 Duplex가 비효율적인 조건에서 어떻게 구조를 개선할 수 있을지도 제안해드릴 수 있어요.