같은 문제를 푸는 네 가지 방식(NVIDIA, AMD, Google TPU, Cerebras)
1. 왜 갈라졌나
이 이야기는 두 가지 법칙이 깨진 데서 시작한다.
무어의 법칙(1965, Gordon Moore)은 칩 하나에 들어가는 트랜지스터 수가 약 2 년마다 두 배가 된다 는 것이다. 물리 법칙이 아니라 경험적·경제적 관찰이고, 중요한 건 이게 개수에 대한 이야기이지 속도에 대한 이야기가 아니라는 점이다. 트랜지스터가 많아진다고 저절로 빨라지지는 않는다.
속도를 담당한 건 다른 법칙이었다. 데나드 스케일링(1974, Robert Dennard)은 트랜지스터를 작게 만들면 단위 면적당 전력 소모가 그대로 유지된다 는 것이다. 치수를 k 배 줄이면 이렇게 된다.
| 항목 | 변화 | 결과 |
|---|---|---|
| 면적 | 1/k² | 트랜지스터가 k² 배 더 들어간다 |
| 전압 | 1/k | |
| 전류 | 1/k | |
| 정전용량 | 1/k | |
| 지연시간 | 1/k | 클럭을 k 배 올릴 수 있다 |
| 트랜지스터당 전력 (C·V²·f) | 1/k² | |
| 면적당 전력 | 그대로 | ★ 더 많이, 더 빠르게, 전력은 그대로 |
마지막 줄이 핵심이다. 두 법칙이 합쳐지면 이렇게 된다.
| 주는 것 | |
|---|---|
| 무어의 법칙 | 트랜지스터를 더 많이 |
| 데나드 스케일링 | 그 트랜지스터가 더 빠르고, 전력은 안 늘어남 |
그래서 1980~2000 년대 초에는 코드를 한 줄도 안 고쳐도 2 년마다 프로그램이 두 배 빨라졌다. 아키텍트가 할 일은 공정이 주는 것을 받아 쓰는 일이었다.
데나드가 먼저 무너졌다 (2005 년 전후)
전압을 계속 낮추려면 문턱 전압도 같이 낮춰야 하는데, 그러면 누설 전류가 폭증한다. 그래서 전압 강하가 멈췄고, 위 공식에서 V² 가 더는 안 줄어드니 면적당 전력이 세대마다 올라가기 시작했다 — 전력 벽이다.
결과가 클럭 정체다. Pentium 4 가 2004 년에 이미 3.8 GHz 였는데 20 년 뒤 주류 CPU 도 5~6 GHz 언저리다. 그 전엔 2 년마다 두 배였던 것이 20 년에 1.5 배가 됐다.
업계의 대응은 멀티코어였다. 코어 하나를 더 빠르게 못 만드니 개수를 늘린 것이다. 하지만 그것도 암달의 법칙에 막힌다. 무어의 법칙은 더 늦게 둔화됐다 — 트랜지스터는 여전히 작아지지만 트랜지스터당 비용이 더는 안 떨어지고 주기가 2 년보다 길어졌다.
단일 스레드 성능 증가율로 보면 가장 선명하다.
Single-thread performance growth, per year
(Hennessy & Patterson, approx.)
1986-2003 52% ################################################
2003-2011 23% #####################
2011-2015 12% ###########
2015-2018 3.5% ###데나드 붕괴 이후 멀티코어로 한동안 버텼지만, 그것도 한계에 닿은 모습이 그대로 보인다.
그래서 특화로 간다
공정에서 공짜 속도를 못 얻고 범용 멀티코어도 막히면 남는 레버는 하나뿐이다 — 하나의 워크로드만 아주 잘하는 칩을 설계하는 것(도메인 특화 아키텍처). Hennessy 와 Patterson 이 2018 년에 "아키텍처의 캄브리아 대폭발"을 예고한 게 정확히 이 지점이다.
그리고 AI 는 그 대상으로 이상적이었다. 연산이 행렬곱 하나로 지배되고, 경제적 가치가 막대한 워크로드이기 때문이다.
그런데 그 행렬곱이 두 가지 모양이다
성능을 더 얻는 길이 "트랜지스터를 더 작게"에서 "이 워크로드만을 위한 칩을 설계" 로 옮겨간 뒤, 설계자들이 마주한 문제는 이것이었다 — 같은 행렬곱인데 두 가지 다른 모양으로 나타난다.
Training / Prefill Decode
------------------ ------
[ A ] x [ B ] = [ C ] [ A ] x [v] = [v]
M x K K x N M x N M x K K x 1 M x 1
GEMM (matrix x matrix) GEMV (matrix x vector)
산술 강도(arithmetic intensity) 높음 산술 강도 낮음
-> 연산에 묶인다 (compute-bound) -> 대역폭에 묶인다 (bandwidth-bound)
-> FLOPs 를 원한다 -> HBM 대역폭을 원한다가중치 한 번 읽어서 연산을 많이 하면(GEMM) 연산기가 병목이고, 가중치 한 번 읽어서 벡터 하나만 곱하면(GEMV) 메모리가 병목이다. 같은 모델, 같은 가중치인데 단계에 따라 병목이 반대편에 있다.
여기에 메모리 벽이 겹친다. 연산 성능은 지수적으로 올랐는데 메모리 대역폭은 그만큼 못 따라왔다. 그래서 모든 설계 결정이 결국 하나의 질문으로 수렴한다 — 데이터를 어디에 두고, 어떻게 움직일 것인가.
네 회사가 이 질문에 서로 다르게 답했다.
2. NVIDIA GPU — 프로그래밍 가능성에 건다
철학
수천 개의 스레드를 띄워 놓고, 하나가 메모리를 기다리는 동안 다른 것을 실행해 지연을 숨긴다. 고정 기능 회로 대신 CUDA 로 프로그래밍 가능하게 두고, 그 대가(SIMT 세금)를 지불한다.
구조
+---------------------------------------------------------------+
| Streaming Multiprocessor (100+ per package) |
| |
| +----------------+ +----------------+ |
| | Warp Scheduler | | Warp Scheduler | ... x4 |
| +-------+--------+ +-------+--------+ |
| | | |
| +-------v--------+ +-------v--------+ |
| | CUDA Cores | | Tensor Core | |
| | (element-wise)| | (matmul) | |
| +----------------+ +----------------+ |
| |
| Registers -> L1 / SMEM -> TMEM (Blackwell+) |
+---------------------------------------------------------------+
|
L2 cache
|
HBMSM 하나에 최대 64 개의 워프가 상주한다. 하나가 막히면 다른 워프로 갈아타는 식으로 지연을 덮는다.
세대별 변화
| 세대 | 연도 | 핵심 |
|---|---|---|
| Volta | 2017 | 최초의 Tensor Core |
| Hopper | 2022 | 비동기 wgmma, Transformer Engine, thread-block cluster |
| Blackwell | 2024 | 2-SM MMA (256×256×16), 네이티브 FP4, Tensor Memory(TMEM) |
| Rubin | 2026+ | HBM4, prefill 분리, 패키지당 1 TB HBM4e / 600 kW 랙 |
다섯 가지 베팅
- 고정 기능이 아니라 CUDA 로 프로그래밍 가능하게
- 대규모 멀티스레딩으로 지연을 숨긴다 (SM 당 64 워프 상주)
- 행렬곱을 워프 단위로 감싼다 (
mma.sync→wgmma→tcgen05.mma) - 메모리 계층을 비동기로 (TMA, TMEM,
mbarrier) - SIMT 세금을 상각한다 — Tensor Core 를 워프 기계장치가 값어치 있을 만큼 크게 만든다
확장
- 스케일업: NVLink + NVSwitch. 캐시 일관성이 있고 수동 구리 케이블을 쓴다. NVL72 기준 all-to-all 약 130 TB/s (케이블 5,184 가닥)
- 스케일아웃: ConnectX NIC + InfiniBand. Blackwell 은 GPU 당 800 Gbps, Rubin 은 1.6 Tbps
소프트웨어
PTX/SASS 인트린식부터 cuBLAS·cuDNN·CUTLASS·TensorRT-LLM, 그 위에 PyTorch·JAX 까지. FlashAttention 은 세대마다 손으로 최적화한다. NVIDIA 는 고객 연구소 안에 엔지니어를 상주시킨다 — 이게 생태계 해자의 실체다.
3. Google TPU — 컴파일러가 전부를 안다
철학
하드웨어 스케줄러가 없다. 캐시가 없다. 스레드도 워프도 없다. XLA 컴파일러가 모든 사이클과 모든 바이트를 미리 계획한다. 학습 워크로드는 정적으로 예측 가능하다는 데 건 것이다.
구조 — 시스톨릭 배열
activations 가 흘러 들어온다 ->
a3 a2 a1
| | |
+----v-----v-----v----+
w -> | w | w | w | | 가중치는 셀에 머문다
w -> | w | w | w | | (weight-stationary)
w -> | w | w | w | |
+--+-----+-----+------+ 256 x 256 = 65,536 MAC
| | | per cycle (Ironwood)
v v v
부분합이 아래로 누적된다가중치를 배열에 고정해 두고 활성값만 흘려보낸다. 명령어 캐시도, 분기 예측기도, 비순차 실행 엔진도 없다.
주변 장치는 이렇게 붙는다:
| 유닛 | 역할 |
|---|---|
| MXU | 시스톨릭 배열, 밀집 행렬곱 |
| VPU | 2D 벡터 element-wise 연산 |
| Scalar Unit | 단일 스레드 스칼라 |
| XLU | 레인 교차 리덕션 |
| SparseCore (v4+) | 임베딩 워크로드 전용 |
| CAE (v8i) | decode 단계 collective 리덕션 |
메모리는 소프트웨어가 관리하는 스크래치패드뿐이다(VMEM/CMEM/SMEM). 322 비트 VLIW 번들에 사이클당 8 개의 기능 슬롯을 컴파일러가 채운다.
세대별 변화
| 세대 | 연도 | 핵심 |
|---|---|---|
| v1 | 2015 | INT8 추론 전용 |
| v2 | 2017 | BF16 학습, 듀얼 MXU + HBM |
| v4 | 2020 | 광 회선 교환(Palomar), SparseCore |
| v5 | 2023 | v4 대비 INT8 3.3 배, v5p 는 8,960 칩 팟 |
| Ironwood(v7) | 2024 | 256×256 MXU, 9,216 칩 슈퍼팟, 42.5 ExaFLOPS FP8 |
| v8 | 2026 | 네이티브 FP4, 121 ExaFLOPS FP4 (9,600 칩) |
다섯 가지 베팅
- 밀집 행렬곱은 시스톨릭 배열로
- 캐시 대신 소프트웨어 스크래치패드 — 연산은 싸고 메모리는 비싸다
- 컴파일러가 스케줄링 — VLIW, 추측 실행 없음, 동적 디스패치 없음
- MAC 만 남기고 다 지운다 — 태그·예측기·리오더 버퍼 전부 삭제
- 모양이 안 맞는 워크로드는 전용 엔진으로 (SparseCore, CAE)
확장
스케일업 스케일아웃
-------- ----------
3D torus (칩 직결) Virgo : TPU 간 east-west
+ Palomar 광 회선 교환 Jupiter: north-south / 스토리지
144 큐브를 가로질러 재구성 Multislice 가 팟을 넘어 확장
밀리초급으로 토폴로지 변경 Pathways 가 멀티리전 잡을 조율
캐시 일관성 없음 (메시지 패싱) 47 Pb/s bisection (134,000+ TPU)소프트웨어
JAX → StableHLO → HLO → LLO → VLIW. XLA 가 연산 융합, 레이아웃 배정, 버퍼 배정, SPMD 분할을 전부 한다. 커널을 직접 쓰고 싶으면 Pallas(TPU 판 Triton)가 탈출구다. 생태계가 구글 자체 제작으로 중앙집중적이다 — Flax NNX, Optax, MaxText, vLLM, Pathways. PyTorch 경로(torch_xla)는 2등 시민이지만 2025 년부터 JAX→XLA 로 낮추는 경로가 통일되며 나아지고 있다.
4. AMD — 코어는 보수적으로, 포장은 공격적으로
철학
Compute Unit 의 모양을 2012 년 GCN 이후 거의 그대로 유지한다. 대신 3D 적층, CPU·GPU 일관성, 개방 표준에 투자한다. 수직 통합이 아니라 파트너십으로 경쟁한다.
구조
+------------------------------------------+
| Compute Unit |
| |
| SIMD16 SIMD16 SIMD16 SIMD16 | <- 벡터 엔진 4 개
| \ \ / / |
| +--------+-----+--------+ |
| | |
| +------v-------+ |
| | Matrix Core | (MFMA) | <- wave64 하나가 발행,
| +--------------+ | 4 SIMD 가 4 사이클 협력
| |
| Scalar Unit LDS 64 kB |
+------------------------------------------+
|
L1 vector cache
|
Infinity Cache (MI300X+ 에서 256 MB)
|
HBM트레이드오프가 분명하다. 웨이브 단위 집합 연산인 MFMA 는 NVIDIA 의 비동기 Tensor Core 와 달리 VPU 와 겹쳐 돌릴 수 없다. 그래서 소프트웨어 파이프라인 커널에서 행렬곱과 softmax/마스킹을 깔끔하게 겹치지 못한다. 대신 Infinity Cache 와 HBM 용량으로 벌충한다.
세대별 변화
| 세대 | 연도 | 핵심 |
|---|---|---|
| CDNA | 2020 | 최초 MFMA 행렬 코어, 그래픽 실리콘 제거, 네이티브 BF16 |
| CDNA 2 | 2021 | 듀얼 다이 MCM, 풀레이트 FP64 |
| CDNA 3 | 2023 | TSMC SoIC 최초 3D 적층 칩렛, FP8, Infinity Cache 256 MB, MI300A APU |
| CDNA 4 | 2025 | 네이티브 FP4/FP6 (OCP MX), CU 당 FP64 절반으로 — AI 우선 전환 |
| CDNA Next | 2026 | HBM4, Helios 랙 (UALink 로 72 GPU 스케일업) |
다섯 가지 베팅
- Compute Unit 모양은 유지하고, 패키징에 투자한다
- HBM 용량 우선 — 2021 년 이후 매 세대 NVIDIA 와 같거나 더 많이
- 3D 적층을 일찍 (2023 년 SoIC 하이브리드 본딩)
- CPU·GPU 일관 APU (MI300A: Zen 4 CCD + CDNA 3 XCD + HBM3)
- 개방 표준 — UALink, UET, OCP MX
확장
- 스케일업: Infinity Fabric 8-GPU OAM 박스(완전 연결, MI350X 기준 GPU 당 1,075 GB/s) → Helios 랙(72 GPU, 출시 시 UALoE 로 260 TB/s, 2027 년부터 네이티브 UALink)
- 스케일아웃: Ultra Ethernet(UET RDMA) + Pensando Vulcano 800 NIC + Broadcom Tomahawk 6
소프트웨어 — 격차를 솔직히
ROCm 스택(HIP, rocBLAS, MIOpen, RCCL, Composable Kernel). XLA 에 해당하는 것이 없다. PyTorch 는 Triton ROCm 백엔드 + torch.compile 로 1급 지원. FlashAttention 은 Composable Kernel 로 FA2 가 프로덕션, FA3/FA4 는 NVIDIA 를 몇 달 뒤따른다.
동일 워크로드에서 CUDA 대비 10–25% 느리고, FlashAttention-4 꼬리는 여전히 NVIDIA 의 해자 영역이다.
5. Cerebras WSE — 웨이퍼를 자르지 않는다
철학
메모리 벽은 물리 법칙이 아니라 설계 선택이다. HBM 을 아예 버리고 SRAM 만 쓴다. 웨이퍼를 칩으로 자르지 않고 46,225 mm² 한 덩어리로 쓴다.
구조
+=====================================================+
| One wafer : 46,225 mm2 , 84 reticles stitched |
| |
| [c][c][c][c][c][c][c][c][c][c][c][c][c][c][c] |
| [c][c][c][c][c][c][c][c][c][c][c][c][c][c][c] |
| [c][c][c][c][c][c][c][c][c][c][c][c][c][c][c] |
| [c][c][c][c][c][c][c][c][c][c][c][c][c][c][c] |
| ... 900,000 cores in 2D mesh ... |
| |
| per core: ~38k um2 , SRAM 48 kB , FP16 SIMD |
| no shared cache / no global mem / no matrix unit |
+=====================================================+
총 SRAM 44 GB · 온칩 집계 21 PB/s
|
12 x 100 GbE = 1.2 Tb/s <- 절벽코어는 데이터가 오기 전까지 놀고 있다. wavelet 이 도착하면 깨어나고, 8 개의 하드웨어 마이크로스레드가 사이클 단위로 전환한다. 행렬 유닛이 없어서 행렬곱을 브로드캐스트 + FMAC + 메시 리덕션으로 조립한다.
이 구조의 부수 효과가 재밌다 — 행렬 유닛이 없으니 송신 측에서 0 을 건너뛰는 것이 공짜다. 비정형 희소성으로 FP16 밀집 15.8 PFLOPS 가 희소 125 PFLOPS 까지 간다.
숫자 하나로 보는 차이
| 바이트당 FLOP 비율 | |
|---|---|
| WSE-3 (온웨이퍼 SRAM) | 약 1.3 |
| B200 (HBM 에서) | 약 0.002 |
세 자릿수 차이다. 이게 "메모리 벽을 설계로 없앴다"는 주장의 근거다.
Weight Streaming — 학습을 어떻게 하나
44 GB 안에 모델이 안 들어가는데 어떻게 학습하나? 활성값을 SRAM 에 고정하고 가중치를 흘려보낸다.
MemoryX (DRAM/flash 어플라이언스)
| weights stream in
v
+-----------------+
| WSE wafer | 활성값은 여기 상주
| (activations) |
+-----------------+
| gradients stream out
v
옵티마이저는 CPU 에서
=> 모델 크기는 44 GB 가 아니라 MemoryX 가 결정한다
=> 샤딩 없이 단일 디바이스처럼 프로그래밍
=> 스케일아웃은 SwarmX 로 순수 데이터 병렬다섯 가지 베팅
- 웨이퍼를 자르지 않는다 (다이 이음매당 2,880 GB/s 로 금속 스티칭)
- SRAM 만 (44 GB, 업계 최고 대역폭/용량 비)
- 데이터플로 코어, 행렬 유닛 없음 — 0 건너뛰기가 공짜로 따라온다
- 가중치가 움직이고 활성값은 머문다 — 모델 크기를 칩 메모리에서 분리
- 처리량이 아니라 지연을 판다 — 토큰당 가장 빠른 추론, 프리미엄 가격
현실 — 원문이 짚는 한계
원문은 여기서 솔직하다.
| 항목 | 상태 |
|---|---|
| 공개된 최대 클러스터 | 64 시스템 (Condor Galaxy 3) |
| 공개된 최대 모델 | 70B (Jais 2, G42, 2.6T 토큰) |
| 70B 초과 고객 사례 | 없음 |
| MFU(실효 활용률) | 미공개 |
| 시스템당 처리량 | 미공개 |
독립 측정(Artificial Analysis, 2024-08)에서 Llama 70B decode 가 446–969 tokens/sec 로 B200 의 약 2.4 배지만, 처리량이 아니라 지연 우위다. 프런티어 모델을 웨이퍼당 44 GB 로 서빙하려면 토큰당 비용이 높을 것으로 추정된다.
6. 한눈에 비교
| 축 | NVIDIA | Google TPU | AMD | Cerebras |
|---|---|---|---|---|
| 철학 | 대규모 병렬·프로그래밍 가능 | 행렬 기계·컴파일러 스케줄 | 보수적 CU·공격적 패키징 | 단일 웨이퍼·SRAM 전용 |
| 연산 추상 | 워프/스레드 + Tensor Core | VLIW 스칼라 + VPU + MXU | 웨이브프런트 + MFMA | 데이터플로 코어 + wavelet |
| 행렬곱 비동기 | 예 (Hopper+) | 아니오 (고정 스케줄) | 아니오 (웨이브 집합) | 아니오 (브로드캐스트+리덕션) |
| 메모리 모델 | HW 캐시 + SMEM + TMEM | SW 스크래치패드 | Infinity Cache + LDS | 온웨이퍼 SRAM 만 |
| 스케일업 | NVLink+NVSwitch (일관성) | ICI torus + 광 스위치 (메시지 패싱) | Infinity Fabric (IOD 통해 일관성) | 웨이퍼 메시 (고정) |
| 수치 형식 | FP32→FP16→FP8→FP4 | BF16→FP8→FP4 | FP16→FP8→FP4/FP6 | FP16/BF16 (FP8 아직) |
| 소프트웨어 | 커널 주도 (CUDA) | 컴파일러 주도 (JAX/XLA) | 하이브리드 (PyTorch+ROCm) | 단일 디바이스 / 레이어 병렬 |
| 최대 배포 | 576 GPU (NVL576) | 9,216 TPU (Ironwood) | 72 GPU (Helios) | 64 시스템 |
스케일업 패브릭을 그림으로
네 회사가 "칩 여러 개를 하나처럼 쓰는" 방법이 근본적으로 다르다.
NVIDIA NVL72 — 스위치를 통과한다
G G G G G G
\ \ | | / /
+------------------+
| NVSwitch |
+------------------+
/ / | | \ \
G G G G G GGPU 끼리 직접 잇지 않는다. 전부 스위치로 들어가고, 스위치가 all-to-all 을 만든다. 그래서 캐시 일관성이 성립하고 — 다른 GPU 의 메모리를 그냥 주소로 읽을 수 있다 — 랙 안 배선이 수동 구리 5,184 가닥으로 끝난다.
Google Ironwood — 스위치 없이 칩끼리 직결
+--- c --- c --- c ---+
| | | | |
+--- c --- c --- c ---+
| | | | |
+--- c --- c --- c ---+이웃한 칩끼리만 연결되고, 양 끝이 감겨 torus 를 이룬다(그림은 3D 중 한 면). 스위치가 없으니 캐시 일관성도 없다 — 대신 메시지 패싱으로 collective 를 돈다. 팟을 넘어갈 때만 광 회선 교환(Palomar)이 끼어들고, 그 스위치는 밀리초급으로 토폴로지 자체를 바꾼다.
AMD Helios — 작게 완전 연결하고, 그걸 쌓는다
+---------------------------+
| G G G G G G G G |
| \__\__\__|__/__/__/__/ |
| all-to-all | OAM box : 8 GPU 완전 연결
+-------------+-------------+
|
[ UALoE / UALink ]
|
x 9 = 72 GPU8-GPU 박스 안에서는 서로 완전 연결이고, 박스 바깥은 패브릭으로 잇는다. 일관성은 IOD(I/O 다이)를 통해 유지된다.
Cerebras WSE-3 — 패브릭이 곧 칩이다
+=================================+
| |
| 900,000 cores · 2D mesh |
| one wafer · 46,225 mm2 |
| no switch · no off-chip hop |
| |
+=================================+연결할 칩이 없다. 웨이퍼 하나가 곧 패브릭이고, 크기가 고정이다. 늘리려면 웨이퍼를 더 사서 이더넷으로 묶는 수밖에 없다.
| NVIDIA NVL72 | Google Ironwood | AMD Helios | Cerebras WSE-3 | |
|---|---|---|---|---|
| 묶는 단위 | 72 GPU | 9,216 칩 | 72 GPU | 웨이퍼 1 장 |
| 대역폭 | 130 TB/s all-to-all | 68 PB/s aggregate | 260 TB/s | 21 PB/s on-chip |
| 연결 방식 | 스위치 경유 | 칩 직결 (torus) | 박스 내 완전 연결 | 온웨이퍼 메시 |
| 일관성 | 캐시 일관성 | 없음 (메시지 패싱) | IOD 통해 일관성 | 해당 없음 |
| 물리 매체 | 수동 구리 5,184 가닥 | 3D torus + 광 회선 교환 | UALoE → UALink | 금속 스티칭 |
| 확장성 | 랙 단위로 증설 | 팟·슬라이스로 증설 | 랙 단위로 증설 | 고정 (웨이퍼 크기) |
7. 그래서 무엇을 고르나
원문의 결론은 "최적 플랫폼은 하나로 수렴하지 않는다" 이다.
- 칩 하나의 FP8 성능은 약 2 배 범위 안으로 모였다. 이 층위에서는 이미 비슷해졌다.
- 그런데 시스템 규모는 자릿수가 다르다. 9,216 칩 슈퍼팟과 72 GPU 랙과 64 시스템은 같은 축에 놓을 수 없다.
- 따라서 최적 플랫폼은 하나로 수렴하지 않고, 무엇을 우선하느냐가 답을 정한다.
네 회사의 베팅이 모두 프런티어 워크로드에서 실제 배포에 성공했다는 점이 이 주장을 뒷받침한다 — Gemini, Llama, xAI, Jais 가 각각 다른 실리콘 위에서 돈다.
소프트웨어 쪽은 좁혀지는 중이다. Triton 과 torch.compile 이 CUDA 와 컴파일러 주도 진영 사이의 간격을 줄이고 있다. 다만 철학의 극은 남는다 — 원문의 표현을 빌리면:
TPU 에서는 컴파일러가 유일하게 의미 있는 인터페이스이고,
GPU 에서는 컴파일러가 여러 인터페이스 중 하나다.
읽고 남는 것
개인적으로 인상적이었던 건 TPU 가 무엇을 "삭제"했는가 였다. 명령어 캐시, 분기 예측기, 리오더 버퍼, 하드웨어 스케줄러 — CPU 가 수십 년에 걸쳐 쌓아온 것을 전부 지우고 MAC 만 남겼다. 그게 가능한 이유가 "학습 워크로드는 정적으로 예측 가능하다"는 단 하나의 가정이고, 그 가정에 회사 전체를 걸었다는 점이 흥미롭다.
반대로 Cerebras 는 모두가 물리적 제약이라고 부르던 것을 설계 선택이라고 부른다. 메모리 벽은 HBM 을 쓰기로 했기 때문에 존재하는 것이고, SRAM 만 쓰면 바이트당 FLOP 비율이 세 자릿수 달라진다 — 대신 44 GB 라는 벽이 새로 생긴다. 벽을 없앤 게 아니라 다른 벽과 바꾼 것에 가깝다.
결국 네 회사 모두 같은 것을 하고 있다. 어떤 제약을 받아들이고 어떤 제약과 싸울지를 고르는 일.
출처
- 원문: AI Chip Architectures — Jacob Peake
- 한국어 소개: GeekNews
'LLM Serving and Optimization Study' 카테고리의 다른 글
| [LLMSO 7주차] llm-d 의 Predicted Latency-Based Scheduling (0) | 2026.09.16 |
|---|---|
| [LLMSO 5주차] vLLM 두 대 앞에 LiteLLM을 세우고, 네 가지를 실제로 재봤다 (0) | 2026.09.04 |
| [LLMSO 4주차] 쿠버네티스 위 TensorRT-LLM 실습기 — 설치부터 FP8 양자화, 그리고 vLLM 대조 (0) | 2026.08.30 |
| [LLM 3.5주차] 양자화 실습 (0) | 2026.08.23 |
| [LLMSO 3주차] K8s 기반 vLLM 서빙 파라미터 실측 튜닝기 (0) | 2026.08.23 |