LLM 토큰 비용 60% 절감하기: 프로덕션 엔지니어의 현장 노트

자, LLM 토큰 비용 60% 절감하기: 프로덕션 엔지니어의 현장 노트

CFO가 단 한 줄의 텍스트가 적힌 AWS 청구서를 저에게 전달했던 그 순간을 기억합니다: "우리 얘기 좀 해야겠어요." 그날 밤 저는 토큰 경제학 (token economics)에 집착하게 되었고, 지난 14개월 동안 추론 레이어 (inference layer)를 세 번이나 재구축했습니다. 이어지는 내용은 그 여정에서 얻은 필터링 없는 노트입니다. 막다른 길, 승리, 그리고 p99 지연 시간 (latency)을 우리의 1.8초 SLA 이내로 편안하게 유지하면서 최종적으로 지출을 절반 이상 줄인 아키텍처 결정들에 대한 기록입니다.

이 문제가 왜 저를 밤잠 설치게 만드는가

여러 리전에 걸쳐 LLM 워크로드를 실행할 때, 비용 곡선은 선형적이지 않습니다. 최악의 방식으로 지수적 (exponential)입니다. 프랑크푸르트에서 새벽 2시에 발생하는 단 한 번의 채팅 완성 (chat completion)은 저렴해 보이지만, 이를 3개 대륙에 걸친 40,000 RPM으로 곱하면 갑자기 돈이 쏟아져 나가는 것을 보게 됩니다. 우리는 한 달에 약 21억 개의 토큰을 서비스하며, 최적화 스프린트(optimization sprint)를 진행하기 전 우리의 월간 청구 금액은 공개적으로 말하고 싶지 않은 숫자였습니다.

Global API는 184개의 모델을 노출하며, 가격은 100만 토큰당 0.01달러에서 3.50달러까지 다양합니다. 그 차이는 엄청납니다. 또한 그것은 함정입니다. 순진한 선택은 가장 저렴한 모델을 골라 배포하는 것입니다. 엔터프라이즈급의 선택은 어떤 토큰이 실제로 얼마의 비용이 드는지 이해하고 그에 따라 라우팅 (route)하는 것입니다.

대부분의 블로그 포스트가 말해주지 않는 사실이 있습니다: 입력 토큰 (input tokens)과 출력 토큰 (output tokens)은 부하 상황에서 매우 다르게 작동합니다. 입력은 캐싱 (cacheable)이 가능하고, 배치 (batchable)가 가능하며, 압축 (compressible)이 가능합니다. 출력은 대화형 (interactive)이고, 지연 시간에 민감하며 (latency-sensitive), 분할 상환 (amortize)이 거의 불가능합니다. 만약 당신이 동일한 전략으로 두 가지를 모두 최적화하고 있다면, 당신은 눈을 감고 비행하고 있는 것입니다.

실제 가격 환경 (내 스프레드시트 기준)

저는 우리가 사용하는 모든 모델을 추적하는 개인용 대시보드를 유지하고 있습니다. 아래의 5개 모델이 우리 트래픽의 93%를 차지하며, 모델 간의 차이가 종종 5배 이상 나기 때문에 정확한 수치를 공유하고자 합니다:

DeepSeek V4 Flash는 128K 컨텍스트 창 (context window)을 제공하며, 입력 토큰 100만 개당 $0.27, 출력 토큰 100만 개당 $1.10의 비용이 듭니다. 이는 심층적인 추론 (deep reasoning)이 필요하지 않은 모든 작업에 사용하는 저의 주력 모델 (workhorse)입니다. DeepSeek V4 Pro는 입력 $0.55, 출력 $2.20의 비용이 들지만, 컨텍스트를 200K까지 확장하여 긴 문서 요약 파이프라인 (long-document summarization pipelines)에 사용합니다.

Qwen3-32B는 입력 $0.30, 출력 $1.20이며, 32K로 더 제한된 컨텍스트를 가집니다. 이 모델은 구조화된 추출 (structured extraction) 작업에서 체급 이상의 성능을 보여줍니다. GLM-4 Plus는 입력 $0.20, 출력 $0.80에 128K 컨텍스트를 제공하는 제 스택의 가성비 영웅 (budget hero)입니다. 저는 분류 (classification) 트래픽의 대부분을 이 모델로 라우팅합니다.

