당신의 LLM은 과금하고 있는가? 토큰화, 투명성, 그리고 인센티브

Digest: 상용 LLM-as-a-service는 대부분 pay-per-token(토큰당 과금) 방식이지만, 사용자는 최종 텍스트만 볼 뿐 공급자가 내부적으로 그 텍스트를 어떻게 토큰화했는지는 관찰할 수 없다. 저자들은 이 정보 비대칭(information asymmetry, 공급자만 생성 과정을 아는 상황)이 공급자에게 “같은 텍스트를 더 긴 토큰열로 보고”해 과금을 부풀릴 경제적 유인을 준다는 것을 principal-agent(주인-대리인) 이론으로 형식화한다. 각 문자를 개별 토큰으로 쪼개 보고하는 단순 전략만으로도 Llama-3.2-1B에서 344.9±3.8%의 초과 토큰(overcharge)이 발생한다(Table 1, LMSYS 400 프롬프트, temperature=1.0). 샘플링 제약(top-p) 하에서 “그럴듯한(plausible)” 최장 토큰화를 찾는 문제는 Hamiltonian path 환원으로 NP-Hard임을 증명하지만(Theorem 3), 탐지되지 않고 과금을 부풀리는 실용적 휴리스틱 Algorithm 1은 temperature 1.3·p=0.99에서 Ministral-8B 기준 최대 13%까지 초과 과금한다. 저자들은 additive(가산적) 가격제 중 유일하게 유인양립(incentive-compatible)한 것은 문자 수에 선형 비례하는 pay-per-character임을 증명하며(Theorem 6), 이 가격제는 공급자가 오히려 토큰화를 더 압축하도록 유도하는 긍정적 외부효과까지 가진다. 한계는 additive 가격제·단일 forward pass 감사 비용 무시·open-weight 모델만 검증이라는 점이다.


먼저 이해하기

ChatGPT나 API 같은 LLM 서비스는 보통 “토큰 1000개당 얼마” 식으로 돈을 받는다. 그런데 토큰(token, 모델이 텍스트를 잘게 나눈 처리 단위)이라는 게 문제다. 똑같은 문장 “hello world”라도 이걸 ["hello", " world"]처럼 2토큰으로 자를 수도 있고, ["h","e","l","l","o",...]처럼 11토큰으로 자를 수도 있다. 텍스트 결과물은 완전히 똑같은데 토큰 개수만 다르다.

여기서 핵심은 사용자는 최종 텍스트만 볼 수 있고, 서비스 제공자가 그 텍스트를 몇 개의 토큰으로 쪼갰다고 “보고”하는지는 확인할 방법이 없다는 것이다(정보 비대칭). 그래서 제공자는 마음만 먹으면 “사실 이건 토큰 11개짜리였어요” 하고 부풀려 청구할 수 있다. 이 논문은 (1) 이런 부풀리기가 실제로 얼마나 돈이 되는지 계산하고, (2) 어떻게 하면 이런 속임수를 원천적으로 불가능하게 만드는지를 수학적으로 증명한다.

왜 중요한가: pay-per-token은 현재 거의 모든 상용 LLM API의 표준 과금 방식이다. 논문의 실증에 따르면 각 문자를 토큰으로 쪼개는 단순 전략만으로 300%가 넘는 초과 과금이 원리적으로 가능하며(Table 1), 사용자가 이를 탐지하기 어렵다는 점에서 규제·투명성 논의의 근거가 된다. 저자들의 대안인 pay-per-character(문자당 과금)는 결과 텍스트의 문자 수에만 의존하므로 토큰화를 어떻게 하든 요금이 바뀌지 않아 속임수 유인이 사라진다.

먼저 알아둘 용어 표

용어쉬운 설명
pay-per-token출력한 토큰 개수에 비례해 요금을 매기는 과금 방식(현행 표준)
pay-per-character출력 텍스트의 문자 수에 비례해 요금을 매기는 대안 과금 방식
tokenization(토큰화)하나의 텍스트를 토큰열로 나누는 방식. 같은 텍스트에 여러 방식이 존재
information asymmetry(정보 비대칭)공급자는 생성 과정 전체를, 사용자는 최종 출력만 보는 불균형
incentive-compatible(유인양립)진실 보고가 공급자에게 항상 최선이 되어 속일 이유가 없는 성질
plausible tokenization(그럴듯한 토큰화)모델의 샘플링 규칙(top-p 등)상 실제로 생성될 수 있었던 토큰화

