AI 칩 아키텍처 6가지 — GPU·TPU·LPU가 데이터 이동을 두고 갈라진 이유

·

AI 칩 아키텍처

핵심 요약

  • 1980년대에는 단일 스레드 CPU 성능이 연 52%씩 증가했으나, 2018년에는 증가율이 3%까지 하락해 범용 CPU만으로 AI 연산 수요를 감당하기 어려운 구조로 전환됨
  • AI 연산은 도메인 특화 아키텍처(Domain-Specific Architecture) 경쟁의 중심에 자리 잡았으며, NVIDIA GPU, Google TPU, AMD Instinct, Cerebras WSE, AWS Trainium, Groq LPU 등 다양한 벤더가 각자의 설계 철학으로 시장에 진입함
  • 각 칩은 서로 다른 데이터 이동 방식을 채택하고 있어, 단순한 연산 성능(FLOPs) 비교만으로는 실제 워크로드 효율을 판단하기 어려운 상황임

분석

AI 칩 아키텍처는 이미 한 가지 정답으로 수렴하지 않았다. 1980년대에는 단일 스레드 CPU 성능이 매년 52%씩 끌어올려졌지만, 2018년에는 증가율이 3%까지 떨어졌다. Moore의 법칙이 무료 점심에 가까웠던 시대가 끝나자, AI 연산 수요는 그 빈자리를 채울 별도의 설계 언어를 요구하기 시작했다.

필자가 이 지점에서 가장 의미 있다고 보는 건, “칩을 어떻게 만드느냐”보다 “데이터를 어떻게 움직이느냐”가 AI 칩 아키텍처 경쟁의 중심축이 되었다는 점이다. 같은 FLOPs를 내걸어도 실제 워크로드 효율은 벤더마다 다르다. 그 차이가 곧 각 사의 설계 철학이다.

AI 칩 아키텍처가 갈라진 배경

2018년 3%까지 떨어진 성능 증가율은 트랜스포머 학습 같은 대규모 행렬 연산에 그대로 적용되지 않는다. NVIDIA는 GPU 기반 AI 칩 아키텍처로 먼저 시장을 열었고, Google은 TPU로 자체 워크로드에 맞춘 설계를 내놓았다. AMD Instinct, Cerebras WSE, AWS Trainium, Groq LPU까지 합류하면서 도메인 특화 아키텍처(DSA) 경쟁이 본격화됐다.

Cerebras WSE는 웨이퍼 전체를 단일 다이처럼 쓰는 극단적 접근을 택했다. Groq LPU는 컴파일 타임에 데이터 흐름을 미리 고정해 메모리 대역폭 병목을 회피한다. AWS Trainium은 가격 대비 성능을, Google TPU는 텐서 코어와 고대역폭 메모리(HBM)를 묶어 행렬 연산을 가속한다. 같은 AI 칩 아키텍처 범주에 묶이지만 작동 원리는 서로 다르다.

데이터 이동 방식이 AI 칩 아키텍처의 효율을 가른다

실무자 입장에서 눈에 띄는 건 FLOPs 스펙시트가 워크로드 성능과 직결되지 않는다는 사실이다. 메모리 계층과 상호연결 설계가 같은 연산량 대비 효율을 좌우한다. NVIDIA GPU는 HBM과 NVLink, NVSwitch로 대역폭과 확장성을 동시에 잡았고, TPU는 팟(pod) 단위 토폴로지로 데이터센터급 확장에 집중했다.

Groq LPU의 결정적 차이는 어디에 데이터를 두느냐가 아니라 언제 보내느냐에 있다. 결정론적 실행(deterministic execution)을 채택해 메모리 지연 변동을 제거한다. Cerebras WSE는 온다이 SRAM을 극대화해 외부 메모리 왕복 자체를 줄였다. 같은 AI 칩 아키텍처 안에서 데이터 이동의 답이 갈라진 셈이다.

트랜스포머 학습 구간이 미치는 영향

