▲

GPU를 이해하는 방법

 (jax-ml.github.io)
6P by GN⁺ 5일전 | ★ favorite | 댓글 1개
  • GPU는 현대 머신러닝에서 핵심적인 역할을 하며, 고속 행렬곱 연산에 특화된 수많은 Streaming Multiprocessors(SMs) 와 HBM(고대역폭 메모리) 가 결합된 구조임
  • GPU의 SM은 Tensor Core(행렬곱)와 CUDA Core(벡터 연산)로 나뉘며, 대규모 병렬 연산과 유연한 프로그래밍을 지원함
  • GPU와 TPU는 내부 구조와 네트워크 구성 면에서 차이가 있으며, GPU는 범용성과 확장성이 높지만, 최적 성능 달성에는 더 많은 고려가 필요함
  • 노드(Node) 내에서는 NVLink 및 NVSwitch로 GPUs 간 초고속 통신이 가능하고, 노드 간에는 InfiniBand 등의 네트워크로 연결되어 대규모 분산 학습에 대응함
  • GPU에서의 집합 연산(Collectives) (예: AllReduce, AllGather 등)은 하드웨어 구조와 네트워크 계층에 따라 성능이 크게 달라지며, 이론상 밴드위스보다 실질적으로 낮은 경향이 있음

GPU란 무엇인가?

  • 최신 ML(머신러닝) GPU(예: H100, B200)는 행렬곱 연산에 특화된 Streaming Multiprocessor(SM) 수십~수백 개와 빠른 HBM 메모리가 결합된 구성임
  • 각 SM에는 Tensor Core(행렬곱), Warp Scheduler(벡터 연산), SMEM(온칩 캐시)이 있음
  • TPU와 달리 GPU는 100개 이상의 SM을 통해 더 유연하고 대규모 병렬 처리가 가능함

SM 세부 구조

  • SM은 4개의 서브파티션으로 나눠지고, 각 서브파티션에는 각기 Tensor Core, CUDA Core(벡터 연산), Warp Scheduler, 레지스터 파일 등이 존재함
  • CUDA Core는 벡터 산술 연산(SIMD/SIMT) 담당, Tensor Core는 행렬곱에 특화
  • Tensor Core FLOPs가 압도적으로 크며, 낮은 정밀도의 연산에서는 처리 속도가 더욱 빨라짐
  • 최신 GPU(예: B200)는 대형 TMEM이 추가되어 대용량 Tensor Core 입력 지원

CUDA Core의 유연성

  • GPU의 CUDA Core는 SIMT(Single Instruction Multiple Threads) 모델을 사용하여, 한 명령어를 여러 쓰레드에 병렬 실행함
  • 각 쓰레드는 독립된 명령 포인터(프로그램 카운터)를 가져 조건 분기 등 유연성 제공하지만, 워프 내 명령 분기(divergence)가 많으면 성능 저하 발생
  • 각 CUDA Core는 개별 상태와 메모리 접근이 자유로움 (TPU는 연속된 메모리만 처리 가능)

스케줄링/병렬성

  • SM은 다수 워프(최대 64개)를 스케줄링해 동시 실행하며, 각 워프 스케줄러는 한 번에 하나의 프로그램 실행
  • 이 구조 덕분에 GPU는 상당히 유연하면서도 높은 동시 처리가 가능함

GPU 메모리 구조

  • GPU는 HBM이 가장 크며, 그 외에도 L2/L1(SMEM)/TMEM/레지스터 등 메모리 계층 구조를 가짐

최신 GPU 사양 요약

  • SM(Streaming Multiprocessor) 개수, 클럭, 메모리, FLOPs, 대역폭(BW) 등이 모델마다 상이함
  • 메모리 용량(HBM) 및 대역폭, FLOPs(흑체/정수/저정밀) 등은 세대가 거듭될수록 증가함
  • 표(생략)에서 주요 특징: Blackwell(B200)은 HBM 192GB, HBM BW 8.0TB/s, FP8 FLOPs 4.5e15 등
  • 각 세대별로 레지스터 및 온칩 캐시(SMEM) 용량, TMEM 추가 등 하드웨어 발전이 뚜렷함

