Как считать стоимость LLM-запросов на своём сервере

MAATRIX

Счёт от OpenAI или Anthropic в конце месяца показывает одну сумму сразу по всем моделям, фичам и пользователям — а разобраться, что именно её раздуло, нечем. Прикинуть стоимость LLM-запросов «на глаз», умножив число символов на примерную цену, не получится: у входных и выходных токенов разные тарифы, кэш меняет цену в разы, а у self-hosted моделей нет прайс-листа от вендора. Разберём, как считать стоимость LLM-запросов на своём сервере по факту — через usage-поля из ответа API и Langfuse, а не прикидкой на бумаге.

Из чего складывается стоимость LLM-запроса

Стоимость запроса к LLM — это не «символы × цена», а произведение числа токенов на тариф, который зависит от направления (вход или выход), провайдера, модели и того, участвовал ли кэш. У обоих грандов — OpenAI и Anthropic — ответ на каждый вызов содержит объект usage с реальными цифрами, а не оценку задним числом.

У Chat Completions API OpenAI это выглядит так:

{
  "usage": {
    "prompt_tokens": 812,
    "completion_tokens": 194,
    "total_tokens": 1006,
    "prompt_tokens_details": { "cached_tokens": 640 }
  }
}

У Messages API Anthropic — так:

{
  "usage": {
    "input_tokens": 812,
    "output_tokens": 194,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 640
  }
}

Оба провайдера считают токены, а не байты и не символы. Один токен — в среднем несколько символов на латинице, но кириллица на большинстве BPE-токенайзеров бьётся заметно мельче — одна и та же фраза на русском обычно даёт больше токенов, чем английский перевод. Умножать len(text) на цену «примерно» — значит закладывать ошибку не в свою пользу для русскоязычного продукта.

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

Почему ручной подсчёт токенов обманывает: токенайзеры и кэш

Прогнать промпт через tiktoken и умножить на цену — обычный способ прикинуть стоимость до вызова API. Но tiktoken — токенайзер OpenAI (o200k_base у последних моделей, cl100k_base у более старых), а не универсальный стандарт. У Anthropic свой токенайзер, не совпадающий с tiktoken ни по словарю, ни по правилам разбиения текста — число токенов для одного промпта у двух моделей разойдётся, и оценка стоимости Claude через tiktoken окажется систематически неточной, а не «примерно похожей».

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

curl -s https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-4-5","messages":[{"role":"user","content":"..."}]}'

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

У Anthropic кэширование явное: вы сами отмечаете точку cache_control в запросе, и первый вызов с такой меткой платит надбавку за запись (cache_creation_input_tokens), а каждый следующий в пределах времени жизни кэша — сниженную цену за чтение (cache_read_input_tokens). У OpenAI кэширование автоматическое: при повторяющемся начале длинного промпта часть входа сама попадает в prompt_tokens_details.cached_tokens по льготному тарифу, без отдельного шага записи и без надбавки.

Разница принципиальна: взяв только input_tokens и умножив на базовую цену входа без учёта полей кэша, вы систематически завысите стоимость чат-бота с длинным системным промптом и историей диалога — часто именно эти токены составляют основной объём входа. Надёжный источник один — usage, который вернул сам провайдер на конкретный вызов.

Как Langfuse превращает usage в стоимость автоматически

Парсить usage вручную и складывать по моделям — работает для одного скрипта и разваливается, как только моделей и провайдеров становится больше одной. Langfuse решает это архитектурно: каждый вызов модели — объект generation внутри трейса с полями по каждому направлению — вход, выход, кэш, если он есть, и итог.

Официальные интеграции — обёртки для OpenAI и Anthropic SDK, callback-хендлер LangChain, встроенная поддержка LiteLLM — сами вытаскивают usage и передают в Langfuse, парсить руками не нужно. Если готовой интеграции нет — например, самописный запрос к нестандартному эндпоинту — usage можно передать в generation вручную: Langfuse найдёт цену по имени модели и посчитает стоимость сам.

Цену Langfuse ищет по встроенному списку моделей, сверяя имя из вызова (gpt-4o-mini, claude-sonnet-4-5) с шаблоном matchPattern — регулярным выражением, а не точной строкой. Удобно, пока имя совпадает с шаблоном: в трейсе видна не одна усреднённая сумма за диалог, а стоимость каждого шага пайплайна отдельно. Если self-hosted Langfuse ещё не развёрнут — установка на Ubuntu 24.04 в статье «Langfuse на Ubuntu 24.04: пошаговая установка», типовые сбои — в материале «Langfuse на сервере: частые ошибки и решения».

