GPU서버호스팅 필요한 사양부터 고르는 방법

얼마 전 하루 요청이 1천 건이라는 이유로 GPU 서버를 상시 임대하려는 팀을 봤다. 로그를 보니 요청은 업무 시간에 몰렸고, 밤에는 거의 없었다. 이럴 때 먼저 볼 숫자는 하루 방문자 수가 아니다. GPU를 실제로 쓰는 시간과 가장 바쁜 순간의 동시 요청 수다.

GPU가 필요한 작업부터 구분한다

일반 웹사이트, 관리자 화면, 이미지 저장소를 운영하는 데 GPU는 필요하지 않다. GPU서버호스팅은 모델 학습, 자체 운영하는 AI 추론, 대량 영상 변환처럼 GPU 연산이 계속 필요한 작업에 맞는다. 외부 AI 서비스를 호출하는 웹사이트라면 웹서버 사양과 호출 비용을 따로 계산하는 편이 정확하다.

학습은 작업을 한꺼번에 돌리고 끝낼 수 있는 경우가 많다. 반면 이용자 요청에 즉시 답하는 추론 서비스는 대기 시간이 중요하다. 같은 모델이라도 긴 입력을 여러 명이 동시에 보내면 필요한 GPU 메모리가 늘어난다. 모델 이름만 보고 서버를 고르면 실제 요청에서 메모리 부족이 나기 쉽다.

메모리와 동시 요청으로 사양을 잡는다

첫 확인 항목은 GPU 메모리다. 예를 들어 매개변수 70억 개짜리 모델의 가중치를 16비트로 담으면 단순 계산으로 약 14GB가 필요하다. 여기에 실행 환경, 입력 길이에 따라 늘어나는 캐시, 동시 요청을 처리할 공간이 더해진다. 4비트 양자화는 가중치 크기를 줄이지만 실제 사용량이 이론값인 3.5GB로 끝나지는 않는다. 배포할 모델과 입력 길이로 직접 측정해야 한다.

처리량도 시험해 봐야 한다. 한 요청이 평균 2초 걸리고 동시에 4개를 처리한다면 이론상 초당 2건이다. 다만 이 수치로 서버를 꽉 채우면 요청이 잠깐만 몰려도 대기열이 길어진다. 초당 1.2건 정도를 운영 목표로 놓고, 가장 바쁜 5분의 요청량과 응답 시간을 확인하는 식이 현실적이다. 평균 응답 시간뿐 아니라 느린 쪽에 속하는 요청의 시간도 봐야 한다.

모델을 올린 뒤 남는 GPU 메모리와 입력 길이별 최대 사용량
동시 요청을 늘릴 때의 초당 처리 건수와 대기 시간
CPU·시스템 메모리·디스크 읽기 속도가 GPU 작업을 기다리게 하는지

작은 시험 서버로 이 세 가지를 재면 필요한 GPU 수를 추정할 수 있다. GPU 사용률이 낮은데 응답이 느리다면 더 비싼 GPU를 사기 전에 데이터 읽기, 전처리, 요청 대기열부터 확인한다.

시간당 가격보다 한 달 사용 시간을 본다

서버 비용은 시간당 요금에 실제 켜 둔 시간을 곱해 계산한다. 가령 시간당 1,200원인 서버를 평일 하루 8시간씩 22일 쓰면 월 21만 1,200원이다. 하루 24시간씩 30일 켜 두면 86만 4천 원이다. 같은 서버라도 운영 방식에 따라 차이가 크다. 이 숫자는 계산 예시이며 실제 요금은 업체와 지역, GPU 종류에 따라 달라진다.

학습이나 내부 배치 작업은 필요할 때만 켜는 방식이 유리할 수 있다. 이용자 대상 서비스는 서버를 끄면 첫 요청을 받기까지 모델을 다시 올리는 시간이 생긴다. 그 시간을 허용할 수 있는지 확인해야 한다. GPU 요금 외에도 저장 공간, 백업, 외부 전송량, 고정 주소와 관리 도구 비용을 월 예산에 넣는다. 할인된 시간당 가격만 비교하면 여기서 자주 어긋난다.

예약형이나 장기 계약은 사용 시간이 안정된 뒤에 검토한다. 몇 주간의 로그도 없이 먼저 약정하면 쉬는 시간까지 비용으로 떠안기 쉽다. 자체 모델을 꼭 운영할 이유가 약하고 요청량이 적다면 외부 AI 서비스나 작업별 과금 방식도 함께 계산할 만하다.

백업과 장애 대응은 계약 전에 확인한다

GPU 서버는 계산 장치이면서 데이터를 두는 서버이기도 하다. 특히 임시 디스크에 모델 파일, 학습 결과, 고객 데이터를 함께 넣어 두면 서버 중지나 교체 과정에서 잃을 수 있다. 아마존 웹 서비스의 인스턴스 스토어처럼 중지 시 데이터가 유지되지 않는 저장소도 있다. 디스크 이름보다 해당 상품의 데이터 보존 조건을 확인하는 게 먼저다.

운영 데이터는 별도 영구 저장소에 두고, 모델 파일과 설정값은 다시 배포할 수 있게 버전을 남긴다. 백업은 복사 성공 알림으로 끝내지 않는다. 빈 서버에 백업을 복원해 모델이 뜨고 요청에 답하는지 시험해야 한다. 학습 중간 결과도 작업을 처음부터 다시 돌리기 어려운 간격으로 저장한다.

장애가 나면 이용자 요청이 서버에 도착하는지, 프로세스가 살아 있는지, GPU 메모리가 찼는지 순서대로 본다. 그다음 드라이버 오류와 디스크 용량을 확인한다. 엔비디아의 DCGM은 GPU 사용률과 메모리 사용량 같은 지표를 수집하는 데 쓸 수 있다. 이런 기록이 있어야 코드 문제인지 장비 문제인지 가려낼 수 있다.

GPU 서버는 가장 높은 사양을 고르는 일보다 작업을 재고 다시 띄울 수 있게 만드는 일이 중요하다. 처음에는 작은 구성으로 바쁜 시간의 처리량을 확인하고, 부족한 수치가 드러날 때 늘리는 편이 운영도 비용도 덜 흔들린다.