Как рассчитать стоимость одного запроса к ИИ: формула и примеры

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

Из чего складывается цена запроса

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

Чтобы собрать полную картину расхода, разделите стоимость на три уровня.

• Прямая оплата токенов в конкретном обращении к модели. Это базовый уровень, с которым работает любой калькулятор.
• Сопутствующие вызовы, без которых запрос не выполняется. Сюда попадают векторизация документов для поиска по базе знаний, отдельные обращения к модели-классификатору, проверка ответа на соответствие правилам.
• Инфраструктура вокруг модели. Хранилище векторов, серверы приложения, логирование, трафик, работа людей, которые разбирают неудачные ответы.

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

Почему интуитивный расчёт по количеству обращений не работает

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

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

Токены как единица расчёта

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

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

• Английский текст даёт примерно четыре символа на токен, то есть одно слово обходится в среднем в один с небольшим токен.
• Русский текст в большинстве современных токенизаторов даёт два или три символа на токон, поэтому слово часто занимает два, три, а иногда и четыре токена.
• Одна страница делового текста на русском языке, около 1800 знаков, превращается примерно в 600 до 900 токенов.
• Цифры, даты, артикулы и адреса страниц дробятся особенно мелко, и таблица с номенклатурой может оказаться дороже текста того же объёма.
• Разметка платная наравне с содержанием. Фигурные скобки, кавычки структурированных данных, отступы, повторяющиеся названия полей занимают токены в каждом обращении.

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

Сколько токенов в русском и английском тексте на одном примере

Возьмём фразу о правилах возврата товара длиной около 400 знаков. На русском языке она займёт примерно 130 до 160 токенов. Её смысловой перевод на английский уложится в 80 до 100 токенов. Разница в полтора раза сохраняется на любом объёме, и для продукта с русскоязычной базой знаний это означает устойчивую надбавку к стоимости контекста. Это не повод переводить базу знаний, но это повод учитывать коэффициент в расчётах и не переносить зарубежные оценки стоимости обращения напрямую в свою модель бюджета.

Чем посчитать токены до отправки запроса

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

1. Библиотека токенизатора для вашей модели, вызванная локально. Даёт точное число до отправки запроса и позволяет отсекать слишком длинный контекст заранее.
2. Поле с расходом токенов в ответе интерфейса прикладного программирования. Поставщики возвращают фактические числа по входу и выходу, и это единственный источник, с которым нужно сверять свои оценки.
3. Грубый пересчёт по символам для прикидок на салфетке. Разделите количество знаков русского текста на два с половиной и получите оценку, достаточную для первого разговора о бюджете.

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

Цены моделей за входные и выходные токены

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

Что обязательно уточнить в прайс-листе до начала расчётов.

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

Что меняет российский контекст расчёта

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

• Курсовая разница. Ставки зарубежных поставщиков в иностранной валюте, и месячный бюджет в рублях меняется вместе с курсом, даже если нагрузка постоянна.
• Комиссия за оплату через посредников. Это прибавка к каждому рублю, и в расчёте на один запрос она даёт устойчивый множитель.
• Отечественные модели, тарифицируемые сразу в рублях. GigaChat и модели Яндекса считают расход в токенах или в собственных единицах, а счёт приходит в рублях без курсового риска.
• Требования к хранению данных. Если персональные данные нельзя передавать за пределы страны, выбор сужается до российских поставщиков или собственного размещения, и сравнение по цене токена становится вторичным.
• Налог на добавленную стоимость в счетах российских поставщиков. В зарубежных прайс-листах его нет, и прямое сравнение ставок получается нечестным.

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

Формула расчёта стоимости одного запроса

Базовая формула умещается в одну строку. Стоимость запроса равна количеству входных токенов, делённому на миллион и умноженному на входную ставку, плюс количество выходных токенов, делённое на миллион и умноженное на выходную ставку.

В промышленной эксплуатации этого недостаточно, потому что часть входа читается из кэша, а часть выхода уходит на внутренние рассуждения. Расширенный вариант учитывает пять слагаемых.

1. Новые входные токены по полной входной ставке.
2. Входные токены, прочитанные из кэша, по сниженной ставке чтения.
3. Токены, записанные в кэш, по ставке записи, если поставщик берёт за это отдельно.
4. Видимые выходные токены по выходной ставке.
5. Токены размышления по выходной ставке, если модель их тарифицирует.

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

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

Какие переменные нужно зафиксировать перед расчётом

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

