SADDLE: PIM-enabled heterogeneous system(GPU + PIM)에서 request마다 draft length를 바꿔 speculative decoding throughput 올리기

0한눈에 보기

speculative decoding은 작은 DLM이 draft token을 만들고 큰 TLM이 한 번에 verification 하는 방식이다. 기존 PIM-enabled heterogeneous system은 draft length $d$를 고정하며, 논문의 동기 실험(SpecPIM, OPT-66B+OPT-1.3B, $d=8$)에서는 batch size 64부터 speculative decoding을 쓰지 않은 baseline보다 throughput이 낮았다 §III-A p.4.
SADDLE은 request마다 누적 확률 $H_t$가 $\tau$ 아래로 떨어지면 draft를 멈추고, request마다 draft length가 달라져 생기는 bubble은 Shared Pool·Eager Pool로, operator arithmetic intensity의 변화는 동적 operator mapping으로 다룬다 §I p.2. 세 모델 쌍·batch size 16–128 평균 throughput은 GPU-SD 대비 2.88×, PIM-SD 대비 1.71×다 §V-B p.10.

1배경: 용어와 speculative decoding·PIM의 기본

0 절의 흐름 그림은 draft token·Shared Pool·operator mapping 같은 용어를 설명 없이 쓴다. 그래서 1 절은 2 절 이후에 쓰는 용어의 뜻을 표로 고정하고, speculative decoding·PIM·arithmetic intensity·micro-batch를 그림과 함께 먼저 설명한다 논문에 없음.
speculative decoding은 DLM이 draft token $d$ 개를 만들고 TLM이 한 번에 verification 해, 앞에서부터 accept 된 token을 출력하는 방식이다 §II-B p.3.
PIM은 memory bank 옆에 PE를 두어 memory-bound operator를 memory 안에서 계산하는 hardware이고, SADDLE 논문은 GPU와 PIM을 함께 쓰는 system에서 operator를 어디에 둘지를 다룬다 §II-C p.4.

1.1용어표

1.2autoregressive decoding과 KV cache

1.3speculative decoding

1.4draft length와 batching

1.5arithmetic intensity와 roofline

1.6PIM chip과 SADDLE PIM device

1.7pipeline parallelism과 micro-batch

2문제: 고정 draft length에서 batch size가 크면 throughput이 떨어진다

1 절에서 speculative decoding은 accept 되는 draft token이 많을수록 iteration 하나에서 얻는 token이 늘고, batching은 request를 묶어 throughput을 올린다고 했다. 2 절은 두 방법을 함께 쓰는 기존 PIM-enabled heterogeneous system에서 batch size를 키우면 throughput이 어떻게 되는지(Fig.3), 원인이 무엇인지(Fig.4), 원인을 고치려 할 때 어떤 새 문제가 생기는지(Fig.5·6)를 순서대로 본다 논문에 없음.
동기 실험(SpecPIM, OPT-66B+OPT-1.3B, $d=8$)에서 batch size 64부터 throughput이 baseline 아래로 떨어졌다. 논문은 원인을 고정 draft length로 보고, $d$가 길면 rejected token이 늘고 짧으면 verification이 잦아져 TLM 병렬성이 준다고 쓴다 §III-A p.4.
optimal draft length는 task·speculative decoding iteration·모델 쌍마다 달라, batch의 모든 request에 같은 $d$를 쓰면 낭비가 남는다고 논문은 쓴다 §III-A p.4–5.

2.1

"While such redundant computation may be tolerable under small batch sizes, it becomes increasingly detrimental as the batch size grows—consuming valuable hardware resources that could otherwise be used for effective inference"§I p.2

2.2

Fig.4는 optimal draft length가 task·iteration·모델 쌍마다 달라 request마다 $d$를 실행 중에 정해야 한다는 근거다. 그러나 request마다 $d$를 다르게 두면 Fig.5(b)의 bubble과 Fig.6의 operator intensity 변화라는 새 문제 두 가지가 생긴다고 논문은 쓴다 §III-B p.5. 3 절의 부품 셋은 draft length 결정·bubble·intensity 변화 세 가지(draft length 결정, bubble, intensity 변화)에 하나씩 대응한다 해석.

Fig.5 · Fig.6 — request마다 $d$를 바꾸면 생기는 새 문제 두 가지

2.3

2.4

3기법: SADDLE의 세 부품

2 절은 고정 $d$의 낭비(Fig.3·4), request 별 $d$가 만드는 bubble(Fig.5b), operator intensity 변화(Fig.6)라는 세 문제를 보였다. 그래서 SADDLE은 세 문제에 하나씩 대응하는 부품 셋을 둔다 Abstract p.1 §I p.2.
① Controller가 request마다 $H_t$를 계산해 $H_t < \tau$이면 draft를 멈춰, reject 될 가능성이 큰 draft token의 생성·verification을 줄인다 §IV-C p.7–8. ② Shared Pool과 Eager Pool로 prediction stage와 verification stage를 떼어 idle time을 줄인다 §IV-C·D p.8.
③ Scheduler가 effective micro-batch size와 request 별 draft token 수로 arithmetic intensity를 추정해 DLM FC·TLM attention을 GPU 또는 PIM에 다시 배치한다 §IV-E p.9.

