ISCA 2025 · Cong Li et al. (Peking Univ. · SJTU · Alibaba · Houmo AI · SEU · HKUST) · DOI 10.1145/3695053.3731008

H2-LLM: hybrid bonding 으로 NMP 연산량을 늘리고, channel 부터 정하는 dataflow 로 edge 의 low-batch LLM inference 를 가속하기

원문 papers/3695053.3731008_복사본.pdf (17쪽, 본문 13쪽) · §5.1 p.7 = 논문이 그렇게 쓴 절·쪽(PDF 쪽 번호) · 해석 = 논문 내용에서 요약자가 끌어낸 설명 · 논문에 없음 = 배경지식·예시·요약자 계산 · 용어는 1 절 용어표의 뜻으로만 쓴다 · 그림은 누르면 크게 열린다

0한눈에 보기

edge 의 LLM 서비스는 batch 가 1~수십으로 작아 decoding 이 memory-bound 다. 기존 NMP 는 PE 를 DRAM die 안에 넣어(in-die NMP) 연산량이 bandwidth 와 1~2 FLOP/Byte 비율밖에 안 되고, batch 가 조금만 커져도 이득이 사라진다 §3.1 p.3–4.
H2-LLM 은 DRAM die 를 logic die 위에 hybrid bonding 으로 쌓아 PE 연산량을 키우고, operator 마다 memory channel 을 먼저 묶는 data-centric dataflow 와 DSE 로 설계를 찾아 in-die NMP 대비 geomean 2.72× 빠르고 decoding energy efficiency 가 1.48× 높다 Abstract p.1.

0.1

0.1.1기 상황

개인 chatbot·가상 비서·안내 bot 처럼 edge 에서 도는 LLM 은 batch 가 1~수십이다 §2.2 p.3. prefill 은 연산이 많고 decoding 은 weight 를 매 token 다시 읽어 memory-bound 라, centralized processor 와 memory channel 안의 PE 를 함께 쓰는 NMP 이종 가속기가 제안돼 왔다 §1 p.2.

0.1.2승 문제

in-die NMP 는 DRAM 공정이라 연산량이 bandwidth 1 Byte 당 1~2 FLOP 수준이다(Table 2). LLaMA3 8B 에서 batch ≥ 8 이거나 GQA 의 KV head ≤ 4 이면 in-die NMP 의 이득이 없다 §3.1 p.4. 기존 dataflow 는 operator 를 고정 배치하거나(SpecPIM 은) prefill 을 고려하지 않는다 §3.3 p.4–5.

0.1.3전 기법

① logic die 에 PE 를 두고 DRAM die 를 Cu-Cu 로 직접 붙인 HB-NMP channel. HB controller 면적과 연산 면적 사이 trade-off 를 설계 공간으로 둔다 §4 p.5–7. ② operator 마다 channel 을 먼저 묶고(data-centric) 엔진은 그 결과로 정해, operator fission 과 prefill bandwidth 를 함께 살린다 §5 p.7–8. ③ genetic algorithm 으로 hardware·dataflow 를 함께 탐색한다 §6 p.8–9.

0.1.4결 결과

시뮬레이션(Ramulator2 + Tileflow)에서 OPT 6.7B·LLaMA3 8B·PaLM 8B × batch 1/4/16 × 4 dataset 을 비교했다. ID-NMP+ 대비 decoding-heavy 에서 3.81×, prefill-heavy 에서 1.94×, 전체 2.71× (geomean) 빠르다 §7.2 p.10–11.

0.2

DRAM bankNMP PEHB controllerhybrid bonding 연결

0.2.cin-die NMP 와 HB-NMP 는 PE 를 어느 die 에 두느냐가 다르고, 그 차이에서 연산량과 controller 면적의 trade-off 가 생긴다는 점을 보이는 그림이다.왼쪽은 PE 를 DRAM die 안에 넣는 in-die NMP 다. DRAM 공정은 logic 대비 transistor 가 3× 느리고 logic density 가 10× 낮으며, PE 에 줄 수 있는 면적도 제한된다(SK Hynix AiM 의 예: 25%) §3.2 p.4. 오른쪽 HB-NMP 는 PE 를 logic die 에 두고 DRAM die 를 위에 Cu-Cu 로 붙인다. 대신 HB I/O 를 구동하는 controller 가 logic die 면적을 차지한다(1024 핀이면 약 40%) §3.2 p.4. 그림의 bank·PE 개수와 배치는 예시다 논문에 없음.

0.3

0.3.1

2.72×

in-die NMP 대비 speedup (geomean, Abstract·§8). §7.2 본문은 2.71×

0.3.2

1.48×

decoding energy efficiency (ID-NMP 대비, ID-NMP+ 대비 1.54×)

0.3.3

3.81×

ID-NMP+ 대비, decoding-heavy HE·SG (geomean)

0.3.4

1.94×

ID-NMP+ 대비, prefill-heavy LB·LG (geomean)

2.72× 와 2.71× 는 원문 안에서 값이 다르다. Abstract·§1·§8 은 2.72×, §7.2 와 §7.3(Fig.13 설명)은 2.71× 로 쓴다. 어느 쪽이 맞는지는 원문에 명시 없음.

1배경: NMP, arithmetic intensity, hybrid bonding

LLM inference 는 prompt 를 한 번에 처리하는 prefill 과 token 을 하나씩 만드는 decoding 으로 나뉜다. decoding 은 weight 를 매 step 다시 읽으므로 batch 가 작으면 연산보다 memory bandwidth 가 속도를 정한다 §1 p.2.
NMP 는 memory channel 안에 PE 를 넣어 bank 를 동시에 읽어 bandwidth 를 늘리는 방식이고, 이 논문은 그 PE 를 어디에 두느냐(DRAM die 안 vs logic die)와 operator 를 어디에 둘지를 다룬다 §2.3 p.3.

1.1용어표

1.1.1

용어	정확한 뜻 (이 요약에서)	기호	논문 원문 표기
1.1.1.1low-batch inference	한 번에 처리하는 request 가 1~수십 개인 inference. 논문 실험은 batch 1·4·16 (혼합 실험은 4·8·16)	BS	"low-batch property (one to a few tens)" (§1 p.2), Fig.1 은 "a few tens (10-20)"
1.1.1.2prefill · decoding	prefill = prompt token 전체를 한 step 에 처리, decoding = request 마다 token 하나씩 만드는 반복 step	–	"prefill stage", "decoding stage" (§1 p.2)
1.1.1.3operator	transformer layer 안의 계산 단위. FC operator(Q·K·V·O·F1·F2·F3)와 attention operator(QK·SV)	–	"operators" (§2.1 p.2–3, Fig.2)
1.1.1.4GEMM	행렬 곱 $(M,K)\times(K,N)$. FC operator 는 GEMM 하나, attention operator 는 head 마다의 batched GEMM	$M, K, N$	"GEMM operators", "batched GEMMs" (§4.2 p.6)
1.1.1.5arithmetic intensity	operator 가 memory 에서 읽는 1 Byte 당 하는 FLOP 수	FLOPs/Byte	Fig.3 x 축 (§3.1 p.4)
1.1.1.6NMP · PE	Near-Memory Processing. memory channel 안에 연산기(PE)를 두어 bank 를 동시에 읽고 계산	–	"NMP", "processing engines (PEs)" (§2.3 p.3)
1.1.1.7in-die NMP	PE 를 DRAM die 안, bank 옆에 둔 NMP. 상용 HBM-PIM·GDDR6-AiM·LPDDR5-PIM 등	–	"in-die NMP" (§1 p.2, 논문이 정의한 이름)
1.1.1.8hybrid bonding (HB)	DRAM die 를 logic die 위에 쌓고 Cu-Cu 로 직접 접합하는 3D 집적 기술. 3 µm pitch 에서 110,000 연결/mm²	–	"hybrid bonding (HB)" (§3.2 p.4)
1.1.1.9HB I/O · HB controller	HB I/O = bank 와 logic die 를 잇는 HB 핀 묶음, HB controller = 그 핀을 구동하는 logic die 의 controller	–	"HB I/O", "HB Ctrl." (Fig.5)
1.1.1.10HB-NMP channel	DRAM die 를 logic die 위에 HB 로 쌓고 logic die 에 PE 를 둔 memory channel. "NMP channel" 이라고도 쓴다	$PC_p$	"HB-NMP channel" (§4.1 p.5), "NMP channel"
1.1.1.11normal channel	DRAM die 하나만 있는 일반 memory channel. centralized processor 만 읽는다	$NC$ (전부 묶어 virtual channel 하나)	"normal DRAM channels" (§4.1 p.5)
1.1.1.12centralized processor	GPU·TPU 같은 중앙 가속기. 연산이 많은 operator 와 전체 scheduling 을 맡는다. 실험에서는 TPU-like	–	"centralized processor (xPU, etc.)" (§4.1 p.5)
1.1.1.13CP (baseline)	NMP 없이 centralized processor 만 쓰는 비교 시스템. 연산량을 2 배로 줬다. 장치 이름과 구별해 "CP (baseline)" 으로 쓴다	–	"Centralized processor only (CP)" (§7.1 p.10)
1.1.1.14ID-NMP · ID-NMP+	in-die NMP 비교 시스템. ID-NMP = Samsung LPDDR5-PIM 방식(PE 당 16 MAC @200 MHz), ID-NMP+ = AiM 방식 PE(16 MAC @1 GHz)	–	§7.1 p.10
1.1.1.15FPU · MAC	FPU = HB-NMP PE 안의 부동소수점 연산기, FPU 하나에 MAC(곱하고 더하기) 16 개	–	"FPUs", "16 MACs" (§4.1 p.5, §7.1 p.10)
1.1.1.16operator mapping	operator 를 어느 연산 엔진(centralized processor 또는 NMP PE)이 실행할지 정하는 것	–	"operator mapping" (§3.3 p.4)
1.1.1.17operator fission	operator 하나를 쪼개 일부는 centralized processor, 일부는 NMP PE 가 실행. weight 는 복제하지 않는다	–	"operator fission" (§3.3 p.5)
1.1.1.18compute-centric · data-centric dataflow	compute-centric = 엔진을 먼저 정하고 그 엔진 쪽 channel 에 operator 를 둔다(SpecPIM). data-centric = channel 을 먼저 묶고 엔진은 그 결과로 정한다(H2-LLM)	–	§3.3 p.5, §5.1 p.7
1.1.1.19MAG · MPG · operator tier	MAG = 차례로 실행하는 operator 묶음, MPG = MAG 안에서 서로 독립이라 channel 을 나눠 갖는 묶음, tier = MPG 안에서 의존 순서로 나눈 단	$A_i$, $P_{(i,j)}$, $T^{(i,j)}_k$	"Memory Access Group", "Memory Partition Group", "operator tiers" (§5.1 p.7–8)
1.1.1.20GCMap · OCMap	GCMap = MPG → channel 집합 대응, OCMap = tier 안 operator → channel 집합 대응	$GCMap_{A_i}$, $OCMap_{T}$	Eq.3, Eq.6 (§5.1 p.7–8)
1.1.1.21VPU	centralized processor 안의 vector processing unit. MPG 마다 따로 배정해 병렬 실행한다	–	"vector processing units (VPUs)" (§5.3 p.8)
1.1.1.22DSE	Design Space Exploration. hardware 설정과 dataflow 를 함께 탐색해 가장 빠른 설계를 찾는 과정	–	"DSE framework" (§6 p.8)
1.1.1.23decoding-heavy · prefill-heavy	decoding-heavy = prompt 와 생성 길이가 비슷한 workload(HE·SG), prefill-heavy = prompt 가 생성 길이보다 10~100 배 긴 workload(LB·LG)	–	§2.2 p.3, Table 1
1.1.1.24normalized speedup · energy efficiency	speedup = end-to-end latency 의 역수를 기준 시스템으로 나눈 값. energy efficiency 는 decoding 단계의 에너지 효율을 기준으로 나눈 값	–	"Norm. Speedup", "decoding energy efficiency" (§7.2 p.11)