Свои модели и свои цены: self-hosted и нестандартные тарифы

У self-hosted моделей — vLLM, Ollama, llama.cpp с OpenAI-совместимым сервером — с токенами всё в порядке: оба в режиме /v1/chat/completions отдают usage в том же формате, что и OpenAI, — протокол общий. Проблема не в подсчёте, а в цене: у своей модели нет счёта от вендора, поэтому Langfuse либо не находит её в списке — имя вида Meta-Llama-3.1-8B-Instruct-Q4_K_M ни с одним шаблоном не совпадёт, — либо считает бесплатной.

Оба случая лечатся кастомной моделью — через UI проекта (Settings → Models) или через публичный API:

curl -s -X POST https://ваш-домен/api/public/models \
  -u "$LANGFUSE_PUBLIC_KEY:$LANGFUSE_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "modelName": "llama-3.1-8b-q4",
    "matchPattern": "(?i)^llama-3\\.1-8b.*
Развернуть за пару минут
Готовый образ на VPS MAATRIX: NVMe, AMD EPYC, root-доступ. Локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Развернуть Langfuse
Как Langfuse превращает usage в стоимость автоматически
Парсить usage вручную и складывать по моделям — работает для одного скрипта и разваливается, как только моделей и провайдеров становится больше одной. Langfuse решает это архитектурно: каждый вызов модели — объект generation внутри трейса с полями по каждому направлению — вход, выход, кэш, если он есть, и итог.
Официальные интеграции — обёртки для OpenAI и Anthropic SDK, callback-хендлер LangChain, встроенная поддержка LiteLLM — сами вытаскивают usage и передают в Langfuse, парсить руками не нужно. Если готовой интеграции нет — например, самописный запрос к нестандартному эндпоинту — usage можно передать в generation вручную: Langfuse найдёт цену по имени модели и посчитает стоимость сам.
Цену Langfuse ищет по встроенному списку моделей, сверяя имя из вызова (gpt-4o-mini, claude-sonnet-4-5) с шаблоном matchPattern — регулярным выражением, а не точной строкой. Удобно, пока имя совпадает с шаблоном: в трейсе видна не одна усреднённая сумма за диалог, а стоимость каждого шага пайплайна отдельно. Если self-hosted Langfuse ещё не развёрнут — установка на Ubuntu 24.04 в статье «Langfuse на Ubuntu 24.04: пошаговая установка», типовые сбои — в материале «Langfuse на сервере: частые ошибки и решения».
Свои модели и свои цены: self-hosted и нестандартные тарифы
У self-hosted моделей — vLLM, Ollama, llama.cpp с OpenAI-совместимым сервером — с токенами всё в порядке: оба в режиме /v1/chat/completions отдают usage в том же формате, что и OpenAI, — протокол общий. Проблема не в подсчёте, а в цене: у своей модели нет счёта от вендора, поэтому Langfuse либо не находит её в списке — имя вида Meta-Llama-3.1-8B-Instruct-Q4_K_M ни с одним шаблоном не совпадёт, — либо считает бесплатной.
Оба случая лечатся кастомной моделью — через UI проекта (Settings → Models) или через публичный API:
curl -s -X POST https://ваш-домен/api/public/models \
  -u "$LANGFUSE_PUBLIC_KEY:$LANGFUSE_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "modelName": "llama-3.1-8b-q4",
    "matchPattern": "(?i)^llama-3\\.1-8b.*$",
    "unit": "TOKENS",
    "inputPrice": 0.0000012,
    "outputPrice": 0.0000012,
    "tokenizerId": "openai"
  }'
