PyTorch `torch.profiler`로 행렬 곱셈(matmul)과 바이어스 덧셈(add) 연산을 분석하는 실전 입문 가이드다. 64×64 행렬에서는 GPU 연산 시간(23μs)보다 CPU 디스패치 시간(2.3ms)이 압도적으로 길어 오버헤드 바운드 상태이며, 4096×4096으로 키우면 CPU·GPU 시간이 모두 ms 단위로 균등해지는 컴퓨트 바운드로 전환됨을 프로파일러 테이블과 Perfetto 트레이스로 확인한다. `torch.compile` 적용 시 두 연산이 디스패처 수준에서 `aten::addmm`으로 병합되지만, GPU에서는 cuBLAS GEMM과 Device-to-Device 메모리 복사가 분리 실행되어 진정한 커널 융합과는 다르다. 단일 연산에서는 컴파일 CPU 오버헤드가 2배 증가하므로, 수십 개 이상의 연산을 가진 실제 모델에서야 비로소 이득이 발생한다.

• •64×64 행렬에서 Self CPU 2.3ms vs CUDA 23μs로 GPU는 1%만 활용되는 오버헤드 바운드 패턴이며, 4096×4096으로 키우면 CPU·GPU 시간이 그 ms 단위로 균등해지는 컴퓨트 바운드로 전환된다.
• •cuBLAS는 matmul 전 SM 점유율 질의(cudaOccupancyMax...)를 통해 커널 변형을 런타임에 선택하며, 이 단계는 add 같은 고정 리소스 경량 커널에서는 발생하지 않는다.
• •`torch.compile`은 두 연산을 `aten::addmm`으로 디스패쳄 수준에서 병합하지만, GPU에서는 DtoD memcpy와 GEMM 에필로그가 분리 실행되어 메모리 트래픽이 줄지 않는다.
• •동일 커널을 동일 입력으로 반복해도 GPU 클럭·발열·전력 관리로 스텝마다 실행 시간이 다르므로, 평균값만 보면 실제 성능을 오판할 수 있다.
• •단일 연산에서 `torch.compile` CPU 스텝 시간은 약 2배 증가한다. Dynamo→AOTAutograd→Inductor 스택 비용이 매 호출마다 부과되므로 수십 개 이상 연산 모델에서만 효과적이다.