21. AI Acceleration 단계별 학습 문서

원문 경로

/Users/keumky/Documents/New project 3/sources/mlsysbook/21-hw_acceleration/source.md

짧은 소개

이 장은 AI 시스템에서 하드웨어 가속이 왜 선택 사항이 아니라 거의 필수 조건이 되었는지 설명해요.

핵심은 “GPU를 쓰면 빨라진다” 정도가 아니에요. 신경망은 벡터, 행렬, 텐서 연산을 엄청나게 반복하고, 이 연산은 CPU의 일반적인 실행 방식과 잘 맞지 않아요. 그래서 GPU, TPU, NPU, 특수 ASIC, 칩렛, 멀티 GPU, TPU Pod, 이기종 SoC 같은 다양한 하드웨어가 등장했어요.

하지만 이 장이 계속 강조하는 더 중요한 메시지는 따로 있어요. AI 가속의 진짜 병목은 계산 자체보다 데이터 이동인 경우가 많다는 점이에요. 메모리에서 데이터를 가져오고, 여러 연산 장치 사이로 옮기고, 여러 칩 사이에서 동기화하는 비용이 실제 성능과 전력 효율을 결정해요.

읽는 방법

처음부터 모든 하드웨어 이름과 수치를 외우려고 하지 않아도 돼요. 이 장은 세 번에 나누어 읽으면 훨씬 잘 잡혀요.

1. 먼저 목차, 서론, 요약을 보며 큰 질문을 잡아보세요. “AI는 왜 일반 CPU만으로 부족할까요?”, “왜 메모리가 계속 문제일까요?”, “왜 컴파일러와 런타임까지 중요할까요?”를 확인하면 돼요.

2. 그다음 핵심 흐름을 따라가세요. 모델의 연산이 벡터와 행렬 연산으로 바뀌고, 그 연산이 가속기의 계산 유닛과 메모리 계층에 배치되고, 컴파일러와 런타임이 실행 계획을 만든다는 흐름을 보는 거예요.

3. 마지막으로 세부 구조를 파고들어요. SIMD/SIMT, tensor core, systolic array, memory wall, tiling, kernel fusion, multi-chip communication, heterogeneous SoC 같은 개념은 3단계에서 자세히 보면 좋아요.

이 문서는 이 장의 내용만 다루며, 다른 장의 문맥을 가져와 보충하지 않아요.

이 장의 한 줄 요약

AI acceleration은 신경망의 반복적인 텐서 연산을 특수 하드웨어, 메모리 계층, 데이터플로우, 컴파일러, 런타임이 함께 맞물려 처리하도록 설계해 성능과 전력 효율을 끌어올리는 하드웨어-소프트웨어 공동 설계입니다.

1단계: 중학교 수준

1. AI 계산은 아주 큰 공장 일과 비슷해요

AI 모델은 숫자를 엄청나게 많이 곱하고 더해요. 일반 컴퓨터의 CPU도 이 일을 할 수는 있어요. 하지만 CPU는 여러 종류의 일을 두루 잘하는 사람에 가까워요.

반대로 AI 가속기는 같은 종류의 계산을 아주 많이, 아주 빠르게 반복하도록 만든 공장 설비에 가까워요. 나사를 하나씩 손으로 조이는 대신, 같은 모양의 나사를 동시에 수천 개 조이는 자동화 라인을 만든 것과 비슷해요.

그래서 AI 하드웨어 가속은 “더 비싼 부품을 쓰자”가 아니라 “일의 성격에 맞는 도구를 쓰자”라는 생각에서 출발해요.

2. GPU, TPU, NPU는 역할이 조금씩 달라요

CPU는 복잡한 판단과 전체 진행 관리에 강해요. 운영체제를 돌리고, 프로그램 흐름을 조정하고, 다양한 작업을 처리해요.

GPU는 비슷한 계산을 한꺼번에 많이 처리하는 데 강해요. 원래는 그래픽을 빠르게 그리기 위해 발전했지만, AI의 반복 계산과 잘 맞아서 딥러닝에 널리 쓰이게 되었어요.

TPU나 NPU는 AI 계산에 더 직접적으로 맞춘 장치예요. 특히 행렬 계산이나 신경망 추론처럼 자주 반복되는 작업을 빠르고 전력 효율적으로 처리하도록 설계돼요.

3. 빠른 계산보다 더 중요한 것이 데이터 이동이에요

AI 가속기를 이해할 때 가장 중요한 비유는 창고예요.

계산하는 사람이 아무리 많아도, 필요한 재료가 창고에서 늦게 오면 일을 못 해요. AI에서도 비슷해요. 계산 장치가 아무리 빨라도 가중치, 입력값, 중간 결과가 제때 오지 않으면 계산 장치는 기다릴 수밖에 없어요.

그래서 좋은 AI 하드웨어는 단순히 계산기를 많이 넣는 장치가 아니에요. 데이터를 가까운 곳에 두고, 한 번 가져온 데이터를 여러 번 재사용하고, 멀리 있는 메모리로 자주 가지 않도록 만든 장치예요.

4. 컴파일러와 런타임은 작업 관리자예요

AI 모델을 사람이 직접 하드웨어에 하나씩 배치하는 것은 너무 어려워요. 어느 계산을 어느 장치에 보낼지, 어떤 데이터를 가까운 메모리에 둘지, 어떤 계산을 합쳐서 처리할지 결정해야 하기 때문이에요.

여기서 컴파일러는 미리 작업 계획표를 짜는 관리자예요. 모델을 보고 “이 계산들은 합치고, 이 데이터는 여기 두고, 이 연산은 이 장치에서 실행하자”라고 정리해요.

런타임은 실제 실행 중에 상황을 보며 조정하는 현장 관리자예요. 입력 크기가 바뀌거나, 메모리가 부족하거나, 여러 작업이 동시에 몰리면 실행 방식을 조금씩 바꿔요.

5. 여러 칩을 쓰면 무조건 빨라질까요?

꼭 그렇지는 않아요. 공장을 여러 개로 늘리면 생산량이 늘 수 있지만, 공장끼리 부품을 주고받는 시간이 너무 길면 오히려 전체 속도가 기대만큼 늘지 않아요.

AI에서도 여러 GPU나 여러 TPU를 쓰면 계산 능력은 커져요. 하지만 가중치, 기울기, 중간 결과를 서로 주고받아야 해요. 이 통신과 동기화가 새로운 병목이 돼요.

1단계 중간 정리

AI 하드웨어 가속은 “AI 계산에 맞는 전용 공장”을 만드는 일이에요. 하지만 좋은 공장은 일꾼만 많은 공장이 아니라, 재료가 가까이에 있고, 이동 동선이 짧고, 작업 순서가 잘 짜인 공장이에요.

2단계: 고등학교 수준

1. 신경망 계산은 결국 숫자의 흐름이에요

신경망의 한 층은 보통 입력값에 가중치를 곱하고, 결과를 더한 뒤, 활성화 함수를 통과시키는 흐름으로 볼 수 있어요.