Цену для собственной модели считайте не по прайс-листу — его нет, — а по амортизации: стоимость сервера в час, делённая на реально измеренную у вас пропускную способность в токенах в секунду для конкретной модели, квантования и размера батча:
цена за 1M токенов = (цена сервера в час / 3600 / токенов в секунду) × 1 000 000
Пропускную способность нельзя брать из чужого бенчмарка — она зависит от GPU, квантования, длины контекста и числа параллельных запросов настолько сильно, что чужая цифра для вашей связки бесполезна. Измерьте на своей машине под своей нагрузкой и подставьте своё число — тогда дашборд Langfuse покажет реальную амортизированную стоимость рядом со счетами от OpenAI и Anthropic, в одной валюте и на одном графике.
Отдельная ловушка — Azure OpenAI: имя развёрнутой модели там задаёт администратор (my-gpt4o-prod, а не gpt-4o), и штатный matchPattern Langfuse его не узнает — стоимость тихо считается нулевой, без единой ошибки в логах. Лечение то же, что для self-hosted: кастомная модель с шаблоном под реальное имя деплоя.
Разбивка расходов по пользователям, фичам и окружениям
Сумма за месяц полезна бухгалтеру, но не разработчику: чтобы понять, какую фичу пора оптимизировать или какому клиенту выставлять счёт, стоимость нужно резать по измерениям. В Langfuse для этого не нужна отдельная система — при создании трейса передаются userId, sessionId и tags (feature:rag, env:prod, plan:enterprise), и по каждому можно фильтровать и группировать стоимость в интерфейсе.
Для отчётов, которые нужно забрать из Langfuse наружу — в свою биллинговую систему или в таблицу для финансов, — есть публичный эндпоинт агрегатов по дням:
curl -s "https://ваш-домен/api/public/metrics/daily?userId=client-42&tags=feature:rag&fromTimestamp=2026-08-01" \
  -u "$LANGFUSE_PUBLIC_KEY:$LANGFUSE_SECRET_KEY" | jq
Ответ — массив дневных бакетов с суммарной стоимостью и разбивкой по моделям за каждый день диапазона: можно построить свой график расхода по клиенту без похода в UI или прицепить крон-скрипт, который раз в сутки складывает данные в свою базу для отчётности.
Если вы продаёте фичу с ИИ клиентам с разными тарифами, разбивка по userId показывает, какой клиент убыточен при плоской цене подписки, — раньше, чем это станет заметно по марже в целом. Тег feature: быстро показывает, что именно ест бюджет: эксперимент с длинным промптом для одной фичи или реально растущий трафик всего продукта.
Что Langfuse не сделает сам: бюджеты и жёсткие лимиты
Честный минус: Langfuse — инструмент наблюдения, а не контроля. Он покажет, сколько стоил вызов, но не остановит следующий запрос, даже если бюджет давно превышен, — жёсткого платёжного лимита в Langfuse нет, кнопки «выключить, если дороже X» тоже нет.
Жёсткая остановка — задача не наблюдателя, а шлюза перед моделью. Если запросы к провайдерам уже идут через LiteLLM, у виртуальных ключей там есть параметр max_budget, который реально блокирует запрос при превышении, а не просто логирует его:
curl -s -X POST http://127.0.0.1:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -d '{"models":["gpt-4o-mini"],"max_budget":25,"duration":"30d"}'
Свои траты LiteLLM тоже считает — в таблице LiteLLM_SpendLogs подключённой Postgres, по каждому запросу отдельной строкой. Отсюда приём: если оба инструмента в связке, суммы за один период в Langfuse и в LiteLLM_SpendLogs должны примерно совпадать. Заметная расходимость — сигнал, что в Langfuse какая-то модель не попала под matchPattern и считается бесплатной, хотя провайдер уже выставил за неё счёт. Разбор виртуальных ключей и master_key — в статье «LiteLLM не видит API-ключи: причины и решение».
Третий уровень защиты — сам провайдер: в консолях OpenAI и Anthropic можно выставить организационный лимит трат в месяц, после которого API начнёт отвечать ошибкой всем ключам сразу. Это грубее, чем max_budget на отдельный ключ, зато работает даже без шлюза между приложением и провайдером — последний рубеж, если сломались оба предыдущих.
Какой сервер и локацию в MAATRIX брать под учёт стоимости LLM-запросов
Обвязка для учёта стоимости — два процесса поверх вашего LLM-приложения: шлюз, если он есть, и Langfuse. Оба не считают модели, а принимают и хранят метаданные — требования к железу другие, чем у инференса: важнее память и диск под трейсы, чем ядра процессора.
Честный минимум, если Langfuse и шлюз стоят рядом на одной машине с приложением: 4 vCPU, 8–12 ГБ RAM, 60–80 ГБ NVMe. Хватает на self-hosted Langfuse — шесть контейнеров: web, worker, Postgres, ClickHouse, Redis, S3-хранилище — и лёгкий шлюз рядом. Минус называем прямо: при заметном потоке трейсов ClickHouse и Postgres начинают конкурировать за память, и всплеск нагрузки рискует закончиться перезапуском по OOM — для теста и небольшой команды нормально, для боевого продукта с активным трафиком уже тесно.
Комфортный вариант — развести по разным машинам: Langfuse на 8 vCPU / 16–32 ГБ / 150–200 ГБ NVMe, шлюз отдельно на 2–4 vCPU / 4–8 ГБ. Точный расчёт памяти под конкретный трафик — отдельная тема, разобрана в статье «Сколько RAM нужно для Langfuse». Разнесение даёт независимые перезапуски: обновление шлюза не роняет историю трейсов, а миграция ClickHouse не блокирует трафик.
Локация — Великобритания, Лондон. Сразу закроем вопрос, который возникает первым: на цену за токен у OpenAI или Anthropic локация сервера не влияет — это тариф провайдера, а не хостинга. Локация решает юрисдикцию и задержку. В трейсах Langfuse оседают промпты, ответы модели и любые персональные данные пользователей, которые в них попали; держать эту копию рядом с GDPR — разумная позиция для команды на европейскую аудиторию. Задержка касается не самих вызовов модели, а батчей телеметрии от SDK до Langfuse — при активном трафике их много, и короткий RTT до Европы держит дашборд отзывчивым. Российская локация здесь не подходит по той же причине, что и для остальных ИИ-инструментов: вызовы к OpenAI, Anthropic и Google с российских адресов отбиваются по региону.
Всё перечисленное можно не собирать руками: Langfuse и LiteLLM есть в каталоге apps.maatrix.io и ставятся автоматически при заказе — команды из этой статьи не нужны, автоустановка работает на Ubuntu и на Debian, а адрес панели и ключи доступа появляются в личном кабинете, в разделе «Доступ». Конфигурацию под свой трафик — на странице аренды VPS. Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT: иностранная карта не нужна, хотя сервер стоит в Лондоне.
Развернуть за пару минут
Готовый образ на VPS MAATRIX: NVMe, AMD EPYC, root-доступ. Локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Развернуть Langfuse
Нужны сами нейросети для контента?
Генерируйте изображения, видео и озвучку нейросетями на falapi.io — десятки моделей в одном окне. Оплата картой РФ и по СБП.
Изображения и ВидеоАудио и звукИИ MAAT — Собеседник
quot;,
    "unit": "TOKENS",
    "inputPrice": 0.0000012,
    "outputPrice": 0.0000012,
    "tokenizerId": "openai"
  }'