1.2LLM layer 와 attention 변형

Fig.2 — 1.2.1.c논문이 어느 장치에 배치할지 고르는 operator(Q·K·V·QK·SV·O·F1·F2·F3)가 무엇이고, attention 변형과 parallel layer 가 그 배치 선택지를 어떻게 바꾸는지 보이는 그림이다.Figure 2: LLM Architecture and Transformer Variants. (p.3) (a) decoder layer 하나는 Q·K·V FC → QK → softmax → SV → O FC 의 attention block 과 F1 → activation → F2 의 FFN block 이다. (b) MHA 는 Q head 마다 K·V head 가 하나씩, MQA 는 모든 Q head 가 K·V head 한 쌍을 공유, GQA 는 그 중간(그림은 4 쌍)이다. (c) GLU 는 FFN 에 F3 를 하나 더 둔다. (d) parallel transformer 는 attention block 과 FFN block 이 같은 입력을 받아 동시에 실행될 수 있다 §2.1 p.2–3.

이 논문에서 (b) 와 (d) 가 중요하다. GQA·MQA 는 K·V head 하나를 여러 Q head 가 같이 쓰므로, attention 이 같은 KV cache 1 Byte 로 더 많이 계산한다. 그래서 attention operator 의 arithmetic intensity 가 오른다 §3.1 p.4. (d) 처럼 서로 독립인 operator 가 있으면 memory channel 을 나눠 동시에 돌릴 여지가 생기고, 5 절의 dataflow 가 이것을 이용한다 §3.3 p.4.

1.3arithmetic intensity 와 roofline

1.3.1

$B$ = batch size · $K$, $N$ = FC weight 의 입력·출력 차원 · weight 와 입력은 FP16(2 Byte) · decoding 에서 request 하나당 token 하나 논문에 없음

$$\text{AI}_{\text{FC}} \approx \frac{2BKN\ \text{FLOP}}{2KN\ \text{Byte}} = B$$요약자 계산

decoding 의 FC operator 는 weight $K\times N$ 을 한 번 읽어 $B$ 개 token 에 쓰므로, 1 Byte 당 약 $B$ FLOP 이다. 같은 방식으로 attention 은 KV cache 를 Q head 몇 개가 공유하느냐(GQA 의 group 크기)에 비례한다. Fig.3 에서 FC 점이 BS 와 같은 x 값에, MQA 가 약 32 에 찍히는 것과 맞는다 해석.

1.3.2

1.3.2.cbatch 가 커지면 in-die NMP 는 낮은 연산 천장에 먼저 닿고, 같은 지점에서 centralized processor 는 아직 memory-bound 라는 roofline 읽는 법을 보이는 그림이다.roofline 은 "operator 가 낼 수 있는 성능 = min(연산 천장, bandwidth × arithmetic intensity)" 를 그린 그림이다. 왼쪽 기울어진 구간이 memory-bound, 평평한 구간이 compute-bound 다. in-die NMP 는 bandwidth 기울기는 가파르지만 천장이 낮아서, batch 가 커져 intensity 가 오르면 곧 천장에 닿는다. 같은 지점에서 centralized processor 는 external bandwidth 가 좁아 아직 memory-bound 라 둘 다 제 성능을 못 낸다. 그림은 모양만 보인 예시다 논문에 없음. 실제 측정은 아래 Fig.3 이다.

1.4나머지 용어

1.4.1

memory channel · bank

memory channel 은 processor 가 독립적으로 접근하는 memory 통로이고, 한 channel 안에 bank 여러 개가 있다 논문에 없음. 실험 시스템은 channel 8 개, channel 당 256 MB bank 16 개다 §7.1 p.10.HB-NMP PE 는 bank 하나와 짝이 되어 bank 를 동시에 읽는다 (§4.1 p.5)

systolic array

곱셈기를 격자로 놓고 데이터를 옆으로 흘려 행렬 곱을 하는 연산 구조다 논문에 없음. 실험의 centralized processor 는 128×128 systolic array 8 개와 SIMD-128 VPU 8 개를 1 GHz 로 둔다 §7.1 p.10.prefill 같은 compute-bound operator 를 맡는다

genetic algorithm

후보 설계(individual) 여러 개를 평가해 좋은 것을 남기고, 그것을 바꾸거나(mutation) 섞어(crossover) 다음 세대를 만드는 탐색 방법이다 논문에 없음.H2-LLM DSE 의 exploration engine (§6.2 p.9)

geomean

여러 비율의 기하평균이다. 비율 몇 개가 아주 커도 산술평균보다 덜 끌려가 speedup 평균에 흔히 쓴다 논문에 없음.논문의 모든 평균 speedup 은 geomean (§7.2 p.10)

2문제: in-die NMP 는 연산이 모자라고, 기존 dataflow 는 prefill 을 놓친다

① 상용 in-die NMP 는 bandwidth 를 외부 interface 의 4~16 배로 늘리지만 연산:bandwidth 비율이 1~2 라, batch 가 8 이상이거나 GQA·MQA 처럼 attention intensity 가 오르면 이득이 없다 §3.1 p.4.
② hybrid bonding 이 대안이지만 HB controller 가 logic die 면적을 먹어 연산과 bandwidth 를 trade-off 해야 하고 §3.2 p.4, 기존 dataflow 는 operator 를 고정 배치하거나 prefill 의 bandwidth 를 줄인다 §3.3 p.4–5.

2.1edge LLM 은 batch 가 작고 workload 가 다양하다

Fig.1 — 2.1.1.cedge 의 LLM 서비스는 cloud 와 달리 한 번에 처리하는 request 가 1~수십 개뿐이라는 점을 보이는 그림이다.Figure 1: Edge-Side LLM Services. (p.2) cloud 는 batch 가 수백이지만 edge 서비스는 1~수십(그림은 10-20)이다. (a) 개인 chat helper 는 사용자 한 명, (b) 가상 비서는 app 여러 개(AIOS 예: 6 개), (c) 안내 bot 은 사용자 수십 명을 받는다 §2.2 p.3.

2.1.2.cedge workload 에는 decoding 비중이 큰 것과 prefill 비중이 큰 것이 섞여 있어, 둘 중 한 단계만 빠르게 해서는 안 된다는 점을 보이는 표다.Table 1: Workload Analysis for Representative Use Cases. (p.3) context 2048 기준으로 네 dataset 의 평균 길이다. HumanEval·ShareGPT 는 prompt 와 생성 길이가 같은 자릿수라 decoding-heavy, LongBench·LooGLE 은 prompt 가 생성보다 1~2 자릿수 길어 prefill-heavy 다. 논문은 그래서 prefill 과 decoding 을 모두 빠르게 해야 한다고 쓴다 §2.2 p.3.

2.2① in-die NMP 의 연산량 부족

2.2.1.c상용 in-die NMP 는 bandwidth 는 크게 늘렸지만 연산량은 bandwidth 1 Byte 당 1~2 FLOP 에 그친다는 점을 보이는 표다.Table 2: Commodity In-die NMP Proposals for LLMs. (p.4) 상용 in-die NMP 네 가지는 NMP bandwidth 가 외부 interface 의 4~16 배지만, NMP 연산량을 bandwidth 로 나누면 1~2 FLOP(OP)/Byte 다 §3.1 p.4. 1 절의 계산대로 decoding FC 의 intensity 가 batch 크기와 같다면, batch 2 만 넘어도 이 PE 들은 연산이 먼저 막힌다 해석.

