From 15% to 90% GPU Utilization: Fix the Data Pipeline, Not the Model

한 줄 핵심

멀티모달 학습에서 GPU 활용률을 끌어올리는 핵심은 모델 최적화보다 데이터 파이프라인의 병목을 찾아 병렬화, 사전 적재, 무복사 전송으로 GPU가 기다리지 않게 만드는 것이다.

시간별 요약

1. 0:00
   소개 멀티모달 SFT 학습에서 GPU를 계속 바쁘게 유지하는 데이터 파이프라인 설계가 주제이며, 모델 자체보다 전체 학습 생태계의 병목을 보는 관점이 핵심이다.
2. 0:45
   학습은 정말 GPU 병목인가? 학습 루프가 실제로 GPU에 막혀 있는지부터 점검해야 하며, 멀티모달 처리의 어려움은 커널 최적화보다 데이터 공급이 끊기지 않게 만드는 데 있다.
3. 1:10
   네 가지 병목 병목은 크게 동시성, 사전 가져오기, 프로세스 간 데이터 복사 최소화, 그리고 추가적인 프레임워크 최적화로 나뉘며, 이를 하나씩 제거하는 방식으로 접근한다.
4. 1:50
   멀티모달이 CPU 집약적인 이유 이미지·오디오·비디오 전처리에는 로딩, 리사이즈, 정규화 같은 CPU 작업이 많이 들어가고, GPU보다 CPU가 많은 환경에서도 GPU가 오히려 굶주리기 쉽다.
5. 2:45
   대기 시간 비율 데이터 준비와 전송에 쓰는 시간을 전체 파이프라인 시간으로 나눈 지표로 병목을 측정하며, 최적화 후에는 GPU 활용률이 15%에서 90%로 올라간다.
6. 3:35
   우리의 스택 Qwen 3VL 기반 모델을 Chat VQA와 멀티턴 VLM 대화 형태로 학습하며, 데이터 로드·변환·전송이 모두 끝나야 GPU가 계산을 시작할 수 있다.
7. 4:10
   데이터 데이터는 JSONL로 구성되고 이미지는 S3에 저장된 링크로 참조되며, 예시 이미지는 객체 저장소에서 읽어오는 구조를 가정한다.
8. 4:35
   시스템 구성 데이터 생성기가 로드·변환·전송을 담당하고, 메가트론의 데이터 병렬 랭크가 분할된 데이터를 받아 전방·역전파를 수행하는 구조로 설계된다.
9. 5:15
   기본선: 15% 활용률 처음에는 이미지를 하나씩 가져와 하나씩 처리하는 직렬 구조 때문에 배치당 데이터 획득 시간이 100초를 넘고, GPU는 15% 수준만 활용된다.
10. 6:20
    해결책 1: 동시성 샘플들이 서로 독립적이므로 이미지 가져오기와 전처리를 워커 풀로 병렬화하면 배치 단위 처리 속도를 크게 높일 수 있다.
11. 7:05
    Async, 스레드, 프로세스? 네트워크 요청과 같은 IO에는 async가 적합하고, GIL을 놓는 CPU 작업에는 스레드가 유용하며, 완전한 격리가 필요하면 프로세스가 적합하다.
12. 8:10
    Asyncio와 Ray actor 이미지 가져오기는 asyncio로, 처리기는 Ray actor로 구성해 병목 구간을 맞춤형으로 분리하며, 그 결과 배치당 데이터 대기 시간이 약 25% 줄어든다.
13. 9:15
    해결책 2: 프리페칭 백그라운드 스레드가 큐를 미리 채워 소비자보다 항상 앞서가도록 만들면, 훈련 요청 시점에는 데이터가 즉시 준비되어 대기 시간이 거의 사라진다.
14. 10:40
    해결책 3: Ray object store를 활용한 제로 카피 배치마다 이미지 배열이 프로세스 경계를 여러 번 복사하는 비용이 커서, Ray object store의 참조 전달 방식으로 메모리 복사를 줄이고 전송 비용을 낮춘다.
15. 12:20
    요약: 대기 시간 85%에서 20%로 직렬 처리, 동시성 추가, 프리페칭, 제로 카피 전송을 거치며 데이터 대기 비율은 85%에서 20%로 줄고 GPU 활용률은 크게 개선된다.
16. 12:55
    확장: 새로운 병목 규모를 키우자 같은 설정이라도 대기 비율이 다시 상승했으며, 워커와 데이터 생성기가 같은 노드에 몰리면서 다른 병목이 드러난다.
17. 13:25
    네트워크 카드 병목 Ray가 기본적으로 같은 노드에 워커를 배치하는 경향 때문에 한 서버의 네트워크 인터페이스 카드가 포화되고, 노드 간 분산이 필요해진다.
18. 14:35
    분산 스케줄링과 제로 카피 제로 카피 조회와 spread scheduling을 함께 적용해야 소규모에서는 보이지 않던 효과가 대규모에서 나타나며, 전체 파이프라인 처리량이 추가로 50% 향상된다.
19. 15:35
    교훈 GPU 병목처럼 보여도 실제 원인은 CPU, IO, 메모리, 네트워크일 수 있으며, 병목은 하나를 해결할 때마다 다른 형태로 이동하므로 항상 기준선을 프로파일링해야 한다.

실무 인사이트

• 멀티모달 학습 최적화는 모델보다 데이터 경로를 먼저 의심해야 하며, 특히 배치당 대기 시간이 길면 전처리와 전송 단계가 우선순위다.
• 동시성, 프리페칭, 제로 카피는 각각 독립적인 개선이 아니라 서로 다른 병목을 겨냥하므로, 한 단계씩 적용하며 프로파일링해야 효과를 정확히 판단할 수 있다.
• 작은 규모에서 효과가 약해 보여도 확장 시 네트워크·배치·스케줄링 병목이 갑자기 드러나므로, 대규모 기준으로 설계를 검증해야 한다.