수 주간의 상주 VRAM 데이터로 온프레미스 GPU 규모 산정하기
사양 시트는 카드의 메모리를 알려주지만, 컨테이너가 유휴 상태에서 실제로 보유하는 메모리 양은 알려주지 않습니다. 다음은 몇 주간의 상주 VRAM 측정값을 통해 단일 온프레미스 GPU의 크기를 파악한 과정입니다.
ML 추론 워크로드를 클라우드에서 단일 온프레미스 장비로 옮길 때 가장 먼저 드는 질문은 GPU 하나로 충분한지 여부입니다. 사양서의 답은 여기서는 소용이 없습니다. 이를 결정하는 것은 컨테이너가 유휴 상태일 때 실제로 차지하는 메모리와 부하 상태에서 도달하는 최대치입니다. 저는 몇 주 동안 동일한 이미지를 실행해 온 세 개의 클라우드 GPU에서 상주 VRAM을 읽어 온프레미스 GPU의 사양을 정했는데, 그 수치들을 보니 결정이 명확해졌습니다.
상주 메모리가 기준이지, 사양표가 아닙니다
시작 시 모델을 로드하는 추론 컨테이너는 작업 간에 해당 메모리를 해제하지 않습니다. 다음 요청에서 콜드 로드 비용이 발생하지 않도록 전체 모델 세트를 상주 상태로 유지합니다. 따라서 여러분의 기준을 설정하는 수치는 카드 크기도 아니고 요청 중의 최고치도 아닙니다. 컨테이너가 유휴 상태일 때의 안정적인 상주 메모리 공간입니다.
그 메모리 공간은 실제 워밍업된 프로세스에서 측정하기 전까지는 보이지 않습니다. 부팅 직후의 새로운 컨테이너는 일주일 동안 작업을 처리한 컨테이너보다 더 낮게 측정됩니다. 이는 할당자 단편화와 캐시 증가로 인해 시간이 지남에 따라 상주 집합이 증가하기 때문입니다. 콜드 리딩을 기준으로 크기를 정하면 실제보다 작게 잡게 될 것입니다.
측정 결과
클라우드에 있는 세 개의 GPU가 각각 23GB 카드에서 동일한 이미지를 실행하고 있었습니다. 저는 세 GPU 모두 유휴 상태일 때 추론 컨테이너의 상주 VRAM을 측정했습니다.
| GPU | 상주 VRAM (유휴) | 참고 |
|---|---|---|
| A | 15,322 MiB | 단일 장기 실행 프로세스, 6주 이상 가동 |
| B | 17,382 MiB | 관찰된 최고치 |
| C | 13,676 MiB | 관찰된 최저치 |
동일한 이미지들에서 13.7GB에서 17.4GB까지 편차가 나타나는 것이 단편화 효과입니다. 컨테이너는 부팅 시 전체 모델 세트를 로드하고, 프로세스가 실행되는 동안 13.7GB에서 17.4GB를 상주 메모리로 유지합니다. 평균보다 더 중요한 것은, 몇 주간의 프로덕션 환경에서 해당 상주 세트 위에서 실행되는 최대 추론이 23GB 카드 용량 내에 머물렀다는 점입니다. 상주 메모리와 활성 메모리의 합이 카드 용량을 초과하지 않았습니다. 이것은 사양 시트에서는 얻을 수 없고, 오직 실제 트래픽을 받는 워밍업된 프로세스에서만 확인할 수 있는 사실입니다.
헤드리스 부팅으로 데스크톱이 빼앗아 간 것을 되찾기
온프레미스 장비는 워크스테이션이었으며, 전체 데스크톱으로 부팅되었습니다. 추론 컨테이너가 시작되기도 전에 디스플레이 관리자와 컴포지터가 수백 MiB의 GPU 메모리를 점유하고 있었습니다. 아무도 로그인하지 않는 워크스테이션에서, 이는 사용자가 크기를 조정하려는 바로 그 리소스를 차지하는 순전한 낭비입니다.
기본 부팅 대상을 헤드리스로 전환하고 디스플레이 관리자를 비활성화하자 해당 메모리가 GPU로 반환되었습니다. 전환 후, 아무도 사용하지 않을 데스크톱에 의해 점유되는 것 없이 GPU 프로세스는 추론 컨테이너만 남게 되었습니다. 빠듯하게 크기를 조정하는 경우, 데스크톱을 끈 상태에서 측정하십시오. 이것이 프로덕션 환경에서 장비가 실제로 실행되는 방식이기 때문입니다.
사이징 결정
온프레미스 카드는 24GB GPU로, 워크로드가 적합하다는 것을 이미 증명한 23GB 클라우드 카드보다 약 1.5GB 더 컸습니다. 데스크톱을 비활성화하면 컨테이너의 상주 집합은 약 15GB(최악의 경우 17.4GB)가 되어, 이미 성능이 입증된 카드보다도 더 큰 카드에서 추론 피크를 위한 7~11GB의 헤드룸이 남았습니다. 두 번째 GPU도, 업그레이드도 필요 없었습니다. 카드 하나로 충분했으며, 몇 주간의 클라우드 데이터는 제가 오후에 실행할 수 있었던 어떤 벤치마크보다도 더 확실하게 이 사실을 뒷받침했습니다.
구매 전에 측정해야 할 것
일반적인 방법은 상주 메모리 사용량이 많은 모든 추론 워크로드에 적용됩니다.
- 새로 부팅한 상태가 아니라 며칠 동안 실제 트래픽을 처리해 온 프로세스의 상주 VRAM을 읽으십시오. 평균이 아닌 동일한 인스턴스들 중에서 최댓값을 취하십시오.
- 프로덕션 환경에서 정상 작동이 확인된 카드 내에서 상주 메모리 + 추론 피크가 유지되었는지 확인하십시오. 그 단 하나의 사실이 수많은 합성 벤치마크를 대체합니다.
- 해당 장비가 워크스테이션인 경우, 데스크톱이 여러분이 예상했던 헤드룸을 빼앗아가지 않도록 디스플레이 관리자를 끈 상태에서 측정하십시오.
- 최악의 경우 상주 메모리 + 피크를 여유롭게 처리할 수 있는 크기의 카드를 구매하고 거기서 멈추십시오. 필요하지 않은 GPU는 랙에서 가장 비싼 유휴 하드웨어입니다.
관련 글
멀티테넌트 SaaS를 에어갭 박스로 뜯어내기
클라우드 SaaS를 단일 온프레미스 어플라이언스로 제공하는 것은 배포 변경이 아닙니다. 이는 적절한 위치에서 테넌트, 크레딧, 관리형 인증 및 모든 클라우드 종속성을 제거하는 것을 의미합니다.
Redis 키스페이스 알림 및 리스를 사용한 GPU 워커 풀 로드 밸런싱
GPU는 비싸고 한 번에 하나의 무거운 작업만 실행하므로, 라운드 로빈 라우팅은 바쁜 워커 뒤에서 지연됩니다. 여기에 Redis 리스와 키스페이스 알림으로 구축된 바쁨 인지 스케줄러가 있습니다.