왜 추천 모델은 GPU에서 힘을 못 쓸까?

우리가 흔히 'AI 학습'이라고 하면 떠올리는 건 거대 언어 모델(LLM)입니다. 엄청난 부동소수점 연산량(FLOPS)을 자랑하는 GPU가 딱 맞는 작업이죠. 그런데 Meta가 실제로 돈을 버는 곳은 **추천 모델(Recommendation Model)**입니다. 인스타그램 릴스, 페이스북 피드, 친구 추천... 이 모든 게 추천 모델이 만들어내는 결과물이에요.

문제는 이 추천 모델이 LLM과 완전히 다른 병목을 가지고 있다는 점입니다.

  • **임베딩 테이블(Embedding Table)**이 모델 파라미터의 99% 이상을 차지함
  • 수백 개의 가속기 사이에서 AllReduce, AllToAll, AllGather 집합 통신이 초당 수없이 발생
  • 결국 연산(Compute)이 아니라 통신(Communication)이 병목

여기서 결정적인 문제가 생깁니다. GPU에서는 NCCL 같은 통신 라이브러리가 GPU 커널로 실행됩니다. 즉, 통신을 하려고 학습 연산에 써야 할 SM(Streaming Multiprocessor)을 빼앗아 쓰는 구조예요. 통신과 학습이 동시에 돌면 둘 다 느려집니다. 실제로 GPU 클러스터에서는 집합 통신과 대형 GEMM이 겹칠 때 20% 이상의 연산 성능 저하가 발생한다고 알려져 있습니다.

Meta는 이 지점에서 근본적으로 다른 선택을 했습니다. 통신을 '나중에 처리할 부가 기능'이 아니라, **칩 설계의 일급 시민(first-class citizen)**으로 만든 거죠. 그 결과물이 MTIA 300입니다. (자세한 실리콘 설계는 ISCA 26 논문에서 확인할 수 있습니다.)

참고로, 이 글의 근거자료는 Meta Engineering Blog입니다.

Meta MTIA 300 AI accelerator chip package diagram showing integrated NIC chiplets for recommendation model training System Abstract Visual

MTIA 300의 핵심 설계: NIC를 칩 안으로

1. 패키지 내장 NIC (Network-in-Package)

MTIA 300은 네트워크 인터페이스가 칩 패키지 내부에 들어 있습니다.

[기존 GPU 아키텍처]
CPU ──PCIe──> GPU ──PCIe──> NIC ──> 네트워크
         (호스트가 중재, 병목 발생)

[MTIA 300 아키텍처]
┌──────────── 칩 패키지 ────────────┐
│  PE Grid (12×6)  │  NIC Chiplet  │
│                  │  (6× 800Gbps) │
│  Message Engines │  NIC Chiplet  │
│  (16개, RISC-V)  │  (6× 800Gbps) │
└──────────────────┴───────────────┘
         PCIe 버스를 건너지 않음
  • 2개의 NIC 칩렛, 각각 6개의 커스텀 800 Gbps RDMA NIC 탑재
  • 총 1.2 TB/s I/O 대역폭을 PCIe 버스 없이 확보
  • 기존 GPU의 호스트-디바이스-NIC 병목 제거

2. 12개의 이더넷 NIC을 유연하게 분할

같은 NIC을 스케일업(랙 내 16노드, 최대 1 TB/s)과 스케일아웃(랙 간, 200 GB/s)에 모두 사용합니다. 하드웨어를 바꾸지 않고 네트워크 재구성만으로 분할 비율을 조정할 수 있어요.

지연 시간 최소화를 위해 express doorbells를 도입했습니다. work request write 자체가 doorbell 역할을 해서 추가 메모리 읽기를 제거, 오퍼레이션당 약 800ns 절약됩니다.

3. 연산 그리드에서 통신을 완전히 분리

MTIA 300은 **16개의 전용 Message Engine(ME)**을 별도로 둡니다. 각 ME는:

  • RISC-V 코어: 워크로드 오케스트레이션
  • NIC 인터페이스: 요청을 올바른 NIC으로 라우팅
  • NMC(Near-Memory Compute) 블록: 128 bytes/cycle로 리덕션 수행

NMC는 HBM과 캐시 옆, 칩 가장자리에 배치되어 총 2.8 TB/s 이상의 리덕션 처리량을 제공합니다. 이는 I/O 대역폭의 2배 이상이며, AllReduce/ReduceScatter를 연산 그리드를 건드리지 않고 line-rate로 실행할 수 있게 해줍니다.

결과: 대형 GEMM과 집합 통신을 동시에 돌려도 연산 처리량 저하가 0.5% 미만입니다. GPU의 20%+ 저하와 비교하면 극적인 차이죠.

4. HCCL: 컴파일된 통신 모델

Meta의 통신 라이브러리 HCCL은 MTIA 300과 처음부터 공동 설계되었습니다.

# 개념적 흐름 (실제 API는 PyTorch c10d/torchcomms와 통합)
# 1. torch.compile로 집합 통신을 트레이싱
# 2. HCCL이 각 집합을 서브그래프로 컴파일
# 3. 워크큐 엔트리 배열 + 명시적 의존성으로 ME에 디스패치
# 4. 디바이스에 도달한 후 호스트는 완전히 개입하지 않음

