Экономика затрат на ИИ-агентов: когда Haiku обходит Sonnet (а когда нет)

Содержание

Обновлено в июне 2026.

Кратко: Выбор Claude Haiku вместо Sonnet способен снизить стоимость одного вызова на порядок, но только когда задача терпит более низкий процент успеха у Haiku. Значимая метрика — это стоимость за успешный результат — стоимость вызова плюс повторные попытки плюс ручная доработка, — а не ценник за токен. Я маршрутизирую по задаче, и заметная доля моих высокообъёмных шагов выполняется на Haiku, тогда как решения, требующие суждения, остаются на Sonnet.

Взгляд оператора: Я веду более 100 агентов, и инференс — реальная статья расходов. Но я видел команды, которые «экономили», загоняя всё на самую дешёвую модель, а потом расплачивались повторными попытками, эскалациями и недовольными клиентами. Расчёт затрат работает только тогда, когда вы измеряете всю воронку.

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

Экономика токенов, без обиняков

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

• Haiku — дешёвый и быстрый уровень, с большим отрывом самая низкая стоимость за токен в семействе.
• Sonnet — посередине: заметно дороже Haiku, заметно дешевле Opus.
• Opus — премиальный уровень для самых сложных рассуждений.

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

Метрика, которая действительно важна: стоимость за успешный результат

Стоимость за вызов — показатель для тщеславия. Вот формула, которой я пользуюсь на самом деле:

стоимость_за_успех = (стоимость_вызова × попытки) + стоимость_доработки
                     ÷ доля_успеха

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

Допустим, Haiku обходится примерно в десятую часть стоимости Sonnet за вызов. Если на задаче Haiku успешен в 80% случаев, а Sonnet — в 98%, экономия за вызов выглядит огромной. Но если каждый сбой Haiku запускает одну повторную попытку и 1 из 10 всё ещё требует человека, который стоит реальных денег, член доработки может поглотить экономию на токенах. На малорисковой высокообъёмной задаче расчёт подавляюще в пользу Haiku. На задаче, где сбой отправляет письмо не тому клиенту, он может полностью перевернуться.

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

Где Haiku побеждает безоговорочно

Haiku — верный выбор, когда задача узкая, структурированная и проверяемая:

• Классификация и маршрутизация — «это входящее сообщение — бронь, жалоба или спам?» Три корзины, легко проверить, выполняется постоянно. Haiku весь день.
• Извлечение по схеме — вытащить из текста дату, имя, сумму, с валидацией через Zod. Если вывод парсится, он почти наверняка верен.
• Короткие переписывания и форматирование — правка тона, резюмирование заведомо хорошего ввода, нормализация данных.
• Фильтрация первого прохода — Haiku сортирует, и только неоднозначные случаи эскалируются на Sonnet. Это паттерн с наибольшим рычагом.

Общая нить: цена ошибки Haiku низка, а саму ошибку дёшево поймать. Когда проверка дешева, а ставки низки, побеждает дешёвая модель.

Где Sonnet отрабатывает свою цену

Sonnet (а иногда и Opus) стоит того, когда задача открытая, многошаговая или дорогая в случае ошибки:

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

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

Правило маршрутизации, которое я действительно внедряю

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

function pickModel(task: Task): string {
  // Дёшево, проверяемо, высокий объём → Haiku
  if (task.type === "classify" || task.type === "extract") {
    return "claude-haiku";
  }
  // Открытая задача или обращённая к клиенту → Sonnet
  if (task.customerFacing || task.steps > 2) {
    return "claude-sonnet";
  }
  return "claude-sonnet"; // по умолчанию — безопасный выбор
}

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

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

Разобранный пример из моего собственного стека

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

Теперь возьмём шаг, который составляет настоящий ответ клиенту. Меньший объём, открытая задача, а ушедший плохой черновик стоит доверия. Этот остаётся на Sonnet. Тот же агент, две модели, маршрутизация по ставкам. Я слежу за стоимостью на запуск и метриками успеха у обеих, как описываю в как я измеряю, действительно ли работает ИИ-агент — и опускаю шаг на уровень ниже лишь после того, как оценка скажет, что более дешёвая модель удерживает долю успеха.

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

Всегда ли Claude Haiku дешевле Sonnet на практике?

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

Как выбрать между Haiku и Sonnet для конкретной задачи?

Оцените задачу по двум осям: насколько проверяем вывод и насколько дорого обходится ошибка. Дешёвая в проверке, малорисковая, высокообъёмная работа идёт на Haiku; открытая, обращённая к клиенту или трудная для проверки — на Sonnet. Маршрутизируйте по задаче, а не по агенту.

Какую единственную метрику затрат мне отслеживать?

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

Можно ли использовать обе модели в одном агенте?

Да, и обычно так и стоит делать. Самый сильный паттерн — дешёвый первый проход (Haiku классифицирует или фильтрует), эскалирующий на Sonnet только неоднозначные случаи. Этот гибрид, как правило, обходит запуск всего на одном уровне.