ИИ-инфраструктура без боли: своя, арендованная или гибридная

Искусственный интеллект сегодня проникает во все сферы: по данным опросов, около 70% российских компаний уже используют ИИ в том или ином виде. Те компании, которые не просто работают с ИИ-чатами, а встраивают ИИ в собственные продукты, стоят перед выбором: арендовать готовые модели через API или строить собственную инфраструктуру. О плюсах, минусах и реальных компромиссах каждого из подходов рассказывает Александр Демидов, директор по облачной инфраструктуре Битрикс24.

Путь первый: модель как сервис (MaaS)

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

MaaS — это полноценный сервис, который включает несколько критически важных компонентов:

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

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

• Широкий выбор моделей без экспериментов с open-source. Не нужно тестировать десятки моделей с открытыми весами. Достаточно взять топ-5 по независимым бенчмаркам, прогнать несколько сценариев и выбрать оптимальную. Результат практически всегда оказывается предсказуемым и стабильным.

• Готовые операционные гарантии. Провайдер берет на себя SLA по доступности, обновлениям, фильтрации контента, мониторингу и безопасности. Все, что обычно требует отдельной инфраструктурной команды, здесь уже реализовано "из коробки".

Аренда (MaaS) выгоднее, когда трафик непредсказуем. Это типично для старта: вы разрабатываете MVP, проводите тесты, проверяете гипотезы. Запросы либо единичные, либо нагрузка идет только в дневные часы, поэтому ночью и в выходные сервис простаивает. Кроме того, аренда дает мгновенный доступ к новым моделям, что критически важно на этапе экспериментов, когда нужно быстро запустить фичу и проверить ее жизнеспособность.

Второй путь: self-hosted

В этом случае компания становится ИИ-провайдером, а не просто запускает ИИ-модели на одном сервере. И этот подход требует решения ряда инженерных задач:

• Запуск моделей на выбранном инференс-фреймворке и выдача ответов через собственное API.

• Обеспечение единой точки входа для запросов с аутентификацией, ключами доступа, лимитами и биллингом. Без биллинга разные команды начинают негласно конкурировать за GPU-ресурсы — одна команда может нечаянно "перетянуть" на себя все мощности, и запросы других будут обрабатываться с ошибками или тормозить.

• GuardRails (фильтры безопасности). Необходимо контролировать, что подается на вход модели и что она выдает на выходе, отсекая вредоносный, противоправный и нежелательный контент.

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

• Проверки качества и тестирование. Без них невозможно экспериментировать и менять компоненты ИИ-инфраструктуры, не рискуя качеством.

• Мониторинг, сбор метрик, логов, трейсов, разделение по уровням запросов. Все это необходимо для диагностики и понимания поведения системы.

• Дежурства и реагирование на инциденты. Работа в качестве ИИ-провайдера требует работы 24/7, а не только в рабочее время. Инциденты случаются в любой момент, и команда должна быть готова к оперативной реакции.

Отдельный аспект — локализация данных и соответствие законодательству. Если вы работаете с персональными данными, которые ни при каких условиях не должны покидать внутренний контур, единственным выбором остается self-hosted.

Плюсы self-hosted

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

• Гибкость и дообучение. Можно взять модель и доработать ее под специфическую задачу. Например, внедрить распознавание речи с детекцией эмоций.

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

• Кастомизация под сценарии. Для простых запросов могут быть использованы легкие модели, для сложных — тяжелые и дорогие.

Сложности self-hosted-подхода

Стоимость GPU-серверов — лишь вершина айсберга. Есть еще несколько факторов, которые многократно увеличивают бюджет или становятся фактором риска.

Самый дорогой ресурс в self-hosted — люди

Ресерч моделей, выбор и настройка инференс-фреймворков, ML-Ops, DevOps — это редкая и дорогая экспертиза. Рынок таких специалистов узкий и пока еще молодой, опыт есть у единиц, поэтому стоят они обоснованно дорого.

