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σ 이상이면 즉시 알림. 모델 롤아웃 초반에 이게 두 번 살려줌.

vLLM 0.6 Speculative Decoding 체감

vLLM 0.6대에 들어 speculative decoding이 꽤 안정됐다. 드래프트 모델로 작은 거 쓰고, 타깃 모델로 검증하는 구조.

원리 요약

드래프트가 여러 토큰을 미리 예측 → 타깃이 한번의 forward로 그 토큰들을 다 검증 → 일치하는 만큼 수용, 불일치 지점에서 재시작. 평균적으로 타깃 호출 횟수가 줄어 latency 감소.

세팅

• 타깃: Llama 3.1 70B Instruct (FP8, H100 4장 tp=4)
• 드래프트: Llama 3.2 1B Instruct

vllm serve meta-llama/Llama-3.1-70B-Instruct \
  --tensor-parallel-size 4 --quantization fp8 \
  --speculative-model meta-llama/Llama-3.2-1B-Instruct \
  --num-speculative-tokens 5

결과

조건	TTFT	tok/s
no spec	280 ms	74
spec (k=5)	310 ms	118
spec (k=8)	330 ms	127

throughput 약 1.6~1.7배. TTFT가 살짝 오르지만 체감 안 됨(인터랙티브 채팅).

주의

• 드래프트가 너무 다른 분포면 수용률이 낮아져서 오히려 느려짐. 같은 제품군(같은 토크나이저, 가까운 학습셋)이 중요.
• temperature 높은 케이스(창의적 생성)는 수용률 하락. 코드·문서 생성에서 이점이 크고, 시적 생성에선 덜.
• num_speculative_tokens를 너무 키우면 이득이 역전됨. 5~7 근처가 우리 sweet spot.

비용

GPU는 그대로. throughput 1.6배 = 비용 1/1.6. 같은 QPS 감당에 인스턴스 수를 줄일 수 있어서 월 단위로 실질 절감. 특히 출력 길이 긴 요약 같은 워크로드에 드라마틱.

spec decoding은 "공짜 점심"처럼 보이지만 드래프트/타깃 조합·분포 매칭이 관건. 운영 전 워크로드별 수용률부터 측정할 것.