Model costs в n8n: как считать стоимость AI workflow и не получить неожиданный счёт ¶

Обновлено: 2026-05-29

Короткий ответ ¶

Model costs в n8n нужно считать не “после получения счёта”, а внутри workflow: какая модель вызвана, сколько было входного и выходного контекста, сколько retries, сколько документов добавил RAG, была ли cache hit, какой user или процесс запустил execution и какой бизнес-результат получен. Главные причины перерасхода — loops, длинная история чата, слишком большие chunks, дорогая модель для простой классификации, повторные repair-chain и массовый запуск без лимитов.

Почему расходы растут незаметно ¶

AI workflow выглядит дешёвым на тестах: один email, один вопрос, один ответ. В production входов становится тысяча, появляются retries, attachments, длинные цепочки, RAG, memory, tool calls и несколько LLM nodes в одном execution. Стоимость растёт не линейно с “числом пользователей”, а с количеством токенов, повторов, веток и ошибок.

Например, email triage может выглядеть так: классификация → extraction → draft reply → safety check → translation. Это уже пять AI-вызовов. Если первый node ошибся и запускает repair, стало шесть. Если RAG добавил десять длинных документов, вырос входной контекст. Если workflow повторяется три раза из-за API timeout, стоимость утраивается.

Что логировать для cost control ¶

Минимальный cost log:

{
  "trace_id": "ai_cost_2026_05_29_001",
  "workflow_id": "support_triage",
  "execution_id": "12345",
  "user_id": "u_1021",
  "task_type": "classification",
  "model": "configured_model",
  "prompt_version": "triage_v5",
  "input_tokens_est": 2100,
  "output_tokens_est": 320,
  "retry_count": 0,
  "rag_chunks": 4,
  "cache_status": "miss",
  "decision": "auto_route",
  "business_result": "ticket_created"
}

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

Основные драйверы стоимости ¶

Model routing ¶

Не все задачи требуют самой сильной модели. Разделите tasks:

• простая классификация: дешёвая и быстрая модель;
• извлечение структурированных полей: модель со стабильным JSON;
• сложный reasoning: более сильная модель;
• risky answer: сильная модель + review;
• черновик письма: средняя модель + human edit;
• финальное действие: не модель, а code/business rules.

Пример routing logic:

const task = $json.task_type;
const risk = $json.risk_level;
const textLength = ($json.text || '').length;

let modelTier = 'small';
if (risk === 'high') modelTier = 'strong';
if (task === 'legal_summary') modelTier = 'strong';
if (textLength > 12000) modelTier = 'context_optimized';
if (task === 'faq_lookup' && $json.cache_hit) modelTier = 'none';

return [{ json: { ...$json, model_tier: modelTier } }];

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

AI cache ¶

Кеш снижает расходы, если запросы повторяются: FAQ, справочные ответы, классификация одинаковых шаблонов, retrieval для одинакового вопроса. Но кеш опасен, если ответ зависит от свежих данных, роли пользователя, персонального контекста или политики доступа.

Ключ кеша должен учитывать:

• normalized user question;
• language;
• role/access scope;
• prompt_version;
• model_tier;
• source_index_version;
• important filters.

Пример ключа:

const crypto = require('crypto');
const payload = {
  question: ($json.question || '').trim().toLowerCase(),
  lang: $json.lang || 'ru',
  role: $json.role || 'public',
  prompt_version: 'faq_v4',
  index_version: $json.index_version || 'kb_2026_05'
};
const key = crypto.createHash('sha256').update(JSON.stringify(payload)).digest('hex');
return [{ json: { ...$json, cache_key: key } }];

Не кешируйте ответы с PII без отдельной политики хранения.

RAG cost control ¶

RAG часто становится скрытым источником расходов. Пользователь задаёт короткий вопрос, а workflow добавляет в prompt 8 документов по 1500 токенов. Стоимость и latency растут, качество не всегда улучшается.

Оптимизация:

1. сначала классифицируйте, нужен ли RAG вообще;
2. используйте metadata filters;
3. ограничивайте top-k;
4. режьте chunks до полезного размера;
5. добавляйте source snippets, а не целые документы;
6. делайте no-answer, если источники слабые;
7. логируйте rag_chunks, retrieval_score, source_ids.

Бюджеты и алерты ¶

Задайте бюджеты по уровням:

В n8n это можно собрать через Postgres/Redis counter: перед AI node проверять лимит, после вызова записывать usage. При превышении — fallback: короткий ответ, human queue или отложенная обработка.

Как расследовать cost spike ¶

Если расходы выросли, не начинайте с “сменим модель”. Проверьте:

• какой workflow дал рост;
• какие task_type подорожали;
• вырос ли input context;
• увеличились ли retries;
• нет ли loop по items;
• не изменился ли prompt_version;
• не добавился ли RAG без фильтров;
• не сломался ли cache;
• нет ли abuse от одного user/session.

Добавьте runbook: freeze risky workflow, включить lower-cost mode, уменьшить top-k, отключить repair-chain, поставить rate limit, уведомить владельца процесса.

Метрики эффективности ¶

Стоимость без качества бессмысленна. Смотрите не только “сколько потратили”, но и “что получили”:

• cost per resolved ticket;
• cost per qualified lead;
• cost per successful extraction;
• cost per human-approved action;
• cost per avoided manual minute;
• cache hit rate;
• retry rate;
• review rate;
• invalid JSON rate.

Если дешёвая модель снижает качество и увеличивает review, итоговая стоимость может вырасти.

FAQ ¶

Почему AI workflow внезапно становится дорогим?
Чаще всего из-за бесконечных loops, повторов после ошибок, слишком больших RAG chunks, длинной истории чата, тяжёлой модели для простой задачи или массового запуска без лимита.

Нужно ли считать стоимость в n8n вручную?
Лучше считать хотя бы приблизительно: входные токены, выходные токены, модель, retries, retrieval size, user_id, workflow_id и business outcome. Это позволяет видеть дорогие ветки.

Что эффективнее снижает расходы?
Сначала routing дешёвая/дорогая модель, затем cache повторных запросов, сокращение контекста, batch limits, no-answer policy и запрет retries без изменения входа.

Можно ли кешировать AI-ответы?
Да, если вход не содержит персональные данные или sensitive context, а ответ не зависит от свежих данных. Для RAG кешируйте retrieval и короткие FAQ-ответы с TTL.

Когда дорогая модель оправдана?
Когда ошибка стоит дороже стоимости запроса: юридический текст, сложная классификация, важный клиент, высокий чек, production incident или ответ с внешними последствиями.