언어별로 가장 저렴한 LLM은? Tokenizer 비용 실측

다국어 텍스트에서 항상 가장 저렴한 LLM은 없다. 같은 문단을 측정한 결과, 유럽 언어와 힌디어, 한국어에서는 GPT-5.5가 가장 적은 token을 청구했고, 중국어에서는 Kimi K2.5, 일본어에서는 DeepSeek가 가장 적었다. Claude Fable 5, Opus 4.8, Sonnet 5는 하나의 tokenizer를 공유해 모든 샘플에서 token 수가 같았으며, 어느 언어에서도 가장 적지 않았다. 동일한 영어 문단이 Claude에서는 raw token 90개, DeepSeek에서는 55개로 계산됐다. net 기준 추가 비용은 일본어의 1.3x부터 중국어의 2.2x까지였다. 과금 단위는 token이다. 따라서 가격표에서는 좀처럼 드러나지 않는 두 요소가 입력 비용을 결정한다. 하나는 언어가 문자에 의미를 얼마나 조밀하게 담는지이고, 다른 하나는 각 모델의 tokenizer가 해당 문자를 얼마나 잘 압축하는지다. 두 값은 곱해지며, 그 결과는 문자당 비용만 봐서는 알 수 없다.

TL;DR

• Claude Fable 5, Opus 4.8, Sonnet 5는 하나의 tokenizer를 공유하며, 어느 경우에도 가장 적지 않았다. 모든 언어에서 최저 token 수보다 1.2-2.3x 많았다.
• 가장 효율적인 tokenizer는 언어마다 다르다. 유럽 언어, 힌디어, 한국어는 GPT-5.5, 중국어는 Kimi, 일본어는 DeepSeek였다.
• 문자당으로 보면 CJK가 3x 비싸 보이지만, 의미당으로 보면 중국어는 거의 비슷하고 일본어와 한국어는 1.5-2.4x다.
• 비용은 문자 체계의 밀도와 tokenizer coverage의 곱이다. coverage가 부족하면 격차가 더 커진다. GLM은 힌디어를 영어의 4.9x로 계산한다.
• 현지화만으로 비용이 줄어드는 경우는 드물다. 언어별 token 수에 맞춰 모델을 선택해야 한다.

2026-07-08에 Synthorai gateway를 통해 측정했다. local tokenizer는 쓰지 않고 항상 각 provider가 반환한 수치를 사용했다. 반복 측정에서도 모든 값이 같았다.

과금 단위는 텍스트가 아니라 token이다

비용은 token 단위로 청구되지만, token은 문자도 단어도 아니다. 모델마다 고유한 vocabulary를 가진 tokenizer를 사용하므로 같은 문장도 모델별 token 수가 달라진다. 이 수치에 token당 가격이 곱해진다. 즉 텍스트가 몇 token으로 변환되는지와 token 하나의 가격이 동시에 달라진다.

대부분의 가격 페이지에는 두 번째 수치만 나온다. 이 글에서는 첫 번째 수치를 측정했다. 의미를 맞춘 문단 3개를 모델 7종(claude-fable-5, claude-opus-4-8, claude-sonnet-5, deepseek-v4-flash, glm-5.2, gpt-5.5, kimi-k2.5)에 전송하고, 각 모델이 입력으로 청구한 token 수를 확인했다.

일상적인 서사문인 토요일 시장 이야기는 9개 언어로 준비했다. 기술 설명인 exponential backoff 재시도와 뉴스 단신인 도시 예산 표결은 영어, 중국어, 일본어, 한국어, 독일어, 힌디어로 만들었다. Python 함수와 JSON tool-call blob도 테스트에 포함했다. 비영어 버전은 의미를 충실히 유지하고 압축하지 말라는 지시로 기계 번역한 뒤 사람이 일부를 확인했다. 번역문 길이 차이는 실제 교란 요인이며, 아래 문체 섹션에서 그 범위를 약 20%로 잡았다.

