Как оптимизировать расходы на LLM и не потерять в качестве

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

Из чего складывается счёт за LLM

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

Пять множителей, которые определяют сумму в конце месяца:

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

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

Почему вход и выход стоят по-разному

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

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

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

Режим рассуждений и токены, которых вы не видите

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

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

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

Почему своё железо считается по другой формуле

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

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

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

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

Диагностика: что именно съедает бюджет

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

Минимальный набор данных, который нужно собрать по каждому обращению:

1. Идентификатор типа задачи, то есть классификация, генерация текста, извлечение данных, ответ на вопрос по документам.
2. Модель и поставщик, которые обслужили запрос.
3. Количество входных токенов с разбивкой на системный промпт, историю и извлечённый контекст.
4. Количество выходных токенов, отдельно служебные токены рассуждений.
5. Признак попадания в кэш и доля контекста, обслуженная кэшем.
6. Номер попытки, если запрос был повторён после сбоя.
7. Расчётная стоимость обращения в рублях.

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

Пять источников перерасхода, которые встречаются чаще всего

Повторяющиеся сценарии, из которых складывается большая часть лишних трат:

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

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

Цикл без кэша и арифметика, которая за ним стоит

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

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

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

Повторы, которые оплачиваются дважды

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

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

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

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

Что показывает распределение и не показывает среднее

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

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

Выбор и маршрутизация моделей

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

Лестница моделей

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

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

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

Правила маршрутизации по сложности запроса

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

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

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

Класс обслуживания и фоновые задачи

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

Задачи, которые безболезненно переводятся в отложенный режим:

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

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

Кэширование запросов

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

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

Prompt caching: скидка до 90% на повторный контекст

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

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

Типовые сценарии, где кэш даёт максимальный эффект:

• Диалоги, где сочетание системного промпта и истории взаимодействия повторяется для разных пользователей или в разных сеансах.
• Обработка одного длинного документа несколькими запросами: сначала вы выделяете информацию, потом задаёте уточняющие вопросы, потом запрашиваете свёртку. Документ уходит в кэш один раз.
• Агенты, которые используют один и тот же набор инструментов на протяжении сеанса. Описания инструментов кэшируются.
• Регулярные задания, которые используют один и тот же промпт, например ежедневная обработка входящей почты.
• Batch-обработка однородных данных с одним промптом для множества записей.

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

Точное совпадение и семантический кэш

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

Семантический кэш работает иначе. Система преобразует запрос в векторное представление и ищет похожие векторы в кэше. Если находит запрос с достаточно близким смыслом, использует его ответ, даже если дословное совпадение отсутствует. Например, вопросы "Какие авиакомпании летают в Барселону?" и "Куда летают самолёты из Москвы в Испанию?" с точки зрения семантики часто означают одно, и на оба можно вернуть одинаковый ответ.

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

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

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

TTL, инвалидация и риск устаревших ответов

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

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

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

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

Сокращение промпта и контекста

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

Чистка избыточности и структурированные форматы

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

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

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

Структурированные форматы помогают сократить промпт иначе. Вместо описания естественным языком, как должен выглядеть ответ, вы даёте JSON-схему или XML. Модель точнее следует структуре, и вам не нужны длинные объяснения. Три примера структурированного ответа часто работают лучше, чем десять примеров в виде текста.

Сжатие промпта и prompt-pruning

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

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

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

Готовые реализации prompt-pruning появляются в исследовательских работах и в некоторых платформах для работы с моделями. Однако если вы работаете с API поставщика, такого встроенного инструмента может не быть. Тогда имеет смысл реализовать простую версию самостоятельно: прогнать через маленькую модель несколько сотен примеров, отсечь явно неиспользуемые части и проверить, что качество не упало.

RAG вместо передачи всего документа

Третий путь сокращения входа — не передавать весь источник данных, а передавать только релевантный фрагмент. Это то, что называют RAG, retrieval-augmented generation, и это часто самая прибыльная оптимизация из всех.

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

Выигрыш чиндалов. Пусть релевантные фрагменты занимают две тысячи токенов. Вы платите за две тысячи вместо пятидесяти тысяч. Если такие вопросы идут по тысяче в день, экономия достигает сорока восьми тысяч токенов на запрос.

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

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

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

Контроль длины ответа

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

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

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

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

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

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