Fig.3 — 2.2.2.cbatch 가 8 이상이거나 KV head 가 4 이하로 줄면 in-die NMP 의 연산 천장 때문에 이득이 사라지고, 그때도 centralized processor 는 여전히 memory-bound 라는 점을 보이는 그림이다.Figure 3: In-die NMP Roofline Analysis. (p.4) LLaMA3 8B 의 operator 를 Samsung LPDDR5-PIM 8 channel 에서 roofline 으로 본 그림이다. 삼각형은 FC operator(BS 1~16), 원은 attention operator(KV head 32=MHA ~ 1=MQA)다. 주황 수평선이 in-die NMP 천장, 검은 사선이 centralized processor 다. BS < 8 또는 KV head > 4 이면 in-die NMP 가 빠르지만, BS ≥ 8 또는 KV head ≤ 4 이면 in-die NMP 의 이득이 없다. 그 구간에서도 centralized processor 는 여전히 memory-bound 라 시스템 자원이 놀게 된다 §3.1 p.4.

2.3② hybrid bonding 의 연산-bandwidth trade-off

Fig.4 — 2.3.1.chybrid bonding 은 연산기를 logic die 에 둘 수 있게 하지만, 핀을 늘려 bandwidth 를 키울수록 controller 가 logic die 면적을 더 차지한다는 trade-off 를 보이는 그림이다.Figure 4: Hybrid Bonding Overview. (p.4) (a) DRAM die 를 logic die 위에 쌓고 Cu-Cu pillar 로 직접 붙인다. 3 µm pitch 면 110,000 연결/mm² 라 bandwidth 가 크고, 기생 정전용량이 작아 HBM 같은 2.5D 집적보다 전력 효율이 좋다고 논문은 쓴다 §3.2 p.4. (b) 저자들의 40 nm 구현에서 bank 하나의 HB I/O 핀을 128 → 1024 개로 늘리면 controller 가 logic die 면적의 약 5% → 40% 를 차지한다 §3.2 p.4. 핀을 줄이면 연산 면적이 늘지만 bandwidth 가 줄어 연산기를 다 쓰지 못한다.

"Therefore, balancing the computation-bandwidth trade-off intrinsic to HB technology is vital to fully unveil its acceleration potential, which is still lack of discussion."§3.2 p.4

HBM logic die 에 PE 를 두는 Duplex 도 연산량을 늘리지만, 논문은 HBM 의 전력 소모가 커서 edge 에 맞지 않는다고 쓴다 §3.2 p.4.

2.4③ 기존 dataflow 의 한계

2.4.1.c기존 dataflow 는 NMP 에 보낼 operator 를 고정하거나 prefill 을 고려하지 않으며, prefill-aware 탐색과 flexible fission 을 함께 하는 것은 H2-LLM 뿐이라는 점을 보이는 표다.Table 3: Comparison of Different Dataflow Designs. (p.5) 기존 설계 넷은 NMP 에 맡길 operator 를 고정한다(FC 만, attention 만 등). SpecPIM 은 탐색을 하지만 compute-centric 이고 prefill 을 고려하지 않는다. H2-LLM 만 data-centric 탐색에 flexible fission 을 한다 §3.3 p.4–5.

고정 배치는 batch 가 커서 operator 마다 intensity 차이가 큰 cloud 에서는 통하지만, low-batch 에서는 NMP 를 다 쓰지 못한다 §3.3 p.4. compute-centric 탐색은 operator 를 엔진 쪽 channel 한 종류에만 둔다. 그래서 centralized processor 가 맡은 operator 는 normal channel 일부의 bandwidth 만 쓰고, edge processor 의 연산:bandwidth 비율이 500~1000 이라 compute-bound 였던 prefill operator 가 memory-bound 로 바뀔 수 있다 §3.3 p.5. decoding 을 충분히 가속하면 prefill 비중이 커지므로 prefill-aware 탐색이 필요하다는 것이 논문의 주장이다. weight 를 prefill·decoding 용으로 복제하는 방법(prefill-decoding disaggregation)은 edge memory 로는 감당하기 어렵다고 쓴다 §3.3 p.5.

3기법: HB-NMP 구조, data-centric dataflow, DSE

① 구조: centralized processor + normal channel + HB-NMP channel. HB-NMP channel 은 bank 마다 PE 하나와 HB controller 를 붙이고, channel 수·PE 연산량·HB bandwidth·SRAM buffer 크기를 설계 변수로 둔다 §4 p.5–7.
② dataflow: operator 에 channel 을 먼저 묶고(MAG → MPG → tier), 둘 다에 걸친 operator 는 fission 한다 §5 p.7–8. ③ 이 두 설계 공간을 genetic algorithm 으로 함께 탐색한다 §6 p.8–9.

3.1① 구조: H2-LLM 의 hardware

Fig.5 — 3.1.1.cH2-LLM hardware 가 centralized processor, normal channel, HB-NMP channel 로 이뤄지고 HB-NMP channel 은 bank 마다 PE 하나를 붙인 구조라는 점을 보이는 그림이다.Figure 5: H2-LLM's Architecture Overview. (p.5) (a) 전체는 centralized processor 하나와 memory system 이다. memory system 의 channel 은 normal channel(진한 파랑)이거나 HB-NMP channel(옅은 파랑)이다. (b) HB-NMP channel 은 위쪽 memory die 의 bank 마다 HB I/O 가 있고, 아래 logic die 에 bank 마다 NMP PE 와 HB controller, 모든 PE 가 공유하는 input global buffer, NMP controller, 외부 interface 가 있다. (c) PE 하나는 FPU 여러 개, weight/KV buffer, output buffer, PE controller 로 이뤄진다 §4.1 p.5.

3.1.2

부품	하는 일	근거
3.1.2.1normal mode / NMP mode	HB-NMP channel 의 bank 는 normal mode 에서 centralized processor 가 외부 interface 로, NMP mode 에서 PE 가 HB controller 로 읽는다. row buffer 간섭을 막으려 한 번에 한 mode 만 켠다	§4.1 p.5
3.1.2.2input global buffer	입력 tensor 를 bank 마다 복제하지 않도록 모든 PE 가 공유	§4.1 p.5
3.1.2.3NoC 없음	실행 흐름에 PE 끼리 통신이 없어 NoC 를 빼고 그 면적을 연산에 준다	§4.1 p.5
3.1.2.4FPU 는 MAC 만	softmax·normalization 은 병렬성이 낮고 element-wise 연산은 결과 병합 단계에 fuse 되므로, GEMM 아닌 operator 는 centralized processor 가 맡는다	§4.3 p.6

3.2HB-NMP channel 안에서 GEMM 을 나누는 법 (Eq.1)

실행은 offloading 방식이다. centralized processor 가 입력을 HB-NMP channel 들에 뿌리고(Step 1), PE 들이 동시에 계산한 뒤(Step 2), centralized processor 가 결과를 읽어 합친다(Step 3) §4.2 p.5. weight 가 크므로 $M$ 은 나누지 않고 $K$ 와 $N$ 만 channel 에 나눈다. $K$ 를 많이 나누면 partial sum 을 모아 합쳐야 하고, $N$ 을 많이 나누면 같은 입력을 여러 channel 에 복제해야 한다 §4.2 p.6.

3.2.1

3.2.1.cGEMM 을 $K$ 방향으로 나누면 partial sum 이, $N$ 방향으로 나누면 입력 복제가 늘어난다는 trade-off 를 보이는 그림이다.$T_K$ 는 $K$ 차원을 몇 조각으로, $T_N$ 은 $N$ 차원을 몇 조각으로 자르는지다. 두 극단의 trade-off 를 그렸다. 그림은 예시이고 논문에 없음, trade-off 자체는 §4.2 p.6.

3.2.2

$s$ = 원소 크기(Byte) · $C$ = HB-NMP channel 수 · $B_l$, $B_s$ = channel 하나의 effective load / store bandwidth · $T_K$, $T_N$ = $K$·$N$ 차원 tiling factor · $M, K, N$ = GEMM 크기

$$\begin{aligned}\min_{T_K,T_N}\ & s\times M\times\left(\frac{K}{T_K\times B_s}+\frac{N}{T_N\times B_l}\right)\\ \text{s.t. }\ & T_K\times T_N = C\end{aligned}$$Eq.1 · §4.2 p.6

첫 항은 입력을 channel 에 쓰는 시간(Step 1), 둘째 항은 출력·partial sum 을 읽는 시간(Step 3)이다. 해는 $T_K=\sqrt{\dfrac{C\times K\times B_l}{N\times B_s}}$ 이고, channel 수만 정해지면 operator 마다 미리(static) 구할 수 있다 §4.2 p.6. attention 의 batched GEMM 은 GEMM 들을 channel 묶음에 고르게 나눠, GEMM 하나가 쓰는 channel 수를 줄여 복제·partial sum 을 줄인다 §4.2 p.6.

계산기: Eq.1 로 $(T_K, T_N)$ 고르기

입력값과 전송 시간은 예시다 논문에 없음. 논문은 $B_l$, $B_s$ 값을 밝히지 않았다. 기본값은 LLaMA3 8B 의 F2(down projection, $K=14336$, $N=4096$) · batch 4 · 8 channel 이고, 2 의 거듭제곱 쌍만 본다.

M (batch) K N C (channel) B_l / B_s

