Податок на токенізатор LLM: Як мова змінює вартість та контекст AI

Податок на токенізатор LLM є вимірювальним витратами та штрафом за контекст. Два запити можуть мати однакове значення, але споживати дуже різну кількість токенів, оскільки вони використовують різні мови.

Дослідження, проведене у липні 2026 року, протестувало 997 узгоджених речень на шести токенізаторах. З використанням старого кодування `cl100k_base` десять індійських мов мали середній податок на словникову родючість 8.0 разів відносно англійської. Малаялам досяг 13.04 разів. Новіший `o200k_base` зменшив середнє значення до 2.1 разів. Дослідження не доводить, що токенізація сама по собі викликає гірші відповіді. Воно показує, що ціна та використовуваний контекст можуть розходитися до того, як модель почне міркувати.

Аудиторія: Середній рівень

Пряма відповідь: Не оцінюйте багатомовний AI продукт за кількістю токенів англійською. Тестуйте точний токенізатор на узгодженому виробничому тексті, вимірюйте весь запит, оцінюйте якість окремо та повторюйте тест щоразу, коли змінюється модель або токенізатор.

Що вимірює податок на токенізатор LLM

Мовні моделі отримують ID токенів, а не слова чи символи. Токенізатор розділяє текст на одиниці токенів і відображає їх на ID; деякі токенізатори спочатку нормалізують текст. Загальні фрагменти можуть вміщатися в один токен. Менш представлені скрипти або форми слів можуть розбиватися на кілька токенів або байтів.

Головна метрика статті - це родючість слів: токени на слово, відокремлене пробілами. Податок токенізатора - це родючість слів однієї мови, поділена на родючість слів англійською під тим же токенізатором.

Для виробничого екрану співвідношення кількості токенів часто легше використовувати:

text співвідношення кількості токенів для мови L = токени для узгодженого контенту мовою L ÷ токени для англійської версії

Ці метрики відповідають на пов'язані питання, але вони не є взаємозамінними. Назвіть метрику, яку ви звітуєте. Обидва порівняння потребують семантично узгодженого тексту. Підрахунок нерелевантних речень або списку загальних слів може дати привабливе число, яке мало говорить про реальний застосунок.

Дослідники також використовують родючість, часто визначену як токени на слово. Родючість слів є інтуїтивно зрозумілою, але межі слів не є однаково чіткими в різних мовах. Додайте родючість символів, байти на токен та частку не злитих байтів, коли вам потрібно діагностувати, чому існує розрив.

Ця відмінність має значення, оскільки кількість токенів має кілька різних наслідків:

Останній рядок є найпростішим для перебільшення.

Що виявило дослідження 2026 року

Нове дослідження податку на токенізатор використовувало узгоджені речення з FLORES-200. Воно порівнювало десять індійських мов з англійською, арабською, іспанською та французькою на шести токенізаторах. Автори вимірювали родючість слів і символів, байти на токен, не злиті однобайтові токени та кількість вихідного тексту, який вижив у фіксованому бюджеті контексту.

Три результати важливі для інженерних рішень:

Мови з високим податком виробляли не злиті однобайтові токени для 27–43% своїх токенів. Серед вибраних мов з дійсними межами слів цей показник корелював з податком на родючість слів при `r = 0.89`. Автори приписують розрив недостатньому покриттю словникового запасу для цих скриптів.

Дослідження NeurIPS 2023 року виявило різниці в довжині токенізації до 15 разів між мовами. Дослідження EMNLP 2023 року вимірювало витрати та корисність на 22 мовах і виявило, що ціноутворення API на основі токенів може стягувати з деяких мовних спільнот більше за порівнянний контент.

Недавня робота також показує, що розрив є вибором дизайну, а не невідворотною властивістю скрипту. Кодування парних байтів з урахуванням паритету (BPE) змінює мету злиття, щоб допомогти найгірше стиснутій мові. Його автори повідомляють про зменшення нерівності витрат на токени до 89%, виміряної за допомогою крос-мовного коефіцієнта Джині, з незначними змінами в глобальному стисненні. Окреме контрольоване дослідження на 11 мовах Південно-Східної Азії розмістило BPE з урахуванням паритету на межі ефективності–справедливості для порівнянних базових моделей з 1.5 мільярда параметрів. Цей результат не встановлює той же компроміс на межі масштабу або після узгодження.

Заява про точність потребує стриманості

Липневе дослідження виявило сирий кореляційний зв'язок `r = -0.61` між родючістю та точністю розуміння прочитаного для 13 мовних точок. Після контролю за рівнем ресурсів мови часткова кореляція стала `r = 0.25`.