Цену для собственной модели считайте не по прайс-листу — его нет, — а по амортизации: стоимость сервера в час, делённая на реально измеренную у вас пропускную способность в токенах в секунду для конкретной модели, квантования и размера батча:

цена за 1M токенов = (цена сервера в час / 3600 / токенов в секунду) × 1 000 000

Пропускную способность нельзя брать из чужого бенчмарка — она зависит от GPU, квантования, длины контекста и числа параллельных запросов настолько сильно, что чужая цифра для вашей связки бесполезна. Измерьте на своей машине под своей нагрузкой и подставьте своё число — тогда дашборд Langfuse покажет реальную амортизированную стоимость рядом со счетами от OpenAI и Anthropic, в одной валюте и на одном графике.

Отдельная ловушка — Azure OpenAI: имя развёрнутой модели там задаёт администратор (my-gpt4o-prod, а не gpt-4o), и штатный matchPattern Langfuse его не узнает — стоимость тихо считается нулевой, без единой ошибки в логах. Лечение то же, что для self-hosted: кастомная модель с шаблоном под реальное имя деплоя.

Разбивка расходов по пользователям, фичам и окружениям

Сумма за месяц полезна бухгалтеру, но не разработчику: чтобы понять, какую фичу пора оптимизировать или какому клиенту выставлять счёт, стоимость нужно резать по измерениям. В Langfuse для этого не нужна отдельная система — при создании трейса передаются userId, sessionId и tags (feature:rag, env:prod, plan:enterprise), и по каждому можно фильтровать и группировать стоимость в интерфейсе.

Для отчётов, которые нужно забрать из Langfuse наружу — в свою биллинговую систему или в таблицу для финансов, — есть публичный эндпоинт агрегатов по дням:

curl -s "https://ваш-домен/api/public/metrics/daily?userId=client-42&tags=feature:rag&fromTimestamp=2026-08-01" \
  -u "$LANGFUSE_PUBLIC_KEY:$LANGFUSE_SECRET_KEY" | jq

Ответ — массив дневных бакетов с суммарной стоимостью и разбивкой по моделям за каждый день диапазона: можно построить свой график расхода по клиенту без похода в UI или прицепить крон-скрипт, который раз в сутки складывает данные в свою базу для отчётности.

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