Fig.6 — 3.2.3.cHB-NMP channel 안에서 PE 들이 서로 통신하지 않고 각자 다른 출력 조각을 계산하도록 GEMM 을 나눈다는 점을 보이는 그림이다.Figure 6: H2-LLM's Intra-Channel Execution Flow. (p.6) channel 하나에 GEMM $(M_{ch},K_{ch})$ × $(K_{ch},N_{ch})$ 가 오면, 입력은 bank 에 고르게 흩고 weight·출력은 $N_{ch}$ 방향으로 bank 마다 나눈다. PE $i$ 는 $W_i$ 로 $O_i$ 를 다른 PE 와 겹치지 않게 만든다. 순서는 ❶ 입력 tile 을 HB I/O 로 input global buffer 에 모으고 ❷ weight tile 을 읽어 ❸ FPU 로 MAC, 출력이 다 쌓이면 ❹ 자기 bank 에 쓴다(output-stationary) §4.2 p.6. tensor 하나씩 연속으로 읽어 row buffer 간섭을 피한다.

command interface 4 종과 hardware 설계 공간

3.2.4

command	하는 일
3.2.4.1Mode Change	NMP 실행 앞뒤에 넣는 memory barrier. 시작 command 는 tile 크기를 실어 buffer offset 을 만든다
3.2.4.2Near-Memory Computation	channel 의 모든 PE 를 command 하나로 구동. weight tile 하나의 계산 단위(coarse-grained)이고 NMP controller 가 세부 명령으로 푼다
3.2.4.3Input Global Buffer Data Movement	bank → input global buffer 로 입력 tile 이동
3.2.4.4Local Buffer Data Movement	PE 의 weight/output buffer ↔ 자기 bank 이동. 발행 순서를 조절해 계산과 weight load 를 겹친다

출처: §4.3 p.6

hardware 설계 공간은 세 축이다. ① HB-NMP channel 수(normal channel 과의 배분) ② PE 구조(HB I/O bandwidth, PE 당 MAC 수, 동작 주파수. 같은 연산량이면 낮은 주파수를 골라 에너지를 줄임) ③ input global/weight/output buffer 크기 §4.4 p.6–7. 실험 범위는 5 절의 Table 5 다.

3.3② data-centric dataflow: channel 을 먼저 묶는다

compute-centric 방식은 엔진을 먼저 정하므로, operator 의 weight 가 normal channel 이나 NMP channel 한쪽에만 놓인다. data-centric 방식은 operator 마다 어느 channel 들에 weight 를 둘지 먼저 정하고, 엔진은 그 결과로 따라 정해진다 §5.1 p.7. 아래 그림이 둘의 차이다.

3.3.1

normal channelHB-NMP channelop X 에 묶인 channel

3.3.1.cchannel 을 먼저 묶으면 prefill 때 centralized processor 가 더 많은 channel 을 읽고 decoding 에서는 fission 할 수 있다는 점을 보이는 그림이다.compute-centric 은 operator 를 한 종류 channel 에 가두므로, centralized processor 가 맡은 operator 의 prefill bandwidth 가 줄고 fission 을 탐색할 수 없다 §5.1 p.7. data-centric 은 channel 을 먼저 묶어 두 문제를 함께 푼다. prefill 은 항상 centralized processor 가 실행한다 §5.2 p.8. 그림의 channel 배분(normal 2 + NMP 6)은 Fig.7 예시와 평가의 고정 설계를 따랐다 §5.1 p.8 §7.2 p.10. op X 를 8 channel 전부에 묶은 배치는 예시다(Fig.7 의 F1 은 normal {0,1} + NMP {4,5} 에 묶인다) 논문에 없음.

channel 묶기는 세 단계다. 단계마다 묶음이 한 층씩 작아진다 §5.1 p.7–8.

3.3.2

3.3.2.cMAG·MPG·tier 가 어떤 포함 관계이고, 각 층이 차례 실행인지 동시 실행인지를 보이는 그림이다.MAG 끼리는 차례로, 한 MAG 안의 MPG 끼리는 서로 다른 channel 에서 동시에, MPG 안의 tier 끼리는 의존 순서대로, tier 안의 operator 끼리는 channel 을 더 나눠 동시에 실행한다 §5.3 p.8. 그림의 operator 와 channel 번호는 논문 Fig.7(d) 의 parallel transformer 예시를 옮긴 것이다 §5.1 p.8.

3.3.3

단계	무엇을 정하나	식
3.3.3.1Step 1 MAG 나누기	layer 의 operator 집합 $V$ 를 순서 있는 묶음 $A_0\preceq\dots\preceq A_{M-1}$ 로 나눈다. $A_i\preceq A_j$ 는 $A_i$ 의 operator 가 $A_j$ 에 의존하지 않는다는 뜻. 같은 입력을 쓰는 operator 는 무작위로 합쳐 fission 후보를 만든다. MAG 는 처음에 모든 channel 을 쓴다	Eq.2
3.3.3.2Step 2 coarse-grain binding	MAG 안의 weakly connected component 하나하나가 MPG $P_{(i,j)}$ 다. MPG 마다 channel 집합을 준다. 채널 집합 $C=\{PC_0,\dots,PC_{P-1},NC\}$ 이고 normal channel 은 전부 virtual channel $NC$ 하나로 본다	Eq.3 GCMap
3.3.3.3제약	MPG 끼리 channel 이 겹치지 않고(channel exclusive), 모든 channel 이 어느 MPG 에든 쓰인다(channel utilization)	Eq.4·5
3.3.3.4Step 3 fine-grain binding	MPG 를 의존 순서로 tier $T^{(i,j)}_k$ 로 나누고, tier 안 operator 마다 MPG 의 channel 중 일부를 준다. 같은 두 제약을 따른다	Eq.6 OCMap

출처: §5.1 p.7–8

3.3.4

$A_i$ = $i$ 번째 MAG · $P_{(i,j)}$ = $A_i$ 의 $j$ 번째 MPG · $C$ = channel 집합 · $\mathcal{P}(C)$ = $C$ 의 멱집합(부분집합 전체)

$$\begin{aligned}GCMap_{A_i} &: \{P_{(i,0)},\dots,P_{(i,N-1)}\}\\ &\to \mathcal{P}(C)\setminus\{\emptyset\}\end{aligned}$$Eq.3 · §5.1 p.7

MPG 마다 비지 않은 channel 부분집합 하나를 고르는 함수다. OCMap(Eq.6)은 같은 꼴로, tier 안 operator 마다 그 MPG 의 channel 중 부분집합을 고른다 §5.1 p.8.

Fig.7 — 3.3.5.cdata-centric dataflow 가 operator 에 memory channel 을 MAG → MPG → tier 세 단계로 묶고, 두 종류 channel 에 걸친 operator 는 fission 한다는 점을 예시로 보이는 그림이다.Figure 7: Operator-Channel Binding in H2-LLM's Data-Centric Dataflow Abstraction. (p.7) normal channel 2 개와 NMP channel 6 개를 가정한 parallel transformer 예시다. (a) operator graph 에서 짙은 원은 FC, 흰 원은 attention operator 다. (b) MAG 두 개 $A_0\preceq A_1$ 로 나누고, 아래 작은 그래프처럼 각 MAG 가 channel 8 개를 모두 쓴다. (c) $A_0$ 는 MPG 셋 {Q,K,QK}·{V}·{F3}, $A_1$ 은 둘 {F1,F2}·{SV,O} 로 나뉘고 MPG 마다 channel 을 받는다. (d) tier 안에서 다시 channel 을 나눈다. 예를 들어 $T^{(0,0)}_0$ 에서 Q 는 NMP {4,5}, K 는 normal {0,1} 을 받는다 §5.1 p.8.

3.4엔진 정하기와 실행 순서

channel 이 정해지면 엔진이 따라 정해진다. prefill 은 prompt 가 수백~수천 token 이라 모두 centralized processor 가 실행한다. decoding 에서 operator 가 normal channel 에만 있으면 centralized processor, NMP channel 에만 있으면 NMP PE 가 실행하고, 둘 다에 걸치면 fission 한다. GEMM 은 출력 차원 $N$ 을 둘로 나누고, attention 은 GEMM 단위로 나눠 두 엔진이 서로 간섭하지 않는다 §5.2 p.8.

Fig.8 — 3.4.1.cFig.7 의 channel 묶기를 따르면 decoding 에서 독립 operator 들이 서로 다른 channel 에서 동시에 돌고, 동기화는 정해진 세 지점에서만 일어난다는 점을 보이는 그림이다.Figure 8: H2-LLM's Layer Execution Flow in Decoding Stage. (p.8) Fig.7 예시의 decoding 실행을 논리 시간으로 그렸다. 세로는 channel(normal 0–1, NMP 0–5), 가로는 시간이다. $A_0$ 에서 MPG 셋이 VPU 4·2·2 개를 나눠 받아 동시에 돌고, $A_1$ 은 VPU 4·4 개다. 회색은 centralized processor, 파랑은 NMP, 노랑은 둘이 함께(fission)다. 동기화는 (1) MAG 의 마지막 operator 끼리, (2) tier 사이, (3) fission 한 operator 의 두 부분 사이에서 일어난다. VPU 가 모자라면 생기는 (4) 는 이 예시에 없다 §5.3 p.8.

dataflow 설계 공간은 MAG 나누기, MAG 마다 GCMap, tier 마다 OCMap, fission operator 의 두 엔진 분할 비율 넷이다 §5.4 p.8. 논문은 이 추상화가 H2-LLM hardware 에 묶이지 않고 NMP 이종 가속기 전반에 쓸 수 있다고 쓴다 §5 p.7.

3.5③ DSE framework: genetic algorithm 으로 함께 찾기