3.0.1

3.0.2

3.1① adaptive draft length: $H_t$가 $\tau$ 아래면 멈춘다

Fig.4에서 optimal draft length가 task·iteration·모델 쌍마다 달랐으므로, draft length는 실행 전에 하나로 정할 수 없고 request마다 실행 중에 정해야 한다. 논문은 optimal draft length를 prediction stage 전에 정하기는 어렵지만, 생성한 draft token의 누적 확률을 보며 추정할 수 있다고 쓴다 §IV-C p.7.

논문은 확률이 낮은 token이 나오면 $H_t$가 떨어져 draft가 일찍 멈추고, reject 될 가능성이 큰 token에 대한 연산을 피한다고 쓴다 §IV-C p.8. 결과적으로 확률이 높은 token을 내는 쉬운 request는 draft length가 길고, 어려운 request는 짧아진다 §IV-C p.8. Controller는 softmax unit·곱셈기·비교기를 갖춰 draft 중단 판단을 hardware로 한다 §IV-C p.8.

3.2② Shared Pool · Eager Pool: prediction stage와 verification stage를 떼어 놓는다

① 로 request마다 draft length가 달라지면, draft를 일찍 멈춘 request는 가장 긴 request의 draft가 끝날 때까지 verification을 기다린다(Fig.5b) §IV-C p.8. 그래서 논문은 verification을 micro-batch 단위로 바로 하지 않고 여러 micro-batch의 draft token을 Shared Pool에 모으며, Shared Pool이 만든 새 문제(draft가 일찍 끊김)는 Eager Pool로 다룬다 §IV-C·D p.8.

Fig.11 — 논문의 timeline 그림, pool 세부

3.2.2

3.2.3
• 3.2.3.1Shared Pool은 CAM(Content Addressable Memory)으로 만든다 §IV-C p.8. 실험 설정은 Shared Pool 1 KB, Eager Pool 1 KB(micro-batch 수로 나눔)로 각 pool이 최대 512 token을 담고, logit·누적 확률용 SRAM이 1 KB다 §V-A p.9.
• 3.2.3.2SADDLE Manager는 greedy로 모든 request 중 verification을 통과할 가능성이 가장 높은 draft token부터 verification에 넣는다. 논문은 greedy 정책이 draft가 지나치게 긴 request 하나가 micro-batch 전체의 verification을 늦추지 않게 한다고 쓴다 §IV-C p.8.
• 3.2.3.3두 pool 사이 이동은 on-chip memory 연산이라 성능 overhead가 무시할 만하다고 논문은 쓴다 §IV-D p.8. pool의 draft token은 verification마다 새로 채워지므로 두 pool 모두 약 1 KB 면 된다고 쓴다 §IV-D p.8–9.

3.3③ arithmetic intensity-aware operator scheduling

① 과 ② 를 넣으면 draft length와 아직 draft 중인 request 수(effective micro-batch size)가 실행 중에 계속 바뀌고, Fig.6처럼 operator의 arithmetic intensity가 PIM-benefit과 GPU-benefit 경계를 넘나든다 §IV-E p.9. 그래서 실행 전에 한 번 정한 operator mapping 대신, Scheduler가 실행 중에 intensity를 추정해 mapping을 바꾼다.

Scheduler는 매 prediction 뒤 추가 DLM iteration을 할 request를 세어 effective micro-batch size를 정하고, effective micro-batch size로 DLM FC의 arithmetic intensity를 근사한다. verification stage 전에는 Shared Pool에서 request 별 draft token 수를 세어 TLM attention의 intensity를 추정한다. 두 intensity 추정값을 미리 재 둔 threshold(PIM compute-bound, GPU memory-bound)와 비교해 GPU·PIM 중 하나로 보낸다 §IV-E p.9. 초기 mapping은 system의 평균 workload profile로 정한다 §IV-E p.9.

논문은 SpecPIM 식 offline 분석을 실행 중 다시 돌리는 비용이 remapping 이득보다 클 수 있다고 쓴다 §II-C p.4. SADDLE의 threshold 비교가 그보다 가볍다는 것은 요약자의 해석이며, 원문에 remapping 비용 수치는 없다 해석.

Fig.9 · Fig.10 — weight·KV cache를 bank에 어떻게 나눠 두나

3.3.2

3.3.3

4구현과 실험 설정

