GPU 프로파일링 (CUDA) — GPU Flight 소개
Source: Dev.to
왜 GPU Flight를 시작했는가
CUDA 애플리케이션을 프로파일링할 때 보통 다음과 같은 과정을 거칩니다:
- Nsight 같은 프로파일링 도구를 설치
- 혹은 CUPTI를 애플리케이션에 직접 통합하는데, 이 경우 코드가 복잡해지고 관리가 어려워짐
- 클라우드나 컨테이너 환경에서 추가적인 복잡성에 직면
이 워크플로우는 특히 프로덕션 시스템에서 불편할 수 있습니다. 저는 더 가볍고 GPU용 비행 기록 장치처럼 동작하는 무언가를 원했습니다.
GPU Flight는 구조화된 프로파일링 로그를 호스트 머신에 직접 기록합니다. 별도의 구성 요소(GPUFL Agent)가 이 로그 파일들을 수집해 백엔드 서비스나 다른 목적지로 전달하므로, GPU 가시성을 보다 유연하고 분산 시스템에 쉽게 통합할 수 있게 합니다.
GPU Flight란?
GPU Flight는 경량화와 모듈화를 목표로 설계되었습니다.
- 모니터링만 필요하면 오버헤드가 최소 수준
- 더 깊은 프로파일링을 활성화하면 보다 상세한 메트릭을 제공
목표는 유용한 GPU 메트릭을 노출해 다음을 명확히 이해하도록 돕는 것입니다:
- GPU가 자원을 어떻게 관리하는지
- 프로그램이 GPU 자원을 어떻게 활용하는지
- 성능 병목 현상이 어디에서 발생하는지
프로젝트 구조
GPU Flight는 현재 여러 구성 요소로 이루어져 있습니다:
1️⃣ gpufl‑client
https://github.com/gpu-flight/gpufl-client
사용자가 애플리케이션에 삽입해 모니터링 및 프로파일링을 수행하는 클라이언트 라이브러리입니다.
2️⃣ gpufl‑agent
https://github.com/gpu-flight/gpufl-agent
이름과 달리 AI 에이전트가 아닙니다 🙂 로그 파일을 추적하고 프로파일링 데이터를 설정된 목적지로 전달합니다.
3️⃣ gpufl‑desktop
https://github.com/gpu-flight/gpufl-desktop
원래는 데스크톱 뷰어를 목표로 했으나 현재는 웹 기반 프론트엔드에 집중하고 있습니다. 일부 레포지토리는 아직 프로덕션 준비가 되지 않아 비공개이며, 핵심 기능이 안정화되면 공개될 예정입니다.
GPU Flight가 지원하는 메트릭은?
GPU Flight는 여러 계층에서 가시성을 캡처합니다.
1️⃣ 시스템 및 GPU 모니터링 (NVML)
- 호스트 메모리 사용량
- GPU 메모리 사용량 (사용/여유/전체)
- GPU 활용도
- 메모리 활용도
- 온도
- 전력 소비량
- 클럭 속도 (Graphics / SM / Memory)
- PCIe RX/TX 대역폭
- 전력 및 열 스로틀링 플래그
예시 JSON 스니펫:
{
"type": "system_sample",
"util_gpu": 57,
"temp_c": 39,
"power_mw": 54415,
"clk_sm": 1740
}2️⃣ CUDA 디바이스 기능
정적 아키텍처 정보:
- Compute capability
- L2 캐시 크기
- 블록당 공유 메모리
- 블록당 레지스터 수
- SM 개수
- 워프 크기
3️⃣ CUDA API 및 커널 이벤트 (CUPTI)
- API 진입/종료 타임스탬프
- 커널 실행 시작/종료 타임스탬프
- 그리드/블록 차원
- 공유 메모리 사용량
- 레지스터 사용량
- 점유율(Occupancy)
- 상관 관계 ID
- 메모리 복사 이벤트 (HtoD, DtoH)
Python 지원
GPU Flight는 CUDA를 사용하는 Python 애플리케이션(예: PyTorch) 지원을 확대하고 있습니다. 이를 통해 기존 코드를 크게 수정하지 않고도 GPU 집약적인 ML 워크로드를 프로파일링할 수 있습니다.
앞으로의 계획
다음 포스트에서는 최소 CUDA 예제를 직접 살펴보고 다음을 보여줄 예정입니다:
gpufl-client통합 방법- 커널 실행
- 생성된 프로파일링 로그 확인
- 스톨 원인 및 메트릭 해석
읽어 주셔서 감사합니다 — 이것은 시작에 불과합니다.