제1부 GPU 아키텍처

1.3 칩 상위 구조 — GPC·TPC·SM 계층

1.3.1 이 장에서 배우는 것 / 선수 지식

1.1~1.2에서 GPU를 처리량 머신(SIMT·지연 은닉)으로 보는 사고틀을 익혔다. 이 장은 그 추상 모델이 실제 실리콘에서 어떤 물리적 계층 구조로 구현되는지 본다. GPU 칩 한 장은 평평한 코어 더미가 아니라 GPC → TPC → SM 으로 내려가는 트리다. 이 트리를 읽을 줄 알아야 "이 GPU가 얼마나 빠른가"를 데이터시트에서 계산할 수 있다.

배우고 나면 할 수 있어야 하는 것:

• GPU 칩 상위 구조(GPC·TPC·SM·메모리 파티션)를 다이어그램으로 그리고, 각 계층이 무엇을 묶는지 설명한다.
• "CUDA 코어 수"가 성능을 단순 의미하지 않는 이유를 클럭·SM 구성·메모리 대역폭·연산 종류로 분해한다.
• 자기 GPU의 SM 수·세대를 cudaGetDeviceProperties·deviceQuery로 읽는다.
• SM 수 × SM당 처리량 × 클럭으로 피크 FLOPS를 추정하고, 그것이 왜 실측 상한일 뿐인지 안다.
• compute capability(sm_XY)와 아키텍처 세대의 관계를 안다.

선수 지식: 1.1~1.2(SIMT·지연 은닉). SM 내부(워프 스케줄러·레지스터 파일·발행)는 1.4~1.6에서, 온칩 메모리는 1.7~1.8, HBM 대역폭은 1.9에서 깊이 다룬다. 이 장은 계층과 개수에 집중한다.

정직성(BK-03·S-5): 이 장의 구체 수치(SM 수, GPC당 TPC 수, 코어 수, 클럭, TFLOPS)는 세대·SKU·시점 의존이다. 같은 아키텍처라도 풀칩과 컷다운 SKU(수율·세그먼트에 따라 일부 SM·GPC 비활성)가 다르다. 절대 수치는 "확인 필요 — 해당 제품 데이터시트·화이트페이퍼 기준".

1.3.2 왜 계층이 있는가 — 평평한 코어 더미가 아닌 이유

SIMT 모델은 "수만 스레드를 워프 단위로 던지면 하드웨어가 지연을 은닉한다"였다. 그 "하드웨어"를 칩 한 장에 1만 개 넘는 연산 레인으로 평평하게 깔면 두 가지가 깨진다.

• 자원 공유의 지역성: 워프들이 협력하려면(공유 메모리·배리어·L1) 가까이 있어야 한다. 협력 단위마다 로컬 자원(레지스터 파일·공유 메모리·스케줄러)을 붙여야 한다 → 이 묶음이 SM.
• 고정 기능 블록의 비례 배치: 그래픽에는 래스터라이저·텍스처 유닛이 필요하고 SM 묶음마다 비례 배치된다 → SM을 텍스처 단위로 묶은 것이 TPC, 래스터 엔진 단위로 묶은 것이 GPC.

즉 계층은 "협력의 지역성 + 고정 기능의 비례 배치 + 칩을 타일로 복제해 키우는 설계 편의" 의 결과다. 엔비디아는 같은 SM 타일을 GPC 단위로 복제해 라인업 전체를 만든다. 그래서 개수만 다르고 구조는 닮아 있다 — 이것이 데이터시트를 "읽을" 수 있는 이유다.

큰 그림 — GPU 칩 한 장의 논리적 계층:

AI 관점에서 우리가 신경 쓰는 것은 거의 전적으로 SM의 수와 그 안의 연산 자원(특히 텐서코어), 그리고 그것을 공급하는 L2·메모리 대역폭이다. 래스터·텍스처 고정 기능은 그래픽용이며 딥러닝 워크로드에서는 직접 쓰이지 않는다. 그래서 이 장은 래스터/그래픽 블록은 간략히 다루고, SM 계층에 비중을 둔다.

