Как вы измеряете стоимость (токены) агентской системы?

Краткий тезис

Измерение стоимости агентской системы сводится к суммированию токенов каждого шага (входных и выходных) и пересчёту в денежные единицы по тарифам используемой LLM. Ключевые аспекты: раздельный учёт prompt tokens и completion tokens, мониторинг среднего расхода на сессию и внедрение инструментов вроде LangFuse или Prometheus. Оптимизации, такие как уменьшение промпта, переиспользование меньших моделей для планирования и кэширование общих результатов, помогают сдерживать затраты. Практический урок: без мониторинга один агент может потратить $50 за час — такой шок заставляет внедрять учёт с первого дня.

1. Термины и контекст

Агентская система — это orchestration (оркестровка) нескольких вызовов LLM, часто с инструментами (поиск, калькулятор, API), где каждый шаг может генерировать новые запросы. Измерение стоимости необходимо, потому что:

• Агенты могут совершать десятки итераций за одну сессию пользователя.
• Плата за токены — основной операционный расход (opex) в продакшене.
• Без метрик невозможно оптимизировать архитектуру.

Токен — минимальная единица текста, на которую модель делит вход/выход. Один токен ≈ 0.75 слова для английского, ~1.5–2 символа для русского. Стоимость задаётся провайдером: например, у OpenAI GPT-4o — $5 за million input токенов и $15 за million output токенов (цены 2025). Для агентов особенно важна разница: completion (выход) обычно дороже в 3–5 раз, чем prompt (вход).

2. Почему измерение стоимости — не просто подсчёт токенов

Простая сумма токенов по всем вызовам LLM не даёт полной картины. Нужно учитывать:

• Повторные вызовы (retry) из-за ошибок.
• Системные промпты — они статичны, но их длина может быть большой (например, инструкции agent framework).
• Контекст окно — если агент передаёт предыдущие шаги, каждый новый вызов включает историю, что резко увеличивает tokens|input tokens.
• Стоимость инструментов — вызов API (например, search) тоже стоит, хотя это не токены.

Поэтому измерение — это multi-level мониторинг: токены + денежный эквивалент + количество шагов.

3. Подход к измерению: суммирование токенов каждого шага

3.1. Базовая формула

Для каждой agentic loop (цикла агента) нужно посчитать:

total_cost = sum_over_steps( prompt_tokens * price_per_prompt_token + completion_tokens * price_per_completion_token )

Пример на Python:

import tiktoken  # для OpenAI
def count_tokens(text: str, model: str = "gpt-4o") -> int:
    enc = tiktoken.encoding_for_model(model)
    return len(enc.encode(text))

# Допустим, одна итерация агента:
system_prompt = "Ты помощник. Делай шаги A, B."
user_query = "Найди погоду в Москве"
completion = "Шаг 1: вызов API погоды... Результат: +5°C"

input_tokens = count_tokens(system_prompt + user_query)
output_tokens = count_tokens(completion)
cost = (input_tokens / 1_000_000) * 5.0 + (output_tokens / 1_000_000) * 15.0
print(f"Step cost: ${cost:.5f}")

Однако в реальности каждый вызов LLM возвращает usage в ответе API — точные числа токенов. На них и нужно опираться.

3.2. Различие prompt vs completion

Отдельное внимание — function calling: описание инструментов в промпте занимает много токенов (иногда по 500–2000 токенов на одно описание). Если агент использует 5–10 инструментов, промпт раздувается.

4. Мониторинг среднего на сессию

4.1. Сессионные метрики

Вместо глобальной суммы за месяц полезнее считать:

• Cost per session (средняя стоимость одного диалога).
• Tokens per step (среднее число токенов на один вызов LLM).
• Steps per session (среднее количество итераций агента).
• Cost per solved problem (стоимость успешно решённого запроса).

Пример дашборда:

Если steps/session растёт — агент "зацикливается" или плохо спланирован, что резко увеличивает стоимость.

4.2. Реализация мониторинга

Минимальный вариант — логировать каждый вызов LLM в CSV или БД:

import uuid, time

def log_call(session_id, step_id, model, input_tokens, output_tokens, cost):
    # запись в ClickHouse / PostgreSQL / файл
    pass

Более продвинутые инструменты — LangFuse (open-source, специализирован для LLM-приложений) или LangSmith. Они автоматически собирают токены, цены и latency. Пример интеграции с LangFuse:

from langfuse import Langfuse
langfuse = Langfuse()

# внутри обработчика агента
with langfuse.trace(name="agent-session") as trace:
    span = trace.span(name="llm-call")
    # вызов LLM
    response = openai.chat.completions.create(...)
    span.end(
        input=prompt,
        output=response.choices[0].message.content,
        usage=response.usage,
        model=model
    )

Для масштаба тысяч сессий удобно выгружать метрики в Prometheus через кастомный экспортёр (например, гистограмму cost_per_session).