그다음은 입력 $2.50, 출력 $10.00인 GPT-4o가 있습니다. 그 출력 비용 수치를 다시 한번 보십시오. 100만 토큰당 $10.00입니다. 단일 500토큰 응답에 대해 0.5센트가 소요됩니다. 이를 40,000 RPM (Requests Per Minute)으로 곱하면 고통스러운 계산 결과가 나옵니다. 저희는 반드시 필요한 경우에만 GPT-4o를 사용하며, 그 경우에도 CDN 엔지니어가 얼굴을 붉힐 정도로 강력한 캐싱 레이어 (caching layers)로 감싸서 사용합니다.

GLM-4 Plus와 GPT-4o 사이의 출력 비용 격차는 12.5배입니다. 이것은 반올림 오차가 아닙니다. 이는 투자를 받는 프로젝트와 종료 (sunset)되는 프로젝트 사이의 차이입니다.

나의 멀티 리전 아키텍처 (그리고 이것이 중요한 이유)

저는 us-east-1, eu-west-1, ap-southeast-1의 세 개 리전 (region)에 걸쳐 액티브-액티브 (active-active) 배포를 운영합니다. 그 이유는 단순히 지연 시간 (latency) 때문만이 아니라 계약 때문입니다. 우리의 엔터프라이즈 고객들은 99.9%의 업타임 (uptime)을 요구하며, 단일 리전 배포는 가용 영역 장애 (zonal outage) 발생 시 그 약속을 지킬 수 없습니다. 저는 클라우드 제공업체에 문제가 생긴 평범한 화요일에

특히 LLM 레이어의 경우, 저는 세 개 지역(region) 모두에서 Global API를 가리키는 통합 SDK를 유지합니다. 모델 이름과 요청 형태(request shape)는 동일하며, 장애 조치(failover)가 발생할 때 베이스 URL(base URL)만 달라집니다. 99.9% SLA는 저에게 마케팅 문구가 아니라, 제가 반드시 지켜야 하는 계약입니다.

실제로 프로덕션에서 실행되는 코드

다음은 제가 인터뷰에서 보여주는 간단한 버전입니다:

import openai
import os

...

깔끔하고 잘 작동합니다. 하지만 프로덕션에서 실행되는 버전은 내부적으로 훨씬 더 많은 것을 처리합니다. 서킷 브레이커(circuit breakers), 재시도 로직(retry logic), 시맨틱 캐싱(semantic caching), 그리고 모델이 오작동할 때 우아하게 성능을 저하시키는 폴백 체인(fallback chain) 등이 포함됩니다. 제가 실제로 배포하는 코드를 보여드리겠습니다:

import openai
import os
import hashlib
...

이것은 이론적인 이야기가 아닙니다. 제가 세 개 지역 전체에서 측정한 DeepSeek V4 Flash의 p99 지연 시간(latency)은 약 1.6초이며, 시스템은 두 번째 워커(worker)를 추가하기 전까지 지역당 초당 약 320개의 토큰을 처리합니다. 이것이 제가 설계 리뷰(design review)에서 인용하는 처리량(throughput) 수치인데, 왜냐하면 이 수치가 제가 프로비저닝(provision)해야 하는 복제본(replica)의 수와 직접적으로 연결되기 때문입니다.

60% 절감 뒤에 숨겨진 수치들

여기서 저는 정확하고 싶습니다. 비용을 40~65% 절감했다고 말할 때, 저는 감사관(auditor)이 사용하는 방식과 동일하게 구체적으로 말하는 것입니다. 백만 토큰당 비용이 혼합 요율 기준 $4.20(GPT-4o 비중이 높음)에서 $1.75(GLM-4 Plus 및 DeepSeek V4 Flash 비중이 높음)로 떨어졌습니다. 계산식은 다음과 같습니다: ($4.20 - $1.75) / $4.20 = 58.3%. 이것이 제가 복도에서 대화할 때 흔히 말하는 60%라는 수치입니다.

