MICRO 2024 · Jin, Rocca, Kim, Kasan, Rhu (KAIST) · Bakhoda (Microsoft) · Aamodt (UBC) · John Kim (KAIST) · DOI 10.1109/MICRO61859.2024.00070

Uncovering Real GPU NoC Characteristics: V100·A100·H100 의 on-chip network 를 실측하고, timing side-channel 과 NoC 설계에 주는 함의를 정리하다

원문 papers/Uncovering_Real_GPU_NoC_Characteristics_-_Implicationson_Interconnect_Architecture.pdf (14쪽, 쪽 번호는 PDF 쪽 = 인쇄 쪽 − 884) · §III-A p.3 = 논문이 그렇게 쓴 절·쪽 · 해석 = 논문 내용에서 요약자가 끌어낸 설명 · 논문에 없음 = 배경지식·예시 · 이 논문은 새 시스템이 아니라 측정(characterization) 논문이라, 3·4 절을 "관측", 5 절을 "함의(평가)" 로 바꿔 구성했다 논문에 없음 · 그림은 누르면 크게 열린다

0한눈에 보기

GPU 의 SM(core) 과 L2 slice 를 잇는 on-chip network(NoC)를 V100·A100·H100 에서 microbenchmark 로 직접 재 보니, SM→L2 slice latency 는 물리 위치에 따라 다르지만(non-uniform) bandwidth 는 거의 같았다(uniform) §I p.1–2.
A100·H100 처럼 칩이 두 partition 으로 나뉜 GPU 는 partition 을 건널 때 latency 와 bandwidth 가 모두 달라진다. 저자들은 이 성질이 timing side-channel 공격·방어와 simulator 의 NoC 가정에 영향을 준다고 보인다 §I p.1.

0.1

0.1.1기 상황

GPU 는 SM 수십~백여 개와 memory partition(MP) 여러 개를 NoC 로 잇는다(V100 SM 80 개 → H100 132 개) TABLE I p.1. 기존 GPU NoC 연구는 대부분 simulator 기반이고, 2D mesh 같은 multi-hop topology 를 가정한 경우가 많다 §II-B p.2.

0.1.2승 문제

실제 GPU NoC 의 latency·bandwidth 를 자세히 분석한 연구가 없어, simulator 의 NoC 가정이 실제 GPU 와 맞는지 확인할 수 없었다 §I p.1. 저자들은 이 논문을 실제 최신 GPU NoC 를 자세히 분석한 첫 연구 중 하나로 소개한다 §I p.1.

0.1.3전 방법

thread 하나가 고른 L2 slice 에 load 하나를 보내고 clock() 으로 round-trip latency 를 재고(Algorithm 1), 목적지 L2 slice 를 고정한 streaming kernel 로 bandwidth 를 잰다(Algorithm 2) §II-C p.2–3. 결과를 Observation 12 개와 Implication 6 개로 정리한다.

0.1.4결 결과

V100 에서 SM→L2 slice latency 는 175~248 cycle 로 퍼지지만, SM 하나→L2 slice 하나 bandwidth 는 평균 약 34 GB/s, σ = 0.147 GB/s 다 §III-A p.3 §IV-A p.7. A100 에서 다른 partition 의 L2 slice 를 읽으면 latency 가 약 400 cycle 로 오른다 §III-C p.6. random thread-block scheduling 을 쓰면 기존 AES·RSA timing 공격의 상관이 흐려진다 §V-C p.10.

0.2

SM (core, 요청 출발지)L2 slice (요청 목적지)

0.2.c이 논문이 재는 대상은 가운데 NoC 다. SM 이 L2 에 load 를 보내면 NoC 를 지나 MP 안의 L2 slice 에 닿고, data 가 같은 길로 돌아온다 §II-A p.2. SM 개수와 slice 개수는 그림을 단순하게 하려고 줄였다 논문에 없음.

0.3

0.3.1

≈70%

on-chip latency 의 최대 차이 (abstract 수치, 계산 기준은 원문에 명시 없음)

0.3.2

2.4–3.5×

aggregate L2 fabric bandwidth ÷ off-chip memory bandwidth (세 GPU)

0.3.3

≈400

A100 에서 다른 partition L2 slice 의 latency (cycle). V100 평균은 약 212

0.3.4

1.7×

A100 square kernel 실행 시간: 두 SM 이 다른 partition 일 때 최대 증가

Observation 12 개 · Implication 6 개를 한 줄씩

0.4

번호	원문 주장 (요약)	근거
0.4.1Obs 1	SM → 각 L2 slice latency 는 non-uniform 이다	Fig.1 · §III-A p.3
0.4.2Obs 2	GPC 별 평균 latency 는 비슷하지만, GPC 안의 분산은 GPC 마다 다르다	Fig.1(b)·2 · §III-A p.4
0.4.3Obs 3	non-uniform latency 는 GPC 안 SM 위치와 MP 안 L2 slice 위치로 정해진다	Fig.3·4·5 · §III-B p.4
0.4.4Obs 4	latency 분포의 Pearson correlation 으로 SM 배치를 알아낼 수 있다	Fig.6 · §III-B p.5
0.4.5Obs 5	partition 이 있는 큰 GPU 는 non-uniformity 가 더 크고, H100 에는 TPC 와 GPC 사이에 계층(CPC)이 하나 더 있다	Fig.6·7 · §III-C p.5–6
0.4.6Obs 6	partition 이 있는 GPU 는 L2 cache 정책에 따라 latency 특성이 달라진다 (원문은 "additional uniformity" 로 적었으나 문맥상 non-uniformity 로 보인다 해석)	Fig.8 · §III-C p.6
0.4.7Obs 7	aggregate L2 fabric bandwidth 가 off-chip memory bandwidth 보다 크다	Fig.9(a) · §IV-A p.6
0.4.8Obs 8	latency 와 달리 L2 slice 별 bandwidth 는 (대체로) uniform 이다	Fig.9(b,c) · §IV-A p.7
0.4.9Obs 9	계층 구조이지만 input speedup 으로 NoC 입력 bandwidth 를 더 준다	Fig.10·11 · §IV-A p.7
0.4.10Obs 10	최근 GPU 는 on-chip bandwidth 가 더 크지만 partition 때문에 bandwidth 가 non-uniform 이다	Fig.12·13·14 · §IV-B p.7–8
0.4.11Obs 11	NoC speedup 이 비대칭이라 L2 slice 보다 SM 쪽 load balancing 이 더 중요하다	Fig.15 · §IV-B p.8
0.4.12Obs 12	memory traffic 이 channel 사이에 고르게 퍼지므로 NoC traffic 도 고르다	Fig.16 · §IV-C p.9
0.4.13Imp 1	NoC 특성으로 SM·L2 slice 배치를 알아내 side-channel 공격의 co-location 에 쓸 수 있다	§V-A p.9
0.4.14Imp 2	non-uniform latency 는 timing 공격을 근본적으로 바꾸지는 않지만 core 마다 timing 이 달라 공격 동작에 영향을 준다	Fig.17 · §V-B p.10
0.4.15Imp 3	random thread-block scheduling 이 non-uniform latency 를 이용해 timing 공격의 영향을 줄인다	Fig.18·19 · §V-C p.10–11
0.4.16Imp 4	실제 GPU 에서 NoC 는 memory·L2 bandwidth 의 병목이 아니지만, 틀린 NoC 가정은 시스템 bandwidth 를 제한한다	Fig.21 · §VI-A p.11
0.4.17Imp 5	bisection bandwidth 뿐 아니라 interface bandwidth 도 충분히 줘야 한다	Fig.20 · §VI-B p.11–12
0.4.18Imp 6	2D mesh 같은 multi-hop topology 는 node 위치와 무관한 uniform bandwidth 와 speedup 을 주기 어렵다	Fig.22·23 · §VI-C p.12

1배경: GPU 안의 계층과 NoC

GPU 는 SM → TPC → GPC 로 묶이는 계층 구조이고, NoC 가 SM 과 memory partition(MP, L2 slice 여러 개 + memory controller)을 잇는다 §II-A p.2.
A100·H100 은 칩 중앙의 interconnect 로 좌우 두 "partition" 으로 나뉜다 §II-A p.2. 이 논문의 latency·bandwidth 는 모두 "어느 SM 에서 어느 L2 slice 로" 를 고정하고 잰 값이다.