간단히 쓰면 다음과 같아요.

[ y = Wx + b ]

여기서 (x)는 입력 벡터, (W)는 가중치 행렬, (b)는 편향, (y)는 출력이에요. 실제 모델에서는 이 계산이 한 번만 일어나는 것이 아니라, 수많은 층과 수많은 입력에 대해 반복돼요.

실행 흐름은 이렇게 생각하면 돼요.

2. 벡터, 행렬, 특수 함수가 기본 재료예요

AI 가속기가 빠른 이유는 자주 나오는 연산을 잘게 분석해서, 그 연산에 맞는 실행 장치를 만들기 때문이에요.

CPU가 숫자를 하나씩 처리하면 오래 걸려요. 벡터 유닛은 여러 숫자를 한 번에 처리하고, tensor core는 작은 행렬 블록을 한 번에 처리해요. systolic array는 숫자를 격자 안에서 흘려보내며 같은 데이터를 여러 번 재사용해요.

3. 계산 시간과 메모리 시간을 비교해야 해요

AI 하드웨어에서 중요한 질문은 “계산기가 얼마나 빠른가?”만이 아니에요. “데이터가 계산기까지 얼마나 빨리 도착하는가?”도 같이 봐야 해요.

메모리에서 데이터를 가져오는 시간은 간단히 이렇게 볼 수 있어요.

[ T_{\text{mem}} = \frac{M_{\text{total}}}{B_{\text{mem}}} ]

(M_{\text{total}})은 옮겨야 하는 전체 데이터 양이고, (B_{\text{mem}})은 메모리 대역폭이에요. 즉, 데이터가 많거나 대역폭이 좁으면 메모리 시간이 길어져요.

계산 시간은 이렇게 볼 수 있어요.

[ T_{\text{compute}} = \frac{\text{FLOPs}}{P_{\text{peak}}} ]

FLOPs는 필요한 계산량이고, (P_{\text{peak}})는 하드웨어의 최대 계산 성능이에요.

만약 (T_{\text{mem}})이 (T_{\text{compute}})보다 크면, 하드웨어는 계산보다 데이터 기다리기에 더 많은 시간을 쓰게 돼요. 이런 상황을 memory-bound라고 해요.

4. 메모리 계층은 가까울수록 빠르고 작아요

AI 가속기에는 여러 종류의 메모리가 있어요. 가까운 메모리는 빠르고 전력도 적게 쓰지만 용량이 작아요. 멀리 있는 메모리는 크지만 느리고 전력도 많이 써요.

그래서 좋은 가속 전략은 데이터를 가능한 한 가까운 메모리에 오래 두는 것이에요.

5. 데이터플로우는 무엇을 붙잡아 둘지 정하는 전략이에요

행렬 곱에서는 입력, 가중치, 중간 출력이 계속 움직여요. 이때 어떤 데이터를 가까운 곳에 고정해 둘지가 중요해요.

이 전략들은 모두 같은 목표를 가져요. 비싼 메모리 이동을 줄이고, 한 번 가져온 데이터를 최대한 여러 번 쓰는 거예요.

6. 컴파일러와 런타임이 실행 계획을 완성해요

고수준 모델은 바로 하드웨어에서 효율적으로 실행되지 않아요. 컴파일러는 모델을 계산 그래프로 보고 다음 일을 해요.

런타임은 실행 중의 변화를 다뤄요. batch 크기가 바뀌거나, sequence 길이가 달라지거나, 메모리 상황이 변하면 커널 선택과 스케줄링을 조정해요.

7. 여러 칩으로 확장하면 통신이 수학적 병목이 돼요

여러 GPU를 쓰면 계산량은 나눌 수 있어요. 하지만 학습에서는 기울기를 모으고, 모델 파라미터를 맞추고, 중간 결과를 주고받아야 해요.

이때 전체 속도는 “얼마나 많은 계산을 병렬화할 수 있는가”와 “얼마나 많은 시간이 통신에 묶이는가”의 균형으로 결정돼요. 그래서 많은 칩을 붙인다고 성능이 정확히 칩 수만큼 늘지는 않아요.

2단계 중간 정리

AI 가속은 다음 흐름으로 이해하면 좋아요.

모델의 층 → 벡터/행렬/특수 함수 연산 → 계산 유닛 배치 → 메모리 계층 배치 → 데이터플로우 선택 → 컴파일러 최적화 → 런타임 조정 → 단일 칩 또는 멀티 칩 실행

3단계: 대학교 수준

1. AI Hardware Acceleration Fundamentals

이 장의 출발점은 명확해요. 현대 머신러닝 시스템은 범용 CPU만으로는 실용적인 성능, 비용, 전력 조건을 만족시키기 어렵다는 점이에요.

원문은 CPU가 신경망 워크로드에서 보통 5~10% 수준의 낮은 활용률을 보인다고 설명해요. 이유는 CPU가 복잡한 제어 흐름, 분기, 불규칙한 메모리 접근, 단일 스레드 성능에 맞게 설계되어 있기 때문이에요. 반면 신경망은 정형화된 행렬 곱, 벡터 연산, 반복적인 데이터 흐름, 큰 메모리 대역폭 요구를 가져요.

즉, 병목은 단순히 “CPU가 느리다”가 아니에요. 워크로드의 성격과 아키텍처의 성격이 맞지 않는다는 것이 핵심이에요.

이 장에서 하드웨어 가속은 다음 세 가지 관점으로 설명돼요.

현대 AI 가속기는 계산 유닛만 특화하지 않아요. 메모리 계층, host-accelerator 연결, 실행 스케줄링, 컴파일러 최적화까지 함께 설계해야 실제 성능이 나와요.

2. Evolution of Hardware Specialization

2.1 Specialized Computing

하드웨어 특수화의 역사는 AI에서 갑자기 시작된 것이 아니에요. 원문은 Intel 8087 수학 코프로세서를 초기 예로 들어요. 8087은 CPU가 잘 못하던 부동소수점 계산을 전담해 과학 계산과 엔지니어링 계산을 크게 가속했어요.

이 사례에서 중요한 패턴이 생겨요.

1. 특정 워크로드에서 반복적으로 느린 부분을 찾습니다.
2. 그 연산을 위한 전용 회로를 만듭니다.
3. CPU와 전용 장치 사이의 인터페이스를 정리합니다.
4. 성공한 특수 기능은 나중에 일반 프로세서 안으로 통합됩니다.

실제로 8087 같은 외부 코프로세서의 역할은 이후 Intel 486DX의 온칩 FPU처럼 CPU 내부 기능으로 흡수되었어요. 이 반복 패턴은 이후 그래픽, 신호 처리, 네트워크 처리, AI 가속에서도 다시 나타나요.

2.2 Parallel Computing and Graphics Processing

