Счёт за модель считают по числу обращений и удивляются, когда он растёт быстрее. Причина в том, что платят не за обращения, а за объём переданного и полученного текста, и объём растёт сам по себе: увеличивается база знаний, копится история диалога, добавляются примеры в инструкцию.
Отсюда два практических вывода, которые определяют всё остальное.
Первый: стоимость считается не по цене за тысячу токенов, а по стоимости одной операции вашего процесса.
Второй, менее очевидный: сокращение контекста обычно улучшает качество ответов, а не только удешевляет их. Лишний текст размывает ответ.
Из чего складывается одно обращение
| Часть | Что это | Как растёт |
|---|---|---|
| Системная инструкция | правила, формат, примеры | фиксирована, но передаётся каждый раз |
| Найденные фрагменты | документы для RAG | зависит от числа и размера фрагментов |
| История диалога | предыдущие реплики | растёт с каждым сообщением |
| Сам запрос | вопрос пользователя | обычно мал |
| Ответ | что вернула модель | обычно дороже входа за токен |
Строка про инструкцию важнее, чем кажется. Инструкция на две страницы с десятком примеров передаётся при каждом обращении. При десяти тысячах обращений в месяц вы оплачиваете эти две страницы десять тысяч раз.
Строка про историю — источник неприятных сюрпризов. В диалоге на двадцать реплик двадцатое обращение несёт все предыдущие. Стоимость одного диалога растёт не линейно, а квадратично относительно числа реплик. Механика та же, что делает непредсказуемым счёт агентов — «Стоимость эксплуатации ИИ-агента».
Как считать стоимость операции
Стоимость операции = (токены входа × цена входа) + (токены выхода × цена выхода)
Практический порядок:
- Возьмите 20–30 реальных операций.
- Посчитайте фактическое число токенов входа и выхода по каждой.
- Возьмите среднее и, отдельно, максимум — по максимуму планируют пики.
- Умножьте на месячный объём.
Считайте на своих текстах. Русский текст даёт заметно больше токенов, чем английский той же длины, и это соотношение различается между моделями. Расчёт по чужим оценкам врёт.
Шесть способов сократить
По убыванию отдачи в моей практике.
1. Передавать меньше найденных фрагментов
Самый результативный. Типичная ошибка — передавать десять фрагментов вместо трёх-четырёх «чтобы наверняка». Это увеличивает и стоимость, и шум в ответе.
Лечится переоценкой найденного — «Реранкинг». Из двух десятков кандидатов отбираются лучшие три-пять.
2. Обрезать историю диалога
Передавать не всю переписку, а последние несколько реплик. Ещё лучше — структурированное состояние вместо истории: что выяснено, что решено, что осталось. Несколько строк вместо страниц.
3. Сократить системную инструкцию
Проверьте, что каждый пример в ней действительно нужен. Часто половина накопилась «на всякий случай» и не влияет на результат — проверяется удалением и прогоном контрольного набора.
4. Кешировать
Два уровня. Полный кеш ответов для повторяющихся запросов. И кеширование неизменной части запроса, если поставщик это поддерживает: инструкция передаётся один раз и переиспользуется, что при длинной инструкции даёт заметную экономию.
5. Использовать модель поменьше на простых шагах
Классификация и приведение к формату не требуют крупной модели — «Малые модели». Требует общего слоя доступа — «Шлюз моделей».
6. Ограничить длину ответа
Выход обычно дороже входа за токен. Если ответ должен быть коротким, это надо задать явно, а не надеяться.
Расчёт: до и после
Иллюстративный пример. Ассистент по документам, 20 000 обращений в месяц.
Было.
| Часть | Токенов |
|---|---|
| Системная инструкция с примерами | 1 800 |
| 10 найденных фрагментов | 6 000 |
| История, 6 реплик | 2 400 |
| Запрос | 60 |
| Итого вход | 10 260 |
| Ответ | 400 |
Стало.
| Часть | Токенов | Что сделали |
|---|---|---|
| Инструкция | 700 | убрали лишние примеры |
| 4 фрагмента | 2 400 | добавили переоценку |
| Состояние вместо истории | 300 | структурированная сводка |
| Запрос | 60 | — |
| Итого вход | 3 460 | сокращение в 3 раза |
| Ответ | 350 | ограничили длину |
Что изменилось помимо счёта. Качество ответов выросло: в контекст перестал попадать нерелевантный текст, размывавший ответ. Это типичный результат, а не приятная случайность.
Плюс побочный эффект на своём железе: сокращение контекста напрямую уменьшает память под одновременные запросы, то есть на той же карте помещается больше пользователей — «Расчёт видеопамяти».
Длинный контекст — не всегда лучше
Отдельное замечание, идущее вразрез с распространённым представлением.
Модели с очень большим окном контекста создают соблазн «передать всё и пусть разбирается». На практике:
- качество на длинных входах падает. Модели неравномерно внимательны к разным частям длинного контекста, и сведения из середины используются хуже;
- растёт время ответа;
- растёт стоимость;
- труднее диагностировать. Когда передано пятьдесят страниц, непонятно, на что модель опиралась.
Заявленная длина контекста и длина, на которой модель работает хорошо, — разные величины. Проверять надо на своих данных.
Правильный подход — не «передать больше», а «передать нужное»: точный поиск и переоценка вместо надежды на объём.
Частые вопросы
Почему счёт за модель растёт быстрее числа обращений?
Потому что платят за объём текста, а он растёт сам: увеличивается база знаний и в контекст попадает больше фрагментов, копится история диалога, разрастается системная инструкция. В диалогах стоимость растёт особенно быстро — каждое следующее обращение несёт все предыдущие реплики.
Как посчитать стоимость одной операции?
Взять 20–30 реальных операций, замерить фактическое число токенов входа и выхода, умножить на цены и взять среднее и максимум. Считать нужно на своих текстах: русский текст даёт больше токенов, чем английский, и соотношение различается между моделями.
Что сокращать в первую очередь?
Число передаваемых фрагментов при поиске по документам — обычно это самая крупная часть. Десять фрагментов вместо четырёх увеличивают и счёт, и шум в ответе. Дальше — историю диалога и системную инструкцию.
Правда ли, что чем больше контекста, тем лучше ответ?
Нет, обычно наоборот. Лишний текст размывает ответ, а на очень длинных входах модели хуже используют сведения из середины контекста. Сокращение передаваемого текста чаще улучшает качество, а не только удешевляет.
Помогает ли кеширование?
Заметно, на двух уровнях: полный кеш ответов для повторяющихся запросов и кеширование неизменной части запроса, если поставщик это поддерживает. Второе особенно полезно при длинной системной инструкции, которая иначе передаётся заново при каждом обращении.
Стоит ли брать модель с большим окном контекста?
Только если ваши документы действительно требуют этого. Большое окно создаёт соблазн передавать всё подряд, что ухудшает качество и удорожает работу. Практичнее точный поиск с отбором нужных фрагментов, чем передача всего целиком.
Что дальше
Как отбирать фрагменты точнее — «Реранкинг» и «Гибридный поиск». Где разместить маршрутизацию на дешёвые модели — «Шлюз моделей». Общая картина расходов — «Сколько стоит эксплуатация ИИ».
Оптимизация расходов на модели — часть работы по разработке и внедрению ИИ и сопровождению решений.