1.1용어표

1.1.1

용어	정확한 뜻 (이 요약에서)	기호	논문 원문 표기
1.1.1.1SM	GPU 의 core 하나(Streaming Multiprocessor). private L1 cache 와 shared memory 를 가진다. 이 요약에서 요청의 출발지	–	"cores (or SMs)", "core" 와 혼용 (§II-A p.2)
1.1.1.2TPC	SM 2 개를 multiplexer 로 묶은 단위	–	"Texture Processing Cluster" (§II-A p.2)
1.1.1.3GPC	TPC 7~9 개를 묶은 단위. GPU 하나는 GPC 6~8 개다	–	"Graphics Processing Cluster" (§II-A p.2)
1.1.1.4CPC	H100 에서 TPC 와 GPC 사이에 있을 것으로 추정한 계층. TPC 2~3 개(SM 4~6 개) 묶음. NVIDIA 문서는 공개하지 않았고 존재는 확인되지 않았다	–	"Compute Processing Cluster", hardware teardown [40] 의 이름 (§III-C p.5 각주 4)
1.1.1.5memory partition (MP)	L2 slice 여러 개와 memory controller(MC) 하나를 묶은 단위. off-chip memory 앞에 있다	–	"memory partition (MP)" (§II-A p.2)
1.1.1.6L2 slice	모든 SM 이 공유하는 L2 cache 를 나눈 조각. 이 요약에서 요청의 목적지. V100 32 개, A100·H100 80 개	$s$	"L2 slice" (TABLE I p.1)
1.1.1.7NoC	SM 과 MP 를 잇는 on-chip network. 실제 GPU 는 hierarchical crossbar 와 비슷하게 구성된 것으로 본다	–	"network-on-chip (NoC)", "interconnect" (§II-B p.2)
1.1.1.8GPU partition	A100·H100 에서 central interconnect 로 나뉜 칩의 왼쪽·오른쪽 절반. 각 partition 에 GPC 와 L2 slice 가 절반씩 있다	–	"partitions" (§II-A p.2). MIG partition 과는 다른 뜻이다 논문에 없음
1.1.1.9near / far partition	요청을 보낸 SM 과 같은 partition / 다른 partition	–	"near partition", "far partition" (§III-C p.6)
1.1.1.10L2 access latency	SM 의 thread 하나가 L1 을 우회해 L2 slice 하나에 load 를 보내고 data 를 받을 때까지의 round-trip 시간. SM·NoC·L2 접근 시간을 모두 포함하고, SM 의 `clock()` cycle 로 잰다	$L[s][n]$	"L2 access latency", "round-trip latency" (§II-C p.2, §III-A p.3). 원문은 "on-chip latency", "L2 latency" 로도 쓴다
1.1.1.11L2 hit latency / L2 miss penalty	L2 에 hit 할 때의 L2 access latency / L2 에 없는 cache line 을 global memory 에서 L2 로 가져오는 데 더 드는 시간	–	Fig.8 caption (§III-C p.6)
1.1.1.12L2 fabric bandwidth	SM 들이 L2 slice(들)로 보내는 load 를 NoC 가 실어 나르는 bandwidth. L2 cache 자체의 read/write 성능과 구분한다	–	"L2 fabric bandwidth", "on-chip bandwidth" (§II-C p.3 각주 2)
1.1.1.13input speedup	계층의 한 단(TPC·CPC·GPC·L2) 출력이 그 단에 들어오는 입력 하나보다 몇 배의 bandwidth 를 주는지. 측정은 "SM $x$ 개 bandwidth ÷ SM 1 개 bandwidth"	$x$	"input speedup ... the excess bandwidth provided into the GPU interconnect" (§IV-A p.7)
1.1.1.14GPC_l / GPC_g	GPC_l = TPC 단 → GPC 단 사이의 local speedup, GPC_g = GPC 안 모든 SM 이 보낼 때의 global speedup	–	§IV-A p.7 각주 6
1.1.1.15Pearson correlation	두 SM 의 L2 slice 별 latency 목록이 얼마나 같은 모양으로 오르내리는지(−1~1)	$r$	Eq.1 (§III-B p.4)
1.1.1.16request / reply network	SM → MP 로 요청을 보내는 망 / MP → SM 으로 data 를 돌려주는 망	–	Fig.20 (§VI-A p.11)
1.1.1.17bisection bandwidth	NoC 를 반으로 자른 단면을 지나는 bandwidth	$BW_{NoC\text{-}BC}$	Fig.20(a) (§VI-B p.11)
1.1.1.18NoC-MEM interface bandwidth	NoC 와 MP 가 맞닿는 지점의 bandwidth. $f_{NoC}\times w\times C$	$BW_{NoC\text{-}MEM}$	"interface (terminal) bandwidth" (§VI-B·C p.11–12)
1.1.1.19memory bandwidth	off-chip memory(HBM) 의 bandwidth	$BW_{MEM}$	Fig.20(b), Fig.22
1.1.1.20thread block scheduling	kernel 의 thread block(CTA)을 SM 에 배정하는 일. 기존 GPU 는 매번 같은 SM 에 배정하는 static scheduling 이다	–	"Thread block (or CTA) scheduling" (§V-C p.10)
1.1.1.21timing side-channel attack	실행 시간을 재서 secret(AES key, RSA key 의 1 개수 등)을 추론하는 공격	–	§V p.9

1.2A100·H100 의 두 partition

1.2.1

1.2.1.cA100 에서 SM0 은 L2 slice 0–39 와 같은 partition 이고, SM2 는 40–79 와 같은 partition 이다 §IV-B p.7. 요청이 다른 partition 의 L2 slice 로 가면 central interconnect 를 건너야 해서 latency 가 늘고 bandwidth 가 준다 §III-C p.6 §IV-B p.7. 그림의 배치는 개념도다 논문에 없음.

1.2.2.cTABLE I: Microarchitecure comparison of NVIDIA GPUs. (p.1) 세대가 바뀌며 SM 수(80 → 132), L2 크기(6 → 50 MB), memory bandwidth(0.9 → 3.35 TB/s)가 함께 커졌다. 논문은 그래서 많은 구성요소를 잇는 NoC 가 시스템 성능의 중요한 요소가 된다고 쓴다 §I p.1. Table I 은 A100 의 GPC 를 7 개로 적지만, Fig.6·8 은 A100 GPC 번호를 0–7 까지 쓴다. 원문은 이 차이를 설명하지 않는다.

1.3input speedup 은 무엇인가

1.3.1

1.3.1.cSM 2 개가 TPC 출력 하나를 나눠 쓰므로(2-to-1), TPC 출력이 SM 출력과 같은 bandwidth(speedup 1)면 두 SM 이 동시에 보낼 때 각자 50% 만 쓴다. speedup 2 면 두 SM 모두 full bandwidth 로 NoC 에 들어간다 §IV-A p.7. GPC 는 TPC 7~9 개를 묶으므로 full bandwidth 에 필요한 GPC_l speedup 은 7·8·9 다 §IV-A p.7. 그림 논문에 없음.

1.4Pearson correlation 으로 두 SM 을 비교한다

1.4.1

$X_i$, $Y_i$ = 두 SM 에서 잰 $i$ 번째 latency 표본 · $\bar X$, $\bar Y$ = 각 평균 · $n$ = 표본 수 §III-B p.4. 표본 $i$ 가 L2 slice $i$ 라는 해석은 Fig.3 의 비교 방식에서 끌어냈다 해석

$$r = \frac{S_{XY}}{\sqrt{S_{XX}}\,\sqrt{S_{YY}}}$$Eq.1 · §III-B p.4

$$\begin{aligned} S_{XY} &= \textstyle\sum_{i=1}^{n}(X_i-\bar X)(Y_i-\bar Y) \\ S_{XX} &= \textstyle\sum_{i=1}^{n}(X_i-\bar X)^2 \end{aligned}$$$S$ 표기는 요약자 표기

$r=1$ 이면 두 SM 의 slice 별 latency 가 같은 모양으로 오르내리고, $0$ 이면 상관이 없고, $-1$ 이면 반대로 움직인다 §III-B p.4. 가까이 있는 SM 일수록 어느 slice 가 가깝고 먼지가 같아 $r$ 이 1 에 가깝다 해석.

