모두
모두콘텐츠
얼마 전 이미지 처리 서비스를 운영하는 분이 GPU서버 견적을 들고 왔습니다. 하루 작업은 두 시간 남짓인데 서버를 한 달 내내 켜두는 조건이었습니다. 처리 속도보다 먼저 확인한 건 실제 작업 시간과 대기열이었습니다. 이 두 가지만 봐도 필요한 사양과 비용이 꽤 달라집니다.
GPU가 필요한 작업부터 구분합니다
웹사이트 방문자가 늘었다고 GPU서버가 필요한 건 아닙니다. 일반적인 게시판, 쇼핑몰, 워드프레스의 페이지 생성과 데이터베이스 처리는 대개 CPU, 메모리, 저장장치가 먼저 병목이 됩니다. GPU는 이미지 생성, 영상 변환의 일부 작업, 모델 학습이나 추론처럼 병렬 연산을 활용하는 프로그램이 있을 때 검토합니다.
먼저 실행할 프로그램이 GPU를 지원하는지 확인해야 합니다. 지원하더라도 특정 드라이버나 연산 환경을 요구할 수 있습니다. 프로그램이 CPU에서만 동작한다면 비싼 GPU를 붙여도 처리 시간은 그대로입니다. 반대로 CPU에서 한 건에 40초 걸리는 작업을 GPU에서 4초에 끝낼 수 있다면, 짧은 시간만 빌려 작업을 몰아서 처리하는 방식이 유리할 수 있습니다. 이 수치는 구매 기준이 아니라 비교 방법을 보여주는 예시입니다.
제가 처음 적는 항목은 세 가지입니다. 한 건을 처리하는 시간, 하루 작업 건수, 결과를 받아야 하는 제한 시간입니다. 하루 1,000건을 처리해도 밤새 순서대로 돌려도 된다면 실시간 서비스와 필요한 장비가 다릅니다.
GPU 메모리와 동시 요청으로 사양을 잡습니다
모델을 실행한다면 GPU의 계산 성능보다 메모리 용량을 먼저 봅니다. 모델 가중치만 들어간다고 끝이 아닙니다. 실행 환경, 중간 계산값, 요청별 데이터도 메모리를 씁니다. 예를 들어 70억 개의 매개변수를 16비트로 저장하면 가중치만 단순 계산으로 약 14GB입니다. GPU 메모리가 16GB라면 남은 공간이 좁아 실제 실행에서 메모리 부족이 날 수 있습니다.
양자화로 가중치를 줄일 수 있지만, 표시된 파일 크기를 그대로 최소 GPU 메모리로 생각하면 곤란합니다. 특히 대화형 모델은 입력 길이와 동시 요청 수에 따라 추가 메모리가 달라집니다. NVIDIA의 운영 문서도 가중치 외에 캐시와 실행 오버헤드를 함께 고려하도록 안내합니다. 처음에는 예상 최대 입력으로 한 건을 실행하고, 이어서 2건과 4건을 동시에 넣어 메모리 최고치와 응답 시간을 기록하는 편이 정확합니다.
처리량도 평균만 보면 놓치기 쉽습니다. 요청 하나가 5초 걸리고 순차 처리한다면 분당 최대 12건이지만, 분당 평균 요청이 8건이라고 해서 언제나 충분한 건 아닙니다. 10초 사이에 8건이 한꺼번에 들어오면 뒤쪽 요청은 기다립니다. 실제 피크 시간대의 동시 요청 수와 응답 시간의 상위 구간을 측정해야 합니다. 대기열을 둘 수 있는 작업이라면 장비를 키우기 전에 허용 대기 시간을 정하는 게 비용을 아낍니다.
월 요금은 켜둔 시간까지 계산합니다
시간당 요금만 비교하면 GPU서버 비용을 낮게 잡기 쉽습니다. 월 비용은 GPU 사용 시간에 시간당 요금을 곱하고, 저장장치·데이터 전송·백업 비용을 더해 계산합니다. 하루 4시간씩 30일 사용하면 GPU 사용 시간은 120시간입니다. 같은 서버를 계속 켜두면 약 720시간으로 잡아야 합니다. 같은 시간당 요금이라도 사용 방식만으로 GPU 사용료가 여섯 배 차이 납니다.
정해진 시간에 파일을 처리하는 작업은 필요할 때 서버를 시작하고 끝나면 종료하는 방식부터 검토합니다. 이때 종료 후에도 디스크나 스냅샷 요금이 남는지 확인해야 합니다. 24시간 응답해야 하는 서비스라면 서버를 껐다 켜는 방식이 맞지 않을 수 있습니다. 요청이 드물다면 CPU 서버로 접수를 받고 GPU 작업을 대기열로 보내는 구조도 가능합니다. 다만 사용자가 즉시 결과를 받아야 한다면 대기 시간과 서버 시작 시간을 먼저 재봐야 합니다.
저렴한 요금제를 비교할 때는 GPU 이름만 보지 않습니다. 할당된 GPU 메모리, CPU와 시스템 메모리, 디스크 속도, 시간당 과금 단위, 중지 중 과금 항목을 같은 표에 적습니다. 공유 GPU 상품이라면 성능 변동 가능성도 확인합니다. 한 번의 시험 실행으로는 피크 시간대의 속도를 알기 어려워 여러 시간대에 같은 작업을 돌려보는 편이 낫습니다.
이전과 장애 대응까지 시험합니다
운영에 들어가기 전에는 기존 환경을 재현할 수 있어야 합니다. 드라이버 버전, 실행 환경, 모델 파일, 설정값을 기록하고 새 서버에서 같은 입력을 처리해 결과와 시간을 비교합니다. 모델 파일이 크면 이전 시간의 대부분이 다운로드에 쓰일 수 있으니 배포 시간을 따로 잽니다. 새 서버가 정상 동작하는 걸 확인한 뒤 요청을 넘기고, 문제가 생기면 이전 처리 경로로 되돌릴 수 있게 둡니다.
백업 대상은 서버 전체가 아닐 수도 있습니다. 다시 내려받을 수 있는 모델 파일보다 직접 만든 데이터, 설정, 작업 결과가 우선입니다. 백업을 저장한 뒤에는 새 환경에서 복원해 실제로 읽히는지 확인합니다. 백업 파일이 있다는 사실과 복구가 된다는 사실은 다릅니다.
장애가 나면 먼저 요청이 서버에 도착했는지, 대기열이 쌓였는지, 프로세스가 살아 있는지 봅니다. 그다음 GPU 메모리와 사용률, 시스템 메모리, 디스크 여유 공간, 오류 기록을 확인합니다. NVIDIA의 관리 도구는 GPU 사용률과 메모리 상태를 볼 수 있고, PyTorch는 실제 할당량과 예약량을 구분해 보여줍니다. GPU 메모리 사용량이 높다는 숫자 하나만으로 누수라고 단정하면 원인을 잘못 짚기 쉽습니다.
GPU서버는 큰 장비를 먼저 고르는 순간 비용이 빠르게 늘어납니다. 실제 입력으로 최대 메모리와 피크 시간 응답을 재고, 한 달에 몇 시간 켜둘지 계산한 뒤 사양을 올리는 순서가 운영하기도 편했습니다.
