Архитектура ИИ под бизнес: железо, задержки и масштабирование
Разберём прикладной подход к внедрению ИИ в бизнесе: выбор модели (API против open-source/on-prem), архитектуру развертывания (облако, локально, гибрид), требования к инфраструктуре и безопасности данных, инструменты быстрого старта и практические кейсы с измеримым ROI. Диалог с Андреем Киселёвым, генеральным директором ИТ-ГРАД сфокусирован на решениях, которые можно запустить в короткие сроки и поддерживать в промышленной эксплуатации.
Во второй части: где уместен on-prem и где облако, как собрать гибрид, какое «железо» выбирать, как масштабировать, что положить в быстрый MVP-стек, базовые практики безопасности и права, приоритетные кейсы, а также как считать TCO и выстроить цикл улучшений.
Фото Катерина Малама
Зачем запускать ИИ у себя на серверах: данные, комплаенс, стоимость, SLA — реальные доводы «за» и «против»?
Это решение, которое всегда сводится к балансу между контролем и удобством.
В первую очередь, это вопрос безопасности и комплаенса. Если вы работаете в банковском секторе, здравоохранении или с персональными данными, то передача информации третьей стороне — это просто неприемлемый риск. Вам не остается ничего другого, кроме как запускать ИИ-модели на своих серверах.
Второй ключевой аргумент — долгосрочная экономика. Своя инфраструктура — это высокие первоначальные затраты, но зато стоимость одного запроса со временем стремится к нулю.
И еще важно помнить про производительность и независимость. В локальной среде ваша скорость работы гораздо менее зависима от сторонних факторов. Вы сами задаете стандарты надежности (SLA) и можете гарантировать отклик в десятки миллисекунд, что критично для систем, работающих в реальном времени. Например, в колл-центрах или системах биржевой аналитики.
Как и у любого решения, здесь есть и свои минусы. Пока вы будете месяц закупать и настраивать серверы, ваш конкурент, использующий API, уже запустит и протестирует три пилота. Облако идеально для стартапов и экспериментов, когда нельзя предсказать нагрузку.
Кроме того, рынок ИИ-решений сейчас развивается невероятно стремительно. Пока вы поддерживаете свою развернутую полгода назад модель, компании уже выпустили следующее поколение. Постоянно работать с актуальными решениями в рамках локальной инфраструктуры — дорого и требует сильной команды.
Как выглядит здравый гибрид: что оставить локально, что унести в облако и как связать это безопасно?
Все, что жизненно важно для бизнеса, остается внутри. Все, что дает масштаб и гибкость — может жить в облаке. Безоговорочно держать в своем контуре стоит любые первоисточники. Это базы данных с клиентами, транзакциями, медкартами — то, утечка чего равносильна катастрофе. Также локально стоит оставить векторные базы, где хранятся кусочки внутренних документов, регламентов и т.д. Это ваша корпоративная память, грубо говоря, «мозги» RAG-систем. Эти данные не нужно никуда выносить.
Еще храните у себя критичные модели. Я имею в виду те ИИ-процессы, что принимают финальные решения на основе этих чувствительных данных. Например, скоринговая модель в банке или система диагностики в клинике. Их работа должна быть полностью изолирована.
Фото Катерина Малама
В облако с чистой совестью можно отдать мощные, но общие API-модели через API, все среды для тестирования и обучения новых моделей на обезличенных данных, а также мониторинг и аналитику.
Чтобы все это безопасно связать, создается многоуровневая система. Сначала настраиваются выделенные каналы связи. Дальше ставятся «умные шлюзы», которые проводят запросы в облако через процедуру обезличивания. В облаке работа ведется уже с анонимными данными. А когда шлюз получает ответ, он как бы «подставляет» обратно реальные значения уже внутри периметра.
Еще, чтобы взаимодействие между системами шло не напрямую, а через асинхронные очереди, используется надежный «буфер». Если облако «ляжет» на минуту, локальная система просто положит задачу в очередь, и она выполнится, когда связь восстановится.
Как подобрать сервер под инференс/дообучение и к каким задержкам готовиться?
Для эксплуатации модели, то есть инференса, главный критерий — это видеопамять. Можно ее сравнить со столом, на котором собирается конструктор. Чем больше этот стол — тем более сложную модель можно собрать.
В большинстве прикладных задач, таких как чат-боты, анализ текстов или классификация, достаточно одной современной игровой видеокарты с большим объёмом памяти. Например, NVIDIA RTX 4090 на 24 ГБ. Остальные компоненты — быстрый SSD-диск и достаточный объем оперативной памяти — играют роль поддержки. Они обеспечивают быструю загрузку данных и стабильную работу системы в целом.
Если же вы собираетесь модель дообучать, требования взлетают в разы. Для серьезной работы уже необходимо выбирать профессиональные карты вроде NVIDIA A100. У них и память побольше, и архитектура заточена под такие задачи. Часто их нужно сразу несколько штук.
Если говорить о задержках, то при правильной настройке на стартовой конфигурации для моделей среднего размера (например в 7 миллиардов параметров) можно ожидать задержку в пределах 200-500 миллисекунд. Для человека это ощущается как естественная пауза в разговоре.
Если вы используете более крупную модель (скажем, на 70 миллиардов параметров), готовьтесь к задержкам от 1 до 3 секунд. Тут уже пользователь почувствует, что он «ждет ответа». Это может быть приемлемо для фоновой генерации отчета, но не для быстрого чата.
Ситуация с NVIDIA A100 иная — это не просто еще больше мощности, а иная архитектура, заточенная на стабильность и эффективность на масштабе. Для моделей в 70 миллиардов параметров и более A100 обеспечит задержки в районе 0.7–2 секунд. Но здесь главное преимущество даже не в абсолютной скорости на один запрос, а в способности обслуживать десятки и сотни таких запросов одновременно без увеличения задержек.
На моделях меньшего размера A100 может показывать схожие с топовыми игровыми картами результаты (200-400 мс). Но опять же, ее сила — в параллелизме и стабильности 24/7 под высокой нагрузкой.
В общем, если вам нужен отзывчивый AI-ассистент для небольшой команды — хватит и мощной игровой карты. Но если вы строите платформу, которая должна стабильно отвечать тысячам пользователей — без профессиональных решений не обойтись.
Когда масштабироваться вертикально (больше GPU в узле), а когда горизонтально (ещё узлы/кластер)?
Выбор между наращиванием мощности одного сервера и добавлением новых машин — это, по сути, выбор между производительностью одного запроса и пропускной способностью всей системы.
При вертикальном масштабировании максимально увеличивается мощность одного сервера. Несколько мощных GPU связываются сверхскоростными соединениями вроде NVLink. Таким путем идут, когда, например, очень большая модель просто физически не помещается в память одной видеокарты. Чтобы заставить ее работать, приходится объединять память нескольких карт в одном корпусе.
Кроме того, общение между видеокартами внутри одного сервера происходит в сотни раз быстрее, чем пересылка данных между разными серверами по сети. Если задержки критичны для системы, тогда стоит держать все в одном узле. Еще на одном мощном сервере с 4-8 GPU часто проще и эффективнее организовать процесс обучения, чем синхронизировать десятки маленьких машин.
Но такой сервер становится «единой точкой отказа». Если он сломается — вся ваша вычислительная мощь разом отключится. И рано или поздно вы упретесь в физический потолок масштабирования.
Чтобы избежать таких рисков, значительно повысить бесперебойность, используют несколько хороших, но не самых мощных серверов. Горизонтальное масштабирование еще подходит в тех случаях, когда нужно не ускорить один запрос, а обрабатывать десятки тысяч параллельных. Для работ со скачущей нагрузкой тоже подходит такое решение. В облаке, например, можно автоматически добавлять серверы в час пик и отключать их, когда нагрузка спадает. Так экономятся значительные деньги.
Главная сложность при таком подходе заключается в управлении. Нужны системы оркестрации вроде Kubernetes, чтобы этот «зоопарк» серверов работал как единое целое.
Фото Катерина Малама
Инструменты для «MVP за неделю»: чем собрать прототип ассистента/поиск по базе знаний (Ollama/vLLM, LangChain/LlamaIndex, векторные БД и т. п.)?
Сейчас для такого прототипа есть четкий стек, который стал практически отраслевым стандартом для быстрого старта. В качестве движка для моделей обычно берут Ollama. Его главное преимущество в том, что он разворачивается буквально одной командой и сразу использует GPU. Вы можете за несколько минут запустить современную модель, чтобы сразу приступить к прототипированию.
Для создания логики поиска по документам — того, что называется RAG — идеально подходит LlamaIndex. Этот фреймворк специально заточен под работу с вашими данными. Он умеет загружать PDF-файлы, базы знаний, разбивать их на осмысленные фрагменты и настраивать интеллектуальный поиск.
В качестве хранилища для этих знаний используют векторную базу данных Chroma. Ее главная прелесть в том, что она легковесная и запускается прямо из кода, не требуя сложного администрирования. Это идеальное решение для прототипа, когда нужно сосредоточиться на функциональности, а не на инфраструктуре.
Ну и вишенка на торте — интерфейс. Здесь на помощь приходит Streamlit. Этот инструмент позволяет буквально за пятнадцать минут и несколько десятков строк кода создать веб-интерфейс, который можно сразу тестировать с коллегами.
Конечно, такой прототип — это не промышленная система. Но это уже мощный инструмент, который позволяет быстро доказать ценность идеи и получить зеленый свет на полноценную разработку.
Как организовать безопасность: изоляция сред, шифрование, логирование запросов/ответов, DLP и «защитные перила» (guardrails) от утечек через промпты?
Начинается все с жесткой изоляции сред. Инфраструктура размещается в защищенном сетевом сегменте, куда нет прямого доступа извне, а общение между компонентами шифруется по принципу mutual TLS, когда каждый сервис должен доказать свою легитимность.
Самое интересное — это «защитные перила» для самой модели. Система проверяет и фильтрует все запросы и ответы в реальном времени. Входящие промпты анализируются на предмет попыток инжекции или доступа к запрещенным темам. Перед обработкой моделью все конфиденциальные данные — имена, номера, реквизиты — автоматически заменяются на абстрактные токены. Фактически, модель работает с обезличенной информацией, а оригинальные данные подставляются только в финальном ответе пользователю.
При этом ведется полный аудит: все запросы и ответы логируются в обезличенном виде. Логи позволяют расследовать инциденты и понимать, почему модель приняла то или иное решение. Финальное — интеграция с классическими DLP-системами, которые контролируют исходящий трафик на предмет утечек уже на сетевом уровне. Если даже один уровень защиты в такой системе будет преодолен, следующие эшелоны гарантированно остановят потенциальную утечку. Это позволяет безопасно применять ИИ даже в самых чувствительных бизнес-процессах.
На что обратить внимание в праве: персональные данные, лицензии датасетов, авторские права при дообучении?
Прежде всего — это работа с персональными данными. Любая информация, позволяющая идентифицировать человека, попадает под жесткое регулирование. Уже на этапе сбора данных нужно сразу определить законное основание для их обработки, будь то согласие или договор. Крайне важно максимально обезличивать такие данные перед загрузкой в модель.
Второй критичный момент — лицензии датасетов. Далеко не все, что можно скачать в интернете, можно использовать в коммерческом продукте. Нужно всегда тщательно проверять лицензионные соглашения, обращая особое внимание на ограничения. Например, многие наборы данных разрешены только для академических или некоммерческих целей. Это же касается и лицензий самих моделей — даже у открытых решений часто есть свои ограничения для крупных коммерческих пользователей.
Наверно, самая сложная тема — авторские права при дообучении. Если модель обучается на защищенном контенте без разрешения правообладателей — это прямой путь к судебным искам. Нужно внимательно анализировать происхождение данных для обучения и стараться создавать собственные «чистые» датасеты из контента, на который у компании есть бесспорные права.
Топ-3 задач, которые реально дают эффект сейчас (поддержка L1, поиск по документам, генерация деловых документов/саммари) — и один пример, где лучше подождать.
Если говорить о самых эффективных точках приложения сил для ИИ сегодня, я бы выделил три направления, где мы стабильно видим быстрый и измеримый эффект.
Первое — это автоматизация рутинной поддержки. Внедрение чат-бота, который закрывает до 80% типовых вопросов об отслеживании заказов или возвратах, дает моментальную разгрузку операторов и сокращает издержки. Экономика здесь считается уже буквально через несколько дней.
Второе — это поиск по внутренним документам. Вместо бесконечного листания сотен страниц регламентов сотрудник задает вопрос на естественном языке и за минуту получает точный ответ, собранный из разных источников. Это радикально ускоряет принятие решений и обучение новых сотрудников.
Третья область — это помощь в составлении документов. ИИ отлично справляется с ролью стажера, который готовит черновики писем, саммари встреч или стандартных коммерческих предложений. Это не замена эксперту, а его усиление, экономящее ему до 40% времени на рутине.
А вот от поручения ИИ полностью самостоятельного создания сложных стратегических документов или юридических заключений я рекомендую воздержаться. По крайней мере пока. Без глубокого контроля эксперта и постоянных правок такие тексты часто оказываются поверхностными и требуют почти полной переделки, сводя на нет всю потенциальную экономию.
Как считать TCO и оптимизировать расходы (модель меньше, квантование, кэширование, батчинг)? Как выстроить цикл улучшений: фидбэк → ретрейнинг → A/B-тесты → мониторинг «галлюцинаций»?
Когда мы говорим о промышленной эксплуатации ИИ, расчет полной стоимости владения выходит далеко за рамки аренды серверов. Сюда входит инфраструктура, разработка и — что часто упускают — операционные расходы на мониторинг и постоянные дообучения.
Часто для решения задач не нужно выбирать самые мощные модели. Небольшая, но грамотно дообученная модель окажется и дешевле, и быстрее гигантов. Еще для оптимизации применяется квантование, то есть сжатие модели, которое в разы ускоряет работу с минимальной потерей качества. Еще активно используется кэширование повторяющихся запросов и батчинг — групповая обработка задач, что повышает пропускную способность и снижает стоимость одного запроса.
Что касается цикла улучшений, все начинается со сбора обратной связи и анализа поведения пользователей. На основе этих данных модель дообучается, точечно исправляются ее слабые места.
Конечно, прежде чем выпускать обновление для всех, обязательно проводите A/B-тесты. Здесь-то как раз и пригодятся реальные бизнес-метрики, по которым стоит сравнивать новую версию со старой. Еще отмечу, что в рамках постоянного мониторинга стоит отслеживать не только классические метрики, о которых я уже говорил, но и специфические риски. Например, появление «галлюцинаций» или дрейф данных, когда запросы пользователей со временем меняются, и модель теряет релевантность.
Мы все еще находимся на этапе активного развития ИИ-решений. И если вы начали внедрять их в свои бизнес-процессы, то будьте готовы управлять ими не как статичным продуктом, а как живым активом, который требует постоянного обновления данных и регулярного тестирования.