1.5나머지 용어

1.5.1

Little's Law

대기열 시스템에서 "한꺼번에 날아가 있는 요청 수 = 처리율 × 지연" 이라는 관계다 논문에 없음. 그래서 SM 이 낼 수 있는 미해결 요청 수가 정해져 있으면 latency 가 긴 경로일수록 bandwidth 가 낮아진다. 논문은 A100 의 far partition bandwidth 가 낮은 이유를 이 법칙으로 설명한다 §IV-B p.8.

memory camping · address hashing

접근이 한 memory channel 에 몰려 전체 memory 처리율이 떨어지는 현상을 memory camping 이라 한다. 최신 GPU 는 이를 막으려고 복잡한 address hashing 으로 주소를 L2 slice 전체에 고르게 나눈다 §IV-C p.8–9.

coalescing

warp 의 32 thread 가 같은 cache line 을 읽으면 요청 하나로 합치는 것이다 §II-B p.2. AES 공격 [6] 은 "서로 다른 cache line 수" 와 실행 시간의 선형 관계를 이용한다 §V-B p.9.

many-to-few-to-many

많은 SM 이 적은 수의 memory controller 로 요청을 보내고(many-to-few), 그 data 가 다시 많은 SM 으로 흩어지는(few-to-many) GPU traffic 모양이다. 선행 연구 [28] 는 그래서 reply network 를 병목으로 지목했다 §II-B p.2 §VI-A p.11.

2문제와 측정 방법

기존 GPU NoC 연구는 simulator 로 평가하며 2D mesh 같은 multi-hop network 를 가정한 경우가 많아, 그 가정 자체가 on-chip bandwidth 병목을 만들 수 있다 §II-B p.2.
저자들은 실제 V100·A100·H100 에서 출발지 SM 과 목적지 L2 slice 를 고정한 microbenchmark 로 NoC 의 latency 와 bandwidth 를 따로 잰다 §II-C p.2–3.

2.1

2.1.cAlgorithm 1 이다. warp 하나의 thread 하나만 요청을 보내 coalescing 과 자원 경합을 없애고, -dlcm=cg 로 L1 을 우회하며, data 를 미리 읽어 L2 에 hit 하게 한다 §II-C p.2–3. 측정값은 SM·NoC·L2 를 모두 포함하지만 SM 과 L2 slice 를 바꿔도 SM·L2 몫은 거의 같으므로, 값의 변화는 NoC 에서 온다고 본다 §II-C p.3. 그림 논문에 없음.

측정 세부: 출발지·목적지를 어떻게 고정했나, bandwidth 는 어떻게 쟀나

2.2

2.2.1출발지 SM 은 smid register 로 확인하고 kernel 을 특정 SM 에 "pin" 한다 §II-C p.3.
2.2.2목적지 L2 slice 는 V100 에서는 nvprof 의 non-aggregated mode 로 slice 별 traffic 을 보고 정했다. A100·H100 은 이 profiler counter 가 지원되지 않아, 한 주소만 읽는 kernel 과 주소를 바꾸는 kernel 을 함께 돌려 경합이 생기면 같은 slice 라고 가정했다 §II-C p.3 각주 1.
2.2.3slice ID 와 SM ID 의 숫자 자체에는 뜻이 없고, 서로 다른(또는 같은) SM·slice 를 고르는 데만 쓴다 §II-C p.3.
2.2.4bandwidth 는 Algorithm 2 로 잰다. streaming benchmark 와 비슷하게 순차·stride 접근을 쓰지만, 모든 thread 의 주소를 같은 L2 slice $s$ 에 매핑되는 것으로 골라(M[s][tid]) 목적지를 고정한다. warp 의 모든 thread 와 여러 thread block 을 써서 bandwidth 를 포화시키고, 따로 적지 않으면 read 다 §II-C p.3.
2.2.5bandwidth = 옮긴 data 크기 ÷ kernel 실행 시간이다. L2 slice 하나, MP 하나, 전체(aggregate) 단위로 각각 쟀다 §II-C p.3.
2.2.6먼저 V100 에서 평가했고 A100·H100 에서도 비슷한 경향을 봤지만, partition 이 있는 두 GPU 는 다른 특성이 있어 따로 분석했다 §II-C p.3.
2.2.7CUDA·driver 버전, GPU clock 고정 여부, 반복 횟수는 원문에 명시가 없다.

3관측 ①: latency 는 위치에 따라 다르다

V100 에서 한 SM 이 32 개 L2 slice 를 읽는 latency 는 175~248 cycle(평균 약 212)로 퍼지고, 이 차이는 GPC 안 SM 위치와 MP 안 L2 slice 위치로 정해진다 §III-A·B p.3–4.
A100 은 다른 partition 의 slice 를 읽으면 약 400 cycle 로 오르고, H100 은 partition 에 가까운 L2 에 data 를 caching 해 latency 가 GPC 사이에 더 고르다 §III-C p.6.

3.2보강 Fig. 1 은 무엇을 쟀고 (a)·(b) 가 각각 무엇을 보여 주는가

무엇을 쟀는가: 연구진은 SM 이 L1 에서 miss 되고 L2 에서 hit 되는 read 를 보낸 뒤 응답이 돌아올 때까지의 왕복 시간을 쟀습니다. 왕복 시간에는 SM 처리 시간, NoC 이동 시간, L2 접근 시간이 모두 들어갑니다 §III-A p.3.
"L2 slice ID 별"의 뜻: L2 cache 는 32 개 slice 로 나뉘어 MP 4 개에 흩어져 있고, 주소마다 그 주소를 맡는 slice 가 정해져 있습니다. 연구진은 같은 SM 에서 slice 32 개 각각으로 read 를 보내 slice 별 왕복 시간을 따로 구했습니다. x 축 번호는 NVIDIA profiler 가 붙인 slice ID 입니다 §III-A p.3.
막대 높이 차이의 의미: SM 처리 시간과 L2 접근 시간은 어느 slice 를 읽든 같습니다. 따라서 막대 높이 차이는 SM 에서 해당 slice 까지 NoC 를 지나는 물리적 거리의 차이를 나타냅니다 §III-A p.3.
(a) 가 보여 주는 것: 출발지를 SM 24 하나로 고정해도 목적지 slice 에 따라 latency 가 달라집니다. GPU 의 L2 latency 는 하나의 고정값이 아닙니다(Observation 1).
(b) 가 보여 주는 것: 출발지를 GPC 단위로 바꿔 보면, GPC 별 평균 latency 는 서로 비슷하지만 latency 가 퍼진 폭은 GPC 마다 다릅니다. GPC2·GPC3 은 폭이 좁고, GPC4 는 최대 71 cycle 까지 벌어집니다(Observation 2) §III-A p.3–4.

Fig.2 · Fig.3 — GPC 마다 분산이 다르고, slice 순서는 SM 사이에 같다

Fig.4 — 3.5.cFig. 4: Block diagram (approximate logical floorplan) of the V100 GPU showing L2 slices placement inside the MP and SM placement inside the GPC. (p.5) die photo [38] 와 측정 결과로 추정한 V100 의 논리 배치도다. GPC 0·2·4 가 위, 1·3·5 가 아래, MP 0~3 이 가운데에 있다. 오른쪽 확대 그림은 GPC 4 의 SM 배치와 MP 3 의 L2 slice 배치다. 가장 가까운 SM64–slice 17 은 180 cycle, 가장 먼 SM4–slice 15 는 217 cycle 이다 §III-B p.4. 실제 SM ID·slice ID 값보다 상대 배치가 중요하다고 원문은 쓴다.

3.7보강 Fig. 5 읽는 법과 SM 4 가 항상 느린 이유