섹션별 요약

Abstract

상용 LLM은 pay-per-token으로 과금하지만 사용자는 출력 텍스트만 관찰하고 그 토큰화는 관찰하지 못한다. 이 정보 비대칭이 공급자에게 토큰화를 잘못 보고(misreport)해 과금을 부풀릴 유인을 준다. 저자들은 이 문제를 형식화하고, 최장 그럴듯한 토큰화 탐색이 NP-Hard임을 보이면서도 실용적 휴리스틱으로 상당한 과금이 가능함을 실증한다. 대안으로 유일한 유인양립 가격제인 pay-per-character를 제시한다.

왜 이 연구를 하는가?

LLM-as-a-service 시장이 커지면서 과금 정직성이 경제적으로 중요해졌다. 그러나 pay-per-token 구조는 공급자와 사용자 사이에 관찰 가능성의 격차(사용자는 텍스트만, 공급자는 토큰화까지)를 내재한다. 이 격차가 시장 신뢰를 훼손할 수 있는 구조적 유인을 만든다는 점이 연구 동기다.

Introduction

저자들은 공급자-사용자 상호작용을 principal-agent 이론으로 모델링한다. 사용자 효용은 출력 “텍스트”에서 나오지 토큰화에서 나오지 않으므로, 텍스트가 동일한 한 토큰화를 부풀려도 사용자는 손해를 감지하지 못한다. 반대로 pay-per-token에서 공급자 효용은 보고 토큰 길이에 선형 증가한다. 가장 극단적 전략은 각 문자를 개별 토큰으로 보고하는 것이며, 이것이 과금 상한을 형성한다.

Methods

핵심 정의와 결과:

  • Definition 1 (Pricing Mechanism): 가격제는 토큰열 공간 V에서 비음 실수로 가는 함수 r: V → ℝ≥0.
  • Definition 4 (Incentive-Compatibility): 어떤 토큰열이든 진실 보고 효용이 오보고 효용 이상이면 그 가격제는 IC(유인양립).
  • Proposition 5: 모든 IC 가격제는 토큰화와 무관하게 동일 문자열을 동일 가격으로 매겨야 한다(오직 밑바탕 문자열만 요금을 결정).
  • Theorem 3: top-p 샘플링 하에서 최장 “그럴듯한” 토큰화를 찾는 문제는 Hamiltonian path 환원으로 NP-Hard.
  • Theorem 6: additive 가격제가 IC일 필요충분조건은 문자 수에 선형 의존, 즉 r(t) = Σ countσ(t)·r(σ) 형태이며, 균일 문자 가격이면 pay-per-character가 유일 해.

Algorithm 1: 어휘 인덱스가 높은 토큰을 반복적으로 쪼개(split) 더 긴 그럴듯한 토큰열을 탐색하는 그리디 휴리스틱. 복잡도 O(m(log m + σmax)). 각 후보의 그럴듯함은 단일 forward pass로 next-token 분포를 확인해 판정하며, 이 비용은 무시 가능하다고 가정.

발견 (Findings)

  • 단순 문자 단위 보고만으로 300%를 넘는 초과 과금이 원리적으로 가능(모든 테스트 모델).
  • NP-Hardness는 “최적” 오보고를 막을 뿐, 실용적 근사(Algorithm 1)로도 상당한 과금이 가능.
  • 과금 여지는 temperature가 높을수록, top-p가 관대할수록(p가 클수록) 커진다.
  • pay-per-character는 오보고 유인을 제거할 뿐 아니라 공급자가 토큰화를 더 압축(짧게)하도록 유도해 에너지·추론속도 측면 긍정적 외부효과를 만든다.

Results

Table 1 (LMSYS Chatbot Arena 400 프롬프트, temperature=1.0, 각 문자를 개별 토큰으로 보고했을 때 초과 토큰 비율):

ModelOvercharge %
Llama-3.2-1B-Instruct344.9 ± 3.8
Llama-3.2-3B-Instruct345.2 ± 6.0
Gemma-3-1B-It308.9 ± 1.4
Gemma-3-4B-It320.8 ± 5.6
Ministral-8B-Instruct-2410337.8 ± 4.29

