Когда начинаешь считать стоимость ИИ-автоматизации, первым делом почему-то открывают прайс нейросети.
Сколько стоит миллион токенов? Сколько запросов будет в месяц? Можно ли вместо дорогой модели взять что-нибудь подешевле?
Логика понятная. У API есть цена, её легко увидеть и умножить на предполагаемое количество запросов. Получается аккуратная цифра, которую можно вставить в Excel.
А потом автоматизацию запускают в реальный бизнес — и выясняется, что токены были одной из самых маленьких проблем.
Сегодня OpenAI, например, продаёт GPT-5.6 Luna по $0,20 за миллион входных и $1,20 за миллион выходных токенов, Terra — по $2 и $12, а Sol — по $4 и $20 соответственно. Даже достаточно большой запрос на 10 тысяч входных и две тысячи выходных токенов к Sol обойдётся примерно в восемь центов.
Восемь центов.
А теперь попробуйте за восемь центов понять, почему ИИ третий раз подряд создал клиента не в той воронке CRM.
Вот здесь начинается настоящая экономика автоматизации.
У токенов есть одно огромное преимущество: их очень легко посчитать
Допустим, у компании тысяча обращений в месяц. На каждое обращение нейросеть получает историю переписки, карточку клиента и несколько инструкций, а затем пишет ответ.
Можно оценить средний объём контекста, среднюю длину ответа, умножить всё на тысячу и получить стоимость модели.
Прекрасно.
Только реальная система обычно выглядит не так:
запрос → нейросеть → ответ.
Она выглядит примерно так:
пришло сообщение → нашли клиента → загрузили историю → определили намерение → проверили данные → вызвали модель → получили результат → проверили результат → записали в CRM → отправили сообщение → обновили статус → поставили задачу → записали лог.
И любой из этих шагов может однажды решить, что сегодня он работать не хочет.
Самая дорогая часть начинается ещё до первого запроса к модели
Представим компанию, которая хочет автоматизировать продажи.
Формулировка владельца:
Давайте нейросеть будет отвечать на заявки.
Звучит как задача минут на двадцать.
Потом начинаются вопросы. Откуда приходят заявки? Что считается новой заявкой? Если человек уже есть в CRM, создавать нового нельзя? Кто обслуживает повторного клиента? Какие цены можно называть? Какие скидки разрешены? Когда передавать менеджеру? Что делать вечером? А если клиент пишет не о покупке, а с претензией?
Через час выясняется, что главная задача состоит вовсе не в написании промпта.
Нужно сначала описать сам бизнес-процесс.
И иногда это неприятное открытие. Оказывается, процесса как такового нет: три менеджера работают тремя разными способами, а четвёртый «просто чувствует клиента».
Нейросеть такое обожает.
Особенно слово «просто».
Автоматизация очень быстро обнаруживает весь накопленный бардак
Человек великолепно умеет чинить плохую систему собственным здравым смыслом.
В CRM два одинаковых клиента?
Менеджер понимает, какой настоящий.
Телефон записан в поле комментария?
Увидел.
Цена на сайте старая?
Сотрудник знает актуальную.
Клиент написал с другого номера?
Узнал по имени.
Для программной системы всё это не «понятно».
Это данные.
И если данные плохие, ИИ не превращает их магически в хорошие. Иногда он просто начинает гораздо быстрее распространять исходный бардак по всей системе.
Поэтому перед серьёзной автоматизацией приходится чистить справочники, приводить в порядок статусы, определять источники истины и разбираться, какая из пяти таблиц наконец считается правильной.
Токены в это время стоят примерно ноль.
Работа уже идёт.
Потом выясняется, что API существуют не в идеальном мире
На презентации интеграция выглядит так:
подключаем CRM.
В реальности:
CRM отдаёт одно поле в таком формате, другое — только отдельным запросом, третье вообще недоступно через этот метод, а нужное событие webhook почему-то отправляет не всегда.
Почта имеет свои ограничения.
Мессенджер — свои.
Календарь — свои.
Авторизация истекает.
Сервис обновляет API.
У пользователя исчезают права.
Один внешний провайдер отвечает пять секунд, второй иногда сорок, третий возвращает ошибку 429.
Сам искусственный интеллект может в этот момент работать идеально.
Автоматизация всё равно лежит.
Именно поэтому рабочий агент — это не «нейросеть плюс три API»
Anthropic в своём руководстве по агентам описывает их как системы, где модель работает в цикле: получает информацию из среды, выбирает инструмент, выполняет действие, смотрит на результат и только после этого решает, что делать дальше. Компания отдельно подчёркивает, что у автономных агентов выше стоимость и существует риск накопления ошибок между шагами.
Это очень важный момент.
Если обычный чат сделал один неудачный ответ, мы получили одну ошибку.
Если агент ошибся на первом шаге и на основании этой ошибки сделал ещё семь вполне логичных действий, мы получили маленькую производственную катастрофу.
А значит, приходится строить контроль.
И вот контроль тоже почему-то не бесплатный.
Допустим, нейросеть работает правильно в 97 случаях из 100
На демонстрации это великолепный результат.
В бизнесе всё зависит от задачи.
Если она определяет тему входящего письма, три ошибки из ста могут быть терпимы.
Если переводит деньги — уже нет.
Если тысяча заявок в день, три процента означают тридцать проблем ежедневно. Кто-то должен их находить, исправлять и разбираться, почему они вообще появились.
Поэтому вопрос:
Насколько точная модель?
сам по себе почти бесполезен.
Нужен другой:
Сколько стоит её ошибка именно здесь?
И стоимость ошибки иногда намного выше стоимости всей нейросети
Представим ИИ-продавца.
За месяц он обработал десять тысяч сообщений. На API ушло, условно, $80.
Красота.
Только один раз система решила, что клиент уже получил коммерческое предложение, хотя менеджер его ещё не отправлял. Клиенту никто не ответил двое суток, и сделка на 300 тысяч рублей ушла конкуренту.
Модель за весь месяц:
$80.
Одна ошибка:
300 000 ₽ потенциальной выручки.
После этого обсуждение, можно ли сэкономить двадцать долларов на токенах, слегка теряет драматизм.
Именно поэтому нормальная экономика AI должна учитывать не только cost per request, но и cost of failure.
Потом появляется human-in-the-loop
Очень красивое английское выражение.
На русский переводится примерно так:
Тут пока всё-таки нужен человек.
😁
Например, ИИ самостоятельно отвечает на типовые вопросы, но договор отправляет только после подтверждения сотрудника. Или создаёт черновик платежа, но не проводит его. Или определяет, что ситуация нестандартная, и передаёт диалог менеджеру.
Так безопаснее.
Но теперь появляется стоимость человеческой проверки.
Если сотрудник должен просмотреть каждый второй результат, возможно, автоматизация вообще не особенно автоматизировала работу.
Поэтому хороший проект постепенно ищет баланс: какие действия можно полностью отдать машине, где достаточно выборочного контроля, а где человек остаётся обязательным.
И этот баланс редко удаётся угадать до запуска.
Вот зачем нужны тесты на реальных случаях
Можно написать прекрасный системный промпт.
Потом придумать десять тестовых запросов.
Модель отвечает идеально.
Запускаем.
Первый настоящий клиент:
Здравствуйте, мы у вас в 2019 ставили котёл бабушке, сейчас дом продали брату, гарантия вроде была на маму, но платил я. Хотим такой же, только не такой.
Вот и тестирование началось.
😁
Реальные пользователи обладают практически бесконечной способностью формулировать ситуацию способом, которого разработчик не предусмотрел.
Поэтому производственная AI-система требует набора evals — проверок на типовых, редких, опасных и пограничных сценариях. OpenAI сейчас прямо относит evals, observability, guardrails, reliability и оптимизацию стоимости к отдельному этапу перевода API-приложения из прототипа в production.
То есть:
работает у меня на ноутбуке
и
работает в компании
— две разные стадии разработки.
И набор тестов никогда не заканчивается
Это особенно весёлая часть.
Нашли новую ошибку.
Допустим, клиент написал:
Спасибо, пока не надо.
А система почему-то классифицировала это как:
клиент согласен на встречу.
Исправили.
После этого правильный подход выглядит так: добавляем этот случай в постоянный тестовый набор.
Потом следующий.
Через полгода у нормальной системы уже сотни или тысячи примеров, которые прогоняются при изменении промпта, модели или логики.
Потому что исправить сегодняшнюю проблему и случайно вернуть три вчерашних — вполне обычный способ разработки.
Модель тоже не высечена в граните
Поставщик выпускает новую версию.
Старая дешевеет.
Новую хочется попробовать.
Или старая вообще перестаёт поддерживаться.
На тестах новая модель вроде умнее, но неожиданно по-другому трактует один инструмент. Или пишет в два раза длиннее. Или стала чаще задавать уточняющие вопросы. Или лучше рассуждает, но медленнее отвечает.
Поэтому заменить:
model=A
на:
model=B
не всегда означает обновление одной строки.
Нужно снова прогнать реальные сценарии.
И опять появляется работа, которая не отображается в строке «API usage».
Причём самая дорогая модель далеко не всегда самая дорогая система
Это один из любимых парадоксов.
Предположим, модель А стоит в десять раз дешевле модели Б.
А делает задачу хуже.
Поэтому после неё нужен дополнительный классификатор, второй запрос на проверку и иногда повторная генерация.
В итоге один бизнес-процесс использует четыре дешёвых вызова вместо одного дорогого.
OpenAI отдельно предупреждает, что сравнивать только цену миллиона токенов неправильно: разные модели используют разный объём токенов и могут потребовать разное количество работы для завершения задачи. Считать нужно стоимость результата, а не прайс одной операции.
Иногда дорогая модель дешевле.
Потому что с первого раза сделала нормально.
А иногда наоборот — мы вызываем профессора, чтобы рассортировать носки
Вот это тоже постоянная ошибка.
Нужно определить:
сообщение относится к продаже, поддержке или спаму?
И разработчик отправляет запрос самой мощной reasoning-модели.
Зачем?
Это как позвать академика на склад:
Николай Петрович, эта коробка синяя или красная?
Для огромного количества вспомогательных задач достаточно маленьких моделей. Именно поэтому нынешние линейки поставщиков специально имеют разные уровни цены и мощности: OpenAI, например, разделяет Sol, Terra и Luna, а Anthropic аналогично предлагает разные классы Claude с различной стоимостью.
Хорошая архитектура не выбирает:
какая модель лучшая?
Она выбирает:
какая минимально достаточная модель нужна на этом конкретном шаге?
Вот здесь токены действительно можно экономить сильно.
Но сначала надо увидеть, куда они вообще уходят
У нормальной автоматизации есть телеметрия.
Сколько запросов.
Какие модели.
Средний контекст.
Сколько повторов.
Сколько ошибок.
Какой инструмент вызывается чаще.
Где растёт latency.
Какой сценарий внезапно начал сжигать в пять раз больше токенов.
OpenAI предоставляет отдельный Usage Dashboard и данные использования непосредственно в API-ответах именно для такого контроля.
Без наблюдаемости система работает примерно так:
Денег стало уходить больше.
— Почему?
Искусственный интеллект.
Очень содержательный финансовый отчёт.
Большой скрытый пожиратель денег — контекст
С моделью хочется поделиться всем.
Вот история клиента за два года.
Вот каталог.
Вот инструкция на 70 страниц.
Вот переписка.
Вот политика компании.
Вот ещё вся CRM, вдруг пригодится.
Модель получает огромный запрос.
Большая часть информации ей вообще не нужна.
Мы платим не только деньгами. Увеличивается задержка, возрастает вероятность потерять важную деталь среди мусора, а система становится сложнее для отладки.
Поэтому хороший AI-проект довольно быстро приходит к совершенно скучной инженерной задаче:
давать модели только тот контекст, который нужен сейчас.
И это часто экономит больше, чем охота за моделью на десять процентов дешевле.
Кэширование может дать ещё один огромный выигрыш
Во многих системах большая часть входного контекста повторяется.
Например, системная инструкция на 20 тысяч токенов одна и та же для каждого клиента.
Зачем каждый раз обрабатывать её как новый ввод?
Современные API предлагают prompt caching, при котором повторяющаяся часть контекста стоит заметно дешевле. У OpenAI cached input для текущих моделей тарифицируется отдельно, Anthropic тоже имеет собственные цены на запись и повторное использование кэша.
Но, опять же, чтобы этим нормально воспользоваться, надо сначала построить архитектуру.
Сама экономия появляется после работы инженера, а не вместо неё.
Ещё есть серверы, базы, очереди и вся скучная часть, про которую AI-стартапы не любят рассказывать
Если система работает раз в неделю — можно почти ничего не строить.
Если она обслуживает бизнес постоянно, появляются:
база данных;
очередь задач;
хранилище файлов;
логирование;
мониторинг;
резервные копии;
авторизация;
секреты;
повторные попытки;
таймауты.
Можно собрать всё на SaaS-сервисах.
Тогда платим подписки.
Можно держать самостоятельно.
Тогда платим серверы и человека, который однажды ночью будет выяснять:
почему Redis умер.
Удивительно, но слово «нейросеть» эту часть инфраструктуры не отменяет.
Она просто добавляется сверху.
Голос и изображения вообще считаются отдельно
Текстовые токены — только часть AI-экономики.
Если агент разговаривает по телефону, появляются распознавание речи и синтез голоса. Если обрабатывает изображения — другой тип вычислений. Если ищет в интернете — могут быть отдельные запросы к поисковым API. Если использует браузер — возрастает время выполнения и количество шагов.
Один простой пользовательский запрос способен внутри системы породить десяток оплачиваемых операций.
Поэтому считать:
одно сообщение = один запрос к модели
можно только на самой ранней салфетке с бизнес-планом.
В реальности лучше считать полный workflow.
И самое неприятное — поддержка после запуска
Допустим, систему сделали.
Запустили.
Все счастливы.
Проходит месяц.
CRM обновилась.
Через неделю появился новый продукт.
Потом отдел продаж изменил стадии сделки.
Маркетологи запустили новую акцию.
Юристы поменяли формулировку договора.
Мессенджер изменил API.
Компания добавила второй филиал.
AI-автоматизация живёт внутри бизнеса, а бизнес постоянно меняется.
Значит, система тоже должна меняться.
Именно поэтому стоимость разработки один раз почти всегда вводит в заблуждение. Нужна стоимость владения.
Иногда самый дорогой компонент — специалист, который знает, как всё это работает
Представим прекрасную автоматизацию, которую написал один разработчик.
Документации нет.
Через год он ушёл.
Сервис сломался.
Новый специалист открывает код.
Смотрит.
Закрывает.
Звонит предыдущему разработчику.
😁
Нормальный production-проект требует документации, понятной архитектуры, конфигурации, версионирования промптов, журналов и возможности восстановить логику спустя месяцы.
Это всё человеко-часы.
Именно они обычно стоят намного дороже токенов.
Тогда почему вокруг API-цен столько разговоров?
Потому что эту цифру видно.
Она простая.
$4 за миллион токенов.
Понятно.
А сколько стоит:
нормально продумать обработку исключений?
Нет универсального прайса.
Сколько:
добиться, чтобы агент правильно передавал нестандартного клиента менеджеру?
Зависит.
Сколько:
интегрировать две старые системы, документацию к которым последний раз обновляли при Медведеве?
Не спрашивайте.
Поэтому внимание автоматически цепляется за единственную красивую цифру.
А реальный бюджет находится в менее красивых строках.
Есть хорошая аналогия с автомобилем
Человек спрашивает:
Сколько стоит ездить?
И ему отвечают:
Бензин — 60 рублей литр.
Технически ответ связан с вопросом.
Но есть ещё:
сама машина;
страховка;
обслуживание;
резина;
ремонт;
налоги;
парковка;
амортизация.
Токены в AI-автоматизации — примерно бензин.
Очень важны, если система работает в огромном масштабе. Но совершенно недостаточны, чтобы оценить стоимость всей машины.
При большом объёме токены, конечно, снова становятся серьёзными
Если у компании сто запросов в день — можно почти не думать.
Если сто миллионов — ситуация другая.
Там снижение стоимости inference на несколько процентов превращается в огромные деньги. Появляются batch processing, кэширование, специальные тарифы производительности и оптимизация инфраструктуры.
OpenAI сейчас даже отдельно предлагает разные режимы обработки для случаев, где важнее скорость, цена или гарантированная пропускная способность.
Но это экономика масштаба.
Большинство компаний до неё ещё сначала должно дожить.
Для малого и среднего бизнеса я бы вообще начинал расчёт не с токенов
Первый вопрос:
Что сейчас стоит существующий процесс?
Например, заявки вручную обрабатывают два менеджера.
Следующий:
какую часть процесса реально можно убрать или ускорить?
Допустим, AI способен самостоятельно обработать первичное обращение, собрать данные и передать квалифицированного клиента человеку.
Тогда считаем экономический эффект.
Сколько времени освободилось?
Сколько заявок перестали теряться ночью?
Сколько клиентов получили ответ быстрее?
Сколько дополнительных диалогов способен вести тот же отдел?
И только потом сравниваем с полной стоимостью системы.
Не:
нейросеть стоит 3000 рублей в месяц, значит выгодно.
А:
система стоит 60 тысяч в месяц и приносит или экономит 250 тысяч.
Вот это уже бизнес.
Мы с этим столкнулись ровно на ИИ-продавце
На раннем этапе кажется, что главное — подобрать хорошую модель и написать сильный промпт.
Потом выясняется: разговор — самая лёгкая часть.
Гораздо важнее понимать, когда человек уже квалифицирован, какие вопросы ему ещё можно задавать, что делать с неполными данными, когда прекращать диалог, когда передавать менеджеру и что именно сохранять для следующего этапа.
То есть из «чат-бота» постепенно получается процесс продаж, в котором нейросеть является только одним из компонентов.
Именно поэтому в Market GPT мы в итоге строили ИИ-продавца не как бесконечно умного болтуна, а как систему, которая должна довести диалог до понятного следующего действия и вовремя отдать человека живому сотруднику.
Вот это уже ближе к производственной автоматизации.
Кстати, отсюда вытекает очень полезное правило
Автоматизировать нужно не то, что AI способен сделать.
А то, что экономически имеет смысл ему отдавать.
Нейросеть способна написать поздравление сотруднику с днём рождения.
Хорошо.
Компания тратит на это двадцать минут в год.
Поздравляю, мы только что построили автоматизацию с окупаемостью примерно никогда.
Зато ежедневная сортировка 300 заявок может выглядеть очень скучно — и приносить реальную экономию.
Главный вопрос не:
можно ли?
А:
зачем?
Поэтому хороший проект начинается с дорогого места в процессе
Где люди тратят много времени?
Где происходят повторяющиеся ошибки?
Где теряются деньги?
Где важно быстро реагировать?
Где приходится постоянно переносить одни данные из одной системы в другую?
Где сотрудники вынуждены читать много текста только ради нескольких фактов?
Вот туда AI обычно входит особенно хорошо.
А уже после этого выбирается модель.
Не наоборот.
И ещё важно считать стоимость НЕавтоматизации
Это часто вообще забывают.
Предположим, система стоит 100 тысяч рублей в месяц.
Дорого?
Возможно.
Но если без неё компания теряет 30 заявок ежемесячно, каждая потенциально приносит 20 тысяч рублей маржи, настоящий вопрос выглядит немного иначе.
И наоборот.
Если автоматизация экономит менеджеру три часа в месяц, вкладывать полмиллиона в разработку ради красивой презентации довольно странно.
ROI искусственного интеллекта считается совершенно так же, как ROI любой другой технологии.
Слово AI не освобождает от арифметики.
Есть простой способ понять, что система уже стала настоящей
В начале разработчики обсуждают:
какая модель?
Потом:
какой промпт?
А когда проект взрослеет, разговоры становятся другими:
процент автоматического завершения;
стоимость успешной операции;
число эскалаций;
среднее время выполнения;
процент ошибок;
экономия рабочего времени;
стоимость одного привлечённого или обработанного клиента.
Вот тогда AI перестаёт быть игрушкой.
Потому что его начинают измерять не качеством красивого ответа.
А результатом процесса.
И токены там действительно оказываются всего одной строкой
Нужной.
Иногда большой.
Иногда очень важной.
Но всё-таки одной.
Рядом стоят разработка, интеграции, инфраструктура, мониторинг, контроль качества, поддержка, человеческая проверка и стоимость ошибок.
Причём по мере удешевления моделей доля самого inference может становиться ещё меньше. OpenAI в 2026 году снова заметно снизила цены младших моделей именно потому, что индустрия постоянно двигается к более дешёвым вычислениям на типовых задачах.
А вот сделать плохой бизнес-процесс хорошим автоматически пока почему-то не подешевело.
Поэтому вопрос «сколько стоит ИИ-автоматизация?» примерно такой же, как «сколько стоит сайт?»
Можно за пять тысяч.
Можно за пять миллионов.
Оба будут сайтами.
Разница определяется не количеством HTML, а тем, какую задачу система должна решать, с чем интегрироваться, насколько надёжно работать и сколько денег стоит её ошибка.
С AI ровно то же самое.
Иногда вся автоматизация действительно состоит из одного запроса к недорогой модели.
А иногда за простым пользовательским:
обработай заявку
скрываются двадцать сервисов, три базы данных, семь проверок и инженер, который однажды в три часа ночи обнаруживает, что OAuth-токен снова истёк.
Именно поэтому я бы перестал спрашивать:
Сколько стоят токены?
И начал с другого:
Сколько стоит один правильно выполненный бизнес-процесс?
Если после внедрения эта цифра стала ниже — автоматизация работает.
Если нет, абсолютно неважно, что нейросеть обошлась вам всего в три доллара.
Вы просто очень дёшево автоматизировали что-то ненужное.