점 하나의 뜻: 점 하나는 "SM 하나 → slice 하나" 왕복 latency 입니다. x 축은 목적지(MP3 의 slice 8 개), 기호는 출발지(GPC4 의 SM 7 개)입니다. 따라서 slice ID 는 속도가 아니라 목적지 이름입니다.
읽는 방향 두 가지: 선 하나를 따라가면 slice 위치 효과(17 이 가장 빠르고 15 가 가장 느림)가 보이고, 같은 x 에서 기호들을 위아래로 비교하면 SM 위치 효과가 보입니다. 두 효과가 거의 더해지는 꼴이라 선들이 평행하게 나옵니다 §III-B p.4.
SM 4 가 항상 느린 이유: Fig. 4 배치에서 SM 4 는 GPC4 안에서 MP3 와 가장 먼 자리에 있습니다. 그래서 MP3 의 어느 slice 로 가도 다른 SM 보다 일정하게 더 깁니다. 가장 먼 쌍인 SM4–slice 15 가 217 cycle, 가장 가까운 SM64–slice 17 이 180 cycle 입니다 §III-B p.4.
범위: "SM 4 가 가장 느리다"는 MP3 를 목적지로 한 Fig. 5 에서의 결과입니다. Fig. 3 처럼 MP 사이 순위는 SM 위치에 따라 바뀌므로, 다른 MP 에서도 SM 4 가 가장 느린지는 논문이 보여 주지 않습니다 논문에 없음.

Fig.6 — 3.8.cFig. 6: Pearson correlation heatmap for L2 latency on the (a) V100, (b) A100, and (c) H100 GPUs. For A100 and H100, GPCs 0-3 are located on the left "partition," while GPC 4-7 are located on the right "partition." (p.5) 두 축 모두 SM 을 GPC 순으로 놓고, 칸 색은 두 SM 의 latency 분포 사이 $r$ 이다. (a) V100 은 같은 GPC 안이 거의 1 이고, 이웃 GPC 쌍(0·1, 2·3, 4·5)도 높다. 논문은 GPC 2·3 이 가운데, 0·1 과 4·5 가 가장자리에 있는 대칭 배치 때문으로 본다 §III-B p.5. (b) A100 은 같은 GPC 안에서도 차이가 생기고 이웃 GPC 사이 유사성이 줄었다(원인은 원문도 불명확하다고 쓴다). (c) H100 은 GPC 안에서 SM 4~6 개 묶음끼리만 비슷하다. 저자들은 이를 TPC 와 GPC 사이의 계층 CPC 로 본다 §III-C p.5. 그래서 latency 분포만으로 SM 배치를 알아낼 수 있다(Observation 4).

Fig.7 — H100 의 CPC 와 SM-to-SM latency

Fig.8 — 3.10.cGPU 가 두 partition 으로 나뉘면 반대편 partition 의 L2 를 읽는 SM 은 latency 가 약 212 에서 약 400 cycle 로 오른다는 점을 보이는 그림입니다. H100 은 가까운 쪽에 data 를 caching 해 차이를 줄였지만, 그 대가로 miss penalty 가 일정하지 않게 되었습니다 §III-C p.6.Fig. 8: Average L2 hit latency from one GPC to one MP (top) and average L2 miss penalty or latency from global memory to L2 (bottom) on (a,d) V100, (b,e) A100, and (c,f) H100. (p.6) 위 줄은 GPC 하나의 SM 들에서 MP 하나의 slice 8 개까지 L2 hit latency 평균이고, 기호 색이 출발 GPC 다. (a) V100 은 약 212 cycle 로 모든 GPC 가 겹친다. (b) A100 은 두 무리로 갈린다. 목적지 slice 가 왼쪽 partition 에 있을 때 GPC 1·2·6·7 은 V100 과 비슷하고, GPC 0·3·4·5 는 partition 을 오가느라 약 400 cycle 이다 §III-C p.6. (c) H100 은 GPC 사이에 더 고르다. 아래 줄 miss penalty 는 (d)(e) V100·A100 은 일정하지만 (f) H100 은 data 가 어디에 cache 되어 있느냐에 따라 두 층으로 갈린다 §III-C p.6. 논문은 H100 의 L2 가 "partition 에 직접 연결된 GPC 의 SM 이 요청한 data 를 caching" 한다는 whitepaper 문장 [12] 을 근거로 들어, H100 에서는 주소와 관계없이 SM 별 latency 가 비슷하다고 설명한다 §III-C p.6. 원문은 GPU NoC 와 memory hierarchy 를 완전히 reverse-engineering 하지는 않았다고 밝힌다. Fig.6 caption 은 GPC 0–3 을 왼쪽 partition 이라 하지만 여기서는 GPC 1·2·6·7 이 왼쪽 slice 와 같은 partition 이라 쓴다. 두 번호 체계의 대응은 원문에 설명이 없다.

4관측 ②: bandwidth 는 고르게 준다

L2 slice 별 bandwidth 는 출발 SM·GPC 와 관계없이 거의 같고(V100 SM 하나 → slice 하나 약 34 GB/s, σ = 0.147 GB/s), aggregate L2 fabric bandwidth 는 off-chip memory bandwidth 의 2.4~3.5× 다 §IV-A p.6–7.
계층마다 input speedup 이 있어 SM 이 몰려도 bandwidth 가 크게 깎이지 않지만, A100·H100 은 partition 때문에 bandwidth 도 non-uniform 해진다 §IV-A·B p.7–8.

Fig.9 — 4.1.cFig. 9: (a) On-chip aggregate L2 and global memory bandwidth. Distribution of L2 bandwidth to a single L2 slice when accessed by (b) a single SM and (c) a single GPC in V100. (p.6) (a) 모든 SM 이 모든 slice 로 보낼 때의 L2 fabric bandwidth(진한 막대)와 L2 miss 로 측정한 memory bandwidth(빗금)다. memory 쪽은 peak 의 약 85~90% 에 이르고, L2 fabric bandwidth 는 그보다 2.4~3.5× 높다(Observation 7) §IV-A p.6. (b) V100 에서 SM 하나 → slice 하나의 모든 조합 bandwidth 분포로, 평균 약 34 GB/s, σ = 0.147 GB/s 다. (c) GPC 하나의 모든 SM → slice 하나는 약 85 GB/s, σ = 0.06 GB/s 다 §IV-A p.7. latency 는 slice 마다 다르지만 bandwidth 분포는 좁다. 논문은 이를 SM·GPC 가 어느 slice 에나 비슷한 bandwidth 를 받는다는 뜻으로 보고(Observation 8), slice 하나를 포화시키려면 SM 이 최소 4 개 필요하다고 쓴다 §IV-A p.7.

Fig.11 — 4.2.cFig. 11: Block diagram that illustrates the various interconnect speedup that are provided within the GPU NoC. (p.7) SM 0·1 → TPC → GPC → crossbar → Memory Partition 순으로 묶이며, 묶이는 자리마다 TPC speedup, GPC speedup, L2 speedup 이 있다 §IV-A p.7. 1 절의 input speedup 그림이 이 중 TPC speedup 하나를 확대한 것이다.

Fig.10 — 4.3.cFig. 10: Interconnect input speedup comparison across different GPU architecture. (p.7) GPU 별로 TPC·(CPC)·GPC_l·GPC_g speedup 을 read(옅은 막대)와 write(진한 막대)로 잰 값이다. TPC read 는 세 GPU 모두 full(2)이지만 V100 TPC write 는 1.09× 다. full GPC_l 에 필요한 값은 7·8·9 인데 V100 은 그 약 50%, H100 은 약 85%(8 가까이)다. A100·H100 은 GPC_g 가 GPC_l 보다 크다. H100 의 CPC 는 read 에는 영향이 없지만 write 는 약 4.6 으로 full(6)에 못 미친다 §IV-A p.7. read 는 요청이 작고 응답(cache line)이 커서 SM 으로 들어오는 방향의 bandwidth 가 더 필요하고, write 는 반대다 §IV-A p.7. 논문은 계층 구조에서 bandwidth 를 나눠 쓰는 손해를 줄이려고 input speedup 을 주며, 최근 GPU 일수록 그 값이 크다고 정리한다(Observation 9).

Fig.12 — 4.4.cFig. 12: L2 slice bandwidth for (a) SM0 and (b) SM2 on A100 where SM0 and SM2 are located on different GPU partitions. (p.7) A100 에서 SM 하나가 slice 80 개 각각으로 보낼 때의 bandwidth 다. (a) SM0 은 같은 partition 인 slice 0–39 에 약 39.5 GB/s, 다른 partition 인 40–79 에 약 26 GB/s 다. (b) SM2 는 반대 partition 이라 near·far 가 뒤바뀐다 §IV-B p.7.