Є більше причин уникати причинного заголовка: числа родючості та оцінки точності походять з різних налаштувань токенізатора/моделі, вибірка була невеликою, а перекладені контрольні речення не є виробничим навантаженням. Стаття підтримує сильні заяви про кількість токенів, контекст і витрати на основі токенів. Вона не ізолює родючість токенізатора як причину нижчої якості відповідей.

Вимірюйте свої власні витрати на багатомовні токени

Дослідження дає попередження, а не ваше виробниче співвідношення. Асистент підтримки, система пошуку або агент кодування має свій власний мовний мікс і структуру запитів.

Використовуйте цей робочий процес перед запуском і після кожної зміни моделі.

1. Створіть узгоджену вибірку

Для початкового екрану зберіть 100–1,000 прикладів з навантаження, яке ви очікуєте:

Використовуйте перевірені переклади одного й того ж значення. Зберігайте ID, який пов'язує кожен мовний варіант. Не порівнюйте випадковий текст, витягнутий з окремих мовних корпусів. Цей діапазон скринінгу не є статистичним мінімумом: необхідна вибірка залежить від кількості мов, варіації навантаження та того, наскільки точно вам потрібно оцінити поведінку на краю.

Зберігайте вибірку у форматі JSON Lines:

{"id":"support-001","language":"en","text":"Reviewed English text"} {"id":"support-001","language":"sv","text":"Reviewed Swedish translation"} {"id":"support-001","language":"tr","text":"Reviewed Turkish translation"}

2. Закріпіть токенізатор

Токенізатор належить до версії моделі. Запишіть обидва. Офіційний `tiktoken` репозиторій відкриває `cl100k_base` та `o200k_base`; його відображення моделей також показує, що сімейства моделей можуть використовувати різні кодування. Для закритої моделі віддавайте перевагу офіційному лічильнику постачальника, коли він існує. API Gemini від Google, наприклад, відкриває `countTokens` метод. Для відкритої моделі завантажте точний артефакт з документованим конвеєром токенізатора моделі, наприклад, описаним у Hugging Face Tokenizers API.

Не припускайте, що дві моделі від одного постачальника ділять токенізатор. Не припускайте, що локальна бібліотека вже знає про модель, випущену вчора.

3. Розрахуйте розподіл, а не одне співвідношення

Встановіть та закріпіть лічильник:

bash python -m pip install "tiktoken==0.13.0"

Потім запустіть:

python import json from collections import defaultdict from math import ceil from statistics import mean, median

import tiktoken

BASELINE = "en" ENCODINGS = ("cl100k_base", "o200k_base")

groups = defaultdict(dict) with open("aligned-samples.jsonl", encoding="utf-8") as source: for line in source: row = json.loads(line) groups[row["id"]][row["language"]] = row["text"]

def percentile(values, probability): ordered = sorted(values) index = max(0, ceil(len(ordered) * probability) - 1) return ordered[index]

for encoding_name in ENCODINGS: encoding = tiktoken.get_encoding(encoding_name) counts = defaultdict(list) ratios = defaultdict(list)

for sample_id, variants in groups.items(): if BASELINE not in variants: raise ValueError(f"{sample_id} has no {BASELINE} baseline")

baseline_tokens = len(encoding.encode(variants[BASELINE])) if baseline_tokens == 0: raise ValueError(f"{sample_id} has an empty baseline")

for language, text in variants.items(): token_count = len(encoding.encode(text)) counts[language].append(token_count) ratios[language].append(token_count / baseline_tokens)

for language in sorted(counts): print( encoding_name, language, f"mean_tokens={mean(counts[language]):.1f}", f"mean_ratio={mean(ratios[language]):.2f}x", f"median_ratio={median(ratios[language]):.2f}x", f"p95_ratio={percentile(ratios[language], 0.95):.2f}x", f"max_ratio={max(ratios[language]):.2f}x", sep="\t", )

Середнє може приховувати кілька довгих запитів, які перевищують контекстне вікно. Перевірте p50 (медіана), p95 (95-й процентиль) та максимальне значення перед використанням результату в плануванні потужності.

*Вимірюйте узгоджений виробничий текст за допомогою розгорнутого токенізатора, а потім використовуйте розподіл для встановлення обмежень на витрати та контекст. Якість залишається окремою оцінкою.*

4. Вимірюйте повний запит

Видиме повідомлення користувача є лише частиною виклику API. Включайте:

Це особливо важливо для агентів. Велика схема JSON інструменту може домінувати над коротким запитом користувача. Локалізований фрагмент RAG може домінувати над англійським системним запитом. Вимірюйте остаточний серіалізований запит щоразу, коли постачальник відкриває це представлення.

5. Перетворіть токени на операційні обмеження

Для простого API з ціною на основі токенів:

text місячна вартість введення = місячні виклики × середня кількість токенів введення × ціна за мільйон токенів ÷ 1,000,000