1.3.3 계층 분해 — GPC·TPC·SM·메모리 파티션

1.3.3.1 SM (Streaming Multiprocessor) — 계산의 기본 단위

SM은 GPU의 "코어"에 해당하는 실질적 단위다. CPU 코어 하나가 페치·디코드·실행·레지스터·캐시를 가진 독립 엔진이듯 SM이 그렇다. SM 하나 안에는(세대마다 개수·배치 다름, 1.4):

• 다수의 CUDA 코어(FP32/INT 연산 레인) — 흔히 광고되는 "코어 수"의 출처.
• 텐서코어 — 행렬곱 누산(MMA) 전용. 딥러닝 성능의 본체(1.11).
• 워프 스케줄러 + 디스패치 유닛 — 보통 SM당 4개 처리 블록으로 나뉨(1.4~1.5).
• 레지스터 파일(흔히 SM당 64K개 32비트 레지스터 — 세대 의존), 공유 메모리/L1(통합·분할 가능 — 1.7).
• 로드/스토어 유닛, SFU, 텍스처 유닛.

핵심: 블록(thread block)은 하나의 SM에 배정되어 그 SM의 공유 메모리·레지스터를 쓴다. 블록이 SM을 넘나들지 않는 이유가 여기 있다. SM 점유율(occupancy)은 "SM의 레지스터·공유 메모리·워프 슬롯을 얼마나 채웠나"이며 1.6에서 계산한다.

1.3.3.2 TPC와 GPC — SM을 묶는 타일

• TPC = 보통 SM 2개 + 공유 텍스처/그래픽 자원. AI 관점에선 거의 "SM 2개"라는 카운팅 단위로만 의미가 있다. 일부 다이어그램은 TPC 계층을 명시하고, 일부는 GPC가 곧장 SM을 나열한다(세대·문서 표현 차이 — 확인 필요). 컴퓨팅만 신경 쓴다면 "TPC ≈ SM 2개"로 환산.
• GPC = 래스터 엔진 1개 + 여러 TPC. 칩을 키우는 "타일"의 단위다. 엔비디아는 GPC 수를 늘리거나 줄여 라인업을 만든다.

GPC 하나를 펼치면 (개수는 세대·SKU 의존 — 확인 필요):

총 SM 수 = (GPC 수) × (GPC당 TPC 수) × (TPC당 SM 수, 보통 2)

1.3.3.3 칩 전체 공유 인프라

GPC들 바깥에는 칩 전체가 공유하는 것들이 있다:

• L2 캐시: 모든 SM이 공유하는 마지막 온칩 캐시. 세대를 거치며 크게 늘었다(대역폭 압력 완화 — 1.8).
• 메모리 컨트롤러 + HBM/GDDR 파티션: 데이터센터 GPU는 HBM, 소비자는 GDDR. 대역폭이 메모리바운드 커널의 상한(1.9).
• GigaThread 엔진: 블록을 비어 있는 SM에 배정하는 칩 레벨 스케줄러.
• NVLink·PCIe: 칩 밖 인터커넥트(4.6).
• 데이터센터 칩은 MIG로 GPC·SM·메모리를 격리해 하나의 GPU를 여러 인스턴스로 분할한다(4.10).

계층 요약표 (절대 수치는 모두 "확인 필요"):

1.3.4 "CUDA 코어 수"가 성능을 단순 의미하지 않는 이유

스펙시트에서 가장 눈에 띄는 숫자가 "CUDA 코어 N개"다. 전문가가 이 숫자에 속지 않으려면 분해해야 한다.

(1) 코어 수는 FP32 레인 수일 뿐, 클럭과 곱해야 처리량이 된다. 피크 FP32 ≈ 코어 수 × 부스트 클럭 × 2(FMA). 코어가 2배라도 클럭·전력 한계로 부스트가 안 유지되면 그만큼 안 나온다.