그래픽 처리는 병렬 하드웨어 발전의 중요한 계기였어요. 3D 그래픽은 많은 픽셀, 정점, 텍스처에 비슷한 계산을 반복해야 하므로 병렬 처리와 잘 맞아요. GPU는 이 요구에 맞춰 발전했고, 많은 동일 계산 유닛과 넓은 메모리 인터페이스를 갖게 되었어요.

이 병렬성은 딥러닝과 잘 맞았어요. 신경망 학습의 행렬 곱과 convolution도 많은 독립 계산을 동시에 처리할 수 있기 때문이에요. AlexNet이 GPU를 이용해 학습 시간을 크게 줄인 사례는 GPU가 AI 학습의 핵심 하드웨어로 자리 잡는 전환점이 되었어요.

DSP와 네트워크 프로세서도 중요한 선례예요. DSP는 multiply-accumulate, circular buffer, 필터링, 변환 연산에 맞춘 구조를 발전시켰고, 네트워크 프로세서는 패킷 처리를 위해 여러 코어와 특수 메모리 관리를 결합했어요. 이런 사례들은 모두 “도메인에 맞는 데이터 경로와 메모리 구조를 만들면 큰 효율을 얻는다”는 원칙을 보여줘요.

2.3 Emergence of Domain-Specific Architectures

도메인 특화 아키텍처가 중요해진 배경에는 Moore’s Law 둔화와 Dennard scaling의 종료가 있어요. 예전에는 트랜지스터가 작아질수록 더 빠른 클럭과 더 많은 트랜지스터를 비교적 자연스럽게 얻을 수 있었어요. 하지만 전력 밀도, 누설 전류, 제조 비용, 물리적 한계가 커지면서 범용 CPU의 클럭을 계속 올리는 방식이 어려워졌어요.

그래서 컴퓨터 구조는 “모든 일을 그럭저럭 잘하는 구조”에서 “중요한 일을 매우 효율적으로 하는 구조”로 이동했어요.

도메인 특화 아키텍처의 핵심 원리는 네 가지예요.

스마트폰의 4K 비디오 디코딩도 좋은 예예요. 범용 CPU로 처리하면 전력과 성능이 부담스럽지만, 전용 비디오 코덱은 같은 작업을 훨씬 적은 전력으로 처리해요. AI 가속기도 이와 같은 특수화의 연장선에 있어요.

2.4 Machine Learning Hardware Specialization

머신러닝 워크로드에는 특수화하기 좋은 특징이 많아요.

원문은 데이터 이동의 에너지 비용을 특히 강조해요. DRAM 접근은 multiply-accumulate 연산보다 훨씬 많은 에너지를 소비해요. 따라서 AI 가속기의 주된 목표는 계산을 빠르게 하는 것뿐 아니라 데이터를 덜 움직이게 만드는 것이에요.

학습과 추론도 요구가 달라요.

데이터센터는 수백 와트 전력으로 최대 처리량을 추구할 수 있지만, 엣지 장치는 밀리와트 수준에서 실시간 추론을 해야 해요. 그래서 단일한 “최고의 AI 칩”은 없고, 배포 환경에 맞는 다양한 가속기 생태계가 생겨요.

원문은 현대 AI 가속기를 세 하위 시스템으로 정리해요.

1. Processing substrate: tensor core, vector unit, special function unit, processing element가 실제 계산을 수행해요.
2. Memory hierarchy: SRAM, cache, scratchpad, HBM 등이 데이터를 가까이 두고 재사용하게 해요.
3. Host interface: CPU가 전체 제어를 맡고, accelerator가 무거운 병렬 연산을 맡도록 연결해요.

3. AI Compute Primitives

3.1 Compute primitive가 필요한 이유

신경망은 모델 종류가 달라도 자주 등장하는 계산 패턴이 있어요. 입력에 가중치를 곱하고, 결과를 누적하고, 비선형 함수를 적용하는 흐름이에요. 이 반복 패턴을 하드웨어 수준에서 잘 처리하도록 만든 기본 단위가 AI compute primitive예요.

좋은 primitive가 되려면 세 조건을 만족해야 해요.

원문은 대표 primitive로 vector operations, matrix operations, special function units를 다뤄요.

3.2 Vector Operations

벡터 연산은 여러 데이터 원소에 같은 연산을 동시에 적용해요. 전통적인 scalar 실행은 값을 하나씩 읽고, 하나씩 곱하고, 하나씩 누적해요. 하지만 신경망에서는 같은 형태의 연산이 수백만 번 반복되므로, 여러 값을 한 번에 처리하는 것이 훨씬 효율적이에요.

RISC-V vector 예시에서 원문은 8개 값을 병렬로 처리하면 명령 수가 크게 줄어든다고 설명해요. 배치 32, 입력 256, 출력 512 같은 dense layer는 수백만 번의 multiply-accumulate가 필요하므로, 벡터화의 효과가 층 전체에서 누적돼요.

벡터 연산은 단순한 원소별 덧셈과 곱셈만 의미하지 않아요.

역사적으로 벡터 처리는 Cray-1 같은 슈퍼컴퓨터에서 과학 계산을 위해 중요했어요. 오늘날 AI 가속기는 이 오래된 원리를 신경망 규모에 맞게 다시 사용하고 있어요.

3.3 Matrix Operations

행렬 연산은 신경망의 중심이에요. fully connected layer, convolution, attention projection은 모두 큰 틀에서 행렬 곱으로 표현할 수 있어요.

예를 들어 batch 32, input feature 256, output neuron 512인 선형 층은 (256 \times 512 = 131{,}072)개의 가중치를 사용해요. 각 출력은 많은 입력과 가중치의 곱을 더해서 만들어져요.

Convolution도 im2col 같은 변환을 통해 행렬 곱으로 바꿀 수 있어요. 이 방식은 메모리 사용량을 늘릴 수 있지만, 고도로 최적화된 GEMM 하드웨어와 라이브러리를 사용할 수 있게 해요.

행렬 가속기는 벡터 처리보다 더 큰 블록을 한 번에 다뤄요. 원문은 (16 \times 16) 블록을 예로 들어요. 이렇게 하면 256개의 multiply-accumulate를 구조적으로 동시에 처리할 수 있어요.

3.4 Special Function Units

행렬 곱만으로는 신경망을 만들 수 없어요. ReLU, sigmoid, softmax, batch normalization, square root, exponential 같은 비선형 연산도 필요해요.

이 함수들은 수식으로 보면 간단해 보이지만 일반 CPU에서 실행하면 여러 문제가 생겨요.

Special Function Unit, 즉 SFU는 이런 함수를 전용 회로로 처리해요. ReLU는 비교와 선택을 전용 논리로 처리하고, square root는 고정된 반복 횟수의 하드웨어 근사를 사용하고, exponential과 logarithm은 작은 lookup table과 보간 회로를 조합할 수 있어요.

3.5 SIMD, SIMT, Tensor Core, PE

compute primitive는 실행 유닛으로 포장돼요.

