온라인상의 모든 "어떤 모델이 가장 저렴한가요?"라는 스레드는 사람들이 막연한 느낌(vibes)을 주고받는 것에 불과합니다. 저는 이에 지쳐, 실시간으로 인용된 가격을 가져와 **정확한 유리수 수학 커널 (exact-rational math kernel)**을 통해 수치를 계산하는 파이프라인을 구축했습니다. 부동 소수점 오차(floating-point drift)도 없고, LLM이 곱셈을 환각(hallucinating)하는 일도 없습니다. 그런 다음, 에이전트 빌더가 실제로 직면하는 8가지 비용 질문에 이 파이프라인을 적용했습니다. 여기 그 결과와 여러분이 직접 다시 실행해 볼 수 있는 리포지토리(repo)가 있습니다.

LLM 비용 조언에는 두 가지 종류가 있습니다. 첫 번째는 가격 열이 포함된 벤치마크 리더보드인데, 이는 여러분의 워크로드에 대해 아무것도 알려주지 않습니다. 두 번째는 누군가가 머릿속으로 100만 토큰당 가격에 잘못된 토큰 수를 곱해서 은밀하게 틀린 정보를 전달하는 자신만만한 트윗입니다.

저는 세 번째 종류를 원했습니다. 바로 **감사(audit)**할 수 있는 모델입니다. 다시 실행하면 비트 단위로 동일한(bit-identical) 숫자를 얻을 수 있으며, 모든 입력 가격의 출처는 파일 하나만 옆으로 가면 확인할 수 있습니다. 이 글은 그 결과물입니다. 실제 돈의 수학으로 답을 내린 8가지 비용 결정 과정을 살펴보고, 직관이 틀리는 지점이 무엇인지 배워보겠습니다.

그 시작이 된 질문부터 시작하겠습니다.

도입: 에이전트를 실행하기에 가장 비용 효율적인 모델은 무엇인가?

설정: 저는 모델 불가지론적(model-agnostic) 에이전트 프레임워크인 Hermes Agent를 실행하며, 이를 구동할 가장 저렴한 토큰 제공자를 찾고 싶었습니다. 단순히 토큰당 가장 저렴한 것이 아니라, 품질 단위당 가장 저렴한 것을 원했습니다. 도구 호출(tool calls)을 실수하고 재시도(retries)를 반복하는 모델은 더 비싸고 신뢰할 수 있는 모델보다 더 많은 비용이 들 수 있기 때문입니다.

따라서 지표는 **혼합 비용 (blended cost) ÷ 에이전트 품질 점수 (agentic-quality-score)**입니다. 혼합 비용은 프로덕션 에이전트용 토큰 믹스(아래에서 자세히 설명)를 사용하며, 품질은 정규화된 에이전트 점수(BFCL / τ²-bench / SWE-bench Verified의 평균)입니다. 필터 조건: 오픈 웨이트 (open-weights), 프롬프트 캐싱 (prompt caching), 학습 제외 (no-train).

모델 @ 제공업체	혼합 $/1M	품질 (Quality)	$/품질 (×1000)
DeepSeek V3.2 @ OpenRouter	0.1145	77	1.49
...
DeepSeek V3.2의 압도적 승리 — 이 모델은 해당 세트에서 가장 높은 품질을 가진 오픈 모델(open model)인 동시에 가장 저렴한 축에 속합니다. 그 이유는 해당 티어(tier) 대비 출력 토큰(output token) 가격이 터무니없이 낮기 때문입니다. (품질 테스트 결과에 따라 달라질 수 있지만) 새롭게 떠오르는 최고의 거래는 Fireworks의 DeepSeek V4 Flash로, 혼합 가격이 $0.0896/1M입니다. 이는 기본 ZDR(Zero Data Retention)과 50% 배치 할인(batch discount)을 제공하며 업계에서 가장 저렴합니다.

그것은 유용한 답변입니다. 하지만 흥미로운 부분은 그 질문이 열어젖히는 모든 것입니다. 만약 제공업체(provider) 간에 트래픽을 분산할 수 있다면, 최적의 조합은 무엇일까요? 대신 직접 호스팅(self-host)해야 할까요?

왜 굳이 이 고생을 해야 할까요? 비용 모델링(cost models)이야말로 부동 소수점(floating-point) 오류가 발생하고 LLM이 실수하기 딱 좋은 영역이기 때문입니다. 토큰당 아주 미세한 가격, 방대한 토큰 수, 그리고 복리로 작용하는 비율들이 얽혀 있습니다. "자체 호스팅(self-hosting)은 가동률 87.2%에서 손익분기점을 넘긴다"라는 답변이 나왔을 때, 여러분은 그것이 단순한 느낌(vibed)이 아니라 정확히 _계산(computed)_된 결과이기를 원할 것입니다. 이 가이드의 비밀스러운 구조는 각 장이 돈에 관한 질문에 답하는 동시에 하나의 커널 도메인(kernel domain)을 연습한다는 점에 있습니다. 즉, 이 책은 비용 모델링 핸드북인 동시에 정밀 계산(exact computation) 투어이기도 합니다.