Fig.14 — 4.5.cFig. 14: Single L2 slice bandwidth on A100 as the number of SMs sending traffic is increased. (p.8) x 축은 같은 slice 로 보내는 SM 수, 왼쪽 축은 near(주황)·far(파랑) bandwidth, 오른쪽 축은 둘의 % 차이(+)다. 약 8 SM 에서 둘 다 포화해 차이가 사라지고, SM 1~2 개일 때는 far 가 최대 28% 낮다 §IV-B p.8. 논문은 far partition latency 가 길어서, SM 이 적을 때는 Little's Law 에 따라 bandwidth 가 낮고 SM 이 충분하면 포화한다고 설명한다 §IV-B p.8.

Fig.13 · Fig.15 · Fig.16 — slice 하나의 분포, SM 쪽 몰림, 실제 workload 의 traffic

Fig.16 — 4.8.cFig. 16: Memory access pattern for (a) BFS and (b) Gaussian workloads measured on the NVIDIA V100 GPU. (p.8) Rodinia 의 bfs·gaussian 을 V100 에서 돌리며 시간(x)별로 slice(y)마다 간 traffic 양을 색으로 그렸다. 시간에 따라 양은 바뀌지만 같은 시각의 세로줄은 거의 한 색이라, slice 사이 분포는 일정하다 §IV-C p.9. address hashing 이 주소를 slice 전체에 고르게 나누기 때문이다. 논문은 그래서 NoC traffic 의 load balancing 보다 모든 목적지에 uniform bandwidth 를 주는 것이 중요하다고 쓴다(Observation 12) §IV-C p.9.

5함의(평가): timing side-channel 과 NoC 설계

① 보안: non-uniform latency 로 SM·L2 slice 배치를 알아낼 수 있고(공격), 같은 성질 때문에 kernel 을 실행할 때마다 시작 SM 을 무작위로 바꾸면 AES·RSA timing 공격의 상관이 흐려진다(방어) §V p.9–11.
② 설계: 실제 GPU 의 NoC 는 memory·L2 bandwidth 를 막지 않는데, simulator 의 NoC 가정이 interface bandwidth 를 memory bandwidth 보다 작게 두면 "network wall" 이 생겨 NoC 최적화의 이득을 과장할 수 있다 §VI p.11–12.

5.1① timing side-channel: 공격

최근 GPU 는 side-channel 공격에 쓰이던 performance counter 를 root 권한 없이는 막았고, slice 별 counter 도 더 이상 주지 않는다 §V-A p.9. 논문은 L2 latency 가 SM–slice 거리의 대리 지표이므로, Pearson correlation 으로 SM 의 GPC 내 위치와 slice 의 MP 내 위치를 reverse-engineering 해 공격 kernel 의 co-location 에 쓸 수 있다고 주장한다(Implication 1) §V-A p.9.

5.1.1

5.1.1.c"서로 다른 cache line 수 ↔ 실행 시간" 관계는 SM 마다 평행 이동한다. 공격자가 어느 SM 에서 돌았는지 모르면 같은 240 cycle 이 12~18 개 cache line 중 어느 것인지 알 수 없다. 수치는 원문 예 §V-B p.10, 그림은 개념도다 논문에 없음.

Fig.17 — 5.1.2.cFig. 17: (a) Average timing (latency) when the number of unique cache lines are varied and (b) average execution time of square kernel for A100 across different cores (SM). (p.9) (a) warp 하나(32 thread)가 읽는 서로 다른 cache line 수에 따라 latency 가 선형으로 오르고, 선 색이 출발 SM(2, 14, 26, 38, 50, 62)이다. 목적지가 같아도 SM 이 바뀌면 직선이 위아래로 이동한다. 240 cycle 이 관측되면 cache line 수가 12~18 개 중 어느 것인지 갈린다 §V-B p.9–10. (b) A100 에서 RSA 의 `square()` kernel 은 SM 2 개를 쓰고, 하나는 고정하고 다른 하나의 위치를 바꿨다. SM 2·16·30·44·58 은 한 partition, 나머지는 다른 partition 이다. 두 SM 이 다른 partition 이면 partition 간 latency 와 동기화 overhead 로 실행 시간이 최대 1.7× 길고, 같은 partition 안에서도 최대 12% 차이가 난다 §V-B p.10. timing 공격은 "실행 시간 ↔ secret 에 따른 동작" 의 선형 관계를 쓰는데, 그 관계가 어느 SM 에서 도느냐에 따라 이동한다. 논문은 그래서 non-uniform latency 가 공격 원리를 바꾸지는 않지만 core 별 timing 차이가 공격 동작에 영향을 준다고 정리한다(Implication 2) §V-B p.10.

5.2① timing side-channel: 방어

기존 GPU 의 thread block scheduling 은 실행할 때마다 같은 SM 에 배정하므로, 공격자가 표본을 아무리 많이 모아도 latency 는 한 SM 의 값으로 고정된다. 논문은 kernel 실행마다 thread block 을 무작위 SM 부터 배정하는 random thread-block scheduling(사실상 random seed scheduling)을 제안한다 §V-C p.10.

Fig.18 — 5.2.1.cFig. 18: AES key-recovery attack on GPU with (a) conventional (static) and (b) random thread block scheduling. The correct key value is circled in the plots and only 4 out of the 16 keys are shown for simplicity. (p.9) x 축은 key byte 후보 0~255, y 축은 후보마다 계산한 "실행 시간 ↔ unique cache line 수" Pearson correlation 이고, 빨간 원이 정답 key 다. 16 byte 중 K0~K3 만 보였다. (a) static scheduling 에서는 정답에서만 correlation 이 1 근처로 솟아 key 를 복구할 수 있다. (b) random scheduling 에서는 그 봉우리가 사라진다 §V-C p.10. 무작위 배정으로 AES 실행 시간이 L2 slice 까지의 non-uniform latency 에 따라 매번 달라지므로, 실행 시간과 cache line 수의 상관이 정답 key 에서도 높게 나오지 않는다 §V-C p.10.

Fig.19 — 5.2.2.cFig. 19: RSA timing attack with (a) static and (b) random thread-block scheduling. (p.10) x 축은 RSA key 의 bit 1 개수, y 축은 전체 실행 시간이다. bit 1 은 `multiply()`·`reduction()` 을 더 하므로 bit 0 보다 약 2 배 걸리고, 그래서 실행 시간이 1 개수에 선형이다 §V-B p.10. (a) static 에서는 SM 별로 깨끗한 직선이 두 묶음(partition)으로 나뉜다. (b) random 에서는 같은 1 개수에서도 실행 시간이 크게 흔들려, $2\times10^9$ cycle 이 관측되면 1 의 개수가 416~1920 사이 어디든 될 수 있다 §V-C p.10. RSA 를 이루는 개별 kernel 의 시간이 배치마다 달라져 전체 실행 시간에 큰 변동이 생긴다 §V-C p.10. 논문은 하드웨어에 randomization 을 넣는 기존 방어(예: randomized coalescing [52])와 달리 이 방식은 하드웨어 복잡도를 늘리지 않는다고 쓴다(Implication 3) §V-C p.11.

5.3② NoC 설계: simulator 의 가정이 병목을 만든다

Fig.20 — 5.3.1.cFig. 20: Communication pattern of many-to-few-to-many in throughput processors. (a) Bisection bandwidth (BWNoC−Bc) and (b) memory bandwidth (BWMEM) and the interface bandwidth (BWNoC−MEM) are highlighted. (p.11) (a) 왼쪽 request network 로 많은 Core 가 적은 MEM 에 요청을 보내고, 오른쪽 reply network 로 data 가 돌아온다. 빨간 가로 점선이 bisection bandwidth $BW_{NoC\text{-}BC}$ 다. (b) MEM 자체의 bandwidth $BW_{MEM}$ 과, MEM 이 reply network 에 data 를 넣는 지점의 interface bandwidth $BW_{NoC\text{-}MEM}$ 을 세로 점선으로 표시했다 §VI-A·B p.11.

5.3.2

5.3.2.ccore·NoC·memory 는 직렬로 이어져 있어, 전체 처리율은 가장 느린 단의 처리율이다 §VI-B p.11. 그래서 bisection bandwidth 가 충분해도 interface bandwidth 가 모자라면 memory·L2 bandwidth 를 다 쓰지 못한다(Implication 5). 선 굵기는 개념 표현이다 논문에 없음.