SIMD는 하나의 명령을 여러 데이터에 적용해요. SIMT는 GPU에서 발전한 모델로, 많은 스레드가 같은 명령 흐름을 공유하면서 각자 다른 데이터를 처리해요. NVIDIA GPU의 SM은 수많은 thread를 warp 단위로 실행하고, warp 안의 thread들은 같은 명령을 lock-step으로 수행해요.

이 구조는 효율적이지만 조건 분기가 갈라지는 warp divergence가 생기면 성능이 떨어질 수 있어요. 또한 thread들이 연속된 메모리를 접근해야 memory coalescing이 잘 되어 대역폭을 효율적으로 사용할 수 있어요.

Tensor core는 행렬 블록 곱을 전용 명령으로 처리해요. scalar 또는 vector loop를 길게 펼치는 대신, 작은 matrix multiply-accumulate를 하드웨어 블록으로 처리해요. NVIDIA V100 이후 tensor core는 대규모 모델 학습을 가능하게 만든 핵심 요소 중 하나로 설명돼요.

Processing Element, PE는 더 큰 구성 단위예요. 보통 vector unit, tensor core, SFU, local memory를 포함하고, 여러 PE가 배열이나 타일로 구성돼요. Graphcore IPU, Cerebras wafer-scale processor, Tesla D1 같은 구조는 PE를 대량으로 배치해 병렬성을 끌어올려요.

3.6 Systolic Arrays

Systolic array는 AI 가속기에서 매우 중요한 구조예요. 처리 요소를 격자처럼 배치하고, 데이터가 이웃 처리 요소로 규칙적으로 흐르며 계산돼요.

행렬 곱 (C[i,j] = \sum_k A[i,k] \times B[k,j])를 생각해볼게요. systolic array에서는 (A)의 원소가 한 방향으로, (B)의 원소가 다른 방향으로 흐르며 각 PE에서 만나요. PE는 곱하고, partial sum에 더하고, 값을 다음 PE로 넘겨요.

이 방식의 장점은 operand reuse예요. 한 번 가져온 가중치나 activation이 격자를 지나며 여러 계산에 참여해요. 외부 메모리에서 같은 값을 반복해서 가져오는 일을 줄이므로 에너지 효율이 좋아져요.

하지만 systolic array도 마법은 아니에요. (128 \times 128) array는 한 사이클에 매우 많은 연산을 할 수 있지만, 매 사이클 필요한 입력과 가중치가 계속 공급되어야 해요. 메모리 대역폭이 부족하면 array는 놀게 돼요.

그래서 quantization과 pruning 같은 모델 최적화가 하드웨어 관점에서도 중요해져요. FP32를 INT8로 줄이면 weight traffic이 4분의 1로 줄고, 구조적 pruning은 이동해야 할 데이터와 계산량을 함께 줄여요.

3.7 Numerics in AI Acceleration

정밀도는 AI 가속에서 성능, 정확도, 에너지의 균형점이에요.

현대 가속기는 mixed precision을 많이 사용해요. 예를 들어 행렬 곱은 FP16이나 BF16으로 수행하고, 누적은 FP32로 유지해 정밀도 손실을 줄일 수 있어요. 추론에서는 INT8이나 INT4를 사용하되 중요한 activation은 더 높은 정밀도로 보존할 수 있어요.

정밀도를 낮추면 메모리 이동량이 줄고, 같은 회로에서 더 많은 값을 병렬 처리할 수 있으며, 정수 연산의 전력 이점도 얻을 수 있어요. 하지만 정확도, 안정성, 공정성, 신뢰성 문제를 함께 봐야 해요.

3.8 Architectural Integration and Cost-Performance

원문은 실행 유닛 구성이 목표 워크로드에 따라 달라진다고 설명해요. NVIDIA A100은 FP16 학습에 강한 tensor core를 대량으로 통합하고, Google TPUv4는 BF16 matrix multiplication과 systolic array 처리량을 강조해요. Intel Sapphire Rapids는 INT8 최적화 tensor 기능을 데이터센터 추론에 활용하고, Apple M1 계열 Neural Engine은 모바일 전력 제약에 맞춰 설계돼요.

배포 결정에서는 peak FLOPS만 보면 안 돼요. 원문은 V100과 A100 비교를 통해 실제 transformer 학습이 memory-bandwidth-bound인 경우가 많다고 설명해요. A100이 peak FLOPS에서 보이는 차이보다 더 큰 실제 이득을 주는 이유는 더 높은 HBM 대역폭과 에너지 효율 때문이에요.

따라서 비용 분석의 핵심 지표는 다음과 같아요.

4. AI Memory Systems

4.1 AI Memory Wall

AI memory wall은 계산 처리량이 메모리 대역폭보다 훨씬 빠르게 증가하면서 생기는 병목이에요. 원문은 지난 20년 동안 peak compute는 2년마다 약 3.0배 성장했지만, DRAM bandwidth는 약 1.6배 성장했다고 설명해요.

예를 들어 NVIDIA H100은 매우 높은 TFLOPS를 제공하지만, 전체 계산 유닛을 꽉 채우려면 바이트당 매우 많은 연산이 필요해요. 하지만 일반적인 신경망은 바이트당 연산량이 그렇게 높지 않은 경우가 많아요. 그래서 계산 유닛은 충분히 많아도 데이터를 기다리게 돼요.

메모리 병목은 세 가지로 나타나요.

4.2 Memory Access Patterns

ML 실행 중 움직이는 데이터는 크게 세 종류예요.

메모리 시간과 계산 시간은 다음처럼 비교해요.

[ T_{\text{mem}} = \frac{M_{\text{total}}}{B_{\text{mem}}} ]

[ T_{\text{compute}} = \frac{\text{FLOPs}}{P_{\text{peak}}} ]

(T_{\text{mem}} > T_{\text{compute}})이면 memory-bound예요. 이 경우 하드웨어의 peak compute를 높이는 것보다 데이터 이동을 줄이는 최적화가 더 중요해요.

4.3 Irregular Memory Access

ML 워크로드는 항상 규칙적이지 않아요. batch size, layer type, sparsity, dynamic computation path가 메모리 접근 패턴을 바꿔요.

작은 batch는 cache 재사용이 낮고, 큰 batch는 메모리 대역폭 요구를 키워요. CNN은 공간적 지역성이 있어 cache와 tiling이 잘 맞지만, fully connected layer는 큰 weight matrix에 자주 접근해야 해요. Transformer는 key-value matrix와 attention span 때문에 sequence 길이에 따라 접근 패턴이 달라져요.

Sparsity도 양면성이 있어요. 0에 가까운 weight나 activation을 건너뛰면 계산량은 줄어들 수 있어요. 하지만 sparse representation은 흩어진 위치의 데이터를 가져오게 만들어 cache와 prefetching을 어렵게 할 수 있어요. Mixture of Experts처럼 입력마다 활성화되는 경로가 달라지는 모델은 더 동적인 메모리 패턴을 만들어요.

4.4 Memory Hierarchy

AI 가속기의 메모리 계층은 속도, 용량, 에너지 사이의 절충이에요.

