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

Разбираем статьи бюджета LLM-проекта, реальные цены API и on-premise, три ловушки расчёта и формулу окупаемости с остаточной ручной работой.

Dmitrij Tamarov Dmitrij Tamarov 29 июля 2026 г. · 7 мин
llm roi внедрение экономика бюджет

Вопрос звучит просто, а честный ответ начинается с неудобного: одной цифры не существует. Разброс на рынке идёт от пятнадцати тысяч рублей за чат-бота на готовой платформе до десятков миллионов за защищённый контур. Обе цифры настоящие, просто за словом «внедрение LLM» скрываются принципиально разные проекты.

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

Если вы ещё не выбрали процесс для автоматизации, начните с обзорного материала: LLM для бизнеса. Считать окупаемость до выбора процесса бессмысленно.

Шесть статей бюджета

Любой проект раскладывается на шесть категорий затрат. Пропуск любой из них даёт неприятный сюрприз через три месяца после старта.

Инфраструктура. Для облачного сценария это счёт провайдера, для закрытого контура это сервер, GPU, хранилище, сеть, электричество и место в стойке.

Модель и обвязка. Открытые модели формально бесплатны, но вокруг них нужен сервер инференса, векторная база, оркестрация и мониторинг. Настройка всего этого тоже работа.

Данные и поиск. Документы нужно собрать, очистить, нарезать, проиндексировать и поддерживать индекс актуальным. По оценке AZONE-AI, на реальных пилотах эта статья доходит до 30-40% бюджета.

Интеграции. Подключение к CRM, ERP, документообороту, почте, каталогу пользователей. Каждое подключение становится отдельной задачей со своим сроком.

Эксплуатация. После запуска кто-то следит за качеством ответов, обновляет базу знаний, чинит сбои и ведёт регламенты. Это постоянные расходы, которые забывают заложить чаще всего.

Информационная безопасность. Разграничение доступа, журналирование, сегментация сети, для регулируемых отраслей ещё и сертифицированные средства. Подробно разбираю это в отдельном материале про безопасность LLM в компании.

Обратите внимание, где в этом списке модель. Она одна из шести статей, и обычно не самая дорогая. Агентство 1seller оценивает, что 60-80% стоимости даже при использовании готового API приходится на адаптацию, интеграцию и работу с внутренними данными. Первоисточник этой оценки в статье не назван, так что относитесь к ней как к отраслевому ориентиру, а не как к измеренному факту. Но порядок она передаёт верно.

Ловушка первая: один запрос пользователя не равен одному вызову модели

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

Проблема в том, что за одним нажатием Enter в реальной системе стоит цепочка вызовов. Разработчики, опубликовавшие разбор юнит-экономики на Хабре, описывают типичный сценарий ассистента с поиском по базе знаний:

  1. лёгкая модель решает, нужен ли поиск вообще;
  2. лёгкая модель переформулирует вопрос под поиск;
  3. система ищет документы, и это тоже платная операция;
  4. лёгкая модель отбирает лучшие из найденных;
  5. основная модель формулирует ответ;
  6. лёгкая модель проверяет ответ на противоречие источникам;
  7. при неудачной проверке шаги с четвёртого по шестой повторяются.

Шесть обращений к моделям вместо одного. Авторы приводят характерное расхождение: заявленные в смете 0,06 доллара за запрос в продакшене превращаются в 0,15 доллара. По их наблюдению, большинство команд ошибаются в бюджете в два-три раза, и не по невнимательности, а потому что считают не те статьи.

Практический вывод: считайте стоимость сценария целиком, а не стоимость одного обращения к модели.

Ловушка вторая: расходы, которых нет в прайсе

Прайс провайдера показывает цену токена. За его пределами остаётся следующее:

  • повторная индексация. База знаний живёт: документы правятся, добавляются, устаревают. Каждый цикл переиндексации оплачивается заново;
  • ретраи. Сбой сети, таймаут, неудачная проверка качества. Каждая повторная попытка тарифицируется как полноценный запрос;
  • тестовое и препродакшн-окружение. Разработка и отладка расходуют токены месяцами до запуска;
  • мониторинг. Чтобы понимать структуру расходов, нужны отдельные инструменты. Счёт провайдера показывает, сколько вы потратили, но не почему;
  • рост потребления. Пользователи осваиваются и начинают задавать больше вопросов и длиннее. Это хороший знак и одновременно рост счёта.

Отдельно про контекст. Основной объём токенов уходит не на вопрос пользователя, а на то, что подкладывается вместе с ним: инструкции, найденные документы, историю переписки. Поэтому сокращение пользовательских запросов почти ничего не даёт, а работа с размером контекста даёт много.

Ловушка третья: остаточная ручная работа

Самая дорогая и самая невидимая статья. Она не появляется ни в одном счёте, потому что оплачивается зарплатой ваших сотрудников.

Спросите себя после запуска пилота: что человек всё ещё делает руками? Обычный список выглядит так:

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

Если LLM готовит отличный черновик, а сотрудник затем открывает CRM и вносит данные вручную, автоматизирована половина процесса. Экономию вы посчитали по всему процессу, а получили по половине.

Это наблюдение пришло не из технической литературы, а из разбора того, как владельцы бизнеса описывают свой опыт внедрения. Претензия у них одна и та же: инструмент купили, а работы меньше не стало.

Порядки цен: облако

Тарифы API считаются за миллион токенов и различаются между моделями примерно в шестьдесят раз. Вот срез на конец мая 2026 года по публикации в рублях на vc.ru (курс ЦБ 71,668 рубля за доллар на 27 мая 2026):

