Никита Векессер, отвечающий за развитие ИИ-продуктов в Orion soft, разобрал ошибки перехода от пробного запуска к постоянной работе корпоративного ИИ. Его главный тезис: до покупки графических ускорителей — GPU — нужно определить задачу, требования к сервису и критерии успеха. Убедительная демонстрация ещё не означает, что система выдержит реальную нагрузку и уложится в бюджет.
Начать с результата, а не с сервера
Векессер рекомендует описывать проект как проверяемую гипотезу: какое действие в рабочем процессе изменится благодаря ИИ, какой показатель нужно улучшить и насколько. Для помощника технической поддержки он предлагает оценивать время обработки обращений, долю корректных ответов и число передач вопроса на следующую линию поддержки. Это пример критериев, а не сообщение о достигнутой экономии.
По наблюдениям автора, в 2026 году его команда всё чаще сталкивается с задачей превратить уже проверенный прототип в устойчивый сервис. При этом удачный личный опыт сотрудника с облачной моделью нельзя автоматически переносить на сотни пользователей: нужны ответственный за сервис, правила работы с данными, подключения к другим системам и требования безопасности.
Приложение, среда и оборудование зависят друг от друга
Orion soft разделяет проект на три уровня. Приложение определяет, что делает пользователь и какого качества ждёт от ответа. Среда эксплуатации отвечает за хранение данных, распределение ресурсов, наблюдение за работой и доступность. Оборудование задаёт физические возможности: вычисления, память и скорость обмена данными.
Проектировать их без обратной связи, предупреждает Векессер, рискованно. Прототип может работать через внешний сервис, который затем окажется недопустим по корпоративным требованиям. А мощные серверы сами по себе не гарантируют, что выбранная система сможет использовать быстрые соединения между ними.
Для языковой модели недостаточно проверить, помещаются ли её параметры в видеопамять. Автор также перечисляет память для промежуточных вычислений, объём обрабатываемого текста, число одновременных запросов и распределение модели между ускорителями. Поэтому успешный запуск на стенде — ещё не проверка работы под пользовательской нагрузкой. Отдельный практический вопрос — как ускорить работу модели без покупки новых GPU.
Пилот должен проверять и качество, и стоимость
Векессер советует заранее ограничить срок эксперимента и сравнивать обоснованные варианты по одинаковым критериям: правильности и полноте ответа, соответствию исходным материалам, времени ожидания и стоимости обработки запроса. Если приемлемого сочетания качества и затрат нет, его рекомендация — пересмотреть гипотезу, а не бесконечно наращивать инфраструктуру.
Среди ошибок из опыта заказчиков автор описывает покупку GPU-серверов без ответственного и требований к будущим сервисам: такое оборудование может месяцами оставаться невостребованным. Другой приведённый сценарий — расширение облачной конфигурации после проверки нагрузки, из-за которого эксплуатация вышла за бюджет проекта.
Это рекомендации и наблюдения представителя Orion soft, а не универсальный расчёт окупаемости. Они не определяют, какой сервер выгоднее конкретной компании. Полезный ориентир здесь иной: оценивать покупку вместе с задачей, допустимым качеством, реальной нагрузкой и условиями эксплуатации, а не по одному факту успешного запуска модели.
