← Все руководства

Как обнаружить аномальный расход на LLM за час, а не в конце месяца

Шаги

1. Разделите расходы по проектам, окружениям и владельцам: передавайте в каждый запрос к LLM идентификатор проекта, среды, команды и, при необходимости, клиента.

2. Зафиксируйте базовый уровень: соберите почасовые данные о количестве запросов, токенах, стоимости, используемых моделях и доле ошибок за обычный период.

3. Установите бюджеты: задайте месячный лимит для проекта и внутренние почасовые ориентиры; пороги пометьте как иллюстрацию и подстройте по вашей базовой линии, например предупреждение при заметном отклонении, а не по универсальному числу.

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

5. Добавьте защитные действия: при критическом превышении временно ограничивайте частоту запросов, отключайте несущественные сценарии или переводите их на заранее проверенную более дешёвую модель.

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

7. Проведите разбор инцидента: зафиксируйте время начала, затронутый проект, источник перерасхода, максимальный ущерб, сработавшие меры и изменения, которые предотвратят повторение.

Чеклист

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

Типичные ошибки

• Контролировать только итоговую сумму за месяц и не видеть почасовые всплески.
• Смешивать расходы нескольких проектов, из-за чего невозможно быстро найти источник проблемы.
• Настраивать алерты только по количеству запросов и игнорировать стоимость токенов и выбор модели.
• Использовать одинаковые пороги для проектов с разной нагрузкой и разной критичностью.
• Отправлять уведомления без владельца, срока реакции и процедуры ограничения расходов.
• Считать любой всплеск атакой, не проверив релиз, рост трафика, повторные запросы и ошибки интеграции.