Латентность против стоимости: инженерия агентных систем

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

Из чего складывается задержка

Latency агента — это не latency модели. Между запросом пользователя и ответом стоит несколько источников ожидания, и модель среди них не всегда главный.

• Сетевой roundtrip до провайдера — десятки миллисекунд на каждый вызов, и агент делает их последовательно.
• Time to first token — задержка до начала генерации. У больших моделей она выше, у небольших — заметно ниже.
• Скорость генерации — токенов в секунду. Длинный ответ модели с рассуждением тянется дольше короткого.
• Вызовы инструментов — поход в базу, в поиск, во внешний API. Если инструмент медленный, агент ждёт его, а не наоборот.
• Циклы саморефлексии — каждый шаг "подумал — проверил — переделал" умножает всё перечисленное.

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

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

Из чего складывается стоимость

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

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

Где деньги утекают незаметно

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

Три архитектуры и их компромиссы

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

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

Рычаги, которые реально работают

Оптимизация агента — это набор конкретных приёмов, а не общий призыв "сделать быстрее".

1. Кэширование промптов. Крупные провайдеры дают кэш на повторяющийся префикс промпта (системная инструкция, описания инструментов). Оплачивается он дешевле обычного ввода. Условия и скидку сверяйте на странице тарифов вашего провайдера — цифры меняются.
2. Разные модели на разные шаги. Мелкая быстрая модель для классификации и маршрутизации, крупная — только для шага, где нужно рассуждение.
3. Обрезка контекста. Суммаризировать старую историю вместо того, чтобы тащить её целиком. Передавать только релевантные на этом шаге инструменты.
4. Параллелизация независимых вызовов. Если два вызова инструментов не зависят друг от друга, запускайте их одновременно, а не в цепочку.
5. Стриминг и промежуточный вывод. Показывать пользователю прогресс шагов снижает воспринимаемую задержку, даже если общее время не изменилось.
6. Бюджет на шаги. Жёсткий лимит итераций, после которого агент отдаёт лучший имеющийся ответ вместо бесконечного самоисправления.

Кому это пригодится, а кому нет

Пригодится, если вы строите что-то из списка:

• Ассистент поддержки, который ходит в несколько систем за одним ответом — здесь маршрутизация и кэш дают прямую экономию на каждом обращении.
• Пакетная обработка документов или данных, где счёт за токены умножается на объём и латентность отдельного запроса вторична, а цена критична.
• Интерактивный продукт, где пользователь ждёт ответ вживую — тут в приоритете time to first token и стриминг.

Не пригодится усложнять, если:

• У вас один-два вызова модели на запрос — это ещё не агент, и городить маршрутизацию нет смысла.
• Задача с жёсткой структурой решается детерминированным пайплайном — свободный агент только добавит расходов и непредсказуемости.
• Объём запросов мал, а инженерное время на оптимизацию стоит дороже, чем сам счёт за токены. Считайте: иногда "дорогой" агент дешевле, чем неделя работы по его удешевлению.

¹ Контекстное окно — максимальный объём текста (в токенах), который модель обрабатывает за один вызов: и промпт на входе, и её ответ. В агенте окно быстро заполняется историей и результатами инструментов, и всё его содержимое оплачивается на каждом шаге заново.