Токен

Токен — минимальная единица текста, которую токенизатор переводит в числовой идентификатор, чтобы модель могла обработать запрос. В LLM токеном может быть слово, часть слова, знак препинания, пробел или служебный маркер. Поэтому токен не равен слову: считать бюджет контекста, стоимость API-запроса или длину ответа «по словам» нельзя. Эта метрика также плохо подходит для оценки смысла, читаемости и объема текста для человека, а сравнение токенов между разными моделями часто некорректно из-за разных словарей и правил разбиения.

Простыми словами

Если упростить, модель не читает текст так, как его читает человек. Перед обработкой строка разбивается на куски, каждому куску присваивается номер, и уже эти номера подаются на вход модели. Эти куски и есть токены.

Иногда токен совпадает со словом, но это не правило. Короткое частотное слово может быть одним токеном, а редкий термин, длинная фамилия, путь к файлу, URL, кусок JSON или фрагмент кода часто распадаются на несколько частей. Пробелы, переносы строк и знаки препинания тоже влияют на итоговое разбиение.

• Для разработчика токены — это единица бюджета контекста.
• Для инженера платформы токены — это единица учета стоимости и задержки.
• Для автора промптов токены — это ограничение на длину инструкции, примеров и ожидаемого ответа.

Главное практическое следствие: два текста одинаковой длины в символах могут сильно отличаться по числу токенов. Особенно это заметно на смешанных данных: естественный язык, таблицы, код, markdown-разметка и структурированный JSON ведут себя по-разному.

Как это работает

Основной конвейер

1. Текст поступает в токенизатор.
2. Токенизатор применяет свои правила разбиения: по частям слова, по статистике подстрок или по байтовым последовательностям.
3. Каждому токену сопоставляется целочисленный ID из словаря.
4. ID преобразуются во внутренние векторы, с которыми работает модель.
5. На выходе модель генерирует новые ID, после чего они декодируются обратно в текст.

На практике распространены алгоритмы BPE, WordPiece и SentencePiece. Их задача — найти компромисс между размером словаря и длиной последовательности. Если словарь слишком маленький, текст распадается на множество мелких частей. Если слишком большой, растет сложность хранения и обучения.

Почти у каждой модели есть и специальные токены: начало последовательности, конец ответа, разделители ролей, заполнитель и другие служебные маркеры. Они важны для чатов, пакетной обработки, структурированного вывода и вызова инструментов, хотя пользователь обычно их не видит.

Критически важно, что количество токенов зависит не только от текста, но и от конкретного токенизатора. Одна и та же строка в двух моделях может занимать разное число токенов. Поэтому оценка, сделанная для одной модели, не переносится автоматически на другую.

Что это означает на практике

Когда вы отправляете запрос в модель, лимит считается не в словах и не в символах, а именно в токенах. В этот лимит часто входят системные инструкции, сообщения пользователя, примеры, retrieved-контекст, промежуточные служебные поля и будущий ответ модели. Если не заложить запас, запрос упрется в предел контекстного окна или будет обрезан.

Зачем нужно

• Контекстное окно. У модели есть предел по числу входных и выходных токенов. Если лимит превышен, часть текста придется урезать, суммировать или вынести во внешнее хранилище.
• Стоимость вызова. Во многих API цена зависит от числа входных и выходных токенов, поэтому оценка по словам почти всегда ошибочна.
• Производительность. Чем длиннее последовательность, тем выше задержка и нагрузка на память. Токены — рабочая метрика для оптимизации промптов, чанков и RAG-конвейеров.
• Качество ответа. Если переполнить контекст шумом, полезный сигнал размоется. Управление токенами помогает оставить в запросе релевантные фрагменты.
• Наблюдаемость. Логи по токенам позволяют находить аномально длинные запросы, дорогие сценарии и неудачные шаблоны подсказок.