Что Langfuse не сделает сам: бюджеты и жёсткие лимиты

Честный минус: Langfuse — инструмент наблюдения, а не контроля. Он покажет, сколько стоил вызов, но не остановит следующий запрос, даже если бюджет давно превышен, — жёсткого платёжного лимита в Langfuse нет, кнопки «выключить, если дороже X» тоже нет.

Жёсткая остановка — задача не наблюдателя, а шлюза перед моделью. Если запросы к провайдерам уже идут через LiteLLM, у виртуальных ключей там есть параметр max_budget, который реально блокирует запрос при превышении, а не просто логирует его:

curl -s -X POST http://127.0.0.1:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -d '{"models":["gpt-4o-mini"],"max_budget":25,"duration":"30d"}'

Свои траты LiteLLM тоже считает — в таблице LiteLLM_SpendLogs подключённой Postgres, по каждому запросу отдельной строкой. Отсюда приём: если оба инструмента в связке, суммы за один период в Langfuse и в LiteLLM_SpendLogs должны примерно совпадать. Заметная расходимость — сигнал, что в Langfuse какая-то модель не попала под matchPattern и считается бесплатной, хотя провайдер уже выставил за неё счёт. Разбор виртуальных ключей и master_key — в статье «LiteLLM не видит API-ключи: причины и решение».

Третий уровень защиты — сам провайдер: в консолях OpenAI и Anthropic можно выставить организационный лимит трат в месяц, после которого API начнёт отвечать ошибкой всем ключам сразу. Это грубее, чем max_budget на отдельный ключ, зато работает даже без шлюза между приложением и провайдером — последний рубеж, если сломались оба предыдущих.

Какой сервер и локацию в MAATRIX брать под учёт стоимости LLM-запросов

Обвязка для учёта стоимости — два процесса поверх вашего LLM-приложения: шлюз, если он есть, и Langfuse. Оба не считают модели, а принимают и хранят метаданные — требования к железу другие, чем у инференса: важнее память и диск под трейсы, чем ядра процессора.

Честный минимум, если Langfuse и шлюз стоят рядом на одной машине с приложением: 4 vCPU, 8–12 ГБ RAM, 60–80 ГБ NVMe. Хватает на self-hosted Langfuse — шесть контейнеров: web, worker, Postgres, ClickHouse, Redis, S3-хранилище — и лёгкий шлюз рядом. Минус называем прямо: при заметном потоке трейсов ClickHouse и Postgres начинают конкурировать за память, и всплеск нагрузки рискует закончиться перезапуском по OOM — для теста и небольшой команды нормально, для боевого продукта с активным трафиком уже тесно.

Комфортный вариант — развести по разным машинам: Langfuse на 8 vCPU / 16–32 ГБ / 150–200 ГБ NVMe, шлюз отдельно на 2–4 vCPU / 4–8 ГБ. Точный расчёт памяти под конкретный трафик — отдельная тема, разобрана в статье «Сколько RAM нужно для Langfuse». Разнесение даёт независимые перезапуски: обновление шлюза не роняет историю трейсов, а миграция ClickHouse не блокирует трафик.

Локация — Великобритания, Лондон. Сразу закроем вопрос, который возникает первым: на цену за токен у OpenAI или Anthropic локация сервера не влияет — это тариф провайдера, а не хостинга. Локация решает юрисдикцию и задержку. В трейсах Langfuse оседают промпты, ответы модели и любые персональные данные пользователей, которые в них попали; держать эту копию рядом с GDPR — разумная позиция для команды на европейскую аудиторию. Задержка касается не самих вызовов модели, а батчей телеметрии от SDK до Langfuse — при активном трафике их много, и короткий RTT до Европы держит дашборд отзывчивым. Российская локация здесь не подходит по той же причине, что и для остальных ИИ-инструментов: вызовы к OpenAI, Anthropic и Google с российских адресов отбиваются по региону.

Всё перечисленное можно не собирать руками: Langfuse и LiteLLM есть в каталоге apps.maatrix.io и ставятся автоматически при заказе — команды из этой статьи не нужны, автоустановка работает на Ubuntu и на Debian, а адрес панели и ключи доступа появляются в личном кабинете, в разделе «Доступ». Конфигурацию под свой трафик — на странице аренды VPS. Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT: иностранная карта не нужна, хотя сервер стоит в Лондоне.

Частые вопросы