공통 · 하드웨어 · 2026-09-17
GPU 통신을 수행하는 SM과 복사 엔진
통신을 수행하는 장치와 연결을 구별하고, 계산과의 자원 경쟁이 전체 완료 시간에 미치는 영향을 살펴봅니다.
GPU 사이에서 데이터를 전달하기에서는 한 GPU가 만든 값을 다른 GPU가 받아 계산에 사용하는 과정을 살펴봤습니다. CPU가 작업을 등록하고, 스트림과 통신의 완료 관계가 실행 순서를 연결했습니다. 이번에는 그중 ‘통신 작업’이라고 묶어 둔 부분을 열어보겠습니다.
데이터를 옮기는 일도 GPU의 자원을 사용합니다. 계산과 통신이 같은 자원을 사용하면 서로의 실행을 늦출 수 있습니다. 통신에 적합한 작업을 별도 장치에 맡겨 계산에 쓸 자원을 더 남기는 것이 한 가지 최적화 방향입니다.
먼저 CPU의 통신 호출이 실제 전달 작업으로 이어지는 과정을 짧게 복습하겠습니다. 이어서 GPU의 계산 장치가 데이터를 옮기는 방식과, 복사를 담당하는 전용 장치를 사용하는 방식을 비교합니다. 마지막으로 이 차이가 통신 시간뿐 아니라 계산과 통신을 모두 마치는 시간에 어떤 영향을 주는지 살펴보겠습니다.
CPU의 호출에서 실제 데이터 전달로
NCCL은 GPU 사이의 통신을 수행하는 라이브러리입니다. 프로그램은 CPU에서 ncclSend를 호출해 ‘이 버퍼의 값을 상대에게 보내 달라’고 요청하고, ncclRecv를 호출해 ‘상대의 값을 이 버퍼로 받아 달라’고 요청합니다. 버퍼는 데이터를 담아 두는 메모리 영역입니다. 여기서는 함수의 문법을 이해할 필요 없이, 송신 요청과 수신 요청을 나타내는 이름으로 읽으면 됩니다.
이 호출을 받는 NCCL의 코드도 CPU에서 실행됩니다. NCCL은 요청을 확인하고 통신 상대, 버퍼, 사용할 수 있는 연결 등의 정보를 바탕으로 실행할 작업을 구성합니다. 이어서 지정된 스트림에서 통신이 진행되도록 필요한 작업을 등록합니다. 스트림은 GPU 작업 사이의 실행 순서를 지정하는 수단입니다.
그림 1의 위쪽은 CPU에서 실행하는 코드이고, 아래쪽은 등록된 통신 작업이 GPU의 데이터를 전달하는 부분입니다. 주황 점선은 작업을 실행하도록 요청하는 관계입니다. 파란 실선은 실제 데이터가 이동하는 관계입니다. CPU가 통신을 요청했다고 해서 전달할 값을 CPU 메모리로 가져와 하나씩 보내는 것은 아닙니다.
작업 등록과 완료도 구별해야 합니다. CPU의 호출이 반환되어 다음 코드로 진행하더라도, GPU의 통신은 아직 끝나지 않았을 수 있습니다. NCCL의 스트림 실행 설명도 작업을 스트림에 등록하는 것과 실제 통신이 완료되는 것을 구별합니다.
그렇다면 NCCL 함수 안에 통신 커널이 하나 들어 있다고 이해하면 될까요? CPU 쪽에서 작업을 준비하고, GPU 커널이나 전송 장치가 그 일을 수행하도록 연결한다고 이해하면 됩니다. 커널은 GPU에서 여러 스레드가 실행하는 프로그램입니다. 통신에서도 이런 프로그램을 사용할 수 있고, 지원되는 작업은 전용 장치에 맡길 수도 있습니다. NCCL은 여러 통신 요청을 묶어서 실행할 수도 있으므로, 함수 호출 하나가 커널 하나에 항상 대응하는 것은 아닙니다.
이제 그 아래에서 실제 데이터 전달을 수행하는 두 가지 방식을 비교해 보겠습니다.
데이터를 옮기는 SM과 복사 엔진
GPU 안에서 커널의 스레드를 실행하는 장치가 SM(Streaming Multiprocessor)입니다. SM에서 실행하는 스레드는 계산뿐 아니라 메모리를 읽고 쓰는 명령도 수행합니다. 다른 GPU의 메모리에 접근할 수 있는 환경이라면, 자신의 GPU 메모리에서 값을 읽어 상대 GPU 메모리에 쓰는 프로그램도 실행할 수 있습니다. 이렇게 데이터 전달과 필요한 진행 확인을 수행하는 GPU 프로그램을 이 글에서는 통신 커널이라고 부르겠습니다.
통신 커널도 SM에서 실행되므로 계산과 자원을 함께 사용합니다. 동시에 실행할 계산이 있다면, 통신에 사용한 만큼 계산에 쓸 실행 자원이 줄어들 수 있습니다. 데이터를 옮기는 작업이 계산 시간에도 영향을 주는 이유입니다.
GPU에는 메모리 복사를 담당하는 별도 하드웨어인 복사 엔진(Copy Engine, CE)도 있습니다. 지원되는 복사 작업의 출발지와 목적지, 크기 등을 지정하면 이 장치가 데이터를 옮깁니다. SM의 스레드가 복사를 위한 명령을 반복해서 실행하는 부담을 줄일 수 있습니다. 여기서 ‘엔진’은 소프트웨어 함수가 아니라 GPU 안의 장치를 뜻합니다.
어느 장치가 복사를 수행하든, 상대 GPU까지 데이터를 전달할 연결은 필요합니다. NVLink는 NVIDIA가 GPU 사이 등에 높은 대역폭의 연결을 제공하기 위해 만든 기술입니다. PCIe(PCI Express)는 GPU 같은 장치들을 컴퓨터 시스템에 연결하는 널리 쓰이는 규격입니다. 대역폭은 단위 시간에 옮길 수 있는 데이터량입니다. GPU 사이의 전달은 구성과 지원 조건에 따라 NVLink나 PCIe를 사용할 수 있습니다. CUDA의 GPU 간 메모리 전달과 접근
그림 2에서는 같은 서버 안의 두 GPU가 NVLink로 연결되어 있다고 가정합니다. 비교하는 작업은 같은 데이터 x를 GPU 0에서 GPU 1로 복사하는 일입니다. GPU 0에서는 통신과 함께 독립적인 계산 C도 실행합니다. C는 전달 중인 x를 읽거나 변경하지 않는 별도 계산입니다.
위쪽에서는 SM의 통신 커널이 GPU 0의 메모리를 읽고 NVLink를 통해 GPU 1의 메모리에 쓰도록 합니다. 계산 C도 SM에서 실행되므로 통신과 계산이 SM 자원을 함께 사용합니다. 아래쪽에서는 복사 엔진이 복사를 맡습니다. 이때 SM에서 복사를 수행하던 부담이 줄어 계산 C에 자원을 더 사용할 여지가 생깁니다. NVIDIA의 NCCL 복사 엔진 활용 설명도 이러한 자원 경쟁의 감소를 다룹니다.
그림에서는 전달을 수행하는 장치와 데이터가 지나가는 연결을 구별하면 됩니다. 실행 장치는 SM에서 CE로 달라졌지만, 연결은 같은 NVLink입니다. CE가 데이터를 위한 새로운 길을 만드는 것은 아닙니다.
복사 엔진이 있다고 모든 통신을 맡길 수 있는 것은 아닙니다. NCCL이 CE를 사용하는 데에는 통신 연산, 버퍼 준비 방식, 소프트웨어 버전과 설정 등의 조건이 있습니다. 그림은 지원되는 복사의 실행 원리를 비교하며, 앞서 본 ncclSend와 ncclRecv가 언제나 CE로 전환된다는 뜻은 아닙니다. 구체적인 조건은 NCCL의 SM을 사용하지 않는 통신 최적화 문서에서 확인할 수 있습니다.
통신과 계산을 함께 마치는 시간
같은 데이터를 같은 NVLink로 전달한다면, SM을 쓰든 CE를 쓰든 통신 시간도 같을까요? 연결의 대역폭은 공통 제약이지만, 그것만으로 통신 시간이 정해지지는 않습니다. 전송할 데이터를 준비하는 시간, 작업을 시작하는 비용, 다음 데이터를 보내기까지 기다리는 시간도 영향을 줍니다. 연결이 빨라도 전달할 데이터나 요청이 준비되지 않았다면 그 속도를 충분히 활용할 수 없습니다.
두 방식이 같은 연결의 대역폭을 충분히 사용하고 준비·대기 시간도 작다면 통신 시간은 비슷할 수 있습니다. 이 경우에도 계산을 함께 실행한 결과는 달라질 수 있습니다. 통신을 빨리 끝내는 것과, 통신과 계산을 모두 빨리 끝내는 것은 따로 확인해야 합니다.
그림 3에서는 이 차이를 보기 위해 두 경우의 통신 시간을 같게 두겠습니다. 전달량과 계산 C의 작업량도 같습니다. 달라지는 것은 통신과 C가 SM 자원을 함께 사용하는 정도입니다.
위쪽에서는 통신 커널과 C가 SM 자원을 나눠 사용하면서 계산이 늦어집니다. 아래쪽에서는 CE가 복사를 맡아 C에 쓸 수 있는 SM 자원이 늘고, C가 더 일찍 끝납니다. 통신 단독의 완료 시간은 같지만 두 작업을 모두 마치는 시간은 줄어든 것입니다. 여기서 ‘전체 완료’는 그림에 있는 통신과 C가 모두 끝나는 시점입니다.
이 그림은 SM 자원 경쟁이 계산을 늦추는 경우를 설명하는 예시입니다. CE도 GPU 메모리를 읽고 쓰고 GPU 사이의 연결을 사용합니다. 따라서 SM 자원 경쟁이 줄어도 메모리와 연결의 대역폭 경쟁까지 사라지는 것은 아닙니다. C가 메모리에서 입력을 가져오는 속도에 더 크게 제한된다면, CE를 사용해 얻는 전체 시간의 개선은 작을 수 있습니다.
실제 실행에서는 통신이 어떤 자원을 사용하는지와 계산이 어디에서 기다리는지를 함께 봐야 합니다. SM 자원 경쟁이 큰지, 메모리나 GPU 사이 연결이 한계에 도달했는지에 따라 효과적인 개선도 달라집니다. 필요한 작업 전체가 더 일찍 끝났는지가 최종 판단 기준입니다.
이번 글에서는 데이터를 옮기는 일을 적합한 장치에 맡겨 계산과의 자원 경쟁을 줄이는 방향을 살펴봤습니다. 또 다른 방향은 데이터가 중간 공간에 복사되는 과정을 줄이는 것입니다. 서버 사이의 GPU 통신과 CPU의 역할에서는 데이터를 다른 서버로 보낼 때의 경로와, 중간 복사를 줄인 뒤에도 필요한 CPU의 역할을 살펴보겠습니다.