Для прикладных команд токены особенно важны в трех местах: при проектировании prompt templates, при нарезке документов для поиска и при контроле стоимости продакшен-систем. Во всех трех случаях грубые оценки «по страницам» или «по словам» быстро перестают работать.

Пример

Предположим, вы строите внутреннего помощника по базе знаний и работаете с моделью, у которой доступно 8 000 токенов контекста. Если резервировать под системные инструкции около 600 токенов, под вопрос пользователя — 300, а под ответ — 1 200, то на извлеченные документы остается примерно 5 900 токенов. Это не означает «5 900 слов»: в реальном русском тексте это может быть заметно меньше или больше в зависимости от токенизатора, разметки, кода и таблиц.

Практическое решение — не вставлять в запрос весь найденный материал, а нарезать документы на чанки и измерять их именно в токенах. Например, можно держать размер чанка в диапазоне, который удобно помещается вместе с вопросом и служебной обвязкой, а затем оставлять запас под ответ и возможные специальные токены. Если считать объем по символам или абзацам, легко получить переполнение контекста уже на этапе сборки запроса.

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

Заблуждения и ограничения

• «Один токен — одно слово». Неверно. Слово может состоять из нескольких токенов, а один токен может включать пробел или часть слова.
• «Токены одинаковы у всех моделей». Неверно. Словари и алгоритмы разбиения различаются, поэтому переносить оценки между моделями без проверки нельзя.
• «Если уменьшить число токенов, качество обязательно вырастет». Не всегда. Слишком агрессивное сжатие может убрать детали, термины и ограничения, без которых модель ошибется.
• «Токены измеряют смысл». Нет. Это техническая единица длины, а не семантическая метрика. Для оценки полноты, качества и фактической точности нужны другие методы.
• «Достаточно посчитать токены только пользовательского текста». Не всегда. В реальном API добавляются системные сообщения, разделители ролей, JSON-обвязка, tool calls и специальные токены.

Метод плохо подходит там, где нужен человеко-ориентированный объем: редакционная норма, юридическая длина документа, оценка удобочитаемости, размер текста в интерфейсе. В таких случаях лучше считать знаки, слова, абзацы или экранное пространство. Для многоязычных систем есть еще одно ограничение: языки с разной морфологией и письменностью дают разную плотность токенов, поэтому единый лимит на все языки ведет себя неравномерно.

Отдельный риск — считать токены слишком поздно. Если вы строите длинный pipeline, проверка только перед отправкой в модель уже недостаточна: желательно контролировать размер на каждом шаге, где добавляется контекст, форматирование или структурированный вывод.

Частые вопросы

Чем токен отличается от слова?

Слово — лингвистическая единица для человека, токен — техническая единица для модели. Они могут совпадать, но часто не совпадают.

Можно ли прикинуть число токенов без токенизатора?

Только грубо. Для планирования бюджета лучше использовать токенизатор именно той модели, с которой вы реально работаете, иначе оценка может заметно ошибаться.

Почему код, JSON и таблицы часто «дороже» в токенах?

В них много повторяющихся разделителей, коротких фрагментов, кавычек, отступов и идентификаторов, которые нередко разбиваются на мелкие части. По символам такие данные могут выглядеть компактно, а по токенам — нет.

Что такое специальные токены?

Это служебные маркеры вроде начала последовательности, конца ответа, разделителей сообщений или заполнителя. Они помогают модели понимать структуру входа и выхода.

Связанные понятия

• Токенизатор — компонент, который разбивает текст на токены и обратно собирает его из токенов.
• Контекстное окно — максимум токенов, который модель может учитывать в одном запросе.
• Embedding — векторное представление текста для поиска, сравнения и кластеризации.
• Chunking — нарезка документов на фрагменты подходящего размера, обычно с учетом лимитов в токенах.
• BPE / WordPiece / SentencePiece — распространенные подходы к токенизации.
• RAG — схема, в которой модель получает внешний контекст, и поэтому особенно чувствительна к токенному бюджету.