(2) 딥러닝의 본체는 CUDA 코어가 아니라 텐서코어다. 학습·추론의 GEMM·컨볼루션은 텐서코어가 처리한다. 텐서코어 처리량(반정밀·FP8·INT8 행렬곱)은 FP32 코어보다 한~두 자릿수 높다. "CUDA 코어 수"는 텐서코어 성능을 거의 말해주지 않는다. AI 비교는 "FP16/BF16 TFLOPS"·"FP8 TFLOPS"·"INT8 TOPS"로 봐야 한다(1.11·1.13).

(3) 코어가 많아도 메모리가 데이터를 공급하지 못하면 유휴 상태다. 메모리바운드 커널은 코어 수가 아니라 HBM 대역폭이 상한이다(루프라인, 1.10). 코어 2배 + 대역폭 그대로 = 메모리바운드 구간 변화 거의 없음.

(4) "코어"의 정의가 세대마다 다르다. 어떤 세대는 FP32와 INT를 별도 레인으로, 어떤 세대는 한 레인이 겸한다. "코어 수" 직접 비교는 세대가 다르면 사과 대 오렌지다.

(5) SM 수가 더 정직한 1차 지표다 — 같은 세대 안에서. SM 하나의 구성이 같은 세대 내에서는 동일하므로 같은 아키텍처 세대 안에서는 "SM 수"가 코어 수보다 명확한 비례 지표다.

• 실효 성능 $\approx f($SM 수, SM당 연산 자원(텐서코어 세대·FP 레인), 부스트 클럭(전력·발열), 메모리 대역폭(L2·HBM, 1.9), 연산 종류(컴퓨트/메모리 바운드), 정밀도(FP32/BF16/FP8/INT8, 1.13), 점유율·커널 효율(1.6·2.14)$)$
• "CUDA 코어 수" 는 위에서 단 한 항만 건드린다.

견해: GPU를 AI용으로 비교할 때 1차 정렬키는 "코어 수"가 아니라 (a) 텐서코어 세대 + 대상 정밀도의 TFLOPS/TOPS, (b) 메모리 대역폭·용량, (c) SM 수(같은 세대) 순이다. 코어 수는 마지막에 본다.

1.3.5 compute capability와 아키텍처 세대

엔비디아 GPU의 하드웨어 기능 집합은 compute capability(CC) 버전 X.Y로 식별된다. 컴파일러 타깃으로는 sm_XY(예: CC 8.0 → sm_80). CC는 "이 GPU가 어떤 명령·기능(텐서코어 종류, 비동기 복사, 특정 정밀도, 공유 메모리 한도)을 지원하는가"를 정의한다.

• CC = 기능/명령어 집합 버전이지 성능 등급이 아니다. CC가 높다고 항상 빠른 것이 아니라 더 새 기능을 쓸 수 있다는 뜻이다.
• 아키텍처 세대(코드네임) 는 설계 세대 이름이고, 각 세대가 하나 이상의 CC에 대응한다. 대략적 대응(시점·확인 필요):

위 매핑·번호는 세대 교체로 바뀌고 새 세대가 계속 추가된다. 같은 세대라도 데이터센터칩과 소비자칩의 마이너 CC가 다를 수 있다. 반드시 CUDA Toolkit 문서의 "GPU Compute Capability" 표로 최종 확인(S-5).

왜 실무에서 중요한가:

• 컴파일 타깃: nvcc -arch=sm_90처럼 CC를 지정한다. 너무 높으면 구형에서 실행되지 않고, 너무 낮으면 신기능(FP8 텐서코어)을 못 쓴다. fat binary로 여러 sm_XY를 담거나 PTX(compute_XY)를 넣어 JIT 상위 호환을 얻는다(2.12).
• 기능 게이팅: cuDNN·CUTLASS·TensorRT가 "이 정밀도/커널은 CC ≥ N에서만"으로 게이트한다. FP8 경로가 안 켜지면 CC부터 의심.
• 라이브러리·프레임워크 지원: 특정 CC 미만을 드롭하기도 한다(시점 의존, 0.3).

1.3.6 워크스루 — 내 GPU의 SM 수·세대 읽기

목표: 자기 GPU의 아키텍처 좌표(SM 수, CC/세대, 클럭, 메모리)를 읽는다. 환경 셋업은 0.3 참조.

