GPU 구조: 연산 장치와 메모리

지난 글에서는 GPU가 많은 연산 장치에 계산을 나누어 처리하며, 이 장치들이 일하려면 데이터도 함께 공급되어야 한다는 점을 살펴봤습니다. 이번 글에서는 GPU 내부로 들어가 어디에서 계산하고, 어디에 데이터를 보관하는지 알아보겠습니다. 이를 바탕으로 모델을 실행할 때 메모리의 어떤 특성을 살펴봐야 하는지도 알아보겠습니다. 여기서는 NVIDIA GPU를 기준으로 설명합니다.

GPU 전체에서 SM 내부로

NVIDIA GPU에는 SM(Streaming Multiprocessor)이 여러 개 있습니다. 각 SM은 명령을 실행할 순서를 정하고, 내부의 연산 장치를 사용해 계산합니다. 지난 글에서 여러 연산 장치를 포함한 묶음으로 그렸던 부분을 조금 더 구체적으로 살펴보겠습니다.

그림 1의 왼쪽에는 여러 SM과 L2 캐시가 GPU 칩 안에 있고, 칩 바깥에는 HBM(High Bandwidth Memory)이 있습니다. HBM은 모델의 가중치와 입력 등을 담는 메모리입니다. 각 SM은 필요한 데이터를 가져와 계산하며, L2 캐시는 여러 SM의 메모리 접근을 돕습니다. NVIDIA의 Blackwell Ultra 구조 설명에서도 여러 SM과 L2 캐시, HBM의 구성을 볼 수 있습니다. 실제 GPU는 두 개의 연산 칩을 연결해 하나의 GPU로 동작하기도 하지만, 그림에서는 기본적인 구성 요소에 집중하겠습니다.

오른쪽은 SM 하나를 확대한 모습입니다. 위쪽에는 명령 스케줄링과 실행을 제어하는 부분이 있고, 그 아래에는 CUDA Core와 Tensor Core가 있습니다. CUDA Core는 개별 값의 덧셈, 곱셈, 곱셈과 누적 같은 산술 연산을 수행합니다. 그림의 a × b + c에서 a, b, c는 각각 하나의 숫자입니다. Tensor Core는 작은 행렬 블록의 곱셈과 누적에 특화된 장치입니다. 옆의 A × B + C에서는 A, B, C가 행렬이며, A × B는 행렬 곱입니다.

CUDA Core로도 행렬 곱을 계산할 수 있습니다. 행렬 곱을 구성하는 개별 곱셈과 덧셈을 실행하는 방식입니다. Tensor Core는 이 규칙적인 계산을 행렬 블록 단위로 처리합니다. 따라서 두 장치의 차이는 병렬 계산을 하는지 여부가 아니라, 어떤 형태의 연산을 처리하도록 설계되었는지에 있습니다. 지원하는 자료형과 행렬 연산의 크기는 GPU 세대에 따라 달라집니다.

SM 안에는 연산 장치뿐 아니라 register, L1 캐시, shared memory처럼 데이터를 연산 장치에 더 가까이 보관하는 공간도 있습니다. 그림은 이런 구성 요소의 관계를 보여주기 위한 것으로, 실제 장치 수나 면적 비율을 나타내지는 않습니다. 이제 연산에 필요한 값이 각각의 공간에서 어떤 역할을 하는지 살펴보겠습니다.

데이터는 어디에 보관할까요?

모델의 모든 가중치와 계산 중인 값들을 연산 장치 바로 옆에 보관할 수는 없습니다. GPU는 큰 데이터를 담는 메모리와, 계산하는 곳에 가까이 둔 작은 저장 공간을 함께 사용합니다. 그림 2에서는 SM 두 개를 나란히 놓고, 여러 SM이 접근하는 공간과 각 SM 안의 공간을 구분했습니다.

아래쪽의 HBM은 모델 가중치, 입력, 중간 데이터 등을 보관하는 큰 저장 공간입니다. HBM에 저장된 데이터에 접근할 때 L2 캐시를 활용할 수 있습니다. 캐시는 접근한 데이터의 일부를 보관해, 다시 필요할 때 활용하는 메모리입니다. 필요한 데이터가 L2 캐시에 남아 있으면 HBM에서 다시 가져오는 일을 줄일 수 있습니다. L2 캐시는 여러 SM이 공통으로 사용하는 반면, L1 캐시는 각 SM 안에 있습니다.

Shared memory는 개발자가 데이터의 배치와 재사용을 직접 제어할 수 있는 저장 공간입니다. 예를 들어 여러 계산에서 같은 입력 값을 반복해서 사용한다면, 개발자는 그 값을 shared memory에 가져온 뒤 함께 사용하도록 코드를 작성할 수 있습니다. 캐시도 데이터를 재사용하는 데 도움을 주지만, 일반적인 캐시 동작에서는 하드웨어가 데이터를 보관하고 교체합니다. Shared memory에서는 어떤 데이터를 가져오고 언제 재사용할지를 개발자가 명시적으로 정할 수 있습니다.