Fig.9 — 3.5.1.chardware 설정과 dataflow 를 따로 고르지 않고 genetic algorithm 하나로 함께 탐색한다는 점을 보이는 그림이다.Figure 9: Overview of H2-LLM's DSE Framework. (p.9) 입력은 workload(모델·batch·prompt/생성 길이), 후보 hardware 설정 목록, DSE 설정(반복 횟수·목표)이다. model parser 가 operator graph 와 shape 를 뽑고, exploration engine 이 ❶ 무작위 초기 population → ❷ capacity checker 로 channel 용량을 넘는 individual 제거 → ❸ 시뮬레이터로 latency·energy 평가 → ❹ selector 가 top-K 선택 → ❺ 되돌려 → ❻ 유전 연산으로 다음 세대를 만든다. 출력은 최적 hardware·dataflow 와 성능 보고서다 §6.1–6.2 p.8–9.

유전 연산 OP1~OP5 와 compile 흐름

3.5.2

연산	남기는 것	다시 뽑는 것
3.5.2.1OP1 re-sample	없음	hardware + dataflow 전부
3.5.2.2OP2 mutate	hardware	dataflow 전부
3.5.2.3OP3 mutate	hardware, MAG	GCMap, OCMap, 분할 비율
3.5.2.4OP4 mutate	hardware, MAG, GCMap	OCMap, 분할 비율
3.5.2.5OP5 crossover	두 부모 중 한쪽 hardware, 겹치지 않는 MAG 를 번갈아	남은 operator 의 MAG, GCMap, OCMap, 분할 비율

출처: §6.2 p.9

workload 가 여러 개면 individual 마다 모든 workload 의 dataflow 를 뽑고 가중 평균 성능으로 고른다 §6.2 p.9. compile 은 operator 별 실행 흐름 생성(NMP operator 는 Eq.1 로 분산, 수작업 template 으로 tile 크기 결정) → layer 실행 흐름에 동기화 삽입 → centralized processor 의 controller 로 전달 순이다. template 자동 생성은 향후 과제라고 쓴다 §6.3 p.9.

4구현과 실험 방법

실제 칩이 아니라 시뮬레이션이다. NMP PE 는 Ramulator2 를 확장해, centralized processor operator 는 Tileflow 성능 모델로 평가해 결과를 합친다 §7.1 p.10.
FPU 는 Chisel 로 구현해 40 nm 로 합성했고, HB 면적은 저자들의 실제 tape-out 값을 쓴다. DSE framework 는 공개돼 있다(github leesou/H2-LLM-ISCA-2025) §7.1 p.10 A p.13.

면적·에너지 수치와 artifact

4.1

항목	값	근거
4.1.1FPU 면적 (0.4/0.6/0.8/1.0 GHz, 40 nm)	0.31/0.44/0.59/0.77 mm²	§7.1 p.10
4.1.2SRAM 밀도	2.72 mm²/MB	§7.1 p.10
4.1.3NMP PE 하나의 면적	6.76 mm²	§7.1 p.10
4.1.4HB I/O 핀 속도	0.4 Gbps	§7.1 p.10
4.1.5HB 핀 128/256/512/1024 → PE 당 bandwidth	6.4~51.2 GB/s	§7.1 p.10
4.1.6그때 HB controller 가 PE 면적에서 차지하는 비율	4.6/10.7/19.7/40.2%	§7.1 p.10
4.1.7MAC 에너지: centralized processor (10 nm)	0.682 pJ	§7.1 p.10
4.1.8MAC 에너지: HB-NMP (0.4~1.0 GHz)	0.974~1.365 pJ	§7.1 p.10
4.1.9MAC 에너지: in-die NMP (200 MHz / 1 GHz)	1.172 / 1.849 pJ	§7.1 p.10
4.1.10memory access 에너지: LPDDR5 interface / HB I/O	7.0 / 0.88 pJ/bit	§7.1 p.10
4.1.11SRAM access 에너지	0.027 pJ/bit	§7.1 p.10

artifact 는 onnx 기반 model parser 와 genetic algorithm exploration engine 을 담는다. 다만 data privacy 문제로 시뮬레이터를 제공하지 못해 artifact 는 대략적인 성능 모델을 쓰고 에너지 평가는 건너뛰며, 결과가 논문과 조금 다를 수 있다고 밝힌다 A.6 p.14.

5평가

OPT 6.7B(MHA)·LLaMA3 8B(GQA)·PaLM 8B(MQA), FP16, batch 1/4/16, 4 dataset 의 평균 길이로 CP (baseline)·ID-NMP·ID-NMP+ 와 비교했다. H2-LLM 은 Table 5 의 밑줄 친 고정 설계 하나로 비교한다 §7.1–7.2 p.9–10.
ID-NMP+ 대비 전체 2.71×, decoding-heavy 3.81×, prefill-heavy 1.94× 빠르고 §7.2 p.11, 같은 hardware 에서 dataflow 만 바꿔도 FC-NMP·CC-NMP 대비 1.37×·1.11× 다 §7.3 p.11.

5.1실험 설정

5.1.1.c비교 모델 셋은 크기는 비슷하지만 attention 이 MHA·GQA·MQA 로 달라, attention 의 arithmetic intensity 가 서로 다르다는 점을 보이는 표다.Table 4: Model Configurations Used for Evaluation. (p.9)세 모델 모두 32 layer, hidden 4096 이다. (Q head, KV head) 가 OPT (32,32)=MHA, LLaMA3 (32,8)=GQA, PaLM (16,1)=MQA 라 attention 의 arithmetic intensity 가 서로 다르다 §7.1 p.9.

5.1.2.cH2-LLM hardware 탐색 범위와, 주 비교에 쓴 고정 설계(밑줄 값)를 보이는 표다.Table 5: H2-LLM's Architecture DSE Parameters. (p.10)hardware 설계 공간이다. 밑줄 값이 7.2·7.3 절의 고정 설계다: NMP channel 6 개, PE 당 FPU 8 개, 0.6 GHz, HB I/O 25.6 GB/s, input global / weight / output buffer 32 / 32 / 4 KB §7.2 p.10. 밑줄 값은 그림에서 읽은 것이고 본문은 "underlined" 라고만 쓴다.

5.1.3.cPE 면적이 고정되면 HB bandwidth 를 키울수록 넣을 수 있는 FPU 수가 줄어든다는 trade-off 를 숫자로 보이는 표다.Table 6: Max FPU Num./PE under Different HB Bandwidths. (p.10)PE 면적 안에서 HB bandwidth 와 주파수별로 넣을 수 있는 최대 FPU 수다. bandwidth 가 클수록 controller 가 면적을 먹어 FPU 가 줄어든다(51.2 GB/s · 1 GHz 면 2 개). 굵은 값은 bandwidth 마다 연산량이 가장 큰 설정으로 Fig.18 에 쓴다 §7.1 p.10 §7.4 p.12.

5.1.4

항목	설정	근거
5.1.4.1centralized processor	TPU-like. 128×128 systolic array 8 개 + SIMD-128 VPU 8 개 @1 GHz, on-chip SRAM 128 MB	§7.1 p.10
5.1.4.2memory system	channel 8 개, channel 당 256 MB bank 16 개, 외부 interface LPDDR5-6400	§7.1 p.10
5.1.4.3CP (baseline)	NMP 가 연산을 더 주는 것을 감안해 centralized processor 연산량을 2 배	§7.1 p.10
5.1.4.4ID-NMP	PE 가 bank 마다 하나, 6.4 GB/s, 16 MAC @200 MHz. channel 당 102.4 GFLOPS · 102.4 GB/s	§7.1 p.10
5.1.4.5ID-NMP+	AiM PE (16 MAC @1 GHz). 상용 in-die NMP 중 최대 연산량. ID-NMP(+) 는 모든 channel 이 NMP channel 이고, 나머지 설정은 H2-LLM 과 같다	§7.1 p.10
5.1.4.6dataflow	ID-NMP·ID-NMP+·H2-LLM 모두 data-centric dataflow 를 쓴다	§7.2 p.10
5.1.4.7DSE 예산	genetic algorithm 100 회 반복, 세대당 5k individual, top-50 선택	§7.2 p.10
5.1.4.8workload	token 수는 Table 1 네 dataset 의 평균, batch 1/4/16	§7.1 p.9

고정 설계의 숫자를 풀면, PE 하나는 FPU 8 × MAC 16 × 0.6 GHz × 2 FLOP = 153.6 GFLOPS, channel 하나(PE 16 개)는 약 2.46 TFLOPS 와 HB bandwidth 409.6 GB/s 다. 연산:bandwidth 가 6 FLOP/Byte 로 Table 2 의 in-die NMP(1~2)보다 크다. centralized processor 는 약 262 TFLOPS, LPDDR5-6400 8 channel 의 외부 bandwidth 는 Table 2 의 "8× external" 에서 역산하면 102.4 GB/s 다 논문에 없음 (요약자 계산).

5.2baseline 과 비교

