Деньги, скорость, окно контекста, качество — всё измеряется в одной единице. Понимание токена как ресурса меняет то, как ты архитектурируешь систему. Это самый дешёвый навык в курсе и один из самых полезных.
Токен — это не слово и не символ. Это фрагмент текста, на который модель разбивает свой вход и выход. Английский 1.3 токена на слово, русский ~2.5, китайский 1.5, код 1.8. Бюджет токенов = деньги + latency + предел памяти агента. Хорошо считать токены — значит хорошо проектировать: где экономить, где не стоит, где переплатить полезнее, чем сэкономить.
Модель не работает со словами или символами. Она работает с токенами — числовыми идентификаторами для частей текста. Каждая модель имеет свой «токенайзер» — алгоритм, который превращает текст в последовательность токенов перед отправкой в нейронную сеть.
Токен — это не слово, не буква, не слог. Это статистически удобный фрагмент. Часто употребляемые слова — это один токен («the», «and», «и», «на»). Редкие — несколько. Длинные технические термины — много. Эмодзи — отдельный токен. Пробелы тоже считаются.
Русский текст стоит в 2-3 раза дороже английского при той же передаваемой информации. Это не «несправедливость» — это особенность токенизаторов, обученных в основном на английских текстах.
Из этого следует практический вывод: если ты делаешь систему на русском (или на другом не-английском), у тебя экономика устроена иначе, чем «среднестатистическая в статьях». Цена в 2-3 раза выше за тот же объём контента. Это нужно сразу закладывать.
Грубые ориентиры, которые надо держать в голове:
Контекстные окна моделей измеряются в токенах. Когда говорят «128K context» — это токены. На английском это ~95K слов. На русском — ~50K слов. На HTML с разметкой — ~10–20 средних веб-страниц.
У каждого провайдера есть свой токенайзер. Считать «на глазок» — окей для оценок, но в проде нужны точные числа. Способы:
usage содержит точные числа (см. День 1). После каждого реального запроса ты знаешь, сколько токенов было.tiktoken, у Anthropic — свой токенайзер, у HuggingFace — обёртки на всё. Это позволяет посчитать до отправки, чтобы решить «помещается ли запрос в окно».Привычка AI-инженера: логировать usage в каждом запросе. Не «когда вылезет проблема», а с первого дня. Это твоя главная метрика стоимости и оптимизации.
Чтобы оптимизировать токены, надо знать, где они тратятся. В типичном агенте бюджет распределяется примерно так:
Инструкции агенту, описания инструментов. Стабилен, но множится на число итераций — за 30 итераций ты заплатишь за system 30 раз.
Обычно короткий. Часто включает обогащение (см. Кластер 05 — RAG). Может вырасти за счёт инжекции контекста.
Внутренний монолог модели на каждой итерации. На большой модели с CoT — основная статья расходов на output-токены.
Тексты страниц, ответы API, данные из файлов. Самая большая и самая неконтролируемая часть. Главный объект оптимизации.
(Доли условные — на реальной задаче распределение сильно зависит от типов инструментов и длины итераций.)
tool_results перед попаданием в контекст.
Биллинг считается раздельно: input (что ты отправил) и output (что модель сгенерировала). Output обычно в 2-4 раза дороже input.
В агенте input доминирует: ты каждую итерацию отправляешь весь массив. Output — только то новое, что модель сгенерировала на этом шаге. Поэтому стандартный совет «делай выход короче» работает слабо для агентов — у тебя проблема не там.
Зато prompt caching у современных провайдеров может сильно помочь: повторно отправляемые части (тот же system на 30 итерациях) кешируются и стоят в 10 раз дешевле обычного input. Включается одной настройкой, окупается мгновенно. Проверь, есть ли у твоего провайдера, и пользуйся.
Когда токены — твой ресурс, оптимизация идёт на нескольких уровнях. На каждом — разные решения:
Каждые лишние 100 токенов в system — это 100 × число итераций. За 30 итераций — 3000 «лишних» токенов на одну задачу.
Что делать:
web_search(query) — поиск в вебе».Это самая выгодная оптимизация. Между «инструмент вернул результат» и «результат пошёл в контекст модели» вставляется твой код, который этот результат уменьшает.
Способы:
Современные провайдеры (OpenAI, Anthropic, Google) поддерживают кеширование частей промпта, которые повторяются между запросами. System prompt длиной 5K токенов, отправляемый 30 раз — типичный кейс.
Как работает: ты помечаешь часть промпта как «кешируемую». Первый раз она обрабатывается полностью (полная цена). Следующие N часов — обрабатывается в 10 раз дешевле, потому что provider держит вычисления в кеше.
Это бесплатная победа в плане усилий — добавляется одной настройкой, экономия 30-50% на агентах без потери качества. Не пользоваться — терять деньги.
Не весь агент должен работать на большой модели. Двухтемповая архитектура (которую упоминали в Дне 5): маленькая модель для извлечения, классификации, сжатия — большая только для финального шага.
Пример: агент должен прочитать 5 веб-страниц и составить сводку. Чтение и извлечение фактов из каждой страницы — задача для gpt-4o-mini ($0.15/1M input). Финальный синтез — для gpt-4o ($2.50/1M). Получаешь качество большой модели на финале при цене ближе к маленькой по объёму работы.
«Сначала всё оптимизирую под токены, потом буду работать». На этапе обучения и прототипа это вредная привычка — сначала научись делать качественно, потом оптимизируй. Если урезать system на 200 токенов и потерять 10% качества — это плохая сделка.
Правильный порядок: сначала добиться работающей системы, потом измерить usage, потом резать там, где много расходов и мало вклада в качество.
«Уберу примеры, лишние слова, всю воду — будет короче». Иногда «вода» — это то, что модель использует, чтобы правильно понять задачу. Слишком сжатый промпт начинает давать худшие ответы — экономия на токенах оборачивается потерей качества.
Лечится тестированием: после каждого сжатия — прогон на нескольких типичных запросах и сравнение качества с предыдущей версией.
Противоположная грабля: «зачем это всё, пусть работает». В обучении окей. В проде с пользователями — катастрофа: счёт за месяц приходит в 10 раз выше ожидаемого, никто не понимает почему.
Минимальная гигиена: в каждом запросе логировать prompt_tokens, completion_tokens, total_tokens. Раз в день смотреть среднее и максимум. Этого достаточно, чтобы не получить сюрприз в конце месяца.
Открой Tokenizer от OpenAI (platform.openai.com/tokenizer) или Anthropic (anthropic.com/tokenizer). Введи одну и ту же мысль на английском и на русском (например, «The quick brown fox jumps over the lazy dog» и «Быстрая коричневая лиса перепрыгивает через ленивую собаку»). Сравни число токенов. Это даст тебе физическое ощущение разницы.
Возьми системный промпт, который ты обычно используешь (если нет — придумай для гипотетического ассистента). Скопируй в токенайзер. Посчитай. Удивись (обычно это в 1.5–2 раза больше, чем кажется на глаз). Затем умножь на гипотетические 20 итераций агента — увидишь реальную стоимость стабильной части контекста.
Возьми какую-нибудь AI-функцию, которая тебе нравится (или которую ты хочешь сделать): «AI-помощник для написания писем», «суммаризатор статей», «ассистент для подготовки к собеседованиям». Прикинь: средний запрос — X токенов input, Y output. Если 1000 пользователей в день делают 10 запросов — это $... в день. Получишь представление, на какой ценовой категории клиентов или модели подписки это работает. Это часть Product-Market Fit'а для AI-функций, многие проваливаются именно тут.