token 수는 항상 provider가 반환한 값을 사용했다. Claude 계열은 실제 Messages 호출의 usage.input_tokens를 읽었다. 현재 gateway가 count_tokens를 proxy하지 않기 때문이다. OpenAI 호환 모델은 작은 요청을 보내 usage.prompt_tokens를 읽었다. local tokenizer의 결과가 청구서와 다른 문제를 피하기 위한 방식이다. 모든 요청에는 chat template과 role marker 같은 고정 framing이 포함돼 token 몇 개를 차지한다. 이를 통제하기 위해 문자 2개짜리 baseline 샘플을 측정해 차감했다. 이 글의 모든 비율은 해당 envelope을 뺀 net 값이며, framing이 아니라 텍스트만 비교한다.

같은 텍스트, 다섯 tokenizer

다음은 언어와 tokenizer별 서사문 입력 token의 raw count다. Claude 모델 3종은 모든 샘플에서 같은 값을 반환했으므로 하나의 열로 합쳤다. 자세한 내용은 아래에서 설명한다. 다른 문단 2개에서도 같은 패턴이 나왔으며, 이후 섹션에 함께 반영했다. chars 열은 각 언어 버전의 문자 수다. 문자 체계마다 의미를 담는 밀도가 다르기 때문에, 영어로 254자가 필요한 내용을 중국어는 77자로 표현한다.

두 가지가 바로 드러난다. Claude 열이 모델 3종에 대해 하나인 이유는 Claude Fable 5, Opus 4.8, Sonnet 5가 언어, code, JSON을 포함한 모든 샘플에서 같은 token 수를 반환했기 때문이다. 세 모델 모두 Opus 4.7에서 도입된 tokenizer를 사용하므로, 한 모델의 token 수를 알면 나머지도 같다. 힌디어에서는 GLM의 192가 더 많았지만, 이를 제외한 모든 행에서 Claude 열의 값이 가장 컸다. 먼저 envelope을 차감한 net count를 기준으로, 언어별 최저 모델을 1.00으로 정규화하면 다음과 같다. 따라서 아래 비율은 위 raw cell을 단순히 나눈 값과 일치하지 않는다.

영어 행에서 4개 모델이 공동 1위인 것은 반올림 때문이 아니다. 이 문단에서 DeepSeek, GLM, GPT-5.5, Kimi 모두 정확히 net token 50개였다. 이 문단에서 Claude는 가장 적은 tokenizer보다 1.3x에서 2.2x 많았고, 문단 3개 전체로는 1.2x에서 2.3x였다. 모델이 유지되는 동안 모든 호출에 적용되는 vocabulary 특성이다. 기술문과 뉴스문에서도 순위는 같았다. 두 문단을 합치면 중국어는 Claude가 net token 212개, Kimi가 114개로 1.9x 차이가 났다. 힌디어는 Claude가 477개, GPT-5.5가 210개로 2.3x였다. 다만 모든 언어에서 이기는 단일 모델은 없다. 언어가 바뀌면 가장 적은 열도 바뀐다.

• GPT-5.5는 독일어, 프랑스어, 스페인어, 이탈리아어, 힌디어, 한국어에서 가장 적었고, 영어에서는 공동 최저였다. 공동 최저와 fr/es/it 결과는 서사문에 한정된다. vocabulary가 Latin 문자에 맞춰져 있고 Devanagari와 Hangul에서도 좋은 효율을 유지한다.
• Kimi K2.5는 중국어에서 가장 적었고 CJK 전반에서도 경쟁력이 있었다.
• DeepSeek-v4는 일본어에서 가장 적었고 중국어에서도 근소한 차이로 뒤를 이었다.
• GLM 5.2는 대부분의 언어에서 중간 수준이었지만, 힌디어에서는 표 전체에서 가장 나쁜 값을 기록했다. 서사문 기준 최저 모델의 2.59x로, GPT-5.5가 net token 69개를 쓰는 동안 179개를 썼다. 격식 있는 문단에서는 차이가 더 커졌고, Claude보다 더 많은 유일한 열이었다.