84.6%라는 평균 벤치마크 점수는 상위 20개 유스케이스(use case)에 대해 자체적인 프라이빗 평가 스위트(private evaluation suite)를 실행하여 얻은 결과입니다. 여기에는 MMLU 하위 집합, HumanEval 조각, 그리고 저희만의 도메인 특화 테스트가 포함됩니다. 트래픽의 70%를 GPT-4o에서 전환했을 때 품질 저하는 관찰되지 않았습니다. 컨텍스트(context)가 충분하고 온도(temperature)가 잘 조정되어 있다면, 구조화된 작업(structured tasks)들은 어떤 모델이 처리하느냐에 크게 개의치 않았습니다.

실제로 유의미한 변화를 만들어낸 최적화 전략

저는 수십 가지 시도를 해보았습니다. 대부분은 미미한 영향만을 주었습니다. 그중 제가 다시 반복할 만한 다섯 가지는 다음과 같습니다:

공격적인 캐싱 (Aggressive caching)은 단일 항목 중 가장 큰 승리였습니다. 첫 달 만에 시맨틱 캐시 (semantic cache) 히트율 40%를 달성했으며, 현재 그 수치는 안정화되었습니다. 계약 검토, FAQ 답변, 템플릿 생성과 같은 반복적인 기업용 쿼리(queries)의 경우, 이는 게임 체인저입니다. 캐시 히트가 발생할 때마다 추론 (inference)에 쓰지 않아도 되는 비용이 절감됩니다.

스트리밍 응답 (Streaming responses)은 직접적으로 돈을 아껴주지는 않지만, 사용자 경험을 변화시킵니다. 전체 응답에 1.5초가 걸리더라도 첫 번째 토큰이 200ms 안에 도착하면 체감 지연 시간 (perceived latency)은 극적으로 줄어듭니다. p99 체감 지연 시간과 p99 실제 지연 시간 (actual latency)은 매우 다른 지표이며, 저는 두 가지를 모두 추적합니다.

단순 쿼리에 대한 GA-Economy 라우팅 (routing)은 해당 트래픽 하위 집합에서 추가로 50%를 절감해 주었습니다. 저희는 아주 작은 라우팅 모델 (routing model)로 들어오는 요청을 분류하고, 사소한 쿼리들은 더 저렴한 경로로 보냅니다. 핵심 통찰은 이렇습니다: 저희 트래픽의 대부분은 프런티어 모델 (frontier model)을 필요로 하지 않습니다. 대부분은 쉬운 작업을 빠르게 정확히 처리하는 모델을 필요로 합니다.

품질 모니터링 (Quality monitoring)은 화려하지 않은 부분입니다. 저는 사용자 만족도 점수, 재시도율 (retry rates), 그리고 명시적인 좋아요/싫어요 (thumbs-up/thumbs-down) 신호를 추적합니다. 모델의 품질이 드리프트 (drift)될 때, 고객이 알기 전에 제가 먼저 알아야 합니다. 이것이 비용을 절감하는 시스템과, 비용을 절감하면서도 제대로 작동하는 시스템의 차이입니다.

폴백 (Fallback) 구현은 타협할 수 없는 사항입니다. 속도 제한 (Rate limits)은 발생합니다. 할당량 (Quotas)은 소진됩니다. 모델은 유지보수를 위해 다운됩니다. 만약 당신의 시스템이 우아하게 성능을 저하시키지 (degrade gracefully) 못한다면, 당신은 프로덕션 시스템을 가진 것이 아니라 데모를 가진 것입니다. 저의 폴백 체인은 포기하기 전에 세 개의 모델을 시도하며, 기본 모델에 문제가 있는 날에도 전체 시퀀스는 보통 6초 이내에 완료됩니다.

제가 틀렸던 것들 (당신은 그러지 않도록)