Припустимо, що гіпотетичний API стягує $1 за мільйон токенів введення. Один мільйон запитів по 1,000 токенів введення коштує $1,000. Якщо узгоджені запити іншою мовою в середньому становлять 2,500 токенів, частина введення стає $2,500 до кешування або знижок.

Контекст потребує окремого розрахунку:

text використовуваний бюджет введення = вікно контексту

Застосовуйте спостережуване мовне співвідношення до частини контенту, а не сліпо до всього запиту.

Посібник з витрат на токени для AI reasoning пояснює, чому бюджет токенів потребує обмеження продукту, а не лише обмеження моделі. Для систем RAG та кодування дизайн контексту між репозиторіями показує, чому надсилання більшого контексту не є автоматично корисним. Якщо вибір API все ще відкритий, існуюче дослідження випадку безкоштовного AI API надає ширшу рамку для порівняння.

Встановіть багатомовні ворота прийняття

Нижче співвідношення токенів корисне лише тоді, коли модель все ще відповідає вимогам продукту. Використовуйте чотири окремі ворота:

Для багатомовної системи RAG розбивайте за допомогою розгорнутого токенізатора, а не спільного підрахунку символів. Для агента вимірюйте сліди інструментів і повтори, а також перший запит. Для продукту підтримки відстежуйте витрати на кожен вирішений випадок, а не витрати на кожен виклик. Ці вибори запобігають тому, щоб метрика токенів стала маркером марнославства.

Використовуйте мовний маршрут лише тоді, коли це покращує повну оцінку. Дешевший токенізатор у парі з більш слабкою моделлю може заощадити токени введення та збільшити повтори. Більше вікно контексту може приховати погане розбиття, поки рахунок не зросте. Правильна одиниця - це завершене завдання користувача.

Що можуть змінити команди

Команди застосування не можуть повторно навчити токенізатор комерційної моделі, але у них все ще є варіанти:

Команди, які навчають свої власні моделі, мають глибший вибір. Результати з урахуванням паритету BPE свідчать про те, що мета токенізатора може зменшити міжмовну нерівність без значних втрат у загальному стисненні. Дослідження Південно-Східної Азії додає контрольовані докази того, що справедливість та ефективність не повинні рухатися в протилежних напрямках.

Розглядайте токенізатор як частину контракту моделі. Версіюйте його, оцінюйте та включайте в огляди міграції.

Обмеження доказів

Найновіше дослідження є препринтом. Воно використовує перекладені речення FLORES-200, скромний набір мов та метрику слів на основі пробілів, яка не підходить для кожної системи письма однаково добре. Його метод виявлення байтів є специфічним для токенізатора.

Найсильніше висновок є незалежним від моделі: коли одна узгоджена мова виробляє більше токенів, вона отримує менше тексту в фіксоване вікно токенів. Висновок про витрати залишається в силі, коли постачальник стягує ці додаткові токени за тією ж одиничною ціною. Політики кешування та знижки на обсяги можуть змінити остаточний рахунок.

Точність потребує свого власного тесту. Покриття навчальних даних, архітектура моделі, післянавчання, дизайн оцінювання та культурний контекст всі впливають на результати. Родючість токенів може сприяти розриву, але липнева стаття не ізолює цей причинний ефект.

Контрольний список багатомовного токенізатора

Часто задавані питання

Чому деякі мови використовують більше токенів LLM?

Словникові запаси підсловів відображають їх навчальні дані та правила злиття. Загальні англійські фрагменти часто представлені ефективно, тоді як менш представлені скрипти можуть бути розділені на менші частини або байти. Розмір розриву залежить від точного токенізатора та тексту.

Чи означає вища кількість токенів гіршу відповідь?

Ні. Це безпосередньо впливає на витрати на основі токенів та кількість тексту, яка вміщується в контекстне вікно. Це не доводить нижчу якість відповіді. Тестуйте якість окремо на перевірених прикладах кожною мовою.

Як я можу підрахувати токени перед викликом API?

Використовуйте офіційний кінцевий пункт підрахунку постачальника, коли це можливо. Для кодувань OpenAI `tiktoken` може підрахувати локально. Для відкритих моделей завантажте точний артефакт токенізатора, що постачається з моделлю. Закріплюйте версії, щоб пізніше оновлення не змінило вимірювання без попередження.

Чи може зміна моделей усунути податок на токенізатор?

Це може зменшити розрив. Липневе дослідження виявило значне поліпшення між `cl100k_base` та `o200k_base`. Зміна моделі також змінює якість, витрати на вихід, кешування, затримку та операційну поведінку, тому порівнюйте повне навантаження, а не лише кількість токенів.

Джерела

Перевірки заяв

| Вищий податок на токенізатор викликає нижчу точність відповіді | Не встановлено | Коригований аналіз липневої статті не підтримував просте причинне читання