Входные, выходные и кэшированные токены: как LLM считает запросы

Именно поэтому короткий запрос не равен дешёвому запросу. В API вы платите не за ощущение простоты, а за количество токенов, которое модель обработала и сгенерировала.

Это ключевой момент для любого AI-продукта. Пока команда смотрит только на текст пользователя, она видит картину не целиком. А деньги чаще всего уходят не в сам вопрос, а в хвост контекста вокруг него: длинные инструкции, раздутую историю чата, лишние документы и слишком подробные ответы.

Проще говоря, у модели своя бухгалтерия. И если её не понимать, счёт за API начинает неприятно удивлять.

Из чего на самом деле состоит один запрос к LLM

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

Внутри одного обращения могут быть:

• системная инструкция, которая задаёт роль и правила поведения модели;
• сообщение пользователя;
• история предыдущих сообщений;
• документы или фрагменты базы знаний;
• результаты RAG-поиска;
• схемы инструментов и функций;
• дополнительные ограничения на формат ответа;
• сам ответ модели.

Если упростить, схема выглядит так:

Системная инструкция + история + документы + вопрос пользователя = входные токены
Ответ модели = выходные токены
Повторяющаяся часть входа = кэшированные токены
Дополнительная внутренняя работа reasoning-модели = reasoning tokens

Пользователь этого обычно не видит. Он видит чат и ответ. Но для разработчика, продакта или владельца сервиса важно видеть весь путь запроса целиком. Иначе начинает казаться, что модель «дорогая сама по себе», хотя на деле её просто каждый раз кормят лишним контекстом.

Что такое токен и почему токен не равен слову

Токен — это единица текста, с которой работает модель. Иногда токен совпадает со словом, но далеко не всегда. Это может быть часть слова, знак препинания, пробел, кусок URL, фрагмент кода или отдельная языковая конструкция.

Поэтому токены нельзя надёжно считать по словам. Два текста одинаковой длины в символах могут давать разное количество токенов. Русский и английский языки, код, HTML, цифры и специальные символы токенизируются по-разному.

Для практики важно помнить главное: модель работает не с абстрактным «объёмом текста», а именно с токенами. Чем больше текста вы даёте ей прочитать и сгенерировать, тем выше нагрузка на контекст и тем выше стоимость запроса.

Поэтому точное количество токенов лучше смотреть через usage в API, встроенную аналитику провайдера или tokenizer, а не оценивать на глаз. Прикидка «ну тут примерно абзац» в расчётах работает плохо.

Типы токенов в API: что именно считается

Ниже — простая опорная схема, которая помогает быстро увидеть разницу между основными категориями.

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

Input tokens: за что вы платите ещё до ответа модели

Input tokens — это все токены, которые модель получает на вход до начала генерации ответа. И здесь многие совершают главную ошибку: думают, что input — это только текст пользователя.

На деле во вход могут входить:

• системный промпт;
• developer-инструкции;
• сообщение пользователя;
• история диалога;
• фрагменты базы знаний;
• результаты поиска по документам;
• содержимое загруженных файлов;
• описания инструментов и функций.

Ключевая мысль простая: входные токены — это весь текст и весь служебный контекст, который модель должна прочитать, прежде чем начать отвечать.

Пример: чат-бот поддержки

Пользователь пишет: «Где мой заказ?»
Сам вопрос короткий. Но в реальном запросе к модели могут быть:
— системная инструкция ассистента;
— правила тона общения;
— история переписки с клиентом;
— данные по заказу;
— политика возврата;
— шаблоны ответов службы поддержки.

В результате пользователь отправил четыре слова, а модель прочитала несколько тысяч токенов. Именно так и появляется разрыв между ожиданием «вопрос же короткий» и фактической стоимостью запроса.

Output tokens: почему подробный ответ быстро раздувает стоимость

Output tokens — это токены, которые модель создаёт в ответ. И да, за них тоже платят.

Если попросить модель дать короткий вывод в два предложения, выходных токенов будет немного. Если попросить написать подробный разбор, таблицу, письмо клиенту, 20 вариантов заголовков, длинную инструкцию или целую статью, объём output вырастет.

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

Пример: генератор контента

Есть два сценария.