Fig.10 — 5.2.1.c모든 모델·batch·dataset 에서 H2-LLM 이 in-die NMP 와 centralized processor 만 쓰는 구성보다 빠르고, decoding energy efficiency 도 높다는 점을 보이는 그림이다.Figure 10: Performance Comparison against Baselines. (p.10) 위 줄은 end-to-end speedup, 아래 줄은 decoding energy efficiency 이고 둘 다 ID-NMP+(노랑)=1 로 정규화했다. 가로는 모델 셋 × batch 1/4/16 × dataset 넷이다. 모든 경우 H2-LLM(흰 막대)이 가장 높다 §7.2 p.10–11. CP (baseline) 는 외부 bandwidth 가 좁아 ID-NMP+ 의 27% 이고 batch 가 작을수록 더 뒤진다. ID-NMP 는 batch 1/4 에서 CP 의 3.03× 지만 batch 16 에서는 CP 의 71% 다. ID-NMP+ 도 CP·ID-NMP 중 나은 쪽의 1.76× 에 그친다. 논문은 이 차이를 DRAM 공정의 연산 자원 부족으로 설명한다. H2-LLM 은 decoding-heavy HE·SG 에서 3.81×, prefill-heavy LB·LG 에서 1.94× 다. energy efficiency 는 ID-NMP·ID-NMP+ 대비 1.48·1.54× 인데, 논문은 on-chip SRAM buffer 재사용 덕이라고 쓴다. CP 는 LPDDR5 interface 의 높은 접근 에너지(7.0 vs HB 0.88 pJ/bit) 때문에 가장 낮다 §7.2 p.10–11. prefill-heavy 에서 배율이 작은 것은 prefill 을 모든 설계가 centralized processor 로 실행하기 때문으로 보인다 해석.

Fig.11 — 5.2.2.c길이가 다른 request 를 섞은 batch 에서도 H2-LLM 의 우위가 유지된다는 점을 보이는 그림이다.Figure 11: Performance Comparison under Mixed Scenarios. (p.10) 네 dataset 을 고르게 섞어 request 길이가 서로 다른 batch 4/8/16 을 만든 실험이다. ID-NMP+ 대비 CP (baseline) 24%, ID-NMP 49%, H2-LLM 3.24× (geomean) 다 §7.2 p.11.

5.3dataflow 만 바꿔 보기

Fig.12 — 5.3.1.chardware 를 고정하고 dataflow 만 바꿔도 성능 차이가 크며, data-centric 탐색이 다섯 dataflow 중 가장 빠르다는 점을 보이는 그림이다.Figure 12: Comparison Against Existing Dataflow Designs. (p.11) hardware 는 고정하고 dataflow 만 다섯 가지로 바꿨다. FC-NMP(모든 FC 를 NMP) = 1 로 정규화했다. Attn-NMP(attention 만 NMP)는 14%, Attn-NMP-Split(+FFN 고정 fission)은 그 1.11×, CC-NMP(SpecPIM 식 compute-centric 탐색)는 FC-NMP 의 1.24×, H2-LLM 은 FC-NMP·CC-NMP 대비 1.37×·1.11× 다 §7.3 p.11. Attn-NMP 는 low-batch FC 를 NMP 로 가속하지 못해 가장 느리다. FC-NMP 는 PaLM 8B 와 batch 1 에서는 탐색 방식과 비슷하지만, MHA·GQA 모델의 큰 batch 에서는 memory-bound attention 이 centralized processor 에 남아 느려진다. CC-NMP 는 탐색으로 decoding 을 가속하지만 prefill 을 모르므로, PaLM 8B · LooGLE 에서는 FC-NMP 보다 5% 느리다 §7.3 p.11.

Fig.13 — 5.3.2.chybrid bonding hardware 를 써도 dataflow 를 잘못 고르면 in-die NMP 보다 느릴 수 있다는 점을 보이는 그림이다.Figure 13: Dataflow Designs on H2-LLM v.s. ID-NMP+. (p.11) 같은 다섯 dataflow 를 H2-LLM hardware 에 올린 결과를 ID-NMP+ (빨간 점선=1)와 비교했다(네 dataset geomean). Attn-NMP(-Split) 은 ID-NMP+ 의 28%(31%), FC-NMP·CC-NMP 는 1.98×·2.45×, H2-LLM 은 2.71× 다. 논문은 hybrid bonding hardware 만으로는 부족하고 dataflow 탐색이 있어야 이득을 다 낸다고 결론짓는다 §7.3 p.11.

Fig.14 — 5.3.3.cdecoding 을 가속한 뒤에는 prefill 이 전체 시간의 큰 몫을 차지하고, data-centric dataflow 가 compute-centric 대비 prefill 을 줄인다는 점을 보이는 그림이다.Figure 14: Prefill Latency Ratio and Prefill Speedup. (p.11) 막대는 H2-LLM end-to-end latency 중 prefill 비율(왼쪽 축), 선은 CC-NMP 대비 prefill speedup(오른쪽 축)이다 §7.3 p.11. decoding 을 충분히 가속한 뒤에는 prefill 이 decoding-heavy 에서 12~26%, prefill-heavy 에서 36~90% 를 차지한다. data-centric dataflow 는 CC-NMP 대비 prefill 을 1.27× (geomean) 줄여 end-to-end 가 좋아진다 §7.3 p.11. 2 절의 그림대로 prefill 때 centralized processor 가 operator 의 weight 를 더 많은 channel 에서 읽을 수 있기 때문으로 보인다 해석.

Fig.15 · Fig.16 · Fig.17 — 설계를 다 탐색하면, 동기화·전송 overhead

Fig.17 — 5.3.6.cGEMM 을 channel 에 나누는 $(T_K, T_N)$ 을 잘못 고르면 전송 overhead 가 최대 5.4× 커지고, Eq.1 로 고른 값은 최적과 같다는 점을 보이는 그림이다.Figure 17: Comparison among Different Tiling Factors. (p.12) OPT 6.7B, NMP channel 8 개, context 2048, batch 4 에서 operator 마다 $(T_K, T_N)$ 네 가지의 전송 overhead 를 최소값=1 로 정규화했다. 회청색 막대는 입력 전송, 노란 막대는 출력 전송이다. 최악의 tiling 은 최적보다 1.5~5.4× 크고, H2-LLM 이 Eq.1 로 고른 값(옅은 파란 별)은 최적(빨간 별)과 같다 §7.3 p.12. 위 계산기와 같은 trade-off 다.

5.4설계 공간 분석 (LLaMA3 8B)

논문은 모델들의 경향이 비슷해 LLaMA3 8B 로 분석하고, 결과를 takeaway 6 개로 정리한다 §7.4 p.12.

Fig.18 — 5.4.1.cbatch 가 작으면 bandwidth 가, 크면 연산이 중요해지므로 둘을 균형 있게 나눈 설계가 가장 안정적이라는 점을 보이는 그림이다.Figure 18: Computation Bandwidth Trade-off Analysis. (p.12) NMP channel 4 개, buffer 32/32/4 KB 로 두고, 행은 HB bandwidth, 열은 (FPU 수, 주파수) 다. 칸의 숫자는 네 dataset 평균 decoding 성능(왼쪽 위=1)이고 괄호는 순위다 §7.4 p.12. batch 1 은 성능이 HB bandwidth 에 비례한다(51.2 GB/s 가 7.65). batch 4 는 6.4 → 25.6 GB/s 까지는 오르지만 51.2 GB/s 에서는 controller 면적 때문에 연산이 모자라 더 오르지 않는다. batch 16 은 중간 비율이 가장 좋다. 세 batch 평균 순위가 가장 좋은 것은 (8 FPU @0.6 GHz, 25.6 GB/s) 다 §7.4 p.12. Takeaway 1·2: batch 가 커지면 연산 자원을 더 주고, 연산과 bandwidth 를 균형 있게 나눠야 한다.

Fig.19 · Fig.20 · Fig.21 — buffer 크기, channel 배분, centralized processor 크기

5.4.3.c총 연산량과 bandwidth 를 고정한 채 NMP channel 수만 바꾸는 실험 설정을 보이는 표다.Table 7: Resource Distribution Exploration Setup. (p.13)총 연산량과 bandwidth 를 고정하고 NMP channel 2/4/8 개에 나눈 설정이다. channel 이 늘면 PE 당 FPU 와 HB bandwidth 가 반씩 준다 §7.4 p.13.

Fig.20 — 5.4.4.c같은 자원을 NMP channel 4 개에 나눌 때가 가장 좋고, 8 개로 지나치게 나누면 channel 당 처리 능력이 약해지고 fission 을 못 써 오히려 떨어진다는 점을 보이는 그림이다.Figure 20: Performance Analysis of Resource Distribution. (p.13) NMP channel 2 → 4 개에서 end-to-end 성능이 크게 오르고, 4 → 8 개는 거의 그대로이며 batch 16 에서는 오히려 떨어진다 §7.4 p.13. 논문 설명: NMP memory 용량이 늘면 NMP 에 둘 operator 가 늘어난다. 하지만 channel 이 너무 많으면 channel 당 처리 능력이 작아지고, 8 개 전부 NMP channel 이면 normal channel 이 없어 operator fission 을 쓸 수 없다 §7.4 p.13. Takeaway 5·6.

Fig.21 — 5.4.5.cprefill 은 centralized processor 가 맡으므로, centralized processor 연산량을 키우면 특히 prefill-heavy workload 가 크게 빨라진다는 점을 보이는 그림이다.Figure 21: Performance Analysis of Centralized Processor. (p.13) systolic array 크기로 centralized processor 연산량을 CPU(Sapphire Rapids AMX, 32 TFLOPS) ~ GPU(A100, 312 TFLOPS) 에 맞춰 바꿨다. 연산량이 클수록 성능이 오르고, prefill-heavy LB·LG 에서 더 크게 오른다(LG 는 최대 약 9×). 논문은 prefill 이 강한 centralized processor 로 빨라지고 decoding 은 거의 그대로이기 때문이라고 쓴다 §7.4 p.13.

6결론과 한계