Fig.21 — 5.3.3.cFig. 21: Memory channel utilization fluctuation from back-pressure from the reply bandwidth bottleneck in a simulation-based evaluation. (p.11) 선행 연구 [28] 와 비슷한 설정의 simulation 에서, memory 집약 synthetic kernel 을 돌리며 memory channel 하나의 bandwidth 를 DRAM cycle 별로 그렸다. 순간적으로 최대(위 점선)에 닿지만 평균(아래 점선)은 약 20% 이용률이다 §VI-A p.11. reply 쪽 interface 가 막히면 그 back-pressure 가 memory system 과 request network 까지 막기 때문이다. 실제 GPU 는 Fig.9(a) 처럼 85% 넘게 쓰므로, simulator 의 NoC 모델이 실제 GPU 를 대표하지 못한다고 논문은 결론 낸다. 같은 설정에서는 L2 bandwidth 도 memory bandwidth 보다 낮게 나오는데, 원인은 L2 모델이 아니라 NoC 모델이라고 쓴다(Implication 4) §VI-A p.11 각주 9. simulator 이름은 원문에 명시가 없다.

Fig.22 — 5.3.4.cFig. 22: Comparison of memory bandwidth and NoC-Mem interface bandwidth modeled as different symbols represent different simulation-based prior work [14], [15], [17], [28]–[32], [58], [59]. (p.12) x 축은 선행 simulation 연구가 쓴 memory bandwidth $BW_{MEM}$, y 축은 같은 연구의 NoC-MEM interface bandwidth $BW_{NoC\text{-}MEM} = f_{NoC}\times w\times C$ 다. 기호 하나가 연구 하나다. 대각선 아래(interface < memory)는 NoC 가 병목인 "network wall" 상태이고, 그림에서 여러 연구가 그 아래나 선 근처에 있다 §VI-C p.12. network wall 아래의 baseline 에서는 NoC bandwidth 를 늘리는 기법이 무엇이든 성능을 올리게 된다. 논문은 실제 GPU 는 interface 가 memory 보다 넓은 쪽(대각선 위)이며, 그렇지 않은 baseline 은 NoC 최적화의 이득을 과장할 수 있다고 쓴다 §VI-C p.12.

5.3.5

$f_{NoC}$ = NoC clock 주파수 · $w$ = NoC channel 폭 · $C$ = MP 수 · $BW_{MEM}$ = off-chip memory bandwidth

$$BW_{NoC\text{-}MEM} = f_{NoC}\times w\times C$$§VI-C p.12

$BW_{NoC\text{-}MEM} < BW_{MEM}$ 이면 NoC interface 가 병목이고, $BW_{NoC\text{-}MEM} > BW_{MEM}$ 이면 memory 가 병목이다. 논문은 후자가 최신 GPU 를 더 잘 대표한다고 쓴다 §VI-C p.12.

5.3.6

계산기: simulator baseline 이 network wall 아래인지 보기 논문에 없음

값은 예시다. 실제 GPU 의 $f_{NoC}$·$w$ 는 원문에 없다.

f_NoC (GHz) channel 폭 w (B) MP 수 C BW_MEM (GB/s)

Fig.23 — 5.3.7.cFig. 23: Bandwidth unfairness that occurs in a multi-hop (2D mesh) topology architecture for (a) round-robin arbitration and (b) globally fair, age-based arbitration. (p.12) network-only simulator [60] 로 6×6 2D mesh 에서 compute node 30 개가 가장자리 memory controller 6 개로 random traffic 을 보낼 때, node 위치(x, y)별 accepted throughput 이다(dimension-ordered routing). 높이 0 인 칸이 memory node 다. (a) round-robin arbitration 에서는 위치에 따라 throughput 이 최대 2.4× 차이 난다. (b) age-based 같은 globally fair arbitration 을 쓰면 고르게 된다 §VI-C p.12 각주 10. 2D mesh 에서는 node 마다 memory 까지 지나는 hop 과 경합 router 가 달라, 지역 arbitration 만으로는 uniform bandwidth 를 줄 수 없다 해석. 논문은 fair arbitration 이 flow control 복잡도를 늘리고, flat topology 에서 speedup 을 주기도 어렵다고 쓴다(Implication 6). hierarchical crossbar 를 baseline 으로 쓴 최근 연구 [34][35] 는 이 한계가 덜하지만, NoC → memory·L2 bandwidth 는 따로 신경 써서 정해야 한다고 덧붙인다 §VI-C p.12.

6결론과 한계

논문의 결론은 최신 GPU NoC 에서 latency 는 core 와 L2 slice 배치에 따라 non-uniform 하고 on-chip bandwidth 는 거의 uniform 하며, partition 이 여럿인 큰 GPU 는 bandwidth 와 성능에도 non-uniformity 를 더한다는 것이다. 이 특성이 GPU timing side-channel 과 NoC 설계에 함의를 갖는다고 정리한다 §VII p.12.
논문에 limitation 절은 없다. 아래 표는 본문 곳곳의 단서와 요약자 정리를 합친 것이다.

6.1

한계	근거
6.1.1GPU NoC 와 memory hierarchy 를 완전히 reverse-engineering 하지 않았다. H100 의 L2 동작은 whitepaper 문장으로만 설명한다	§III-C p.6 (원문이 밝힘)
6.1.2CPC 계층의 존재는 확인되지 않았고, A100 에서 GPC 사이 correlation 이 줄어든 이유도 "확실하지 않다" 고 쓴다	§III-C p.5 각주 3·4 (원문이 밝힘)
6.1.3random thread-block scheduling 이 다양한 timing 공격에 완전히 안전한지는 남은 문제다	§V-C p.11 (원문이 밝힘)
6.1.4A100·H100 의 slice 식별은 profiler 대신 "경합이 생기면 같은 slice" 라는 가정에 기댄다	§II-C p.3 각주 1 (원문이 밝힘)
6.1.5측정 GPU 는 NVIDIA 세 세대뿐이다. AMD·Intel GPU 나 chiplet 형 GPU, 소비자용 GPU 는 다루지 않는다	논문에 없음
6.1.6random scheduling 의 성능 비용(locality 손실, partition 간 배치로 인한 최대 1.7× 같은 지연)을 일반 workload 에서 재지 않았다	논문에 없음 · 1.7× 는 Fig.17(b)
6.1.7simulator 비판(Fig.21·22)은 선행 연구 설정의 비교이고, 수정한 NoC 모델로 그 연구들의 결론이 실제로 얼마나 바뀌는지는 재현하지 않았다	논문에 없음
6.1.8CUDA·driver 버전, clock 고정, 반복 횟수 같은 측정 조건이 없고, 표준편차는 일부 측정(Fig.2·9)에만 있다	논문에 없음
6.1.9abstract 의 "최대 약 70%" 는 본문의 어느 비교인지 명시가 없다. A100 far partition 약 400 cycle 과 near 약 230 cycle 의 비로 보인다	해석 · Fig.8(b)

7관련 연구

V100·A100 microbenchmark 연구 [22][23] 와 memory hierarchy 분석 [24] 은 GPU 구성요소를 자세히 다루지만 칩 안 interconnect 는 분석하지 않았고, multi-GPU 연구 [25]–[27] 는 GPU 사이 연결을 다룬다 §II-B p.2.
GPU NoC 설계 연구 [28]–[33] 는 대부분 simulator 와 2D mesh 같은 multi-hop network 를 가정해, 이 논문은 그 가정이 on-chip bandwidth 병목을 만들 수 있다고 지적한다 §II-B p.2. 논문에 비교표 figure 는 없다.

