Skip to content
←

Split View: 토크나이저 내부 — 한국어가 토큰을 더 먹는 이유와 그 비용

✨ Learn with Quiz
|

토크나이저 내부 — 한국어가 토큰을 더 먹는 이유와 그 비용

들어가며

같은 내용을 영어로 쓰면 100 토큰인데 한국어로 쓰면 190 토큰입니다. API 요금도, 문맥 창을 채우는 속도도, 그만큼 차이가 납니다. 이 글은 그 차이가 어디서 오는지를 실제 토크나이저를 내려받아 측정한 숫자로 설명합니다.

이 글의 측정값은 논문 인용이 아니라 직접 실행한 결과입니다. 공개된 토크나이저 파일을 내려받아 같은 문장을 토큰화한 것이므로 누구나 재현할 수 있습니다.

수치는 2026-08-12에 논문·공식 리포트·config.json에서 직접 확인했습니다. 모델은 갱신되므로 원본을 다시 확인하세요.

바이트 수준 BPE

지금 나오는 모델은 거의 전부 바이트 수준 BPE를 씁니다. Qwen3 리포트는 Qwen의 토크나이저가 바이트 수준 바이트 페어 인코딩을 구현하며 어휘 크기는 151,669라고 적습니다(arXiv:2505.09388).

동작 방식은 두 단계로 이해하면 됩니다. 먼저 모든 텍스트를 UTF-8 바이트로 바꿉니다. 그다음 학습 말뭉치에서 자주 함께 나타나는 바이트 쌍을 반복해서 병합해 더 긴 조각을 만듭니다. 어떤 문자가 와도 최소한 바이트 단위로는 표현되므로 미등록 단어 문제가 사라집니다.

여기서 한국어의 불리함이 시작됩니다. ASCII 영문자는 1바이트지만, 한글 음절과 대부분의 CJK 문자는 UTF-8에서 3바이트를 차지합니다. 병합 규칙이 학습되지 않은 조각은 그대로 바이트로 쪼개지고, 한 글자가 토큰 세 개가 됩니다.

직접 측정하기

공개 저장소에서 토크나이저 파일을 내려받아 같은 뜻의 문장을 토큰화했습니다. 영어 392자, 한국어 199자로 같은 내용을 담은 문단입니다.

                영어 392자        한국어 199자
                (UTF-8 392B)      (UTF-8 489B)

Qwen3-8B          76 토큰           148 토큰      -> 1.95배
DeepSeek-V3       76 토큰           142 토큰      -> 1.87배
Mixtral-8x7B      81 토큰           218 토큰      -> 2.69배

글자당 토큰 (한국어)
Qwen3-8B      1.34 자/토큰
DeepSeek-V3   1.40 자/토큰
Mixtral-8x7B  0.91 자/토큰

Mixtral의 마지막 줄을 보세요. 글자당 토큰이 1을 밑돕니다. 한글 한 글자를 표현하는 데 토큰이 하나보다 많이 든다는 뜻이고, 이는 병합 규칙이 부족해 바이트 단위로 쪼개지고 있다는 신호입니다.

짧은 문장으로 언어별 비교도 해 봤습니다. 같은 뜻의 한 문장입니다.

언어    글자수  UTF-8   Qwen3   DeepSeek-V3   Mixtral
영어      73     73B     13         13          13
한국어    29     73B     22         19          32
일본어    28     84B     19         20          29
중국어    19     57B     12         10          20

중국어가 가장 효율적입니다. 한 글자가 담는 의미가 크고, 자주 쓰이는 한자가 단일 토큰으로 병합되어 있기 때문입니다. 한국어와 일본어는 셋 다 영어보다 토큰을 많이 쓰며, 둘 중 어느 쪽이 유리한지는 토크나이저마다 달라집니다. 한 문장만 측정한 값이므로 경향으로만 받아들이세요.

어휘 크기의 트레이드오프

세 토크나이저의 어휘 크기는 각각 151,669, 128,815, 32,000입니다. 차이가 결과로 그대로 나타납니다. 어휘가 32,000인 Mixtral은 한국어에서 218 토큰을, 어휘가 15만 수준인 Qwen3는 148 토큰을 씁니다.

그렇다면 어휘를 무한정 키우면 될까요. 그렇지 않습니다. 대가가 있습니다.

첫째, 임베딩 행렬이 커집니다. Qwen3-8B는 폭이 4096이므로 임베딩 하나가 약 6.2억 파라미터입니다. 어휘를 두 배로 늘리면 여기서만 6억 파라미터가 더 듭니다. 작은 모델일수록 이 비중이 커집니다.

둘째, 출력 소프트맥스가 커집니다. 매 토큰마다 전체 어휘에 대한 확률을 계산하므로 어휘 크기가 그대로 마지막 층의 연산량이 됩니다.