Algorithm 1 (top-p 샘플링, temperature 1.3, 탐지되지 않는 조건):

  • Llama-3.2-1B: 9.5% (p=0.99), 1.6% (p=0.95), 0.3% (p=0.9)
  • Ministral-8B: 13% (p=0.99), 2.6% (p=0.95), 0.3% (p=0.9)

문자당 가격 환산: rc = r₀/cpt, 여기서 평균 문자/토큰(cpt)은 Llama 4.50, Gemma 4.22, Ministral 4.43. 이 환산은 매출 중립(revenue-neutral)을 유지한다.

Discussion

NP-Hardness(Theorem 3)는 공급자가 생성 과정(next-token 분포)을 투명하게 공개할 때만 사용자 보호로 작동한다. 투명성 요건이 없으면 수학적 장벽에도 불구하고 사용자는 Algorithm 1류 근사에 노출된다. 따라서 실질적 해법은 규제 차원의 가격제 전환(pay-per-character)이거나 생성 과정 감사 가능성 확보다.

이론적 의의

“어떤 가격제가 정직 보고를 강제하는가?”라는 질문을 mechanism design(메커니즘 설계) 문제로 환원하고, additive 범주 안에서 pay-per-character의 유일성을 증명했다는 점이 이론적 기여다. 이는 토큰화라는 구현 세부가 시장 인센티브와 직접 연결됨을 보여준다.

Discussion Points

  • 투명성 없는 NP-Hardness는 실효적 방어가 되지 못한다 — 근사 공격(Algorithm 1)이 존재.
  • pay-per-character의 매출 중립성은 cpt 추정에 의존 — 분포가 바뀌면 재보정 필요.
  • additive 범주 밖(비가산적·번들 가격제)에서의 유인양립 가능성은 열린 문제.

실험 결과 상세

표 A. 문자 단위 보고 시 초과 과금 (Table 1, LMSYS 400 prompts, temperature=1.0)

ModelDatasetMetric값출처
Llama-3.2-1B-InstructLMSYS-400Overcharge %344.9 ± 3.8Table 1
Llama-3.2-3B-InstructLMSYS-400Overcharge %345.2 ± 6.0Table 1
Gemma-3-1B-ItLMSYS-400Overcharge %308.9 ± 1.4Table 1
Gemma-3-4B-ItLMSYS-400Overcharge %320.8 ± 5.6Table 1
Ministral-8B-Instruct-2410LMSYS-400Overcharge %337.8 ± 4.29Table 1

표 B. Algorithm 1의 탐지 회피 과금 (top-p 샘플링, temperature=1.3)

Modelp=0.99p=0.95p=0.9출처
Llama-3.2-1B9.5%1.6%0.3%Fig. 2 / 본문
Ministral-8B13%2.6%0.3%Fig. 2 / 본문

표 C. 문자/토큰 환산 계수 (pay-per-character 매출 중립 설정)

Modelcpt (평균 문자/토큰)rc
Llama4.50r₀/4.50
Gemma4.22r₀/4.22
Ministral4.43r₀/4.43

프레임워크 다이어그램

flowchart TD
    U[사용자: 프롬프트 전송] --> P[공급자: LLM 생성]
    P --> TXT[출력 텍스트 str t - 사용자 관찰 가능]
    P --> TOK[내부 토큰화 t - 사용자 관찰 불가]
    TXT --> V[사용자 효용: 텍스트에서만 발생]
    TOK --> R{과금 방식}
    R -->|pay-per-token| M1[보고 토큰 수에 비례 요금]
    R -->|pay-per-character| M2[출력 문자 수에 비례 요금]
    M1 --> MIS[오보고 유인 존재: 문자 분할·Alg.1]
    MIS --> OVER[초과 과금 최대 약 345 percent 원리적]
    M2 --> IC[유인양립: 토큰화 무관 요금 고정]
    IC --> POS[긍정 외부효과: 토큰화 압축 유도]

재현성 및 신뢰도 평가

종합등급: B (Evidence-Quality B / Reproducibility B)