GPU/TPU 비교

  • GPU는 범용적이면서도 많은 소형 SM(병렬 유닛)으로 모듈화되어 있으며, 하드웨어 제어가 많아 이해/최적화가 어려움
  • TPU는 소수 대형 Tensor Core 및 많은 벡터 ALU(VPU)로 구성, 단일 스레드 제어 방식으로 하드웨어 단순/비용 절감 가능
  • 이로 인해 TPU는 컴파일러 최적화가 필수이며, GPU는 여러 커널을 독립 실행 가능해 사용 용이성 높음
  • 성능/가격 측면에서 최근 H200 GPU가 TPU v5p보다 FLOPs/s 2배, HBM 1.5배, 가격은 2.5배 정도임
  • TPU는 VMEM(온칩 캐시)이 많고 빠르며, LLM 모델 추론 등에서 큰 이점 발생 가능

GPU 하드웨어 퀴즈 Q&A 요점

  • H100의 fp32 CUDA 코어는 총 16,896개(132 SM x 4 x 32), B200은 18,944개
  • 벡터 연산 FLOPs는 H100 기준 최대 33.5TFLOPs/s 수준, Tensor Core의 행렬곱 FLOPs(990TFLOPs/s)에 비해 30배 낮음
  • H100의 L1/SMEM, 레지스터 합산 용량은 66MB, TPU VMEM은 120MB
  • Bandwidth(대역폭)와 FLOPs의 비율(이론상 연산 집약도)은 H100/B200 모두 280-300 정도로 TPU와 유사

GPU 네트워킹(통신 구조)

노드/클러스터 구조

  • GPU 노드는 대개 8개 GPU로 묶여 NVLink(초고속) 및 NVSwitch(스위치)로 Full Bandwidth 직접 연결됨
  • 노드 간에는 InfiniBand(Ethernet 등)를 사용해 스케일 아웃 가능
  • 최신(Blackwell) GPU는 Node 72개까지 확장 가능한 구조

네트워크 계층별 특징

  • 노드 내부(NVLink 영역): 각 GPU당 egress 450GB/s(H100), 900GB/s(B200), NVSwitch 당 최대 1.6TB/s
  • 노드 상위(InfiniBand Leaf/Spine): Leaf Switch(8개)~Spine Switch(16개) 구조, GPU~GPU간 이론상 400GB/s Full Bandwidth 유지
  • SuperPod와 같은 대형 아키텍처에서는 1024개 GPU(128노드), GB200(72GPU Node)는 9배 증폭된 대역폭(3600GB/s)

네트워크 성능 요점

  • 이론상 네트워크 구조(Full Fat Tree)는 노드~노드 간에도 최대 대역폭을 제공하도록 설계
  • 하드웨어 포트 제약 등으로 1024~4096GPU로 확장 시 Spine/Core Switch를 더 추가하는 계층화 방식 사용
  • Node 내 밴드위스(450GB/s) → Node 간 밴드위스(400GB/s) 로 전환 = 집합 연산에서 성능 차이

집합 연산(Collectives) 구조

  • AllGather, AllReduce(합산), AllToAll(분산) 등 고수준 집합 연산 지원
  • Node 내에서는 NVLink로 직접 연결되어 최적 성능 가능(이론상 B/W), Node~Node간은 InfiniBand 경유
  • NVIDIA의 NCCL, NVSHMEM 라이브러리 활용

집합 연산 성능 분석

  • AllGather/ReduceScatter: B/W(450GB/s H100 기준)로 링(Ring) 방식 구현, 작은 메시지일 때는 트리(Tree) 방식도 가능
  • AllToAll: 각 GPU가 직접 상대 GPU에 전송, B/W에서 N으로 나누는 방식이어서 Node 내에서 이론상 2배 빠름
  • 실제 측정 결과 AllReduce에서 370GB/s 수준으로, 하드웨어 최대치에는 미치지 못함
  • TPU 대비 대용량(수십 MB ~ GB)에서야 하드웨어 Peak Bandwidth에 근접

종합 요약 및 인사이트

  • GPU는 범용성, 확장성이 강점이지만, 하드웨어/네트워크 구조에 따라 성능 최적화 난이도와 관찰 가능성이 TPU보다 높음
  • 네트워킹(Intra-Node/NVLink/InfiniBand/Leaf/Spine 등)이 대규모 학습 성능의 핵심이고, 실질 밴드위스와 이론 밴드위스 차이 주의 필요
  • 집합 연산 및 네트워크 구조에 대한 이해가 초대형 분산 모델 학습/서빙에서 필수 요소임
  • 실질적인 벤치마크와 하드웨어 세부 구조 이해를 바탕으로 성능 병목 구간/최적 조건을 파악하는 프로세스가 요구됨
