모델을 교체하거나 출력 품질을 떨어뜨리지 않고도 LLM API 지출을 50%에서 90%까지 줄일 수 있습니다. 기술은 이미 존재하고 문서도 공개되어 있지만, 대부분의 팀은 이를 활용하지 못하고 있습니다. 실제로 효과를 볼 수 있는 방법들을 소개합니다.

LLM 청구서가 실제로 발생하는 지점

모든 API 호출은 입력 토큰 (input tokens)과 출력 토큰 (output tokens)에 대해 비용을 청구합니다. 단순한 계산이지만, "입력 토큰"은 보기보다 훨씬 더 큰 실수 유발 요인 (footgun)입니다.

대부분의 프로덕션 워크로드 (production workloads)는 매 요청마다 동일한 시스템 프롬프트 (system prompt), 지침, 또는 검색 컨텍스트 (retrieval context)를 보냅니다. 만약 시스템 프롬프트가 4,000 토큰이고 분당 100개의 요청을 보낸다면, 매분 400,000개의 입력 토큰이 정가로 소모되는 것입니다. 다른 무엇을 최적화하기 전에, 토큰 지출이 실제로 어디로 향하고 있는지 파악하십시오.

대부분의 비용은 세 가지 범주에서 발생합니다:

• 반복되는 컨텍스트 (Repeated context): 매 호출마다 전송되는 시스템 프롬프트, 도구 정의 (tool definitions), 검색된 문서
• 프런티어 모델 (Frontier model) 과다 사용: 더 저렴한 모델로도 충분히 처리할 수 있는 간단한 분류 작업을 GPT-4o나 Claude Sonnet에 보내는 경우
• 비대해진 출력 (Bloated outputs): 10개 토큰 정도의 구조화된 필드 (structured field)가 필요한 상황에서 문단 형태의 산문(prose)을 받는 경우

어떤 범주가 가장 큰 비용을 초래하는지 알게 되면 해결책은 명확합니다. 이 글의 나머지 부분에서는 구체적인 수치와 함께 각 항목을 다룹니다.

프롬프트 캐싱 (Prompt caching): 아무도 사용하지 않는 가장 높은 ROI 최적화

만약 앱이 매 호출마다 동일한 접두사 (prefix) (시스템 프롬프트, 도구 정의, 퓨샷 예시 (few shot examples))를 보낸다면, 프롬프트 캐싱 (prompt caching)은 당신이 할 수 있는 가장 영향력 있는 변화입니다.

Anthropic의 캐싱 API를 사용하면 cache_control 블록을 통해 입력의 일부를 캐싱 가능하도록 표시할 수 있습니다. 첫 번째 호출 시 캐시를 작성하는 비용은 일반 입력 토큰 가격의 25%입니다. 이후 발생하는 모든 캐시 히트 (cache hit) 비용은 일반 가격의 10%입니다. 이는 캐싱된 부분에 대해 90%의 비용 절감을 의미합니다.

import anthropic

client = anthropic.Anthropic()
...

첫 번째 호출 시에는 캐시 쓰기 비용(일반 입력 가격의 25%)을 지불합니다. 두 번째 호출부터는 모든 히트(hit) 시 일반적인 비용의 10%만 발생합니다. 3,000토큰의 시스템 프롬프트(system prompt)를 대상으로 시간당 1,000번의 호출을 수행하는 앱의 경우, 시간당 270만 토큰의 비용이 전체 가격에서 10% 가격으로 떨어지게 됩니다.

OpenAI는 자동 프롬프트 캐싱(automatic prompt caching)을 통해 유사한 동작을 제공합니다. 구현 방식은 약간 다르지만 경제적 효과는 비슷합니다.

프롬프트 캐싱(Prompt caching)은 다음과 같은 경우에 가장 효과적입니다: 시스템 프롬프트가 1,000토큰 이상일 때, 동일한 문서를 반복적으로 주입하는 RAG 파이프라인을 실행할 때, 또는 턴(turn)마다 재사용되는 대규모 도구 정의(tool definitions)를 가진 에이전트 프레임워크를 사용할 때입니다.

모델 라우팅(Model routing): 모든 것을 프런티어 모델(frontier model)로 보내지 마세요

모든 작업에 GPT-4o나 Claude Sonnet이 필요한 것은 아닙니다. 의도 분류(Intent classification), 슬롯 추출(slot extraction), 요약(summarization), 그리고 간단한 질의응답(Q&A)은 GPT-4o-mini나 Claude Haiku가 충분히 처리할 수 있는 범위 내에 있습니다. 토큰당 비용 차이는 대략 10배에서 20배에 달합니다.

트래픽의 40%를 더 작은 모델로 라우팅하면, 사용자에게 노출되는 기능을 하나도 건드리지 않고도 전체 API 지출을 절반으로 줄일 수 있습니다. 핵심은 적절한 작업을 선택하는 것입니다.

import OpenAI from "openai";

const client = new OpenAI();
...

이것은 키워드와 메시지 길이에 기반한 단순한(naive) 라우터입니다. 프로덕션 버전은 라우팅 전에 복잡도를 점수화하기 위해 작은 분류기(classifier) 또는 다른 LLM을 사용합니다. 직접 구축하고 싶지 않다면 LiteLLM이나 RouteLLM 같은 프로젝트에서 제공하는 사전 구축된 라우터를 사용할 수 있습니다.

