Почему стоимость агентных ИИ растёт стремительно: модель расчёта затрат, основанная на архитектуре

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

«Какова стоимость в миллион токенов для этой модели?»

Это разумный вопрос, но для производственных систем агентного ИИ он упускает из виду настоящую проблему.

Одна запрос от пользователя не приводит к одному вызову языковой модели.

Поток обработки запросов в агентной системе обычно выглядит следующим образом:

User Request
     ↓
Router
     ↓
Planner
     ↓
Retrieval
     ↓
Tool Call
     ↓
Tool Result Interpretation
     ↓
Validator
     ↓
Final Response

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

Поэтому показатель, который стоит отслеживать, — это не просто:

Стоимость одного вызова модели

Это:

Стоимость выполненной задачи.

Что на самом деле влияет на стоимость агента

Общая стоимость работы агентного рабочего процесса значительно превышает просто расход токенов:

Agent Cost
=
LLM inference
+ Embeddings
+ Reranking
+ Vector/Search infrastructure
+ Tool/API calls
+ Compute
+ Storage
+ Observability
+ Evaluations

Даже внутри категории «инференс LLM» приходится иметь дело с входными токенами, выходными токенами, кэшированными токенами, а также возможно с несколькими разными моделями, которые работают на разных этапах обработки данных.

Такая реальность меняет подход к принятию архитектурных решений.

1. Отправляйте каждый запрос в модель подходящего размера

Не каждая задача требует использования самой мощной модели, к которой у вас есть доступ.

Request
   ↓
Router
   ├── Simple extraction → Small model
   ├── Moderate reasoning → Mid-tier model
   └── Complex reasoning → Strong model

Ещё одним полезным подходом является поэтапное усиление модели.

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

Цель не в том, чтобы всегда выбирать самый дешевый вариант.

Цель — найти самую недорогую архитектуру, которая всё равно соответствует установленным требованиям к качеству и надежности.

2. Прекратите тратить ресурсы на вызовы моделей для детерминированной логики

Этот момент кажется очевидным, но он имеет огромное значение при работе в масштабах.

Каждый раз, когда обычный код может надежно ответить на вопрос, пусть именно он этим занимается.

Такие вещи, как проверка прав доступа, арифметические операции, верификация схемы, фильтрация, детерминированные решения по маршрутизации и большинство бизнес-правил, как правило, не требуют использования LLM.

Полезное правило:

Никогда не делегируйте LLM те задачи, которые детерминированный софт уже может выполнять лучше.

Сохраняйте вероятностное мышление для тех этапов рабочего процесса, где оно действительно оправдывает свои затраты.

3. Рассматривайте контекст как бюджет на расходы

Агенты с длительным сроком работы постоянно накапливают контекст в процессе своей работы.

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

Вместо того чтобы позволять объему контекста расти без ограничений, следует поддерживать его объем примерно на таком уровне:

Recent Context
      +
Compact Summary
      +
Relevant Memory
      +
Task-Specific Retrieved Context

Практики вроде краткого изложения, установления срока действия контекста, использования скользящих окон контекста и поиска информации на основе релевантности существуют не только для контроля размера контекста.

Они также выполняют функцию контроля затрат.

4. Настройка RAG Top-K — это инструмент контроля затрат

Предположим, вы получаете 20 фрагментов информации, каждый из которых содержит примерно 700 токенов.

Это в сумме дает примерно 14 000 токенов полученного материала.

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

Лучше спроектированный механизм поиска будет выглядеть примерно так:

Query
  ↓
Retrieve broader candidate set
  ↓
Rerank
  ↓
Select best 4–6 chunks
  ↓
LLM

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

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

5. Кэширование на нескольких уровнях

Кэширование — это не единая техника; существует несколько его видов, которые можно комбинировать.

Например:

Exact Cache
Semantic Cache
Prompt/Context Cache
Tool Result Cache
Retrieval Cache

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

Аналогично, объёмные статические промпты системы, определения инструментов и тексты правил не требуют перепроцессирования с нуля при каждом вызове, если ваша платформа или поставщик моделей поддерживает соответствующий механизм кэширования.

6. Установление строгих ограничений для автономных агентов

Агенты сами создают риски: выход за пределы контроля.

LLM
 ↓
Tool
 ↓
LLM
 ↓
Tool
 ↓
LLM
 ↓
...

Одна ошибка в организации работы может одновременно привести к сбоям в надежности и значительному увеличению затрат.

Поэтому агентам в производственной среде необходимы четкие ограничения, касающиеся таких аспектов, как:

Maximum agent steps
Maximum tool calls
Maximum tokens
Maximum wall-clock time
Maximum cost per run

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

7. Включение затрат в стек инструментов для мониторинга

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

Which application?
Which workflow?
Which agent?
Which model/provider?
How many input tokens?
How many output tokens?
How many tool calls?
How long did it take?
How much did it cost?
Did the task actually succeed?

На основе этого панели управления могут отображать такие показатели, как:

Cost / request
Cost / successful task
Cost / workflow
Cost / model
Cost / application
Cost / team
Cost / customer

На этом этапе оптимизация расходов на ИИ все больше напоминает инженерию платформ и FinOps, чем настройку промптов.

Стоимость и качество должны настраиваться совместно

Самый дешевый способ выполнения задачи не обязательно является лучшим.

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

Поэтому показатель, который стоит оптимизировать, ближе к следующему:

Successful Tasks
Value = --------------------
        Cost + Latency + Risk

Это не буквальное универсальное уравнение — это инженерный подход.

Для производственных систем агентного ИИ необходимо сменить мышление на следующее:

Перестаньте оптимизировать токены по отдельности. Начните оптимизировать экономическую эффективность успешного выполнения задачи.

Потому что как только агенты смогут рассуждать, получать информацию, вызывать инструменты, повторять попытки, проверять результаты и работать в циклах:

1 запрос от пользователя больше не равен 1 вызову модели.

И именно здесь стоимость перестаёт быть просто деталью ценообразования и превращается в проблему проектирования системы.