근거: 이론적 주장은 명시된 정의와 증명(Theorem 3, 6, Proposition 5)으로 뒷받침되며, 실증은 공개 open-weight 모델(Llama-3.2, Gemma-3, Ministral-8B)과 공개 데이터셋(LMSYS Chatbot Arena)에서 오차범위(±)와 함께 보고되어 재현 가능성이 높다. 다만 (1) 코드 공개 여부가 본문에서 확정되지 않고, (2) LMSYS가 실사용 분포를 대표하지 못할 수 있다는 저자 자인의 한계가 있어 A에는 미치지 못한다.

  • 주장 1 (문자 단위 보고 시 ~345% 과금 가능): 신뢰도 높음 — 다섯 모델 모두 300%대, 좁은 표준편차. 단, 이는 원리적 상한이며 탐지 무시 가정.
  • 주장 2 (Theorem 3, NP-Hardness): 신뢰도 높음 — Hamiltonian path 환원 제시. 단, 최적 공격 불가일 뿐 근사 공격은 유효.
  • 주장 3 (Algorithm 1로 최대 13% 탐지 회피 과금): 신뢰도 중간 — 특정 setting(temp 1.3, p=0.99)에서만 두 자릿수, p가 낮아지면 급감(0.3%).
  • 주장 4 (Theorem 6, pay-per-character 유일성): 신뢰도 높음(이론) — 단 additive 가격제 범주로 한정된 결과.

원자적 인사이트 (Zettelkasten)

  • 정보 비대칭이 과금 유인을 만든다: 사용자 효용은 출력 텍스트에서만 발생하고 토큰화는 관찰 불가하므로, pay-per-token에서 공급자는 텍스트를 바꾸지 않고도 토큰화를 부풀려 요금을 올릴 수 있다. 관찰 가능성의 격차가 곧 조작 여지다.
  • NP-Hardness는 투명성 없이는 방어가 아니다: 최적 오보고 탐색이 NP-Hard(Theorem 3)라도, 그리디 근사(Algorithm 1)가 실질적 과금을 달성한다. 계산 난해성은 “완벽한 최적화”만 막을 뿐 “충분히 이득이 되는 근사”는 막지 못한다.
  • 가격제를 관찰 가능한 양에 묶으면 유인이 정렬된다: pay-per-character는 사용자가 직접 관찰·검증 가능한 문자 수에만 요금을 연동하므로, 토큰화가 어떻든 요금이 불변이 되어 오보고 유인이 소멸한다(Theorem 6).
  • 정직 가격제는 뜻밖의 정렬 효과를 낳는다: pay-per-character 하에서 진실 보고 공급자의 효용은 토큰열이 짧을수록 커지므로, 공급자가 자발적으로 토큰화를 압축해 추론 비용·에너지를 줄일 유인이 생긴다.

핵심 용어 정리

용어정의
pay-per-token출력 토큰 수에 비례해 과금하는 현행 표준 방식. 토큰화 부풀리기에 취약
pay-per-character출력 문자 수에 비례해 과금하는 대안. additive 범주에서 유일한 유인양립 해(Theorem 6)
incentive-compatibility (IC)어떤 입력에서도 진실 보고 효용이 오보고 효용 이상이어서 속일 이유가 없는 성질(Definition 4)
plausible tokenization모델의 샘플링 규칙(top-p/top-k) 하에서 실제 생성 가능했던 토큰화. 오보고는 이 집합 안에서만 탐지를 피함
principal-agent model정보 비대칭 하 주인(사용자)-대리인(공급자) 상호작용을 분석하는 경제 이론 틀
cpt (characters per token)모델별 평균 문자/토큰 계수. pay-per-character 매출 중립 환산(rc=r₀/cpt)에 사용

관련 연구

태그

LLM tokenization mechanism-design pricing incentive-compatibility principal-agent


BibTeX

@misc{artolavelasco2025overcharging,
  title        = {Is Your LLM Overcharging You? Tokenization, Transparency, and Incentives},
  author       = {Artola Velasco, Ander and Tsirtsis, Stratis and Okati, Nastaran and Gomez-Rodriguez, Manuel},
  year         = {2025},
  eprint       = {2505.21627},
  archivePrefix= {arXiv},
  primaryClass = {cs.LG},
  howpublished = {arXiv preprint arXiv:2505.21627},
  url          = {https://arxiv.org/abs/2505.21627}
}