트랜스포머의 학습과 prefill 단계는 행렬-행렬 곱셈 비중이 높다. 이 구간은 메모리 대역폭보다 연산 처리량에 무게가 실린다는 뜻이다. H100, MI300, TPU v5p 같은 칩은 텐서 코어와 HBM을 묶어 처리량을 끌어올렸다. GeekNews의 AI 칩 아키텍처 토픽에 따르면 이 구도가 도메인 특화 칩 경쟁의 중심축으로 자리 잡았다.

반면 decode 단계처럼 토큰 단위 생성이 반복되는 구간은 메모리 대역폭이 병목이 된다. 같은 AI 칩 아키텍처가 양쪽을 모두 커버하기 어렵기 때문에, 실무에서는 워크로드 비율에 따라 칩을 혼합 배치하는 구도가 흔해졌다. a16z의 AI 밸류체인 종주 전략에서도 살펴봤듯, 칩 선정은 단순 스펙 비교에서 워크로드 단위 의사결정으로 이동하고 있다.

쟁점 정리

AI 칩 아키텍처 경쟁은 세 갈래로 수렴한다. 첫째, GPU는 범용성과 생태계 우위를 무기로 한다. 둘째, TPU·Trainium은 자체 워크로드 최적화로 비용 효율을 노린다. 셋째, Cerebras·Groq LPU는 메모리 병목을 회피하는 대체 경로를 제시한다. 어느 쪽이 정답인지는 워크로드 특성에 따라 갈린다.

AI 칩 아키텍처 선정 시 반드시 확인할 지표

단일 스레드 CPU 성능 증가율 52%→3%라는 수치는 단순 회고가 아니라 현재 의사결정의 출발점이다. 칩을 비교할 때 FLOPs만 보면 같은 함정에 빠진다. 메모리 대역폭(GB/s), HBM 용량, 상호연결 토폴로지(NVLink·ICI·이더넷), 그리고 워크로드 단계별 처리량까지 함께 봐야 실제 효율이 나온다.

필자가 현장에서 자주 보는 실수는 “벤치마크 점수가 좋다”만으로 칩을 고르는 경우다. 실제 학습·추론 파이프라인에서는 데이터 전처리와 통신 오버헤드가 전체 시간의 30~50%를 잡아먹는다. 이 구간을 AI 칩 아키텍처의 메모리 계층과 함께 따져야 한다.

지금 바로 해볼 것

  • 현재 학습·추론 파이프라인의 단계별 시간 비율을 프로파일링한다(전처리, 학습, 통신, decode).
  • 대상 칩의 HBM 용량과 메모리 대역폭을 GB/s 단위로 정리해 배치 크기와 매칭한다.
  • decode 비중이 높은 워크로드는 LPU, 학습·prefill 비중이 높은 워크로드는 GPU/TPU로 구분해 혼합 배치 시나리오를 검토한다.
  • 상호연결(NVLink, ICI, 이더넷) 토폴로지가 다중 노드 확장에서 병목이 되는지 시뮬레이션한다.
  • 분기마다 칩 벤더의 새 릴리즈 노트를 추적해 메모리 계층과 데이터 이동 방식 개선점을 기록한다.

자주 묻는 질문

AI 칩 아키텍처에서 가장 중요한 지표는 무엇인가요?

FLOPs만으로는 부족합니다. 메모리 대역폭, HBM 용량, 상호연결 토폴로지, 그리고 워크로드 단계별 시간 비율을 함께 봐야 실제 효율이 나옵니다.

Groq LPU는 GPU와 무엇이 다릅니까?

Groq LPU는 결정론적 실행으로 메모리 지연 변동을 제거합니다. 외부 메모리 왕복을 줄여 decode 단계처럼 토큰 단위 생성에 강점을 보입니다.

TPU와 Trainium 중 어떤 칩을 선택해야 하나요?

자체 워크로드가 Google Cloud 안에 머문다면 TPU가 유리하고, AWS 환경에 종속적이며 가격 대비 성능을 우선한다면 Trainium이 후보입니다. 둘 다 도메인 특화 칩이지만 생태계 의존도가 다릅니다.

Cerebras WSE는 어떤 환경에 적합한가요?

