Стоимость эксплуатации ИИ-решения нужно считать до разработки, а не после запуска, потому что решение, отлично работающее на тесте, может оказаться нерентабельным при реальном объёме обращений. Расчёт строится от стоимости одного обращения, умноженной на ожидаемый объём, плюс постоянные расходы на инфраструктуру и сопровождение.
Почему это считают до, а не после
Типичный сценарий провала: прототип на десяти тестовых запросах работает прекрасно, решение запускают, а через месяц выясняется, что счёт за обработку сопоставим с зарплатой сотрудника, которого оно должно было разгрузить. Проект технически успешен и экономически бессмыслен.
Причина в том, что у ИИ-решения, в отличие от обычного скрипта, есть переменная стоимость: каждое обращение к модели стоит денег, и при росте объёма расходы растут пропорционально. Скрипт, обрабатывающий миллион записей, стоит столько же, сколько обрабатывающий десять. Обращение к языковой модели миллион раз стоит в сто тысяч раз дороже, чем десять раз.
Поэтому вопрос «сколько это будет стоить в эксплуатации» должен быть частью постановки задачи, а не приятным сюрпризом после запуска. Это один из пунктов, разобранных в опорной статье «Внедрение ИИ в бизнес»; здесь — как считать конкретно.
Из чего складывается стоимость
Разовые затраты (на старте)
- постановка задачи и проверка гипотезы;
- подготовка данных — часто основная статья, особенно при разнородном корпусе;
- разработка;
- интеграции с существующими системами;
- оборудование, если решение разворачивается локально;
- обучение пользователей.
Это капитальные вложения, которые нужно окупить. Они важны, но предсказуемы. Опаснее вторая категория, которую часто недооценивают.
Регулярные затраты (постоянно)
- обращения к модели (для облачных сервисов) или содержание сервера (для локального развёртывания);
- сопровождение и контроль качества;
- обновление базы знаний;
- миграция при смене модели.
Именно регулярные затраты определяют, рентабельно ли решение в долгую. Их и нужно считать в первую очередь.
Как считается стоимость обращения для облачных моделей
Облачные модели тарифицируются по объёму обработанного текста, который измеряется в токенах. Токен — это примерно часть слова; в среднем для русского текста один токен соответствует нескольким символам. Оплачиваются и входящие токены (то, что отправлено модели), и исходящие (то, что она ответила), обычно по разным ставкам.
Стоимость одного обращения складывается из:
- входящего контекста — сам вопрос плюс всё, что система добавляет: системная инструкция, найденные фрагменты документов (в RAG их может быть много), история диалога;
- исходящего ответа — сгенерированный текст.
Практический вывод, который часто упускают: в RAG-системах входящий контекст обычно в разы больше самого вопроса, потому что вместе с вопросом модели передаются найденные фрагменты документов. Именно они, а не короткий вопрос пользователя, составляют основную часть счёта. Поэтому решение, которое кладёт в контекст двадцать фрагментов «на всякий случай», стоит существенно дороже решения, которое кладёт три релевантных после реранкинга, — при том же или лучшем качестве.
Формула для прикидки: (средний размер входящего контекста × ставка за входящие токены + средний размер ответа × ставка за исходящие) × ожидаемое число обращений в месяц.
Средние размеры оцениваются на прототипе, ставки — по тарифам выбранной модели, число обращений — по реальному объёму процесса. Результат — реалистичная месячная стоимость, которую можно сравнить с экономией.
Как считается стоимость для локального развёртывания
Здесь модель другая: нет платы за обращение, но есть постоянные расходы независимо от объёма.
- амортизация оборудования — сервер с видеокартами распределяется на срок службы;
- электроэнергия — инференс на GPU потребляет заметно, и это регулярная статья;
- администрирование — обновления, мониторинг, поддержание работоспособности;
- резервирование, если требуется отказоустойчивость.
Ключевое отличие: локальное развёртывание имеет высокий постоянный расход и почти нулевой переменный. Поэтому оно выгодно при большом объёме (постоянные расходы размазываются на много обращений) и невыгодно при малом (платите за простаивающее железо). Точка безубыточности между облаком и своим сервером — предмет отдельного расчёта под конкретный объём; подробнее о самом развёртывании — в статье «Локальное развёртывание LLM».
Как снизить стоимость эксплуатации
Расходы на обращения — не константа, ими можно управлять. Основные рычаги:
Реранкинг вместо большого контекста. Передавать модели три релевантных фрагмента вместо двадцати условно подходящих. Дешевле и точнее одновременно — один из самых эффективных рычагов.
Маршрутизация по сложности. Простые обращения обрабатывает маленькая дешёвая модель, сложные — большая. Классификатор на входе стоит копейки и часто окупается многократно, если большая доля обращений простые.
Кэширование частой неизменной части. Если в каждом запросе повторяется большой неизменный блок (системная инструкция, справочник), его кэширование даёт существенную экономию в поддерживающих это сервисах.
Кэширование ответов на повторяющиеся вопросы. Одинаковые вопросы не обязательно каждый раз гонять через модель — ответ на частый вопрос можно отдавать из кэша.
Ограничение длины ответа там, где длинный ответ не нужен: короткий ответ дешевле.
Пакетная обработка для фоновых задач без требования к скорости — часто тарифицируется дешевле.
Маленькая дообученная модель для узкой массовой задачи: иногда дешевле один раз дообучить компактную модель, чем гонять большую на миллионе однотипных обращений.
Защита от неконтролируемых расходов
Отдельная и обязательная часть — защита от сценария, когда ошибка выкручивает счёт. Классический случай: агент попадает в цикл и за ночь совершает тысячи обращений, или резкий всплеск нагрузки многократно превышает план.
Меры:
- лимиты расходов с автоматической остановкой при превышении порога;
- оповещения при аномальном росте потребления;
- ограничение числа обращений на пользователя и в единицу времени;
- обнаружение зацикливания у агентов.
Это дешёвая страховка от дорогой ошибки, и закладывать её нужно на этапе проектирования, а не после первого неприятного счёта.
Как принять решение по экономике
Итоговое сравнение простое по структуре:
Экономия = (стоимость текущей ручной обработки одной единицы × объём) − стоимость решения.
Стоимость решения = регулярные расходы (обращения или сервер + сопровождение) + амортизация разовых затрат (разработка, интеграции) на разумный срок.
Если экономия устойчиво положительна и разовые затраты окупаются в приемлемый для компании срок — проект имеет смысл. Если стоимость обработки одним ИИ-решением сопоставима с ручной — нет, и это лучше выяснить до разработки.
Отдельно стоит учитывать неденежные эффекты (скорость, качество, обработка того, что раньше не обрабатывалось) — они реальны, но их сложнее свести к рублям, и полагаться только на них при обосновании рискованно.
Частые вопросы
Почему стоимость эксплуатации надо считать до разработки?
Потому что решение может быть технически исправным и при этом нерентабельным при реальном объёме: у ИИ переменная стоимость, каждое обращение стоит денег, и расходы растут пропорционально масштабу. Прототип на десяти запросах ничего не говорит о счёте на тысячах. Расчёт до разработки защищает от проекта, который окажется дороже задачи, которую решает.
Что дороже — облако или свой сервер?
Зависит от объёма. Облако имеет нулевой постоянный расход и плату за обращение — выгодно при малом и среднем объёме. Свой сервер имеет высокий постоянный расход (железо, электричество, администрирование) и почти нулевой переменный — выгоден при большом объёме и обязателен при жёстких требованиях к данным. Точка безубыточности считается под конкретный объём.
Из чего складывается цена одного обращения?
Из объёма входящего текста (вопрос плюс системная инструкция плюс найденные фрагменты документов) и объёма ответа, каждый по своей ставке. В RAG-системах основную часть составляют не вопрос пользователя, а переданные модели фрагменты документов — поэтому передавать в контекст меньше, но релевантнее, напрямую снижает счёт.
Как не получить огромный счёт из-за ошибки?
Заложить лимиты расходов с автоматической остановкой при превышении, оповещения об аномальном росте потребления, ограничения на число обращений и защиту от зацикливания у агентов. Это стандартная страховка, которая закладывается на этапе проектирования. Без неё ошибка в цикле способна за ночь исчерпать месячный бюджет.
Можно ли снизить расходы уже работающего решения?
Да, обычно есть резерв. Основные рычаги: сократить объём контекста через реранкинг, направлять простые запросы на дешёвую модель, кэшировать повторяющееся, ограничить длину ответа. Часто расходы удаётся снизить существенно без потери качества — это отдельная задача оптимизации уже внедрённого решения.
Что дальше
Стоимость эксплуатации — один из факторов, определяющих, стоит ли внедрять ИИ в конкретный процесс. Полная картина — в опорной статье «Внедрение ИИ в бизнес». Как выбрать сам процесс — «Как выбрать процесс для первого ИИ-проекта». Про выбор между облаком и своим сервером подробнее — «Локальное развёртывание LLM».
Расчёт стоимости эксплуатации входит в этап discovery при разработке и внедрении ИИ.