Как мы разворачивали универсального ИИ-агента в приватном контуре
О проекте
Нужно было создать не облачный сервис, а полноценного цифрового ассистента, который можно запустить во внутреннем контуре компании или у частного лица. Чтобы он делал все то же самое, что и облачные LLM: отвечал на запросы, работал по агентным сценариям, общался с внешними сервисами и автоматизировал рутину.
Самый важный момент заключается в том, как именно поставляется решение. Вместо удалённого API клиент получает физический сервер, который ставится локально, у него «под столом» или в его внутренней сети. На этом сервере запускаются открытые языковые модели, которые мы дообучаем под конкретные задачи бизнеса или пользователя. Чувствительные данные при таком подходе не покидают инфраструктуру заказчика – никаких утечек промптов, документов или результатов генерации к внешним хостингам LLM.
Речь идет не просто о запуске ИИ-помощника на локальной машине, а о построении полноценной платформы для приватного искусственного интеллекта: с вычислительными ресурсами, оркестрацией, инструментами для деплоя, возможностью работать автономно и с поддержкой агентских систем, которые клиент сам разрабатывает поверх этой инфраструктуры.
Задача
Участие разработчиков Evrone в проекте заключалось в том, чтобы организовать поставку, настройку и запуск такого решения, включая сценарий работы вообще без интернета. На практике, конечно, большинство подобных систем используют гибридный режим и взаимодействуют с внешними сервисами. Но архитектура должна поддерживать и полностью автономный вариант – для предприятий с жесткими требованиями к безопасности или для изолированных контуров, где внешняя сеть просто недоступна по политике компании.
Работу разбили на несколько частей.
Первое – профилирование оборудования. Под каждую задачу, под конкретную модель и под ожидаемую нагрузку нужно было найти железо, которое даст нормальную скорость инференса и будет стабильно работать в продакшене.
Второе – развернуть и настроить программный стек: инфраструктуру, оркестрацию, инструменты для инференса, систему обновлений и доставки приложений.
Третье – протестировать сами LLM и форматы весов, чтобы понять, что лучше подходит: требования к скорости, совместимость, наличие ограничений на уровне платформы.
Подбор железа
Если говорить про минимальную конфигурацию для запуска масштабных моделей, то порог входа высокий, а для топовых LLM в приватном контуре нужен серьёзный GPU-кластер. В нашем проекте минимальная конфигурация - это сервер enterprise-уровня на 8 видеокартах Nvidia H100. Это уже не экспериментальная сборка за небольшую сумму, а дорогая промышленная инфраструктура на десятки миллионов рублей.
Мы собрали enterprise-оборудование, на котором можно стабильно запускать мощные языковые модели и встраивать их в реальные бизнес-процессы. Потому что локальный ИИ перестаёт быть «демо на ноутбуке» и становится сервисом, который должен держать нагрузку, обслуживать сценарии пользователей и быть предсказуемым с точки зрения эксплуатации.
При этом проект не ограничивается только тяжелыми конфигурациями. Если нужен не кластер для универсального агента, а более компактный помощник, архитектуру можно упростить. Например, использовать Mac Studio и запускать ИИ-асситента в более легком режиме. То есть вместо одного большого enterprise-сервера можно собрать компактное решение под ограниченный круг задач с моделями меньшего размера.
В силу специфичных задач клиента, для управления и развёртывания использовался Kubernetes и распределённый инференс , чтобы вычисления могли масштабироваться на несколько GPU и несколько узлов. Это открывает дополнительный сценарий, позволяя не просто усиливать один сервер вертикально, а объединять несколько машин в единое программное решение. Таким образом можно собрать кластер даже из нескольких компактных устройств, если это имеет смысл для задачи и оптимизации затрат.
Настройка ПО
Невозможно ограничиться только железом, немаловажную роль играет софт, который позволяет моделям работать стабильно, предсказуемо и управляемо.
В рамках проекта мы настраивали ПО для запуска инференса и адаптировали открытые языковые модели под конкретные пользовательские и бизнес-сценарии. Это включало не только развертывание инструментов, но и тестирование их совместимости с разными форматами моделей, режимами вычислений и целевой инфраструктурой.
В процессе работы мы протестировали практически все популярные инструменты для запуска LLM на своём железе: vLLM, Ollama, llama.cpp, mistral-rs и SGLang. И это важный момент, потому что в мире open source до сих пор нет по-настоящему универсального стандарта запуска. Формально спецификации есть, но на практике все остается фрагментированным.
Проблема в том, что открытые языковые модели существуют в нескольких форматах: Safetensors, GGUF и MLX. Каждый заточен под свои сценарии и платформы. Например, MLX сильнее привязан к Apple Silicon, GGUF часто используют для более компактных сценариев локального запуска, а Safetensors распространён в классическом Linux-окружении и серверных конфигурациях. Универсального инструмента, который одинаково хорошо покрывает все форматы, все типы моделей и все инфраструктурные сценарии, пока нет.
Поэтому запуск LLM в приватном контуре не ограничивается задачей «подними один контейнер и нажми Старт», он подразумевает целую серию инженерных компромиссов, которые должны учитывать, что где-то модель лучше работает через vLLM, где-то – через Ollama, где-то – через SGLang, а проектирование такой платформы неизбежно включает фазу глубокого тестирования.
Тестирование, выбор моделей и методов запуска
На этапе испытаний мы запускали разные модели, которые помещались в доступную память кластера. Среди них были GLM и Qwen, а по итогам тестов рабочим вариантом стал актуальный Qwen 3.5. Параллельно подбирали оптимальный способ запуска.
Как наиболее универсальное решение выбрали SGLang. Его преимущество – в более гибкой поддержке форматов: он работает и с Safetensors, и с GGUF, что особенно полезно в Linux-инфраструктуре. Для проекта, где важно не просто однократно поднять модель, а иметь работающую платформу под разные сценарии, такая универсальность оказалась решающей.
Выбор модели и рантайма упирался не только в совместимость, но и в производительность. Некоторые конфигурации давали слишком низкую скорость – около 20 токенов в секунду. Для реальных агентных сценариев этого мало, потому что при таких условиях система становится заметно менее отзывчивой, особенно если она должна обрабатывать длинные цепочки рассуждений или несколько последовательных операций.
В рабочей конфигурации удалось получить около 160 токенов в секунду. Да, это все еще не сравнимо с производительностью крупных коммерческих облачных сервисов, за которыми стоят гигантские дата-центры и специализированные стеки оптимизации. Но для приватного контура это уже практический уровень: модель остается локальной, данные не покидают инфраструктуру заказчика, а качество ответов и интеллектуальные возможности сопоставимы с тем, что бизнес обычно ждет от современных облачных LLM.
В этом и есть основной компромисс: немного проиграть облаку в абсолютной скорости, но выиграть в контроле, конфиденциальности и независимости.
Сколько времени ушло
За три недели мы собрали инфраструктуру, задеплоили приложения, протестировали модели и подобрали рабочую конфигурацию.
Еще неделя ушла на скачивание моделей, профилирование, замеры производительности и тесты совместимости с агентскими системами клиента. При планировании сроков подобных проектов нужно всегда учитывать, что часть времени приходится не на «установку», а на инженерную доводку – проверку того, как модели реально ведут себя в конкретной инфраструктуре.
Текущий статус
Проект уже перешёл из статуса MVP в рабочую инфраструктуру. Сформирован набор инструментов, понятен стек, автоматизированы процессы поставки и обновления.
Для настройки инфраструктуры использовали классический GitOps-подход: все конфигурации описывались декларативно, для доставки изменений применяли Argo CD и Kubernetes. Это сделало систему воспроизводимой и удобной для передачи на сторону клиента.
В результате агентские системы, которые разрабатывает заказчик, автоматически выкатываются в контур и могут работать как с доступом в интернет, так и локально. На практике большинство таких систем раскрывает максимум пользы именно при доступе к внешним сервисам и данным. Но архитектура допускает и другой сценарий: подключить только внутренние системы предприятия, полностью отключив выход во внешнюю сеть. Для многих отраслей это не опция «на всякий случай», а обязательное требование.
Команда Evrone выступает в роли экспертного интегратора. После завершения проекта инфраструктура и подходы были переданы инженерам клиента. Сейчас система уже эксплуатируется и поддерживается внутренней командой заказчика без постоянного внешнего участия.
Команда для разработки приватного ИИ
Если смотреть на такой проект как на продукт, который можно продать, то базовая команда будет выглядеть следующим образом:
- Два инженера-разработчика, которые параллельно работают над агентскими системами и бизнес-логикой. Это могут быть Python или TypeScript – выбор языка не принципиален, если команда умеет строить надежные интеграции, оркестрационный слой и прикладную логику поверх LLM.
- ML-инженер. Его роль критична: он отвечает за понимание того, как подбирать и настраивать большие языковые модели, как проводить бенчмарки, готовить данные, проектировать промпты и интерпретировать реальное поведение моделей, а не их теоретические возможности на бумаге.
- DevOps-инженер, потому что без зрелой инфраструктуры приватный ИИ быстро превращается в нестабильный стенд. Здесь важны оркестрация, автоматизация поставки, мониторинг, управление ресурсами и воспроизводимость среды.
- Аналитик. В таких проектах его роль часто недооценивают. Универсальный агент создается не «вообще», а под конкретные пользовательские ожидания, сценарии и ограничения. Кто-то должен перевести бизнес-потребности в формализованные требования: понять, какие действия должен выполнять агент, где нужны ограничения, какие внешние системы подключать, а какие изолировать. Без этого агентская система рискует остаться красивой технической демонстрацией, но не рабочим инструментом.
Вывод
Проект, над которым мы работали, хорошо показывает, что персональный и приватный ИИ-помощник сегодня – уже не теоретическая концепция, а вполне реализуемая инженерная практика. Да, она требует серьезного железа, аккуратного выбора и тестирования моделей, зрелой инфраструктурной культуры. Но результатом становится платформа, где заказчик контролирует и вычисления, и данные, и жизненный цикл всей системы. Запуск решений в приватном контуре может стать безальтернативным инструментом в работе государственных информационных систем, банковского сектора, и владельцев корпоративных сетей с критической информацией.
Главный вывод простой: если бизнесу нужен не просто доступ к LLM, а безопасный, управляемый и локально развернутый интеллектуальный контур, такую систему можно построить уже сейчас. Причём не как разовый эксперимент, а как основу для дальнейшего развития агентных сервисов внутри компании.
Если вашей команде нужен приватный AI-ассистент или сервис, который работает внутри собственного контура, не отправляет данные во внешние облака и при этом остаётся пригодным для реальных бизнес-сценариев, начинать стоит не с выбора «самой новой модели», а с проектирования всей системы целиком: архитектуры, железа, стека запуска, ограничений безопасности и сценариев эксплуатации. Именно такой подход позволяет превратить LLM из впечатляющего демо в рабочий инструмент.