공유 워크로드 모델 (The shared workload model)

모든 장에서는 하나의 프로덕션 에이전트용 토큰 프로필(production-agentic token profile)을 사용합니다. 에이전트의 도구 루프(tool-loops)는 입력 부하가 매우 크기 때문입니다:

구성 요소	토큰 점유율
새로운 입력 (Fresh input)	21.25%
...

이는 입력/출력 비율이 85/15이며, 입력의 75%가 캐시 히트(cache hit)인 구조입니다(시스템 프롬프트, 도구, 기술 등이 매 도구 루프 단계마다 다시 전송됩니다). 혼합 가격(Blended price) = 0.2125·in + 0.6375·cached + 0.15·out입니다. 7장에서는 왜 이러한 프로필이 강제되는지 설명하며, 6장에서는 왜 캐시 히트율이 그렇게 높은지를 설명합니다. 지금은 이를 워크로드로 받아들이십시오.

제1장 — 최적의 멀티 프로바이더 라우팅 (선형 계획법)

하나의 제공업체(provider)만 선택할 필요는 없습니다. 대량의 작업은 저렴한 곳에서 처리하고, 제약 조건이 요구될 때 다른 곳으로 격상(escalate)시키십시오. 품질 하한선, 엔드포인트별 용량 제한, 그리고 **미국 관할권 하한선 θ (US-jurisdiction floor θ)**를 조건으로 지출을 최소화하는 최적의 분할은 말 그대로 선형 계획법(linear program) 문제입니다. agent-calc가 이를 해결하며(solve_lp), 그 후 저는 승리한 할당량의 비용을 정밀 유리수(exact rationals)로 재검증합니다(LP 솔버는 f64를 사용하지만, 헤드라인 숫자는 그렇지 않아야 합니다).

개인정보 보호 노브(privacy knob) θ를 조절하면 **개인정보 보호 비용 경계선(cost-of-privacy frontier)**을 추적할 수 있습니다:

미국 하한선 θ	최소 $/1M	$/mo @ 1B	할당량
0.00–0.40	0.1468	$146.77	A=0.60, B=0.40
...

직관이 놓치는 세 가지 사항은 다음과 같습니다:

1. 미국 관할권 트래픽의 첫 40%는 무료입니다 — 가장 저렴한 제공업체의 한도가 60%로 제한되어 있고, 초과분은 어차피 미국 엔드포인트(endpoint)로 넘어가기 때문에 비용 최적화 혼합(cost-optimal blend)은 이미 그 지점에 도달해 있습니다.
2. 개인정보 보호의 한계 비용(marginal cost)은 볼록(convex)합니다 — 40%에서 60%까지는 저렴하지만, 60%를 넘어서면 품질 하한선(quality floor) 때문에 성능이 낮은 대체재를 강제로 사용해야 하며, 비용은 87%까지 거의 두 배로 치솟습니다.
3. 87.2% 지점에는 단단한 벽이 존재합니다. 이 메뉴에는 단 하나의 고품질 미국 엔드포인트만 존재합니다. 해당 용량을 넘어서면 수학적으로 실행 불가능해집니다. 이 벽을 깨려면 두 번째 고품질 미국 제공업체가 필요하거나, 단일 장애점(single-point-of-failure) 위험을 감수해야 합니다.

제2장 — 셀프 호스팅(Self-host) vs 서버리스(serverless): 이는 활용도(utilization)의 문제입니다

모두의 직관은 이렇습니다: "어느 정도 규모가 되면, GPU를 대여하는 것이 토큰당 API 비용보다 유리할 것이다." 모든 것을 바꾸는 재정의는 다음과 같습니다: 셀프 호스팅 노드(self-hosted node)는 부하(load)가 5%일 때나 95%일 때나 비용이 동일한 반면, API는 토큰에 따라 선형적으로 증가합니다. 따라서 이는 금액 기준의 손익분기점이 아니라, **활용도 손익분기점(break-even utilization)**의 문제입니다. 즉, 이득을 보려면 장비를 얼마나 바쁘게 돌려야 하는가의 문제입니다.

u* = node_$/mo × 1e6 / (capacity_tokens/mo × API_$/1M)

만약 u* > 100%라면, 셀프 호스팅은 풀 가동(full tilt) 상태에서도 손해입니다. DeepInfra의 $0.195/1M 토큰 비용과 비교하여 DeepSeek V3.2(8-GPU 노드)를 모델링해 보겠습니다. 이때 agent-calc는 자체 하드웨어 상각(finance)과 정확한 u*(eval)를 처리합니다.

하드웨어 / 조달 (procurement)	손익분기점 u*	판결
8×H200, 온디맨드(on-demand) 대여	531%	절대 불가
...

