Облако или свой сервер: как выбрать инфраструктуру для корпоративного ИИ-агента

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

Поэтому полезнее спросить: какой компонент где должен работать с учётом данных, угроз, нагрузки и компетенций команды? Ответом нередко становится гибридная архитектура.

Сначала разделим три модели размещения

Под «облаком» понимают разные вещи. Выделим три модели.

1. Внешний AI API. Компания управляет приложением, но отправляет контекст поставщику модели. Инфраструктура запуска модели скрыта, оплата зависит от потребления.
2. Свой стек в облаке. Приложение, базы и модель развёрнуты на арендованных VM или GPU. Конфигурацией и обновлениями управляет ваша команда.
3. On-premises, или локальное размещение. Система работает на оборудовании компании. Контроль максимален, но на компании также закупки, резервирование, охлаждение, сеть и эксплуатация.

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

Постройте модель угроз до выбора железа

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

Входом становится не только сообщение пользователя. Инструкция может скрываться в PDF, письме или карточке CRM, которую агент читает через RAG – поиск по базе знаний с передачей найденных фрагментов модели. Так возникает косвенное внедрение инструкций, или prompt injection. OWASP Top 10 for LLM and GenAI также выделяет раскрытие чувствительной информации, чрезмерную автономность и неконтролируемое потребление ресурсов.

Минимальный набор мер не зависит от места размещения:

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

Следуйте принципу zero trust: сетевое расположение не основание доверять сервису. Этот подход описан в NIST SP 800-207. Агент внутри локальной сети не должен автоматически получать доступ ко всем системам.

Классифицируйте данные и их маршруты

Составьте карту данных от ввода до удаления. Что приходит из CRM и попадает в индекс? Какой фрагмент уходит модели? Где сохраняются запросы и ответы? Использует ли их поставщик? Каков срок хранения копий?

Практично разделить информацию минимум на четыре класса:

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

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

Проверяйте не только страну сервера, но и оператора, субподрядчиков, копии и телеметрию. Законодательные и договорные требования – обязательный фильтр. Для персональных данных отдельно проверьте применимость 152-ФЗ и требований локализации с профильным специалистом.

Измеряйте задержку по этапам

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

T = сеть + очередь + поиск + первый токен + генерация + вызовы инструментов

Для чата важнее время до первого токена, для фоновой задачи – полное время. При нескольких вызовах именно интеграции могут оказаться медленнее модели.

На пилоте измеряйте p50, p95 и p99 – границы, в которые укладываются 50, 95 и 99% запросов. Фиксируйте первый токен, скорость генерации, поиск, инструменты, тайм-ауты и очередь. Тестируйте из реальных офисов, с типичными документами и в часы пик.

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

Считайте TCO, а не цену токена или видеокарты

У API расходы в основном переменные. У собственного инференса они ступенчатые: GPU оплачивается при простое, а затем требуется новый узел. Сравнивайте стоимость полезной операции – обращения, документа или завершённой задачи.

Упрощённая формула месячной стоимости выглядит так:

TCO = API и инфраструктура + хранение и трафик + лицензии + эксплуатация + резервирование + ожидаемая стоимость простоев

В эксплуатацию включите инженеров, обновление драйверов, тесты, безопасность и дежурства. Для on-premises добавьте амортизацию, электричество, охлаждение и запасные компоненты. Для API – повторные запросы, контекст, построение векторов и пересортировку результатов поиска.

Снимите метрики пилота: запросы, входные и выходные токены, кэширование, параллелизм и сезонность. Посчитайте обычный месяц, пик и трёхкратный рост. Связывать расходы с полезной бизнес-единицей рекомендует и FinOps Foundation.

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

Масштабируйте оркестратор и модель раздельно

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

Для оркестратора важны запросы в секунду и очередь; для модели – токены в секунду, память GPU, размер пакета, ожидание и соблюдение целевого уровня сервиса. Масштабирование только по CPU не покажет перегрузку модели.

Kubernetes назначает GPU через device plugins и масштабирует workloads по пользовательским метрикам. Но небольшой компании не обязательно начинать с кластера: один контейнер и понятное восстановление надёжнее Kubernetes без компетентной команды.

API или своя модель

API подходит для быстрого запуска и переменной нагрузки. Он снимает заботы о драйверах и резерве GPU, но добавляет зависимость от сети, лимитов, цен и изменений поставщика.

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

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

Обновления должны быть воспроизводимыми

На поведение влияют модель, промпт, схема инструментов, поиск, модель векторизации, разбиение документов и база знаний.

Фиксируйте их версии. Перед релизом проверяйте качество, запрещённые действия, prompt injection, права, время и стоимость. Выпускайте изменения на небольшой группе и сохраняйте путь отката. Критичные действия требуют детерминированных правил и подтверждения человеком.

Риски на всём жизненном цикле помогает структурировать NIST AI RMF Generative AI Profile.

Наблюдаемость: видеть не только uptime

HTTP 200 ещё не означает, что агент выполнил задачу правильно. Нужны три уровня метрик:

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

Создавайте единый trace – маршрут запроса – и отдельные этапы для авторизации, поиска, модели и инструментов. OpenTelemetry объединяет трассировки, метрики и логи и подходит для облака и on-premises.

Телеметрия сама становится чувствительным хранилищем. Не пишите туда документы и секреты «на всякий случай»: используйте маскирование, ограниченный срок хранения и идентификаторы.

Когда гибрид лучше крайностей

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

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

Матрица выбора

Сначала исключите варианты, не прошедшие обязательные требования. Остальные оцените с весами, например: безопасность – 30%, качество – 25%, TCO – 20%, задержка – 15%, запуск – 10%.

Чек-лист перед решением

1. Какие действия агент может выполнять, а не только предлагать?
2. Какие данные проходят через каждый компонент и где остаются их копии?
3. Какие классы данных разрешено передавать внешним поставщикам?
4. Нужна ли работа при отключённом интернете?
5. Каковы целевые p95 для первого токена и завершения задачи?
6. Как выглядит обычная, пиковая и трёхкратно выросшая нагрузка?
7. Сколько стоит одна полезная операция во всех трёх вариантах?
8. Есть ли в команде люди для круглосуточной эксплуатации GPU и модели?
9. Как ограничены права инструментов, расходы и число шагов агента?
10. Какие логи нужны для аудита и что в них запрещено сохранять?
11. Как тестируются новая модель, промпт, индекс и коннекторы?
12. Что произойдёт при отказе модели, сети, базы знаний или внешней системы?
13. За сколько минут можно откатить релиз и восстановиться из резервной копии?
14. Можно ли сменить поставщика модели без переделки всего приложения?

Вывод

Универсального победителя нет. API ускоряет запуск, свой стек в облаке даёт больше контроля без закупки площадки, on-premises – автономность. Начните с карты данных и пилота, измерьте качество, p95 и стоимость полезной операции, затем выбирайте по цифрам.

AiHummer – один из примеров платформ, поддерживающих облачное и локальное размещение; конкретную схему выбирают по требованиям организации к данным, интеграциям и эксплуатации.