3 절의 부품 셋은 새 hardware(PE가 붙은 HBM, SADDLE Manager)를 전제하므로, 5 절의 수치를 읽기 전에 어떤 simulator·모델·baseline·hardware 구성에서 잰 값인지 먼저 정한다 논문에 없음.
실제 chip이 아니라 Ramulator2와 AttAcc를 고친 cycle-accurate simulator로 GPU system과 SADDLE의 성능·energy를 평가했다. SADDLE은 SADDLE PIM device 8 개(각 A100 1 개 + PIM chip 5 개, 80 GB)를 쓰고, 모든 비교 system의 memory 용량을 640 GB로 맞췄다 §V-A p.9.
PE는 Synopsys Design Compiler 28 nm·1 GHz로 합성하고 area를 DRAM 공정으로 환산했다 §V-A p.9–10. 2 절 동기 실험의 SpecPIM 구성(A100 4 개)은 평가의 PIM-SD 구성(A100 8 개)과 다르다 §III-A p.4 §V-A p.9.

모델 · baseline · hardware 표

4.1

4.2

system	구성	근거
4.2.1GPU-AD	DGX A100 (A100 8 개, 640 GB, 합산 memory 대역폭 16 TB/s), DeepSpeed Inference, TLM으로 autoregressive decoding	§V-A p.9
4.2.2GPU-SD	같은 GPU system에서 speculative decoding	§V-A p.9
4.2.3PIM-AD	AttAcc의 HBM-PIM 구조. A100 8 개 + HBM stack 40 개(각 16 GB, 합 640 GB, 내부 대역폭 144 TB/s). attention은 PIM, FC는 GPU. TLM으로 autoregressive decoding	§V-A p.9
4.2.4PIM-SD	PIM-AD와 같은 hardware에서 speculative decoding. SpecPIM의 mapping 전략대로 초기 batch size·최대 sequence length로 실행 전 design-space 탐색을 한다	§V-A p.9
4.2.5SADDLE	SADDLE PIM device 8 개 × (A100 1 개 + NVLink로 연결한 HBM3 PIM chip 5 개, 각 16 GB, 5.2 Gbps/pin)	§V-A p.9
4.2.6workload	Dolly dataset(수천 명의 직원이 만든 open-source instruction-following dataset, InstructGPT의 behavior category 여러 개에 걸침), batch size 16–128, 대부분 실험의 최대 sequence length 1024 (OPT-175B는 memory 제약으로 512)	§V-A p.9
4.2.7interconnect · 대역폭	host와 SADDLE PIM device 사이는 고속 interconnect(원문 예: CXL, NVLink). SADDLE PIM device 안 내부 대역폭 2 TB/s, device 사이 대역폭 600 GB/s. host CPU 종류·host memory·PCIe 세대는 원문에 명시가 없다	§IV-A p.5, §V-E p.11
4.2.8simulator · energy	Ramulator2와 AttAcc를 고친 cycle-accurate simulator가 system 구성과 모델 사양을 받아 system 별 실행 시간과 energy를 낸다. HBM energy는 선행 연구의 activation·read energy 값을 쓴다. pipeline stage 수 $S$·micro-batch 수, sampling 설정은 원문에 명시가 없다	§V-A p.9–10

5평가

2 절의 문제는 큰 batch size에서 speculative decoding의 throughput이 떨어지는 것이었으므로, 5 절은 4 절의 설정에서 batch size를 16–128로 키웠을 때 SADDLE이 앞서는지(Fig.12·13), 이득이 어느 부품에서 왔는지(Fig.14·19), 어디서 시간이 줄었는지(Fig.16–18)를 본다 논문에 없음.
세 모델 쌍 × batch size 16·32·64·128 모든 조합에서 SADDLE의 throughput이 가장 높고, 평균으로 GPU-AD 대비 3.36×, GPU-SD 2.88×, PIM-AD 1.94×, PIM-SD 1.71×다 §V-B p.10.
batch size가 커지면 GPU-SD·PIM-SD의 GPU-AD·PIM-AD 대비 이득은 줄거나 뒤집히지만 SADDLE은 앞선다. 논문은 원인으로 adaptive draft length, cross-micro-batch verification, 동적 operator mapping 셋을 든다 §V-B p.10.

5.1

5.2

5.3

Fig.13 — energy efficiency

5.4

Fig.15 — sequence length · 작은 batch size 민감도

5.5

Fig.17 · Fig.18 · Fig.19 — 통신 비용, hardware 사용률, operator scheduling 효과

5.6

5.7

5.8

6결론과 한계

5 절의 수치는 모두 simulator·Dolly 한 dataset·batch size 16–128이라는 4 절의 조건에서 나왔다. 그래서 6 절은 논문의 결론을 옮긴 뒤, 4 절 조건 밖에서 결론이 유지되는지 확인되지 않은 부분을 한계로 정리한다 논문에 없음.
논문의 결론은 누적 확률 기반 draft length 조절, DLM과 TLM을 떼어 놓는 asynchronous pipeline, arithmetic intensity 기반 operator scheduling으로 평균 throughput을 GPU-only 대비 2.88×, 기존 PIM-enabled speculative decoding system 대비 1.71× 올렸다는 것이다 §VII p.13.
논문에 limitation 절은 없다. 아래는 요약자가 정리한 한계다 논문에 없음.