특히 scratchpad는 AI 가속기에서 중요해요. cache는 하드웨어 정책에 따라 evict되지만, scratchpad는 컴파일러나 런타임이 어떤 데이터를 유지할지 더 명시적으로 계획할 수 있어요. systolic array나 CNN convolution처럼 재사용 패턴이 분명한 작업에 잘 맞아요.

4.5 Memory Bandwidth and Architectural Trade-offs

원문은 H100, TPUv4, Apple M3 Neural Engine 같은 사례를 통해 bandwidth-capacity-power trade-off를 설명해요.

H100은 높은 HBM3 bandwidth와 큰 용량으로 대규모 모델에 유리해요. TPUv4는 상대적으로 낮은 외부 bandwidth라도 systolic array와 on-chip reuse를 통해 tensor operation의 에너지 효율을 높여요. 모바일 가속기는 훨씬 낮은 전력과 비용 제약 안에서 충분한 bandwidth efficiency를 추구해요.

또한 HBM은 DDR5보다 훨씬 비싸요. 클라우드 training은 높은 HBM bandwidth를 비용으로 감당할 수 있지만, 엣지 추론은 낮은 비용과 낮은 전력이 우선이에요. 그래서 배포 환경에 따라 메모리 구조 선택이 달라져요.

4.6 Host-Accelerator Communication

GPU나 TPU는 CPU와 별도의 메모리 공간을 갖는 경우가 많아요. 따라서 실행 전에 데이터를 accelerator memory로 복사하고, CPU가 실행 명령을 내리고, accelerator가 계산하고, 결과를 다시 host로 가져오는 흐름이 생겨요.

동기식 transfer는 안전하지만 실행을 막을 수 있어요. 비동기 transfer는 계산과 데이터 이동을 겹칠 수 있지만, 정확한 순서와 데이터 준비 상태를 잘 관리해야 해요.

4.7 Model Memory Pressure

모델 구조마다 메모리 부담이 달라요.

MLP는 규칙적이지만 weight bandwidth가 중요해요. CNN은 공간적 재사용이 좋아 메모리 최적화 기회가 많아요. Transformer는 parameter와 activation이 크고 attention 접근이 불규칙해 memory capacity와 interconnect bandwidth의 영향을 크게 받아요.

5. Hardware Mapping Fundamentals for Neural Networks

5.1 Mapping이란 무엇인가요?

Mapping은 신경망 계산을 하드웨어 자원에 대응시키는 일이에요. 어떤 연산을 어느 PE나 tensor core에서 실행할지, 어떤 데이터를 어느 메모리 계층에 둘지, 데이터가 언제 이동할지 정해야 해요.

원문은 mapping을 세 부분으로 나눠요.

좋은 mapping은 off-chip memory access를 줄이고, compute utilization을 높이고, 데이터 이동을 효율화해요.

5.2 Computation Placement

AI 가속기에는 수천 개에서 수십만 개 이상의 처리 요소가 있을 수 있어요. H100은 수많은 streaming processor와 tensor core를 갖고, TPU는 systolic array를 사용하며, Cerebras 같은 wafer-scale 시스템은 아주 많은 코어를 한 칩 규모로 통합해요.

이런 구조에서는 작은 placement 실수도 큰 손실로 이어져요. 일부 PE는 바쁘고 일부 PE는 idle이면 전체 throughput이 떨어져요. 데이터를 멀리 있는 메모리에서 가져와야 하도록 배치하면 지연시간과 전력도 증가해요.

모델별로 placement 난이도도 달라요.

5.3 Memory Allocation

Memory allocation은 데이터가 어디에 저장되고 언제 이동할지 결정해요. GPU는 global memory, shared memory, register를 조합하고, TPU는 on-chip SRAM scratchpad를 systolic array에 맞춰 사용해요. wafer-scale processor는 코어와 메모리가 넓게 퍼져 있으므로 interconnect traffic을 고려해야 해요.

나쁜 memory allocation은 세 가지 문제를 만들어요.

CNN은 비교적 규칙적인 layout으로 이득을 얻지만, Transformer와 GNN은 더 동적이고 적응적인 allocation이 필요해요.

5.4 Combinatorial Complexity

Mapping이 어려운 이유는 선택지가 폭발적으로 많기 때문이에요.

반복문 차원이 (d)개라면 실행 순서만 해도 다음만큼 가능해요.

[ \mathcal{O} = d! ]

convolution이 7개 loop dimension을 갖는다면 (7! = 5{,}040)가지 순서가 생겨요. 메모리 계층이 (l)개이면 순서 선택은 ((d!)^l)처럼 더 커져요.

병렬화 선택도 커져요. (d)개 loop 중 (k)개를 병렬화 대상으로 고르면 가능한 배치는 다음처럼 나타낼 수 있어요.

[ \mathcal{P} = \frac{d!}{(d-k)!} ]

예를 들어 6개 loop 중 3개를 선택하면 120가지가 가능해요.

메모리 배치는 더 빠르게 커져요.

[ \mathcal{M} = n^{d \times l} ]

(d=5), (l=3), (n=4)라면 (4^{15} = 1{,}073{,}741{,}824)가지가 돼요.

전체 search space는 원문에서 다음처럼 근사돼요.

[ \mathcal{S} = \left( n^d \times d! \times \frac{d!}{(d-k)!} \right)^l ]

이 수식의 의미는 단순해요. 실행 순서, 병렬화 방식, 메모리 배치, 메모리 계층이 서로 얽히기 때문에 사람이 모든 조합을 직접 확인하는 것은 불가능하다는 뜻이에요. 그래서 컴파일러, cost model, profiling, heuristic, 자동 튜닝이 필요해요.

6. Dataflow Optimization Strategies

6.1 Building Blocks

Dataflow optimization은 mapping이 정한 위치와 메모리 배치를 실제 데이터 흐름으로 바꾸는 단계예요. 핵심 기법은 다음과 같아요.

6.2 Data Movement Patterns

행렬 곱에서 (Z[i,j])를 만들려면 weight row, input column, partial sum이 필요해요. 같은 weight가 여러 input에 쓰이고, partial sum은 여러 번 누적돼요. 이때 무엇을 local에 오래 둘지가 dataflow 전략의 핵심이에요.

세 전략 모두 memory wall에 대한 답이에요. 데이터 이동이 계산보다 훨씬 비싸기 때문에, 가장 재사용 가치가 큰 데이터를 가까이 두는 것이 핵심이에요.

6.3 Memory-Efficient Tensor Layouts

Tensor layout은 다차원 데이터를 메모리에 어떤 순서로 펼칠지 정해요. layout이 맞지 않으면 같은 모델도 훨씬 느릴 수 있어요.

GPU에서는 memory coalescing이 중요해요. warp 안의 thread들이 연속된 주소를 읽으면 memory controller가 여러 요청을 하나의 효율적 transaction으로 합칠 수 있어요. 반대로 흩어진 주소를 읽으면 bandwidth가 크게 떨어질 수 있어요.