단일 모델이 HBM 한계를 넘는 매개변수 크기를 다뤄야 할 때 검토할 만합니다. 일반적인 학습·추론 파이프라인에서는 비용 대비 ROI를 확보하기 어렵습니다.

전문가 코멘트(AI)

AI반도체아키텍트

데이터 이동 중심의 도메인 특화 설계는 기술적으로 확정된 흐름이지만, 승부는 결국 소프트웨어 스택과 경제성에서 갈린다

덴나드 스케일링의 종료와 무어의 법칙 둔화 이후 도메인 특화 아키텍처(DSA)로의 전환은 컴퓨터 구조계가 예견해온 확정된 방향이며, ‘데이터 이동이 연산 자체보다 에너지와 지연을 지배한다’는 문제 의식은 아키텍처적으로 타당하다. Groq LPU의 정적 스케줄링 기반 결정론적 실행은 온칩 SRAM 의존으로 모델 크기와 유연성에 제약이 있음에도 저지연 추론에서 실질적 차별화를 증명했고, Cerebras의 웨이퍼스케일 접근은 수율과 비용 문제를 안고도 메모리 월을 우회하는 독특한 해법을 제시한다. 다만 이 경쟁의 실질 승부처는 HBM 용량이나 상호연결 토폴로지 같은 하드웨어 지표만이 아니라 컴파일러 성숙도, 커널 커버리지, CUDA 대체 생태계의 완성도에서 결정된다. 칩렛(UCIe), HBM 세대 교체, 광 상호연결로 이어지는 로드맵을 고려하면 지금의 아키텍처 분화는 수렴 이전의 과도기적 풍경에 가깝다. 워크로드별 최적점이 다르다는 진단 자체는 옳지만, 아키텍처 다양성이 생태계 파편화 비용을 키워 중소 도입자에게는 진입장벽으로 작동한다는 점이 이 구도의 숨은 리스크다.

평점: 8/10 – 데이터 이동 중심 설계와 워크로드별 최적화라는 방향은 기술적으로 검증된 진보이나, 하드웨어 다양성의 이면인 생태계 파편화와 경제성 문제가 아직 풀리지 않은 단계

ML인프라엔지니어

prefill-decode 병목 분리와 칩 혼합 배치는 실무 경험과 일치하지만, 다중 스택 운영 비용과 공급망 변수가 이상과 현실 사이에 놓여 있다

prefill이 연산 바운드이고 decode가 메모리 대역폭 바운드라는 구분은 continuous batching, PagedAttention, 프리필-디코드 분리 서빙까지 확산된 실무 지식과 정확히 맞물려 있으며, 워크로드 프로파일링을 칩 선정의 출발점으로 삼는 접근은 올바르다. 다만 현장의 칩 선택은 스펙시트보다 CUDA 커널 호환성, 분산 학습 프레임워크 지원, 인스턴스 가용성, HBM 공급 상황이 먼저 작동하고, GPU·TPU·LPU 혼합 배치는 이론상 최적이지만 서로 다른 툴체인과 모델 포맷을 동시에 유지하는 운영 비용이 상당하다. Groq의 결정론적 실행은 소규모 모델의 저지연 서빙에서 강점이 있으나 대규모 학습 지원이 제한적이라, ‘decode에는 LPU’라는 대응 관계를 실제 파이프라인에 적용하려면 모델 이식성 검증이 선행되어야 한다. TPU·Trainium의 비용 효율은 각 클라우드 생태계 종속이라는 조건부이므로 벤더 락인을 감수할 수 있는 조직인지가 사실상 첫 번째 판단 기준이 된다. 향후 2~3년은 벤치마크 재현성과 마이그레이션 도구 성숙도가 칩 다변화 전략의 성패를 가를 것으로 본다.

평점: 7/10 – 워크로드 기반 칩 선택이라는 원칙은 실무 타당성이 높지만, 다중 하드웨어 스택 운영 비용·이식성 리스크·공급망 현실을 반영하면 완성도가 떨어지는 단계

비판적 분석가