1.3.6.1 cudaGetDeviceProperties — 코드로 정확히 (권장)

cudaDeviceProp.multiProcessorCount가 SM 수다. nvidia-smi는 compute_cap·메모리·클럭은 주지만 SM 수는 직접 안 준다(이 도구의 한계).

// devinfo.cu  —  빌드: nvcc devinfo.cu -o devinfo  실행: ./devinfo
#include <cstdio>
#include <cuda_runtime.h>
int main() {
    int n = 0; cudaGetDeviceCount(&n);
    for (int d = 0; d < n; ++d) {
        cudaDeviceProp p; cudaGetDeviceProperties(&p, d);
        printf("GPU %d: %s\n", d, p.name);
        printf("  compute capability : %d.%d  (sm_%d%d)\n", p.major, p.minor, p.major, p.minor);
        printf("  SM 수 (multiProcessorCount) : %d\n", p.multiProcessorCount);
        printf("  부스트 클럭 : %.0f MHz\n", p.clockRate / 1000.0);
        printf("  글로벌 메모리 : %.1f GiB\n", p.totalGlobalMem / (1024.0*1024.0*1024.0));
        printf("  메모리 클럭 / 버스폭 : %d MHz / %d-bit\n", p.memoryClockRate / 1000, p.memoryBusWidth);
        printf("  L2 캐시 : %d KiB\n", p.l2CacheSize / 1024);
        printf("  SM당 최대 스레드 : %d\n", p.maxThreadsPerMultiProcessor);
        printf("  SM당 공유메모리 : %zu KiB\n", p.sharedMemPerMultiprocessor / 1024);
        printf("  SM당 레지스터 : %d\n", p.regsPerMultiprocessor);
    }
    return 0;
}

예상 출력(개략 — 값은 환경마다 다름):

GPU 0: NVIDIA <제품명>
  compute capability : 8.6  (sm_86)
  SM 수 (multiProcessorCount) : 84
  부스트 클럭 : 1860 MHz
  글로벌 메모리 : 24.0 GiB
  메모리 클럭 / 버스폭 : 9751 MHz / 384-bit
  L2 캐시 : 6144 KiB
  SM당 최대 스레드 : 1536
  SM당 공유메모리 : 100 KiB
  SM당 레지스터 : 65536

주의: cudaDeviceProp은 CUDA 코어 수를 직접 주지 않는다. "SM당 코어 수"는 CC별 상수 테이블(CUDA 샘플 헬퍼 _ConvertSMVer2Cores)로 곱해 얻는다 — 이것 자체가 "코어 수는 파생값일 뿐"이라는 1.3.4의 방증이다.

1.3.6.2 deviceQuery — CUDA 샘플로 한 번에

CUDA Samples의 deviceQuery는 위 속성을 보기 좋게 덤프하고 SM당 코어 수도 환산한다.

git clone https://github.com/NVIDIA/cuda-samples.git
cd cuda-samples/Samples/1_Utilities/deviceQuery
make && ./deviceQuery

핵심 줄(개략): (NN) Multiprocessors, (MMM) CUDA Cores/MP: <NN*MMM> CUDA Cores. 여기서 (NN)이 SM 수, CUDA Cores/MP가 SM당 코어 수(CC로 결정되는 상수), 둘의 곱이 광고용 "CUDA 코어 수"다. 두 경로가 일치하는지 교차 확인하라.

1.3.7 워크스루 — 피크를 추정하고 그 한계를 안다

읽은 좌표로 피크 처리량을 직접 추정한다. 핵심은 공식 암기가 아니라 "피크는 도달 못 하는 상한" 임을 체득하는 것.

1.3.7.1 FP32 피크(CUDA 코어 경로)

• FP32 피크 $=$ SM 수 $\times$ (SM당 FP32 레인 수) $\times$ 부스트 클럭(Hz) $\times 2$(FMA)
• 가정: SM 84개, SM당 FP32 레인 128, 클럭 1.86 GHz (가상의 값 — 산수 시범용)
  • $= 84 \times 128 \times 1.86\mathrm{e}9 \times 2 \approx 4.0\mathrm{e}13\,\mathrm{FLOP/s} =$ 약 $40\,\mathrm{TFLOPS}$ (FP32, 피크)

