LLM 추론 비용 프로파일링

"LLM 비용이 너무 많이 나와요"라는 말은 있는데 구체적으로 어디서 나는지 모르는 경우가 90%. 직접 계측 안 하면 영영 모름.

최소 schema

llm_call(
  id, parent_id, session_id, user_id,
  provider, model, purpose,           -- "summary" / "router" / "final"
  prompt_tokens, completion_tokens,
  cost_usd,                           -- 산정식으로 기록
  latency_ms, ttft_ms,
  cache_hit, retried,                 -- 플래그
  created_at
)

핵심은 purpose와 parent_id. 하나의 유저 요청에 내부적으로 LLM 5~10번 도는 게 보통인데, 이걸 트리로 묶어야 진짜 비용이 보임.

대시보드

세 가지 관점:

1. per-feature: 검색, 요약, 챗 등 기능별 비용 비중.
2. per-user: 상위 1% 유저가 쓴 양. 대부분 파워유저가 비용 50%+ 먹음.
3. per-call-in-tree: 한 요청 트리 안에서 가장 비싼 노드. "router가 쓸데없이 긴 context 받고 있음" 같은 낭비 발견.

실제 개선

• router 모델을 Sonnet → Haiku로 교체, 응답 품질 차이 미미. 해당 노드 비용 1/6.
• summary 단계에서 "원문 전체"를 넣던 걸 pre-extractive로 800 토큰 추림. 품질 거의 유지, 토큰 -68%.
• 캐시 계층 추가. session_id 단위로 embedded 질문 유사도 기준 answer cache. hit율 18%.
• output max_tokens를 케이스별로 조정. 무한히 길게 답하는 거 방지. output 토큰 -22%.

숫자

4주 작업으로 월 LLM 비용 $18K → $6.8K. 품질 지표(faithfulness, user CSAT)는 오히려 소폭 상승. 기술적 계측은 엔지니어링 시간의 최고 ROI였다.

팁

provider-side 사용량 대시보드 믿지 말 것. 단위(1M 기준 가격)와 round up 방식이 달라 실제 청구서와 미묘하게 어긋남. 내 DB의 cost_usd를 ground truth로, provider는 sanity check용.

그리고 월 고정 예산 alarm을 Slack에 연결. 일 단위 3σ 이상이면 즉시 알림. 모델 롤아웃 초반에 이게 두 번 살려줌.