연구	한 일	이 논문과 차이
7.1.1Jia et al. [22] · Abdelkhalik et al. [23]	microbenchmark 로 V100·A100 구조 분석 (V100 L2 latency 193 cycle 보고)	칩 안 interconnect 는 자세히 다루지 않음. 이 논문의 V100 평균 212 cycle 과 비슷 (§III-A p.3)
7.1.2Throughput-effective NoC [28]	many-to-few-to-many traffic 에서 reply network 를 병목으로 지목	이 논문은 실제 GPU 에서 그 병목이 나타나지 않는다고 보임 (§VI-A p.11)
7.1.3[29]–[32] · packet coalescing [33]	reply network 영향을 줄이는 NoC 구조, NoC traffic 감소	multi-hop(2D mesh) baseline 가정 (§II-B p.2)
7.1.4NUBA [34] · memory-side LLC [35]	hierarchical crossbar 를 baseline 으로 가정	실제 GPU 와 비슷한 구성이지만 실제 NoC 분석은 없고, NoC bandwidth 가 L2 bandwidth 에 주는 영향을 고려하지 않음 (§II-B p.2)
7.1.5Accel-Sim [36]	검증된 GPU simulator	L2 bandwidth 차이가 최신 GPU 모델링 오차의 원인일 수 있다고 언급 (§II-B p.2, §VI-C p.12)
7.1.6AES 공격 [6] · Trident [7] · RSA 공격 [8]/[49]	GPU 에서 cache line 수·실행 시간 상관으로 key 복구	이 논문은 SM 위치에 따라 그 선형 관계가 이동함을 보임 (§V-B p.9–10)
7.1.7NoC covert channel [47] · Attack of the knights [51]	NoC microarchitecture 기반 covert channel, 2D mesh 거리로 L2 접근 패턴 추론	GPU 는 hop 수가 다르지 않을 수 있으나 latency 특성은 새 공격에 쓰일 수 있다고 언급 (§V-B p.10)
7.1.8BCoal [52] · RCoal [54] · 난독화 [53]	하드웨어 randomization 으로 timing 공격 완화	이 논문의 random thread-block scheduling 은 추가 하드웨어가 없음 (§V-C p.11)

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

TABLE I 과 Fig.1~23 을 슬라이드 순서대로 놓고, 슬라이드마다 말할 내용을 2~4 문장으로 적었다. 측정 알고리즘의 세부 구현은 빼고, 측정 방법 → latency → bandwidth → 실험 환경 → 보안 함의 → 설계 함의 흐름만 남겼다.
발화문은 요약자가 쓴 것이고 논문에 없음, 수치와 주장은 원문에서 확인한 것만 넣었다. 각 슬라이드 옆 시간은 권장 분량이다.

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

도입 · 60 초

오늘 소개할 논문은 MICRO 2024 에서 KAIST 와 Microsoft, UBC 가 낸 "Uncovering Real GPU NoC Characteristics" 입니다. 새 시스템을 제안하는 논문이 아니라, 실제 NVIDIA GPU 세 세대의 칩 안 network 를 직접 재 본 측정 논문입니다. 결론부터 말하면, SM 에서 L2 까지의 latency 는 위치마다 다르지만 bandwidth 는 거의 같고, A100 과 H100 처럼 칩이 둘로 나뉜 GPU 는 둘 다 달라집니다. 저자들은 이 성질을 GPU 보안과 simulator 설계 두 쪽으로 끌고 갑니다.

측정 대상인 V100, A100, H100 입니다. SM 은 80 개에서 132 개로, L2 는 6 MB 에서 50 MB 로, memory bandwidth 는 0.9 에서 3.35 TB/s 로 커졌습니다. L2 slice 는 V100 이 32 개, 나머지가 80 개입니다. 연결할 부품이 이만큼 늘면서 칩 안 network 가 성능에 중요해졌다는 것이 출발점입니다.

1 부 · latency (약 5 분)

측정은 thread 하나가 L1 을 우회해 고른 L2 slice 하나를 읽고, 그 round-trip 시간을 SM 의 clock 으로 재는 방식입니다. (a) 는 V100 의 SM 24 하나가 32 개 slice 를 읽은 latency 인데, 막대 높이가 slice 마다 다릅니다. 전체로 보면 175 에서 248 cycle 사이이고 평균은 약 212 입니다. (b) 는 GPC 별 분포인데, 평균은 거의 같지만 상자 폭은 GPC 마다 다르고 GPC4 는 최대 71 cycle 이 차이 납니다.

두 GPC 의 latency 분포를 나란히 놓았습니다. (a) GPC0 은 평균 213, 표준편차 13.9 cycle 로 넓게 퍼지고, (b) GPC2 는 평균 209, 표준편차 7.5 cycle 로 좁습니다. 평균만 보면 같은 GPC 처럼 보이지만 분포는 다르다는 것이 요점입니다.

slice 를 memory partition 별로 묶고, 묶음 안에서는 latency 순으로 정렬했습니다. 색은 진한 회색이 MP0, 흰색이 MP3 입니다. 위 두 칸은 GPC0 의 SM 두 개, 아래 두 칸은 GPC4 의 SM 두 개입니다. 같은 GPC 끼리는 모양이 거의 같고, GPC 가 바뀌면 어느 MP 가 가깝고 먼지가 바뀝니다. 그런데 MP 안에서 slice 순서는 네 SM 모두 같습니다.

die photo 와 측정 결과로 저자들이 추정한 V100 의 배치도입니다. GPC 여섯 개가 위아래로 있고, memory partition 네 개가 가운데에 있습니다. 오른쪽 확대 그림에서 서로 가까운 SM64 와 slice 17 은 180 cycle, 가장 먼 SM4 와 slice 15 는 217 cycle 입니다.

앞 그림의 GPC4 SM 일곱 개와 MP3 slice 여덟 개 사이 latency 입니다. x 축 오른쪽으로 갈수록 모든 SM 의 latency 가 오르고, SM 사이 간격은 거의 일정합니다. 즉 latency 는 SM 위치 몫과 slice 위치 몫이 더해진 모양입니다.

두 SM 의 slice 별 latency 목록이 얼마나 같은 모양인지를 Pearson correlation 으로 계산해 heatmap 으로 그렸습니다. (a) V100 은 같은 GPC 안이 거의 1 이고, 이웃 GPC 쌍도 높습니다. (b) A100 은 같은 GPC 안에서도 차이가 생기고, (c) H100 은 GPC 안에서 SM 네다섯 개 묶음끼리만 비슷합니다. 저자들은 이 묶음을 TPC 와 GPC 사이의 숨은 계층, CPC 로 봅니다. 이 heatmap 만 있으면 SM 이 칩 어디에 있는지 거꾸로 알아낼 수 있다는 점이 뒤의 보안 이야기로 이어집니다.

(a) 는 저자들이 추정한 H100 GPC 안의 CPC 세 개와 SM-to-SM network 입니다. (b) 는 H100 의 distributed shared memory 로 다른 SM 의 shared memory 를 읽은 latency 를 CPC 쌍별로 잰 것입니다. 같은 CPC0 안이 196 cycle 로 가장 빠르고, CPC2 안끼리가 약 213 cycle 로 가장 느립니다. 다만 CPC 의 존재 자체는 확인되지 않았다고 저자들도 밝힙니다.

위 줄은 L2 hit latency, 아래 줄은 L2 miss 때 memory 에서 L2 로 가져오는 시간이고, 열은 V100, A100, H100 입니다. (a) V100 은 모든 GPC 가 212 cycle 근처에 모입니다. (b) A100 은 두 무리로 갈려, 다른 partition 에서 온 요청은 약 400 cycle 입니다. (c) H100 은 partition 이 있는데도 고른 편인데, 저자들은 H100 의 L2 가 가까운 partition 쪽에 data 를 caching 하기 때문으로 봅니다. 그 대신 (f) 처럼 miss penalty 가 data 위치에 따라 두 층으로 갈립니다.

2 부 · bandwidth (약 4 분)

bandwidth 는 모든 thread 와 여러 thread block 으로 같은 slice 에 몰아 보내며 잽니다. (a) 칩 전체로 보면 L2 까지의 bandwidth 가 off-chip memory bandwidth 의 2.4 에서 3.5 배입니다. (b) V100 에서 SM 하나가 slice 하나에 내는 bandwidth 는 모든 조합에서 약 34 GB/s, 표준편차 0.147 로 거의 같습니다. (c) GPC 하나가 보내도 약 85 GB/s 로 좁게 모입니다. latency 와 달리 bandwidth 는 위치를 타지 않는다는 결과입니다.

SM 들이 계층으로 묶일 때 출력이 입력보다 몇 배 넓은지를 input speedup 이라 하고, read 와 write 로 나눠 쟀습니다. TPC 는 SM 두 개를 묶으니 2 가 나오면 손해가 없는데, read 는 세 GPU 모두 2 이고 V100 write 만 1.09 입니다. GPC 단은 full 이 7, 8, 9 인데 V100 은 그 절반, H100 은 85% 쯤입니다. 세대가 갈수록 칩 안 bandwidth 를 더 넉넉히 준다는 뜻입니다.