Примеры расчёта на конкретных числах

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

Короткий вопрос в чате без дополнительного контекста

Пользователь спрашивает о сроках доставки. Системная подсказка занимает 120 токенов, вопрос 40 токенов, ответ 300 токенов.

• Вход составляет 160 токенов, что даёт 0,00048 единицы валюты.
• Выход составляет 300 токенов, что даёт 0,0045 единицы валюты.
• Итого 0,00498, или примерно 42 копейки.

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

Запрос с документом в контексте

Пользователь задаёт вопрос по договору на пятнадцать страниц. Документ целиком уходит в контекст и занимает около 11 500 токенов, системная подсказка и вопрос добавляют 500, ответ занимает 700 токенов.

• Вход составляет 12 000 токенов, что даёт 0,036 единицы валюты.
• Выход составляет 700 токенов, что даёт 0,0105 единицы валюты.
• Итого 0,0465, или примерно 3 рубля 95 копеек.

Картина переворачивается. Теперь более семидесяти процентов счёта это вход, и работать нужно с контекстом, а не с ответами. Разница между двумя примерами почти десятикратная, при том что для пользователя оба действия выглядят одинаково, как один заданный вопрос. Именно поэтому средняя стоимость обращения по продукту без разбивки на сценарии бесполезна для управления расходами.

Если в этом сценарии вместо полного договора передавать три релевантных фрагмента по 600 токенов, вход сокращается до 2300 токенов, а счёт падает до примерно 1 рубля 50 копеек. Качество ответа при корректно настроенном поиске по документам при этом не ухудшается, а иногда растёт, потому что модель не отвлекается на посторонние разделы.

Длинный диалог с историей

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

Возьмём помощника в поддержке. Системная подсказка 120 токенов, каждое сообщение пользователя около 50 токенов, каждый ответ около 250. Диалог на десять оборотов даёт следующую картину.

• Первый оборот отправляет на вход 170 токенов, десятый уже 2870, потому что тащит за собой всю предысторию.
• Суммарный вход по всему диалогу составляет около 15 200 токенов, суммарный выход 2500 токенов.
• По нашим ставкам это 0,0831 единицы валюты, то есть примерно 7 рублей 6 копеек за один завершённый разговор.
• Если бы каждый оборот обрабатывался без истории, тот же диалог стоил бы 3 рубля 62 копейки.

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

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

Отсюда понятная инженерная развилка. Скользящее окно из последних трёх обменов сокращает вход того же десятиоборотного диалога до 8900 токенов и опускает счёт примерно до 5 рублей 46 копеек. Сжатие ранней части разговора в короткую сводку на 200 токенов работает ещё сильнее, но требует отдельного вызова модели, стоимость которого нужно включить в расчёт.

Генерация изображения и обработка звука

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

• Снимок экрана размером около 1024 на 1024 точки превращается примерно в 1100 входных токенов, что по нашей ставке даёт около 28 копеек. Разбор десяти страниц сканированного документа стоит дороже, чем разбор тех же десяти страниц в виде текста, примерно в полтора раза.
• Генерация одного изображения у разных поставщиков стоит от нескольких рублей до нескольких десятков рублей, и зависимость от разрешения нелинейная. Переход с квадратного формата на большой горизонтальный может удвоить цену.
• Распознавание речи тарифицируется за минуту звучания. Час записи совещания обходится в десятки рублей, но дальше этот час превращается в семь или девять тысяч токенов текста, которые вы оплачиваете ещё раз при каждом обращении к расшифровке.
• Синтез речи считается по символам исходного текста, и здесь русский язык работает в вашу пользу, потому что символов в нём меньше, чем в подробном английском переводе.

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

Что увеличивает счёт незаметно

Расхождение между расчётом на салфетке и фактическим счётом почти всегда объясняется четырьмя причинами. Все они невидимы в интерфейсе продукта и заметны только в полях расхода токенов.

Системная подсказка в каждом обращении

Системная подсказка отправляется заново при каждом вызове. Пока она занимает сто токенов, это не важно. Но в зрелых продуктах она разрастается до двух или трёх тысяч токенов, потому что туда складывают правила тона, запреты, примеры хороших ответов, описания доступных инструментов и формат вывода.

Посчитаем. Подсказка на 2500 токенов при миллионе обращений в месяц даёт 2,5 миллиарда входных токенов, или 7500 единиц валюты, то есть около 637 тысяч рублей только за повторное чтение одного и того же текста. При этом пользователь не получает от этого ни одного дополнительного слова в ответе.