Ранняя остановка и экономия на незавершённых ответах

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

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

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

Батчинг и асинхронная обработка

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

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

Как устроен пакетный режим на практике

Порядок работы примерно одинаков у всех поставщиков, которые его предлагают:

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

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

Какие задачи выносить в фон

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

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

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

Экономия на self-hosted инференсе

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

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

Квантование модели и KV-кэша

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

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

Логика экономии здесь выворачивается наизнанку относительно привычной. Вы не уменьшаете стоимость вычисления, она фиксирована арендой. Вы увеличиваете количество полезной работы, выполняемой за один оплаченный час.

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

Урезание окна контекста

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

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

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

Расчёт потребления памяти ускорителя

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

Составляющая	Как оценить	Пример для модели на 20 млрд параметров
Веса модели	Число параметров умножить на объём одного параметра	Около 20 ГБ при восьмибитной точности
Кэш внимания	Зависит от длины контекста, числа слоёв и числа параллельных запросов	От 6 до 15 ГБ при контексте 8 тысяч токенов и 30 запросах
Буферы вычислений	Фиксированный объём под промежуточные результаты и графы вычислений	2 до 4 ГБ
Накладные расходы среды	Резерв среды исполнения и драйвера	1 до 2 ГБ

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

Мониторинг расходов и лимиты

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

Метрики, которые действительно работают

Набор показателей, достаточный для управления расходами:

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

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

Уровни оповещений и жёсткие бюджеты

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

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

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

Чем вести учёт

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

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

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

Сколько экономят приёмы вместе

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

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

Шаг	Что изменилось	Эффект на счёт
Маршрутизация	Классификация и типовые ответы ушли на младшую модель, наверх поднимается около 20% обращений	Минус 55%
Кэширование промпта	Системный промпт и описания инструментов обслуживаются кэшем	Минус 25% от остатка
Поиск вместо полного контекста	В контекст идут релевантные фрагменты базы знаний вместо всего раздела	Минус 20% от остатка
Контроль вывода	Режим рассуждений только на сложных обращениях, лимит и формат ответа	Минус 30% от остатка
Пакетный режим	Разбор истории обращений и аналитика переведены в отложенную обработку	Минус 10% от остатка

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

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

Где экономить не стоит

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

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

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

Три типичные ошибки при внедрении

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

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

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

Чек-лист внедрения

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

1. Проведите все обращения к моделям через единую внутреннюю точку входа, если этого ещё нет. Без этого остальные шаги невозможны.
2. Включите подробное журналирование с типом задачи, версией промпта, количеством токенов по категориям и расчётной стоимостью.
3. Соберите данные за неделю и постройте распределение расходов по типам задач и по стоимости отдельных обращений.
4. Сверьте число обращений в своём журнале с отчётом поставщика и настройте политику повторов, если расхождение превышает десять процентов.
5. Соберите тестовый набор из ста-двухсот реальных примеров с известными правильными ответами по каждому крупному типу задач.
6. Прогоните набор через модели разных классов и зафиксируйте, где понижение класса не влияет на качество.
7. Внедрите маршрутизацию на тех типах задач, где измерения это подтвердили, с проверкой результата и подъёмом наверх при неудаче.
8. Выделите неизменяемую часть промпта и включите кэширование контекста.
9. Выставьте лимиты на длину вывода по фактическим процентилям и добавьте последовательности остановки.
10. Отключите режим рассуждений на задачах, где он не нужен, и проверьте качество на тестовом наборе.
11. Переведите задачи без требования к мгновенному ответу в пакетный режим.
12. Почистите системные промпты последовательным удалением частей с проверкой качества на каждом шаге.
13. Замените передачу полных документов поиском релевантных фрагментов там, где это применимо.
14. Настройте оповещения по скорости расхода, по доле бюджета и по аномально дорогим обращениям.
15. Установите жёсткий потолок с деградацией вместо отказа и отдельные лимиты для тестовых окружений.
16. Поставьте в календарь ежемесячный разбор расходов, чтобы оптимизация не разрушилась за следующий квартал.

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

С чего начать, если нужен быстрый результат за один день

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

Насколько младшая модель проигрывает флагману

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

Стоит ли переходить на собственное размещение модели

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

Может ли кэш отдавать устаревшие ответы

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

Нужно ли переписывать приложение под все эти приёмы

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

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

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

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