이 40 TFLOPS는 이론 상한이다. 실제로는 (a) 부스트 클럭이 전력·발열로 안 유지되고, (b) 명령 믹스에 FMA만 있는 것이 아니며, (c) 메모리가 데이터를 공급하지 못하면 코어가 유휴 상태다. 실측은 흔히 피크의 일부다.

1.3.7.2 텐서코어 피크 — AI가 실제로 보는 숫자

딥러닝 피크는 CUDA 코어가 아니라 텐서코어 기준이며 정밀도마다 다르다:

텐서코어 피크(정밀도 $P$) $\approx$ SM 수 $\times$ (SM당 텐서코어 수) $\times$ (텐서코어당 MMA 처리량@$P$) $\times$ 클럭

정밀도가 낮을수록(FP16 → FP8 → FP4) clk당 처리량이 커져 피크가 계단식으로 뛴다(1.11·1.13). 그래서 같은 칩이라도 "BF16 X / FP8 2X / FP4 4X TFLOPS" 식으로 표기된다(배수·값은 세대 의존). AI 성능 비교는 반드시 "어느 정밀도의 피크인가"를 명시해야 의미가 있다.

1.3.7.3 피크의 한계 — 루프라인 한 줄 예고

어떤 커널이 실제로 낼 수 있는 상한은 min(연산 피크, 대역폭 × 산술강도) 다(루프라인, 1.10). 산술강도가 낮은 커널은 연산 피크가 아무리 높아도 대역폭에 제한된다. SM 수 × SM당 처리량은 "연산 피크"라는 한쪽 벽만 준다. 이 장은 첫 벽을, 1.10이 둘째 벽을, 1.6·2.14이 효율을 다룬다.

1.3.8 중간 점검 (체크포인트)

• [ ] GPU 칩을 GPC → TPC → SM + 칩 공유(L2·메모리·GigaThread) 로 그리고 "총 SM = GPC수 × GPC당 TPC수 × TPC당 SM수(보통 2)"를 쓴다.
• [ ] cudaGetDeviceProperties의 multiProcessorCount가 SM 수, nvidia-smi는 SM 수를 직접 안 준다는 것을 안다.
• [ ] "CUDA 코어 수"가 AI 성능을 말해주지 않는 네 가지 이유를 제시한다.
• [ ] CC가 성능 등급이 아니라 기능 집합 버전임을 설명한다.
• [ ] 피크를 추정하고 그것이 도달 못 하는 상한인 이유를 제시한다.

증상 → 의심: nvidia-smi엔 GPU가 보이는데 cudaGetDeviceCount가 0 → 드라이버/런타임 불일치 또는 컨테이너 디바이스 미마운트(0.3). FP8/FP4 경로가 라이브러리에서 안 켜짐 → CC 미지원(1.3.5) 또는 빌드 타깃 누락.

1.3.9 트레이드오프 — "이 GPU가 내 워크로드에 맞나"

같은 세대 안에서 SKU(노트북·소비자·워크스테이션·데이터센터)는 SM 수·메모리 종류·NVLink 유무로 갈린다. 1차 기준을 워크로드별로:

• ① 대규모 학습 — 텐서코어 피크(BF16/FP8) + 메모리 용량·대역폭(HBM) + NVLink 도메인(4.6). SM 수보다 "고대역폭 메모리 + 인터커넥트"가 결정적 → 데이터센터 GPU.
• ② 추론·서빙(흔히 메모리바운드) — 대역폭·용량(KV 캐시!)과 정밀도 지원(FP8·INT8·FP4) 이 핵심. CC가 대상 정밀도를 지원하는지부터 확인(5.7·1.13).
• ③ 엣지·로보틱스(Jetson) — SM·코어 수보다 전력 예산(W)당 성능·메모리 용량이 1차. Orin·Thor는 SM 수가 적지만 그것이 목적(8.2·9.1).

