Как устроены LLM: токены, контекст, цена

Спросите у любой языковой модели, сколько букв R в слове strawberry. С хорошим шансом она ответит «две» — и будет неправа. Вращайте как угодно: просите посчитать по буквам, писать каждую букву отдельно. Модель будет ошибаться с честным лицом.

Первый вывод, который делают из этого эксперимента: «модель глупая». Вывод неверный, и разница между этими двумя позициями — примерно как между «компьютер завис» и пониманием, что случилось с оперативной памятью. Модель не видит букв. Совсем. То, что она видит, как это считать и сколько это стоит, — тема этого занятия. Без неё агент собирается наугад; с ней — экономится куча денег и нервов.

Токены: модель читает кусками

То, что приходит в модель, сначала нарезается на токены — куски текста фиксированного словаря. Не буквы и не слова: что-то среднее. Слово review может стать одним токеном, слово reviewer — двумя (review + er), а ревьюер — тремя-четырьмя кусками помельче.

Нарезкой занимается токенизатор — алгоритм, обученный вместе с моделью на частотностях. Идея простая: частые последовательности символов получают короткие коды. the, def, http — очень частые, им достались собственные токены. Редкие сочетания режутся на несколько частей.

Отсюда — разгадка strawberry. Модель получает не десять букв, а два-три токена, и внутри токена она не «видит» отдельные символы. Просить её посчитать буквы — всё равно что считать буквы в слове, напечатанном очень мелким шрифтом сквозь матовое стекло: слово-то видно, а буквы — нет. (Кстати, попросите модель написать слово по буквам, а потом посчитать написанное — шансы резко вырастут: буквы появятся в контексте как отдельные токены.)

Для разработчика из токенизации следуют три практических факта.

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

Второй: счёт идёт за токены, а не за запросы. Ни «за сообщение», ни «за задачу»: провайдер тарифицирует объём текста на входе и на выходе.

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

Контекстное окно: память на один запрос

У каждого запроса к модели есть контекстное окно — максимум токенов, которые модель может «держать в голове» за один раз. В это окно входит всё: системные инструкции, ваш промпт, дифф, который вы принесли, предыдущие реплики диалога и ответ, который модель сейчас сгенерирует. У современных моделей окна — от десятков тысяч до сотен тысяч токенов; точные цифры смотрите в доках конкретной модели, они меняются чаще, чем цены.

Ключевая деталь, которую часто упускают: окно живёт один запрос. Между двумя запросами память пуста. Модель не «помнит» вчерашнее ревью, предыдущий PR или ваш разговор час назад — если этот текст не передан в новом запросе, его не существует. Когда в маркетинговых текстах пишут «модель с памятью», под капотом всегда лежит код, который буквально подкладывает историю в следующий запрос. «Память» — это управление контекстом, и этому будет посвящён отдельный урок.

Что происходит при переполнении? Если промпт не влезает в окно, сервер API отвергнет запрос ошибкой. Но между вашим кодом и сервером часто стоит обёртка — SDK, фреймворк, «умный» клиент, — и некоторые обёртки молча подрезают историю, чтобы влезть. Симптом узнаете сразу: агент «забыл», зачем начал, и ходит по кругу. Поэтому правило разработчика агента: считать контекст до отправки, а не разбираться потом. И всегда оставляйте в окне место под ответ: вход и выход делят одно окно, и дифф, забивший его под завязку, не оставит модели места «подумать».

Цена: input, output и кэш

Тарификация у всех крупных провайдеров устроена одинаково: за миллион токенов, отдельно за вход и отдельно за выход. Возьмём для примера актуальную линейку OpenAI (цены — с официальной страницы developers.openai.com/api/docs/pricing, сентябрь 2026; у других вендоров цифры свои, но скелет такой же):

Три факта из этой таблички стоят всего занятия.

Выход дороже входа — в этой линейке ровно впятеро. Генерация вычислительно дороже чтения: каждый выходной токен модель производит последовательно, а входные обрабатываются параллельно. Практическое следствие: длинный промпт с коротким ответом («вот дифф, ответь списком замечаний») — дешёвый паттерн. Короткий промпт с простынёй на выходе («напиши документацию») — дорогой.

Кэш даёт десять процентов цены входа. Если ваши запросы начинаются с одинакового префикса — системные инструкции, правила ревью, — провайдер узнаёт знакомый кусок и тарифицирует его по кэшевой ставке. Для агента-ревьюера, который на каждом PR отправляет один и тот же инструкции, это не мелочь, а прямая скидка на постоянную часть счёта. (За кэш обычно ещё берут небольшую плату за запись — конкретику смотрите в доках провайдера.)

Между ярусами — два порядка. Самая дешёвая модель линейки в сто раз дешевле флагмана на входе. Ровно поэтому вопрос «какую модель взять» решается не верой, а арифметикой — этим займёмся в конце модуля.

Арифметика: сколько стоит месяц ревью-бота

Прикидка на коленке. Один pull request: инструкция ревьюера (~1 500 токенов) + правила (~500) + дифф (~4 000) = 6 000 токенов на вход; ответ с замечаниями — 1 000 токенов на выход. Поток: 20 PR в день, 22 рабочих дня — 440 ревью в месяц.

python

>>> def month_cost(price_in: float, price_out: float) -> float:
...     per_review = 6000 / 1_000_000 * price_in + 1000 / 1_000_000 * price_out
...     return round(440 * per_review, 2)
>>> month_cost(0.10, 0.50)    # gpt-6-luna
0.48
>>> month_cost(2.00, 10.00)   # gpt-6-sol
9.68
>>> month_cost(10.00, 50.00)  # gpt-6-astra
48.4

Полдоллара в месяц на самой дешёвой и почти пятьдесят на флагмане — за одну и ту же работу. А теперь главное: агент — это не один запрос, а петля, и каждый шаг петли несёт с собой весь накопленный контекст. Пять шагов — и вход уже не 6 000 токенов, а 15–20 тысяч. Счёт растёт не линейно по запросам, а кумулятивно по шагам, и без сметы «дешёвый бот» незаметно становится золотым.

Округление в round(..., 2) — не косметика: деньги считаются в float, и без округления на выходе будут 0.4840000000000001 в отчёте. Округляйте на выходе, а в промежуточных вычислениях храните как есть.

«У меня же большое окно»: главная ошибка

Соблазн прямой: окно — сотни тысяч токенов, значит можно скармливать агенту весь репозиторий, «пусть сам найдёт». Окно-то выдержит. Но, во-первых, вы платите за каждый токен на входе — на каждой итерации петли. Во-вторых, качество падает: чем больше нерелевантного в контексте, тем хуже модель отличает главное от фонового шума — как человеку, которому для одной правки раскладывают на стол весь архив отдела.

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

Что запомнить

• Модель читает токены, а не буквы; русскому тексту токенов нужно больше, чем английскому переводу.

• Контекстное окно — память одного запроса: между запросами пусто, вход и выход делят одно окно, переполнение ловится до отправки, а не после.

• Output дороже input (в примере — в 5 раз), кэш — 10% от цены входа, между дешёвым и флагманским ярусом — стократная разница.

• Агент платит за каждый шаг петли с накопленным контекстом — смета считается до запуска, а не после выставления счёта.

• «Влезет» — не аргумент. Аргумент — «принесено ровно то, что нужно».

Дополнительно

• Цены API OpenAI — официальная страница: input/output/cache по всем моделям, обновляется вживую.