В первом пользователь просит: «Сделай краткий анонс статьи».
Во втором: «Напиши полную SEO-статью с введением, структурой, раскрытием каждого блока, таблицей, FAQ и выводом».

С точки зрения интерфейса это может быть один и тот же сервис. Но с точки зрения output — это два очень разных по стоимости сценария.

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

Cached tokens: когда повторяющийся контекст можно не считать каждый раз по полной

Cached tokens — это токены из повторяющейся части входа, которые могут переиспользоваться при следующих запросах. Именно здесь начинается первая по-настоящему прикладная оптимизация.

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

Где это особенно полезно

Кэширование даёт эффект там, где есть стабильные и тяжёлые по объёму блоки:

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

Пример: AI-ассистент компании

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

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

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

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

Reasoning tokens: дополнительная внутренняя работа модели

Кроме входных, выходных и кэшированных токенов, в некоторых сценариях есть ещё один слой — reasoning tokens. Это токены, которые reasoning-модели могут использовать для внутренней работы над задачей до финального ответа.

Для базового понимания темы достаточно запомнить одно: не все потраченные токены обязательно превращаются в видимый текст ответа.

Если задача простая — переписать абзац, классифицировать сообщение, выдать краткий ответ, — сложная reasoning-модель может быть избыточной. А если модель решает многошаговую задачу, анализирует документ, сопоставляет условия или строит план, её внутренняя работа может быть больше.

Этот блок не должен перегружать новичка. В повседневной практике сначала важно понять три базовые категории: input, output и cached. Reasoning tokens — это уже следующий уровень, который становится важнее при выборе моделей для сложных сценариев.

Почему одинаковые промпты могут стоить по-разному

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

Причины обычно такие:

— разная длина истории диалога;
— разные системные инструкции;
— подключены или не подключены документы и RAG-контекст;
— разный объём ответа;
— в одном случае сработал кэш, а в другом нет;
— используется другая модель или другой режим работы.

Итог простой: пользователь может видеть один и тот же промпт, а система — два совершенно разных по стоимости обращения.

Частые ошибки при подсчёте токенов

1. Первая ошибка — считать только сообщение пользователя. Это самая популярная иллюзия. На практике пользовательский текст часто занимает меньшую часть всего input.
2. Вторая ошибка — не учитывать историю диалога. Чат кажется удобным, пока история не начинает раздувать каждый новый запрос.
3. Третья ошибка — каждый раз передавать модели слишком много контекста. Например, весь документ целиком, всю базу знаний или весь накопленный диалог, хотя для ответа нужен только небольшой фрагмент.
4. Четвёртая ошибка — не ограничивать длину ответа. Длинный output — это не просто «подробно и красиво», а прямой рост себестоимости.
5. Пятая ошибка — не разделять в аналитике input, output и cached tokens. Пока эти категории смешаны, непонятно, где именно утекают деньги.
6. Шестая ошибка — не смотреть фактический usage. Пока команда живёт на предположениях, она управляет расходами вслепую.
7. Седьмая ошибка — считать, что кэш у всех провайдеров работает одинаково. На практике это не так.

Какие метрики токенов стоит считать в продукте

Если AI-функция используется регулярно, токены нужно считать не как теорию, а как рабочую продуктовую метрику.

Пример: ассистент по документам

Если внутренний AI-ассистент анализирует договоры, полезно отдельно считать:

— сколько токенов уходит на загрузку и чтение документа;
— сколько — на историю переписки;
— сколько — на финальный ответ;
— какие типы документов дают самый дорогой сценарий.

Тогда становится видно, где искать оптимизацию: резать документ на фрагменты, менять способ поиска контекста, сокращать ответ или использовать другую модель.

Вот в этот момент тема токенов перестаёт быть учебной и становится управленческой.

Где обычно теряются деньги

Если говорить совсем по делу, перерасход чаще всего возникает не из-за самой модели, а из-за архитектурных привычек:

• слишком длинная системная инструкция;
• история диалога без нормальной обрезки;
• отправка лишних документов;
• отсутствие контроля за длиной ответа;
• использование сложной модели там, где хватило бы более простой;
• отсутствие аналитики по usage.

То есть проблема часто не в том, что «API дорогое», а в том, что продукт разговаривает с моделью слишком щедро и слишком бесконтрольно.