딥러닝이 느린 진짜 이유, GPU 활용률 30%에서 90%로 끌어올리는 첫 원칙

딥러닝 모델, 왜 이렇게 느릴까요?

딥러닝을 좀 해보신 분이라면 한 번쯤 이런 경험 있으실 거예요. "비싼 GPU 사놨는데 왜 학습이 이렇게 느리지?" 또는 "코드 한 줄 바꿨더니 속도가 10배 차이 나네?" 같은 거요. 메타(구 페이스북)의 PyTorch 팀에서 일하는 호레이스 헤(Horace He)가 쓴 "Making Deep Learning Go Brrrr from First Principles"라는 글이 다시 회자되고 있는데, 2022년에 나온 글인데도 지금 봐도 무릎을 탁 치게 만드는 통찰이 가득해요.

이 글의 핵심 메시지는 단순해요. 딥러닝 성능 최적화는 마법이 아니라 세 가지 병목 중에 어떤 게 문제인지 정확히 파악하는 게임이라는 거예요. 그 세 가지가 뭐냐면 컴퓨트(연산), 메모리 대역폭, 그리고 오버헤드예요. 이 세 개 중에 어디서 막히는지 모르면 아무리 코드를 최적화해도 효과가 없어요. 어쩌면 더 느려질 수도 있어요.

세 가지 병목, 풀어서 설명해드릴게요

첫 번째는 컴퓨트(Compute) 병목이에요. GPU가 곱셈, 덧셈 같은 실제 계산을 하느라 바쁜 상태죠. 이게 사실 우리가 "이상적으로" 바라는 상태예요. GPU가 100% 일하고 있다는 뜻이니까요. NVIDIA의 A100 GPU 같은 경우 BF16 연산으로 312 TFLOPS(초당 312조 번의 부동소수점 연산)까지 낼 수 있는데, 이걸 다 끌어내는 게 목표죠. 대표적인 컴퓨트 바운드 작업이 큰 행렬 곱셈이에요. 트랜스포머의 어텐션 연산이나 대형 컨볼루션 같은 거요.

두 번째는 메모리 대역폭(Memory Bandwidth) 병목이에요. 이게 뭐냐면, GPU가 계산할 데이터를 메모리에서 가져오는 데 시간을 다 써버리는 상태예요. GPU 안에는 빠른 메모리(SRAM)와 느린 메모리(HBM/DRAM)가 있어요. SRAM은 엄청 빠르지만 용량이 작고, DRAM은 용량이 크지만 상대적으로 느려요. A100의 HBM 대역폭이 약 1.5TB/s 정도인데, 이게 한계가 되면 GPU 코어들이 데이터 기다리느라 놀게 돼요. ReLU나 normalization 같은 "원소별 연산(elementwise operation)"이 대표적인 메모리 바운드 작업이에요. 계산 자체는 단순한데 데이터를 읽고 쓰는 비용이 크거든요.

세 번째는 오버헤드(Overhead)예요. 이게 좀 의외인데, GPU가 실제로 일하기 전에 "준비"하는 시간이에요. PyTorch에서 텐서 하나 만들고 함수 하나 부르는 데도 Python 인터프리터가 돌아가야 하고, CUDA 커널 런칭에도 시간이 걸려요. 모델이 작거나 배치 사이즈가 작으면 이 오버헤드가 전체 시간의 대부분을 차지할 수도 있어요. 호레이스가 든 예시로, 아주 작은 모델은 GPU에서 돌리는 게 CPU보다 오히려 느릴 수 있다는 거예요.

그래서 어떻게 알아내고 어떻게 고치느냐

어떤 병목인지 알아내는 가장 쉬운 방법은 배치 사이즈를 두 배로 늘려보는 것이에요. 시간이 똑같이 걸리면? 컴퓨트 바운드가 아니에요. 시간이 두 배가 되면? 컴퓨트 바운드예요. 메모리 바운드라면 배치 사이즈를 늘려도 시간이 비례해서 늘지 않고 천천히 늘어나요. 오버헤드 바운드라면 배치를 늘려도 시간이 거의 안 변해요. 이 간단한 실험만으로도 어디를 손봐야 할지 감이 잡혀요.

컴퓨트 바운드라면 더 큰 GPU를 쓰거나, 더 효율적인 알고리즘(예: Flash Attention)을 쓰는 게 답이에요. 메모리 바운드라면 오퍼레이터 퓨전(operator fusion)이 핵심이에요. 이게 뭐냐면, 여러 작은 연산을 하나로 합쳐서 메모리 왕복을 줄이는 기법이에요. 예를 들어 x.cos().cos() 같은 코드가 있으면 첫 번째 cos 결과를 메모리에 썼다가 다시 읽어서 두 번째 cos를 계산하는데, 퓨전을 하면 메모리에 안 쓰고 GPU 레지스터에서 바로 처리해요. torch.compile이나 Triton 같은 도구가 이걸 자동으로 해줘요.

오버헤드 바운드라면 CUDA Graph나 JIT 컴파일이 답이에요. PyTorch 2.0의 torch.compile이 이걸 자동으로 처리해주는데, 작은 모델에서 5~10배 속도 향상도 가능해요.

업계 흐름에서 어떤 위치인가

이 "세 가지 병목" 프레임워크는 지금 LLM 추론 최적화 업계의 표준이 됐어요. vLLM, TensorRT-LLM, SGLang 같은 추론 엔진들이 다 이 원칙에 기반해서 만들어졌어요. 특히 LLM은 단계마다 병목이 달라요. 입력을 처리하는 prefill 단계는 컴퓨트 바운드인데, 토큰을 하나씩 생성하는 decode 단계는 심하게 메모리 바운드예요. 그래서 PagedAttention, Continuous Batching 같은 기법들이 나온 거예요.

Flash Attention의 성공도 이 관점에서 보면 명확해요. 어텐션 계산이 사실 메모리 바운드였다는 걸 깨달은 거거든요. 알고리즘은 똑같지만 메모리 접근 패턴을 바꿔서 SRAM을 최대한 활용했더니 2~4배 빨라진 거예요.

한국 개발자에게 주는 시사점

LLM 파인튜닝이나 학습을 직접 해보시는 분들이라면 이 원칙을 무조건 알아야 해요. GPU 비용이 시간당 비싸니까 활용률 1%만 올려도 비용이 확 줄거든요. 특히 한국에서도 LLM 서빙을 직접 운영하는 회사가 늘고 있는데(네이버 하이퍼클로바X, 카카오의 Kanana 등), 추론 최적화는 곧 비용 최적화예요.

실무 팁을 드리면, 일단 torch.profiler나 nvidia-smi dmon으로 GPU 활용률부터 측정해보세요. 활용률이 80% 미만이면 십중팔구 메모리 바운드거나 오버헤드 바운드예요. 그다음 torch.compile을 한 줄 추가해보세요. 그것만으로도 큰 차이가 날 때가 많아요.