Содержание
Введение
После выбора архитектуры и языковой модели возникает практический вопрос: на какой инфраструктуре будет работать корпоративный ИИ. Начинать с покупки оборудования — распространённая, но неверная последовательность. Оборудование должно следовать из бизнес-сценариев, требований к безопасности и рассчитанной нагрузки.
Почему это важно
Недостаточная конфигурация увеличивает время ответа и снижает доверие пользователей, а избыточная — стоимость владения без ощутимой пользы. Цель архитектора — построить платформу для текущей нагрузки, которую можно развивать без полной замены.
Основное объяснение
Расчёт начинается не с числа GPU, а с профиля работы: количества одновременных пользователей, размера модели, объёма базы знаний, допустимой задержки, роста нагрузки и требований к доступности.
flowchart TD
business[Бизнес-нагрузка] --> requirements[Архитектурные требования]
requirements --> model[Выбор модели]
requirements --> sizing[Расчёт инфраструктуры]
sizing --> compute[CPU и GPU]
sizing --> memory[Оперативная память]
sizing --> storage[Хранилище]
sizing --> network[Сеть]
Для большинства предприятий разумно отделять вычислительные узлы моделей от поиска, баз данных и мониторинга. Тогда каждый компонент можно масштабировать независимо, а отказ одного сервиса не останавливает всю платформу. Для пилота может быть достаточно одного сервера; целевая архитектура всё равно должна предусматривать добавление узлов.
Безопасность
| Требование | Практическое значение |
|---|---|
| Защищённый контур | Корпоративные данные не покидают разрешённую среду |
| Сегментация сети | Сервисы получают только необходимый доступ |
| Резервное копирование | Критичные данные можно восстановить |
| Мониторинг оборудования | Отказы обнаруживаются до остановки сервиса |
| Управление обновлениями | Изменения инфраструктуры остаются контролируемыми |
Безопасность проектируют одновременно с инфраструктурой, а не добавляют после закупки.
Корпоративный пример
Промышленный холдинг запускает пилот для нескольких десятков пользователей. Вместо максимальной конфигурации он выделяет отдельный сервер для модели, сервисы поиска и хранения знаний, а также централизованный мониторинг. После подтверждения ценности команда добавляет вычислительные узлы, не меняя общую схему.
Пример из промышленной безопасности
Эксперты работают с проектной документацией, архивами обследований и нормативными материалами. Им важны не только качество ответа, но и устойчивость системы в периоды высокой нагрузки. Поэтому ключевые компоненты резервируются, данные регулярно копируются, а состояние оборудования постоянно наблюдается.
ИИ помогает специалисту быстро находить материалы, но не снимает с него ответственность за выводы, влияющие на безопасность объекта.
Типичные ошибки
- Покупать оборудование до оценки нагрузки.
- Проектировать платформу только под первый пилот.
- Игнорировать резервирование и хранение данных.
- Считать GPU единственным важным компонентом.
- Не учитывать сеть, мониторинг и сопровождение.
Практические выводы
До закупки подготовьте прогноз нагрузки, требования к доступности и задержке, план масштабирования, схему резервирования и оценку совокупной стоимости владения. Эти документы позволяют выбирать инфраструктуру по фактам, а не по рекламным характеристикам.
Ключевые тезисы
- Инфраструктура следует из бизнес-нагрузки и архитектуры.
- GPU — важный, но не единственный компонент платформы.
- Разделение сервисов повышает устойчивость и упрощает рост.
- Резервирование и безопасность закладываются заранее.
- Поэтапное масштабирование обычно выгоднее максимальной конфигурации с первого дня.