Что обычно удаётся вычистить без потери качества.

• Примеры ответов, которые дублируют друг друга. Три показательных примера работают почти так же, как десять, а занимают втрое меньше.
• Описания инструментов, которые в этом сценарии недоступны. Библиотеки часто подставляют полный список автоматически.
• Подробные объяснения формата вывода там, где можно задать структуру через параметры запроса.
• Вежливые преамбулы и повторные формулировки одного и того же требования разными словами.

Накопленный контекст диалога

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

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

Токены размышления у моделей с рассуждением

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

Это меняет всю арифметику. Ответ на 300 видимых токенов при тысяче токенов размышления стоит не 0,0045, а 0,0195 единицы валюты. Четырёхкратный рост при одинаковом результате на экране.

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

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

Повторные обращения из-за неудачного ответа

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

Доля повторов в продуктах, которые я видел, держится в диапазоне от двенадцати до тридцати пяти процентов. Добавьте к этому автоматические повторы на стороне приложения.

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

В расчёте это учитывается множителем. Умножайте стоимость типового обращения на коэффициент от 1,15 до 1,35 в зависимости от зрелости продукта. Без этого множителя план расходов систематически оптимистичен.

Кэширование и пакетная обработка меняют расчёт

Два механизма, которые влияют на счёт сильнее, чем выбор модели. Кэширование подсказок позволяет не платить полную ставку за неизменную часть контекста. Пакетная обработка даёт скидку за отказ от немедленного ответа.

Вернёмся к примеру с договором на пятнадцать страниц. Входные 12 000 токенов, из которых 11 500 это сам документ, не меняющийся между вопросами. Сравним три режима при чтении из кэша по ставке в десять раз ниже входной.

Режим	Входные токены по полной ставке	Стоимость обращения	В рублях
Без кэша	12 000	0,0465	3,95
Первое обращение с записью в кэш	12 000 с надбавкой за запись	0,0549	4,67
Последующие обращения с чтением из кэша	500	0,0155	1,31

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

Чтобы кэш работал, нужно соблюсти несколько условий.

1. Неизменная часть контекста стоит в начале запроса. Кэш работает по совпадению префикса, и один изменённый символ в первой строке обнуляет попадание.
2. Динамические элементы вынесены в конец. Текущая дата, имя пользователя, идентификатор сессии в начале подсказки убивают кэширование полностью.
3. Длина кэшируемого блока превышает минимальный порог поставщика. Обычно это от тысячи токенов, короткие подсказки не кэшируются.
4. Обращения идут достаточно часто, чтобы кэш не истёк. Время жизни обычно измеряется минутами, и при редкой нагрузке попаданий почти не будет.

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

Как сочетать оба механизма

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

Расчёт месячного бюджета по среднему обращению

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

Порядок действий выглядит так.

1. Выделите три или четыре типовых сценария с разной структурой контекста. Короткий вопрос, вопрос по документу, длинный диалог, фоновая обработка.
2. Для каждого посчитайте стоимость одного обращения по расширенной формуле с учётом кэша и скрытых токенов.
3. Оцените долю каждого сценария в общем потоке. Данные берите из журналов приложения, а не из предположений.
4. Умножьте стоимость сценария на его объём и сложите суммы.
5. Примените множитель повторов от 1,15 до 1,35.
6. Переведите в рубли по курсу с запасом и добавьте комиссии и налог.
7. Заложите резерв на рост нагрузки и на изменение поведения пользователей, обычно от двадцати до тридцати процентов.

Разберём на примере продукта с сотней тысяч обращений в месяц. Шестьдесят процентов это короткие вопросы по 42 копейки, двадцать пять процентов вопросы по документам с кэшированием по 1 рублю 31 копейке, десять процентов длинные диалоги по 7 рублям, пять процентов фоновая обработка в пакетном режиме по 90 копеек.

• Короткие вопросы дают 25 200 рублей.
• Вопросы по документам дают 32 750 рублей.
• Длинные диалоги дают 70 000 рублей.
• Фоновая обработка даёт 4500 рублей.
• Сумма составляет 132 450 рублей, с множителем повторов 1,25 это 165 562 рубля, с резервом в четверть около 207 тысяч рублей.

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

Где посмотреть фактический расход и сверить с расчётом

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

