LLM-агенты на дешёвых моделях обходятся втрое дороже: почему цена за токен врёт

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

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

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

Я называю это «эффект скрытой пошлины» — вы экономите на входе и переплачиваете на выходе, причём переплата не видна, пока вы не начнёте считать реальные цифры.

Бенчмарки врут — но не специально

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

MMLU проверяет знания по 57 предметным областям. GSM8K проверяет арифметику на школьных задачах. HumanEval проверяет способность писать код. Все три — отличные инструменты для своей задачи.

Но ни один из них не измеряет: — Способность планировать последовательность из 5+ шагов. — Устойчивость к ошибкам (что делает модель, когда первый план не сработал). — Эффективность использования инструментов (сколько вызовов нужно для решения задачи). — Деградацию при длинном контексте (как меняется качество на 50-м шаге цепочки).

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

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

Три процента на бенчмарке могут означать тридцать процентов провалов в продакшене.

Как на самом деле считать стоимость модели

Единственный честный способ — считать не цену за токен, а стоимость решённой задачи.

Формула простая:

Стоимость задачи = (цена за токен) × (среднее количество токенов на задачу) + (стоимость времени ожидания) + (стоимость ошибок)

Цена за токен — единственное, что показывают в маркетинговых материалах. Остальные три компонента вы узнаете только в бою.

Как это замерить:

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

Я готов поставить на то, что в большинстве случаев дешёвая модель окажется дороже.

Не все задачи одинаковы

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

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

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

Чем длиннее цепочка, тем сильнее проявляется разрыв между моделями. На одном шаге — разница 3%. На пяти шагах — уже 15%. На двадцати — модель может уйти в бесконечный цикл.

Что с этим делать: практические рекомендации

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

Второе — считайте стоимость за задачу, а не за токен. Заведите метрики: количество вызовов инструментов на задачу, количество повторных попыток, процент успешных завершений, среднее время выполнения. Это ваши реальные KPI, а не цена за миллион токенов.

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

Четвёртое — мониторьте деградацию. Модели обновляются, и то, что работало вчера, может сломаться завтра. Автоматические тесты на ваших реальных сценариях — не роскошь, а необходимость.

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

Заключение

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

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

Имя источника: dzen.guru URL источника: https://dzen.ru/a/aCnHSgO1Dxsqp7U_

Угол: Практический разбор: при переходе на дешёвые модели для агентов счета за токены растут в 10-100 раз из-за неэффективности планирования — стандартные бенчмарки это не видят, поэтому разработчикам нужна локальная методология оценки моделей