Кроме того, массовый сервис на сотни тысяч или миллионы пользователей требует круглосуточных дежурств. Для собственной ИИ-инфраструктуры нужны полноценные смены с SLA по времени реакции, обработкой инцидентов, коммуникацией с вендорами. Также понадобятся отдельные команды, отвечающие за метрики, логи, трейсы и соблюдение регламентов.

Покупка оборудования на годы привязывает к одному поколению GPU

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

Мы столкнулись с этим на практике. Уже имея парк машин с A100, мы решили протестировать новую модель GPT-OSS. Оказалось, что она требует GPU, построенных на архитектуре Hopper, то есть H100, и на A100 не запускается в принципе.

Поддержка новых моделей во фреймворках отстает от обещаний

Фреймворки часто заявляют поддержку любой новой модели в день релиза. Работа с self-hosted инфраструктурой показывает, что при выходе новой модели могут возникать проблемы с запуском, с качеством работы модели, скоростью поддержки. Примерно 2-4 недели уходит у вендора фреймворка на выпуск патчей, затем еще 1-2 недели на внутренние тесты на собственной инфраструктуре. В итоге выход новой модели в продакшн занимает около месяца.

Для сравнения: в MaaS вы меняете одну строку в конфигурационном файле, указываете название новой модели и начинаете работать сразу.

Открытые веса не означают свободное коммерческое использование

Модели с открытыми весами, то есть уже обученные, не всегда бесплатны и доступны для любых целей. Внимательно читайте документацию до внедрения: вам подойдут лицензии MIT, Apache 2.0. Но есть лицензии, которые запрещают коммерческое использование, ограничивают число запросов, не доступны в конкретных регионах. Кажущаяся свобода выбора может обернуться юридическими рисками.

Главный инструмент управления рисками — тестирование

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

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

Гибридные решения

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

Есть две основные механики.

Первая практика — разделение запросов по отдельным пулам в зависимости от их сложности и требований к скорости обработки. Для сценариев, работающих в режиме реального времени, например ИИ-чата, обычно устанавливаются жесткие требования к времени ответа — порядка трех секунд. На практике может возникать ситуация, когда в тестовой среде все показатели соответствуют требованиям, а при реальной эксплуатации время ответа увеличивается. Одной из причин может быть смешивание в одном пуле легких чатовых запросов и ресурсоемких задач, например анализа карточек CRM.

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

Вторая механика — Semantic Router, умная диспетчеризация на основе содержания запроса. Она позволяет анализировать сам запрос и принимать решение, на какую модель его отправить. Если задача простая, например саммаризация текста, — направлять на легкую и дешевую модель. Если запрос сложный, требует агентского цикла или многошаговых рассуждений — отправлять на более мощную.

А исследовательские кейсы или MVP, если это допустимо с точки зрения локализации данных, можно вовсе направлять на внешние модели через API. Это экономит ресурсы на развертывание инфраструктуры под единичные сценарии.

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

Чек-лист: как выбрать между MaaS и self-hosted

1. Насколько важна локализация данных?

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

2. Есть ли у вас команда?

Для self-hosted нужны SRE-инженеры, ML-Ops, DevOps, специалисты по мониторингу и дежурствам. Если команды нет, выбирайте MaaS.

3. Насколько стабильна и предсказуема нагрузка?

Если вы прошли бета-тестирование, собрали сценарии использования и можете прогнозировать объем запросов или гарантировать утилизацию ресурсов в коридоре 60-90%, self-hosted подход экономически оправдан.

4. Готовы ли вы к тестированию решения?

При смене модели или версии фреймворка вы должны быть уверены, что качество не деградирует. Если у вас нет отлаженных автоматических тестов и эталонных датасетов — переход на self-hosted будет сопряжен с высокими рисками.

5. Готовы ли вы считать время на промпты, контекст и инженерию?

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

6. Получаете ли вы выгоду от кастомизации?

Если ваши сценарии типовые и не требуют доработок — выгода от self-hosted может оказаться минимальной.

Эти пункты стоит оценивать в совокупности. Нет единственного критерия, который бы все решал, но если у вас есть жесткие требования к данным, предсказуемый трафик и готовая команда — self-hosted становится не просто возможным, а экономически оправданным.