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

작성일 | In , , |

논문 링크

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

A :

📌 결론 요약

논문 “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)하는 방식입니다.

📘 논문의 강점 및 독창성

구분 설명
🎯 문제 정의 Continuous batching으로 인한 MoE/Attention Layer의 DRAM 접근량 증가와 낮은 Op/B로 인한 GPU 활용률 저하
🧠 독창적 접근 기존 PIM이 Op/B < 1 영역에 특화된 것과 달리, Op/B = 1~32 범위 최적화를 위한 Logic-PIM 제안
🔀 동시 처리 구조 Attention과 MoE layer를 Op/B 기반으로 xPU와 Logic-PIM에 동적 분배하여 활용도 극대화
🔄 Co-processing 방식 Expert 간 토큰 수 편차를 기반으로 expert-level parallelism, attention은 요청 단위로 병렬화
📊 성능 향상 H100 대비 평균 2.07× throughput 향상, 28.19% 에너지 절감, TBT 지연 최대 58.3% 감소

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

🔧 예시 입력 조건

  • 모델: 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 과정

단계 작업 설명
1 Gate-projection FC를 통해 각 토큰이 top-2 expert로 라우팅됨
2 각 expert가 처리할 토큰 수 집계됨: 예컨대 Expert 0이 80개, Expert 1이 30개 등
3 작업 분배: 토큰 수가 많은 Expert (예: 0, 2, 4)는 xPU, 적은 Expert (예: 1, 3, 5…)는 Logic-PIM에 할당
4 각 단위는 독립적으로 GEMM → 활성화 → down-projection 수행
5 down-projection의 partial sum은 xPU에서 all-reduce 수행 후 최종 MoE 출력 생성

② Attention Co-processing 과정

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

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

비교 대상 Throughput (tokens/s) TBT 지연 에너지 소비
GPU (H100) 1.0 (baseline) 1.0x 1.0x
Duplex 2.07× ↓58.3% ↓28.2%
Duplex+PE+ET 2.67× 최대 ↓60.2% 최대 ↓42.0%
2×GPU 1.76× 유사 ↑ 에너지 소비

⚠️ 한계점 및 고려사항

구분 설명
🧠 Expert skew dependency Co-processing 효과는 전문가 간 토큰 수 불균형이 있을 때 극대화됨. 균일 분포일 경우 효율 감소
🔁 KV cache 관리 긴 시퀀스 및 대형 배치 시 KV 캐시가 메모리 병목. PagedAttention 등의 캐시 이관 기법 필요
🔃 Prefill-Decode 분리 처리 Splitwise와 유사한 prefill/decoding 노드 분리 시 Throughput 하락 발생 (비효율적 weight 복제, 활용률 저하)
🔌 TSV 추가 및 PIM area overhead TSV와 로직 연산기 추가로 HBM3 logic die의 14.71% 면적 증가 발생 (하지만 기존 Bank-PIM 대비 작음)

✅ 정리

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

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

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

A :

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이 필요한 이유

Layer 특징 문제점 (GPU 기준)
MoE Layer Top-k Expert 선택 후 GEMM + activation 토큰이 각 Expert로 분산돼 Op/B가 낮음 (1~4 수준), 연산기 활용도 저조
Attention Layer (GQA) Grouped Head들이 공유된 KV로 Attention 요청마다 다른 KV → GEMV 연산 + DRAM 액세스 증가

이로 인해 기존 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 수준

🧩 정리

구성요소 기여
🔄 Co-processing 연산기 활용률 향상, Op/B 기반 계층 분할
⚖️ Expert 분배 Load balancing 기반 GPU + Logic-PIM 동시 활용
🔁 Attention 병렬 Request & Head 병렬화로 GQA 연산 최적화
🧠 LUT 기반 스케줄링 런타임 오버헤드 최소화하면서 최적화된 분배 결정

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

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

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

A :

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

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

비교 대상 Throughput 향상 TBT (p50) 감소 E2E Latency 감소 Energy 감소
GPU (H100) 기준선 (1.0×) 기준선 기준선 기준선
2× GPU (H100) 1.76× ↓ 낮음 ↓ 약간 감소 ✖ 증가
Duplex 2.07× ↓ 58.3% ↓ 60.2% ↓ 28.2%
Duplex+PE+ET 최대 2.67× ↓ 최대 58.3% ↓ 35~60% ↓ 42.03%

🔁 평가 모델: 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 나의 해석