이 추가 비용은 산문에만 국한되지 않는다. Python 함수에서 Claude는 최저 모델의 1.61x, JSON tool-call에서는 1.29x였다. JSON 격차가 더 작은 이유는 구조화된 텍스트 대부분이 모든 tokenizer에서 비슷하게 처리되는 문장부호와 짧은 ASCII key이기 때문이다. 큰 tool schema를 매 turn마다 다시 보내는 장기 실행 agent에서는 이 비용이 누적된다. 이때 caching의 효과가 커진다. 관련 원리는 prompt caching 시리즈에서 다룬다.

문자당 비용의 함정: CJK는 실제 청구액보다 비싸 보인다

위 표는 모델을 비교했다. 모델을 고정해도 언어에 따라 token 수는 달라지지만, 단순한 문자 기준과는 다른 양상이 나타난다. tokenizer에서 자주 인용되는 수치는 문자당 token 수이며, 이 기준에서는 CJK가 압도적으로 높다. Claude의 문자 100개당 net token 수는 중국어 약 114개, 한국어 106개, 일본어 94개였고 영어는 32개였다. 이 열만 보면 CJK에 3x의 추가 비용이 붙는 것처럼 보이지만, 잘못된 기준이다. 비용은 문자가 아니라 의미에 대해 지불한다. 정렬된 각 문단은 모든 언어에서 같은 의미를 담는다. 다음은 Claude에서 서사문을 두 관점으로 본 결과다.

오른쪽 두 열은 서로 다른 결론을 보여준다. 중국어에서 차이가 가장 뚜렷하다. 문자당 token 밀도는 가장 높지만, 이 문단의 의미당 추가 비용은 영어의 1.07x에 불과하다. 영어가 254자로 표현하는 내용을 77자로 전달하므로, 높은 문자당 비율에 매우 적은 문자 수가 곱해져 거의 상쇄된다. 문단 3개 전체에서도 상쇄 효과는 유지됐지만 완전히 사라지지는 않았다. 중국어는 Claude 자체 영어 대비 평균 1.17x였고, 모델에 따라 0.95x에서 1.32x였다. 문자당 열에서 보이는 3x가 아니라 거의 비슷한 수준이다.

일본어와 한국어에서는 같은 착시가 나타나지만 상쇄 효과가 약하다. 둘 다 문자당 token 밀도는 높지만, Hangul과 일본어 kana는 중국어 hanzi처럼 문자 하나에 단어 전체를 담기보다 대체로 음절당 한 글자로 소리를 표기한다. 따라서 중국어로 77자인 문단이 한국어에서는 143자, 일본어에서는 136자가 필요하다. 높은 문자당 비율에 더 많은 문자 수가 곱해지면서 비용이 상쇄되지 않고 커진다. Claude에서 문단 3개의 의미당 평균은 한국어가 영어의 1.96x, 일본어가 1.56x로 실제로 비쌌다. 문자당 열만 보면 중국어와 비슷해 보이지만 결과는 다르다.

독일어는 중국어의 반대다. 문자당 비율은 48로 영어에 가깝지만, 문자 수는 합성어 때문에 289자로 테스트 언어 중 가장 많아 총합은 1.68x가 된다. 비용은 두 축의 곱이므로 어느 한쪽만 보면 잘못된 결론을 내리게 된다.

수치가 달라지는 이유: 두 요소의 곱

위 모든 표를 설명하는 식은 하나다.

문단의 token 수 = (같은 의미를 표현하는 데 필요한 문자 수) x (문자당 token 수)