셋째, 희귀 토큰은 학습 신호를 적게 받습니다. 어휘를 늘려 만든 토큰이 말뭉치에 드물게 나타나면 그 임베딩은 충분히 학습되지 않습니다.

Llama 3의 사례가 이 균형을 잘 보여 줍니다. 리포트는 어휘 크기를 128,000으로 하고, 기존 토크나이저에 28K 토큰을 추가해 비영어를 더 잘 지원하도록 했으며, 영어 표본 기준 압축률이 토큰당 3.17자에서 3.94자로 개선되었다고 적습니다. 같은 문단은 선별한 비영어 언어에서 28K 토큰을 추가한 것이 압축률과 다운스트림 성능을 모두 개선했고 영어 토큰화에는 영향이 없었다고 밝힙니다(arXiv:2407.21783).

config의 vocab_size는 어휘 수가 아니다

첫 글에서 짚은 함정을 여기서 확인합니다. Qwen3-8B의 config는 vocab_size가 151936입니다. 그런데 리포트가 밝힌 어휘 크기는 151,669이고, 토크나이저 파일을 직접 열어 확인한 값도 151,669였습니다.

모델            config vocab_size    실제 토크나이저 어휘
Qwen3-8B            151,936              151,669
DeepSeek-V3         129,280              128,815
Mixtral-8x7B         32,000               32,000

차이는 임베딩 행렬을 하드웨어에 맞게 올림한 여유분입니다. Mixtral처럼 딱 맞는 경우도 있습니다. 파라미터를 셀 때는 config의 값을 쓰고, 토큰 수를 논할 때는 토크나이저의 값을 쓰면 됩니다.

실무에서 무엇을 의미하는가

토큰 효율은 세 군데에서 비용으로 바뀝니다.

첫째, 문맥 창입니다. 128K 문맥이라고 해도 한국어 문서를 넣으면 같은 창에 들어가는 원문 분량은 영어의 절반 수준입니다. 앞 글에서 본 것처럼 문맥이 길어지면 프리필 연산은 제곱으로, KV 캐시는 선형으로 늘어납니다. 토큰이 두 배면 캐시 메모리도 두 배입니다.

둘째, 생성 속도입니다. 토큰 단위로 생성하므로 같은 분량의 한국어 답변은 영어보다 더 많은 디코딩 스텝을 요구합니다.

셋째, 학습 데이터의 효율입니다. Llama 3 리포트가 압축률 개선을 두고 같은 학습 연산으로 더 많은 텍스트를 읽을 수 있게 해 준다고 표현한 것이 정확히 이 의미입니다.

모델을 고를 때 확인할 것

한국어를 많이 다룬다면 벤치마크 점수보다 먼저 확인할 것이 있습니다. 실제로 다룰 문서를 그 모델의 토크나이저로 토큰화해 보는 것입니다. 토크나이저 파일은 대개 공개되어 있으므로 모델 가중치를 내려받지 않고도 확인할 수 있습니다.

같은 문서가 어떤 모델에서는 1.9배, 어떤 모델에서는 2.7배가 됩니다. 이 차이는 벤치마크 표에는 나오지 않지만 운영 비용에는 그대로 반영됩니다.

마치며

토크나이저는 모델 구조에서 가장 덜 주목받지만 한국어 사용자에게는 가장 체감이 큰 부분입니다. 바이트 수준 BPE에서 3바이트 문자는 구조적으로 불리하고, 어휘 크기를 키우면 개선되지만 임베딩과 소프트맥스 비용이 함께 늘어납니다. 직접 측정해 보는 것이 가장 확실합니다. 재현하기도 어렵지 않습니다.

참고 자료

직접 해보기

  • VRAM 계산기 — 토큰 수가 늘었을 때 캐시 메모리가 어떻게 변하는지 확인해 보세요.
  • AI 벤치마크 정리 — 벤치마크가 다루지 않는 축이 무엇인지 생각해 보세요.
  • 뉴럴넷 실습실 — 입력 표현이 학습에 미치는 영향을 실험해 보세요.

시리즈

Inside the Tokenizer — Why Korean Costs More Tokens, and What That Costs

Introduction

The same content is 100 tokens in English and 190 tokens in Korean. API billing and the rate at which you fill the context window differ by exactly that much. This post explains where that difference comes from, using numbers measured by downloading the actual tokenizers.

The measurements here are not paper citations but results from runs performed directly. Public tokenizer files were downloaded and the same sentences tokenized, so anyone can reproduce them.

All figures were verified directly against papers, official reports, and config.json files on 2026-08-12. Models get updated, so check the originals again.

Byte-Level BPE

Nearly every model shipping today uses byte-level BPE. The Qwen3 report states that the Qwen tokenizer implements byte-level byte-pair encoding with a vocabulary size of 151,669 (arXiv:2505.09388).

The mechanism is easiest to understand in two steps. First, all text is converted to UTF-8 bytes. Then byte pairs that frequently co-occur in the training corpus are repeatedly merged to form longer pieces. Since any character is representable at least at the byte level, the out-of-vocabulary problem disappears.