5. Инструменты для измерения стоимости

5.1. Встроенные SDK (OpenAI, Anthropic)

Каждый ответ содержит поля usage.prompt_tokens, usage.completion_tokens. Anthropic добавляет input_tokens и output_tokens. Бесплатно, но нужно агрегировать.

5.2. Платформы наблюдения (Observability)

5.3. Калькуляторы стоимости

Полезно иметь локальный скрипт, который по логу (CSV) считает общую стоимость с учётом разных моделей (GPT-4o, Claude 3.5 Sonnet, GPT-4o-mini). Пример:

PRICES = {
    "gpt-4o": {"input": 5.0, "output": 15.0},      # $ per 1M tokens
    "gpt-4o-mini": {"input": 0.15, "output": 0.6},
    "claude-3.5-sonnet": {"input": 3.0, "output": 15.0},
}

def compute_total_cost(log_entries: list):
    total = 0
    for entry in log_entries:
        model = entry["model"]
        inp = entry["prompt_tokens"]
        out = entry["completion_tokens"]
        p = PRICES[model]
        total += (inp / 1e6) * p["input"] + (out / 1e6) * p["output"]
    return total

6. Оптимизация стоимости агентской системы

6.1. Уменьшение промпта

• Сокращение системного промпта: убрать примеры, использовать короткие инструкции.
• Динамический промпт: включать только релевантные инструменты (не все сразу).
• Сжатие истории: пересказывать предыдущие шаги кратко вместо полного контекста.

6.2. Использование меньшей модели для планирования

Агенты часто используют дорогую модель (GPT-4o) для каждого шага. Альтернатива:

• Большая модель (GPT-4o) — для критических решений или генерации ответа.
• Маленькая модель (GPT-4o-mini или Llama 3.1 8B) — для планирования, summarization, выбора инструмента.

Пример архитектуры: GPT-4o-mini пишет план (5 шагов), затем каждый шаг выполняется на GPT-4o (если высокая точность нужна) или на той же мини-модели (для простых действий). Это сокращает стоимость в 3–10 раз.

6.3. Кэширование общих результатов

• Кэш запросов: если два пользователя задают одинаковый вопрос, можно вернуть закэшированный ответ (если агент не меняет состояние).
• Memoization промежуточных шагов: вызовы API (погода, поиск) можно кэшировать на несколько минут.
• Промпт кэш (OpenAI Prompt Cache): некоторые провайдеры дают скидку на повторяющиеся префиксы промпта.

6.4. Ограничение числа шагов

Установить max_iterations (например, 10) и timeout на сессию. Если агент зациклился — прерывать и возвращать частичный ответ или ошибку. Это спасает от "убежавшей" стоимости.

7. Реальный опыт: шок $50/час

В одном из проектов разработчик запустил агента в prod без мониторинга. Агент должен был парсить документы, но из-за ошибки в промпте начал бесконечно рекурсивно вызывать функцию поиска в Википедии. За 30 минут было потрачено 8 миллионов выходных токенов на GPT-4 — около $120. В итоге средняя стоимость сессии оказалась $2.50, а ожидалась $0.05. Урок:

• Мониторинг в реальном времени: алерт, если cost/min > порога.
• Лимиты: максимум шагов и бюджета на сессию.
• Дроп-тесты: перед релизом прогонять агента на тестовых сценариях и проверять стоимость.

8. Пет-проект для закрепления

Задача: Создать простого агента-помощника (поиск информации в интернете + ответ), который логирует стоимость каждого шага и показывает её в конце диалога.

Инструменты: Python, OpenAI API (или любой LLM), библиотека aiohttp для поиска, tiktoken или SDK для подсчёта токенов, локальный SQLite для логов.

Шаги:

1. Реализовать агент с двумя инструментами: search_web(query) и calculate(expression).
2. Для каждого вызова LLM извлекать usage из ответа и сохранять в таблицу logs (session_id, step, model, input_tokens, output_tokens, cost).
3. Добавить функцию get_session_cost(session_id), которая суммирует затраты по всем шагам.
4. В конце каждого диалога выводить пользователю итоговую стоимость в долларах.
5. Написать скрипт, который симулирует 10 диалогов и выводит среднюю стоимость на сессию.
6. Опционально: добавить кэш для повторяющихся ответов (если вопрос совпадает с предыдущим на 90%).

Ожидаемый результат:

• Понимание, как каждый шаг влияет на общую стоимость.
• Статистика: средний cost/session, распределение шагов.
• Вывод: без мониторинга легко потратить лишнее.

9. Связь с другими вопросами

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

10. Навигация

• Предыдущий: 54
• Следующий: 56
• Индекс: 00. Индекс разборов

Навигация

• Предыдущий: 54
• Следующий: 56
• Индекс: 00. Индекс разборов