항목 논문 설명 나의 해석
🎯 문제 정의 Continuous batching에서의 낮은 Op/B로 GPU 자원 미활용 타당함. 특히 decoding-only stage에서 대부분의 시간이 MoE/Attention에 소비됨
🚀 성능 향상 근거 Op/B 기반 device selection + co-processing 단순 Layer 이동이 아닌 intra-layer 분할이라는 점에서 큰 구조적 차별성 존재
⚙️ Logic-PIM 우수성 DRAM die 대신 logic die에 연산기 배치로 area 효율 및 Op/B 대응 범위 확장 TSV 밀도 증가를 효과적으로 활용했다는 점에서 실리콘 구현 관점에서도 설득력 있음
📉 경쟁 구조 대비 Bank-PIM은 Op/B 증가 시 성능 급감 실제 Mixtral 등 고 Op/B GQA 모델에서 Duplex가 압도적 우위 확보

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

항목 Duplex 기존 PIM (Bank-PIM 등) GPU only
Layer 처리 방식 Intra-layer Co-processing Layer offloading Full layer GPU 처리
Target Op/B 1–32 <1 제한 없음, 그러나 저 Op/B 비효율
하드웨어 위치 Logic Die (HBM 내부) DRAM Die 별도 SoC
Throughput 2.67× ~1.4–1.6× baseline
Latency ↓ 최대 60% ↓ 일부 감소 높음
Energy ↓ 28–42% 중간 높음
Weight Duplication 문제 없음 있음 없음

✅ 결론 요약

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

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

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

A :

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

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

📌 예시 설정

항목 값
Request 수 4개 (Req0 ~ Req3)
각 Request의 Input Length (Lin) 512 tokens
Output Length (Lout) 128 tokens
Model Mixtral-47B
MoE 구성 8 experts, top-2 선택
Attention Grouped Query Attention (deggrp = 4)
Stage Mixed stage (Req0~2: decoding, Req3: prefill)

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. ⚙️ 각 연산별 요구 자원 분석

연산 종류 설명 메모리 요구량 연산량 (FLOPs) Op/B (대략) 처리 위치
Embedding Token → vector Lin × dmodel negligible - xPU
QKV 생성 Linear FC ×3 O(B×d²) O(B×d²) 높음 (≥32) xPU
GQA Attention Q·KT → Softmax → V GEMV (1×d · d×seq) 낮음 1~8 Logic-PIM
MoE Gate FC + Top-k d→Nex, k=2 낮음 ~1 xPU
MoE FFN (Expert) FC1 → Act → FC2 B×2×dint×dmodel 높음 (조건부) 1~10 xPU/Logic-PIM 혼합
AllReduce (MoE output) expert별 partial sum 결합 bandwidth ↑ 낮음 - xPU
LM Head FC → vocab O(d×V) 매우 높음 ≥64 xPU

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

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

항목 요구량
KV Cache 2 × d × Lin × batch size × FP16 = 2×4096×512×4×2B ≈ 8MB
MoE expert weight 각 expert FFN: (FC1 + FC2) ≈ 2 × d × dint × Nex = 약 2GB
GQA weight WQ, WK, WV 공유되므로 전체 FC 연산용 가중치: 수십 MB

6. ⚡ Computing 요구량 (per stage)

Stage 유형 주요 연산 FLOPs (대략) 병목 Layer
Prefill GQA + MoE 1–2 TF xPU에서 집중 처리
Decoding-only GQA (GEMV) + MoE (GEMM) 수백 GF Logic-PIM에 최적

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

✅ 정리

항목 Duplex의 설계/알고리즘에서 어떻게 대응하는가
다양한 Op/B 계층 존재 GQA (Op/B 4–8), MoE (Op/B 1–10), FC (Op/B ≫ 32)
→ 연산기 할당 전략 Op/B에 따라 Logic-PIM vs xPU에 동적 분배
긴 sequence → KV cache ↑ KV 캐시를 bank bundle 단위로 분산 + migration 지원
Token 단위 processing 토큰별로 서로 다른 expert에 분기 → Fine-grained expert routing
Memory 대역폭 병목 DRAM die 대신 Logic die에 연산기 탑재 + TSV 확장으로 해결

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

A :

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

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

한계점 상세 설명 대응 연구 흐름
🎯 A. Co-processing 결정의 정적 정책 Token 수 기반 expert 분배는 미리 측정된 LUT에 의존함. → 동적 부하 변동이나 QoS에 민감하지 않음 🔹 Reinforcement Learning 기반 동적 expert scheduling
🔹 QoS-aware routing (e.g., latency-bound co-processing)
🔹 System-level runtime profiler 연동
🔄 B. Bank bundle 충돌 및 memory mapping overhead Logic-PIM ↔ xPU 간 병렬 접근 시 DRAM bank 충돌 가능성 있음 → 메모리 매핑 전략이 복잡함 🔹 Bank-aware compiler pass 또는 Placement-aware runtime
🔹 DRAM row/bank-aware memory allocator
🔁 C. KV Cache migration/recomputation overhead 긴 문장이나 대규모 배치 시 KV Cache가 DRAM을 초과하여 성능 저하 🔹 PagedAttention 방식 채택 (유닉스 OSDI’23)
🔹 Layer-wise KV compression, recomputation trade-off 연구
🔹 CPU-GPU-Disk 계층화된 캐시 관리
⚙️ D. Static hardware resource partitioning Logic-PIM과 xPU의 리소스를 정해진 연산 계층에만 사용 → under-utilization 가능 🔹 Elastic co-execution 구조 (범용 연산기를 동적 할당)
🔹 Resource Virtualization: on-demand PIM/XPU pooling
💾 E. Weight duplication 문제 (Splitwise와 유사) Prefill/decoding 분리를 위한 Layer weight 복제 시 메모리 낭비 발생 🔹 Weight offloading/streaming 구조
🔹 Expert weight eviction/cache 교체 방식 연구
🔹 On-the-fly expert recomputation (e.g., Code-MoE 구조)
🧠 F. Expert 선택 불균형 (Expert Skew) 실제 추론에서는 특정 Expert에 많은 토큰이 몰리는 현상 발생 🔹 Load-balanced MoE router (e.g., Switch-Router [Fedus’21])
🔹 Routing-aware scheduling (traffic-aware 토큰 분배)
🔹 Entropy-regularized gating function