‘FLOPs는 무의미하다’는 담론의 최대 수혜자는 피크 스펙 경쟁에서 이기기 어려운 도전자와 마진을 회수하려는 하이퍼스케일러다

표면적으로는 기술적으로 중립적인 ‘데이터 이동이 핵심’이라는 통찰이지만, 이면을 들여다보면 이 담론이 가장 크게 이익을 보는 주체는 피크 FLOPs 경쟁에서 NVIDIA를 따라잡기 어려운 도전 업체들과, 머천트 실리콘에 지불하던 마진을 자사 실리콘으로 회수하려는 하이퍼스케일러다. TPU와 Trainium의 자체 칩 확장이 순수한 아키텍처 우월성 주장이 아니라 H100 공급난 시기에 형성된 NVIDIA의 가격 결정력에 대한 협상 카드이자 수익 구조 재편 수단이라는 해석이 자연스럽다. ‘워크로드별로 칩을 섞어 쓴다’는 결론 역시 칩 소비 총량을 늘리는 방향으로 읽힐 수 있어, 다양화 담론의 궁극적 수혜자가 오히려 칩을 파는 쪽 전체일 가능성을 배제할 수 없다. 우리가 진짜 주목해야 할 점은 벤치마크 평가 기준 자체가 누구의 손에 의해 어느 방향으로 재정의되고 있는가이며, ‘어떤 지표를 믿을 것인가’라는 선택조차 이미 이해관계의 장 위에 놓여 있다는 것이다.

물밑 시나리오

  • Groq·Cerebras 같은 도전 업체들이 ‘FLOPs 비교는 함정’이라는 프레임을 업계 담론으로 확산시켰을 가능성이 있다. 이는 자신들이 유리한 평가 축(토큰당 지연, 사용자당 처리량)으로 전장을 옮기는 전형적 포지셔닝 전략이기 때문이다.
  • 구글과 AWS의 자체 칩 확대는 공급 부족과 높은 마진율로 대변되는 NVIDIA의 가격 결정력에 대한 실질적 협상 레버리지로 작동했을 개연성이 크다. 자체 칩 공개와 확대 타이밍이 H100 품귀와 AI 캐펙스 경쟁 격화 시기와 겹친다는 정황이 이 해석을 뒷받침한다.

공식 설명 설득력: 6/10 – 데이터 이동 중심 프레임 자체는 기술적으로 설득력이 있으나, 이 담론이 특정 벤더와 하이퍼스케일러의 이해관계와 정렬되어 있다는 경제적 맥락과 평가 기준 재정의의 주체가 전혀 드러나지 않는다

6의 “AI 칩 아키텍처 6가지 — GPU·TPU·LPU가 데이터 이동을 두고 갈라진 이유”에 대한 답변

  1. […] 구조는 AI 칩 아키텍처 6가지에서 다룬 데이터 흐름 분리 사고방식과 닮아 있다. 시계열의 “데이터”를 어떻게 잘게 쪼개고 어디서 […]

  2. […] structure is reminiscent of the data-flow separation thinking discussed in the 6 AI chip architectures piece. How you slice a time series’ “data” and where you reassemble it is what […]

  3. […] 또는 llama.cpp로 미니CPM5-2B를 내려받아 Mac·RTX 3090 단일 GPU에서 추론 latency를 직접 […]

  4. […] MiniCPM5-2B via Ollama or llama.cpp and measure inference latency directly on a Mac or a single RTX 3090 […]

  5. […] 같은 가중치를 다양한 스택에서 즉시 시험할 수 있다. 배포 인프라 선택은 AI 칩 아키텍처별 데이터 이동 비용 관점에서 따져볼 […]

  6. […] On the day of release, vLLM, SGLang, and Ollama received day-0 support, with FP8 and GGUF builds also provided. The supported range extends beyond NVIDIA to include AMD and Cerebras. According to the official IFM announcement, hosting is split across Compass, Cerebras, and Nebius APIs, plus the platform.ifm.ai gateway, so the same weights can be tested immediately on various stacks. Deployment-infrastructure choice is worth evaluating from the perspective of data-movement costs by AI chip architecture. […]

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다