• Поле расхода токенов в теле ответа. Приходит с каждым вызовом и содержит разбивку по входу, выходу, чтению из кэша и записи в кэш. Это единственный источник, по которому можно посчитать стоимость конкретного обращения конкретного пользователя.
• Раздел с расходами в личном кабинете поставщика. Показывает итог по дням и по моделям, служит контрольной суммой. Данные там часто обновляются с задержкой в несколько часов, поэтому для оперативного управления он не годится.
• Журналы вашего собственного приложения, если вы заранее начали писать туда расход по каждому вызову. Без этого шага любая оптимизация делается наугад.

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

Как построить сверку, которая показывает расхождения

Соберите простую таблицу, где по каждому сценарию стоят рядом ваша расчётная стоимость обращения и фактическая средняя за период. Расхождение до десяти процентов нормально. Больше означает, что в расчёте не учтён какой-то слой.

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

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

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

Частые ошибки в расчётах

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

• Перепутаны единицы тарификации. Ставка за тысячу токенов принята за ставку за миллион. Расчёт расходится с фактом ровно в тысячу раз, и обычно это обнаруживается в первый же платёжный период.
• Входная и выходная ставки применены одна вместо другой. Поскольку выход дороже в три до пяти раз, ошибка в продуктах с длинными ответами даёт недооценку в разы.
• Токены русского текста посчитаны по английскому коэффициенту четыре символа на токен. Недооценка примерно в полтора раза по всему входу.
• Забыт системный блок, который отправляется при каждом вызове. В коротких сценариях он составляет основную часть входа.
• Не учтён рост контекста в диалоге. Расчёт сделан по первому обороту и умножен на количество сообщений.
• Пропущены токены размышления. Для моделей с рассуждением это недооценка выхода в два до десяти раз.
• Не посчитаны сопутствующие вызовы. Векторизация текста, классификатор, проверка ответа, формирование сводки для сжатия истории.
• Отсутствует множитель повторных обращений. Систематический оптимизм на пятнадцать до тридцати пяти процентов.
• Курс взят на день расчёта без запаса, комиссии посредников и налог не добавлены. Для российской компании это недооценка рублёвой суммы на заметную долю.
• Прогноз построен на средней стоимости обращения по всему продукту. Цифра получается арифметически верной и управленчески бесполезной, потому что скрывает сценарий, который съедает половину бюджета.
• Не заложен резерв на изменение поведения пользователей. Как только люди понимают, что в помощника можно загрузить документ, средняя длина контекста меняется без всякого участия команды разработки.

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

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

Как снизить стоимость одного обращения

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

Сократить системную подсказку

Уберите дублирующиеся примеры, оставьте три показательных вместо десяти. Вычистите описания недоступных инструментов. Замените развёрнутые объяснения формата вывода на параметры запроса со строгой схемой. Сократите повторные формулировки одного требования. Типичный результат составляет от сорока до шестидесяти процентов длины без изменения качества ответов. Проверяйте каждое сокращение на наборе из двадцати до пятидесяти реальных запросов, иначе экономия обернётся ростом повторов.

Обрезать историю диалога

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

Ограничить длину ответа

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

Включить кэширование подсказок

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

Выбрать модель под сложность задачи

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

Перенести массовые задачи в пакетный режим

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

Отдать простые задачи локальной модели

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

Чего делать не стоит

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

Собственное размещение против интерфейса прикладного программирования

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

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

Параметр	Оплата по интерфейсу	Собственное размещение
Структура расхода	Пропорционально объёму токенов	Постоянная плата за оборудование и обслуживание
Запуск	Часы	Недели на подбор модели, настройку и нагрузочные испытания
Качество на сложных задачах	Доступны самые сильные модели	Ограничено моделями, которые помещаются в ваше оборудование
Данные	Уходят внешнему поставщику	Остаются в вашем контуре
Изменение нагрузки	Масштабируется само	Требует закупки или аренды мощностей
Скрытые затраты	Курс, комиссии, лимиты частоты запросов	Работа инженеров, обновления, простой оборудования

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

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

Промежуточный вариант, который работает чаще всего

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

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

Как быстро прикинуть стоимость обращения без расчётов

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

Почему счёт растёт, хотя количество пользователей не изменилось

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

Нужно ли платить за токены, если ответ не понравился

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

Что дороже, один длинный запрос или несколько коротких

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

Как считать расход в рублях при оплате в иностранной валюте

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

Можно ли уложиться в бесплатные лимиты

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

С чего начать, если расход уже вышел из-под контроля

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

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