7관련 연구

6 절의 한계 중 하나는 다른 adaptive drafting 알고리즘과 비교하지 않았다는 것이다. 7 절은 SADDLE이 PIM-enabled heterogeneous system 연구와 adaptive draft length 연구 두 갈래 중 어디에 서 있는지를 논문 §VI 기준으로 정리한다 논문에 없음.
PIM-enabled heterogeneous system(AttAcc, IANUS, SpecPIM, PAPI)은 operator를 GPU·PIM에 나누지만, 논문은 PIM-enabled heterogeneous system에서 adaptive draft length를 처음 쓴 것이 SADDLE이라고 주장한다 §I p.2.
adaptive draft length 연구(Disco, OPT-Tree)는 단일 request에서 latency를 줄였고, SADDLE은 adaptive drafting을 batching과 결합해 large batch throughput을 높인다 §VI p.12–13.

background figure (Fig.1 · Fig.2)

7.2

7.3

8세미나 발표 대본 (약 18 분)

1~7 절은 읽는 사람이 찾아보는 순서로 썼으므로, 발표에서는 논문 그림 순서대로 질문을 이어 가는 대본을 따로 둔다. Fig.1~19와 Table I을 원 caption·쪽과 함께 놓고, 그림마다 앞 그림이 남긴 질문에서 출발해 다음 그림으로 넘기는 발화를 적었다. Table I은 원문 p.10에 있지만 평가 전 실험 환경에서 다룬다.
발화문은 요약자가 쓴 것이고 논문에 없음, 수치와 주장은 원문에서 확인한 것만 넣었다. caption 끝의 시간은 권장 분량이며 합계 약 18 분 30 초다.

펼치기: 슬라이드별 그림과 발화 (Fig.1~19 · Table I)

도입 · 40 초

오늘 소개할 논문은 HPCA 2026의 SADDLE입니다. speculative decoding은 작은 draft 모델인 DLM이 token 여러 개를 먼저 만들고 큰 target 모델인 TLM이 한 번에 검사하는 방식인데, GPU와 PIM을 함께 쓰는 기존 system에서는 batch size가 커지면 speculative decoding을 쓰지 않을 때보다 throughput이 낮아지는 경우가 있습니다. SADDLE은 request마다 draft length를 실행 중에 정하고, request마다 draft length가 달라져 생기는 두 문제를 pool 두 개와 동적 operator mapping으로 다뤄, 세 모델 쌍·batch size 16~128 평균 throughput을 GPU-SD 대비 2.88배, PIM-SD 대비 1.71배로 올렸습니다. 문제를 보기 전에 배경 그림 두 장으로 용어부터 맞추겠습니다.

1 부 · 배경 (약 70 초)

8.1

첫 배경은 LLM이 token을 만드는 구조입니다. 왼쪽 prefill phase가 입력 전체로 첫 token $x_0$을 만들고, 가운데와 오른쪽 decoding phase는 iteration마다 token 하나를 만들면서 각 decoder layer의 Key·Value를 KV cache에 덧붙입니다. 오른쪽 확대 그림처럼 decoder layer는 QKV generation, multi-head attention, projection, FFN으로 이뤄지고, 논문은 QKV generation과 FFN을 FC operator, multi-head attention을 attention operator로 부릅니다. 뒤에서 GPU와 PIM에 나눠 싣는 단위가 바로 FC operator와 attention operator입니다.

8.2

token을 하나씩만 만드는 decoding의 throughput을 올리는 방법은 두 가지이고, Fig.2가 두 방법을 나눠 보여 줍니다. (a)는 batching으로, request #0~#4를 한 iteration에 묶어 request 단위 병렬성을 얻으며, FC operator는 모든 request가 같은 weight를 쓰므로 GEMV 여러 개가 GEMM 하나로 합쳐집니다. (b)는 speculative decoding으로, 초록 DLM이 prediction stage에서 draft token을 차례로 만들고 파란 TLM이 verification stage에서 한 번에 검사하며, 그림에서는 draft token 세 개 중 두 개가 accept되고 마지막 하나가 reject됩니다. SADDLE은 두 병렬성을 함께 쓰는 큰 batch의 speculative decoding을 다루는데, 두 방법을 합치면 무슨 일이 생기는지가 다음 그림입니다.

2 부 · 문제 (약 4 분)

8.3

기존 system인 SpecPIM에서 batch를 키우면 speculative decoding이 얼마나 효과가 있는지 잰 결과입니다. SpecPIM은 A100 4개에 A100마다 HBM-PIM 5개를 붙인 구성이고, OPT-66B를 TLM, OPT-1.3B를 DLM으로 Dolly dataset을 돌렸으며, 초록 막대는 같은 hardware에서 OPT-66B만으로 autoregressive decoding한 baseline, 파란 막대는 speculative decoding입니다. (a)는 draft length를 8로 고정하고 x축 batch size를 8부터 128까지 늘린 그림으로, batch size 32까지는 파랑이 높지만 64와 128에서는 초록보다 낮아집니다. (b)는 batch size를 64로 고정하고 x축 draft length를 2부터 12까지 바꾼 그림으로, 본문 기준 $d=4$에서 baseline의 1.41배로 가장 높고 $d=8$과 12에서는 baseline 아래이므로, 다음 질문은 $d$를 4로 잘 고르면 해결되는가입니다.