This is where the disadvantage for Korean begins. ASCII letters are 1 byte, but Hangul syllables and most CJK characters occupy 3 bytes in UTF-8. Any piece for which no merge rule was learned gets split back into bytes, and one character becomes three tokens.

Measuring It Directly

Tokenizer files were downloaded from public repositories and used to tokenize text with the same meaning. The paragraphs carry identical content in 392 English characters and 199 Korean characters.

                English 392 ch     Korean 199 ch
                (UTF-8 392B)       (UTF-8 489B)

Qwen3-8B          76 tokens          148 tokens      -> 1.95x
DeepSeek-V3       76 tokens          142 tokens      -> 1.87x
Mixtral-8x7B      81 tokens          218 tokens      -> 2.69x

characters per token (Korean)
Qwen3-8B      1.34 ch/token
DeepSeek-V3   1.40 ch/token
Mixtral-8x7B  0.91 ch/token

Look at the last line for Mixtral. Characters per token falls below 1. That means representing a single Hangul character takes more than one token, a signal that merge rules are scarce and text is being split at the byte level.

A per-language comparison on a short sentence, one sentence with the same meaning throughout.

language   chars   UTF-8   Qwen3   DeepSeek-V3   Mixtral
English      73     73B      13         13          13
Korean       29     73B      22         19          32
Japanese     28     84B      19         20          29
Chinese      19     57B      12         10          20

Chinese is the most efficient. Each character carries more meaning, and frequently used characters are merged into single tokens. Korean and Japanese both spend more tokens than English here, and which of the two fares better flips depending on the tokenizer. This is a single-sentence measurement, so take it as a tendency only.

The Vocabulary-Size Tradeoff

The vocabulary sizes of the three tokenizers are 151,669, 128,815, and 32,000. The difference shows up directly in the results. Mixtral, with a vocabulary of 32,000, spends 218 tokens on the Korean paragraph, while Qwen3 at around 150,000 spends 148.

So should vocabulary just grow without limit? No. There is a cost.

First, the embedding matrix grows. Qwen3-8B has a width of 4096, so a single embedding is about 620 million parameters. Doubling the vocabulary adds 600 million parameters from this alone. The smaller the model, the larger that share becomes.

Second, the output softmax grows. Probabilities are computed over the entire vocabulary at every token, so vocabulary size becomes the compute of the final layer directly.

Third, rare tokens receive little training signal. If a token created by expanding the vocabulary appears rarely in the corpus, its embedding never trains adequately.

The Llama 3 case illustrates this balance well. The report sets the vocabulary size at 128,000, adds 28K tokens to an existing tokenizer to better support non-English languages, and states that the compression rate on a sample of English data improved from 3.17 to 3.94 characters per token. The same passage notes that adding 28K tokens from select non-English languages improved both compression ratios and downstream performance, with no impact on English tokenization (arXiv:2407.21783).

The config vocab_size Is Not the Vocabulary Count

Here we confirm the trap flagged in the first post. The Qwen3-8B config gives vocab_size as 151936. Yet the vocabulary size stated in the report is 151,669, and opening the tokenizer file directly also yields 151,669.

model            config vocab_size    actual tokenizer vocabulary
Qwen3-8B             151,936                  151,669
DeepSeek-V3          129,280                  128,815
Mixtral-8x7B          32,000                   32,000

The gap is padding that rounds the embedding matrix up to a hardware-friendly size. Sometimes, as with Mixtral, it lines up exactly. Use the config value when counting parameters, and the tokenizer value when discussing token counts.

What This Means in Practice

Token efficiency turns into cost in three places.

First, the context window. Even with a 128K context, feeding Korean documents fits roughly half the source material of English into the same window. As seen in the previous post, longer context raises prefill compute quadratically and the KV cache linearly. Twice the tokens means twice the cache memory.

Second, generation speed. Generation happens token by token, so a Korean answer of the same length requires more decoding steps than an English one.

Third, the efficiency of training data. When the Llama 3 report describes its compression improvement as enabling the model to read more text for the same amount of training compute, this is precisely what it means.

What to Check When Choosing a Model

If you work heavily in Korean, there is something to check before benchmark scores: tokenize the documents you will actually handle with that model's tokenizer. Tokenizer files are usually public, so you can check without downloading the model weights.

The same document becomes 1.9 times longer on one model and 2.7 times on another. That difference never appears in a benchmark table, but it lands directly in operating cost.

Closing

The tokenizer draws the least attention of any part of model architecture, yet for Korean speakers it is the most keenly felt. Under byte-level BPE, three-byte characters are structurally disadvantaged, and raising vocabulary size improves matters while raising embedding and softmax costs alongside. Measuring it yourself is the surest approach, and reproducing it is not hard.

References

Try It Yourself

Series