Как не сжечь бюджет на ИИ: учет токенов для команды
Расходы на ИИ неприятно удивляют не в первый день. Сначала кажется, что команда просто купила подписки или добавила API к нескольким задачам. Потом сотрудники начинают запускать исследования, агенты читают длинные файлы, черновики переписываются по пять раз, проверки идут отдельными запросами, и внезапно бюджет становится похож на счетчик такси.
Проблема не в самих токенах. Проблема в том, что команда считает ИИ как "доступ к модели", хотя в реальности платит за повторяемую работу: входные данные, выходной текст, вызовы инструментов, повторные проверки, память, кэш и ошибки процесса.
Что произошло
В теме из discovery-архива был хороший сигнал: в компаниях растет использование ИИ, а вместе с ним возникает вопрос для финансового директора и руководителя продукта - какую долю бюджета можно тратить на модели и как не потерять контроль. Это не про трейдинг, не про токены криптовалют и не про инвестиции. Это про обычную операционную экономику ИИ-систем.
Официальные страницы OpenAI API pricing, Anthropic API pricing и Google Vertex AI pricing показывают одну общую вещь: цена зависит не только от "какая модель", но и от типа входа, выхода, кэша, батчевого режима, мультимодальности и объема. Поэтому вопрос "сколько стоит ИИ" слишком грубый. Правильнее спрашивать: "сколько стоит выполнить эту работу таким способом".
Почему подписки больше не объясняют бюджет
Подписка удобна для человека: платишь фиксированную сумму и работаешь. Но как только компания строит процессы на API, агентах и автоматических проверках, бюджет становится переменным. Один сотрудник может запускать короткие ответы, другой - глубокие исследования с длинными документами, третий - агента, который делает десятки промежуточных шагов.
У ИИ-расходов есть четыре видимые части:
| Часть расхода | Что это значит | Как снизить без потери качества |
|---|---|---|
| Входные данные | Сколько текста, файлов и истории модель читает | Давать только нужные фрагменты, чистить повтор, использовать поиск |
| Выходной текст | Сколько модель пишет в ответ | Просить короткий формат, таблицу, JSON или черновик нужной длины |
| Повторные запуски | Сколько раз задача переделывается | Улучшать входы, чеклист качества и тестовые примеры |
| Дорогая модель | Какая модель выполняет шаг | Делить задачу: простое дешевой модели, критичное сильной |
Это похоже на облачную экономику. Поэтому методология FinOps полезна как аналогия: расходы должны быть видимыми, привязанными к владельцам и оптимизироваться через поведение команды, а не только через запрет сверху.
Метод: считать стоимость задачи
Самый полезный переход - перестать считать "сколько мы тратим на ИИ" и начать считать "сколько стоит типовая задача". Например: один анализ договора, одна карточка клиента, одна публикация, один отчет, один ответ поддержки, один поиск по базе знаний.
Если задача стоит 20 рублей и экономит 20 минут специалиста, это может быть прекрасно. Если она стоит 500 рублей, а заменяет две минуты ручной работы, значит процесс спроектирован плохо. Но это видно только при учете на уровне сценария.
Rich block render error: mapping values are not allowed here
in "<unicode string>", line 3, column 53:
... пользование ИИ", а один сценарий: проверка письма, анализ догово ...
^
items:
- title: Выберите повторяемую задачу
body: Не "все использование ИИ", а один сценарий: проверка письма, анализ договора, резюме созвона, подготовка статьи, поиск по базе.
- title: Разделите шаги
body: Что читает модель, что пишет, какие проверки делает, где вызывает инструменты и где повторяет запрос.
- title: Назначьте модель на каждый шаг
body: Сильная модель нужна не всегда. Классификация, форматирование и простая проверка часто могут идти дешевле.
- title: Включите кэш и батчи там, где это уместно
body: Повторяемые системные инструкции, справочники и большие документы не должны каждый раз оплачиваться как новые.
- title: Поставьте лимит и остановку
body: У задачи должен быть максимум попыток, максимум длины и условие, когда нужно спросить человека.Рабочая карточка
Где нельзя экономить
Экономия на ИИ не должна ломать качество. Нельзя просто заменить сильную модель слабой в юридически важной проверке, медицинском тексте, финансовом решении или публичной публикации без отдельной проверки. Иногда дорогой шаг нужен, потому что цена ошибки выше цены токенов.
Правильная экономия выглядит иначе. Сначала убрать мусор из входа. Потом не просить длинный ответ, если нужна таблица. Потом разделить задачу на простой черновик и сильную проверку. Потом использовать кэш для повторяющихся инструкций и документов. И только после этого спорить о модели.
Rich block render error: mapping values are not allowed here
in "<unicode string>", line 2, column 100:
... ель. Он управляется картой задач: где нужен сильный интеллект, г ...
^
label: Редакционный вывод
body: Бюджет на ИИ управляется не запретом и не верой в дешевую модель. Он управляется картой задач: где нужен сильный интеллект, где нужен дешевый шаг, где нужен кэш, а где задача вообще не должна запускаться автоматически.Что сделать сегодня
Возьмите три повторяемых ИИ-сценария в команде и заведите простую таблицу: задача, владелец, входные данные, модель, среднее число запусков, длина ответа, проверка, стоимость одного результата, польза для бизнеса. Уже через неделю станет видно, где ИИ действительно помогает, а где просто незаметно сжигает бюджет.
Связка с предыдущей статьей про ИИ-зрелость компании прямая: зрелость начинается тогда, когда компания видит не только красивый результат, но и стоимость маршрута, который к нему приводит.