8.4

$d$ 하나를 잘 고르면 충분한지 보려고 논문은 accept되는 token 수를 Dolly의 세 task별로 나눠 봅니다. (a)는 OPT 쌍에서 x축 draft length를 4·8·12로 늘릴 때 y축 acceptance rate, 즉 DLM이 만든 draft token 중 TLM이 accept한 비율이고, 파랑 summarization, 주황 open_qa, 초록 creative_writing 세 task 모두 $d$가 길수록 낮아집니다. (b)는 같은 OPT 쌍에서 x축이 speculative decoding iteration 번호, y축이 해당 iteration에서 accept된 token 수인데, creative_writing은 첫 iteration 5개에서 12번째 iteration 1개로 줄고 세 task의 선이 서로 다르게 움직이며, (c)는 모델 쌍만 Llama3-70B+Llama3-1B로 바꾼 같은 그림으로 같은 task·iteration에서도 값이 (b)와 다릅니다. 논문은 accept될 수 있는 최대 token 수를 optimal draft length라 부르고, optimal draft length가 task·iteration·모델 쌍마다 달라 모든 request에 같은 $d$를 쓰면 낭비가 남는다고 결론짓는데, 그렇다면 request마다 $d$를 바꾸면 되는지가 다음 그림입니다.

8.5

Fig.5는 고정 draft length와 request별 draft length를 같은 batch의 request 4개로 비교하며, 두 패널 모두 가로가 시간, 세로가 request #0~#3, 초록 칸 하나가 draft token 하나를 만드는 시간, 파란 상자가 TLM verification입니다. (a)는 $d$를 고정한 경우로, #1과 #2의 뒤쪽 draft token에 빨간 X가 붙어 있고 나중에 reject될 token을 만든 연산이 낭비입니다. (b)는 request마다 draft length를 다르게 한 단순한 방식인데, 가장 긴 #0이 끝날 때까지 verification이 시작하지 못해 일찍 끝난 #1~#3의 칸이 bubble로 비어 있습니다. 즉 (a)의 낭비 연산을 없애려고 (b)로 가면 기다리는 시간이 새로 생기며, 논문은 문제가 하나 더 있다고 말합니다.

8.6

두 번째 새 문제는 operator의 성격이 실행 중에 바뀐다는 것이고, Fig.6이 roofline으로 보여 줍니다. x축은 arithmetic intensity, 즉 memory에서 1 byte를 읽을 때의 연산 수이고 y축은 달성 성능 TFLOPS이며, 주황 선이 PIM, 검은 선이 GPU의 한계로 읽히고 빨간 점선 왼쪽은 PIM이, 오른쪽은 GPU가 빠른 구간입니다. 원은 attention, 삼각형은 FC, 파랑은 TLM인 OPT-66B, 노랑은 DLM인 OPT-1.3B이고, 연한 색은 아직 draft 중인 request 수와 draft length가 (4, 1), 진한 색은 (12, 8)인 설정입니다. 설정이 (4, 1)에서 (12, 8)로 바뀌면 TLM attention과 DLM FC가 점선 왼쪽에서 오른쪽으로 넘어가므로 실행 전에 한 번 정한 mapping은 맞지 않게 되고, 따라서 SADDLE에는 draft length를 정하는 방법, 기다림을 줄이는 방법, operator를 다시 배치하는 방법 세 가지가 필요합니다.

3 부 · 설계 (약 4 분 30 초)

8.7

세 가지 해법을 올릴 hardware부터 보겠습니다. 다섯 패널은 왼쪽에서 오른쪽으로 한 단계씩 확대한 그림으로, (a)는 host, SADDLE Manager, SADDLE PIM device 여러 개가 CXL이나 NVLink 같은 interconnect로 이어진 전체 system이고, (b)는 SADDLE PIM device 하나로 가운데 centralized processor(평가에서는 A100 GPU)와 router 주위에 PIM chip 여러 개가 붙어 있습니다. (c)는 PIM chip 안의 bank group으로 bank마다 PE가 하나씩 붙고 pCH 단위로 global buffer와 accumulator가 있으며, (d)는 PE 내부로 bank의 row buffer와 global buffer에서 operand를 받아 곱셈기와 adder tree로 계산하고, (e)는 buffer die의 SFU로 softmax처럼 행렬 곱이 아닌 연산을 맡습니다. 세 해법을 실행 중에 결정하는 곳은 (a)의 SADDLE Manager이고, SADDLE Manager의 내부가 다음 그림입니다.

8.8