TensorFlow, PyTorch, XLA, cuDNN, oneDNN 같은 프레임워크와 라이브러리는 target hardware에 맞춰 layout 변환을 자동으로 수행할 수 있어요. 개발자가 직접 layout을 조정할 수도 있지만, 많은 경우 compiler와 runtime이 결정해요.

6.4 Kernel Fusion

Kernel fusion은 여러 연산을 하나의 커널로 합쳐 중간 tensor를 메모리에 쓰고 다시 읽는 비용을 없애는 기법이에요.

나이브한 실행은 다음처럼 중간 결과를 계속 만들 수 있어요.

[ X’ = \text{ReLU}(X) ]

[ X” = \text{BatchNorm}(X’) ]

[ Y = \alpha \cdot X” + \beta ]

Fusion을 적용하면 다음처럼 하나의 흐름으로 합칠 수 있어요.

[ Y = \alpha \cdot \text{BatchNorm}(\text{ReLU}(X)) + \beta ]

중간값이 register나 local memory 안에 머물면 DRAM traffic이 줄고 kernel launch overhead도 줄어요.

하지만 모든 연산을 무조건 fusion하면 안 돼요. element-wise operation은 fusion에 잘 맞지만, convolution이나 matrix multiplication처럼 global data dependency가 큰 연산은 직접 fusion이 어려울 수 있어요. 또한 너무 많이 fusion하면 register pressure가 커져 occupancy가 낮아지거나 spill이 발생해 이득이 줄어들 수 있어요.

6.5 Memory-Efficient Tiling

Tiling은 큰 행렬이나 tensor를 작은 tile로 나눠 빠른 메모리에 올리고, 그 안에서 여러 번 재사용하는 기법이에요.

행렬 곱은 다음처럼 표현돼요.

[ C = A \times B ]

[ C[i,j] = \sum_k A[i,k] \times B[k,j] ]

나이브한 구현은 (A)와 (B)의 같은 값을 여러 번 DRAM에서 다시 가져올 수 있어요. Tiling은 작은 submatrix를 cache, shared memory, register에 올려 재사용해요.

tile size가 너무 작으면 재사용 이득이 작고, 너무 크면 fast memory를 넘쳐 cache thrashing이 생겨요. 병렬 하드웨어에서는 tile이 고르게 분배되지 않으면 load imbalance도 생겨요. 그래서 compiler와 runtime은 register blocking, double buffering, hierarchical tiling, prefetching을 함께 고려해요.

6.6 Applying Mapping Strategies

모델별로 우선순위가 달라요.

현대 모델은 여러 층이 섞여 있으므로 hybrid mapping이 필요해요. Vision Transformer처럼 patch embedding은 convolution-like하고, self-attention은 activation reuse가 중요하고, MLP block은 GEMM 최적화가 중요해요. Google TPU, NVIDIA GPU, Graphcore IPU 같은 하드웨어는 이런 layer-specific 전략을 지원하도록 발전하고 있어요.

7. Compiler Support

7.1 ML Compiler가 다른 이유

전통적인 컴파일러는 보통 순차적 프로그램, 함수 호출, instruction scheduling, register allocation에 집중해요. 반면 ML compiler는 tensor computation graph를 최적화해야 해요.

ML compiler는 고수준 모델을 target hardware에 맞는 실행 계획으로 바꿔요.

7.2 ML Compilation Pipeline

원문은 ML compilation pipeline을 다음 단계로 정리해요.

7.3 Graph Optimization

Graph optimization은 hardware-specific code를 만들기 전, 그래프 수준에서 비효율을 줄이는 단계예요.

대표 기법은 다음과 같아요.

XLA, TVM, TensorRT, MLIR 같은 컴파일러는 pattern recognition과 rewrite rule을 이용해 이런 변환을 자동 적용해요.

7.4 Kernel Selection

Kernel은 특정 연산을 특정 하드웨어에서 효율적으로 실행하는 구현이에요. 같은 matrix multiplication이라도 CPU에서는 vectorized GEMM, GPU에서는 tensor core kernel, TPU에서는 systolic array용 구현, 추론에서는 INT8 kernel이 선택될 수 있어요.

Kernel selection에는 여러 방식이 있어요.

잘못된 kernel 선택은 graph optimization의 이득을 무너뜨릴 수 있어요. GPU에서 tensor core를 쓰지 않는 matrix kernel을 고르면 성능이 크게 낮아질 수 있고, 정확도가 필요한 모델에 무리하게 INT8 kernel을 쓰면 수치 안정성이 깨질 수 있어요.

7.5 Memory Planning

Memory planning은 tensor가 어떤 layout으로 저장되고, 어떤 buffer를 재사용하며, 어떤 데이터 이동을 줄일지 결정해요.

핵심은 세 가지예요.

1. Tensor layout optimization: target hardware가 좋아하는 메모리 접근 패턴에 맞춰 layout을 바꿔요.
2. Buffer allocation and reuse: 중간 tensor를 계속 새로 할당하지 않고 재사용해 memory footprint를 줄여요.
3. Movement minimization: tiling으로 fast local memory 안에 계산을 맞춰 off-chip access를 줄여요.

이 단계가 부족하면 convolution feature map layout 변환이 계속 발생하거나, Transformer가 edge device에서 off-chip memory를 너무 자주 접근해 real-time latency를 만족하지 못할 수 있어요.

7.6 Computation Scheduling and Code Generation

Computation scheduling은 언제, 어디서, 어떤 순서로 계산할지 정해요. task partitioning, execution order optimization, resource allocation, synchronization이 포함돼요.

GPU에서는 matrix multiplication과 convolution을 수많은 CUDA core와 tensor core에 나누고, TPU에서는 systolic array에 맞게 structured dataflow를 스케줄링해요. scheduling은 computation과 data transfer를 겹쳐 memory latency를 숨기는 데도 중요해요.

Code generation은 마지막 단계예요. CPU와 GPU에는 machine code나 optimized assembly를 만들 수 있고, TPU나 FPGA 같은 장치에는 runtime이 해석하는 execution graph나 bytecode 형태가 될 수 있어요.

컴파일이 끝나도 모든 문제가 끝나는 것은 아니에요. 실제 실행 환경에서는 batch size, sequence length, 공유 자원, 메모리 상태가 바뀌므로 runtime support가 필요해요.

8. Runtime Support

8.1 Runtime이 필요한 이유

Compiler는 실행 전에 최적화를 해요. 하지만 실제 배포 환경은 고정되어 있지 않아요. batch size가 바뀌고, 여러 workload가 같은 accelerator를 공유하고, 메모리 압박이 생기고, latency constraint가 달라질 수 있어요.

AI runtime은 이런 동적 상황에서 다음 일을 해요.

8.2 AI Runtime과 전통 Runtime의 차이

전통 runtime은 주로 CPU thread, 함수 호출, 일반 메모리 allocation을 관리해요. AI runtime은 computation graph, tensor dependency, parallel kernel, accelerator memory를 관리해요.

