eBPF로 GPU 관측하기: PTX에 계측 코드를 심어 워프 단위 실행과 드라이버 정책까지 들여다보는 방법

핵심 메시지

• GPU 스택은 사용자 공간 런타임, 커널 드라이버, 디바이스 세 층으로 나뉘는데 상당 부분이 닫혀 있어 내부에서 무슨 일이 벌어지는지 관찰하기 어렵다.
• 발표자는 리눅스 커널을 안전하게 확장하는 기술인 eBPF를 GPU 커널 코드(PTX)와 드라이버 양쪽에 심어, 세밀한 관측과 정책 교체를 동시에 노린다.
• CUPTI 같은 기존 인터페이스는 커널 실행의 시작과 끝처럼 굵은 이벤트만 주기 때문에, 여러 커널이 SM 자원을 두고 경쟁할 때 생기는 지연의 원인을 짚기 어렵다.
• 통합 메모리(UVM)의 이주·프리페치 정책과 GPU 스케줄링의 시간 분할 값은 드라이버에 고정돼 있어, 워크로드마다 다른 최적 정책을 사용자가 선택할 수 없다.
• 목표는 프로파일링에 그치지 않고 여러 작업이 한 GPU를 나눠 쓸 때의 공정성·격리와 KV 캐시 오프로딩 성능까지 손대는 것이다.

쉽게 이해하기

GPU 프로그램의 성능 문제를 파고들어 본 사람이라면 어느 지점에서 벽을 만난다. 애플리케이션과 프레임워크 위쪽은 볼 수 있지만, 그 아래 CUDA 런타임과 커널 드라이버, 그리고 장치 위에서 도는 펌웨어는 대부분 닫혀 있기 때문이다. GPU MODE 강연에 나선 발표자는 이 문제를 "보이지 않는다(invisible)"와 "바꿀 수 없다(inflexible)" 두 가지로 정리했다.

그가 제시한 해법은 리눅스 세계에서 이미 검증된 도구를 GPU로 옮겨오는 것이다. eBPF는 커널 안에서 작은 프로그램을 돌리되, 실행 전에 검증기가 무한 루프나 잘못된 메모리 접근이 없는지 확인해 안전을 보장하는 기술이다. 커널 모듈과 달리 재시작 없이 동적으로 붙일 수 있고, 맵(map)이라는 자료구조로 사용자 공간과 상태를 공유한다. 리눅스에서는 이미 추적·보안·네트워킹은 물론 CPU 스케줄러 교체까지 이 방식으로 이뤄지고 있다.

디바이스 쪽 구현은 eBPF 프로그램을 GPU 중간 언어인 PTX로 컴파일한 뒤, 원래 CUDA 커널의 PTX에 호출 지점을 끼워 넣는 방식이다. 컴파일된 fatbin을 가로채 PTX를 꺼내고, 계측 코드를 합친 뒤 다시 어셈블해 장치에 올린다. 스레드마다 실행하면 분기 발산으로 비용이 커지므로 워프나 스레드 블록당 한 번만 실행하도록 줄이고, 맵을 CPU 메모리에 두면 접근 지연이 커지므로 배치 전략을 따로 두는 식의 최적화가 뒤따랐다.

이렇게 얻는 정보는 기존 도구와 결이 다르다. 예를 들어 커널 실행이 느릴 때, CUPTI 기반 도구는 시작과 종료 시각만 보여주기 때문에 원인이 스레드 블록이 SM을 얻지 못해 기다린 탓인지 알기 어렵다. CPU 쪽 프로브가 기록한 커널 실행 요청 시각과 GPU 진입 시점을 워프 단위로 맞춰 보면 그 차이가 드러난다. 발표자는 이를 오프라인 분석 도구가 아니라 낮은 부담으로 상시 돌리는 온라인 프로파일러로 설명했다.

두 번째 축은 드라이버다. GPU 커널은 사용자 공간 라이브러리가 푸시 버퍼와 도어벨 레지스터로 직접 제출하기 때문에, 스케줄링 단위인 TSG의 시간 분할이나 우선순위 같은 값은 사용자에게 열려 있지 않다. 통합 메모리 역시 페이지 폴트가 나면 드라이버가 정해진 정책대로 메모리를 옮기는데, 이 기본 정책이 느려 많은 팀이 결국 프레임워크에서 메모리를 직접 관리한다. 연구진은 드라이버에 좁고 안전한 훅을 추가해 축출·프리페치 정책과 스케줄링 값을 바깥에서 갈아 끼울 수 있게 만들었고, 발표자는 이 방식으로 오프로딩 성능이 기본 구현보다 나아졌다고 밝혔다.

주요 인사이트

• "관측"과 "확장"은 같은 문제의 앞뒷면이다. 무엇이 일어나는지 볼 수 없으면 정책을 바꿀 근거도 없고, 정책을 바꿀 수 없으면 관측 결과를 활용할 방법도 없다.
• 워크로드마다 메모리 접근 패턴이 크게 다르다는 점이 이 연구의 출발점이다. 벡터 검색, LLM 추론의 프리필과 디코드, 딥러닝 학습은 서로 다른 곡선을 그리며, 하나의 고정 정책이 모두에 맞을 수 없다.
• HBM은 비싸고 용량이 한정돼 있어 전문가 혼합 모델 추론이나 KV 캐시처럼 큰 메모리를 CPU로 내리는 오프로딩이 흔해졌다. 이때 이주 정책의 품질이 곧 체감 성능이 된다.
• 안전성이 핵심 설계 제약이다. 드라이버를 직접 고치는 방식은 강력하지만 유지보수와 안정성 위험이 크고, 그래서 검증기가 붙은 eBPF와 좁게 정의한 인터페이스를 택했다.
• 한 장의 GPU를 여러 작업이 나눠 쓰는 환경이 늘수록, 지연에 민감한 추론과 처리량 위주의 배치 작업을 어떻게 갈라 놓느냐가 중요해진다. 이는 관측 도구가 아니라 스케줄링 정책의 문제다.

자주 묻는 질문

관련 AI 소식