Fertility & Token Tax
Per-token 가격이 같다고 같은 내용을 전달하는 비용까지 같은 것은 아니다. 어떤 언어가 더 잘게 나뉘면 같은 의미를 쓰는 데 더 많은 IDs가 필요하고, 그만큼 context를 먼저 채운다. 이 분절 부담을 Fertility로 측정하고 비용 차이를 Token Tax로 살펴본다. 언어의 우열이 아니라, encoding과 Tokenizer 설계가 만드는 처리량 차이다.
- 언어별 분절 차이
- Fertility ↑
- 비용·latency ↑ / 유효 context ↓
- Tokenizer 설계·adaptation
Fertility
Fertility는 word당 평균 token 수이며 script 비교에서는 character당 token 수도 쓴다. 앞에서 본 English 6 / Korean 14의 같은 의미 문장은 약 2.3배 차이다. 같은 per-token rate라면 약 2.3배의 요금과 context를 쓰며, 더 많은 tokens를 생성해야 하는 부담도 생긴다.
Petrov et al.의 17 tokenizers 비교에서는 best-served 언어 대비 Shan 등에서 최대 15배의 token count가 보고됐다. 이는 논문이 측정한 비율이지 모든 문장에 적용하는 상수는 아니다. 일부 언어 쌍에서는 Character 또는 Byte-level로 바꾸어도 encoding length 차이가 4배 이상 남았다. Byte fallback이 모든 문자를 표현하게 해 주어도, 동일한 양의 의미를 동일한 길이로 압축해 주는 것은 아니다.
Token Tax
Byte/character로 가도 언어간 encoding length gap이 자동 사라지지 않는다. Ahia et al.의 22언어 API 평가에서는 일부 언어가 같은 content에 token을 더 지불하면서 benchmark utility는 낮았다. Per-token rate가 같아도 Tokenizer가 필요한 token 수를 정한다. 강의의 double disadvantage는 그 평가 맥락이다.
Language-Aware Tokenization
한국어의 UTF-8 음절 3 bytes와 교착어의 다양한 stem+ending 조합은 token 수를 늘릴 수 있다. 한국어 corpus 비율·Vocabulary allocation·Pre-tokenization 설계가 비용을 바꿀 수 있다. 언어 자체의 결함이라는 뜻이 아니다.
o200k launch의 예시별 token 감소: Korean45→27(1.7×), Hindi90→31(2.9×), Gujarati145→33(4.4×). 언어 전체 평균이 아니다.
Thunder-Tok의 BPE-Mecab은 언어적으로 올바른 분절이 가장 경제적이지 않을 수 있음을 보여준다. Korean-aware Pre-tokenization, linguistic seed와 branching-entropy selection 예시에서 plain BPE보다 약 10% fewer tokens를 보고했다.
교수님은 Tokenizer의 효율과 LM의 task 성능도 나누어 보라고 설명했다. 한국어 Vocabulary가 많아지면 분절을 줄이는 데 도움이 될 수 있지만, 같은 전체 training budget에서 한국어 데이터 비중을 늘리면 그만큼 다른 데이터 비중은 줄어든다. 표현 공간을 형성하는 데이터의 품질과 training strategy도 결과에 영향을 주므로, 한국어 비율을 높였다는 사실만으로 한국어 task가 더 좋아진다고 보장할 수 없다.
형태소 분석도 마찬가지다. 아버지/NNG 가/JKS 방/NNG처럼 언어적으로 잘 자르는 것과 모델의 token 소비를 줄이는 것은 다른 목표다. 너무 많은 올바른 조각으로 나누면 오히려 Fertility가 올라간다. Thunder-Tok의 요점은 형태소 규칙을 통째로 정답으로 삼는 것이 아니라 Korean-aware Pre-tokenization, linguistic seed, branching-entropy selection을 조절해 재사용성과 경제성을 함께 얻으려는 것이다.
Ahia et al.의 결과에서 더 많은 tokens를 지불하면서 utility도 낮은 언어가 있었다는 점은 이 차이가 단순한 속도 문제가 아님을 보여 준다. API 비용의 소득 대비 부담이 큰 지역에서는 같은 제품을 더 비싸고 낮은 효용으로 쓰는 격차가 생길 수 있다. 다만 이는 22언어 benchmark 평가 맥락이며, 모든 한국어 요청이 항상 영어보다 낮은 성능이라는 뜻은 아니다.
형태소 경계에 맞는 분절 ≠ token 효율 최적.
Check
Byte fallback이 있어도 한국어 Token Tax가 남는 이유는?
Answer
fallback은 coverage를 보장한다. 희귀 음절이 여러 bytes로 나뉘는 효율 문제와 언어별 Vocabulary 배분 문제는 남는다.
한국어 corpus 비율을 늘리면 한국어 task 성능이 항상 높아지는가?
Answer
교수님은 보장할 수 없다고 설명했다. 다른 언어의 transfer와 모델 capacity·데이터 구성까지 동시에 고려해야 한다.