SADDLE Manager에는 micro-batch마다 Draft Generator가 하나씩 있고, Draft Generator는 Controller와 Eager Pool로 이뤄지며, Shared Pool과 Scheduler는 SADDLE Manager 전체에 하나씩 있습니다. 오른쪽 SADDLE PIM device들이 prediction과 verification을 실행하고, Scheduler가 SADDLE PIM device로 보낼 operator를 어느 hardware로 보낼지 정합니다. 새 draft token이 생기면 Controller는 해당 request의 이전 draft token이 verification 중인지 보고, 아니면 Shared Pool에, verification 중이면 Eager Pool에 넣습니다.

첫 번째 해법인 draft 멈춤 판단도 Controller가 합니다. Controller는 draft token을 하나 sample할 때마다 sample한 token의 DLM 확률 $p_t$를 곱해 누적 확률 $H_t$를 갱신하고, $H_t$가 validation set으로 미리 정한 threshold $\tau$ 아래로 떨어지면 해당 request의 draft를 멈춥니다. 그래서 확률이 높은 token이 이어지는 request는 길게, 확률이 낮은 token이 나온 request는 짧게 draft하며, 판단은 곱셈 몇 번과 비교 한 번이라 Controller 안의 전용 hardware에서 처리합니다. 두 pool이 실제로 어떻게 맞물리는지는 Fig.11에서 보고, 그 전에 data를 PIM에 어떻게 나눠 두는지 짧게 보겠습니다.

8.9

Fig.9는 decoder layer의 weight를 PIM device들에 나눠 두는 방식으로, 왼쪽부터 QKV generation, multi-head attention, projection, FFN 순서이고 색 하나가 weight 조각 하나에 대응합니다. QKV generation은 attention head 단위로 나눠 각 head의 출력을 바로 attention 입력으로 쓰고, projection과 FFN의 둘째 FC는 부분 결과를 만든 뒤 AllReduce로 합칩니다. 본문과 caption의 row-wise·column-wise 표기가 서로 반대라는 점만 짚고, KV cache 배치로 넘어가겠습니다.

8.10

세 패널은 HBM stack에서 bank 안 계산까지 확대합니다. (a)는 가로가 request, 세로가 HBM stack인 표로, attention head 하나를 HBM stack 하나에 두고 다른 request의 head가 같은 stack을 함께 쓸 수 있어 head 사이 통신이 없습니다. (b)는 stack 안에서 $K^\top$와 $V$를 BG와 bank에 서로 반대 방향으로 나누는 규칙이고, (c)는 q vector를 global buffer에서 bank group의 모든 bank에 broadcast해 bank 4개의 PE가 동시에 곱하는 모습입니다. data 배치는 여기까지이고, 이제 두 pool이 bubble을 어떻게 줄이는지 보겠습니다.

8.11

Fig.5(b)의 bubble을 두 pool로 어떻게 줄이는지 보여 주는 timeline이고, 가로는 시간, 위 두 줄은 Device 0·1에서 DLM이 micro-batch #0(연한 파랑)과 #1(진한 파랑)의 draft token을 만드는 구간, 맨 아래 주황 막대는 TLM verification 구간입니다. 노란 Shared Pool은 여러 micro-batch의 draft token을 모아, token 수가 GPU가 한 번에 verification할 수 있는 양에 닿거나 GPU가 놀 때 한꺼번에 TLM으로 보냅니다. Shared Pool이 Locked인 동안에도 DLM은 verification 중인 token이 모두 accept된다고 가정하고 draft를 이어 가며, verification 중에 만든 token은 초록 Eager Pool에 쌓입니다. Unlock 뒤 이전 draft token이 모두 accept된 request의 Eager Pool token만 Shared Pool로 옮기고, reject가 나온 request의 token은 버린 뒤 TLM이 고친 token부터 다시 draft합니다.

Eager Pool이 필요한 이유는 Shared Pool만 쓰면 pool이 빨리 차서, 논문 예로 draft token 5개를 만들 수 있던 request가 2개만 만들고 verification으로 넘어가기 때문입니다. 다만 그림에도 TLM이 노는 빗금(Idleness) 구간이 남아 있어 idle time이 0이 되지는 않습니다. 남은 세 번째 해법은 Scheduler로, 매 prediction 뒤 아직 draft 중인 request 수로 DLM FC의 intensity를, verification 전에는 Shared Pool의 request별 token 수로 TLM attention의 intensity를 추정해 미리 재 둔 threshold와 비교하고 GPU 또는 PIM으로 보냅니다. DLM attention은 PIM, TLM FC는 GPU에 고정하므로 실행 중에 옮기는 것은 DLM FC와 TLM attention 두 operator뿐입니다.

실험 환경 · 80 초

8.12