AI runtime은 특히 adaptive해야 해요. cloud accelerator는 multi-tenant일 수 있고, 모바일 SoC는 thermal state가 계속 바뀌고, 입력 sequence 길이가 요청마다 달라질 수 있어요.

8.3 Dynamic Kernel Execution

Dynamic kernel execution은 실행 중 상황에 맞춰 kernel, tiling, memory allocation, execution order를 조정하는 과정이에요.

예를 들어 고해상도 이미지 batch가 들어와 예상보다 메모리를 많이 쓰면, runtime은 tile 크기를 줄여 on-chip memory에 맞출 수 있어요. Transformer 추론에서 sequence length가 짧으면 latency-optimized kernel을 쓰고, 길면 throughput이나 memory 효율이 좋은 kernel을 선택할 수 있어요.

비동기 실행과 double buffering도 중요해요. 이전 batch를 계산하는 동안 다음 batch 데이터를 미리 가져오면, 계산 유닛이 데이터 이동을 기다리는 시간을 줄일 수 있어요.

8.4 Runtime Kernel Selection and Scheduling

Runtime은 compiler가 고른 kernel을 실행 중에 바꿀 수도 있어요. GPU가 tensor core를 갖고 있고 FP16이 허용되면 FP16 kernel을 선택할 수 있지만, 수치 불안정성이 보이면 mixed precision을 선택할 수 있어요.

Batch size도 kernel 선택에 영향을 줘요. 작은 batch는 latency-optimized kernel이 좋고, 큰 batch는 throughput-optimized kernel이 좋을 수 있어요.

Scheduling은 선택한 kernel을 언제 실행할지 정해요. convolution, batch normalization, activation이 pipeline을 막지 않도록 interleave하고, 중간 feature map이 필요해지기 전에 cache에 준비해요. multi-accelerator 환경에서는 더 복잡한 scheduling이 필요해져요.

9. Multi-Chip AI Acceleration

9.1 단일 칩을 넘어가는 이유

현대 AI 모델은 단일 accelerator 하나로 감당하기 어려운 계산량과 메모리 요구를 가질 수 있어요. 그래서 chiplet, multi-GPU, TPU Pod, wafer-scale AI 같은 확장 방식이 등장해요.

하지만 multi-chip은 단순히 칩을 여러 개 붙이는 문제가 아니에요. 계산 분배, inter-chip communication, memory coherence, synchronization, fault tolerance가 모두 새로운 병목이 돼요.

9.2 Chiplet-Based Architectures

Chiplet은 큰 칩 하나를 통째로 만드는 대신, 작은 특수 die 여러 개를 한 패키지 안에서 연결하는 방식이에요. AMD MI300 같은 AI accelerator는 compute chiplet과 memory chiplet을 고속 die-to-die interconnect로 묶어요.

장점은 제조 수율과 모듈성에서 나와요. 작은 die는 큰 monolithic die보다 만들기 쉽고, 서로 다른 공정의 chiplet을 조합할 수도 있어요.

하지만 inter-chiplet latency, memory coherence, thermal management가 중요해져요. 특히 AI accelerator는 수많은 PE가 같은 데이터의 일관된 관점을 가져야 하므로 coherence를 일반 CPU 방식으로 유지하는 것이 부담스러울 수 있어요. 그래서 많은 ML hardware는 explicit memory management와 synchronization을 선호해요.

9.3 Multi-GPU Systems and Amdahl’s Law

Multi-GPU 시스템은 각 GPU가 자기 메모리와 계산 자원을 갖고, NVLink, NVSwitch, PCIe 같은 interconnect로 연결돼요. 데이터 병렬화에서는 각 GPU가 다른 batch를 처리하고, 모델 병렬화에서는 모델의 다른 부분을 GPU마다 나눠요.

문제는 gradient synchronization이에요. 큰 Transformer 모델에서는 매 학습 step마다 매우 큰 gradient를 교환해야 해요. 원문은 GPT-3 규모의 175B parameter 모델을 예로 들며 FP32 gradient가 700GB 규모가 될 수 있다고 설명해요.

병렬화 한계는 Amdahl’s Law로 볼 수 있어요.

[ \text{Speedup} = \frac{1}{(1-P) + \frac{P}{N}} ]

AI 학습에서는 communication overhead (C)가 추가돼요.

[ \text{Speedup}_{\text{AI}} = \frac{1}{(1-P) + \frac{P}{N} + \frac{C}{N}} ]

(P)는 병렬화 가능한 작업 비율, (N)은 processor 수, (C)는 통신 overhead예요. 칩을 더 붙여도 (C)와 동기화 비용이 커지면 speedup은 선형으로 증가하지 않아요.

원문은 통신 병목을 줄이는 방법으로 gradient compression, pipeline parallelism, model parallelism, asynchronous update를 제시해요. 이들은 통신량을 줄이거나, 통신을 계산과 겹치거나, 동기화 요구를 완화하는 방식이에요.

9.4 TPU Pods

TPU Pod는 많은 TPU를 데이터센터 규모로 연결해 하나의 큰 시스템처럼 쓰는 구조예요. 2D torus interconnect와 optical link를 사용해 여러 accelerator 사이의 통신을 지원해요.

원문은 ResNet-50 같은 workload에서 TPU Pod가 큰 규모에서도 강한 scaling을 보인다고 설명해요. 하지만 Transformer처럼 AllReduce와 대규모 gradient synchronization이 필요한 모델에서는 torus network의 hop 수, interconnect congestion, distributed memory coordination이 병목이 돼요.

또한 각 TPU node가 독립적인 memory space를 가지므로 data marshaling과 synchronization protocol이 필요해요. optical interconnect를 통한 데이터 이동은 on-chip communication보다 훨씬 비싼 에너지를 소비할 수 있어요.

9.5 Wafer-Scale AI

Wafer-scale AI는 여러 칩을 자르고 연결하는 대신, 실리콘 wafer 전체를 하나의 거대한 processor처럼 사용하는 방식이에요. Cerebras WSE 계열이 대표 사례예요.

장점은 inter-chip boundary를 없애 통신 지연을 크게 줄인다는 점이에요. 한 wafer 안에서 compute fabric을 구성하면 기존 multi-chip 시스템의 통신 병목 일부를 피할 수 있어요.

하지만 대가도 커요.

9.6 Multi-Chip에서 바뀌는 최적화

단일 칩에서는 locality가 핵심이에요. 가까운 memory와 PE를 잘 쓰면 돼요. multi-chip에서는 locality가 시스템 전체 문제로 확장돼요.

Compiler와 runtime도 multi-chip에 맞게 확장돼요. compiler는 interconnect-aware placement를 수행하고, runtime은 network congestion, load imbalance, synchronization delay를 보며 실행 계획을 조정해요.

10. Heterogeneous SoC AI Acceleration

10.1 모바일과 엣지는 조건이 다르다

