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통합- 커널 실행
- 생성된 프로파일링 로그 확인
- 스톨 원인 및 메트릭 해석
읽어주셔서 감사합니다 — 이것은 시작에 불과합니다.