Как снизить стоимость LLM без ухудшения качества: три эксперимента

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

Ниже три мысленных, но технически воспроизводимых эксперимента: интернет-магазин, Telegram-команда и финансовый отдел. Цифры приведены как методика расчёта, а не как обещание экономии для любого проекта.

01Интернет-магазин: дорогим оказался не текст

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

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

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

02Telegram: одна модель писала красиво, но одинаково

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

Workflow разрезали не по сложности, а по характеру мышления:

· дешёвая модель собирала факты из брифа и отмечала пробелы;

· вторая модель предлагала пять разных углов без написания поста;

· сильная модель разворачивала только выбранный угол;

· детерминированный validator проверял длину, ссылки и запрещённые слова;

· редактор принимал решение, а его правки возвращались в Eval.

Стоимость одного API-запроса выросла: вместо одной генерации стало три. Но стоимость опубликованного поста снизилась, потому что резко сократилось число полных переписываний.

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

Что измеряли

03Финансы: дешёвая модель прошла benchmark и не прошла аудит

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

Команда отказалась от правила «всё ниже определённой длины — дешёвой модели». Вместо него появился risk router:

· обычная операция с известным контрагентом — быстрый route;

· новый контрагент, большая сумма или конфликтующие поля — сильная модель;

· отсутствующая ссылка на источник — ручная проверка;

· любое действие в учётной системе — только после детерминированной валидации.

Модель больше не принимала финальное решение. Она формировала структурированное предложение: категория, аргумент, цитата из документа и confidence. Это одновременно снизило стоимость и повысило объяснимость.

Общая формула трёх экспериментов

Во всех случаях оптимизировали не цену Token, а ожидаемую стоимость результата:

Стоимость результата = API + повторные вызовы + проверка человеком + цена ошибки.

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

Как собрать портфель моделей

Для большинства компаний достаточно трёх ролей, а не двадцати моделей:

Через OdiRouter такой портфель можно держать за единым OpenAI-compatible API и менять Model ID без отдельного биллинга и интеграции для каждой модели. Но логику Fast/Strong/Specialist лучше хранить в продукте: только он понимает цену ошибки.

Эксперимент, который можно запустить за неделю

День 1: выгрузить 100 обезличенных production-задач.

День 2: разделить их по риску и типу результата.

День 3: прогнать fast и strong routes вслепую.

День 4: посчитать не Token, а принятые результаты.

День 5: включить shadow routing.

День 6: проверить ошибки на границе классов.

День 7: запустить 5% безопасного трафика.

Вместо вывода

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