커널을 2.2배 빠르게 만들었는데 학습이 3배 느려졌다? GPU 최적화의 함정

무슨 이야기냐면요

한 개발자가 머신러닝 모델 학습 코드를 최적화하다가 정말 황당한 일을 겪은 걸 공유했어요. 연산 커널(kernel) 하나를 2.2배나 빠르게 만들었는데, 정작 전체 학습 루프는 3배가 더 느려졌다는 거예요. 부분을 빠르게 했는데 전체가 느려지다니, 직관에 완전히 반하죠? 그런데 이건 GPU로 딥러닝을 돌려본 사람이라면 누구나 빠질 수 있는 깊은 함정이라, 그 정체를 풀어볼게요.

배경부터 잠깐 짚을게요. 이 개발자는 Dr. GRPO라는 강화학습 기법의 연산을 최적화하던 중이었어요. GRPO는 요즘 LLM(거대 언어 모델)을 추론 잘하도록 훈련시킬 때 쓰는 강화학습 알고리즘인데, 자세한 원리는 몰라도 돼요. 핵심은 "이 연산을 더 빠른 커널로 갈아끼웠다"는 부분이니까요. 여기서 커널이란 GPU에서 도는 작은 연산 프로그램 하나를 가리켜요.

왜 부분이 빨라졌는데 전체가 느려졌냐면

범인은 CPU와 GPU의 동기화(synchronization)였어요. 이게 이번 이야기의 핵심이에요.

GPU 프로그래밍의 비밀 하나를 알려드릴게요. CPU가 GPU에게 "이 연산 해"라고 명령을 던질 때, CPU는 GPU가 그 일을 다 끝낼 때까지 기다리지 않아요. 명령만 휙 던져두고 바로 다음 줄로 넘어가요. 이걸 비동기(asynchronous) 실행이라고 해요. 덕분에 CPU는 계속 다음 명령들을 GPU의 작업 대기열에 쌓아둘 수 있고, GPU는 쉬지 않고 일감을 받아 처리해요. 마치 주방에서 셰프(GPU)가 요리하는 동안 직원(CPU)이 계속 주문서를 밀어 넣는 것과 같아요. 이렇게 둘이 겹쳐서 일해야 전체 처리량이 높아지거든요.

그런데 코드에서 GPU가 계산한 결과 값을 CPU가 직접 들여다보려고 하는 순간 문제가 터져요. 예를 들어 GPU 텐서의 값을 파이썬 숫자로 꺼내거나(.item() 같은 동작), 그 값으로 if 조건 분기를 하거나, CPU로 데이터를 복사하면, CPU는 어쩔 수 없이 멈춰 서서 "GPU야, 거기까지 한 일 다 끝낼 때까지 기다릴게" 하고 대기해요. 이걸 동기화 지점 또는 파이프라인 stall(정체)이라고 불러요. 주방 비유로 치면, 직원이 주문서를 계속 넣다 말고 "방금 그 요리 다 됐어요?" 하고 셰프 앞에 멍하니 서서 기다리는 거예요. 그동안 주문서 밀어 넣는 일이 멈추니, 셰프도 다음 일감이 끊겨서 결국 주방 전체가 굼떠지죠.

이 개발자가 만든 "더 빠른 커널"은 아마 그 안에서, 혹은 그걸 호출하는 코드에서 이런 동기화를 유발했던 거예요. 커널 자체의 계산 시간은 2.2배 줄었지만, 그 커널을 쓰느라 CPU와 GPU가 매번 손발을 맞추려고 멈춰 서는 비용이 새로 생긴 거죠. 그 멈춤 비용이 커널을 빠르게 해서 번 시간보다 훨씬 커서, 결과적으로 전체가 3배 느려진 거예요. 개별 부품은 빨라졌는데 부품끼리 연결되는 이음새에서 다 까먹은 셈이에요.

어떻게 알아내고 고치냐면

이런 문제는 코드만 봐서는 절대 안 보여요. 그래서 프로파일러(profiler)가 필수예요. PyTorch 사용자라면 torch.profiler나 NVIDIA의 Nsight 같은 도구로 GPU 타임라인을 그려볼 수 있어요. 그러면 GPU가 실제로 계산하는 구간과, 일감이 없어서 텅 비어 노는(idle) 구간이 한눈에 보여요. 동기화 때문에 GPU가 띄엄띄엄 노는 게 보이면 그게 바로 범인이에요.

해결의 큰 방향은 "GPU 결과를 CPU로 자꾸 끌어오지 마라"예요. 학습 루프 안에서 매 스텝마다 손실 값을 .item()으로 꺼내 출력하는 흔한 습관도 동기화를 유발해요. 꼭 필요한 게 아니면 여러 스텝을 모아서 한 번에 가져오거나, 로깅 빈도를 줄이거나, 연산을 GPU 위에서 끝까지 유지하는 식으로 동기화 횟수를 줄여야 해요.

업계 맥락에서 보면

이건 "국소 최적화(local optimization)의 함정"이라는 아주 보편적인 교훈의 GPU 버전이에요. 컴퓨터 과학의 오랜 격언인 "전체를 측정하기 전에 최적화하지 마라"가 딱 들어맞죠. 부분 성능 지표(이 커널 빠르다!)에만 꽂히면, 그 부분이 전체 시스템과 맺는 관계를 놓쳐요. 데이터베이스 쿼리 하나를 빠르게 했는데 캐시 적중률이 떨어져 전체가 느려지는 것과 본질이 똑같아요.

최근 LLM 학습·추론 최적화 판에서 이런 "동기화·데이터 이동 비용"은 갈수록 중요해지고 있어요. 연산 자체보다 데이터를 옮기고 손발 맞추는 비용이 병목인 경우가 많거든요. 그래서 요즘 고성능 커널들은 여러 연산을 하나로 합치는 커널 퓨전(kernel fusion)으로 데이터가 GPU 메모리를 들락거리는 횟수 자체를 줄이는 방향으로 가요. 유명한 FlashAttention도 결국 이 발상의 산물이고요.

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

딥러닝 모델을 직접 학습시키는 분이라면 이건 당장의 실전 팁이에요. 학습이 이상하게 느리다면 GPU 사용률(nvidia-smi로 확인)부터 보세요. GPU가 100%가 아니라 띄엄띄엄 놀고 있다면, 십중팔구 데이터 로딩이나 CPU-GPU 동기화가 발목을 잡는 거예요. "GPU를 더 좋은 걸로 바꿔야 하나" 고민하기 전에, 이음새 비용부터 잡으면 돈 안 들이고 몇 배 빨라질 수 있어요.

그리고 ML이 아니더라도 교훈은 보편적이에요. 부분을 빠르게 만들었다고 전체가 빨라진다는 보장은 없다. 항상 끝에서 끝까지(end-to-end) 측정하고 나서 "빨라졌다"고 말하는 습관, 이게 진짜 실력이에요.

마무리

핵심 한 줄은 이거예요. GPU 최적화의 진짜 적은 느린 연산이 아니라, CPU와 GPU가 서로를 기다리며 멈춰 서는 순간이다. 커널을 깎기 전에 타임라인부터 그려보세요.

여러분은 성능 최적화하다가 "분명 빠르게 했는데 전체는 더 느려진" 황당한 경험, 있으신가요? 어떤 이음새에서 발목 잡히셨는지 들려주세요.