앞 그래프의 speedup 이 어디에 있는지 보여 주는 그림입니다. SM 두 개가 TPC 로, TPC 들이 GPC 로, GPC 들이 crossbar 를 거쳐 memory partition 으로 묶이고, 묶이는 세 자리에 TPC, GPC, L2 speedup 이 있습니다.

A100 에서는 bandwidth 도 partition 을 탑니다. (a) SM0 은 같은 partition 인 slice 0 에서 39 까지 약 39.5 GB/s, 건너편 40 에서 79 까지 약 26 GB/s 입니다. (b) 건너편에 있는 SM2 는 정확히 반대 모양입니다.

slice 하나에 대해 SM 마다 잰 bandwidth 분포입니다. (a) A100 은 같은 partition SM 과 다른 partition SM 으로 봉우리가 둘로 갈립니다. (b) H100 은 봉우리가 하나지만 V100 보다 넓게 퍼집니다.

같은 slice 로 보내는 SM 수를 늘려 가며 near 와 far bandwidth 를 비교했습니다. SM 이 한두 개일 때는 far 가 최대 28% 낮지만, 8 개쯤에서 둘 다 포화해 차이가 없어집니다. 저자들은 far 쪽 latency 가 길어서 Little's Law 에 따라 적은 SM 으로는 bandwidth 를 못 채운다고 설명합니다.

세 패널은 몰리는 쪽을 바꿔 가며 잰 것입니다. (a) 목적지 slice 를 한 MP 에 모으든 흩든 bandwidth 는 거의 같아, 받는 쪽은 넉넉합니다. (b) 반대로 보내는 SM 을 GPC 한두 개에 모으면, 28 SM 기준으로 여섯 GPC 에 흩을 때보다 약 62% 낮습니다. (c) 한 GPC 에 모은 14 SM 의 목적지 MP 를 1 개에서 4 개로 늘리면 218% 오릅니다. 그래서 저자들은 L2 쪽보다 SM 쪽 load balancing 이 더 중요하다고 말합니다.

실제 workload 인 Rodinia 의 bfs 와 gaussian 에서 시간별, slice 별 traffic 양입니다. 시간에 따라 색은 바뀌지만 세로로는 거의 한 색이라, address hashing 덕분에 traffic 이 모든 slice 에 고르게 퍼집니다. 그러니 NoC 는 traffic 을 분산하는 것보다 모든 목적지에 같은 bandwidth 를 주는 것이 중요하다는 결론입니다.

실험 환경 · 50 초

함의로 넘어가기 전에 실험 환경을 정리하겠습니다. GPU 는 TABLE I 의 V100, A100, H100 세 장이고, 측정은 모두 직접 작성한 CUDA microbenchmark 입니다. latency 는 SM 의 clock() 으로, 출발 SM 은 smid register 로, 목적지 slice 는 V100 에서는 nvprof 의 slice 별 counter, A100 과 H100 에서는 두 kernel 의 경합으로 찾았습니다. 실제 workload 로는 Rodinia 의 bfs 와 gaussian 을 썼습니다. 보안 실험은 기존 AES 와 RSA timing 공격 코드를 A100 등에서 다시 돌렸고, NoC 설계 실험은 선행 연구와 비슷한 설정의 GPU simulation 과 network-only simulator 를 썼습니다. host CPU, host 메모리, PCIe, CUDA 버전은 논문에 적혀 있지 않습니다.

3 부 · 보안 함의 (약 3 분)

먼저 공격 쪽입니다. 앞의 heatmap 으로 SM 위치를 알아내면 공격 kernel 을 피해자 옆에 놓는 데 쓸 수 있습니다. (a) 는 AES 공격이 이용하는 "읽은 cache line 수와 시간의 직선" 인데, 선 색인 SM 이 바뀌면 직선이 위아래로 이동합니다. 그래서 240 cycle 을 보면 cache line 이 12 개인지 18 개인지 모호해집니다. (b) 는 RSA 의 square kernel 로, 두 SM 이 다른 partition 에 놓이면 실행 시간이 최대 1.7 배, 같은 partition 안에서도 12% 까지 달라집니다.

이번에는 방어입니다. 지금 GPU 는 thread block 을 매번 같은 SM 에 배정하는데, 저자들은 kernel 마다 시작 SM 을 무작위로 바꾸자고 제안합니다. 그래프의 x 축은 key byte 후보, y 축은 후보별 correlation 이고 빨간 원이 정답입니다. (a) 기존 방식에서는 정답에서만 1 근처로 솟아 key 가 드러나고, (b) 무작위 배정에서는 그 봉우리가 사라집니다.

RSA 는 key 의 1 이 많을수록 실행 시간이 선형으로 늘어나는 점을 노립니다. (a) 기존 배정에서는 SM 별로 깨끗한 직선이 나오고, partition 에 따라 두 묶음으로 나뉩니다. (b) 무작위 배정에서는 같은 1 개수에서도 시간이 크게 흔들려, 20 억 cycle 을 보면 1 의 개수가 416 개에서 1920 개 사이 어디든 될 수 있습니다. 하드웨어 추가 없이 scheduling 만 바꾼다는 점이 장점이지만, 저자들도 완전한 방어인지는 남은 문제라고 말합니다.

4 부 · NoC 설계 함의 (약 3 분)

GPU traffic 은 많은 core 가 적은 memory 로 보내고 다시 흩어지는 모양입니다. (a) 는 기존 연구가 중시한 bisection bandwidth, 즉 network 단면의 폭을 표시했습니다. (b) 는 memory 자체의 bandwidth 와, memory 가 network 에 data 를 넣는 입구인 interface bandwidth 를 표시했습니다. 저자들의 주장은 직렬로 이어진 시스템은 가장 좁은 곳이 전체를 정하므로, 단면만이 아니라 이 입구도 넓어야 한다는 것입니다.

선행 연구와 비슷한 설정의 simulation 에서 memory channel 하나의 bandwidth 를 시간순으로 그렸습니다. 가끔 최대치에 닿지만 평균은 약 20% 에 그칩니다. reply 입구가 막혀 그 압력이 memory 와 request network 까지 거꾸로 막기 때문입니다. 실제 GPU 는 Fig.9 에서 85% 넘게 썼으니, simulator 의 NoC 가정이 실제와 다르다는 증거입니다.

기존 simulation 연구 열 편 남짓이 쓴 설정을 점으로 찍었습니다. x 축은 memory bandwidth, y 축은 NoC clock 곱하기 channel 폭 곱하기 partition 수로 구한 interface bandwidth 입니다. 대각선 아래는 network 가 memory 보다 좁은 "network wall" 이고, 여러 연구가 그 아래나 선 근처에 있습니다. 이런 baseline 에서는 NoC 를 넓히는 어떤 기법도 좋아 보이므로, 이득이 과장될 수 있다는 지적입니다.

6×6 2D mesh 에서 compute node 30 개가 가장자리 memory controller 6 개로 보낼 때 위치별 처리량입니다. (a) 흔한 round-robin 중재에서는 위치에 따라 최대 2.4 배 차이가 납니다. (b) 오래 기다린 packet 을 먼저 보내는 age-based 중재를 쓰면 고르게 되지만 flow control 이 복잡해집니다. 실제 GPU 는 bandwidth 를 고르게 주는데 mesh 로는 그게 어렵다는 것이 마지막 함의입니다.

마무리 · 45 초

정리하겠습니다. 실제 GPU 의 칩 안 network 는 latency 는 위치마다 다르고 bandwidth 는 고르며, partition 이 있는 큰 GPU 는 둘 다 달라집니다. 이 성질은 SM 위치를 알아내는 공격에도, 무작위 배정이라는 방어에도 쓰이고, simulator 의 NoC 가정이 network wall 을 만들면 연구 결론이 왜곡될 수 있습니다. 한계로는 NoC 를 완전히 reverse-engineering 하지는 못했고, CPC 의 존재와 무작위 배정의 안전성·성능 비용은 확인되지 않았다는 점을 들 수 있습니다.