평가로 넘어가기 전에 실험 환경입니다. 실제 chip이 아니라 Ramulator2와 AttAcc를 고쳐 만든 cycle-accurate simulator가 GPU system과 SADDLE 모두의 실행 시간과 energy를 계산했습니다. 모델은 Table I의 TLM–DLM 세 쌍, OPT-66B+OPT-1.3B, OPT-175B+OPT-6.7B, Llama-3.1-70B-Instruct+Llama-3.2-1B-Instruct이고 모두 FP16이며, 예를 들어 OPT-66B는 hidden size 9216, layer 64개, head 72개, OPT-1.3B는 2048, 24개, 32개입니다. dataset은 Dolly 하나이고 batch size는 16·32·64·128, 최대 sequence length는 1024 token(OPT-175B는 memory 제약으로 512)입니다.

hardware는 모든 system의 memory 용량을 640 GB로 맞췄습니다. GPU-AD·GPU-SD는 A100 80 GB 8장인 DGX A100(합산 memory 대역폭 16 TB/s)에서 DeepSpeed Inference로 돌리고, PIM-AD·PIM-SD는 같은 A100 8장에 HBM-PIM stack 40개(각 16 GB, 내부 대역폭 144 TB/s)를 붙인 AttAcc 구조이며, PIM-SD는 SpecPIM의 mapping 전략으로 실행 전에 design space를 탐색합니다. SADDLE은 A100 1장과 NVLink로 연결한 HBM3 PIM chip 5개(80 GB, pin당 5.2 Gbps)로 된 device 8개를 쓰고, device 안 대역폭은 2 TB/s, device 사이는 600 GB/s이며, SADDLE Manager에는 Shared Pool·Eager Pool·누적 확률용 SRAM을 1 KB씩 둡니다. host CPU 종류, host memory, PCIe 세대, pipeline stage 수와 sampling 설정은 원문에 나와 있지 않습니다.

4 부 · 평가 (약 6 분)

8.13

첫 질문은 Fig.3에서 무너졌던 큰 batch에서도 SADDLE이 앞서는가입니다. 세 칸은 왼쪽부터 OPT-66B, Llama3.1-70B, OPT-175B 모델 쌍이고, 칸마다 x축이 batch size, y축은 같은 모델 쌍·batch size의 GPU-AD를 1로 둔 throughput이며, 막대는 회색 GPU-AD, 갈색 GPU-SD, 초록 PIM-AD, 노랑 PIM-SD, 파랑 SADDLE입니다. 12개 조합 모두에서 파랑이 가장 높고, 평균으로 GPU-AD 대비 3.36배, GPU-SD 2.88배, PIM-AD 1.94배, PIM-SD 1.71배입니다. batch size 128을 보면 세 모델 쌍 모두 GPU-SD가 GPU-AD보다, PIM-SD가 PIM-AD보다 낮아 Fig.3의 역전이 다시 나타나지만 SADDLE은 앞서며, 같은 조건에서 energy는 어떤지가 다음 그림입니다.

8.14

칸과 막대 배치는 Fig.12와 같고 y축만 GPU-AD를 1로 둔 energy efficiency이며, 평균으로 GPU-AD 대비 6.81배, GPU-SD 5.96배, PIM-AD 2.32배, PIM-SD 1.45배입니다. 논문은 GPU system 대비 이득을 memory-bound operator를 PIM에서 돌려 중간 activation을 GPU global memory로 옮기는 energy를 줄인 데서, PIM-SD 대비 이득을 reject될 token의 연산을 줄인 데서 찾습니다. energy efficiency의 정확한 정의는 원문에 없고, throughput 이득이 세 부품 중 어디서 왔는지는 다음 ablation이 답합니다.

8.15

OPT-66B+OPT-1.3B에서 x축 batch size마다 PIM-SD를 1로 두고 부품을 하나씩 더한 ablation입니다. 막대는 왼쪽부터 회색 PIM-SD, 살구색 SADDLE-d(adaptive draft length만), 노랑 SADDLE-p(Shared Pool 추가, DLM과 TLM은 여전히 순차 실행), 초록 SADDLE-s(Eager Pool 추가, FC는 GPU·attention은 PIM 고정), 파랑 SADDLE(동적 operator mapping 추가)입니다. 살구색 SADDLE-d가 네 batch size 모두 1보다 낮아 평균 PIM-SD보다 1.22배 느린데, Fig.5(b)의 bubble과 Fig.6의 intensity 변화를 풀지 않으면 adaptive draft length만으로는 손해라는 뜻이고, SADDLE-d 위에 Shared Pool이 SADDLE-d 대비 1.52배, Eager Pool이 1.24배, 동적 mapping이 1.13배를 더합니다. 이득이 큰 batch에서 나온다면 batch가 아주 작거나 sequence가 길 때는 어떤지가 다음 그림입니다.

8.16

두 패널은 서로 다른 조건을 바꾸며, 둘 다 y축은 GPU-AD를 1로 둔 throughput입니다. (a)는 Llama3.1-70B+Llama3.2-1B, batch size 16에서 x축 sequence length를 1024부터 8192까지 늘린 그림으로, 길수록 SADDLE의 이득이 커지는데 논문은 KV cache가 커져 attention 시간이 늘고 attention을 PIM에서 돌리는 이득이 커지기 때문이라고 설명합니다. (b)는 OPT-66B+OPT-1.3B에서 x축 batch size를 1·2·4·8로 줄인 그림으로, SADDLE은 PIM-SD와 비슷한데 논문은 batch가 작으면 낭비 연산의 영향이 작기 때문이라고 씁니다. SADDLE의 이득이 시간 단계 중 어디서 생기는지는 다음 latency 분해가 보여 줍니다.