▲
GN⁺ 5일전  [-]
Hacker News 의견

  • 나는 이 글과 여러 문서들이 다소 불분명하다고 느꼈음, 특히 GPU에 대해 설명하면서 용어가 애매하게 사용되는 경우가 많음, 예를 들어 첫 번째 이미지에 ‘Warp Scheduler’가 TPU의 VPU와 비슷한 SIMD 벡터 유닛이라고 설명하면서 32개의 ‘CUDA Core’가 있다고 하는데, 여기서 ‘CUDA core’가 무엇인지 명확하게 설명하지 않아 설명의 핵심 사물을 제대로 전달하지 못함, 이런 복합적인 오류로 인해 초심자나 개념을 익히려는 독자들은 여전히 이해가 어렵고 반면 어느 정도 개념을 이해하고 있는 사람들에게는 이미 아는 내용임, 초안이던 내용이라도 공개할 땐 용어 하나하나를 외과 수술처럼 정확하게 다뤄야 하고, 용어를 혼동하거나 섞어서 쓰지 않아야 함, 아날로지를 쓸 땐 신중해야 한다는 조언임, 그리고 MXU(매트릭스 연산 유닛) 같은 용어는 부연설명이나 하이퍼링크를 통해 쉽게 찾을 수 있도록 해야 한다고 생각함, 요즘은 AI에게 이 역할을 시킬 수도 있는데, 이는 다소 슬픈 일임

    • 저자로서 직접 답변함, 지적에 대체로 동의함, 설명에서 정확성을 확보하려 할수록 ‘도덕적 진실’과의 균형에 늘 고민이 있음, 예를 들어 “NVIDIA가 CUDA Core라 부르는 SIMD(단일 명령-다중 데이터) 벡터 유닛 32개(ALU)로 구성된 TPU VPU와 유사한 유닛"이라고 쓸 수도 있지만, 이러면 문장이 길어지고 벡터 유닛 등 용어 정의는 또 빠질 수 있음, 각주를 많이 쓰려 노력하지만, 독자가 일일이 클릭할 거라 기대하기도 어렵고, 사이드노트는 HTML에서 구현 난이도가 있음, MXU 같은 용어는 전장(前章)에서 이미 정의했지만, 독자가 모든 장을 꼭 읽으리라 가정하는 건 무리라 생각함, "Warp Scheduler"도 실제로는 여러 역할(스케줄러, 디스패치 유닛, SIMD ALU)을 모두 뜻하는 등 용어 자체의 모호함이 있지만, NVIDIA가 복합 유닛에 별도 명칭을 붙이지 않아 생기는 일임, 앞으로 더 개선하려힘, 쉽지 않은 타협의 연속임

    • LLM은 이런 용어 연결의 난관을 풀기 꽤 좋은 도구임, 한 용어를 찾아도 연쇄적으로 모르는 용어가 나올 때 어디서부터 공부하면 되는지 잘 안내해 줌

    • 구글 TPU 시스템 아키텍처 문서에 거의 다 나와있음

    • 진지하게 묻고 싶은데, 컴퓨터 아키텍처에 대한 적정 수준의 배경지식은 어느 정도가 적합한지 궁금함, SIMD 개념 자체가 이미 50년이 넘었음, 해당 자료 서두에선 LLM과 Transformer 아키텍처에 대한 이해는 기본으로 보고 있지만, 컴퓨터 작동 원리에 대한 이해는 없어도 된다고 하면서도, CPU 기본 동작 원리는 알아야 하는 게 아닌가란 생각임

    • 해당 콘텐츠는 머신러닝 분야에 종사하는 사람을 대상으로 쓰인 책의 한 챕터임

  • 나는 오픈 소스가 아니거나 여러 공급업체가 교차 사용 가능한 기술이 아니면 투자한 시간을 정당화하기 매우 어렵다고 느낌, Nvidia 칩 활용을 잘 하는 일이 예전의 SAP ABAP 컨설턴트 같은 것이라 여겨짐, 물론 이 분야에서 돈이 많이 벌리긴 하지만, 역사적으로 이런 전문성은 그리 득이 아니었다고 생각함

    • 나도 10년 전 대학 때 CUDA 수업을 일부러 건너뛰며 같은 생각을 했었음

    • CUDA는 하드웨어 아키텍처와 이를 위한 소프트웨어 스택 두 가지가 있음, 소프트웨어 스택은 폐쇄적이어서 직접 저수준 최적화를 할 계획이 아니면 굳이 신경 쓸 필요 없음, 하지만 하드웨어 구조는 배울 가치가 충분함, 모든 GPU들은 기본적으로 비슷한 방식으로 동작하고(CUDA 구조는 2007년부터 기본 철학은 그대로임), 이러한 아키텍처가 셰이더 언어나 GPU 추상화 방식에 큰 영향을 미침, 쓰레드 스케줄링, 워프, 사설/공유 메모리 구조 등 자세한 특성을 이해하면, 알고리즘을 하드웨어 실행 모델에 더 잘 맞춰 막대한 연산 성능을 활용할 수 있음

    • 병렬 컴퓨팅의 원리와 하드웨어, 드라이버 레벨에서의 작동 방식은 상당 부분에 일반성이 있음을 강조하고 싶음, 일부는 특정 플랫폼 특화 내용이지만 상당수는 폭넓게 응용 가능함, 일반성만 맹신하다 보면 오히려 손해 보기도 함, 오픈 소스 여부와 범용/특화성은 별개로도 볼 수 있으니, 더 넓은 탐구가 필요함

    • 전환이 그리 어렵지 않음, 이미 OpenMP나 MPI 코드를 짰던 사람이라면 CUDA 입문 자체는 쉬웠음, CUDA에서 성능 최적화 방법을 배우면 CPU 병렬 코드도 빨라지므로 본질적으로 기존 컴퓨팅 모델의 진화형임

    • 나도 어릴 때 IBM PC/MS-DOS로 프로그래밍 배웠는데 둘 다 오픈 소스가 아니었지만, 지금도 크게 도움이 되고 있음

  • “Quiz 2: GPU nodes” 부분의 계산이 부정확하다고 생각함, 실제로는 GPU나 스위치마다 포트가 제한돼 있어서 이론상 가능한 450GB/s가 확실히 제공되지 않으며, 그래서 주요 클라우드나 레퍼런스 시스템에서 3.2TB/s이 제공되는 것임, 만약 3.6TB/s가 가능하다면 분산 링 워크로드에서 병목이 발생함, 한편 구직 중임

    • 나도 이 부분 오랜만에 생각해 봤는데, 클라우드 업체들이 3.2Tbps만을 광고하는 이유는 노드의 IB(InfiniBand) 네트워크 연결 한계 때문임, DGX 기준으로 H100 한 개당 Connect-X 7 NIC 1개씩이 400Gbps까지 제공함, 8개의 GPU x 400Gbps = 3.2Tbps임, Quiz 2는 표현이 헷갈리게 되어 있는데 내 생각엔 노드 내 GPU 간 연결을 의미하는 것 같고, 노드 간 네트워크는 아님

  • 이 시리즈 전체가 정말 좋았음, 현대 AI 워크로드의 이론적 한계를 설명하면서 아키텍처와 병렬화 등 기술적 원리를 쉽게 풀어줌, TPU 중심이긴 하지만 대체로 다른 분야에도 적용할 수 있어 활용성이 높음

  • 타입이 확실한 언어로 수치 집약적인 코드를 최대한 최적화하고, 그럼에도 빨라야 한다면 GPU 옵션을 검토하는 게 순서임, 내 경험상 GPU로 대략 8배는 빨라짐, 웹 응답 4초를 0.5초로 줄일 수 있으면 어마어마한 변화임, 하지만 사실상 웹소켓으로 지연 표시(스피너)하거나 백그라운드 캐시를 쓰는 편이 더 쉽기도 함, 그리고 클라우드에서 GPU 돌리는 건 비용이 많이 드는 점도 고려해야 함

  • nvshmem이 ML 분야에서 이렇게 각광받는 것이 흥미로움, 반면 동일 기능의 MPI는 예전 과학 시뮬레이션 세계에선 그리 만족스럽지 않았음, 참고로 나는 여러 노드에 걸친 장거리 힘 계산처럼 난도가 높은 작업을 주로 했었음

  • 왜 Nvidia는 TPU를 자체 개발하지 않았는지 궁금함

    • 그럴 필요가 없음, 이미 하드웨어와 프로그래밍 모델 시장 지배적 위치에 있고, TPU는 오히려 프로그래밍 난이도가 더 높음

    • 사실상 이 기사에서 설명하듯, Nvidia GPU 성능의 90%가 행렬 연산 유닛에서 나오기 때문에 거의 TPU와 유사한 구조임, 약간의 성능은 포기하지만 훨씬 더 유연한 컴파일러 생태계를 확보함

  • 아직까지 Nvidia에서 이런 수준의 리소스를 공식 제공하지 않은 게 놀라움, 결국 3rd party들이 하드웨어를 역공학해서 실제로 쓸 만한 개념도로까지 정리하는 상황이 됨, Nvidia의 진짜 동기가 궁금함, 만약 단순 마케팅만 생각한다면 성공한 셈이지만, 나는 엔지니어링 컬처엔 의문이 남음

    • 실시간 렌더링 엔지니어 입장에서 항상 그랬음, NV는 세대간 변화 포착을 경쟁사들이 못하게 하려고 대부분 정보를 꽁꽁 숨김, 다른 벤더들도 다르지 않음, 게임에서는 NDA 맺고 세부 아키텍처 정보를 더 자세히 제공하긴 하는데 그 외엔 Intel 빼고 완전한 공개 사례는 못 봤음

    • Nvidia는 실제로 타사 대비 정말 우수한 공식 문서가 많음

    • 왜 그렇게 느꼈는지 궁금함, 사실 이 기사에 있는 내용 대부분은 Nvidia 공식 문서를 거의 그대로 가져온 것으로 보임, 예를 들어 H100 다이어그램도 실제로는 H100 whitepaper에서 출처 표시 없이 복사된 것임, 연산량, 대역폭 정보도 전부 공식 whitepaper와 CUDA C++ 가이드 5,6,7장이 이미 다 다루고 있음, 외부에서 더 간략하게 정리하고 해석 덧붙이는 건 가치 있지만, Nvidia 공식 자료 없었으면 이런 기사 자체가 힘들었을 것이니 근거 없는 추측·의심은 좀 과함

    • Nvidia가 평범한 수준의 문서만 공개함으로써 cuBLAS, cuDNN 같은 폐쇄형 라이브러리만 빠르고, 이로 인해 벤더 종속이 심해지는 구조임, 덕분에 다른 업체가 역공학으로 쫓아오기도 어렵게 만듦

    • 여러 정황을 볼 때 Nvidia는 NDA 서명자와 VIP에게만 맞춤형 자료를 제공하고 공공용 공식 매뉴얼 공개는 일부러 소홀히 하는 경향이 있음, 그게 상업적으로 자신들에게 유리하니까 그렇게 하는 것 같음, API 공식 문서조차 장벽을 치면 평범한 개발자들은 접근 어려워도 AI, GPU 자체, 소프트웨어, VIP용 문서 등 전체 생태계 판매에 집중하고 있어서 아예 일반 개발자에겐 신경을 덜 쓰는 셈임

  • 우리가 구조 다이어그램을 볼 때 실제 하드웨어를 완벽히 반영한 것이 아니란 점을 반드시 유념해야 함, Nvidia는 다이어그램의 블록이나 구성 요소가 실제로 존재함을 보장하지 않고, 어디까지나 GPU와 SM 구조를 생각할 때 참고용 멘탈 모델로만 제공함, 예를 들어 실제 SM에 기능 유닛이 몇 개나 있는지, ‘tensor core’ 자체가 독립된 하드웨어인지 아니면 여러 유닛의 조합 결과인지, warp 이하 단위의 세부 동작도 공식적으로는 알 수 없음

    • 흥미로운 의견임, 그런데 실제로는 SM이 tensor core 연산 중에는 블로킹되어 있다는 점이 동일한 FPU가 tensor 연산까지 모두 처리한다고 해석할 수 있지 않을까란 생각임

  • 정말 환상적인 리소스임, 덕분에 좋은 내용 얻게 됨

답변달기