코드 한 줄 수정 없이 LLM API 비용을 70% 절감한 방법
요약
LLM API 비용을 절감하기 위해 코드 수정 없이 제공업체를 전환하는 방법을 소개합니다. OpenAI 호환 API 게이트웨이를 활용하여 기존 로직을 유지하면서도 더 저렴한 모델로 라우팅하는 전략을 다룹니다.
핵심 포인트
- OpenAI SDK 중심의 코드베이스를 유지하며 비용 절감 가능
- API 제공업체별 토큰당 가격 차이를 활용한 비용 최적화
- 유니버설 API 게이트웨이를 통한 모델 라우팅 전략
- 통합 레이어 재작성 없이 모델 마이그레이션 구현
나는 매달 날아오는 API 청구서를 바라보며, 익숙한 공포와 불신이 뒤섞인 감정을 느끼고 있었다. 지난달 비용은 212.43달러였다. 아직 수익조차 발생하지 않는 사이드 프로젝트(side project) 치고는 너무 큰 금액이었다. 프롬프트(prompt)를 최적화하고, 토큰(token) 수를 줄이고, 심지어 캐싱(caching)까지 추가했다. 하지만 비용은 계속해서 치솟았다.
그러다 문득 깨달았다. 나는 잘못된 것을 최적화하고 있었다는 것을. 병목 현상(bottleneck)은 내 코드가 아니었다. 바로 내가 사용하는 API 제공업체(API provider)였다.
애플리케이션 로직을 단 한 줄도 바꾸지 않고, 어떻게 월 지출액을 200달러 이상에서 약 60달러 수준으로 낮출 수 있었는지 보여주겠다.
경종을 울린 사건
내 프로젝트는 콘텐츠 분석 도구이다. 기사를 가져와 요약하고, 엔티티(entities)를 추출하며, 메타데이터(metadata)를 생성한다. 꽤 전형적인 LLM 파이프라인(pipeline)이다. 나는 모든 작업에 OpenAI의 GPT-4를 사용하고 있었는데, 이유는 단순했다. 그것이 기본(default)이었기 때문이다. 나는 전체 스택(stack)을 OpenAI SDK를 중심으로 구축했기에, 다른 제공업체로 마이그레이션(migrating)한다는 생각은 코드베이스의 절반을 다시 쓰는 것처럼 느껴졌다.
하지만 숫자는 거짓말을 하지 않았다. 2024년 1월, 나의 사용량을 추적해 보았다:
- 입력 토큰(Input tokens): 약 1,200만 개 (대부분 기사 텍스트)
- 출력 토큰(Output tokens): 약 200만 개 (요약 및 구조화된 데이터)
- 총 비용: $212.43
수익이 나지 않는 프로젝트치고는 지속 불가능한 수준이었다.
진짜 문제: 가격 모델 (Pricing Models)
여기서 내가 배운 것이 있다. 모든 LLM API가 동일하게 만들어진 것은 아니지만, 대부분은 같은 언어를 사용한다는 점이다. OpenAI, Anthropic, Google, Mistral, Cohere — 이들은 모두 유사한 요청 형식(역할이 지정된 메시지, 시스템 프롬프트(system prompts) 등)을 사용한다. 차이점은 토큰당 가격에 있다.
당시 GPT-4는 입력 토큰 1K(1,000개)당 0.03달러, 출력 토큰 1K당 0.06달러였다. 내 작업량 기준으로 보면, 방대한 양의 기사를 처리하는 데 입력 토큰 1K당 약 0.36달러가 들었고, 여기에 출력 비용이 추가되었다. 이를 Claude 3 Sonnet과 비교해 보자. Claude 3 Sonnet은 입력 1K당 0.003달러, 출력 1K당 0.015달러였다. 또는 Mistral Large는 입력 0.004달러, 출력 0.012달러였다. 심지어 GPT-3.5 Turbo는 입력 0.0005달러, 출력 0.0015달러였다.
절감액은 엄청났습니다. 때로는 요청당 10배에서 20배에 달했습니다. 하지만 제공업체(Provider)를 바꾸는 것은 통합 레이어(Integration layer)를 다시 작성하고, 서로 다른 에러 형식(Error formats), 서로 다른 속도 제한(Rate limits), 서로 다른 인증 체계(Authentication schemes)를 처리해야 함을 의미했습니다. 바로 그 지점에서 실제 시간이 소요됩니다.
비결: 유니버설 API 게이트웨이 (Universal API Gateway)
그러던 중 모든 것을 바꿔놓은 무언가를 우연히 발견했습니다. 바로 OpenAI 호환 요청을 수락하고 원하는 제공업체로 라우팅(Routing)해주는 통합 API 엔드포인트(Endpoint)였습니다. 표준 채팅 완성(Chat completion) 요청을 보내면, 게이트웨이가 이를 대상 API로 번역하고, 인증을 처리하며, OpenAI 스타일의 응답을 반환합니다.
아이디어는 간단합니다. API 키를 라우터(Router)처럼 취급하는 것입니다. 백그라운드에서 어떤 모델이 어떤 제공업체에 매핑될지 구성하십시오. 여러분의 코드는 그 차이를 전혀 알 필요가 없습니다.
실제 적용 사례는 다음과 같습니다. 저는 다음과 같은 Python 함수를 가지고 있었습니다:
import openai
def summarize_article(text):
...
제가 변경한 것은 베이스 URL(Base URL)과 API 키뿐이었습니다:
import openai
openai.api_base = "https://my-gateway.example.com/v1" # 게이트웨이
...
모델 이름을 claude-3-sonnet으로 변경한 점에 주목하십시오. 게이트웨이는 해당 모델을 인식하여 Anthropic의 API로 요청을 전달하고, 응답을 다시 OpenAI 형식으로 번역했습니다. 제 코드는 상관하지 않았습니다. 그저 choices와 message.content가 포함된 딕셔너리(Dictionary)를 받았을 뿐입니다.
비즈니스 로직(Business logic)은 단 한 줄도 건드리지 않았습니다. 새로운 SDK도, 에러 처리(Error handling)의 재작성도, 속도 제한(Rate limit)의 조정도 필요 없었습니다. 그저 설정(Config) 변경만 있었을 뿐입니다.
나를 설득한 수치들
게이트웨이 기반 방식으로 전환한 후, 저는 다양한 작업에 서로 다른 모델을 사용하는 실험을 시작했습니다. 어떤 작업은 GPT-4의 추론 능력(Reasoning power)이 필요하지 않았습니다. 또 어떤 작업은 고품질의 출력이 필요하지만 더 저렴한 모델을 사용할 수 있었습니다.
2024년 3월 기준으로, 저의 월간 사용 내역은 다음과 같았습니다:
- GPT-4: 복잡한 추론 작업 전용 (쿼리의 약 15%)
- Claude 3 Sonnet: 대부분의 요약 및 분석 작업 (60%)
- Mistral Large: 구조화된 데이터 추출 (20%)
- GPT-3.5 Turbo: 단순 분류 작업 (5%)
해당 월의 총 비용: $58.21. 요청 횟수, 출력 품질, 코드베이스는 모두 동일했습니다.
저는 더 열심히 코딩하는 대신, 더 스마트하게 라우팅함으로써 72%를 절감했습니다.
주의할 점 (항상 예외는 있습니다)
물론 모든 모델이 동일하지는 않습니다. 반드시 테스트를 거쳐야 합니다. 저는 Claude 3 Sonnet이 일부 요약 작업에서는 GPT-4보다 실제로 더 뛰어나지만, 코드 생성 (Code Generation) 측면에서는 더 떨어진다는 것을 발견했습니다. Mistral Large는 구조화된 JSON 출력에는 탁월했지만, 때때로 사실 관계를 환각 (Hallucination) 하기도 했습니다. 게이트웨이 (Gateway) 접근 방식 덕분에 설정 파일에서 모델 이름만 변경하는 것만으로 모델 A/B 테스트를 수행할 수 있었습니다 — 코드 변경은 전혀 필요 없었습니다.
또한, 지연 시간 (Latency)도 제각각입니다. 어떤 제공업체는 다른 곳보다 더 빠릅니다. 이는 엔드포인트 (Endpoint)별로 조정할 수 있는 또 다른 요소입니다.
실질적인 권장 사항 (광고 아님)
직접 구축한 셀프 호스팅 게이트웨이를 몇 달간 사용해 본 후, 저는 또 다른 인프라를 유지 관리하고 싶지 않다는 것을 깨달았습니다. 그때부터 관리형 솔루션 (Managed Solutions)을 찾기 시작했습니다. 제가 원했던 조건은 다음과 같았습니다:
- 여러 제공업체 (OpenAI, Anthropic, Google, Mistral 등) 지원
- OpenAI 호환 API 형식 사용
- 간단한 종량제 (Pay-as-you-go) 모델
- 각 제공업체마다 키를 관리할 필요가 없음
몇 가지 옵션을 찾았지만, 지난 6개월 동안 제가 사용해 온 것은 tai.shadie-oneapi.com입니다. 이것은 정확히 제가 설명한 것과 같습니다: 하나의 API 키와 하나의 베이스 URL (Base URL)을 사용하는 통합 엔드포인트이며, 요청 시 모델 이름만 변경하면 서로 다른 제공업체의 모델 간 전환이 가능합니다. 사용한 토큰 (Token)만큼만 비용을 지불하며, 월간 약정이나 최소 사용량 제한이 없습니다.
세상에 유일한 옵션은 아니지만, 저에게는 아무런 마찰 없이 잘 작동한 옵션입니다. 만약 여러분도 특정 제공업체에 종속되어 API 호출 비용을 너무 많이 지출하고 있는 상황이라면, 살펴볼 가치가 있습니다.
내가 배운 것
가장 큰 교훈은 이것이었습니다: 여러분의 API 비용은 코드가 아니라 제공업체(provider)의 함수입니다. 프롬프트(prompt)를 최적화하고, 응답을 캐싱(cache)하며, 입력을 압축(compress)하는 데 온종일 시간을 보낼 수도 있겠지만, 만약 토큰당 필요한 것보다 10배나 더 많은 비용을 지불하고 있다면 여러분은 잘못된 싸움을 하고 있는 것입니다.
제가 했던 가장 영리한 최적화는 코드 변경이 아니었습니다. 그것은 라우팅(routing)의 변경이었습니다. 그리고 이를 구현하는 데는 약 30분 정도밖에 걸리지 않았습니다.
때때로 최고의 엔지니어링은 더 나은 코드를 작성하는 것이 아니라, 더 나은 인프라(infrastructure)를 선택하는 것입니다.
이제 실례하겠습니다, 저는 지불해야 할 60달러의 월간 청구서와 마침내 현금 흐름(cash-flow)이 플러스로 돌아선 프로젝트가 있으니까요.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기