비용 vs 응답 품질

프로토타입을 넘어 수백~수백만 request로 확장하면 비용이 점점 중요해진다. 이번 편은 고품질 응답을 유지하면서 비용을 줄이는 전략을 정리한다. 일반적 RAG의 가장 큰 두 비용은 벡터 DB와 LLM이다.

그림 1. RAG의 두 주요 비용원 — 벡터 DB(저장·쿼리)와 LLM(추론·생성).

 

 

1. LLM 비용 줄이기 — 작은 모델 · 짧은 프롬프트

첫째, 더 작은 모델을 실험한다. 최종 응답을 만드는 core LLM이든 agentic의 router LLM이든, 작고 싼 모델로 비슷한 전체 품질을 낼 수 있다. 모델이 작은 이유는 애초에 파라미터가 적거나, 값이 8비트로 양자화됐기 때문이다. 특히 LLM이 제한된 작업만 한다면 작은 모델 성능에 만족스럽게 놀라는 경우가 많고, 작은 모델을 파인튜닝하면 낮은 비용으로 좋은 결과를 얻는다.

둘째, 입출력 토큰 수를 제한한다. RAG 프롬프트는 긴 chunk를 많이 검색하면 빠르게 커진다 — top-k를 줄여 문서를 덜 검색해 본다. 또 LLM은 장황할 수 있고 생성 토큰마다 과금되므로, 시스템 프롬프트로 간결한 응답을 유도하거나 토큰 한도를 두는 것도 방법이다. 모델·프롬프트를 줄일 때 관측성 파이프라인이 있으면 그 trade-off가 값어치 있는지 판단할 수 있다.

그림 2. LLM 비용 최적화 — 더 작은 모델(적은 파라미터/양자화) + 더 짧은 프롬프트(top-k↓·간결·토큰 한도).

 

 

2. 전용 엔드포인트에 호스팅

또 다른 방법은 LLM을 전용 하드웨어(dedicated hardware)에 호스팅하는 것이다. Together AI·AWS·Google 같은 cloud provider의 편리한 inference endpoint는 프로토타입엔 적합하다. 하지만 수천~수백만 request로 커지면 같은 회사에서 전용 하드웨어를 임대해 비용을 아낄 수 있다. 전용 엔드포인트는 내 트래픽만 처리하므로 신뢰성도 높다. 이땐 GPU 시간당 과금인데, 규모가 크면 토큰당 과금보다 시간당이 훨씬 저렴할 수 있다.

그림 3. 호스팅 — 프로토타입은 cloud endpoint, 대규모는 전용 하드웨어(GPU 시간당 과금)로 절감·신뢰성↑.

 

 

 

3. 벡터 DB 비용 — 3층 메모리

벡터 DB 비용을 아끼려면 대부분의 DB가 세 종류의 메모리를 제공한다는 점을 알아야 한다 — RAM(가장 빠르지만 가장 비쌈), disk(중간), cloud object storage(가장 느리지만 가장 쌈). RAM은 GB당 disk보다 몇 배, disk는 cloud보다 몇 배 비싸다. 따라서 성능에 실제로 도움이 될 때만 빠르고 비싼 저장소에 둔다. 예를 들어 HNSW 인덱스는 RAM에 둬 검색을 빠르게 하고, 문서 본문은 RAM에 둘 필요가 없다 — 자주 쓰는 문서는 disk, 드물게 쓰는 것은 cloud object storage에 둔다. 많은 벡터 DB가 이 trade-off를 모니터링하고 동적으로 데이터를 옮겨 주기도 한다.

그림 4. 3층 메모리 — RAM(빠름·비쌈)엔 HNSW 인덱스, 본문은 disk/cloud로. 성능에 값할 때만 RAM 사용.

 

 

4. Multi-tenancy

대표적 적용이 multi-tenancy다 — 벡터 DB의 모든 문서를 소유한 사용자·조직별로 나눈다. 예로 1,000명이 소유한 100만 문서가 있다면, 각 사용자는 자기 문서에만 접근하도록 각자의 HNSW 인덱스를 갖는다. 그러면 tenant 데이터를 필요할 때만 빠르고 비싼 메모리에 올리기 쉽다 — 고객이 로그인할 때 그의 벡터를 RAM에 올리거나, 유럽 tenant 데이터를 유럽 밤 시간엔 느린 저장소에 두는 식이다. 결국 비싼 메모리 안팎으로 데이터를 옮기는 일인데, tenant별 조직화가 이를 효율적으로 만든다.

그림 5. Multi-tenancy — tenant별 인덱스로 나눠, 로그인 시 로딩·시간대 최적화로 비싼 메모리를 효율적으로 쓴다.

 

핵심. 모든 최적화의 핵심은 엔지니어가 비용의 원천을 이해하고 그 비용이 성능으로 정당화되는지 확인하는 것이다. LLM은 작은 모델·짧은 프롬프트, 벡터 DB는 비싼 저장소엔 적게 담고 RAM↔disk↔object 사이 이동이 주된 절감법이다. 변경의 영향을 실험·모니터링해 값어치를 판단한다.

 

다음 글에서는 또 다른 축 — 지연(latency) vs 응답 품질 — 을 다룬다.