첫 번째 요소는 문자 체계의 밀도로, 모델이 아니라 언어의 속성이다. 중국어만의 예외가 아니라 연속적인 스펙트럼이다. 표어문자인 중국어는 문자 하나에 형태소 하나를 담아 가장 밀도가 높다. 일본어 kana와 한국어 Hangul은 소리를 표기하므로 밀도가 더 낮고 더 많은 문자가 필요하다. Devanagari와 Latin alphabet은 이보다 더 낮다. 문자당 의미 밀도는 중국어에서 영어로 갈수록 꾸준히 낮아진다.

두 번째 요소는 모델의 vocabulary가 해당 문자 체계를 처리할 때 문자당 몇 token을 쓰는지이며, 전적으로 모델별 특성이다. BPE tokenizer는 학습 corpus에서 여러 문자로 이뤄진 merge를 학습한다. 자주 본 문자 체계에는 압축된 token이 할당되고, 드물게 본 문자 체계는 문자 단위 또는 byte 단위 encoding에 가까워진다. 이 경우 문자 하나가 token 2개나 3개로 나뉠 수 있다. 다음은 세 언어의 net 문자당 token 수다.

이 표는 세 가지를 설명한다. 중국어 총합이 특이해 보이는 것은 첫 번째 요소가 극단적이기 때문이다. Claude의 중국어 압축률은 문자당 1.14 token으로 좋지 않아 일부 hanzi를 여전히 2개로 분리한다. 하지만 전체가 77자뿐이라 총 token 수는 크게 늘지 않는다. 중국에서 학습한 모델은 문자당 0.52에서 0.58로 더 잘 압축해 자체 영어와 거의 같은 수준에 도달한다. 힌디어의 추가 비용은 밀도가 아니라 두 번째 요소에서 나온다. GLM은 Devanagari 문자당 0.91 token을 쓴다. vocabulary에 여러 문자로 구성된 Devanagari merge가 거의 없어 문자당 token 하나에 가깝다. 반면 GPT-5.5는 전체 음절 cluster를 처리해 0.35 token만 쓴다. 같은 문자 체계에서도 coverage 차이가 크다. Claude는 영어에서도 문자당 비율이 0.32로 DeepSeek의 0.20보다 높다. 모델 자체의 baseline이 높고, 그 위에 언어별 특성이 더해지므로 모든 언어에서 값이 크다.

이 현상은 테스트한 모델 7종에만 국한되지 않는다. 관련 연구에서는 이를 token premium이라고 부른다. Petrov et al. (NeurIPS 2023)은 수백 개 언어 쌍에서 이를 측정해 같은 두 가지 원인을 확인했다. 같은 의미를 표현하는 문자 수가 언어마다 다르고, 문자 체계별 tokenizer coverage도 다르다. 저자원이 언어에서는 premium이 최대 15x였으며, 결과도 같았다. 비용과 latency가 늘고, 같은 context budget에 담을 수 있는 의미가 줄어 실사용 가능한 context window가 작아진다. vendor가 투자하면 격차는 줄어든다. 독립 측정 결과에 따르면 중국어는 GPT-3 시기 vocabulary에서 영어보다 token이 +182% 많았지만 GPT-4o에서는 +24%까지 줄었다. 이번 측정에서 GPT-5.5는 +32%였고, 중국에서 학습한 모델은 영어와 거의 같았다. coverage를 높이려면 vocabulary slot이 필요하며, vendor들은 여기에 계속 투자하고 있다.

현지화로 비용을 줄일 수 있는가?

앞의 함정 섹션만 보면 “Claude는 언어별 차이가 없으니 현지화를 무시해도 된다”거나 “중국 모델은 중국어가 저렴하니 현지화하면 비용이 줄어든다”고 해석하기 쉽다. 둘 다 틀렸다. 다음은 문단 3개가 모두 있는 5개 언어에 대해, 각 모델의 자체 영어 대비 평균을 나타낸 표다.

