Project HowAbout RAG API - Outro: Optimization - TPM 문제 정의

개선 동기

현재 프로젝트를 위해 만든 RAG API의 경우 Retrieval과정에서 들어오는 Query에 대한 Embedding과 Multiple Query Generation 생성과정에서도 외부 Model API를 사용한다.(OpenAI API: text-embedding-3-large & gpt-4o) 그렇다 보니 TPM이라는 에러가 발생할 요소가 있었다. 또한 Vector Store를 만드는 과정이었던 Data Ingestion 파트에서도 일정 수준의 데이터가 들어가면 바로 TPM 문제가 발생할 가능성이 다분했었다. 물론 발생하기 전까지는 그런 문제가 전형 없다고 생각했으나 되려 발생해서 다행이라고 생각했다. 그래서 추후 외부 Model API를 사용할 수 있는 상황을 대비하여 구현된 프로젝트에서 개선해 보려고 한다.

 

문제 설명

먼저 TPM 문제는 Rate Limits를 감안하지 않기 때문에 발생한다. 기본적으로 외부 API의 경우 요청 남용등과 같은 문제를 예방하기 위해 재한을 설정해 놓는다. 그래서 외부 API를 사용하는 부분에 있어서는 Rate limits을 감안하여 구현해야 한다. 이번에 구현한 프로젝트에서 Rate Limits에 대한 예방을 구현해야 하는 부분들은 아래와 같다.

1. Vector Store 생성 파트
   • text-embedding-3-large
2. Query Translation 파트
   • Query Embedding: text-embedding-3-large
   • Multi Query Generation: gpt-4o
3. Generation 파트
   • Multi Query Generation: gpt-4o

 

그리고 위의 해당하는 Model들의 Rate Limits은 아래의 링크를 통해 자세히 확인할 수 있다.

OpenAI 공식문서: Rate limits - OpenAI API (기본적으로 Tier1을 넘어서기는 어렵기 때문에 Tier1 기준으로 설명하겠다.)

그리고 아래의 사진처럼 위의 사용된 모델들의 Rate limits를 확인할 수 있다.

OpenAI API: Tier1 rate limits

그래서 결론적으로 이번 프로젝트에서의 TPM은 아래와 같다.

• text-embedding-3-large: 100만 개
• gpt-4o: 3만 개

그리고 인지하지 못한 Rate Limits이 하나 더 존재했다. 바로 '비용'이다. GPT-3.5-Turbo를 사용했을 당시에는 크게 체감하지 못했으나 4o와 Data Ingestion과정에서 비용의 문제가 크게 다가왔다. 그래서 추가적으로 Pricing의 경우 아래와 같다.

OpenAI API: 비용 관련 페이지

내용이 너무 많아 자신이 사용하는 모델을 찾아서 확인하는 게 빠르다. 그런데 내가 사용한 모델의 경우는 아래와 같다.

• text-embedding-3-large: $0.000020 / 1K tokens
• gpt-4o: $0.00500 / 1K input tokens

TPM문제가 발생했다는 것은 최소 100만 개의 Token을 사용했다는 건데 이게 쌓이다 보면 비용이 만만치 않다는 것을 알게 됐다. 이러한 재한과 Rate limits 발생 가능성을 봤을 때 아래와 같은 접근을 생각할 수 있다.

 

해결 도출 

먼저 OpenA 공식문서에서는 문제 발생 시 아래와 같은 해결 방안을 먼저 추천한다.

1. 재시도: Exponential Backoff
   • Exponential Backoff의 경우 error 발생시 랜덤 하게(합리적인) 요청을 멈춰(sleep)하여 실패한 요청을 재요청해서 적절한 멈춤 시간을 찾아가는 과정을 말한다. 그리고 이를 위해서 아래와 같은 외부 라이브러리들을 사용할 수 있다고 한다.
     1. Tenacity Library
     2. Backoff Library
     3. Manual Implementation: 이 부분에서 의도하지 않았으나 Vector Store생성에서 유사하게 사용하였다.
2. 배치 요청의 경우 대표적으로 Batch API를 사용함으로써 가격과 TPM을 방지할 수 있다. 이 요청의 경우 인위적으로 요청을 나눠 시간을 두고 요청하는 것으로 즉각적인 대답이 필요할 경우 적합하지는 않다.

여기서 알 수 있듯이 개선할 수 있는 기준은 OpenAI API로 처리 해야할 요청이 즉각적으로 처리되야 하는지 아닌지를 기준으로 생각할 수있다.(즉시성)

 

하지만 비용의 문제도 있고 항상 OpenAI API를 사용한다는 보장이 없기 때문에 구조적인 그리고 Task에 따른 모델의 세분화도 시도해 볼만하다고 판단 했다. 

 

그래서 아래와 같이 각 파트별로 나눠서 구현을 진행하기로 결정했다. 현재 단계에서는 아래와 같이 적용해 볼 수 있다.

1. Vector Store 생성 파트
   • 사용 토큰 수 조정
   • Batch 적용
   • Embedding Model 변경
2. Query Translation & Generation 파트
   • Tenacity 혹은 Backoff 적용

그래서 먼저 Vector Store 개선 그리고 Query Translation & Generation 파트 개선을 구현할 예정이다.

참고 자료

OpenAI Rate Limtis