Зміст
Вступ
Після вибору архітектури та мовної моделі постає практичне питання: на якій інфраструктурі працюватиме корпоративний ШІ. Закупівля обладнання не має бути першим рішенням. Її визначають бізнес-сценарії, вимоги безпеки та розраховане навантаження.
Чому це важливо
Недостатня конфігурація збільшує час відповіді й знижує довіру користувачів, а надмірна — підвищує вартість володіння без помітної користі. Завдання архітектора — забезпечити поточні потреби й залишити можливість розвитку без повної перебудови платформи.
Основне пояснення
Розрахунок починається не з кількості GPU, а з профілю роботи: числа одночасних користувачів, розміру моделі, обсягу бази знань, допустимої затримки, очікуваного зростання та вимог до доступності.
flowchart TD
business[Бізнес-навантаження] --> requirements[Архітектурні вимоги]
requirements --> model[Вибір моделі]
requirements --> sizing[Розрахунок інфраструктури]
sizing --> compute[CPU і GPU]
sizing --> memory[Оперативна пам’ять]
sizing --> storage[Сховище]
sizing --> network[Мережа]
Для більшості підприємств доцільно розділяти вузли виконання моделей, пошук, бази даних і моніторинг. Так кожний компонент масштабується незалежно, а відмова одного сервісу не зупиняє всю платформу. Пілоту може вистачити одного сервера, проте цільова схема має передбачати додавання вузлів.
Безпека
| Вимога | Практичне значення |
|---|---|
| Захищений контур | Корпоративні дані залишаються в дозволеному середовищі |
| Сегментація мережі | Сервіси отримують лише потрібний доступ |
| Резервне копіювання | Критичні дані можна відновити |
| Моніторинг обладнання | Відмови виявляють до зупинки сервісу |
| Керовані оновлення | Зміни інфраструктури залишаються контрольованими |
Безпеку проєктують разом з інфраструктурою, а не додають після закупівлі.
Корпоративний приклад
Промисловий холдинг запускає пілот для кількох десятків користувачів. Замість придбання максимальної конфігурації він виділяє сервер для моделі, окремі сервіси пошуку та зберігання знань і централізований моніторинг. Коли пілот підтверджує цінність, команда додає обчислювальні вузли без зміни загальної архітектури.
Приклад з промислової безпеки
Експерти працюють із проєктною документацією, архівами обстежень і нормативними матеріалами. Їм потрібні не лише якісні відповіді, а й стабільна робота під навантаженням. Тому критичні компоненти резервують, дані регулярно копіюють, а стан обладнання постійно контролюють.
ШІ допомагає фахівцеві знайти матеріали, але не знімає з нього відповідальності за висновки, що впливають на безпеку об’єкта.
Типові помилки
- Купувати обладнання до оцінки навантаження.
- Проєктувати платформу лише для першого пілота.
- Ігнорувати резервування та сховища даних.
- Вважати GPU єдиним важливим компонентом.
- Не враховувати мережу, моніторинг і супровід.
Практичні висновки
До закупівлі підготуйте прогноз навантаження, вимоги до доступності й затримки, план масштабування, схему резервування та оцінку сукупної вартості володіння. Це дозволить обирати інфраструктуру за фактами, а не за рекламними характеристиками.
Ключові тези
- Інфраструктура випливає з бізнес-навантаження та архітектури.
- GPU — важливий, але не єдиний компонент платформи.
- Розділення сервісів підвищує стійкість і спрощує розвиток.
- Безпеку та резервування закладають заздалегідь.
- Поетапне масштабування зазвичай вигідніше за максимальну конфігурацію з першого дня.