AI Accelerator Architecture
“칩을 이해하는 것은 네 질문으로 환원된다: 데이터가 어디에 사는가, 컴퓨트로 어떻게 이동하는가, 컴퓨트 유닛이 어떻게 생겼는가, 칩들이 스케일에서 어떻게 대화하는가.”
핵심 개념
데이터 엔지니어가 AI 칩 아키텍처를 알아야 할 이유는 워크로드의 모양이 하드웨어 선택을 결정하고, 하드웨어가 다시 파이프라인 설계와 비용 구조를 결정하기 때문이다. 배치 학습 파이프라인의 병목과 실시간 추론 서빙의 병목은 물리적으로 다른 곳에 있다.
공통 적은 하나다 — memory wall: 컴퓨트는 지수적으로 확장했지만 메모리 대역폭은 그러지 못했다. 여섯 개의 성공한 아키텍처는 전부 “matmul이 일어나는 곳으로 숫자를 충분히 빠르게 옮기는 문제” 에 대한 서로 다른 답이다.
배경 — 왜 domain-specific architecture인가
| 시점 | 단일 스레드 CPU 성능 성장률 |
|---|---|
| 1980년대 | 연 52% |
| 2018년 (Moore’s Law + Dennard Scaling 종언) | 연 3% |
Hennessy·Patterson의 2018 튜링 강연 “A New Golden Age for Computer Architecture” 가 든 예시가 TPU v1 — 신경망 추론에서 CPU의 29배 처리량, 80배 나은 에너지 효율. 예언은 “다음 10년은 새로운 컴퓨터 아키텍처의 캄브리아기 대폭발” 이었고, 실현되었다.
수십 가지가 개발되었지만 실제 배포를 얻은 것은 여섯 개 — NVIDIA GPU, AMD Instinct, Google TPU, AWS Trainium, Cerebras WSE, Groq LPU.
워크로드 shape이 전부를 결정한다
트랜스포머는 matmul의 연속(Q/K/V projection → attention → output projection → FFN)에 element-wise 연산이 끼어든 것이다. 문제는 그 matmul의 모양이 페이즈마다 다르다는 것이다.
| 페이즈 | 연산 모양 | Arithmetic Intensity | 병목 |
|---|---|---|---|
| Training | GEMM (행렬-행렬) | 높음 | compute-bound |
| Prefill (프롬프트 인제스션) | GEMM | 높음 | compute-bound |
| Decode (autoregressive 생성) | GEMV (행렬-벡터) | 자릿수 낮음 | memory-bandwidth-bound |
Decode가 근본적으로 어려운 이유: 토큰을 하나 만들려면 모델의 모든 가중치를 완전히 훑고 KV Cache를 완전히 읽어야 하는데, 그렇게 읽은 데이터로 하는 산술 연산은 토큰 하나 분량뿐이다. 그리고 토큰 N이 나오기 전에 N+1을 시작할 수 없다.
intensity 회복 기법 — GEMV를 GEMM으로 승격시키기:
- continuous batching — 여러 사용자의 decode 스텝을 쌓는다
- speculative decoding — 요청당 K개 draft 토큰을 쌓아 한 패스로 검증
- multi-token prediction — 같은 트릭을 모델 안으로
⚠️ 함정: continuous batching에서도 각 사용자 요청은 자기 KV Cache를 읽는다. 그래서 긴 컨텍스트 decode는 weight-bandwidth-bound에서 KV-bandwidth-bound로 옮겨갈 뿐 병목이 사라지지 않는다.
여섯 가지 전략
| 아키텍처 | 데이터가 사는 곳 | 스케줄링 주체 | 핵심 베팅 |
|---|---|---|---|
| NVIDIA GPU | HBM + 캐시 계층 | 하드웨어(warp 스케줄러) + CUDA 커널 | 프로그래머빌리티. 프로그래밍 모델을 바꾸지 않고 SM에 프리미티브를 계속 더한다. 같은 칩이 학습·추론·렌더링 |
| Google TPU | HBM → VMEM (소프트웨어 관리) | 컴파일러(XLA)가 전부 — 하드웨어 스케줄러·캐시·warp 없음 | 단일 프리미티브 집중. 큰 systolic array 위 dense matmul만. 그래픽 야심 없음 |
| AMD Instinct | HBM (용량 우위) | 하드웨어 + ROCm/HIP | CU는 보수적으로 유지하고 패키지에 재투자. HBM 용량, 3D 스택, coherent APU, 오픈 생태계 |
| Cerebras WSE | on-wafer SRAM 전부 (HBM 없음) | 컴파일러 + dataflow | memory wall은 웨이퍼를 자른 결과다. 톱질을 건너뛴다 |
| AWS Trainium | HBM (TPU 플레이북) | XLA 공유 | fast-follower + 경제성. NVIDIA를 AWS 안에서만 이기면 된다 |
| Groq LPU | SRAM 전부, 네트워크도 스케줄됨 | 컴파일러가 사이클 단위로 전부 | 결정론. 실행 전에 레이턴시를 안다 |
NVIDIA — 프로그래머블 대규모 병렬
수천 스레드를 호스트 CPU가 조율하고 CUDA로 노출. 매 세대 프로그래밍 모델을 유지하면서 가속 프리미티브를 추가하는 것이 30년 생태계 축적의 비결이자 moat다.
TPU — 컴파일러가 곧 시스템
하드웨어 fallback이 없다. warp 스케줄러도, 캐시도, 나쁜 스케줄을 덮어줄 out-of-order 엔진도 없다. XLA가 어떤 연산을 fuse할지, 각 텐서가 어디 살지, 322-bit VLIW 번들을 어떻게 스케줄할지, 수천 칩에 어떻게 샤딩할지 전부 결정한다.
- 컴파일 경로: JAX → JAXpr → StableHLO → HLO → LLO → VLIW
- 핵심 패스: operation fusion(중간 결과가 HBM에 닿지 않게), layout assignment(transpose 없이 MXU로 스트림 — 1D SIMD보다 훨씬 어렵다)
- 다중 칩은 SPMD —
Mesh+PartitionSpec으로 선언하면 컴파일러가 collective를 삽입. 틀리면shard_map으로 manual SPMD - 탈출구는 Pallas (GPU의 Triton에 해당) — XLA가 새 attention 변형, fused MoE dispatch처럼 이득이 대수학이 아니라 스케줄에 있는 FlashAttention급 최적화를 항상 합성할 수는 없기 때문
생태계 성격의 차이: CUDA가 sprawling하다면 TPU 스택은 centralised다. 프레임워크 아래 거의 전부(XLA, JAX, Flax, Pallas, MaxText, Pathways, Shardy, Mosaic)를 Google이 직접 오픈소스로 내고 실리콘과 lockstep으로 진화시킨다. 워크로드가 이상하게 생긴 곳에서는 moat가 얇고, Gemini처럼 생긴 곳에서는 깊다.
Cerebras — 톱질하지 않기
fab이 300mm 실리콘에 수십 개 die를 찍고 톱질해 나누면, 산업은 가장 exotic한 엔지니어링(HBM, NVLink, CoWoS, 랙당 5,184개 구리 케이블)을 on-die 대역폭의 극히 일부로 조각들을 다시 잇는 데 쓴다.
84 reticle field, 46,225 mm², 900,000 dataflow core, 모든 메모리가 컴퓨트에서 1 사이클 거리.
표의 축 자체를 깬다: HBM이 없고 44 GB SRAM에 집계 21 PB/s. dense FLOP당 약 1.3 바이트 — GPU 행들이 0.002 근처인 것과 3자릿수 차이다. 대가도 같은 행에 있다: H200 한 장보다 적은 총 메모리, 와트당 dense FLOPs가 동시대 모든 GPU에 뒤짐, coherent 도메인이 웨이퍼 자체이므로 scale-up 칸이 비어 있다.
Groq — 비결정성 제거
다른 모든 칩은 불확실성을 견디는 데 실리콘을 쓴다 — 캐시, 스케줄러, arbiter.
LPU는 캐시·분기 예측기·arbiter·reorder buffer·on-chip crossbar까지 전부 삭제하고 전체 스케줄링을 컴파일러에 넘긴다. TPU가 스케줄링을 컴파일러로 옮기되 HBM과 동적 네트워크를 유지했다면, Groq는 마지막 비결정성 원천까지 제거했다 — 메모리는 전부 SRAM, 네트워크도 스케줄되어 수백 칩이 하나의 clock-exact 프로그램으로 돈다.
용량을 SRAM 대역폭과 교환한다: 첫 GroqRack은 64칩에 걸쳐 14 GB만. Groq 3 LPX는 256칩에 128 GB / 40 PB/s. 12 TB DDR5 tier와 Rubin과의 페어링은 LPU가 대용량 GPU 랙을 대체하는 게 아니라 보완함을 보여준다.
스펙 읽는 법 — 비교 불가능한 것들
⚠️ 벤더 표를 그대로 비교하면 안 되는 이유:
- 메모리 대역폭: GPU/TPU/Trainium은 HBM, Cerebras/Groq는 on-chip SRAM 집계. 직접 비교 불가
- scale-up 대역폭: 벤더마다 칩당 집계 / 랙 집계 / 진짜 bisection 중 다른 것을 쓴다
- FLOPs: peak, 명시된 정밀도, 근거를 공개하지 않으면 dense 기준
2023–2026 트렌드
- 칩당 FP8은 수렴했다 — B200(4.5 PF), Ironwood(4.6 PF), MI355X(10 PF)가 서로 약 2배 이내. 칩 단위 군비 경쟁은 박빙이고, 아키텍처가 갈라지는 곳은 랙과 pod이다
- HBM 용량은 AMD의 지속적 승리 — 192 → 256 → 288 GB로 매 세대 동등 이상. NVIDIA는 B300(2025 말)에서야 288GB, Rubin Ultra가 2026년 패키지당 1TB로 탈환
- 랙 스케일 scale-up은 2026년까지 NVIDIA — GB200/GB300 NVL72가 2024~2025의 유일한 coherent 랙 스케일 도메인. TPU는 질문 자체를 회피한다 — 그 torus가 랙이자 클러스터다
- pod 규모는 TPU — Ironwood pod 9,216칩 / 42.5 ExaFLOPS FP8 vs NVL576 576 GPU / ~5 ExaFLOPS. 칩당 정액 × 거대 pod 레시피가 시스템당 총 컴퓨트를 더 내되 칩당 대역폭을 대가로 한다
- 전력이 데이터센터 설계를 강제한다 — 700 W(Hopper) → 1,000 W(Blackwell) → 1,400 W(B300, MI355X) → ~1,800 W(Rubin Ultra). 약 1,000 W 위에서 액체 냉각이 필수이고, 공랭은 사실상 Hopper로 끝난다
- scale-out NIC이 NVIDIA 세대마다 두 배 — 400 Gbps(CX-7) → 800(CX-8) → 1.6 Tbps(CX-9, Rubin). AMD는 한 세대 뒤(Pollara 400 → Vulcano 800)
- Trainium은 스펙이 아니라 경제성 — 칩당으로는 뒤지지만(Trn2 1.3 PF FP8 ≈ MI355X의 1/4) AWS가 Nitro 카드부터 API까지 모든 레이어를 소유하고 앵커 테넌트 하나(Anthropic, 100만+ Trainium2)가 frontier 규모에서 검증한다
데이터 엔지니어에게 주는 함의
- 학습 파이프라인의 병목은 대개 칩이 아니라 그 앞의 스토리지·전처리다 → AI Training Storage
- 추론 비용 구조는 decode의 메모리 대역폭에 지배된다 — 배칭 전략(continuous batching, speculative decoding)이 프롬프트 최적화보다 큰 레버일 때가 많다 → Tokenization Economics
- 하드웨어 다양화는 이식성 비용을 만든다 — CUDA 락인 vs XLA 계열(TPU/Trainium이 컴파일러를 공유). Pallas:Mosaic-GPU처럼 한 번 쓰고 여러 substrate로 lowering하는 시도가 나오는 이유
- 전력·냉각이 배포 지역과 계약을 제약한다 — 1,000 W 이상은 액체 냉각 전제
연관 개념
- AI Training Storage — 가속기를 굶기지 않는 데이터 공급
- Tokenization Economics — 토큰 비용이 결국 하드웨어 효율의 함수
- LLM Platform Engineering — 서빙 스택과 배칭 전략
- Columnar Execution Engine — 컴파일러 주도 실행이라는 같은 발상의 데이터 엔진 버전
- Data Engineering FinOps
- Distributed Systems Reliability
Source: AI Chip Architectures