Claude가 언어별로 일정한 것은 아니다. 한국어는 자체 영어의 1.96x, 힌디어는 2.40x다. 중국어가 1.17x에 가까운 것은 해당 언어에서만 나타난 결과이지 모델 전체의 특성이 아니다. 중국 모델도 중국어에서 영어보다 크게 저렴한 것이 아니라 비슷한 수준에 도달했을 뿐이다. 전체 표에서 가장 낮은 값은 Kimi의 0.95x로 자체 영어보다 5% 낮다. 나머지는 모두 같거나 더 비싸다. 힌디어, 일본어, 한국어에서는 같은 중국 모델이 Claude보다 더 큰 추가 비용을 보였다. 해당 문자 체계가 학습 중심에서 더 멀기 때문이다. “vendor X가 저렴하다”는 패턴은 없다. 모든 모델은 자체 영어를 기준으로 학습 데이터와 가까운 언어에서 가장 효율적이다.

문체도 수치에 영향을 준다. 일상적인 서사문이 가장 유리했고, 기술문과 뉴스문에서는 거의 모든 배수가 커졌다. 비 Latin vocabulary가 merge를 충분히 보유하지 못한 영역이 바로 전문 용어와 외래어이기 때문이다. Claude에서 독일어는 일상문 1.68x에서 기술문 2.29x로 증가했고, GLM의 힌디어는 뉴스문에서 자체 영어의 5.98x에 도달했다. 문단 하나만 benchmark하면 번역이 가장 자연스럽고 짧은 언어가 실제보다 유리해진다. 서사문 하나만 보면 Kimi의 중국어는 0.80x였지만, 문단 3개를 합치면 0.95x였다.

애초에 자체 영어 대비 비율은 비용을 판단하기에 적합하지 않다. 실제로 지불하는 것은 절대 token 수다. Claude는 9개 언어 중 8개에서 가장 비쌌고, 유일한 예외는 더 나쁜 GLM의 힌디어였다. “Claude 영어 대비 저렴한” 중국어 콘텐츠도 서사문에서 Claude는 net token 88개, Kimi는 40개였다. 따라서 비용을 줄이려면 현지화가 아니라 언어에 맞는 모델을 선택해야 한다. 중국어는 Kimi 또는 DeepSeek, 힌디어와 한국어는 GPT-5.5, 일본어는 DeepSeek가 유리하다. 품질에서는 Claude가 이길 수 있지만, 어느 언어에서도 token 비용 기준 1위는 아니었다.

token 수는 청구액의 절반만 결정한다

token 배수는 token당 가격과 함께 봐야 하며, 두 값은 곱해진다. Claude Fable 5의 입력 token 100만 개당 정가는 $10, Opus 4.8은 $5, Sonnet 5는 출시 가격 종료 후 $3다. 세 모델이 공유하는 tokenizer는 중국어를 최저 모델의 2.2x로 계산한다. 따라서 token 수 차이는 routing 대안과의 모델 요금 차이에 다시 곱해진다. 반대도 가능하다. token을 적게 계산하는 모델도 요금이 높으면 호출당 비용이 더 클 수 있다. 어느 한 수치만으로는 청구액을 알 수 없다. 다른 vendor의 가격은 tokenizer보다 자주 바뀌므로 여기에는 싣지 않았다. 위 token 수가 계산에서 더 오래 유지되는 절반이다.

실제로 해야 할 일은 표시 가격 비교를 중단하고 유효 입력 비용을 계산하는 것이다. 실제 traffic 구성으로 각 후보 모델의 token 수를 측정한 뒤 해당 모델의 입력 요금을 곱한다. 중국어나 한국어 비중이 높은 제품에서는 가장 저렴한 모델의 순서가 바뀔 수 있다. 격차는 반올림 오차가 아니라 지속적인 1.5x에서 2x 수준이다. caching에서도 중요한 값은 표시 요금이 아니라 hit rate를 가중한 유효 비용이다. provider 비교에서 이 계산을 자세히 다룬다. 같은 영어를 Sonnet 5가 Sonnet 4.6보다 41% 더 많은 token으로 계산하는 등 버전별 차이는 Sonnet 5 tokenizer 글에 정리했다.