논문의 결론은 H2-LLM 이 edge low-batch LLM inference 용 첫 hybrid bonding 기반 이종 가속기이며, hybrid bonding 의 연산-bandwidth trade-off 를 설계 공간에 넣고 data-centric dataflow 로 이종 구조를 활용해, in-die NMP 이종 가속기 대비 geomean 2.72× 빠르고 energy efficiency 가 1.48× 라는 것이다 §8 p.13.
논문에 limitation 절은 없다. 본문에 적힌 향후 과제는 NMP operator template 의 자동 생성뿐이다 §6.3 p.9. 아래는 요약자가 정리한 한계다 논문에 없음.

6.1

한계	근거
6.1.1모든 결과가 시뮬레이션이다. HB 면적은 tape-out 값이지만 H2-LLM 전체 칩은 만들지 않았고, artifact 에는 시뮬레이터가 빠져 있다	§7.1 p.10, A.6 p.14
6.1.2prefill 은 언제나 centralized processor 가 실행한다. prefill-heavy 에서 배율이 decoding-heavy 의 절반 수준(1.94× vs 3.81×)이고, Fig.21 처럼 성능이 centralized processor 크기에 크게 좌우된다	§5.2 p.8, §7.2 p.11, §7.4 p.13
6.1.3workload 는 dataset 평균 길이를 batch 에 고정한 것이다. 실제 request 도착·길이 분포와 continuous batching, KV cache 가 자라는 동안의 재배치는 다루지 않는다(혼합 실험 Fig.11 은 네 dataset 을 고르게 섞은 것)	§7.1 p.9, §7.2 p.11
6.1.4context 는 2048 로 잡았다. 긴 context 에서 KV cache 가 channel 용량을 얼마나 차지하는지는 capacity checker 로 거르기만 하고 따로 분석하지 않는다	§2.2 p.3, §6.2 p.9
6.1.5energy efficiency 는 decoding 단계만 잰다. end-to-end 에너지나 HB 적층·logic die 의 제조 비용·수율은 비교하지 않는다	§7.2 p.11 (비용은 §3.2 에서 "less advanced logic technology" 로 언급만)
6.1.6요약자 계산으로 실험 centralized processor 는 약 262 TFLOPS / 102.4 GB/s ≈ 2,560 FLOP/Byte 로, 논문이 든 edge processor 비율 500~1000 보다 크다. 이 차이가 prefill bandwidth 논리(§3.3)의 크기에 주는 영향은 원문에 명시 없음	§3.3 p.5, §7.1 p.10 (계산은 4·5 절)
6.1.7genetic algorithm 은 최적을 보장하지 않는다. 탐색 예산(100 회 × 5k)에 대한 수렴 분석이 없다	§7.2 p.10

7관련 연구

논문은 관련 연구 절을 따로 두지 않고, 2.3 절(NMP 이종 가속기)과 Table 2·3 으로 비교한다 §2.3 p.3 §3 p.3–5.
Table 3 의 비교 다섯 시스템 중 data-centric·prefill-aware 탐색과 flexible fission 을 함께 하는 것은 H2-LLM 뿐이다 §3.3 p.5.

연구	한 일	H2-LLM 과 차이
7.2.1Samsung HBM-PIM + MI100	모든 FC 를 NMP 로 보내 single-batch GPT-J 6B 가속	in-die NMP, FC 고정 배치 (§2.3 p.3)
7.2.2SK Hynix GDDR6-AiM	MHA 를 NMP, FC 를 GPU 로	in-die NMP, 고정 배치 (§2.3 p.3)
7.2.3AttAcc · NeuPIMs	NMP HBM 으로 large-batch cloud 의 MHA 가속. AttAcc 는 FFN 고정 fission	cloud·HBM 대상, 고정 배치 (§2.3 p.3, Table 3)
7.2.4SpecPIM	speculative inference 용으로 centralized 가속기와 NMP 사이 mapping 탐색	compute-centric, prefill-unaware, fission 없음 (§3.3 p.4–5)
7.2.5Duplex	HBM logic die 에 PE 를 두어 연산량 증가	HBM 전력 때문에 edge 에 부적합하다고 논문은 쓴다 (§3.2 p.4)
7.2.6LPDDR5-PIM · LPDDR5X-AiM	on-device LLM 용 개념 제품	in-die NMP, 연산:bandwidth 1~2 (§2.3 p.3, Table 2)
7.2.7기존 HB-NMP	추천 모델·vision 모델 가속에 hybrid bonding NMP 적용	LLM 과 연산-bandwidth trade-off 탐색은 아님 (§3.2 p.4)

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

Fig.1~21 과 실험 설정 Table 을 슬라이드 순서대로 놓고, 슬라이드마다 말할 내용을 2~4 문장으로 적었다. Eq.1 유도·command 세부·유전 연산 종류는 빼고, 문제 → 설계 → 실험 환경 → 평가 흐름만 남겼다.
발화문은 요약자가 쓴 것이고 논문에 없음, 수치와 주장은 원문에서 확인한 것만 넣었다. 각 슬라이드 옆 시간은 권장 분량이다.

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

도입 · 40 초

오늘 소개할 논문은 ISCA 2025 의 H2-LLM 입니다. edge 기기에서 batch 가 작은 LLM inference 를 위해, DRAM 을 logic die 위에 hybrid bonding 으로 쌓아 memory 옆 연산기를 키운 가속기와, operator 를 어느 memory channel 에 둘지 정하는 dataflow 를 함께 설계합니다. 결론부터 말하면 기존 in-die NMP 가속기 대비 geomean 2.72 배 빠르고, decoding 에너지 효율은 1.48 배입니다. 결과는 모두 시뮬레이션입니다.

1 부 · 문제 (약 4.5 분)

위 띠는 batch 크기 축으로, cloud 는 수백이지만 edge 는 1 에서 수십입니다. 아래 세 칸은 edge 서비스의 예입니다. (a) 개인 chat helper 는 사용자 한 명, (b) 가상 비서는 app 여러 개, (c) 안내 bot 은 사용자 수십 명을 받습니다. 그래서 이 논문은 batch 1~16 을 기준으로 봅니다.

(a) 는 decoder layer 의 operator 구성입니다. Q·K·V, QK, SV, O 와 FFN 의 F1·F2 가 있고, 이 operator 들을 어디서 실행할지가 오늘의 주제입니다. (b) 는 attention 변형으로, MHA 는 Q head 마다 KV head 가 따로, MQA 는 하나를 공유, GQA 는 그 중간입니다. 공유할수록 attention 이 같은 KV 로 더 많이 계산합니다. (c) GLU 는 FFN 에 F3 를 더하고, (d) parallel transformer 는 attention 과 FFN 을 동시에 돌릴 수 있게 합니다.

edge workload 는 성격이 다양합니다. HumanEval 과 ShareGPT 는 prompt 와 생성 길이가 비슷해 decoding 비중이 크고, LongBench 와 LooGLE 은 prompt 가 수십 배 길어 prefill 비중이 큽니다. 그래서 prefill 과 decoding 을 둘 다 빠르게 해야 한다는 것이 논문의 전제입니다.

첫 번째 문제입니다. LLaMA3 8B 의 operator 를 Samsung LPDDR5-PIM 8 channel 에서 roofline 으로 본 그림입니다. x 축은 1 Byte 당 FLOP 수, 삼각형은 FC 를 batch 1~16 으로, 원은 attention 을 KV head 수별로 찍었습니다. 주황 수평선이 memory 안 연산기의 천장인데 아주 낮아서, batch 가 8 이상이거나 KV head 가 4 이하면 이득이 사라집니다. 그런데 그 지점에서 검은 선의 centralized processor 는 아직 bandwidth 에 막혀 있어, 두 쪽 모두 놀게 됩니다.

원인은 연산기를 DRAM 공정 안에 넣었다는 데 있습니다. DRAM 공정은 logic 보다 transistor 가 3 배 느리고 밀도가 10 배 낮습니다. 대안이 (a) 의 hybrid bonding 으로, DRAM die 를 logic die 위에 Cu-Cu 로 직접 붙여 연결이 촘촘하고 전력도 적습니다. 그런데 (b) 처럼 bank 당 핀을 1024 개로 늘리면 controller 가 logic die 의 40% 를 차지합니다. 핀을 늘리면 bandwidth 는 늘지만 연산기 자리가 줄어드는 trade-off 가 두 번째 문제입니다.

세 번째 문제는 dataflow 입니다. 기존 설계 대부분은 FC 만, 또는 attention 만 NMP 로 보내는 식으로 고정합니다. SpecPIM 은 탐색을 하지만 연산 엔진을 먼저 정하는 compute-centric 방식이라, centralized processor 가 맡은 operator 는 일부 channel 의 bandwidth 만 쓰게 되고 prefill 이 느려질 수 있습니다. H2-LLM 은 channel 을 먼저 정하는 data-centric 탐색으로 이것을 풉니다.

2 부 · 설계 (약 4.5 분)

세 패널은 바깥에서 안으로 확대한 그림입니다. (a) 전체는 centralized processor 와, 일반 memory channel 과 HB-NMP channel 이 섞인 memory system 입니다. (b) HB-NMP channel 은 위쪽 DRAM die 의 bank 마다 HB I/O 가 있고, 아래 logic die 에 bank 마다 PE 와 HB controller, 그리고 PE 들이 공유하는 input global buffer 가 있습니다. (c) PE 하나는 FPU 여러 개와 weight·output buffer 로 이뤄지고, 행렬 곱만 합니다. softmax 같은 나머지는 centralized processor 몫입니다.

