- Authors

- Name
- Youngju Kim
- @fjvbn20031
- 들어가며
- 0. WSE 세대의 진화 — 어디서 왔나
- 1. 왜 웨이퍼스케일인가 — 메모리 월 문제
- 2. WSE-3의 숫자들
- 3. 칩 간 통신을 제거한다는 것
- 4. 결함을 견디는 설계 — 수율의 비밀
- 5. 프로그래밍 모델 — 어떻게 쓰는가
- 5.5. 데이터 이동 에너지를 숫자로 느껴 보기
- 6. 실시간 추론에서의 강점
- 7. GPU 클러스터 대비 장단점
- 8. 어떤 워크로드에 맞는가
- 9. 웨이퍼스케일을 다른 가속기와 나란히 놓기
- 10. 가중치 스트리밍을 더 깊이 보기
- 11. 사례로 보는 적합성 — 언제 고려할 가치가 있나
- 12. 총소유비용(TCO) 관점
- 13. 자주 묻는 질문
- 14. 제조와 패키징의 도전
- 15. 개발자 관점 — 실무에서 무엇을 점검할까
- 15.5. 한눈에 보는 핵심 요약
- 16. 희소성을 더 깊이 — 0을 건너뛴다는 것
- 17. 더 큰 흐름 속의 웨이퍼스케일
- 마치며
- 참고 자료
들어가며
GPU를 수천 장 연결해 거대 모델을 학습시키는 시대에, Cerebras는 정반대의 질문을 던졌습니다. "칩을 잘게 쪼개 연결하는 대신, 아예 웨이퍼 한 장을 통째로 하나의 칩으로 쓰면 어떨까?"
보통 반도체 제조는 지름 300mm 웨이퍼 한 장 위에 수백 개의 작은 다이(die)를 찍어내고, 이를 잘라 개별 칩으로 패키징합니다. Cerebras의 WSE(Wafer Scale Engine)는 이 자르는 과정을 생략합니다. 웨이퍼 거의 전체가 잘리지 않고 하나의 거대한 프로세서가 됩니다. 손바닥보다 큰, 식판만 한 단일 칩입니다.
이 글에서는 WSE-3의 핵심 설계 결정들을 따라가며, 왜 이런 극단적인 형태가 등장했는지, 그리고 이것이 실무에서 어떤 의미를 갖는지 살펴봅니다. 결론부터 말하면, 웨이퍼스케일은 만능 해법이 아니라 "메모리 월"이라는 구체적인 문제를 정면으로 겨냥한 설계입니다.
0. WSE 세대의 진화 — 어디서 왔나
웨이퍼스케일은 하루아침에 등장하지 않았습니다. Cerebras는 세대를 거듭하며 같은 철학을 더 큰 규모로 밀어붙여 왔습니다.
| 세대 | 대략적 위치 | 핵심 진전 |
|---|---|---|
| WSE-1 | 1세대 | 웨이퍼스케일을 처음으로 양산 가능하게 증명 |
| WSE-2 | 2세대 | 코어 수와 온칩 메모리를 크게 확대 |
| WSE-3 | 현 세대 | 약 4조 트랜지스터, 약 90만 코어, 약 44GB SRAM |
각 세대의 공통 메시지는 한결같습니다. "데이터를 칩 안에 가두고, 칩 간 통신을 줄이며, 결함을 견디는 설계로 양산한다." 세대가 올라갈수록 더 많은 코어와 더 큰 온칩 메모리를 담아, 더 큰 모델을 칩 하나에 가깝게 다룰 수 있게 했습니다. 이 흐름을 이해하면, WSE-3의 숫자들이 갑자기 튀어나온 것이 아니라 일관된 베팅의 누적임을 알 수 있습니다.
이 글에서 다룰 원리들 (메모리 월 회피, 온칩 SRAM 중심, 결함 허용, 데이터플로우) 은 세대를 관통하는 공통 뼈대입니다. 그래서 특정 세대의 정확한 숫자보다, 그 숫자를 만들어낸 설계 철학을 이해하는 것이 더 오래 유효한 지식입니다.
1. 왜 웨이퍼스케일인가 — 메모리 월 문제
데이터 이동이 연산보다 비싸다
현대 AI 가속기의 가장 큰 골칫거리는 연산 자체가 아니라 데이터 이동입니다. 행렬 곱셈에 필요한 부동소수점 연산(FLOP) 한 번은 매우 저렴하지만, 그 연산에 필요한 데이터를 메모리에서 연산 유닛까지 옮기는 비용은 훨씬 큽니다.
대략적인 에너지 비율을 보면 직관이 잡힙니다.
연산/이동 상대 에너지 (대략)
-----------------------------------------------
FP 곱셈-덧셈 (연산) 1배
온칩 SRAM 읽기 (수 mm 이동) 수 배 ~ 수십 배
오프칩 HBM 읽기 수백 배
다른 칩으로 전송 (인터커넥트) 수백 ~ 수천 배
연산 유닛은 굶주린 채 데이터를 기다리고, 전력의 상당 부분이 비트를 옮기는 데만 쓰입니다. 이것이 "메모리 월(memory wall)"입니다. 연산 성능은 계속 빨라지는데, 메모리 대역폭이 그 속도를 못 따라가면서 생기는 격차입니다.
GPU의 해법과 그 한계
GPU는 이 문제를 HBM(High Bandwidth Memory)으로 완화합니다. 칩 옆에 고대역폭 메모리를 쌓아 붙여 대역폭을 끌어올리는 방식입니다. 하지만 HBM도 결국 칩 "바깥"에 있고, 모델이 커지면 여러 GPU에 나눠 담아야 하며, 그 순간 칩 간 통신(NVLink 등)이 새로운 병목이 됩니다.
Cerebras의 베팅은 이렇습니다. 메모리를 칩 바깥이 아니라 연산 유닛 바로 옆, 온칩 SRAM으로 가져오고, 모델을 여러 칩에 쪼개지 않아도 될 만큼 칩을 키우면 데이터 이동 비용이 근본적으로 줄어든다는 것입니다.
2. WSE-3의 숫자들
WSE-3의 스펙은 일반적인 칩과 비교하면 비현실적으로 느껴집니다.
| 항목 | WSE-3 (대략) | 비교: 대형 GPU |
|---|---|---|
| 트랜지스터 | 약 4조 개 | 수백억 개 |
| 코어 수 | 약 90만 개 | 수만 SM 레인 |
| 온칩 SRAM | 약 44GB | 수십 MB 급 |
| 온칩 메모리 대역폭 | 약 21 PB/s | 수 TB/s 급 |
| 물리적 크기 | 웨이퍼 전체 | 손톱~손바닥 |
여기서 핵심은 단일 숫자의 크기가 아니라 비율입니다. 온칩 SRAM이 44GB라는 것은, 많은 모델의 가중치를 오프칩 HBM 없이 칩 안에 그대로 담을 수 있다는 뜻입니다. 그리고 약 21 PB/s라는 온칩 대역폭은 HBM 대역폭과 자릿수가 다릅니다. 데이터가 칩 안에서 짧은 거리만 움직이기 때문에 가능한 수치입니다.
SRAM 절반, 로직 절반
WSE의 다이를 거칠게 나누면 면적의 약 절반이 SRAM, 절반이 연산 로직입니다. 이는 GPU와 정반대의 철학입니다. GPU는 연산 밀도를 최대화하고 메모리는 바깥에 두는 반면, WSE는 메모리를 연산 옆에 분산 배치해서 "각 코어가 자기 데이터를 바로 옆에 둔다"는 구조를 만듭니다.
GPU 모델 WSE 모델
----------------- -----------------
[ 연산 코어 다발 ] [코어][SRAM][코어][SRAM]
| [SRAM][코어][SRAM][코어]
(오프칩 버스) [코어][SRAM][코어][SRAM]
| ...격자 전체에 분산...
[ HBM 스택 (바깥) ] 메모리가 연산 바로 옆
3. 칩 간 통신을 제거한다는 것
대규모 학습의 숨은 비용은 통신입니다. 모델을 여러 GPU에 나누면(텐서 병렬, 파이프라인 병렬), 매 스텝마다 GPU들이 활성값과 그래디언트를 주고받아야 합니다. 이 통신은 빠른 인터커넥트로도 완전히 숨기기 어렵고, 스케일이 커질수록 효율이 떨어집니다.
WSE의 논리는 단순합니다. 모델이 칩 하나에 들어가면, 칩 간 통신 자체가 없습니다. 코어들 사이의 통신은 웨이퍼 위 격자 네트워크를 통해 일어나며, 이는 별도 칩으로 나가는 것보다 훨씬 짧고 빠릅니다.
물론 한 장으로 부족할 만큼 큰 모델은 여러 WSE를 클러스터로 묶습니다. 이때 Cerebras는 가중치를 별도의 외부 메모리 장치(MemoryX)에 두고 스트리밍하는 방식 등으로 단일 칩의 메모리 한계를 보완하는 접근을 취합니다. 핵심은 "통신을 없앤다"가 아니라 "통신을 가능한 한 칩 안의 짧은 거리로 가둔다"입니다.
데이터플로우와 희소성
WSE는 각 코어가 자신에게 들어오는 데이터에 반응해 연산하는 데이터플로우 스타일로 동작합니다. 여기서 흥미로운 점은 0인 값에 대해 곱셈을 건너뛸 수 있다는 것입니다. 신경망 활성값에는 0이 많은데(특히 ReLU 계열), 0을 곱하면 결과가 0이므로 그 연산을 통째로 생략하면 시간과 전력을 아낄 수 있습니다. 세밀한 입자(fine-grained)의 희소성을 하드웨어 차원에서 활용하는 설계입니다.
4. 결함을 견디는 설계 — 수율의 비밀
웨이퍼 전체를 칩 하나로 쓴다는 발상에서 누구나 떠올리는 질문이 있습니다. "웨이퍼에 결함이 하나라도 있으면 칩 전체가 불량 아닌가?"
일반적인 칩 제조에서는 결함이 있는 다이를 버리면 됩니다. 작은 다이가 수백 개 있으니 몇 개 버려도 나머지는 팝니다. 하지만 칩이 웨이퍼 전체라면, 결함 하나로 전체를 버리는 것은 경제적으로 불가능합니다.
Cerebras의 해법은 여분(redundancy)과 우회입니다.
- 웨이퍼 위에 필요한 코어보다 약간 더 많은 여분 코어를 배치합니다.
- 제조 후 테스트에서 결함이 있는 코어를 찾아내면, 라우팅을 재구성해 그 코어를 우회합니다.
- 격자 네트워크가 결함 지점을 돌아가도록 경로를 다시 잡습니다.
그 결과, 일부 코어가 죽어 있어도 칩은 정상 사양으로 동작합니다. "완벽한 웨이퍼"를 요구하는 대신, "결함이 있어도 동작하는 웨이퍼"를 설계한 것입니다. 이것이 웨이퍼스케일을 양산 가능하게 만든 핵심 엔지니어링입니다.
[코어][코어][불량][코어] 라우팅이 불량 코어를
[코어][코어][코어][코어] → 우회하도록 재구성됨.
[불량][코어][코어][코어] 논리적 격자는 그대로 유지.
5. 프로그래밍 모델 — 어떻게 쓰는가
90만 개의 코어를 개발자가 손으로 다룬다면 아무도 쓰지 못할 것입니다. Cerebras는 익숙한 프레임워크 위에서 동작하도록 소프트웨어 스택을 제공합니다.
개념적인 흐름은 다음과 같습니다.
# 개념적 예시 (실제 API와 다를 수 있음)
import cerebras.framework as cb
model = build_transformer(num_layers=48, hidden=8192)
# 그래프를 WSE에 맞게 컴파일.
# 컴파일러가 레이어를 코어 격자에 배치하고
# 데이터 흐름과 라우팅을 자동으로 결정한다.
compiled = cb.compile(model, batch_size=32)
# 학습 또는 추론 루프는 친숙한 형태를 유지.
for batch in dataloader:
loss = compiled.train_step(batch)
핵심은 컴파일러입니다. 개발자가 표준 모델 정의를 주면, Cerebras 컴파일러가 그 연산 그래프를 웨이퍼의 코어 격자에 매핑하고, 어떤 코어가 어떤 연산을 맡을지, 데이터가 격자 위에서 어떻게 흐를지를 결정합니다. PyTorch 등 익숙한 프레임워크를 프런트엔드로 쓰면서, 백엔드에서 이 매핑을 처리하는 구조를 지향합니다.
큰 모델을 어떻게 담는가
44GB라는 온칩 SRAM도 수천억 파라미터 모델 앞에서는 부족할 수 있습니다. 이때는 가중치를 외부 메모리에 두고 레이어 단위로 스트리밍하는 방식을 씁니다. 활성값은 칩 안에 머물고, 가중치가 흘러 들어오는 형태입니다. 이렇게 하면 "모델 크기"와 "칩 메모리"를 분리해서, 칩을 키우지 않고도 더 큰 모델을 다룰 수 있습니다.
5.5. 데이터 이동 에너지를 숫자로 느껴 보기
CIM 글에서도 다루지만, 데이터 이동이 왜 그렇게 비싼지 한 번 더 짚고 가면 웨이퍼스케일의 가치가 또렷해집니다.
같은 곱셈-덧셈 한 번을 수행하더라도, 그 연산에 필요한 데이터를 어디서 가져오느냐에 따라 에너지가 자릿수로 갈립니다. 연산 자체보다, 그 데이터를 옮기는 거리가 비용을 지배합니다.
데이터 출처 상대 에너지(개념)
-----------------------------------------------
바로 옆 레지스터/SRAM 가장 저렴
같은 칩 내 먼 SRAM 조금 더 비쌈
오프칩 HBM 훨씬 비쌈
다른 칩(인터커넥트 경유) 가장 비쌈
이 표가 말하는 바는 단순합니다. 데이터를 가까이 둘수록 싸다는 것입니다. 웨이퍼스케일의 모든 설계 결정 (온칩 SRAM 분산, 칩을 키워 통신 회피, 가중치를 칩 안에 담기) 은 결국 이 표의 위쪽 행에 머무르려는 노력입니다. 전력이 데이터센터 확장의 실질적 상한이 된 2026년에, "비트를 멀리 옮기지 않는다"는 것은 곧 더 많은 모델을 같은 전력 예산 안에서 돌릴 수 있다는 뜻입니다.
이것이 웨이퍼스케일을 단순한 속도 자랑이 아니라 "에너지 구조"의 문제로 이해해야 하는 이유입니다. 속도는 결과일 뿐이고, 근본 원인은 데이터를 덜 움직이는 구조에 있습니다.
6. 실시간 추론에서의 강점
웨이퍼스케일의 효과가 가장 극적으로 드러나는 곳은 학습보다 오히려 추론, 특히 지연(latency)이 중요한 LLM 서빙입니다.
LLM의 토큰 생성은 본질적으로 메모리 대역폭에 묶여 있습니다. 토큰 하나를 만들려면 모델 가중치 전체를 한 번 읽어야 하는데, 이 읽기 속도가 생성 속도를 결정합니다. GPU에서는 가중치가 HBM에 있어 HBM 대역폭이 상한이 됩니다.
WSE는 가중치를 온칩 SRAM에 두므로, 가중치 읽기가 자릿수 빠른 온칩 대역폭으로 일어납니다. 그 결과 단일 요청에 대한 토큰 생성 속도(토큰/초)가 GPU 대비 크게 높아질 수 있습니다. 사용자가 "타이핑되는 속도"를 체감하는 챗봇이나, 추론 과정을 길게 펼치는 reasoning 모델에서 이 차이는 사용자 경험을 바꿉니다.
| 워크로드 | 병목 | WSE 이점 |
|---|---|---|
| 학습 (대규모 배치) | 연산 + 통신 | 통신 축소, 단일 칩 효율 |
| 배치 추론 (처리량) | 연산/대역폭 균형 | 상황에 따라 다름 |
| 저지연 추론 (토큰/초) | 메모리 대역폭 | 온칩 SRAM으로 큰 이점 |
7. GPU 클러스터 대비 장단점
장점
- 단순한 스케일링: 모델이 칩에 들어가면 복잡한 병렬화 전략(텐서/파이프라인 병렬)을 짜지 않아도 됩니다.
- 낮은 추론 지연: 온칩 메모리 덕분에 토큰 생성이 빠릅니다.
- 통신 오버헤드 감소: 칩 간 통신을 칩 내부의 짧은 경로로 대체합니다.
- 전력 효율: 데이터를 멀리 옮기지 않으므로 이동에 쓰는 전력이 줄어듭니다.
단점과 한계
- 비용과 접근성: 시스템 단가가 높고, 생태계가 NVIDIA만큼 넓지 않습니다.
- 유연성: GPU는 범용성이 압도적입니다. 그래픽, 다양한 HPC, 온갖 프레임워크가 GPU를 1순위로 지원합니다. WSE는 특정 워크로드에 최적화된 만큼 범용성에서 손해를 봅니다.
- 생태계와 도구: CUDA를 중심으로 한 방대한 라이브러리, 커뮤니티, 인재 풀은 단기간에 따라잡기 어려운 해자입니다.
- 메모리 상한: 온칩 SRAM은 빠르지만 용량이 HBM 대비 작아, 매우 큰 모델은 스트리밍 등 추가 기법에 의존합니다.
8. 어떤 워크로드에 맞는가
웨이퍼스케일이 빛나는 자리는 분명합니다.
- 지연이 중요한 실시간 LLM 추론(대화형, reasoning 체인이 긴 모델)
- 통신 병목이 학습 효율을 갉아먹는 대규모 모델
- 데이터 이동 에너지가 운영비의 큰 비중을 차지하는 환경
반대로, 다양한 워크로드를 한 인프라에서 유연하게 돌려야 하거나, 기존 CUDA 자산과 생태계에 깊이 묶여 있거나, 비용 민감도가 높은 일반적인 환경에서는 GPU 클러스터가 여전히 합리적인 선택입니다.
2026년 현재의 큰 그림에서, NVIDIA가 가속기 시장의 약 75~80%를 점유하며 Blackwell 세대로 영향력을 굳히고 있고, 클라우드 자체 ASIC과 추론 특화 칩의 비중이 빠르게 커지는 중입니다. 추론 capex가 학습 capex를 처음으로 추월하는 전환점이 다가오는 가운데, "추론 지연"을 무기로 삼는 Cerebras 같은 설계의 존재 이유가 더 또렷해집니다. 웨이퍼스케일은 GPU를 대체하려는 시도가 아니라, GPU가 구조적으로 불리한 영역을 공략하는 다른 답입니다.
9. 웨이퍼스케일을 다른 가속기와 나란히 놓기
같은 메모리 월 문제를 풀려는 여러 설계를 한 표에 모아 보면, 웨이퍼스케일의 위치가 선명해집니다.
| 설계 | 핵심 아이디어 | 메모리 전략 | 강점 영역 |
|---|---|---|---|
| GPU (Blackwell) | 범용 처리량 극대화 | HBM(오프칩, 대용량) | 학습 + 폭넓은 워크로드 |
| TPU (systolic) | 행렬곱 전용 격자 | HBM + 온칩 버퍼 | 대규모 학습/추론 |
| 웨이퍼스케일(WSE) | 칩을 웨이퍼 크기로 | 온칩 SRAM 중심 | 저지연 추론, 통신 회피 |
| 추론 ASIC(Groq 등) | 추론 특화 데이터플로우 | 온칩 SRAM | 저지연 LLM 서빙 |
| 인메모리(CIM) | 메모리에서 연산 | 메모리=연산기 | 초저전력 엣지 추론 |
핵심 직관은 이렇습니다. 모든 설계가 "데이터를 덜 움직인다"는 같은 목표를 향하지만, 그 목표에 도달하는 물리적 수단이 다릅니다. GPU는 대역폭을 키워 정면 돌파하고, 웨이퍼스케일은 칩을 키워 데이터를 칩 안에 가두며, 인메모리는 아예 메모리를 연산기로 바꿉니다. 어느 쪽이 우월하다기보다, 워크로드의 병목 위치에 따라 답이 갈립니다.
시스토릭 어레이와의 대비
TPU로 대표되는 시스토릭 어레이는 데이터가 격자를 따라 박동(systolic)처럼 흐르며 곱셈-덧셈을 누적합니다. WSE도 데이터가 코어 격자를 흐른다는 점에서 닮았지만, 결정적 차이는 메모리의 위치입니다. 시스토릭 어레이는 여전히 가중치/활성값의 상당 부분을 오프칩 HBM에 의존하는 반면, WSE는 온칩 SRAM에 가중치를 담는 비율이 훨씬 높습니다. 같은 "격자 위 데이터플로우"라도, 데이터가 칩을 떠나는 빈도에서 갈리는 것입니다.
10. 가중치 스트리밍을 더 깊이 보기
44GB 온칩 SRAM으로도 수천억~조 단위 파라미터 모델은 한 번에 담기 어렵습니다. 이때 Cerebras가 쓰는 접근의 핵심은 "활성값은 칩에 고정, 가중치는 흘려보낸다"입니다.
일반 GPU 학습 Cerebras 가중치 스트리밍
----------------- -----------------
가중치 + 활성값을 GPU 메모리에 활성값은 WSE 온칩에 상주
모델을 여러 GPU에 분할(샤딩) 가중치는 외부에서 레이어 단위로 유입
스텝마다 GPU 간 통신 폭증 모델을 칩에 쪼개 담지 않음
이 분리가 주는 이점은 두 가지입니다. 첫째, "모델 크기"와 "칩 용량"이 분리됩니다. 칩을 더 키우지 않아도 더 큰 모델을 다룰 수 있습니다. 둘째, 활성값 메모리가 칩에 머무르므로, 학습에서 흔한 활성값 재계산(recomputation)이나 활성값을 오프칩으로 내보내는 비용이 줄어듭니다.
대신 트레이드오프도 분명합니다. 가중치를 외부에서 흘려보내려면 그 경로의 대역폭이 충분해야 하고, 레이어가 매우 큰 경우 이 유입 속도가 새로운 상한이 될 수 있습니다. "온칩에 다 담는 이상"과 "외부에서 흘려보내는 현실" 사이의 균형점이 시스템 설계의 핵심입니다.
11. 사례로 보는 적합성 — 언제 고려할 가치가 있나
추상적인 장단점만으로는 결정을 내리기 어렵습니다. 구체적인 상황 몇 가지로 감을 잡아 봅시다.
상황 A: 대화형 reasoning 서비스. 사용자가 질문을 던지면 모델이 긴 추론 체인을 펼치며 답을 만드는 서비스가 있습니다. 토큰을 빨리 뽑을수록 사용자가 답을 빨리 받고, 같은 GPU 시간에 더 많은 요청을 처리합니다. 토큰/초가 곧 매출과 사용자 만족으로 직결됩니다. 이 경우 온칩 SRAM 기반의 빠른 가중치 읽기가 직접적인 이득이 됩니다.
상황 B: 다양한 모델을 매주 교체하는 연구팀. 새 아키텍처, 새 연산자, 실험적 모델을 끊임없이 바꿔 돌립니다. 이때는 컴파일러가 모든 변형을 매끄럽게 받아내야 하는데, 특화 하드웨어보다 성숙한 GPU 생태계가 마찰이 적습니다. 유연성이 지연보다 중요한 사례입니다.
상황 C: 비용 민감한 일반 서빙. 트래픽은 많지만 지연 요구가 느슨하고, 배치로 묶어 처리량을 키울 수 있는 서비스입니다. 이런 경우 처리량당 비용이 핵심이라, 대량 보급된 GPU의 규모의 경제가 유리할 수 있습니다.
결정의 기준은 한 문장으로 압축됩니다. "내 서비스의 가치가 단일 요청의 지연에 묶여 있는가, 아니면 처리량과 유연성에 묶여 있는가." 전자면 웨이퍼스케일을, 후자면 GPU를 먼저 검토하는 것이 합리적입니다.
12. 총소유비용(TCO) 관점
하드웨어 선택은 칩 가격표만으로 끝나지 않습니다. 운영 전체를 보는 TCO 관점이 필요합니다.
- 전력과 냉각: 데이터 이동을 줄이면 같은 일을 더 적은 전력으로 합니다. 전력이 데이터센터 확장의 실질적 상한이 된 시대에, 와트당 성능은 곧 운영비입니다.
- 시스템 수와 공간: 모델이 적은 수의 시스템에 들어가면 랙 공간, 네트워킹, 운영 인력이 줄어듭니다.
- 엔지니어링 시간: 복잡한 병렬화를 직접 튜닝하는 데 드는 인건비는 종종 과소평가됩니다. 단순한 스케일링은 그 자체로 비용 절감입니다.
- 생태계 마찰: 반대로, 익숙하지 않은 도구에 팀을 적응시키는 비용, 라이브러리 부재로 인한 우회 작업은 숨은 비용입니다.
핵심은 "칩 단가"라는 한 숫자에 속지 않는 것입니다. 비싼 칩이 더 적은 시스템과 더 낮은 전력으로 같은 일을 해낸다면, 시스템 전체로는 더 쌀 수 있습니다. 반대도 마찬가지입니다.
13. 자주 묻는 질문
Q. 웨이퍼스케일이 결국 GPU를 대체하나요? 아닙니다. GPU의 범용성과 생태계는 당분간 대체 불가에 가깝습니다. 웨이퍼스케일은 특정 영역(저지연 추론, 통신 병목이 큰 학습)을 공략하는 보완재로 보는 것이 정확합니다.
Q. 코어가 90만 개면 개발자가 그걸 다 신경 써야 하나요? 아닙니다. 컴파일러가 모델 그래프를 코어 격자에 자동 배치합니다. 개발자는 표준 프레임워크로 모델을 정의하는 데 집중합니다.
Q. 결함이 있는 웨이퍼로 어떻게 정상 성능이 나오나요? 여분 코어와 라우팅 재구성 덕분입니다. 결함 코어를 우회하도록 경로를 다시 잡아, 논리적으로는 완전한 칩처럼 동작합니다.
Q. 온칩 SRAM이 44GB면 모든 모델이 들어가나요? 아닙니다. 매우 큰 모델은 가중치를 외부에서 스트리밍합니다. 이때는 그 유입 대역폭이 성능을 좌우합니다.
14. 제조와 패키징의 도전
웨이퍼스케일은 설계뿐 아니라 제조와 패키징에서도 새로운 문제를 풀어야 했습니다. 일반 칩은 작아서 균일한 전력 공급과 냉각이 비교적 쉽지만, 식판만 한 단일 칩은 차원이 다릅니다.
- 전력 공급: 거대한 칩 표면 전체에 균일하게 전력을 공급해야 합니다. 한쪽만 전압이 떨어지면 그 영역의 코어가 제대로 동작하지 않습니다. 그래서 전력을 칩 위에서 수직으로 끌어오는 방식 등 특수한 전력 전달 설계가 필요합니다.
- 열 관리: 큰 면적에서 발생하는 열을 균일하게 빼내야 합니다. 핫스팟이 생기면 그 부분만 성능이 떨어지거나 수명이 줄어듭니다. 시스템 차원의 정교한 냉각 설계가 필수입니다.
- 기계적 응력: 실리콘과 패키지 재료는 온도에 따라 팽창률이 다릅니다. 칩이 클수록 가열·냉각 시 휘어지는 응력이 커져, 이를 견디는 패키징이 필요합니다.
이 모든 것을 풀어야 비로소 "웨이퍼 한 장 = 칩 하나"가 실제 제품이 됩니다. 웨이퍼스케일이 단순한 아이디어를 넘어 엔지니어링의 집약체인 이유입니다.
일반 칩 웨이퍼스케일
----------------- -----------------
작은 면적, 균일 전력 쉬움 거대 면적, 전력 균일성 도전
국소 냉각 전면 균일 냉각 필요
응력 적음 가열/냉각 응력 큼
15. 개발자 관점 — 실무에서 무엇을 점검할까
웨이퍼스케일 시스템 도입을 검토하는 팀이라면 다음을 순서대로 점검하면 좋습니다.
- 워크로드 프로파일링: 먼저 내 추론/학습의 진짜 병목을 측정합니다. 메모리 대역폭에 묶여 있는지, 통신에 묶여 있는지, 연산에 묶여 있는지를 데이터로 확인합니다.
- 모델·연산자 지원: 쓰는 모델 구조와 연산자가 벤더 컴파일러에서 잘 지원되는지 확인합니다. 핵심 연산이 1급으로 지원되면 도입이 매끄럽습니다.
- 마이그레이션 경로: 기존 코드를 얼마나 고쳐야 하는지, 표준 프레임워크에서 얼마나 자연스럽게 넘어가는지 평가합니다.
- 벤치마크는 내 워크로드로: 벤더가 제시하는 수치가 아니라, 실제 내 모델과 입력 분포로 측정한 토큰/초, 지연, 전력을 봅니다.
- TCO 시뮬레이션: 칩 단가가 아니라 시스템 수, 전력, 운영 인력을 합친 총비용으로 비교합니다.
이 점검을 통과한다면, 웨이퍼스케일은 GPU가 주지 못하는 가치를 줄 수 있습니다. 통과하지 못한다면, 무리해서 도입할 이유는 없습니다. 도구는 문제에 맞아야 빛납니다.
15.5. 한눈에 보는 핵심 요약
긴 글을 압축하면 다음 다섯 문장으로 정리됩니다.
- 웨이퍼스케일은 메모리 월, 즉 데이터 이동 비용 문제를 정면으로 겨냥한 설계입니다.
- WSE-3는 웨이퍼 한 장을 통째로 칩으로 만들어, 약 90만 코어와 약 44GB 온칩 SRAM을 담습니다.
- 메모리를 연산 옆에 분산하고 칩 간 통신을 줄여, 특히 저지연 추론에서 강점을 보입니다.
- 여분 코어와 라우팅 재구성으로 결함을 견디는 설계가 양산을 가능케 했습니다.
- 범용성과 생태계는 GPU에 양보하므로, 워크로드의 병목이 메모리·통신일 때 가장 빛납니다.
이 다섯 줄을 기억한다면, 세부 숫자가 바뀌어도 웨이퍼스케일을 평가하는 기준은 흔들리지 않습니다.
16. 희소성을 더 깊이 — 0을 건너뛴다는 것
앞서 WSE가 0인 값에 대한 곱셈을 건너뛸 수 있다고 했습니다. 이 점을 조금 더 풀어 보면 웨이퍼스케일 설계의 또 다른 영리함이 보입니다.
신경망의 활성값에는 의외로 0이 많습니다. ReLU 같은 활성화 함수는 음수 입력을 전부 0으로 만들어, 한 레이어 출력의 절반 이상이 0인 경우도 흔합니다. 디지털 가속기는 보통 이 0들도 정직하게 곱셈을 수행합니다. 0을 곱하면 결과가 0인 것을 뻔히 알면서도, 고정된 격자가 모든 위치를 동일하게 처리하기 때문입니다.
밀집 처리(dense) 희소 처리(sparse)
----------------- -----------------
0 x w 도 계산 0인 입력은 곱셈 생략
모든 위치 동일 처리 비0 위치만 연산
예측 가능하지만 낭비 연산/전력 절약, 제어 복잡
WSE는 데이터플로우 구조 덕분에 비0 데이터에만 반응하도록 만들 수 있어, 이런 세밀한 희소성을 하드웨어 차원에서 활용합니다. 이론적으로 활성값의 절반이 0이라면 그만큼의 연산과 전력을 아낄 수 있습니다. 물론 희소성을 활용하려면 어디가 0인지 추적하는 오버헤드가 따르고, 그 이득이 오버헤드를 넘어서야 의미가 있습니다. 고정된 격자에 의존하는 시스토릭 어레이가 희소성 활용에서 상대적으로 불리한 반면, 데이터플로우 기반 설계가 유리한 지점이 바로 여기입니다.
17. 더 큰 흐름 속의 웨이퍼스케일
마지막으로 한 걸음 물러나 큰 흐름을 봅시다. 지난 수십 년간 컴퓨팅은 "무어의 법칙"이라는 순풍을 탔습니다. 트랜지스터가 작아지고 많아지면서 같은 면적에 더 많은 연산이 들어갔습니다. 하지만 미세화의 속도가 둔화되고, 전력과 메모리 대역폭이 새로운 상한이 되면서, "더 작게"만으로는 부족한 시대가 왔습니다.
이 전환기에 등장한 답들이 서로 다른 방향을 가리킵니다. 칩렛과 CoWoS 같은 고급 패키징은 여러 다이를 하나처럼 묶어 "더 작게"의 한계를 우회하고, HBM은 메모리를 칩 옆에 쌓아 대역폭을 끌어올리며, 인터커넥트(NVLink, UALink)는 칩들을 더 빠르게 연결합니다. 웨이퍼스케일은 이 흐름의 극단에 있습니다. "쪼개서 다시 연결하는" 비용 자체를 없애려고, 아예 쪼개지 않는 길을 택한 것입니다.
어느 답이 최종 승자가 될지는 아직 모릅니다. 아마 단일 승자는 없을 것입니다. 워크로드마다 병목이 다르고, 그 병목마다 가장 잘 맞는 설계가 다르기 때문입니다. 분명한 것은, "하나의 범용 칩이 모든 것을 한다"는 단순한 시대가 저물고, 설계의 다양성이 폭발하는 시대가 왔다는 점입니다. 웨이퍼스케일은 그 다양성의 가장 대담한 표현 중 하나입니다.
마치며
Cerebras의 웨이퍼스케일은 "더 빠른 코어"가 아니라 "데이터를 덜 움직이는 구조"로 메모리 월에 답합니다. 웨이퍼 한 장을 통째로 칩으로 만들고, 메모리를 연산 옆에 분산하고, 결함을 견디는 설계로 양산을 가능케 한 것은 그 자체로 인상적인 엔지니어링입니다.
하지만 모든 강력한 설계가 그렇듯, 이것은 트레이드오프의 산물입니다. 범용성과 생태계를 일부 내주고 특정 워크로드의 지연과 효율을 얻었습니다. 하드웨어를 고를 때 우리가 던져야 할 질문은 "어느 칩이 더 빠른가"가 아니라 "내 워크로드의 진짜 병목이 무엇인가"입니다. 그 병목이 메모리 대역폭과 통신이라면, 웨이퍼스케일은 진지하게 고려할 가치가 있는 답입니다.
참고 자료
- Cerebras 공식 사이트: https://www.cerebras.ai
- Cerebras WSE 제품 페이지: https://www.cerebras.ai/product-chip
- NVIDIA Blackwell 플랫폼: https://www.nvidia.com/en-us/data-center/technologies/blackwell-architecture/
- Google Cloud TPU: https://cloud.google.com/tpu
- 메모리 월 관련 연구 검색(arXiv): https://arxiv.org/list/cs.AR/recent
- SemiAnalysis (반도체 산업 분석): https://www.semianalysis.com