결론

• token 비용은 문자 체계의 밀도와 tokenizer coverage의 곱이다. 첫 번째 요소는 언어가, 두 번째 요소는 모델이 결정한다. 어느 한쪽만 보면 잘못된 결론을 내리게 된다.
• Claude Fable 5, Opus 4.8, Sonnet 5는 모든 언어에서 최저 모델보다 1.2x에서 2.3x 많았다. 영어에서도 문자당 비율이 높기 때문이다.
• 가장 효율적인 모델은 언어마다 다르다. 유럽 언어, 힌디어, 한국어는 GPT-5.5, 중국어는 Kimi, 일본어는 DeepSeek다. GLM은 힌디어에서 가장 약해 문자당 거의 1 token을 쓴다.
• 격식체와 기술 문체에서는 거의 모든 언어의 배수가 높아진다. 실제 서비스에서 사용하는 문체로 benchmark해야 한다.
• 비용 절감만을 위해 현지화하지 말아야 한다. 절대 token 수를 기준으로 언어에 맞는 모델을 선택한 뒤, 각 모델의 요금을 곱해 유효 비용을 비교해야 한다.

FAQ

어떤 LLM tokenizer가 가장 저렴한가? 언어에 따라 다르다. 의미를 맞춘 같은 문단을 모델 7종에서 측정한 결과, 유럽 언어와 힌디어, 한국어는 GPT-5.5가 가장 적었고 영어에서는 공동 최저였다. 중국어는 Kimi K2.5, 일본어는 DeepSeek-v4가 가장 적었다. Claude 계열인 Fable 5, Opus 4.8, Sonnet 5는 어느 경우에도 가장 적지 않았으며, 모든 언어와 문체에서 최저 token 수의 1.2x에서 2.3x였다.

Claude Fable 5, Opus 4.8, Sonnet 5는 같은 tokenizer를 사용하는가? 그렇다. 세 모델은 모든 언어, code, JSON 샘플에서 같은 token 수를 반환했다. Opus 4.7에서 도입된 tokenizer를 공유하므로 한 모델에서 측정한 수치를 다른 모델에도 적용할 수 있다. Fable 5의 청구액이 더 높은 이유는 전적으로 token당 가격 때문이다.

Claude에서 중국어가 영어보다 비싼가? 조금 더 비싸다. 문단 3개의 의미당 평균은 1.17x였고, 중국에서 학습한 모델에서는 거의 같았다. 문자당으로 보면 중국어 100자당 net token 약 114개, 영어는 32개로 훨씬 비싸 보인다. 하지만 중국어는 같은 의미를 약 3분의 1에 해당하는 문자 수로 전달하므로 총합은 거의 상쇄된다.

일본어와 한국어도 중국어와 비슷한가? 절반만 비슷하다. 문자당 token 밀도는 중국어처럼 높지만, Hangul과 kana는 소리를 표기하므로 같은 문단에 훨씬 많은 문자가 필요하다. 일본어는 136자, 한국어는 143자였고 중국어는 77자였다. 높은 문자당 비율이 상쇄되지 않으므로 의미당으로 보면 Claude에서 일본어는 영어의 약 1.6x, 한국어는 약 2x였다. 모델 7종 전체에서는 1.5x에서 2.4x였다.

내 prompt에서는 어떻게 측정해야 하는가? 실제 서비스에서 사용하는 문체의 prompt 몇 개를 후보 모델마다 전송하고, local tokenizer를 신뢰하는 대신 usage field에 담긴 provider 자체 입력 token 수를 읽어야 한다. 문단 하나만 측정하면 특정 언어가 약 20% 유리하게 보일 수 있으므로 여러 문단을 사용해야 한다. 그런 다음 각 token 수에 해당 모델의 입력 가격을 곱하면 실제 traffic의 유효 비용을 구할 수 있다.

← 블로그로 돌아가기