API를 통한 이 정도로 저렴한 범용 모델(commodity model)을 사용할 경우, GPU를 대여하는 것은 모든 구성에서 손해입니다. 서버리스 제공업체는 개별 사용자가 도달할 수 없는 수준의 가동률(utilization)을 달성하기 위해 수천 명의 테넌트(tenant)에 걸쳐 배치를 처리하기 때문입니다. 유일하게 승리하는 구성은 Blackwell 실리콘을 직접 소유하고 24시간 내내 약 72% 이상의 가동률을 유지하는 것(~월간 약 56B 토큰의 꾸준한 부하)뿐입니다. 그리고 하락하는 API 최저가($0.0896/1M)와 비교하면, 그마저도 손익분기점이 대략 두 배로 늘어납니다. 결론: 자체 호스팅(self-host)은 개인정보 보호, 제어권, 또는 지연 시간(latency)을 위해서 해야 하는 것이지, 토큰 비용을 줄이기 위해 하는 것이 아닙니다.

제3장 — 추론 토큰 세금 (The reasoning-token tax)

추론 모델(Reasoning models)은 숨겨진 "생각(thinking)" 토큰을 생성하며, 이는 출력(output) 요율로 청구됩니다. 600토큰짜리 답변이 7,800토큰으로 청구될 수 있습니다. 더 높은 성공률이 이러한 소모를 정당화할까요? 정직한 단위는 $/token이 아니라, 해결된 작업당 비용 (cost per solved task) = 시도 비용 ÷ 성공률입니다.

agent-calc가 정확한 비용(eval)과 손익분기점 성공률(solve)을 계산하면 다음과 같습니다:

모델	k (생각 배수)	해결된 작업당 $/	×챔피언
DeepSeek V3.2	4	3.17m	1.00×
...
(m = 밀리달러 = 작업당 $0.001)

충격적인 결과: DeepSeek R1이 V3.2의 작업당 비용과 일치하려면 627%의 성공률이 필요합니다. 이는 수학적으로 불가능합니다. 심지어 완벽한 R1이라 할지라도 훨씬 더 비쌉니다. 왜냐하면 R1의 시도당 토큰 소모량만으로도 V3.2의 전체 작업당 비용을 초과하기 때문입니다. 전수 조사(sweep) 결과가 이를 확인해 줍니다. k=0(생각 없음)인 경우에도 R1은 여전히 챔피언보다 2.6배 더 비쌉니다.

규칙: 추론 세금은 출력 토큰이 저렴할 때만 이득이 됩니다. 생각(Thinking)은 출력 가격에 곱해지는 승수(multiplier)입니다. $2.15/M를 내면서 12배의 승수를 적용한다면, 작업을 해결하는 가장 비싼 방법을 구축한 셈이 됩니다. 반면 $0.38/M를 낸다면 동일한 승수가 적용되어도 그 영향은 미미합니다.

제4장 — 재시도 폭포 (The retry cascade)

모든 작업에 하나의 모델만 사용할 필요는 없습니다. 모든 작업에는 저렴한 (cheap) 모델을 실행하고, 잔여 실패(residual failures)가 발생할 때만 신뢰할 수 있는 프리미엄 모델로 에스컬레이션 (escalate) 하십시오. agent-calc는 에스컬레이션 확률(stats/binomial_pmf)과 정확한 기대 비용(eval)을 계산합니다.

전략	해결당 비용 (cost/solved)	커버리지 (coverage)	% → 프리미엄
저가형 전용 (DeepSeek V3.2)	3.17m	77.0%	0%
...

이 폭포(cascade) 방식은 두 가지 축 모두에서 프리미엄 전용 방식보다 우수합니다. 오직 23%의 작업만이 비싼 모델에 도달하기 때문에, 비용은 4분의 1 수준이면서도 더 높은 커버리지(97% vs 88%)를 달성합니다. 중간 단계(mid-tier)를 추가하면 비용을 더욱 절감하면서도 커버리지를 99.5%까지 끌어올릴 수 있습니다. 저가형과 중간 단계가 트래픽의 95.6%를 흡수하므로, 7,300만 달러 규모의 Opus 호출은 작업의 4.4%에서만 발생합니다.

그리고 피해야 할 함정은 다음과 같습니다: 동일한 모델을 재시도하는 것은 해결당 비용 (cost-per-solved)을 절대 변화시키지 못하며 (C/p 상태 유지), 결정론적 실패(deterministic failures)의 경우에는 커버리지조차 높이지 못합니다. 오직 다른, 더 강력한 모델로 에스컬레이션해야만 유의미한 변화가 생깁니다. "그냥 재시도를 추가하라"는 아무런 효과가 없는 작업(no-op)이지만, "계층(tier)을 추가하라"는 승리하는 전략입니다. (비용 우위는 강력한 실패 상관관계가 존재할 때도 유지됩니다. 즉, 프리미엄 모델이 저가형 모델이 망친 작업을 구제하는 경우가 드물 때조차 프리미엄 전용 방식보다 3.6배 더 저렴합니다.)

제5장 — 기다림의 순현재가치 (The NPV of waiting)