Зміст
Вступ
Після проєктування знань, пошуку та мовних моделей виникає практичне запитання: де працюватиме корпоративний ШІ? Відповідь не починається з вибору найпотужнішого сервера. Інфраструктура — це засіб досягнення бізнес-результату, а не мета проєкту.
Архітектор проєктує платформу для десятків або сотень працівників із різними сценаріями роботи, а не машину для запуску однієї моделі.
Чому це важливо
Інфраструктура є одним із найдорожчих компонентів ініціативи. Помилка призводить або до зайвих витрат, або до системи, що не витримує реального навантаження.
Цільовий час відповіді, доступність, вимоги до розміщення даних і зростання кількості користувачів впливають на архітектуру сильніше, ніж характеристики конкретного прискорювача.
Основне пояснення
Корпоративна платформа складається з кількох рівнів: інтерфейсів і прикладних систем, сервісів ШІ, пошуку та оркестрації запитів, моделей і обчислень, сховищ та засобів спостережуваності.
flowchart TD
users[Користувачі та ERP] --> services[Сервіси ШІ]
services --> rag[RAG і пошук]
rag --> llm[LLM]
llm --> compute[Прискорювачі та сервери]
compute --> storage[Сховища, моніторинг і резервування]
До закупівлі обладнання дайте відповідь на п'ять запитань: скільки користувачів працюють одночасно, який час відповіді прийнятний, які дані не можуть залишати контур, який простій допустимий і як платформа зростатиме впродовж двох-трьох років.
Модульна архітектура дає змогу незалежно розвивати обчислення, пошук, сховища та інтеграції. Один потужний сервер може підійти для обмеженого пілота, але стає єдиною точкою відмови для робочого процесу.
Корпоративний приклад
Холдинг починає зі ста користувачів, але планує підключити всі підприємства групи. Замість найбільшої конфігурації він відокремлює сервіси пошуку, зберігання знань і обслуговування моделей.
Кожен компонент масштабується за власним навантаженням. Це знижує вартість розвитку й обмежує наслідки відмови: проблема з моделлю не повинна зупиняти доступ до документів, а збільшення індексу — вимагати заміни всієї платформи.
Приклад з промислової безпеки
Експерти використовують матеріали обстежень і нормативну документацію для підготовки висновків. Навіть коротка недоступність платформи в цей період може зірвати строк робіт.
Тому резервування критичних сервісів, резервне копіювання, журналювання й перевірене відновлення мають бути закладені заздалегідь. ШІ залишається помічником експерта, але його платформа потребує надійності інших корпоративних систем.
Типові помилки
- Купувати обладнання до оцінки навантаження та сценаріїв.
- Проєктувати платформу навколо однієї моделі.
- Оцінювати лише GPU та ігнорувати мережу, сховища й дискову підсистему.
- Не передбачати моніторинг, резервування та відновлення.
- Зводити безпеку до мережевої ізоляції.
Практичні висновки
Зафіксуйте архітектурні вимоги до вибору обладнання:
- кількість одночасних користувачів і критичні сценарії;
- цільовий час відповіді та допустимий простій;
- правила розміщення й захисту даних;
- вимоги до резервного копіювання та відновлення;
- план зростання платформи й критерії масштабування.
Лише після цього обирайте сервери, прискорювачі та програмні компоненти.
Ключові тези
- Інфраструктура проєктується під бізнес-навантаження та процеси.
- Масштабованість і надійність важливіші за пікову потужність одного сервера.
- Пошук, моделі, сховища та інтеграції мають розвиватися незалежно.
- Безпека й спостережуваність стосуються всієї платформи.
- Спочатку визначаються вимоги, потім обирається обладнання.