데이터센터 accelerator는 수백 와트에서 킬로와트급 전력과 큰 냉각 인프라를 사용할 수 있어요. 하지만 스마트폰은 2~5W 수준의 전력 예산에서 동작해야 하고, 자동차는 안전을 위해 deterministic latency가 필요하며, IoT 센서는 배터리로 오래 살아야 해요.

그래서 edge와 mobile AI에서는 heterogeneous SoC가 중요해져요. 하나의 칩 안에 CPU, GPU, DSP, NPU가 함께 있고, workload에 따라 적절한 processor를 골라 실행해요.

10.2 Mobile SoC Architecture Evolution

Qualcomm Snapdragon AI Engine은 Kryo CPU, Adreno GPU, Hexagon DSP, NPU를 조합해 workload를 분배해요. 컴퓨터 비전은 GPU shader에, 오디오는 DSP에, Transformer attention은 NPU matrix engine에 보내는 식이에요.

Apple M2 같은 구조는 unified memory와 Neural Engine, GPU, CPU의 긴밀한 통합을 통해 data copy overhead를 줄여요. Neural Engine은 transformer layer, GPU는 convolution, CPU는 control flow와 dynamic layer selection을 맡을 수 있어요.

ARM의 IP licensing 모델은 SoC 설계자가 목표 제품에 맞게 Mali GPU, Ethos NPU, Cortex microcontroller를 조합할 수 있게 해요. 자동차는 deterministic real-time을, 스마트폰은 interactive performance와 battery efficiency를 더 중시할 수 있어요.

10.3 Dynamic Workload Distribution

SoC 안에는 여러 processor가 있으므로 어느 연산을 어디서 실행할지 계속 판단해야 해요.

공유 LPDDR memory를 여러 processor가 함께 쓰면 memory controller arbitration도 중요해요. 실시간 카메라 처리는 background AI보다 높은 우선순위를 받을 수 있어요.

10.4 Power and Thermal Management

모바일 SoC는 DVFS를 사용해 전압과 주파수를 조절해요. 한 processor가 latency 요구를 맞추기 위해 frequency를 올리면, 다른 processor의 전압을 낮춰 전체 power budget을 맞출 수 있어요.

Thermal throttling도 단순히 전체 속도를 낮추는 방식만 있는 것이 아니에요. NPU가 열 한계에 가까워지면 runtime이 일부 layer를 GPU나 CPU로 옮길 수 있어요. 배터리가 낮을 때는 고정확도 모델 대신 더 가벼운 모델을 사용하거나, inference 빈도를 줄일 수 있어요.

10.5 Automotive Heterogeneous AI Systems

자동차 AI는 모바일처럼 전력 효율이 중요하면서도 safety-critical latency가 필요해요. ADAS에서는 perception, planning, control이 정해진 시간 안에 끝나야 하고, safety-critical 기능과 convenience 기능을 시간적으로 격리해야 해요.

차량은 camera, radar, central compute, V2X communication이 함께 동작해요. 여러 sensor modality의 시간 정합성을 microsecond 수준으로 맞추어야 할 수 있고, 5G modem, AI accelerator, control system 사이에 millisecond deadline이 걸릴 수 있어요.

10.6 Software Stack Challenges

이기종 SoC를 잘 쓰려면 software stack이 복잡해져요. OpenCL과 Vulkan은 여러 processor에 걸친 실행을 추상화하지만, 최적 성능을 내려면 processor-specific optimization이 필요해요. TensorFlow Lite와 PyTorch Mobile은 automatic processor selection을 제공하지만, 개발자는 여전히 memory coherency, cache behavior, DMA synchronization을 이해해야 해요.

고급 SoC는 runtime telemetry를 모아 workload 특성, processor utilization, power consumption을 학습하고, 다음 workload에 더 나은 processor 선택과 thermal management를 적용할 수 있어요.

11. Fallacies and Pitfalls

원문은 하드웨어 가속을 둘러싼 오해를 명확히 짚어요.

효과적인 하드웨어 선택은 “가장 강한 칩”을 고르는 일이 아니에요. workload의 연산 패턴, 메모리 접근, batch size, latency requirement, precision requirement, 배포 환경, 비용 구조를 맞추는 일이에요.

12. 3단계 최종 정리

이 장은 AI acceleration을 여러 층의 시스템 문제로 보여줘요.

결국 AI 하드웨어 가속의 중심 질문은 하나예요.

“이 모델의 가장 중요한 데이터와 계산을, 가장 가까운 곳에서, 가장 적게 움직이며, 가장 많은 처리 요소가 동시에 일하도록 만들 수 있는가?”

복습 질문

1. AI 워크로드가 범용 CPU와 잘 맞지 않는 이유를 병렬성, 메모리 접근, 데이터 크기 관점에서 설명해보세요.

2. GPU, TPU, NPU는 각각 어떤 종류의 AI 작업에 강한지 비교해보세요.

3. AI memory wall이란 무엇이며, 왜 peak FLOPS만으로 accelerator 성능을 판단하면 안 될까요?

4. (T_{\text{mem}})과 (T_{\text{compute}})를 비교했을 때 어떤 경우에 memory-bound라고 말할 수 있나요?

5. Vector operation, matrix operation, special function unit은 신경망의 어떤 부분을 각각 가속하나요?

6. Systolic array가 데이터 이동을 줄이는 원리를 operand reuse 관점에서 설명해보세요.

7. FP32, FP16, BF16, INT8은 각각 어떤 장단점을 갖고 있나요? 학습과 추론에서 선택 기준이 어떻게 달라질까요?

8. Weight stationary, input stationary, output stationary 전략은 각각 어떤 데이터를 local memory에 오래 두나요?

9. Tensor layout에서 NHWC와 NCHW가 성능에 영향을 주는 이유를 memory coalescing과 cache locality 관점에서 설명해보세요.

10. Kernel fusion이 memory traffic을 줄이는 이유와, 과도한 fusion이 오히려 손해가 될 수 있는 이유를 함께 설명해보세요.

11. ML compiler의 graph optimization, kernel selection, memory planning, computation scheduling은 각각 어떤 문제를 해결하나요?

12. Runtime이 compiler만으로 해결되지 않는 문제를 어떻게 보완하나요? batch size나 sequence length가 달라지는 예로 설명해보세요.

13. Multi-GPU 학습에서 accelerator 수를 늘려도 성능이 선형으로 증가하지 않는 이유를 communication overhead와 synchronization 관점에서 설명해보세요.

14. Chiplet, multi-GPU, TPU Pod, wafer-scale AI는 각각 어떤 확장 전략이며, 어떤 새로운 병목을 만들까요?

15. 모바일 heterogeneous SoC에서 CPU, GPU, DSP, NPU에 작업을 나눌 때 power, thermal, latency constraint를 어떻게 고려해야 할까요?

16. “특수 하드웨어는 항상 범용 프로세서보다 빠르다”라는 말이 왜 틀릴 수 있는지 예시를 들어 설명해보세요.