8.17

네 칸은 batch size 16·32·64·128이고, 칸마다 PIM-SD와 SADDLE의 end-to-end latency를 초 단위로 쌓았으며, 모델 쌍은 원문에 명시가 없습니다. 주황 빗금은 verification, 파란 빗금은 prediction, 초록은 monitoring, 노랑은 decision-making이고, SADDLE 막대에서 두 빗금이 겹친 부분에 Overlap이 표시되어 있습니다. 논문은 PIM-SD 대비 prediction latency가 1.18배, verification latency가 1.23배 줄었고, $H_t$ 갱신과 $\tau$ 비교에 쓴 시간은 SADDLE end-to-end latency의 0.83%라고 보고합니다. end-to-end latency는 1.73배 줄었는데 논문은 겹침의 효과로 설명하지만, 1.73배는 두 단계의 감소와 겹침을 모두 포함한 비교로 읽어야 하며, 다음으로 PIM 사이 통신이 시간을 잡아먹지 않는지 보겠습니다.

8.18

TLM verification을 여러 pCH와 HBM stack에 나눠 돌리면 통신이 늘 수 있어, 논문은 SADDLE의 TLM verification 실행 시간을 항목별로 나눴습니다. x축은 token length, y축은 비율이고, 초록이 stack 사이 통신, 노랑이 pCH 사이 통신, 파랑이 FC, 살구색이 attention입니다. 본문은 pCH 사이 통신이 13.54%, stack 사이 통신이 7.51%이고 DRAM die의 accumulator와 buffer die의 SFU가 부분합을 먼저 모아 전송량을 줄인다고 설명하는데, 두 값이 어느 token length의 값인지는 원문에 없습니다. 통신이 bottleneck이 아니라면 남는 질문은 hardware를 얼마나 바쁘게 썼는가입니다.

8.19

세 칸은 모델 쌍, 칸 안의 두 묶음은 PIM과 GPU이고, y축은 batch size 64에서의 평균 utilization이며, 막대는 초록 PIM-AD, 노랑 PIM-SD, 파랑 SADDLE입니다. 여섯 묶음 모두 SADDLE이 가장 높고, 세 모델 쌍 평균으로 GPU utilization은 PIM-AD·PIM-SD 대비 1.13배·1.37배, PIM utilization은 1.84배·1.18배이며, 논문은 asynchronous pipeline이 pipeline stall을 줄인 결과로 봅니다. utilization을 무엇으로 쟀는지는 원문에 정의가 없고, 마지막으로 operator scheduling이 PIM 쪽 일을 얼마나 늘렸는지 보겠습니다.

8.20

세 칸은 모델 쌍이고, 칸마다 W/O는 operator scheduling을 끈 SADDLE, W는 켠 SADDLE입니다. 막대는 왼쪽 y축으로 전체 operation 중 파랑 PIM과 주황 GPU에서 실행한 비율, 빨간 점과 선은 오른쪽 y축으로 W/O를 1로 둔 throughput입니다. 본문은 PIM 비율이 9.51%에서 14.89%로 늘고 throughput이 1.21배 올랐다고 쓰며, 그림의 모델별 값은 OPT-66B 1.24배, Llama3-70B 1.21배, OPT-175B 1.17배입니다. 논문은 1.21배를 heterogeneous architecture의 가속 여지를 다 쓴 결과로 표현하지만 최적 mapping과의 비교는 없으므로, 측정된 것은 scheduling을 켰을 때와 껐을 때의 차이입니다.

마무리 · 50 초

정리하겠습니다. GPU와 PIM을 함께 쓰는 기존 speculative decoding system은 draft length를 고정해, 큰 batch에서 reject될 token의 생성·verification 연산이 쌓여 autoregressive decoding보다 throughput이 낮아질 수 있었습니다. SADDLE은 누적 확률 $H_t$로 request마다 draft를 멈추고, Shared Pool과 Eager Pool로 request마다 draft length가 달라져 생기는 대기를 줄이며, arithmetic intensity를 보고 DLM FC와 TLM attention을 GPU와 PIM 사이에서 옮겨 PIM-SD 대비 평균 1.71배의 throughput을 얻었습니다. 한계로는 실제 chip이 아닌 simulator 결과라는 점, dataset이 Dolly 하나이고 $\tau$를 validation set으로 offline에 정해 다른 도메인에서 다시 맞춰야 할 수 있다는 점, greedy verification 순서 때문에 생길 수 있는 request별 latency와 fairness를 보고하지 않았다는 점을 들 수 있습니다. 감사합니다.