LLM 시스템의 비용 최적화: 비용이 실제로 발생하는 지점

LLM (Large Language Model) 비용은 사용량에 따라 선형적으로 증가합니다. 요청당 $0.01의 비용이 드는 시스템이 하루에 10,000개의 요청을 처리하면 매일 $100, 즉 연간 $365의 비용이 발생합니다. 엔터프라이즈 규모에서는 그 금액이 $10,000를 넘어섭니다.

비용 최적화는 단순히 비용을 절감하는 것이 아닙니다. 중요한 곳에 토큰 (Token)을 사용하는 것에 관한 것입니다.

낭비되는 모든 토큰은 더 나은 답변에 사용할 수 있었던 토큰입니다.

토큰 예산 편성 (Token budgeting)

비용을 제어하는 가장 간단한 방법은 제한을 설정하는 것입니다. 세션별, 작업별, 또는 일별로 설정할 수 있습니다.

전략 1: 세션별 예산 (Per-Session Budgets)

세션별 예산은 간단합니다:

class SessionBudget:
    def __init__(self, budget_tokens: int = 10000):
        self.budget = budget_tokens
...

전략 2: 작업별 예산 (Per-Task Budgets)

작업별 예산이 더 유용합니다. 서로 다른 작업에는 서로 다른 양의 컨텍스트 (Context)가 필요합니다:

task_budgets:
  classify:
    max_tokens: 100
...

전략 3: 적응형 예산 (Adaptive Budgets)

적응형 예산은 실제로 발생하는 상황에 따라 조정됩니다. 분류 (Classification) 작업이 지속적으로 80개의 토큰을 사용한다면, 100개를 할당하는 것을 중단하십시오:

class AdaptiveBudget:
    def __init__(self):
        self.task_history = {}
...

지수 이동 평균 (Exponential Moving Average, 0.9 가중치)은 최근의 사용량이 과거 기록보다 더 중요하다는 것을 의미합니다. 워크로드 (Workload)의 변동성에 따라 가중치를 조정하십시오.

API vs 로컬 추론 (Local inference)

규모가 커질수록 로컬 추론이 더 저렴합니다. 손익분기점은 하드웨어와 API 요금에 따라 달라집니다.

모델 (Model)	API ($/M tokens)	로컬 시간당 비용	손익분기점
GPT-4o	$2.50 / $10.00	—	N/A
...

하드웨어 계산:

하드웨어	초기 비용	월간 전기료	API 대비 손익분기점
RTX 3090 (중고)	$600	$15	~4개월
...

하루에 한 시간 이상 사용하는 중간 정도의 사용량에서는 로컬 추론이 비용을 회수할 수 있습니다. 사용량이 많을 경우 절감 효과는 극적입니다. 문제는 초기 자본입니다. RTX 5080은 $1,000입니다. API 청구서는 일시 중지할 수 있지만, 하드웨어는 그럴 수 없습니다.

폴백 전략 (Fallback strategies)

선호하는 모델이 너무 비싸거나 너무 느릴 때, 더 저렴한 모델로 폴백 (Fallback) 하세요. 핵심은 품질이 "충분히 좋은" 시점이 언제인지 아는 것입니다.

전략 1: 품질 기반 폴백 (Quality-Based Fallback)

품질 기반 폴백은 출력이 임계값 (threshold)을 충족할 때까지 모델을 시도합니다:

class QualityFallback:
    def __init__(self, quality_threshold: float = 0.8):
        self.threshold = quality_threshold
...

문제는 평가 (evaluation) 그 자체입니다. 다른 모델을 호출하지 않고 어떻게 품질을 측정할 수 있을까요? 일부 시스템은 작은 분류기 (classifier)를 사용합니다. 다른 시스템은 길이, 구조, 키워드 존재 여부와 같은 휴리스틱 체크 (heuristic checks)를 사용합니다. 이 중 완벽한 것은 없습니다.

전략 2: 지연 시간 기반 폴백 (Latency-Based Fallback)

지연 시간 기반 폴백은 더 간단합니다. 시간 예산 (time budget)을 충족하는 가장 빠른 모델로 라우팅 (route) 하세요:

class LatencyFallback:
    def __init__(self, max_latency: float = 5.0):
        self.max_latency = max_latency
...

캐싱 (Caching)

캐싱은 가장 과소평가된 비용 최적화 방법입니다. 동일한 프롬프트 (prompt)는 생각보다 더 자주 발생합니다. 분류 요청, FAQ 스타일의 질의, 반복되는 도구 호출 (tool calls) 등이 그 예입니다.

전략 1: 프롬프트 캐싱 (Prompt Caching)

정확한 프롬프트 캐싱은 간단합니다:

import hashlib

class PromptCache:
...

전략 2: 시맨틱 캐싱 (Semantic Caching)

시맨틱 캐싱은 더 유용합니다. 표현은 다르지만 의미가 같은 프롬프트를 잡아냅니다:

from sentence_transformers import SentenceTransformer

class SemanticCache:
...

임계값 (threshold)이 중요합니다. 0.95는 매우 공격적입니다. 매우 유사한 프롬프트만 매칭됩니다. 0.85는 더 관대하지만 잘못된 답변을 반환할 위험이 있습니다. 미스율 (miss rate)을 측정하고 조정하세요.

일반적인 질의에 대한 응답 캐싱 (Response caching) 또한 가치가 있습니다. 사용자가 "날씨가 어때" 또는 "지금 몇 시야"라고 반복해서 묻는다면, 정확한 프롬프트뿐만 아니라 그 패턴을 캐싱하세요:

class ResponseCache:
    def __init__(self):
        self.common_queries = {
...

이것은 정교하지는 않지만 효과가 있습니다. 일반적인 질의가 일반적인 데에는 이유가 있습니다.

최적화가 도움이 되는 경우

대량의 데이터를 처리하거나, 혼합된 워크로드 (mixed workloads)를 실행하거나, 누적되는 API 비용을 지불하고 있을 때 최적화가 중요합니다.

프로토타입을 제작 중이거나, 단일 모델을 사용하거나, 처리량이 적을 때는 최적화가 중요하지 않습니다. 하루에 100개의 요청만 처리하는 시스템을 위해 예산 책정 (budgeting), 폴백 (fallback), 캐싱 (caching)의 복잡성을 감수할 가치는 없습니다.

먼저 기본적인 흐름이 작동하도록 만드세요. 최적화는 청구서가 날아올 때 추가해도 됩니다.

트레이드오프 (Tradeoffs)

전략 (Strategy)	비용 (Cost)	품질 (Quality)	복잡도 (Complexity)
최적화 없음 (No optimization)	가장 높음	일관됨	가장 낮음
...

프로덕션 시스템은 보통 하이브리드 (hybrid) 방식으로 운영됩니다. 세션당 예산을 설정하고, 품질이나 지연 시간 (latency) 중 하나를 양보하며, 가능한 것은 캐싱하세요. 복잡성은 실제로 존재하지만, 그만큼의 비용 절감 효과도 확실합니다.