GPU 사용률이 높다고 해서 커널 내부의 작업이 효율적으로 겹쳐 실행되는 것은 아닙니다. 행렬 연산과 데이터 이동이 모두 진행되는 동안에도, 다음 데이터를 가져오는 시점이 늦어져 연산 장치가 기다릴 수 있습니다. 커널의 총 실행 시간은 이런 손실이 있다는 사실을 보여주지만, 어느 의존 관계를 바꿔야 하는지까지 알려주지는 않습니다.
KPerfIR은 이 원인을 컴파일러 내부에서 추적하는 계측 기반 기술입니다[1]. UC San Diego, Meta, George Mason University, OpenAI 소속 연구진이 참여한 OSDI 2025 논문으로, 루프와 워프 그룹처럼 컴파일러가 이미 알고 있는 구조를 실행 시간 측정에 연결합니다. 완성된 범용 자동 최적화기를 제시한 것은 아니며, 여러 성능 도구를 만들 수 있는 기반과 구간별 실행 시간 측정 도구를 함께 평가했습니다.
인프라 운영에서 중요한 점도 이 구분입니다. 계측 도구를 붙였다고 추론 처리량이 곧바로 늘어나지는 않습니다. 도구로 대기 원인을 찾고, 해당 의존 관계를 수정한 다음, 계측을 제거한 실행에서 결과의 정확성과 성능을 다시 확인해야 합니다. 그 개선이 전체 서비스에 남는지까지 확인해야 GPU 시간을 실제 운영 여력으로 전환했다고 볼 수 있습니다.
전체 실행 시간에 가려지는 의존 관계
최근 GPU 커널은 데이터를 읽은 다음 계산하는 순서를 그대로 반복하지 않습니다. 현재 데이터를 계산하는 동안 다음 데이터를 준비하는 소프트웨어 파이프라이닝을 쓰고, 워프 그룹별로 데이터 이동과 계산의 역할을 나누기도 합니다. 이때 전체 소요 시간은 개별 명령의 시간을 더한 값보다 작업 사이의 의존 관계에 더 크게 영향을 받습니다.
계산 담당 워프가 오래 기다린다고 해서 반드시 메모리 대역폭이 부족한 것은 아닙니다. 이전 데이터를 사용하는 쪽이 버퍼를 늦게 반환했거나, 데이터를 사용할 수 있다는 알림을 필요 이상으로 늦게 보냈을 수도 있습니다. 이런 경우 연산 처리량이나 메모리 대역폭만 높여도 다음 작업을 시작하는 시점은 달라지지 않습니다. 병목을 제거하려면 자원 사용량뿐 아니라 시작을 막는 조건을 알아야 합니다.
기계어 수준의 실행 기록은 상세하지만, 어느 루프의 몇 번째 반복을 측정했는지 연결하기 어렵습니다. 반대로 소스 코드의 큰 구간을 재면 프로그램의 의미는 남지만 비동기 작업이 겹치는 과정을 놓칠 수 있습니다. KPerfIR은 컴파일러가 구조를 아직 알고 있는 위치에 계측 연산을 넣고, 이를 낮은 수준의 명령으로 변환하는 과정에서도 분석에 필요한 정보를 유지합니다.
프로그램의 의미를 보존하는 계측 연산
KPerfIR은 계측을 한 번의 코드 삽입으로 끝내지 않고 여러 단계의 중간 표현(IR)으로 나눕니다. 상위 단계에서는 어느 구간의 시작과 종료인지, 어떤 반복이나 워프와 연결되는지를 기록합니다. 이후 이를 장치의 카운터를 읽는 연산과 읽은 값을 저장하는 연산으로 변환하고, 최종적으로 GPU가 실행할 명령을 생성합니다.
카운터 읽기와 기록 저장을 분리한 이유는 두 동작이 측정에 미치는 영향이 다르기 때문입니다. 시각은 관찰하려는 실행 지점에서 읽어야 하지만, 그 값을 저장하는 명령은 별도의 시간과 자원을 사용합니다. 두 동작을 하나의 불투명한 작업으로 묶으면 주변 명령을 배치할 여지가 줄고, 어느 동작이 원래 실행을 방해했는지도 설명하기 어려워집니다.
그렇다고 도구 개발자의 일이 없어지는 것은 아닙니다. 계측할 위치를 선택하고, 기록용 메모리를 관리하며, 수집한 결과를 해석하는 과정은 여전히 필요합니다. 논문은 이를 위한 컴파일러 인터페이스와 Python 인터페이스를 제시합니다. 원래 커널과 계측용 커널을 별도로 유지할 수 있어, 분석이 끝난 뒤 계측을 제거하고 본래 실행과 비교할 수 있습니다.
공통 인터페이스 아래에 남는 장치별 차이
평가에는 NVIDIA H100-HBM3와 AMD MI300X가 사용됐으며, 소프트웨어는 Triton 3.0.0과 LLVM 19.1을 기준으로 합니다. 두 장치에서 같은 상위 계측 의도를 표현할 수 있다는 점은 도구 개발 비용을 줄이는 데 의미가 있습니다. 다만 인터페이스가 같다고 카운터 명령, 스레드 실행 방식, 기록 비용까지 같아지는 것은 아닙니다.
AMD 구현에는 타임스탬프를 저장하는 분기에서 발생하는 비용을 줄이기 위한 별도 방식이 들어갑니다. 여러 스레드가 협력해 기록을 남기고, 하드웨어 식별 정보를 사용해 결과를 해석합니다. 이는 공통 추상화 아래에서 해결한 장치별 문제입니다. 따라서 이식성은 장치 차이를 없앴다는 의미보다, 상위 분석을 재사용하면서 차이는 백엔드에서 다룰 수 있다는 의미로 읽어야 합니다.
컴파일러의 명령 재배치와 레지스터 사용도 영향을 받습니다. 계측 명령 자체가 몇 개에 불과해도 주변 코드의 최적화 결과가 달라질 수 있습니다. 운영 환경의 컴파일러나 GPU가 바뀌면 기존 계측 비용을 그대로 적용하지 말고 다시 확인해야 합니다. 인터페이스를 재사용할 수 있다는 사실이 오래된 보정값의 유효성까지 보장하지는 않습니다.
전체 기록 대신 최근 반복을 남기는 선택
세밀한 계측에는 저장 공간이 필요하지만, 최적화된 커널은 이미 공유 메모리를 상당 부분 사용하고 있을 수 있습니다. 모든 기록을 즉시 전역 메모리에 쓰면 실행 이력은 보존할 수 있지만, 추가 메모리 접근이 관찰하려는 동작을 바꿀 수 있습니다. 논문의 구간별 시간 측정 도구는 이를 줄이기 위해 공유 메모리에 순환 버퍼를 둡니다.
기본 방식은 버퍼가 가득 찼을 때 오래된 기록을 덮어씁니다. 따라서 남는 것은 전체 실행 이력이 아니라 최근 반복의 기록입니다. 반복마다 비슷하게 나타나는 중첩 문제를 찾을 때는 유용하지만, 시작 구간의 준비 비용이나 앞부분에서 한 번 발생한 긴 대기는 사라질 수 있습니다. 마지막 반복이 일정하게 보인다는 이유로 커널 전체가 일정했다고 해석해서는 안 됩니다.
기록을 전역 메모리로 내보내 보존하는 방식도 선택할 수 있지만 비용이 늘어납니다. 무엇을 측정할지 먼저 정해야 하는 이유입니다. 정상 상태의 반복을 볼 것인지, 초기화 과정이나 드문 정지를 볼 것인지에 따라 적합한 저장 방식이 달라집니다. 가장 저렴한 계측 설정이 필요한 증거까지 남겨준다는 보장은 없습니다.
기록에 사용하는 시계의 비트 수도 제한됩니다. 논문은 일정한 시간 간격 조건에서 카운터가 한 바퀴 도는 현상을 후처리로 복원합니다. 임의로 긴 구간이나 정보가 부족한 기록까지 모두 복구하는 기능은 아닙니다. 계측을 가볍게 만든 전제를 결과 해석에서도 유지해야 합니다.
측정 때문에 짧아지거나 길어지는 대기
비동기 연산에서는 계측 자체가 대기 시간을 바꿀 수 있습니다. 스레드가 다른 연산 장치에 작업을 요청한 뒤 별도 명령을 수행하다가 완료를 기다리는 경우를 생각할 수 있습니다. 중간에 타임스탬프를 읽는 명령을 추가하면 그 시간만큼 다른 연산이 더 진행하므로, 관찰되는 대기는 짧아질 수 있습니다. 실제 연산이 빨라진 것은 아닙니다.
반대로 계측 명령이 원래 남아 있던 시간보다 오래 걸리면 없던 유휴 구간이 생겨, 기록만 보고 수정 대상을 잘못 고를 수 있습니다. 동시에 진행되는 작업 사이의 관계 자체가 달라졌으므로 커널 전체 시간에서 평균 계측 비용 하나를 빼는 방식만으로는 이를 바로잡기 어렵습니다.
논문은 기록 위치와 프로그램의 의미를 이용해 실행 흐름을 재구성하는 후처리를 제시합니다. 비동기 연산 사례에서는 연산 장치의 실행 시간이 삽입한 계측 작업을 충분히 가릴 수 있다는 조건을 사용합니다. 모든 짧은 구간에서 계측을 완전히 투명하게 만드는 방법은 아닙니다. 커널을 수정한 뒤에도 해당 조건이 유지되는지 확인해야 시간축의 숫자를 신뢰할 수 있습니다.
FlashAttention에서 확인한 장벽 위치의 영향
대표적인 최적화 사례는 H100에서 실행한 실험용 Triton FlashAttention 3 구현입니다. 데이터를 읽는 워프 그룹과 행렬 연산 및 softmax를 수행하는 워프 그룹이 나뉘어 있습니다. 계측 결과 V 텐서와 관련된 장벽이 다음 데이터 읽기를 지연시키고, 이 때문에 일부 연산이 전체 실행 시간을 결정하는 경로에 남아 있는 것으로 나타났습니다.
연구진은 해당 알림의 위치를 앞당기고 반복 시작 전의 데이터 준비를 포함해 실행 순서를 조정했습니다. 그 결과 이전에는 순차적으로 기다리던 작업이 데이터 읽기와 겹쳐 실행될 수 있었습니다. 동기화를 무조건 줄인 것이 아니라, 필요한 의존 관계가 실제로 충족되는 시점을 찾아 알림을 옮긴 것입니다. 정확성을 유지하면서 제거할 수 있는 대기를 구분한 사례입니다.
측정한 구간별 시간을 중첩 성능 모델에 연결해 다음 배치를 선택하는 방법도 제시합니다. 다만 모델이 예측한 처리량은 별도의 실측 결과가 아닙니다. 모델은 반복 내부의 계산과 데이터 이동에 초점을 맞추며 초기화와 종료 비용을 단순화합니다. 짧은 입력이나 다른 타일 크기에 적용할 때는 이런 비용의 비중이 달라질 수 있으므로 다시 측정해야 합니다.
성능 향상, 계측 비용, 모델 오차의 구분
논문은 최적화한 커널이 기존 실험용 Triton FA3보다 24.1% 개선됐다고 보고합니다. 비교 대상을 논문에서 사용한 수작업 FA3 구현으로 바꾸면 개선 폭은 7.6%입니다. 이는 계측 결과, 성능 모델, 수동으로 조정한 최적화가 결합된 결과입니다. 임의의 모델에 KPerfIR을 붙이기만 하면 얻는 성능 향상으로 볼 수 없습니다.
계측 비용은 이와 다른 결과입니다. 초록은 8.2%를 제시하며, 평가에서는 대부분의 시험이 10% 미만이고 기록이 많은 시험도 15% 이내라고 설명합니다. 이는 증거를 수집하는 동안 추가되는 실행 비용입니다. 최종 커널에서는 계측을 제거할 수 있으므로, 앞의 성능 향상률에서 이 값을 기계적으로 빼서 배포 효과를 계산하는 것도 맞지 않습니다.
약 2%라는 값 역시 의미를 구분해야 합니다. 해당 평가는 원래 GEMM 실행 시간에 계측 명령 비용을 더한 모델과 실제 계측 실행 시간을 비교합니다. 모든 내부 구간의 타임스탬프가 참값에서 2% 이내라는 정확도 보장이 아닙니다. 측정 비용, 모델과 실측의 차이, 최적화 후 성능은 서로 다른 질문에 대한 답입니다.
기존 도구와 전체 서비스 검증의 역할
컴파일러가 삽입하는 명령으로 읽을 수 있는 정보에는 한계가 있습니다. GPU 제조사 도구는 외부에 공개되지 않은 성능 레지스터나 별도 활동 정보에 접근할 수 있습니다. 따라서 KPerfIR을 Nsight Compute나 AMD의 분석 도구 전체를 대체하는 기술로 보기는 어렵습니다. 프로그램 구조와 연결된 내부 시간을 제공한다는 점에서 상호 보완적입니다.
시스템 규모가 커져도 같은 구분이 필요합니다. 커널 내부의 대기를 설명하는 기능만으로는 다른 서버의 지연 때문에 학습이 멈추거나, 요청 배치가 잘못돼 서빙 큐가 길어지는 원인까지 알 수 없습니다. 논문은 분산 작업으로의 확장 가능성을 논의하지만, 통신과 계산이 하나로 합쳐진 커널에는 관련 컴파일러 지원이 더 필요하다고 밝힙니다.
도입 순서는 전체 작업에서 시간을 많이 차지하고 실제 병목에 놓인 커널을 찾는 것부터 시작하는 편이 합리적입니다. 그다음 내부 계측으로 수정 위치를 정하고, 계측 없는 실행으로 돌아와 효과를 확인합니다. 마지막에는 실제 배치 크기와 요청 분포에서 지연 또는 처리량이 달라지는지 측정해야 합니다. 그래야 커널 수준의 개선을 서비스 용량으로 잘못 환산하지 않습니다.
컴파일러가 바뀌어도 재현 가능한 최적화
실행 기록에는 커널 소스뿐 아니라 컴파일러 버전, 실행 설정, 입력 크기, 계측 위치와 버퍼 정책을 함께 남겨야 합니다. 그렇지 않으면 다음 컴파일러 버전에서 커널과 계측 코드가 동시에 바뀌었을 때 성능 차이의 원인을 분리하기 어렵습니다. 기록 파일 하나보다 그 기록을 만든 조건이 장기적인 최적화 자산에 가깝습니다.
정확성 검증도 빠른 결과가 나온 입력 하나에 한정해서는 안 됩니다. 장벽 위치를 바꾸면 지원하는 입력 크기와 수치 범위에서 의존 관계가 계속 성립하는지 확인해야 합니다. 반복 구간이 빨라졌더라도 추가 준비 작업 때문에 짧은 입력에서는 오히려 느려질 수 있습니다. 모델이 이득을 예측한 조건과 그렇지 않은 조건을 함께 시험해야 수정의 적용 범위를 정할 수 있습니다.
KPerfIR의 가치는 사용률 숫자를 추가하는 것보다 컴파일러의 의도와 실제 실행을 연결하는 데 있습니다. AI 인프라에서 필요한 것은 바쁜 GPU를 확인하는 데서 한 걸음 더 나아가, 무엇을 바꾸면 기다림이 줄고 그 여유를 어떤 작업이 사용할 수 있는지 설명하는 능력입니다. 이 논문은 그 설명을 재현 가능한 도구로 만드는 방향을 보여 줍니다.
출처와 저작권 안내
이 글은 OSDI 2025 논문과 공식 발표 자료를 검토해 독립적으로 작성한 편집 분석입니다. 실험 결과는 원문 저자들의 보고이며, 운영 적용에 관한 판단은 본지의 해석입니다. 원문 저작권은 저자들에게 있습니다(© 2025). 도판은 이 글을 위해 새로 제작했으며 원문 도판을 복제하지 않았습니다.