주의해야 할 실패 사례: 단순해 보이지만(

만약 평가 (evals)를 실행하거나, 문서를 처리하거나, 보고서를 생성하거나, 혹은 24시간의 대기 시간이 허용되는 모든 대량 추론 (bulk inference) 작업을 수행한다면, OpenAI Batch API를 통해 동기식 가격 (synchronous pricing) 대비 비용을 50% 절감할 수 있습니다.

JSONL 파일을 제출하면, OpenAI가 이를 비동기적 (asynchronously)으로 처리합니다. 결과가 준비되면 가져오기만 하면 됩니다. 스트리밍 (streaming)이나 실시간 SLA (Service Level Agreement)는 제공되지 않습니다.

import openai
import json
from pathlib import Path
...

이를 모델 라우팅 (model routing)과 결합하십시오. 저렴한 모델에 50% 할인이 적용된 배치 작업 (batch jobs)을 수행하는 것입니다. 바로 이 지점에서 비용 계산이 매우 흥미로워집니다.

Anthropic 또한 유사한 비동기 배치 처리 (async batch processing)를 제공합니다. API 형태는 약간 다르지만 가격 패턴은 동일합니다.

응답 토큰을 줄이기 위한 출력 스키마 (Output schema) 규율

자유 형식의 산문 (Freeform prose) 출력은 비용이 많이 듭니다. 다운스트림 (downstream) 코드에서 마크다운 코드 블록 (markdown code block)으로부터 JSON 블롭 (JSON blob)을 파싱할 때, 당신은 설명 텍스트, 코드 펜스 (code fences), 그리고 주석에 대한 비용을 지불하고 있는 것입니다. 이 중 어느 것도 당신에게 유용하지 않습니다.

구조화된 출력 (Structured outputs)이 이를 해결합니다. OpenAI와 Anthropic 모두 당신이 정의한 필드만을 유효한 JSON 형식으로 매번 반환하는 스키마 제약 생성 (schema constrained generation)을 지원합니다.

from anthropic import Anthropic
import json

...

스키마 제약 (schema constraint)은 모델에게 필요한 필드가 채워지면 멈추도록 지시합니다. 확언 (hedging), 마크다운 포맷팅, 불필요한 설명 산문 등을 작성하지 않습니다. 구조화된 작업에서는 자유 형식의 작업과 비교했을 때 출력 토큰 (output token) 수가 눈에 띄게 감소합니다.

이 부분은 제가 전환하기 전 운영 환경 (prod)에서 겪었던 문제입니다. 제가 필요했던 것은 점수와 레이블(label), 즉 단 두 개의 필드뿐이었는데, 평가 (eval) 파이프라인이 모든 항목에 대해 전체 설명 단락을 반환하고 있었습니다. 그 장황함은 순전한 낭비였습니다.

FAQ

LLM API 비용을 어떻게 줄이나요?

가장 높은 ROI (투자 대비 수익)를 제공하는 레버(levers)를 순서대로 나열하면 다음과 같습니다: (1) 반복되는 컨텍스트를 위한 프롬프트 캐싱 (prompt caching), (2) 최첨단 모델 (frontier models)이 필요하지 않은 작업을 위한 모델 라우팅 (model routing), (3) 비동기 워크로드 (async workloads)를 위한 배치 처리 (batching), (4) 응답 크기를 줄이기 위한 스키마 제약 출력 (schema constrained outputs). 각각은 서로 다른 비용 항목을 목표로 하며, 이들은 중첩되어 적용될 수 있습니다.

프롬프트 캐싱 (Prompt Caching)이 LLM 비용 절감에 효과가 있을까요?

네, 시스템 프롬프트 (System Prompt)나 검색된 컨텍스트 (Retrieval Context)가 1,000 토큰을 초과하고 이를 반복적으로 전송한다면 효과가 있습니다. Anthropic의 캐시 읽기 (Cache Read) 가격은 일반 입력 가격의 10%입니다. 하루에 4,000 토큰의 시스템 프롬프트를 500번 호출하는 경우, 한 번은 전체 가격을 지불하지만 나머지 499번은 10%의 가격만 지불하면 됩니다. 계산 결과는 매우 명확합니다.

프로덕션 환경에서 LLM을 실행하는 가장 저렴한 방법은 무엇인가요?

직접 호스팅하는 오픈 웨이트 (Open Weight) 모델 (Llama, Mistral, Qwen)은 대규모 운영 시 API 가격보다 저렴하지만, 직접 운영해야 하는 인프라가 필요합니다. 벤더 API를 사용하는 워크로드의 경우: 라우팅 (Routing, 단순 작업에는 저렴한 모델 사용) + 배치 (Batching, 비동기 처리 시 50% 할인) + 캐싱 (Caching, 반복되는 컨텍스트에 대해 90% 할인)을 결합하십시오. 대부분의 팀은 이 세 가지를 모두 수행하지 않고 있으며, 이는 곧 대부분의 팀이 비용을 과다 지불하고 있음을 의미합니다.

각 기술이 호출 볼륨에 따라 실제로 얼마나 절감되는지에 대한 세부 분석을 포함하여, 프로덕션 LLM 추론 최적화에 대해 제 블로그에서 더 자세히 다룹니다.

만약 귀하의 스택에 이 기술들을 엔드 투 엔드 (End-to-End)로 구축하고 싶다면, 바로 제가 수행하는 업무의 종류입니다.

귀하의 팀은 프로덕션에서 어떤 라우팅 또는 캐싱 설정을 사용하고 있나요? 댓글을 남겨주세요. 사람들이 실제로 어떤 수치를 보고 있는지 궁금합니다.