У большинства enterprise AI-счетов, тихо вырастающих до пятизначных и шестизначных сумм, одна и та же первопричина — и не та, к которой инженерные команды тянутся первой. Полевой отчёт о том, что реально гонит расходы на инференс вверх, и о дисциплине, возвращающей их к числу, которое CFO перестаёт пересылать с вопросительным знаком.
AI-счета, удваивающиеся каждый квартал — это не ценовая проблема, а накапливающаяся архитектурная проблема. Модель поменьше и больше кэша обычно дают меньше трети доступной экономии. Остальные две трети живут в оркестрации, дисциплине промпта и контекста, UX и governance.
Кэширование устраняет один конкретный режим отказа — повторяющиеся идентичные или почти идентичные вызовы. Большинство enterprise AI-счетов, растущих квартал к кварталу, проваливаются не в кэшировании; они проваливаются в оркестрации, дисциплине контекста и отсутствии cost governance. Кэширование обычно захватывает около десятой части доступной экономии; остальное в другом.
Редко. Замены на более дешёвую модель выглядят привлекательно изолированно, но часто приводят к дополнительным попыткам, увеличению контекста и последующим исправлениям, которые сводят на нет экономию на каждом вызове. Первый ход почти всегда — видимость (трассировка токенов для каждого запроса), затем чистка оркестрации, и только потом оценка смены модели.
Средства наблюдения (трассировка, теги, алерты) обычно внедряются на первой неделе. Быстрые улучшения промптов и оркестрации — на второй-третьей и обычно составляют 20–40% снижения. Структурные улучшения — те, что снижают расходы на порядок — внедряются в течение следующих двух месяцев по мере изменения архитектуры.