Изменения цен поставщиков ИИ: как защитить экономику на единицу

Что ломается при смене цен

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

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

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

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

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

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

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

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

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

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

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

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

Затем измеряйте стоимость на одно пользовательское действие, а не только стоимость на токен. Один клик «generate report» может запускать планировщик, шаг извлечения, длинный ответ и повтор‑фоллбек. Финансы смотрят на полную стоимость этого клика. Продукт тоже должен.

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

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

Настройте маршрутизацию по шагам

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это не значит делать подсказки расплывчатыми. Речь о том, чтобы платить только за токены, которые действительно меняют ответ. Команды с высоконагруженными AI‑потоками часто сохраняют качество на том же уровне, сокращая при этом использование токенов на 20–40 % только этими мерами. Такая маржа даёт пространство для реакции, не заставляя срочно всё переделывать.

Переработайте рабочие процессы, чтобы дорогие вызовы делали меньше работы

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

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

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

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

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

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

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

Реалистичный пример

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

Предположим, команда видит две большие группы. Около 8 500 тикетов — простые возвраты, вопросы о статусе заказа или уточнения по политике. Остальные 1 500 — споры по оплате, подозрения на злоупотребления аккаунтом или клиенты, которые могут оттечь. Первая группа нуждается в вежливом, понятном черновике. Вторая — в более тонкой формулировке, суждении и большей истории.

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

Разница в стоимости заметна. Если старая схема использовала бы 2 400 входных токенов и 250 выходных токенов для всех 10 000 тикетов, месячные расходы могли бы приблизиться к $315 с премиальной моделью. В маршрутизированной схеме всё выглядит иначе. Простая очередь использует гораздо меньше токенов на дешёвой модели, а рискованные случаи сохраняют премиум для тех, кому это нужно. В этом примере месячные расходы падают примерно до $51.

Разделение также смягчает удар при росте цен у премиальной модели. Если её цена вырастет на 50 %, старая схема поднимется с ~$315 до ~$473. Маршрутизированная схема повысится с ~$51 до ~$71. Команда поддержки всё ещё почувствует увеличение, но экономика на единицу останется в порядке, потому что лишь малая доля тикетов зависит от дорогой модели.

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

Ошибки, которые быстро увеличивают расходы

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

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

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

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

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

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

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

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

Быстрая проверка перед тем, как считать стек устойчивым

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

Короткий чек‑лист ловит большинство слабых мест до того, как цены станут проблемой:

• Измеряйте стоимость по шагам рабочего процесса, а не только по запросу. Если поток использует OCR, извлечение, проверку и финальный ответ, отслеживайте средние токены, задержку и процент ошибок для каждого шага.
• Меняйте модели, не меняя поведения продукта. Прогоните тот же набор тестов через основной и резервный маршруты. Если формат ответа, тон или точность меняются настолько, что ломают downstream‑логику, резерв не готов.
• Поставьте жёсткие лимиты на размер подсказки и повторы. Ограничьте длину контекста, число вызовов инструментов и остановите петли повторов после нескольких попыток.
• Напишите правила фоллбека и для отключений, и для скачков цен. Решите, когда трафик уходит на более лёгкую модель, когда рабочий процесс урезает необязательные шаги и когда продукт должен вернуть более простой ответ вместо долгого ожидания.
• Проверьте маржу при повышении цен на 20–30 %. Используйте реальные цифры трафика, а не догадки.

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

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

Следующие шаги для вашей команды

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

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

Контроль затрат подсказок начните с самых «шумных» задач. Ищите подсказки, которые растут, потому что люди вставляют лишний контекст, повторяют системные инструкции или запрашивают вывод, который никто не использует. Установите бюджеты по токенам для входа и выхода и обрезайте подсказки до момента, пока качество не упадёт. Большинство команд находят потери быстрее, чем ожидали.

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

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

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

Если нужна внешняя проверка, Oleg Sotnikov at oleg.is работает как Fractional CTO и советник стартапов и помогает командам оптимизировать архитектуру ИИ, маршрутизацию и инфраструктурные расходы. Свежий взгляд часто замечает дорогостоящие привычки, которые внутри команды кажутся нормой.