🔍 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 효율성과 연산 병렬성을 개선하는가?

A :

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

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

1. 기존 PIM 구조의 한계

구조 연산기 위치 Op/B 타겟 범위 주요 한계
Bank-PIM DRAM bank 내부 < 1 연산기 수 제한, 고 Op/B 시 비효율, DRAM 공정 제약
BankGroup-PIM DRAM bank group < 1 유사 문제 + DRAM 내 버퍼 크기 제한
Logic-PIM (Duplex 제안) HBM logic die 1~32 (MoE, GQA에 적합) 연산기 확장 용이, 고대역폭 TSV 활용 가능
  • 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는 deggrp개의 head가 K/V를 공유
  • decoding 단계의 attention 연산은 GEMV 형태 (낮은 Op/B)
  • Logic-PIM은 request-level, head-level 병렬로 각 attention 연산을 수행

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

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

구조 Throughput TBT latency Energy 적합 Op/B
GPU 1.0× 기준선 기준선 전체 가능, 저 Op/B에서 비효율
Bank-PIM ~1.2–1.4× 약간 개선 일부 절감 Op/B < 1
Logic-PIM (Duplex) 최대 2.67× ↓ 58% 이상 ↓ 42% Op/B 1–32 (MoE, 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 구조 등)을 어떻게 활용하여 성능을 높이는가?

A :

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

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

구성 요소 병렬 처리 대상 분배 기준 담당 처리기
MoE Layer (Experts) Expert별 FFN 각 expert가 처리할 토큰 수 xPU (토큰 많음), Logic-PIM (토큰 적음)
Attention Layer (GQA) Request별 Attention 요청 유형 (prefill vs decoding) xPU (prefill), Logic-PIM (decoding)

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)

📦 분배 정책

요청 유형 연산 특성 처리기
Prefill Q: 전체 입력 (512개), KV 공유 xPU
Decoding Q: 1개 토큰, KV 공유 Logic-PIM
  • 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 구조의 그룹화 특징

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

🧪 실험 결과로 본 효과

구성 MoE 실행 시간 Attention 처리 시간 Overall Throughput
All xPU 높음 (underutilized) 비효율적 1.0× (baseline)
All Logic-PIM 병목 발생 일부 개선 ↓
Co-processing Load-balanced Op/B별 최적 처리 ↑ 2.67×

✅ 결론 요약

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

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

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

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

A :

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)

Stage 유형 전체 stage 중 비율 특징
Decoding-only 약 80~90% Op/B 낮음, 주요 병목 발생
Mixed stage 10~20% Prefill 포함, Op/B 다소 높음

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

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

비교 대상 Throughput (tokens/s) TBT Latency 감소 (p50)
GPU 기준선 (1.0×) -
2× GPU 1.76× 일부 감소
Duplex 2.07× 58.3% 감소
Duplex+PE+ET 최대 2.67× 최대 60% 감소

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

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

  • QPS (Queries per Second) 증가에 따른 latency 변화
QPS GPU 2× GPU Duplex
4~9 처리 가능 가능 가능
10~14 처리 불가 (큐 대기 증가) 가능 가능 (14 QPS까지)
≥15 모든 구조에서 overload overload overload

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

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

Duplex 설계 요소 Continuous Batching과의 정합성
Logic-PIM의 low Op/B 최적화 대부분 decoding-only stage 연산이 해당됨
Co-processing (expert/token 단위) stage별 다양한 token 수에 맞춤형 분배 가능
KV cache 분리 및 migration 구조 decoding stage 캐시 증가 문제를 대응할 수 있도록 설계
Bank-bundle 기반 DRAM 매핑 decoding stage 집중 시 DRAM 충돌 회피

⚠️ 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가 비효율적인 조건에서 어떻게 구조를 개선할 수 있을지도 제안해드릴 수 있어요.