Где запускать AI-сервис: API, облако, GPU или on-prem

При внедрении AI компании обычно начинают с выбора модели. Но для реального проекта не менее важен другой вопрос: где и как эта модель будет работать.

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

На практике стоит рассматривать пять вариантов:

1. готовые AI-функции в существующих продуктах;
2. внешний LLM API;
3. управляемая AI-платформа;
4. собственная модель на арендованном GPU;
5. private cloud или on-prem.

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

Краткое сравнение

2. Внешний LLM API: модель как готовый сервис

В этом варианте компания обращается к языковой модели через API, а всю прикладную часть создаёт самостоятельно.

Провайдер отвечает за запуск и масштабирование модели. Команда компании разрабатывает остальную систему:

• промпты;
• бизнес-логику;
• RAG и поиск по документам;
• работу с инструментами;
• оркестрацию агентов;
• интеграции с корпоративными системами;
• контроль качества и журналирование.

Например, можно обращаться к YandexGPT через API Yandex AI Studio или использовать Evolution Foundation Models — сервис Cloud.ru с готовыми моделями и OpenAI-совместимым API. В обоих случаях модель уже развёрнута поставщиком, но архитектуру AI-приложения компания собирает сама.

Преимущества подхода:

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

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

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

Подходит, если компании нужна готовая модель, но она хочет сохранить контроль над логикой своего AI-сервиса.

3. Управляемая AI-платформа: готовая среда для AI-приложений

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

В зависимости от поставщика в неё могут входить:

• каталог моделей;
• управляемый RAG;
• базы знаний и векторный поиск;
• конструкторы AI-агентов;
• подключение функций и внешних инструментов;
• guardrails и фильтрация данных;
• оценка качества;
• мониторинг и трассировка;
• управление доступом;
• выделенные вычислительные ресурсы.

Российские примеры:

• Yandex AI Studio — модели, API, RAG, инструменты и создание агентов;
• Cloud.ru Evolution AI Factory — Foundation Models, Managed RAG, AI Agents, ML Inference, дообучение и среды разработки.

Международные примеры:

• Amazon Bedrock — управляемый доступ к моделям, Knowledge Bases, Agents, Flows и Guardrails;
• Microsoft Foundry — платформа для создания, развёртывания, мониторинга и управления AI-приложениями и агентами;
• Google Gemini Enterprise Agent Platform — среда для работы с моделями, RAG и корпоративными агентами.

Главное отличие от обычного LLM API заключается в объёме ответственности.

При использовании только API компания получает модель и самостоятельно строит вокруг неё всю систему. Управляемая платформа предоставляет значительную часть этой системы как готовые облачные сервисы.

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

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

4. Собственная модель на арендованном GPU

Компания арендует сервер или вычислительный инстанс с GPU и самостоятельно разворачивает модель с открытыми весами.

Часто такой подход называют запуском open-source-модели. Однако точнее говорить именно об открытых весах: разные модели распространяются по разным лицензиям, и доступность весов не всегда означает полную свободу использования, изменения и распространения.

В этом сценарии компания самостоятельно выбирает:

• модель и её версию;
• размер и тип квантизации;
• параметры инференса;
• программный сервер;
• регион размещения;
• правила хранения журналов и запросов;
• способ масштабирования.

Развёрнутую модель можно предоставить внутренним приложениям через стандартный API. Например, vLLM позволяет запустить сервер, совместимый с рядом интерфейсов OpenAI API, поэтому прикладному сервису не обязательно знать, используется внешняя или самостоятельно размещённая модель.

Преимущества подхода:

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

Но вместе с контролем компания получает ответственность за:

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

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

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

5. Private cloud и on-prem

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

Такой подход выбирают, когда:

• данные нельзя выводить за пределы контролируемого контура;
• необходима интеграция с закрытыми информационными системами;
• действуют специальные требования информационной безопасности;
• критична независимость от внешних AI-провайдеров;
• нагрузка велика и предсказуема.

Главное преимущество — максимальный контроль над инфраструктурой, доступом и жизненным циклом данных.

Цена этого контроля:

• капитальные затраты на оборудование;
• длительный запуск;
• резервирование вычислительных мощностей;
• собственная команда ML, DevOps и информационной безопасности;
• самостоятельное обновление моделей;
• необходимость планировать масштабирование;
• риск недозагрузки дорогостоящих GPU.

On-prem обычно оправдан не самим желанием «хранить всё у себя», а конкретными требованиями к безопасности, задержкам, интеграциям или экономике крупной нагрузки.

Что учитывать при выборе

Какие данные будет обрабатывать сервис

Нужно оценивать не только место размещения модели, но и весь путь данных:

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

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

Поэтому формулировка «сервис соответствует 152-ФЗ» сама по себе мало что говорит. Соответствовать требованиям должен весь процесс обработки, а не только облачный провайдер или дата-центр.

Какая ожидается нагрузка

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

Собственная модель может стать экономически привлекательнее при постоянном большом объёме запросов. Но сравнивать нужно полную стоимость владения:

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

Стоимость одного миллиона токенов и стоимость GPU-сервера нельзя сравнивать напрямую без модели реального использования.

Насколько важна кастомизация

API вполне подходит для собственной бизнес-логики, RAG, агентов и интеграций.

Развёртывание собственной модели становится оправданным, если нужно:

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

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

Есть ли команда для эксплуатации

Скачать модель — не значит создать production-сервис.

Для собственной инфраструктуры потребуются компетенции в ML-инженерии, DevOps, информационной безопасности и наблюдаемости. Нужно будет контролировать задержки, потребление памяти, ошибки, очереди запросов, обновления и деградацию качества.

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

Насколько критична зависимость от поставщика

Зависимость возникает не только при работе через API. Она может появиться и внутри управляемой платформы — через собственные форматы агентов, баз знаний, инструментов и мониторинга.

Чтобы снизить риски, полезно:

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

Какой вариант выбрать

Для большинства MVP оптимальный выбор — внешний API или управляемая AI-платформа. Они позволяют быстро проверить бизнес-гипотезу без вложений в GPU-инфраструктуру.

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

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

On-prem оправдан, когда его необходимость определяется закрытым контуром, требованиями безопасности, интеграциями или экономикой крупной постоянной нагрузки.

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

Главный принцип прост: начинать стоит не с покупки GPU и не с выбора самой известной модели, а с анализа данных, бизнес-процесса, рисков и экономики.