비엔비디아 대안(정직, BK-04 경계): AMD·구글 TPU·인텔도 "코어/타일 수"가 아니라 해당 정밀도 피크 + 메모리 + 인터커넥트 + 소프트웨어 성숙도로 봐야 한다. 엔비디아의 실질 우위는 칩 스펙 단일 지표가 아니라 생태계(0.1).

견해: 데이터시트를 받으면 코어 수 칸을 가리고, 먼저 "대상 정밀도 텐서코어 TFLOPS/TOPS · 메모리 GB·대역폭 · 인터커넥트 · CC" 네 칸을 본다.

1.3.10 흔한 함정

• 세대 넘어 코어 수 직접 비교. 세대·정밀도·대역폭이 다르면 무의미. 같은 세대·같은 정밀도 피크로 비교하라.
• nvidia-smi로 SM 수를 찾으려 함. 안 준다. multiProcessorCount(코드) 또는 deviceQuery를 써라.
• CC를 성능 등급으로 오해. CC 8.9가 9.0보다 "구형 기능"일 수 있다(세대 분기). CC는 기능 집합 버전이지 빠르기 순서가 아니다.
• 풀칩 스펙을 자기 SKU로 착각. 화이트페이퍼의 "최대 SM 수"는 풀칩, 실제 제품은 컷다운일 수 있다. 항상 자기 디바이스의 multiProcessorCount로 확인.
• 피크를 실측처럼 인용. 피크는 상한. 메모리바운드 커널에 연산 피크를 들이대면 과대평가(1.10).
• 정밀도 명시 없이 TFLOPS 비교. FP32인지 BF16인지 FP8 텐서코어인지에 따라 한~두 자릿수 차이. 항상 정밀도를 명시하라.

1.3.11 연습문제

연습 1. "GPC 6개, GPC당 TPC 6개, TPC당 SM 2개"인 칩의 총 SM 수는? 컷다운 SKU가 SM 4개를 비활성했다면?

연습 2. nvidia-smi로 SM 수를 확인하려는 동료에게 무엇이 틀렸고 무엇을 써야 하는지 한 줄로.

연습 3 (직접 해보기). 1.3.6의 devinfo.cu를 자기 GPU에서 빌드·실행해 SM 수·CC·클럭·버스폭·L2를 적고, deviceQuery와 교차 확인하라.

연습 4. A는 "코어 10752개", B는 "코어 9728개"인데 B가 학습 처리량이 더 높다고 광고된다. 모순이 아닌 세 가지 이유를 들라.

연습 5. multiProcessorCount=80, SM당 FP32 레인 128, 클럭 1.5 GHz의 FP32 피크를 계산하고, 이를 실측으로 인용하면 안 되는 이유 두 가지를 제시하라.

1.3.12 요약 · 다음 장

• GPU 칩은 GPC(래스터+TPC) → TPC(SM 보통 2개) → SM 계층이고, 칩 전체가 L2·메모리 파티션·GigaThread를 공유한다. 계산의 실질적 단위는 SM이며 블록이 SM에 배정된다.
• "CUDA 코어 수"는 AI 성능을 말해주지 않는다: 텐서코어가 본체이고 클럭·대역폭·코어 정의·정밀도가 함께 정한다. 같은 세대 안에서는 SM 수가 명확한 비례 지표.
• 자기 GPU 좌표는 cudaGetDeviceProperties의 multiProcessorCount·major.minor로 읽는다.
• CC = 기능 집합 버전(성능 등급 아님). 세대 매핑·절대 수치는 시점 의존, 공식 문서 확인.
• SM 수 × SM당 처리량은 연산 피크(상한) 만 준다. 실제 성능은 메모리 벽·점유율·효율이 함께 정한다.

다음 장: 1.4 SM 내부 I — 처리블록·레지스터 파일. SM 하나를 열어 4개 처리 블록·레지스터 파일·연산 유닛 배치를 본다. 이 장의 "SM 수"가 1.4~1.6의 "SM당 실효 처리량·점유율"과 곱해져야 비로소 성능이 된다.