그림에서 L1 캐시와 shared memory를 하나의 테두리 안에 그린 이유는, NVIDIA GPU에서 두 기능이 GPU 칩 위에 있는 온칩 저장 자원을 나누어 사용하는 구조를 표현했기 때문입니다. 사용하는 물리적 자원은 연결되어 있지만, 프로그램이 활용하는 역할까지 같은 것은 아닙니다. NVIDIA의 CUDA 가이드는 GPU 세대별로 통합 저장 공간의 크기와 shared memory에 할당할 수 있는 용량을 정리합니다.

위쪽의 register는 개별 계산에 사용할 값과 중간 결과를 담는 작은 저장 공간입니다. 연산 장치는 register에 준비된 값으로 산술 연산을 수행하고, 그 결과를 다시 register에 담아 이어지는 계산에 사용할 수 있습니다. HBM에 있는 데이터 전체를 register에 올려놓는 것이 아니라, 실행 중인 계산에 필요한 값들을 보관합니다.

이 저장 공간들을 모두 순서대로 거쳐야 하는 것은 아닙니다. 특히 shared memory는 데이터를 명시적으로 배치해 활용하는 공간이므로, 모든 계산이 반드시 거쳐야 하는 단계는 아닙니다. 그림 2의 연결선은 저장 공간의 위치와 접근 관계를 나타냅니다.

실제 크기는 얼마나 차이가 날까요? 아래는 Blackwell B200의 SM 148개 구성을 기준으로, 앞서 소개한 공간의 용량을 비교한 표입니다. SM 수는 NVIDIA의 B200 플랫폼 사양, 메모리 용량은 Blackwell 가이드를 기준으로 했습니다. SM마다 있는 공간의 GPU 전체 값은 SM당 용량에 148을 곱했습니다.

KiB는 1,024바이트, MiB는 1,024 KiB입니다. L2와 HBM은 NVIDIA 자료의 MB·GB 표기를 따랐습니다. L1 캐시와 shared memory의 용량은 통합 공간에 포함되므로 따로 더하지 않습니다. 또한 register가 GPU 전체에 37 MiB 있다고 해서, 한 SM이 그 공간을 모두 사용할 수 있는 것은 아닙니다. 각 SM에 나뉘어 있는 용량을 합한 값입니다.

숫자에서 눈여겨볼 점은 규모의 차이입니다. 연산 장치에 가까운 공간은 SM당 수백 KiB인 반면, HBM은 GPU 하나에 수백 GB를 담습니다. 더 최근의 B300은 GPU당 288 GB의 HBM3e를 제공합니다. 큰 모델의 데이터를 HBM에 담고, 그중 계산에 필요한 일부를 연산 장치 가까이 가져와 사용하는 이유를 이 차이에서 볼 수 있습니다.

두 값을 더할 때 일어나는 일

앞에서 살펴본 구조를 간단한 계산에 연결해 보겠습니다. 메모리에 a = 2, b = 3이 저장되어 있고, 두 값을 더한 c = 5를 메모리에 저장하려고 합니다. 그림 3에서는 값의 흐름에 집중하기 위해 캐시와 데이터 이동을 담당하는 장치의 세부 동작을 생략했습니다.

①에서는 메모리의 입력 값을 읽어 register에 준비합니다. 입력이 GPU 메모리에 저장되어 있다는 것과, 연산 장치가 그 값을 바로 사용할 수 있다는 것은 다릅니다. 계산을 실행하려면 필요한 값이 도착해야 합니다.

②에서는 CUDA Core가 준비된 두 값을 더합니다. 덧셈 명령을 실행하면 ③처럼 계산 결과 5가 register에 놓입니다. 입력을 읽어오는 것, 가져온 값으로 계산하는 것, 그 결과를 보관하는 것을 구분해 볼 수 있습니다.

④에서는 register에 있는 결과를 메모리에 저장합니다. 이 예시에서는 결과를 저장하고 끝내지만, 뒤에 다른 계산이 이어진다면 register의 값을 그대로 활용할 수도 있습니다. 모든 산술 연산이 끝날 때마다 결과를 HBM에 저장해야 하는 것은 아닙니다.

모델의 행렬 곱도 많은 입력과 가중치를 읽고, 곱셈과 덧셈을 수행하며, 결과를 보관하는 과정으로 이루어집니다. 이때 입력을 가져오는 양과 중간 결과를 저장하는 양은 계산을 어떻게 구성하는지에 따라 달라집니다. GPU의 실행을 이해하려면 연산 장치의 계산 능력과 함께, 필요한 데이터를 가져오고 결과를 저장하는 과정도 살펴봐야 합니다.

