천이백만원을 들여 5090을 갖춘다고 쳐보자. 그런데 99%의 시간 동안 놀린다면? 아주 비싼 인테리어다.
물론 가격은 가정이고, 사용률도 내 예상이다. 남들은 잘 쓸지 몰라도 나는 안다. 새 모델이 나오면 며칠 신나게 돌리고, 나머지는 코드 고치고 자료 읽다가 보낼 사람이라는 걸.
그래서 안 샀다. 대신 RunPod에서 필요할 때만 GPU를 빌렸다. 궁금한 건 간단했다. 가끔 실험하는 정도라면, 이걸로도 충분하지 않을까?
GPU를 살까 말까 고민할 때는 가장 열심히 쓸 날만 상상하게 된다. 새 모델을 돌리고, 밤새 학습을 맡기고, 아침에 결과를 확인하는 나. 그런데 실제 주인은 평소의 나다. 논문을 읽다가 다른 글로 새고, 설치하다가 오늘은 여기까지만 하자고 할 사람. 성능을 갖고 싶은 마음과 꾸준히 계산을 시킬 능력은 별개였다.
임대도 귀찮기는 하다. 계정과 키를 챙기고, 실행환경을 정하고, 결과를 어디에 둘지 생각해야 한다. 이번 실험은 그 귀찮음이 없다는 주장이 아니다. 한 번 준비한 것을 재사용하면, 큰돈을 먼저 쓰지 않고도 하고 싶은 일을 끝낼 수 있는지 확인해본 쪽에 가깝다.
빌린 GPU로 60초 음악을 만들었다
작은 언어모델에서 짧은 답변만 받으면 좀 싱겁다. 그래서 ACE-Step 1.5로 실제 음악을 만들었다. RTX 5090 한 장에 turbo 2B DiT와 4B 언어모델 등을 올렸다. 사용한 가중치는 약 14.7GB. 60초짜리 instrumental lo-fi를 생성하고 원본 파일을 내 PC로 가져왔다.
처음에는 Qwen2.5-1.5B로 짧은 답변을 받아봤다. 준비물을 재사용한 새 5090에서 결과를 받기까지 31.9초, 33.2초, 40.2초였다. 꽤 괜찮았지만, 이 정도 작은 작업만으로 GPU 구매의 대안을 이야기하기에는 아쉬웠다. ACE-Step으로 바꾼 건 그래서다. 모델도 더 무겁고, 직접 들어볼 수 있는 결과도 남는다. 다만 두 모델은 환경과 작업이 달라 숫자를 곧장 성능비로 비교하지 않았다.
관리 화면에 GPU가 떴다고 측정을 끝내진 않았다. 모델을 준비하고 음악을 만든 뒤, 내 PC에 파일이 도착할 때까지 쟀다.
| 시작 상태 | 음악 파일을 받기까지 |
|---|---|
| 빈 저장소에서 처음 준비 | 약 12분 8초 |
| 모델·환경을 남기고 새 Pod 할당 | 3회 중앙값 약 2분 59초 |
| 모델이 이미 올라간 같은 Pod | 추가 3회 중앙값 약 11초 |
마지막 조건의 생성 자체는 중앙값 약 6.9초였다. GPU 접속은 캐시 재사용 3회에서 중앙값 약 27초였지만, 접속과 음악 생성 준비 완료는 다른 일이었다.
처음 준비에서는 의존성 설치에 213초, 모델 다운로드에 40초가 들었다. 막연히 다운로드가 다 잡아먹을 줄 알았는데 그렇지도 않았다. 설치와 초기화도 만만찮았다.
새 Pod 세 번의 음원 회수시간은 201.8초, 165.9초, 178.6초였다. 새 Pod라는 건 켜져 있던 GPU에서 프로세스만 다시 실행했다는 뜻이 아니다. 기존 Pod를 반납한 뒤 다른 Pod를 만들고 같은 저장소를 연결했다. 다만 서로 다른 물리 서버였는지와 공급자 쪽 캐시까지는 통제하지 못했다.
원격이 로컬처럼 즉시 준비되는 건 아니다. 다만 나는 이미 코딩 에이전트에 일을 맡기고 기다리는 생활을 한다. 그 흐름에 3분 정도의 준비시간을 넣을 만한지가 중요했다. 내게는 해볼 만했다. 결과를 보며 연속으로 프롬프트를 고칠 때는 GPU를 유지하는 편이 훨씬 편했고.
GPU는 반납하고, 모델은 남기면 된다
“로컬에는 모델 캐시가 있잖아.” 맞다. 그런데 임대한다고 파일까지 매번 버려야 하는 건 아니다.
RunPod의 network volume에 모델과 실행환경을 남기고, 다음 Pod에 다시 연결했다. 같은 저장소에는 S3 호환 API로도 접근할 수 있다. RunPod이 제공하는 경로이지, 별도 AWS S3 버킷을 썼다는 뜻은 아니다.
보관함과 작업대를 나눠놓았다고 생각하면 쉽다. 작업대는 잠깐 빌렸다 돌려주고, 다음에도 쓸 준비물은 보관함에 둔다. 같은 파일을 Pod에서는 마운트한 파일시스템으로, 밖에서는 S3 도구로 다룰 수 있었다.
Ceph를 아는 사람이라면 RADOS 위에 파일·블록·객체 인터페이스를 얹는 구성을 떠올릴 수 있다. 다만 이것은 개념을 이해하기 위한 비유다. RunPod 내부가 Ceph라는 것을 확인한 건 아니고, Ceph에서도 파일시스템과 S3가 저절로 같은 파일을 공유하는 건 아니다. 이번에 확인한 것은 RunPod이 제공하는 접근 방식이다.
Pod가 0개일 때도 표식 파일을 쓰고 읽었고, 큰 가중치의 크기와 64KB 구간을 확인했다. 이후 새 Pod에서는 사용 가중치 전체의 hash를 대조했다. 모델 전체를 S3로 왕복 전송하는 시험까지 한 것은 아니다.
중요한 건 캐시에도 층이 있다는 점이다. 모델 파일이 저장소에 있는 것과 모델이 GPU 메모리에 올라가 있는 것은 다르다. 다운로드를 생략해도 Python 패키지를 읽고 가중치를 확인하고 모델을 초기화하는 시간은 남는다. 새 Pod의 약 3분과 상주 상태의 약 11초 차이를 보면 이 구분이 꽤 실감 난다.
당시 단가로 60GB 보관비는 월 $4.20이었다. GPU를 한 달에 7.2시간 빌린다고 가정하면 시간당 $1.19 × 7.2시간에 저장소를 더해 약 $12.77이다. 여기서 7.2시간은 계산뿐 아니라 설치·기동·대기까지 포함한 할당시간이다. 실제 월 청구액이나 구매와의 손익분기 계산은 아니다.
저장소는 GPU를 반납해도 비용이 계속 든다. 다음에도 쓸 모델을 남길지, 실험이 끝났으니 지울지는 따로 결정해야 한다. 이번에는 재사용을 확인한 뒤 더 쓸 계획이 없어 저장소까지 정리했다.
한 달에 7.2시간을 어떻게 쓰는지도 중요하다. 긴 작업 몇 번으로 채우는 것과 짧은 작업을 수십 번으로 쪼개는 것은 기동 횟수가 다르다. GPU가 계산하는 시간이 같아도 임대시간은 달라질 수 있다. 저장소 비용을 계산하고 나니, 다음 질문은 자연스럽게 GPU를 언제 끌 것이냐가 됐다.
그렇다고 매번 끄면 더 쌀까?
음악을 받고 바로 다시 만들 수도 있고, 한참 듣다가 돌아올 수도 있다. GPU도 캐시처럼 잠깐 붙잡아두면 어떨까. 다음 요청이 곧 올 것 같으면 보존하고, 안 올 것 같으면 반납하는 것이다.
CPU 캐시나 Redis, LLM의 prefix cache에도 비슷한 고민이 있다. 다시 필요할지 모르는 준비물을 얼마나 오래 남길 것인가. GPU는 여기에 시간당 요금이 붙는다. 너무 일찍 지우면 다시 준비하느라 기다리고, 너무 오래 남기면 아무 일도 안 하는 장비에 돈을 낸다. 여기서 말하는 투기적 보존과 셧다운은 그 다음 사용을 예상해 결정한다는 뜻이다.
네 정책으로 각각 음악을 네 번 만들었다. 응답을 받은 뒤 5초, 25초, 180초를 쉬고 다음 요청을 보냈다.
| GPU 관리 방식 | 평균 응답시간 | 정책 구간 GPU 비용 추정 |
|---|---|---|
| 계속 유지 | 12.6초 | $0.0984 |
| 매번 즉시 반납 | 149.4초 | $0.2000 |
| 20초 기다렸다 반납 | 111.2초 | $0.1704 |
| 과거 사용 간격으로 유예시간 조절 | 59.1초 | $0.1208 |
예측 정책은 과거에 얼마나 쉬었는지를 지수이동평균으로 갱신하고, 그 값의 4배만큼 기다렸다. 최소 5초, 최대 60초다. 초기 예상 간격은 10초, 새 관측의 반영 비율은 50%로 정했다. 미래 요청 시각을 미리 알려주지는 않았다. 비용 최적화 알고리즘이라기보다 간단한 규칙을 실제로 시험한 것이다.
예를 들어 첫 유예시간은 10초의 4배인 40초다. 다음 요청이 응답 후 5초 만에 오면 예상 간격은 7.5초, 유예시간은 30초로 바뀐다. 그다음 간격이 25초면 예상은 16.25초가 되고, 4배 값이 상한을 넘어 유예시간은 60초가 된다. 어떤 관측을 보고 언제까지 기다리는지 설명할 수 있는 정도의 규칙이다.
각 요청은 앞의 음악을 받은 뒤에 보냈다. 따라서 같은 25초를 쉬어도 앞 응답이 늦으면 다음 요청도 늦어진다. 모든 정책에 동일한 시각의 요청을 쏟아부은 부하 시험은 아니다. 정책별 최초 모델 준비는 비교 구간에서 제외했지만, 전체 실험 비용에는 포함했다.
재밌게도 즉시 반납이 계속 유지하는 것보다 약 103% 비쌌다. 다시 GPU를 받고 모델을 올리는 동안에도 비용이 들기 때문이다. 20초 뒤 껐는데 25초 뒤 다시 필요하면, 5초 아끼려다 훨씬 오래 기다릴 수 있었다.
그렇다고 항상 켜두라는 결론도 아니다. 별도의 L4 짧은 텍스트 실험에서는 5분 공백에 GPU를 반납해 비용을 40.5% 줄였다. 대신 전체 완료시간이 32.7% 늘어, 미리 정한 시간 증가 20% 이하 목표에는 실패했다. 모델과 공백이 달라지면 답도 달라졌다.
예측 정책도 계속 유지하는 것보다 싸거나 빠르지는 않았다. 이 세션에서는 다음 작업이 돌아오기까지의 준비비가 컸다. 특히 가장 긴 공백도 3분이었으니, 이 결과만으로 몇 시간 뒤 돌아올 GPU까지 붙잡아둘 이유는 없다. 반납 버튼을 자주 눌렀다는 사실보다, 재기동을 포함해 총 얼마 동안 빌렸는지가 중요했다.
내가 가져갈 운영법은 이 정도다. 모델 파일은 남겨두고, 연달아 만지는 동안은 GPU를 유지하고, 긴 공백에는 반납한다. 취미 실험에 예측 서버까지 새로 운영할 필요는 없겠다.
빌려 쓸 만했다. 내 경우에는
이번 ACE-Step 실험에서는 총 23회 생성해 모두 60초 음원으로 회수·검증했다. 같은 seed라도 비교한 네 실행 중 하나는 PCM이 달랐다. 유효한 결과를 받았다는 것과 파형까지 똑같이 재현됐다는 것은 구분했다. 음질 우열을 평가한 실험도 아니다.
파일은 48kHz stereo FLAC으로 회수했고, 길이와 유한한 sample, RMS, 파일·PCM hash를 확인했다. 모델 가중치도 고정한 원본과 대조했다. 음악이 나왔다는 것만 보고 성공으로 끝내지 않으려는 확인이었다. 그렇다고 파일 검증이 감상 평가를 대신하지는 않는다.
새 Pod 재사용은 3회, 보존 정책은 각각 한 세션이다. 공급자 캐시와 물리 호스트를 통제하지 않았고, 같은 조건의 로컬 5090과 비교하지도 않았다. 이 숫자로 모든 사용자의 구매 결정을 대신할 수는 없다.
그래도 나처럼 가끔 모델을 만지는 사람에게는 꽤 괜찮았다. 큰돈을 먼저 쓰지 않고도 실제 음악을 만들고, 기다림과 비용을 직접 확인할 수 있었다. 자주 쓰고 즉각적인 반응이 필요하다면 소유의 편리함에도 값어치가 있을 것이다.
실험을 마친 뒤 GPU와 network volume은 모두 삭제했다. ACE-Step 전체 자원비는 약 $1.27 추정이다. 최초 준비와 재기동 등을 포함하고, 세금과 에이전트 비용은 제외한 미확정 금액이다. 수치와 단가는 2026년 10월 실험 당시 기준이다.
반납 전에 결과를 챙기는 것도 빼먹으면 안 된다. 다시 받을 수 있는 모델 파일과 내가 만든 음악·실험 기록은 사정이 다르다. 저장소가 Pod보다 오래 산다고 별도 백업까지 생기는 것은 아니다. 결과를 로컬로 가져와 확인한 다음 자원을 지웠다. 집에 놀리는 GPU를 두기 싫어서 시작했는데, 클라우드에 켜둔 채 잊어버리면 좀 웃기니까.
여기까지 읽으면 꽤 합리적인 소비철학처럼 보인다.
사실 그냥 돈이 없어서 못 샀다.
그래서 빌렸고, 궁금한 걸 재봤다. 실험은 재밌었다. 돈이 생기면 입장이 달라질 수 있으니 너무 진지하게 받아들이지는 말아주시길.
실험 자료
음원은 원 실험에서 회수한 FLAC을 감상용 MP3로 변환한 파일입니다. 본문과 음원은 같은 고정 커밋의 공개 자료에서 가져왔습니다.