channel 하나 안에서 행렬 곱을 하는 순서입니다. weight 와 출력을 열 방향으로 bank 마다 나눠, PE 마다 서로 다른 출력 조각을 만듭니다. ❶ 입력을 공유 buffer 로 모으고, ❷ 각 PE 가 자기 bank 에서 weight 를 읽어 ❸ 곱하고 더한 뒤, ❹ 출력을 자기 bank 에 씁니다. PE 끼리 통신이 없어서 network 를 빼고 그 면적을 연산에 줬습니다.

핵심 그림입니다. 일반 channel 2 개, NMP channel 6 개를 가정한 parallel transformer 예시이고 네 단계로 읽습니다. (a) operator graph 에서 출발해, (b) 차례로 실행할 묶음 MAG 두 개로 나눕니다. (c) 각 MAG 안에서 서로 독립인 묶음 MPG 마다 channel 을 따로 줍니다. 예를 들어 V 는 NMP 2·3 번, F3 는 NMP 0·1 번입니다. (d) 마지막으로 묶음 안 operator 마다 channel 을 더 나눕니다. QK 처럼 일반 channel 과 NMP channel 을 함께 받은 operator 는 둘로 쪼개 centralized processor 와 PE 가 나눠 계산하는데, 이것을 operator fission 이라 합니다.

앞의 binding 이 decoding 에서 어떻게 실행되는지를 시간축으로 그렸습니다. 세로는 channel, 가로는 시간이고 색은 회색이 centralized processor, 파랑이 NMP, 노랑이 둘이 함께인 fission 입니다. 같은 MAG 안의 묶음들은 서로 다른 channel 과 vector unit 을 받아 동시에 돌고, MAG 경계와 묶음 안 단계 사이, fission 의 두 조각 사이에서만 동기화합니다. prefill 은 이 그림과 달리 모두 centralized processor 가 실행합니다.

hardware 설정과 dataflow 를 함께 고르는 DSE framework 입니다. 왼쪽에 workload, 후보 hardware, 탐색 설정을 넣으면 model parser 가 operator graph 를 뽑습니다. 가운데 exploration engine 은 genetic algorithm 으로, 후보를 무작위로 만들고, memory 용량을 넘는 것을 버리고, 시뮬레이터로 평가해 상위 후보로 다음 세대를 만듭니다. 오른쪽으로 최적 hardware 와 dataflow 가 나옵니다.

실험 환경 · 약 2 분

모델은 OPT 6.7B, LLaMA3 8B, PaLM 8B 이고 모두 FP16 입니다. 크기는 비슷하지만 attention 이 각각 MHA, GQA, MQA 라서 attention 의 계산 밀도가 서로 다릅니다. batch 는 1·4·16, 길이는 앞의 네 dataset 평균을 씁니다.

실제 칩이 아니라 시뮬레이션입니다. centralized processor 는 TPU 와 비슷하게 128×128 systolic array 8 개와 vector unit 8 개를 1 GHz 로 두고 SRAM 128 MB 를 줍니다. memory 는 LPDDR5-6400 channel 8 개, channel 당 256 MB bank 16 개입니다. 이 표가 NMP 쪽 탐색 범위이고, 밑줄 친 값, 즉 NMP channel 6 개, PE 당 FPU 8 개 0.6 GHz, HB 25.6 GB/s 가 주 비교에 쓴 고정 설계입니다. NMP 는 Ramulator2 를 확장해, centralized processor 는 Tileflow 모델로 평가했고, FPU 는 40 nm 로 합성했으며 HB 면적은 저자들의 실제 tape-out 값입니다.

이 표가 trade-off 를 숫자로 보여 줍니다. PE 면적 안에서 HB bandwidth 를 6.4 에서 51.2 GB/s 로 올리면, 1 GHz 기준 넣을 수 있는 FPU 가 8 개에서 2 개로 줄어듭니다. 비교 대상은 centralized processor 만 쓰되 연산량을 2 배로 준 CP, Samsung LPDDR5-PIM 방식의 ID-NMP, 그리고 연산을 키운 AiM 방식의 ID-NMP+ 입니다.

3 부 · 평가 (약 7 분)

주 결과입니다. 위 줄은 속도, 아래 줄은 decoding 에너지 효율이고, 모두 노란 ID-NMP+ 를 1 로 놓았습니다. 가로는 모델 셋, batch 셋, dataset 넷입니다. CP 는 bandwidth 가 좁아 ID-NMP+ 의 27% 이고, ID-NMP 는 batch 16 이 되면 오히려 CP 보다 느립니다. 흰 막대 H2-LLM 은 모든 경우 가장 빠르고, decoding 비중이 큰 HE·SG 에서 3.81 배, prefill 비중이 큰 LB·LG 에서 1.94 배입니다. 에너지 효율은 ID-NMP 대비 1.48 배입니다.

네 dataset 을 고르게 섞어 길이가 다른 request 를 함께 처리한 경우입니다. batch 4·8·16 모두에서 H2-LLM 이 ID-NMP+ 대비 평균 3.24 배로, 섞인 workload 에서도 결론이 같습니다.

이제 hardware 는 그대로 두고 dataflow 만 바꿉니다. 세 줄은 모델, 막대 다섯 개는 attention 만 NMP, attention 만 NMP 에 FFN 고정 분할, FC 만 NMP, SpecPIM 식 탐색, 그리고 H2-LLM 이며 FC-NMP 를 1 로 놓았습니다. attention 만 보내는 방식은 14% 로 가장 느립니다. FC 만 보내는 방식은 PaLM 에서는 괜찮지만 MHA·GQA 의 큰 batch 에서 attention 이 발목을 잡습니다. H2-LLM 은 FC-NMP 대비 1.37 배, SpecPIM 식 대비 1.11 배입니다.

같은 다섯 dataflow 를 ID-NMP+ 와 비교하면, 빨간 점선 1 아래로 떨어지는 dataflow 도 있습니다. attention 만 보내면 hybrid bonding hardware 를 쓰고도 ID-NMP+ 의 28% 입니다. hardware 만으로는 부족하고 dataflow 를 함께 찾아야 2.71 배가 나온다는 그림입니다.

SpecPIM 식 탐색보다 왜 빠른지를 보여 줍니다. 막대는 전체 시간 중 prefill 비율로, decoding 을 빠르게 만든 뒤에는 prefill 이 prefill-heavy dataset 에서 최대 90% 를 차지합니다. 선은 SpecPIM 식 대비 prefill speedup 으로 평균 1.27 배입니다. channel 을 먼저 묶어 prefill 때 더 많은 channel 의 bandwidth 를 쓰는 효과로 보입니다.

고정 설계 대신 경우마다 설계를 끝까지 탐색하면 얼마나 더 얻는지입니다. 막대가 속도, 선이 에너지 효율이고 평균 1.38 배, 1.74 배를 더 얻습니다. batch 1 에서는 bandwidth 를 키운 설계가, batch 16 의 OPT 에서는 연산을 키운 설계가 이깁니다.

동기화와 데이터 전송 overhead 는 전체의 1.6~15.7% 이고 대부분이 전송입니다.

행렬을 channel 에 나누는 방법에 따라 전송량이 달라집니다. 입력 쪽을 많이 자르면 partial sum 이 늘고, 출력 쪽을 많이 자르면 입력 복제가 늡니다. 잘못 고르면 최대 5.4 배 손해인데, 논문의 해석식으로 고른 옅은 파란 별이 실제 최적인 빨간 별과 일치합니다.

trade-off 자체를 본 그림입니다. 세 heatmap 은 batch 1·4·16, 세로는 HB bandwidth, 가로는 FPU 수와 주파수이고 칸은 성능과 순위입니다. batch 1 은 bandwidth 가 클수록 좋고, batch 16 은 중간 비율이 가장 좋으며, 51.2 GB/s 는 연산이 모자라 오히려 밀립니다. 세 batch 를 통틀어 FPU 8 개 0.6 GHz, 25.6 GB/s 가 가장 안정적이라 고정 설계로 쓰였습니다.

세 패널은 input, weight, output buffer 를 하나씩 키운 결과입니다. batch 가 크면 input·output buffer 가 중요해져 output buffer 는 최대 2.26 배까지 영향을 주고, weight buffer 는 batch 가 작을 때만 효과가 있습니다. 빨간 별의 32·32·4 KB 에서 이득이 포화됩니다.

위 표처럼 총 자원을 고정하고 NMP channel 2·4·8 개에 나눈 결과입니다. 2 개에서 4 개로 가면 NMP 에 둘 operator 가 늘어 크게 좋아지지만, 8 개로 나누면 channel 하나가 약해지고 일반 channel 이 없어 fission 도 못 해 batch 16 에서는 오히려 떨어집니다.

마지막으로 centralized processor 크기를 CPU 급 32 TFLOPS 에서 A100 급 312 TFLOPS 까지 바꿨습니다. 연산량이 클수록 좋아지고, 특히 prefill 비중이 큰 LooGLE 은 9 배 가까이 오릅니다. prefill 은 centralized processor 몫이므로 NMP 가 아무리 좋아도 중앙 processor 를 충분히 강하게 둬야 한다는 뜻입니다.

마무리 · 45 초

정리하겠습니다. edge 의 작은 batch 에서는 memory 옆 연산기가 유리하지만, DRAM 안에 넣은 연산기는 batch 가 조금만 커져도 힘이 부족했습니다. H2-LLM 은 hybrid bonding 으로 연산기를 logic die 로 옮기고, 연산과 bandwidth 의 균형, 그리고 operator 를 channel 에 묶는 방법까지 함께 탐색해 2.72 배를 얻었습니다. 한계로는 결과가 모두 시뮬레이션이고, prefill 은 여전히 centralized processor 에만 맡기며, 평균 길이로 고정한 workload 라 실제 request 도착 패턴은 다루지 않았다는 점을 들 수 있습니다.