МодельВход, ₽ за 1MВыход, ₽ за 1MПрофиль
GPT-5.53502150флагман, мультимодальность
Claude Opus 4.73501790сложный код, агенты
Claude Sonnet 4.62101070универсал
GPT-5.41701070универсал
Gemini 3.1 Pro140860длинный контекст
Gemini 3.5 Flash100640быстрый и дешёвый
DeepSeek V4 Pro3060массовая генерация
Qwen 3.6 Plus20130массовая генерация

Две вещи, которые отсюда стоит забрать. Первая: выход дороже входа в разы, поэтому длина ответа влияет на счёт сильнее длины вопроса. Вторая: разница между флагманом и рабочей лошадкой десятикратная, и далеко не каждый шаг конвейера требует флагмана. В сценарии с Хабра из семи шагов флагман нужен ровно на одном.

Цифры устаревают за месяцы. Проверяйте актуальный прайс на момент своего расчёта.

Порядки цен: закрытый контур

Если данные не могут покидать периметр, экономика меняется полностью: вместо ежемесячного счёта появляются капитальные вложения. Ориентиры российского рынка на 2026 год по разбору AZONE-AI:

КонфигурацияОриентир
Ускоритель A100 80GB1,5-2,5 млн ₽
Сборка под модель 8B (1-2 A100, 256-512 ГБ ОЗУ)3,5-5 млн ₽
Платформа под модель 70B (2 A100)8-12 млн ₽
Конфигурация из 4 карт с резервированием15-25 млн ₽

Это только железо, то есть одна из шести статей бюджета. Сама модель при этом чаще всего бесплатна: открытые лицензии позволяют использовать её без платежей. Платите вы за всё остальное.

Простое правило для сравнения вариантов: считайте, за сколько месяцев работы на API набежит стоимость сборки. Если срок превышает горизонт вашего планирования, закрытый контур обсуждать рано.

Что реально удешевляет проект

Прежде чем урезать функциональность, стоит применить четыре приёма. Они дают основную экономию и не влияют на результат для пользователя.

Маршрутизация моделей. Разные шаги конвейера требуют разного класса модели. Классификация обращения, переформулировка запроса и отбор документов прекрасно выполняются дешёвой моделью, а флагман нужен там, где формулируется финальный ответ. При десятикратной разнице в цене между классами это самая крупная экономия из доступных.

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

Кэширование. Повторяющиеся вопросы и стабильные части инструкции не обязаны оплачиваться каждый раз. В корпоративных сценариях доля повторов высокая: сотрудники спрашивают об одном и том же.

Мониторинг с разбивкой. Не приём экономии, а условие для неё. Без разбивки расходов по пользователям, сценариям и окружениям вы видите общую сумму и не знаете, что именно резать. Инструмент, показывающий структуру счёта, окупается первым же обнаруженным перекосом.

Формула

text
Ежемесячная выгода
= сэкономленные часы, умноженные на полную стоимость часа
+ предотвращённые ошибки и переделки
+ измеримая дополнительная валовая прибыль

Ежемесячные расходы
= стоимость модели или API
+ инфраструктура и сопровождение
+ остаточная ручная работа
+ поддержка интеграций и базы знаний

Срок окупаемости
= стоимость внедрения, делённая на разницу выгоды и расходов

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

Ещё один множитель, о котором забывают: доля реального использования. Решение, которым пользуется треть отдела, приносит треть расчётной экономии. Закладывайте это в расчёт сразу, а не узнавайте через полгода.

Разбор на собственном проекте

MediaUniversal, наш конвейер подготовки SEO-материалов из четырнадцати с лишним агентов. Ручной цикл занимал 14-20 часов, конвейер отрабатывает примерно за 30 минут. Разбивка по этапам:

ЭтапВручнуюКонвейерОсталось человеку
Исследование конкурентов3-4 ч5-8 миннет
Структура материала1-2 ч2-3 миннет
Черновик4-6 ч2-3 миннет
Проверка фактов2-3 ч3-5 мин2-5 мин проверки
Редактура, шесть проходов3-4 ч8-10 миннет
Метаданные30 мин1-2 миннет

Это собственный проект, а не клиентский кейс, и цифры измерены на нашем процессе. В вашем они будут другими.

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

Другие проекты с разбивкой по этапам собраны в разделе кейсов.

Когда считать не нужно

Четыре признака процесса, который не окупится. Если совпадает хотя бы два, сэкономьте себе время на расчётах.

Объём меньше сотни операций в месяц. Затраты на интеграцию и сопровождение постоянны и не зависят от нагрузки. На малых объёмах они съедают любую экономию.

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

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

Ошибка необратима и дорога. Платежи, юридические обязательства, медицинские решения. Здесь нужен человек в контуре на каждом шаге, и экономии не остаётся.

Отделить такой процесс от перспективного как раз и есть задача AI-аудита, и делается это до того, как потрачен бюджет.

Чек-лист перед стартом

  1. Измерьте текущий процесс: объём, время цикла, частота ошибок.
  2. Посчитайте, сколько вызовов модели стоит за одной пользовательской операцией.
  3. Заложите ретраи, переиндексацию и тестовое окружение.
  4. Оцените, что останется человеку после внедрения, и в часах.
  5. Умножьте расчётную экономию на реалистичную долю использования.
  6. Сравните стоимость года на API со стоимостью своей инфраструктуры.
  7. Назовите одну метрику, по которой примете решение о масштабировании.

Нужна помощь с расчётом?

На 30-минутном разборе пройдём по вашему процессу: где эффект будет измеримым, сколько останется ручной работы и какая архитектура достаточна.

Напишите мне в Telegram: https://t.me/dtamarov

Подготовьте описание одного процесса, примерный месячный объём операций и список систем, которые в нём участвуют. Этого хватит, чтобы посчитать порядок величины на встрече.

Dmitrij Tamarov
Dmitrij Tamarov

AI architect

Статьи по теме