Совокупная стоимость владения (TCO, total cost of ownership) — все затраты на ИИ-решение за срок его жизни: разработка и внедрение, токены или железо, сопровождение и доработки, переоценка, обучение персонала, откат. Смета на разработку — обычно меньше половины этих денег.
TCO считается до выбора архитектуры, а не после: решение «облачный API или своя модель» меняет структуру затрат на порядок, и без полной картины его принимают по привычке, а не по цифрам. Ссылка на то, как эта выгода превращается в ROI — в статье про ROI ИИ-проекта; здесь — только про знаменатель.
Статьи затрат
Разработка и внедрение. Диагностика данных, проверочный набор, пайплайн, интеграции с внутренними системами, тестирование, обучение пользователей. Интеграции часто дороже самой ИИ-части: подключение к CRM, зондирующее единственный сценарий, съедает 30–50% сметы внедрения.
Токены и API либо железо. Облачный API оплачивается за токены и растёт линейно с объёмом; своя модель — это GPU-серверы или аренда, электроэнергия, администрирование. Правило ориентира: при малых и средних объёмах API дешевле из-за отсутствия капитальных затрат; своя модель начинает выигрывать на больших стабильных потоках и при требованиях к приватности.
Сопровождение и доработки. Исправление промптов на новых типах обращений, пополнение базы знаний, обновление зависимостей, инциденты. Ориентир — 15–30% стоимости разработки в год; ниже 10% — система деградирует незаметно, выше 35% — сценарий выбран неудачно или качество системы низкое.
Переиндексация и переоценка. Обновление модели эмбеддингов или генератора требует переиндексации базы и переоценки на проверочном наборе — это работа на дни, а не «нажали кнопку». Обновления моделей вендора меняют поведение даже без вашего участия: закладывайте переоценку не реже раза в полгода-год.
Обучение персонала. Не только курсы, но и время на привыкание: месяц-два сниженной производительности при переходе процесса на новую схему. Скрытая, но реальная статья.
Откат и риски. План отката, дублирование процесса на переходный период, разметка спорных случаев, юридическая проверка контента. Статья, о которой вспоминают при инциденте — то есть тогда, когда она уже не заложена в бюджет.
Первый год против второго
Первый год — разработка и запуск. Типовая структура: 40–60% — разработка и интеграции, 15–25% — данные, разметка и проверочный набор, 10–20% — эксплуатация, остальное — обучение и оргработа. Эксплуатационные затраты первого года занижены относительно второго: поток ещё не на полную мощность.
Второй год — почти целиком эксплуатация. Сопровождение, доработки, токены, переоценка. Сравнивать предложения по смете первого года — типовая ошибка: у дешёвого первого года бывает дорогое содержание, и наоборот. Вопрос «сколько стоит содержание в месяц» на этапе выбора важнее скидки на разработку.
Точка пересечения API и своей модели. При росте объёма затраты API растут линейно, своей модели — ступенчато (следующий сервер). На малых объёмах выигрывает API, на больших — своя модель; точка пересечения зависит от длины контекста и нагрузки, поэтому решение проверяется расчётом на своих объёмах, а не общими словами. Подробно — в материале своя модель или API.
Скрытые статьи
Сопровождение проверочного набора. Набор — живой артефакт: пополняется вопросами из эксплуатации, эталоны пересматриваются при изменении базы знаний. 2–5 часов в месяц разметки и ревизии; статья маленькая, но когда её несут в никуда, качество системы перестаёт измеряться.
Дублирование процессов на переходный период. Пока системе не доверяют, обращение проходит и через систему, и через человека: затраты не снижаются, а растут. Планируйте период дублирования на 1–3 месяца и критерий, когда человек из контура выходит — иначе дублирование становится постоянным.
Мониторинг и реагирование на дрейф. Обращения меняются, база знаний устаревает; без мониторинга деградация замечается по жалобам, а не по метрикам. Что и как мониторить — в статьях про MLOps и дрейф данных.
Разметка на поддержку. Спорные случаи, добавляемые в набор, разметка новых типов обращений — постоянная работа эксперта на несколько часов в месяц, редко попадающая в сметы.
Где уместен расчёт TCO
Перед выбором архитектуры. API против своей модели, векторная база в существующем Postgres против отдельной инсталляции — каждое решение сдвигает структуру затрат на годы. Сравнивайте на горизонте 2–3 лет, не на месяце запуска.
При сравнении предложений подрядчиков. Два предложения с равной сметой разработки могут отличаться вдвое по стоимости владения: разные модели сопровождения, разные договорённости о правах на код. Вопросы для такого сравнения — в статье выбор подрядчика.
При бюджетировании на следующий год. Действующая система — это статья операционных затрат; заявка «нам нужно ещё» без цифр содержания не защищается перед финансами. TCO даёт число, которое можно вносить в бюджет.
Когда TCO избыточен. Пилот на 2–6 недель или разовый анализ данных: затраты ограничены сметой работ, долгосрочное владение не планируется. Полный TCO здесь — накладные расходы ради формы; достаточно сметы и оценки токенов.
Типичные ошибки
Приравнять TCO к смете разработки. Механизм ошибки: разработка — единственная цифра в договоре, и она становится «стоимостью проекта». Реальная пропорция на горизонте трёх лет: суммарное содержание обычно превышает первоначальную разработку.
Не заложить рост объёмов. Смета токенов посчитана на пилотный поток; при выходе на все обращения затраты растут в разы. Считайте эксплуатацию на целевом объёме, а не на текущем.
Забыть, что модели вендора меняются. Обновление модели в API — бесплатно, но ведёт за собой переоценку, правку промптов, иногда миграцию. Один такой цикл в год — это дни инженерного времени, которых нет в смете «сопровождение по запросу».
Считать только прямые затраты. Время экспертов на разметку, время сотрудников на проверку в контуре, время руководителя на приёмку — реальные деньги, обычно 10–20% от видимой части проекта.
Частые вопросы
Сколько стоит содержание ИИ-системы в месяц?
Ориентиры для системы среднего размера (бот по базе знаний, поток до 10 тысяч обращений в месяц): токены API — от десятков до сотен долларов в месяц в зависимости от длины контекста; сопровождение — 20–40 инженерных часов; пополнение набора и базы знаний — 5–10 часов эксперта. Порядок величины полного содержания — 5–15% стоимости разработки в месяц.
Облачный API или своя модель — что дешевле?
До определённого объёма — API: нет капитальных затрат, оплата растёт с потоком. Своя модель выигрывает на больших стабильных объёмах, при требованиях держать данные в контуре и при специфических задачах дообучения. Решение считается расчётом на ваших объёмах с горизонтом 2–3 года, не общим правилом.
Почему смета второго года не нулевая, если система готова?
Потому что «готова» — состояние на дату сдачи, а не навсегда: обращения дрейфуют, база знаний меняется, модели вендора обновляются. Без доработок и переоценки система деградирует за месяцы; затраты второго года — плата за то, чтобы система продолжала соответствовать реальности.
Как сократить TCO без потери качества?
Начать с узкого сценария и расширять по факту, а не строить сразу универсальную систему; выбирать гибрид — критичные данные в контуре, остальное в API; сокращать длину контекста через чанкинг и реранкинг вместо «пихать всё в промпт»; автоматизировать переоценку на проверочном наборе. Механика экономии на токенах — в статье как снизить расходы на токены.
Кто должен считать TCO?
Заказчик вместе с подрядчиком: подрядчик знает инженерные статьи и типовые объёмы доработок, заказчик — стоимость часа сотрудников, планы по объёмам и ограничения безопасности. Расчёт только подрядчиком склонен занижать содержание, только заказчиком — завышать разработку.
Как TCO связан с ROI?
TCO — это знаменатель ROI: полный охват статей владения делает ROI честным. Завышение ROI почти всегда происходит не от выдуманной выгоды, а от усечённого TCO — забытого сопровождения, дублирования, переоценки.