모델을 실행할 때 메모리에서 살펴볼 것

GPU에서 모델을 실행하려면 우선 모델과 실행에 필요한 데이터가 메모리에 들어가야 합니다. 데이터가 들어간 뒤에는 연산 장치가 계산하는 속도에 맞춰 필요한 값을 공급할 수 있어야 합니다. 그리고 요청한 값이 도착하기까지 기다리는 시간도 있습니다. 그림 4의 용량, 대역폭, 접근 지연은 각각 이런 문제를 이해하는 데 필요한 특성입니다.

큰 모델을 GPU에 올리고 싶어도 메모리가 부족하면 가중치 전체를 담을 수 없습니다. 예를 들어 가중치가 1,000억 개이고 각각을 2바이트로 저장한다면, 가중치만 약 200 GB가 필요합니다. 여기에 입력과 중간 결과를 위한 공간도 더 있어야 합니다. 이때 먼저 확인하는 것이 저장할 수 있는 데이터의 양인 용량(capacity)입니다. 그림의 첫 번째 패널처럼 용량이 커지면 더 많은 데이터를 담을 수 있지만, 담을 수 있다는 것만으로 계산이 빠르게 진행되는 것은 아닙니다.

모델이 메모리에 들어가더라도, 많은 연산 장치가 계속 일하려면 필요한 입력과 가중치가 충분히 공급되어야 합니다. 연산 장치가 처리할 수 있는 양에 비해 데이터 공급이 부족하면 계산 능력을 충분히 활용하지 못합니다. 이때 중요한 것이 단위 시간에 전달할 수 있는 데이터의 양인 대역폭(bandwidth)입니다. 보통 GB/s나 TB/s로 표시하며, 그림의 두 번째 패널처럼 같은 시간에 더 많은 데이터가 도착할수록 대역폭이 높습니다. 필요한 데이터 이동량에 비해 대역폭이 부족하면 실행 속도가 제한될 수 있습니다. 제품 사양의 최대 대역폭을 실제로 얼마나 활용하는지는 메모리에 접근하는 방식과 실행 상황에 따라서도 달라집니다.

그렇다면 가져올 데이터의 크기를 대역폭으로 나누면, 계산을 시작할 때까지 기다릴 시간을 알 수 있을까요? 이 계산은 많은 데이터를 전달하는 데 필요한 시간을 가늠하는 데는 도움이 되지만, 요청 하나의 대기 시간을 전부 설명하지는 못합니다. 필요한 값이 캐시에 있는지, HBM까지 가서 읽어야 하는지에 따라 거치는 과정이 달라집니다. 메모리 내부에서 데이터를 읽을 준비를 하는 데도 시간이 들고, 다른 요청의 처리를 기다려야 할 수도 있습니다. 데이터가 도착할 때까지의 시간은 데이터 크기와 대역폭만으로 결정되지 않습니다. NVIDIA의 메모리 연구에서도 요청 대기열과 DRAM 내부 접근을 함께 다룹니다.

이처럼 데이터를 요청한 뒤 사용할 수 있을 때까지 걸리는 시간을 접근 지연(memory access latency)이라고 합니다. 그림의 세 번째 패널은 요청 하나가 얼마나 기다리는지 보여줍니다. 앞서 두 값을 더하는 예시에서도 입력 하나가 아직 도착하지 않았다면 그 덧셈은 실행할 수 없습니다. 요청한 데이터의 양이 작더라도, 그 값을 기다리는 시간이 계산의 진행을 늦출 수 있는 것입니다.

여러 요청을 겹쳐 처리하면, 각 요청에는 기다리는 시간이 있어도 데이터는 계속 도착할 수 있습니다. 이 경우 일정 시간에 전달되는 데이터의 총량은 많지만, 요청 하나의 접근 지연이 그만큼 짧아지는 것은 아닙니다. 대역폭은 여러 요청을 통해 공급할 수 있는 데이터의 양을, 접근 지연은 각 요청의 대기 시간을 설명합니다. 두 특성은 서로 영향을 주기도 하지만 같은 의미는 아닙니다.

따라서 GPU 메모리를 볼 때는 필요한 데이터를 담을 용량이 있는지, 데이터를 충분한 양으로 계속 전달할 수 있는지, 요청한 값이 도착하기까지 얼마나 기다리는지를 구분해야 합니다. 연산 장치가 많아도 필요한 데이터가 아직 도착하지 않았다면 그 값을 사용하는 계산은 진행할 수 없습니다.

이번 글에서는 GPU 안의 연산 장치와 저장 공간, 그리고 데이터를 읽고 계산해 저장하는 흐름을 살펴봤습니다. 다음 글에서는 모델에서 사용하는 원소별 연산, reduction, 행렬 곱을 다시 살펴보며 어떤 계산을 동시에 진행할 수 있고, 어디에서 결과를 모아야 하는지 알아보겠습니다.