Отдельная проблема - мониторинг агентных систем
AWS описал случай: у агента нет прав IAM на вызов модели, ответ приходит пустым, но код ошибки 500 не возникает - с точки зрения инфраструктуры всё зелёное.
AWS разобрал ошибку в оценке LLM: цена за токен не равна цене результата. Разбираем точность, кеширование промптов и тихие сбои агентов.
AWS на днях разобрал по косточкам вопрос, который каждая компания решает неправильно: как выбрать модель для продакшена.
Стандартный подход - открыть прайс-лист и сравнить доллары за миллион токенов.
Цифра одна на всех сайтах, поэтому она же попадает в таблицу закупки.
Бизнес платит за закрытый тикет поддержки, готовый research-отчёт, верную цифру в финансовой сводке - токены здесь только промежуточная единица.
Между ценой на сайте вендора и результатом на столе клиента стоят три множителя, которые прайс-лист не показывает: как часто модель отвечает правильно, сколько токенов ей нужно, чтобы добраться до правильного ответа, и - для агентных сценариев - сколько шагов она делает.
Каждый шаг агента пересылает модели весь разросшийся контекст диалога заново.
Модель дешевле на 30% за токен может обходиться дороже на 200% за решённую задачу, если ей нужно вдвое больше попыток и втрое больше шагов.
AWS считает три параметра: точность с первой попытки, число токенов на правильный ответ, число шагов в агентном сценарии. Формула реальной стоимости - это цена за токен, умноженная на объём токенов до результата и число итераций, с поправкой на долю ответов, которые вообще пришлось переделывать. Компания, которая меряет модели по первому параметру из трёх, регулярно выбирает не ту модель.
Есть и менее очевидная статья расходов - латентность и повторные вычисления. В типичном запросе к LLM есть фиксированная часть (инструкции, документы, история диалога) и переменная часть (реальный вопрос пользователя). У бота поддержки инструкция может занимать 3000 токенов, а вопрос клиента - 50. Без переиспользования кеша модель пересчитывает эти 3000 токенов на каждый запрос заново.
AWS показал, что prefix-aware маршрутизация в SageMaker Inference - направление запросов с одинаковым префиксом на одни и те же инстансы - снижает задержку и вычислительную нагрузку без изменения самой модели. Это тот же принцип, что лежит в основе кеширования промптов в LLM & Security Gateway: одна и та же системная инструкция не должна пересчитываться тысячу раз в день.
AWS описал случай: у агента нет прав IAM на вызов модели, ответ приходит пустым, но код ошибки 500 не возникает - с точки зрения инфраструктуры всё зелёное.
Другой сценарий: supervisor-агент с плохо сформулированным промптом начинает направлять 20% запросов не тому специализированному агенту, при этом инфраструктурные метрики не меняются.
Классический мониторинг падений и задержек эти сбои не видит - нужна отдельная оценка эффективности самого агента, а не только его доступности.
Для бизнеса это означает: 20% запросов клиентов обслуживаются неправильно, а дашборд показывает 100% аптайм.
Руководитель, который боится потратить бюджет впустую, обычно сравнивает прайс-листы вендоров вместо того, чтобы посчитать стоимость решённой задачи на своих данных. Правильный тест - прогнать реальные кейсы компании через несколько моделей и посчитать цену результата: сколько стоило получить верный ответ с учётом переделок и лишних шагов. Цена одного запроса эту сумму не показывает.
Это ровно тот инженерный слой, который KT.Team строит для клиентов через LLM & Security Gateway: единая точка маршрутизации между OpenAI, Claude, GigaChat, YandexGPT и Qwen с кешированием промптов и метриками по решённым задачам. RAG сокращает число токенов и шагов: модель получает контекст из базы знаний вместо того, чтобы каждый раз выдумывать его заново. А оценка агентов на уровне бизнес-метрик, а не HTTP-статусов, ловит именно те 20% тихо неверных ответов, которые обычный мониторинг пропускает.
Простой на вид выбор модели - инженерная задача: считают цену результата с поправкой на точность, объём токенов и число шагов. Компании, которые продолжают сравнивать модели по прайс-листу, платят за иллюзию экономии - и получают счёт за неё в другом месяце, строкой про низкую точность и лишние доработки.