상품 카탈로그를 운영하는 글쓴이는 야간에 처리해도 되는 AI 작업에 OpenAI와 Anthropic API 비용으로 몇 달간 약 1,000달러를 썼다. 이 경험을 바탕으로 대기 시간을 활용해 저렴한 GPU 자원을 찾고, 여러 단계의 작업을 한꺼번에 관리하는 플랫폼 Otium을 만들었다.
처음에는 두 개의 대형 프롬프트로 상품 정보를 보강하고 중복을 판별했다. OpenAI Batch API로 옮기자 비용은 절반이 됐지만, 여러 작업을 한 프롬프트에 몰아넣은 탓에 설명에 내용 없는 문구가 들어가고 중복 상품도 걸러지지 않는 문제가 이어졌다. 이후 플랫폼별로 프롬프트를 나누고 추출·분류·설명·중복 확인을 별도 단계로 구성해 품질을 개선했다.
하지만 배치 API는 요청을 하나씩 처리하며 요청 간의 관계를 알지 못한다. 단계마다 결과를 모아 다음 요청을 만들고 다시 제출해야 했고, 일곱 단계 작업은 최악의 경우 일주일이 걸릴 수 있었다. 다음 단계가 앞 단계의 잘못된 결과를 읽지 않도록 검증하고 재시도하는 기능도 직접 마련해야 했다. 글쓴이는 이 연결 작업을 Go 코드 수백 줄과 PostgreSQL 테이블로 구현했으며, 이를 사이트에서 가장 신뢰하기 어려운 부분이었다고 설명한다.
이후 AWS 서울 리전의 스팟 GPU 인스턴스에서 vLLM과 오픈 웨이트 모델을 실행해 같은 작업을 처리했다. 글쓴이는 추출과 분류 작업에 필요한 품질은 충분했고, 주말 비용은 API로 같은 작업을 했을 때보다 훨씬 적었다고 말한다. 스팟 용량은 클라우드 사업자가 판매하지 못한 자원을 회수할 수 있다는 조건으로 할인해 제공하는 방식이다. 자료에 따르면 한국의 주말에는 해당 인스턴스 수요가 낮아 저렴했으며, 같은 인스턴스 유형도 시간과 지역에 따라 가격이 달라질 수 있다.
글쓴이가 제시한 2026년 9월 자체 가격 지수에서 A10G 스팟 인스턴스의 온디맨드 대비 할인율 중앙값은 51%, H100은 64%였다. 같은 달 A10G 가격은 지역별로 가장 싼 곳과 비싼 곳 사이에 10.2배 차이가 났다. 월요일 전까지 결과를 내면 되는 작업은 기한 안에서 저렴한 시간과 지역을 찾아 실행할 수 있지만, 즉시 응답해야 하는 작업은 그러기 어렵다는 것이 글쓴이의 설명이다.
Otium은 작업 전체를 하나의 파이프라인으로 받아 실행 순서와 병렬 처리 가능성을 파악하고, 마감 시간 안에 저렴한 GPU 자원을 찾도록 설계됐다. 고객은 기기나 지역 대신 얼마나 기다릴 수 있는지를 정한다. 글쓴이는 대기 시간이 길수록 스케줄러가 선택할 수 있는 시간과 지역이 늘어나므로 비용도 낮아질 수 있다고 설명한다. 배치에 반복되는 프롬프트 앞부분을 따뜻하게 유지되는 모델에서 재사용해 같은 내용을 매번 다시 처리하지 않도록 하는 방식도 적용했다.
Otium에서는 한 YAML 문서로 파이프라인을 작성한다. 단계는 프롬프트, 사용자가 운영하는 HTTP 엔드포인트 호출, 외부 시스템이나 사람의 응답 대기 중 하나로 구성할 수 있다. 컴파일러는 단계가 어떤 결과를 참조하는지 읽어 실행 그래프를 만들고, 실행 전에 병렬 단계와 예상 소요 시간, 비용을 알려준다. 각 단계의 결과는 스키마에 맞는지 검사하며, 다음 단계로 넘기기 전에 재시도하거나 더 큰 모델로 보낼 수 있다. 미리 준비한 결과를 이용해 오프라인에서 파이프라인 전체를 단위 테스트하는 기능도 있다.
Otium은 오픈 웨이트 모델을 사용한다. 글쓴이는 이를 가격뿐 아니라 공급업체의 지원 종료 일정에 따라 기반 모델이 사라지는 상황을 피할 수 있다는 점에서도 중요하게 본다. 프롬프트와 결과는 사용자가 소유한 키로 암호화하고 정해진 일정에 따라 삭제하며, 학습에 사용하지 않는다고 설명한다.
Otium은 10월 중순부터 운영 중이며, 현재 유료 고객은 글쓴이의 카탈로그 사이트 한 곳이다. 스팟 용량 계층, 데이터 암호화 형식, Hugging Face 클라이언트는 Apache-2.0 라이선스로 공개했지만 스케줄러와 워크플로 엔진은 공개하지 않았다. 서비스는 비공개 알파 단계다.
글쓴이는 Otium 사용 여부와 관계없이 야간·주간 AI 작업에서 기다릴 사람이 없는 일을 대기 중인 업무와 분리하고, 각 단계의 출력을 스키마로 검증하며, 필요한 시점을 기준으로 마감 시간을 정하라고 권한다. ‘가능한 한 빨리’는 필수 요건이 아니라 비용이 가장 많이 드는 기본 설정일 수 있다는 설명이다.
관련 자료: 스팟·선점형·잔여 GPU 컴퓨팅, OpenAI Batch API에서 이전하기, 연쇄 호출에서 하나의 파이프라인으로, 워크플로 인식 추론: 요청이 잘못된 단위인 이유, AI 작업의 마감 시간 정하기, LLM 추론 요청의 실제 비용
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요