# 스케일업/스케일아웃 대역폭 비대칭을 활용하는
# 토폴로지 인식 알고리즘 선택 → 랙 간 트래픽 최소화

호스트가 실행 중에 통신을 드라이빙하는 게 아니라, 각 집합을 완전한 서브그래프로 컴파일해서 ME에 넘기면 디바이스가 자율적으로 실행합니다.

5. 프로덕션 성능

  • 단일 랙 내 최대 940 GB/s 통신 대역폭
  • 150B 파라미터 프로덕션 추천 모델, 40개 가속기 환경에서
  • MTIA 300의 총 통신 시간이 동등 GPU 클러스터보다 3.9배 빠름

HCCL communication library dispatching collective operations to message engines on MTIA 300 chip without host CPU involvement Technical Structure Concept

MTIA 300 vs 전통 GPU 아키텍처 비교

항목전통 GPU (NCCL)MTIA 300 (HCCL)
네트워크 위치호스트 외부 NIC, PCIe 경유칩 패키지 내장 NIC 칩렛
통신 실행 주체SM(연산 코어)가 커널로 실행전용 Message Engine 16개
리덕션 처리SM 리소스 공유NMC가 2.8 TB/s 전담
호스트 개입실행 중 지속적 관여디바이스 도달 후 완전 자율
통신+연산 동시 실행 시 저하20% 이상0.5% 미만
랙 내 통신 대역폭모델/토폴로지 의존최대 940 GB/s
스케일업/아웃 분할하드웨어 고정네트워크 재구성으로 유연 조정

이 설계의 한계와 주의사항

  1. 추천 모델 특화: MTIA 300은 처음부터 ranking/recommendation 모델 학습에 최적화되어 있습니다. LLM 학습처럼 FLOPS 중심 워크로드에서는 GPU 대비 이점이 제한적일 수 있어요.
  2. 소프트웨어 생태계 종속: HCCL은 PyTorch c10d/torchcomms와 통합되지만, CUDA 생태계만큼의 범용성과 서드파티 라이브러리 지원은 아직 부족합니다.
  3. 벤더 락인: 자체 칩 + 자체 통신 라이브러리 조합은 성능 최적화에는 유리하지만, Meta 외부에서는 재현하거나 이식하기 어렵습니다.
  4. 표현된 수치의 맥락: '3.9배 빠름'은 특정 워크로드(150B 추천 모델, 40 가속기)와 특정 클러스터 구성에서의 결과입니다. 모든 워크로드에 일반화하기는 어렵습니다.

다음 단계 학습 방향

  • RDMA와 RoCEv2: NIC 칩렛이 사용하는 800 Gbps RDMA의 프로토콜 스택 이해
  • 집합 통신 알고리즘: Ring/Tree/Hierarchical AllReduce의 트레이드오프
  • torch.compile과 그래프 컴파일: HCCL이 어떻게 연산 그래프와 통합되는지
  • 이기종 학습(Heterogeneous Training): CPU 오프로딩과 1:1 CPU-to-accelerator 비율 활용

Performance comparison chart of MTIA 300 versus GPU clusters for 150B parameter recommendation model training Development Concept Image

마무리: '통신을 일급 시민으로' 라는 설계 철학

MTIA 300의 진짜 메시지는 특정 칩의 성능이 아닙니다. "통신을 나중에 처리할 부가 기능으로 취급하지 말자" 라는 아키텍처 철학이에요.

GPU는 범용성을 위해 연산과 통신이 같은 리소스를 공유하는 구조를 택했습니다. 이 선택은 LLM 시대에는 잘 맞았지만, 추천 모델처럼 통신 집약적인 워크로드에서는 명확한 한계를 드러냅니다. Meta는 그 한계를 하드웨어 레벨에서 해결했고, 그 대가로 소프트웨어 생태계의 범용성을 포기했습니다.

국내 개발자 관점에서 이 사례가 주는 시사점은 명확합니다. "범용 하드웨어 + 범용 라이브러리"가 항상 정답은 아니라는 것. 워크로드의 병목이 명확하다면, 그 병목을 하드웨어 레벨에서 제거하는 것이 소프트웨어 최적화보다 훨씬 큰 효과를 낼 수 있습니다.

특히 추론이 reasoning, agentic, long-context로 진화하면서 메시지는 더 작아지고, 더 자주, 더 지연에 민감해지고 있습니다. 네트워크를 '일급 시스템 제약'으로 취급하는 아키텍처가 앞으로 더 중요해질 겁니다.

함께 보면 좋은 글

참고: 본 분석은 Meta Engineering Blog의 MTIA 300 발표 자료를 기반으로 재구성했습니다.

본 콘텐츠는 신뢰할 수 있는 출처를 바탕으로 AI 도구를 활용하여 초안이 작성되었으며, 편집자의 검토를 거쳐 발행되었습니다. 전문가의 조언을 대체하지 않습니다.