Реальная стоимость заказной интеграции LLM в 2025 году и почему большинство пилотов не доходят до продакшена

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

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

Почему названная цена редко равна итоговой

Когда подрядчик называет цену заказной интеграции LLM для предприятия, он часто оценивает стоимость соединения API с интерфейсом. Это демо. Промышленная AI-система требует детерминированной надёжности от вероятностной модели. Достижение такой надёжности требует строгой инженерии вокруг самой модели.

Лицензии и плата за API — лишь одна часть совокупной стоимости владения. Остальное составляют инфраструктура, подготовка данных и непрерывный мониторинг.

Пять слоёв затрат промышленной LLM-системы

Устойчивая интеграция LLM состоит из пяти отдельных слоёв затрат:

1. 01
   Подготовка данных

   Подготовка, очистка и разметка данных занимают более 80% времени в AI-проектах (Cognilytica, 2019). Векторизация данных, настройка прав доступа и очистка неструктурированных документов для RAG — самый ресурсоёмкий этап.

2. 02
   Лицензии базовой модели и плата за API

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

3. 03
   Инженерия интеграции

   Написание соединительной ткани: оркестрация промптов, маршрутизация API, запасные пути и логика, привязывающая модель к корпоративным данным.

4. 04
   MLOps и мониторинг

   Модели деградируют. LLM требуют наблюдаемости для отслеживания дрейфа, доли галлюцинаций и задержек.

5. 05
   Постоянное дообучение и оптимизация

   По мере изменения корпоративных данных эмбеддинги и дообученные веса нужно обновлять.

Разрыв между «готово для демо» и «готово для продакшена»

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

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

Рамка для оценки объёма работ по LLM

До выделения бюджета на AI-интеграцию технический руководитель должен ответить на четыре вопроса:

1. 01
   Где лежат эталонные данные и доступны ли они через API?
2. 02
   Какая задержка генерации ответа приемлема?
3. 03
   Как мы будем количественно измерять точность вывода модели?
4. 04
   Каков запасной механизм, когда модель отказывает или возвращает небезопасный ответ?

Пока эти вопросы без ответа, любая оценка бюджета — догадка.

Чем полезен этап исследования

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

Не финансируйте интеграцию исходя из стоимости API. Проведите аудит готовности данных и разметьте промышленную архитектуру до первой строки кода.