처음에는 가장 낮은 p50 지연 시간 (latency)을 최적화하려고 시도했습니다. 그것은 실수였습니다. 중요한 것은 p99였고, 그보다 더 중요한 것은 지연 시간 분포의 '형태 (shape)'였습니다. 가끔 3초의 스파이크 (spike)가 발생하는 p50 800ms 모델은, 분산 (variance)이 적고 안정적인 p50 1.2s 모델보다 운영 측면에서 더 나쁩니다. 저는 모델 배포 (rollout) 중에 꼬리 지연 시간 (tail latency) 예산이 폭발하면서 이를 뼈아프게 배웠습니다.

또한 라우팅 계층 (routing layer)을 과하게 설계했습니다. 비용과 품질에 따라 모델을 동적으로 선택하는 멀티 암드 밴딧 (multi-armed bandit) 시스템을 구축했습니다. 영리한 방식이었지만, 유지보수 부담이 컸습니다. 실제로 프로덕션에 배포된 것은 단순한 계층형 라우팅 테이블 (tiered routing table)이었습니다. 때로는 지루한 솔루션이 정답일 때가 있습니다.

세 번째 실수는 Global API에 있는 184개의 모델이 모두 동일하게 신뢰할 수 있다고 가정한 것이었습니다. 그렇지 않습니다. 어떤 모델은 매우 빠르지만 불안정합니다. 어떤 모델은 더 느리지만 매우 견고합니다. 저는 우리 스택의 모든 모델에 대해 신뢰도 점수 (reliability score)를 유지하며, 신뢰도에 따라 비용에 가중치를 둡니다. 500 에러를 던지는 저렴한 모델은 그냥 잘 작동하는 더 비싼 모델보다 더 비용이 많이 듭니다.

14개월 후 제가 도달한 지점

현재 저의 아키텍처는 재무 보고서의 한 줄에 편안하게 들어갈 정도의 비용으로 월 21억 개의 토큰을 처리합니다. 지난 분기에 우리는 단 한 건의 장애 — 제공업체 유지보수 시간 동안 eu-west-1에서 발생하여 우리의 페일오버 (failover)가 흡수한 23분간의 성능 저하 — 를 제외하고 99.9%의 업타임 (uptime)을 달성했습니다. p99 지연 시간은 1.6초입니다. 평균 처리량 (throughput)은 리전당 초당 320 토큰입니다.

이 스택은 가장 좋은 의미에서 지루합니다. 세 개의 리전. 하나의 통합된 API. 잘 파악된 몇 가지 모델. 캐싱 (Caching). 폴백 (Fallbacks). 모니터링 (Monitoring). 마법도 없고, AI가 AI를 라우팅하는 AI 기반 AI도 없습니다. 그저 실제 문제에 적용된 탄탄한 엔지니어링뿐입니다.

만약 여러분이 불어나고 있는 LLM 청구서를 바라보며 어디서부터 시작해야 할지 고민하고 있다면, 저는 이렇게 말하겠습니다. 측정하지 않는 것은 최적화하지 마세요. 먼저 관측성 (observability)을 확보하세요. 그런 다음 저렴한 트래픽을 저렴한 모델로 라우팅하세요. 그다음 캐싱을 추가하세요. 그다음 튜닝하세요. 화려한 기술은 마지막에, 그리고 기본 사항만으로는 충분하지 않을 때만 도입하는 것입니다.

Global API에 있는 184개의 모델은 제가 접해온 거의 모든 유스케이스 (use case)를 커버하며, 통합 SDK (unified SDK) 덕분에 새벽 2시에 글루 코드 (glue code)를 작성할 필요가 없습니다. 솔직히 말씀드리면, 아직 통합 엔드포인트 (unified endpoint)를 통해 라우팅하고 있지 않다면 global-apis.com에서 직접 확인해 보세요. 그들이 제공하는 무료 크레딧은 실제 워크로드 (workload)에 대해 제대로 된 벤치마크 (benchmark)를 실행하기에 충분하며, 가격 페이지에서는 184개 모델 전체 카탈로그를 한곳에서 확인할 수 있습니다. 제가 만약 이 모든 과정을 처음부터 다시 한다면, 바로 이곳에서 시작할 것입니다.