LLM 비용과 지연을 운영 지표로 읽는 법

LLM 비용과 지연은 입력과 출력, prefill과 decode, 캐시와 라우팅의 비대칭을 이해해야 운영할 수 있다. Prompt caching, Batch API, 모델 라우팅, self-hosting, reasoning 모델 선택을 비용과 지연의 관점에서 정리한다.

Layer: L12
Duration: 길이 미정
Generated: 2026. 5. 25. 오후 4:31:14

원본 문서 읽기 오디오 파일 열기

Script Companion

오디오와 함께 스크립트 보기

01
LLM 비용과 지연은 모델을 한 번 호출할 때마다 쌓이는 운영 문제다. Pretraining과 fine-tuning은 상대적으로 일회성에 가깝지만, inference는 서비스가 쓰일수록 계속 누적된다. 그래서 문서는 운영 비용의 80%가 inference라고 강조한다. 사용자 경험도 바로 연결된다. 첫 토큰이 나오기까지 걸리는 TTFT가 1초 이상이면 챗봇 이탈로 이어질 수 있고, reasoning 모델 시대에는 토큰 비용 차이가 5에서 20배까지 벌어져 모델 선택이 곧 운영 결정이 된다.
02
먼저 비용 모델은 input과 output의 비대칭에서 출발한다. 거의 모든 provider에서 output이 input보다 4에서 5배 비싼데, 이유는 처리 방식이 다르기 때문이다. Input 처리는 prefill 단계로, 병렬화가 가능하고 GPU 활용률이 높아 상대적으로 싸다. 반대로 output 생성은 decode 단계로, 토큰을 하나씩 순차적으로 만들어야 하며 memory-bound 성격이 강하다. 같은 토큰처럼 보여도 입력 토큰과 출력 토큰은 비용 구조가 다르다는 점이 핵심이다.
03
Reasoning 모델은 여기에 reasoning token이라는 축을 더한다. o3, Claude extended thinking, R1 같은 모델은 답변을 내기 전 사고에 해당하는 토큰을 별도로 세며, 같은 답변이라도 일반 모델보다 비용이 5에서 20배 커질 수 있다. 다만 항상 비싼 선택이라고만 볼 수는 없다. 여러 단계를 일반 모델로 나누어 호출해야 하는 작업에서는 reasoning 모델이 한 번에 풀어 전체 합산 비용이 더 낮아질 수도 있다. 그래서 단순 분류와 추출은 일반 모델, 수학이나 코드 디버깅처럼 다단계 reasoning이 필요한 작업은 reasoning 모델을 검토하는 식의 구분이 필요하다.
04
지연 시간은 TTFT, TPOT, end-to-end latency, throughput으로 나누어 본다. TTFT는 첫 토큰까지의 시간이며 사용자 체감이 가장 크고, 목표는 1초 미만이다. TPOT은 Time Per Output Token, 즉 출력 토큰 하나당 시간이며 30 tok/s 기준으로 30에서 50ms가 목표다. TTFT는 input length, 모델 크기, 서버 큐 depth, prompt caching 여부의 영향을 받는다. TPOT은 모델 크기, continuous batching의 batch size, KV cache 메모리와 대역폭, speculative decoding 사용 여부에 영향을 받는다.
05
비용 절감의 1순위는 prompt caching이다. 같은 prefix를 재사용해 prefill 비용을 줄이는 방식이며, 시스템 프롬프트와 few-shot은 항상 caching 대상으로 보는 것이 좋다. RAG context에서는 자주 쓰이는 사내 정책 같은 문서가 캐싱 대상이 되고, 긴 대화 history도 누적 prefix라 자연스럽게 cache hit가 발생할 수 있다. Provider별로는 Anthropic이 cache_control을 쓰는 명시적 방식이고 cache hit 가격은 input의 10%다. OpenAI는 1024 토큰 이상에서 automatic prefix caching이 적용되고 cache hit 가격은 input의 50%다. Google은 context caching을 수동으로 쓰며 input의 약 25%로 제시된다.
06
Batch API는 비동기 작업에서 input과 output 모두 50% 할인을 주는 도구다. 데이터 분석, eval, 콘텐츠 생성, 분류처럼 실시간 응답이 필요하지 않은 작업에 맞고, 채팅이나 실시간 agent에는 맞지 않는다. 모델 라우팅은 더 큰 절감 축이다. Cascade 패턴에서는 단순 질문을 cheap 모델에서 끝내고, 복잡한 요청만 비싼 모델로 올린다. RouteLLM의 공개 벤치마크에서는 95% GPT-4 품질 유지 조건에서 MT Bench는 비용 85% 절감, MMLU는 45% 절감, GSM8K는 35% 절감으로 제시된다. 다만 운영 현장에서는 quality 모니터링과 threshold 튜닝 없이 30에서 60% 절감이 현실적이라고 본다.
07
라우팅 방식은 cascade만 있는 것이 아니다. Classifier routing은 작은 LLM이나 분류기가 query를 분류해 적절한 모델을 고르는 방식이고, Semantic Router는 query 임베딩을 미리 만든 카테고리 임베딩과 비교해 가장 가까운 카테고리의 모델을 선택한다. 운영 도구로는 OpenRouter, LiteLLM Router, Portkey, NotDiamond가 언급된다. Cascade threshold도 고정값이 아니다. threshold 0.8은 너무 보수적이라 escalation 비율이 올라가고 절감 효과가 작아질 수 있다. threshold 0.6은 대화형 traffic 기준 표준이며 escalation 30에서 50%, 평균 비용 5에서 10배 감소가 목표다. threshold 0.4는 공격적이라 품질 폭락 위험이 있다.
08
Self-hosting은 API 호출 비용이 일정 규모를 넘을 때 검토한다. Open-weight 모델 호스팅 엔진으로는 vLLM, TGI, SGLang, TensorRT-LLM, llama.cpp, Ollama가 나온다. vLLM은 PagedAttention과 continuous batching으로 널리 쓰이고, TGI는 production-ready와 k8s 친화성이 강조된다. 비용은 GPU뿐 아니라 모니터링, autoscaling, 장애 대응 인력, vLLM과 FlashAttention과 speculative decoding 같은 최적화에 들어가는 엔지니어 시간까지 포함해야 한다. 경험적 break-even은 1M 호출월에서는 API, 10M에서는 사례별, 100M 이상에서는 self-host 우위로 제시된다.
09
Inference 최적화 기법은 비용과 지연의 병목을 다르게 건드린다. FlashAttention 2와 3은 sequence length가 길수록 효과가 크고, 메모리 O(n)과 속도 2에서 4배 효과가 언급된다. Continuous batching은 high concurrency에서 throughput을 2에서 4배 높이며 vLLM 표준에 가깝다. PagedAttention은 KV cache 단편화를 60에서 80%에서 4% 미만으로 낮추고 throughput도 올린다. Speculative decoding은 draft model과 target 검증으로 output latency를 2에서 3배 줄일 수 있지만, output이 짧으면 오버헤드가 생긴다. INT8과 INT4 quantization은 메모리를 2에서 4배 줄이지만 정확도 critical 작업에는 위험하다.
10
운영에서는 비용과 지연을 측정 항목으로 고정해야 한다. 호출당 input과 output 토큰 분포, model별 호출 수와 비용, 사용자와 feature와 route별 비용 attribution, cache hit ratio, latency P50과 P95와 P99, 시간대별 비용 추이를 본다. 도구로는 Helicone, Langfuse, LangSmith, Portkey, OpenAI usage dashboard가 제시된다. Alert도 비용 임계 초과만 보면 부족하다. cache hit ratio 폭락, TTFT P99 임계 초과, 특정 사용자나 route의 비용 폭증을 함께 잡아야 한다. 평균 latency가 좋아도 p99가 30초면 사용자 경험의 핵심 신호를 놓친 것이다.
11
Silent failure는 LLM 운영에서 특히 조용히 비용을 키운다. Cache miss explosion은 prompt 구조 변경으로 cache hit ratio가 폭락하는 경우이고, prompt 누적은 대화 history가 무한히 증가해 context와 비용이 폭증하는 경우다. Tool 안의 LLM 호출은 tool이 내부적으로 LLM을 불러 보이지 않는 비용을 만들 수 있다. Reasoning 폭주는 reasoning 모델이 너무 길게 생각해 reasoning_tokens가 100k 이상으로 커지는 상황이며, reasoning_budget 제한이 복구 실마리다. Stale routing은 router 분류기가 옛 모델 가격이나 capability를 기준으로 판단해 cascade escalation이 70% 이상으로 오르는 상황이고, 주기적 재학습이 필요하다.
12
Cache hit ratio 폭락은 별도 절차로 볼 만큼 흔한 실패다. Anthropic 공식 필드인 cache_read_input_tokens와 cache_creation_input_tokens로 5분 sliding window hit ratio를 계산하고, 5분 동안 0.50 미만이면 warning, 0.30 미만이면 critical로 본다. 한 호출에서 두 필드가 모두 0인 비율이 10% 이상이면 캐시가 아예 적용되지 않는 신호일 수 있어 별도 alert가 필요하다. 원인은 모델별 최소 길이 미달이나 cache_control 미부착일 수 있고, hit ratio 분모가 0이면 일반 alert에 잡히지 않을 수 있다. Critical 이후에는 고정 prefix와 동적 suffix를 분리하고, timestamp나 request_id나 user 이름 같은 동적 값을 cache_control breakpoint 다음으로 옮긴다.
13
마지막으로 이 문서는 LLM 비용과 지연을 통신, 연산, 캐시의 trade-off로 일반화한다. 일반 공식은 ‘비용·지연 = 자원 × 가격 - 캐시 - 압축’이다. Prompt caching은 캐시 항을 건드리고, cascade routing은 자원 × 가격 항을 직접 줄이며, Batch API는 24시간 지연 허용을 50% 가격으로 바꾸는 시간 차원 압축에 가깝다. Self-host는 per-token 곱하기 호출 수 구조를 per-GPU-hour 곱하기 시간 구조로 바꾸는 결정이다. CDN edge, DB read replica와 Redis, Spark batch ETL에서도 같은 진단 구조가 보인다. LLM에서는 여기에 토큰 비용과 비결정성이 추가된다.

같은 레이어

L12에서 이어 듣기

원본 문서: content/topics/L12/llm-cost-and-latency.md
오디오 파일: /podcasts/l12-llm-cost-and-latency.mp3