Припиніть проєктувати інфраструктуру ШІ навколо GPU

Чому MSP слід починати з робочого навантаження, а не з обладнання

Проведіть п’ять хвилин на конференції з ШІ, і ви легко можете вийти з переконанням, що кожне успішне впровадження ШІ починається з придбання більшої кількості GPU. Це легко зрозуміти. Обладнання домінує в розмовах. Клієнти чують про системи Blackwell, мережі InfiniBand, гіпермасштабні хмари та все більші кластери ШІ. Постачальники природно схиляються до найновіших прискорювачів і найшвидших систем, бо вони захоплюючі, актуальні та відносно легко розміщувані на ринку.

Проблема не в тому, що обчислення не важливі. Вони мають надзвичайне значення.

Проблема в тому, що, починаючи з цього, організації можуть ставити не те питання. Ринок ШІ більше не перебуває у фазі експериментів. ШІ впроваджується у виробництво, компанії вкладають реальні гроші і очікують вимірюваних бізнес-результатів. Рішення щодо інфраструктури стали набагато більш вагомими, ніж два роки тому. Проте недостатньо рішень приймаються на підставі бізнес-вимог – технологічно орієнтовані рішення залишаються домінуючими.

Перше питання не повинно звучати «Який GPU нам купити?»

«Яке навантаження ми намагаємося підтримати?» має стати у центрі уваги.

Здається, це невелика зміна, але вона впливає майже на кожне інфраструктурне рішення, що слідує за нею.

Не існує стандартної інфраструктури ШІ

Одне з найбільших хибних уявлень на ринку – це думка, що існує стандартний шаблон інфраструктури ШІ. Це не так.

Ми говоримо про ШІ, ніби це єдине навантаження. Насправді ШІ охоплює величезний спектр бізнес-додатків з дуже різними вимогами. Платформа голосового ШІ не має тих самих інфраструктурних вимог, що і медичне зображення. Пошук знань відрізняється від генерації зображень. Виявлення шахрайства не схоже на предиктивну аналітику, і жодне з них не нагадує обробку відео. Усі вони використовують ШІ, просто інфраструктуру використовують по‑різному.

Ви насправді не проєктуєте інфраструктуру для «ШІ». Ви проєктуєте інфраструктуру для бізнес‑додатку, який випадково використовує ШІ. Це розрізнення має значення. Кожне навантаження ставить унікальні вимоги до інфраструктури, що його підтримує. Деякі потребують значних обчислювальних ресурсів. Інші сильно залежать від продуктивності сховища, бо постійно витягують великі набори даних. Деякі обмежені пропускною здатністю мережі, інші можуть загинути через затримку, оскільки кожен мілісекунд впливає на досвід користувача.

Існує ще одна практична реальність. Інфраструктура, для якої модель була спроектована, не завжди доступна в момент розгортання. Доступність обладнання, довгі терміни поставки або дедлайни розгортання можуть змусити організації використовувати інші GPU, прискорювачі чи конфігурації інфраструктури, ніж планувалося спочатку. Це може означати повторну оптимізацію моделі або навіть її перепроектування під доступне обладнання.

Вимоги безпеки та управління також специфічні для навантаження. Додаток, що обробляє публічну інформацію, має зовсім інші вимоги, ніж той, що працює з фінансовими транзакціями, медичними записами або власною інтелектуальною власністю. Захист даних, управління ідентифікацією та доступом, відповідність, суверенітет, резервне копіювання, відновлення та доступність не можна просто додати після розгортання – це архітектурні рішення.

Бізнес‑вимоги додають ще один шар. Наскільки швидко додаток має масштабуватись? Які експлуатаційні витрати є стійкими? Який рівень доступності потрібен бізнесу? Скільки складності організація може реально керувати? На ці питання відповідає кожен клієнт індивідуально. Ось чому не існує універсальної інфраструктури ШІ.

Організації, які починають з улюбленої хмари, апаратної платформи чи постачальника, не отримують правильну інфраструктуру ШІ. Лідери починають з навантаження і проєктують архітектуру навколо бізнес‑цілі.

Тренування привертає увагу. Інференція забезпечує бізнес‑цінність.

Захоплення індустрії тренуванням – ще одна причина, чому розмови про інфраструктуру ШІ можуть йти в неправильному напрямку.

Тренування великої мовної моделі – це надзвичайний інженерний виклик. Потрібні величезні набори даних, масивні кластери GPU, значна потужність та інфраструктура, здатна працювати на повну потужність протягом днів, тижнів чи навіть місяців. Це дорого, технічно вражаюче і природно привертає увагу.

Однак більшість організацій не будують модель наступного рубежу. Вони створюють додатки служби підтримки клієнтів, голосові системи ШІ, помічники для співробітників, асистенти знань, інструменти пошуку, платформи підсумовування документів, системи виявлення шахрайства та десятки інших практичних застосувань, використовуючи вже навчені моделі.

Це інференційні навантаження, і інференція змінює рівняння інфраструктури. Замість оптимізації виключно для максимальної обчислювальної потужності, організації можуть потребувати оптимізації під швидкі часи відповіді, низьку затримку, передбачувані експлуатаційні витрати та стабільну продуктивність.

Клієнту не важливо, наскільки потужний базовий GPU, якщо чат‑бот відповідає п’ять секунд. Абоненту не важливі специфікації кластера ШІ, якщо голосовий асистент постійно неправильно розуміє запити або затримується під час розмови. Вони просто знають, що додаток працює погано.

Тому проєктування кожного середовища ШІ так, ніби ви навчаєте базову модель, зазвичай є помилковим підходом і часто надмірно дорогим.

Мета більшості клієнтів MSP – не побудувати найбільший у світі кластер GPU. Мета – швидко, надійно, безпечно та економічно вивести ШІ‑додатки у виробництво.

Завдання – знайти правильний баланс між продуктивністю, безпекою, масштабованістю, стійкістю та вартістю для навантажень, які вони дійсно виконують.

Можливо, GPU не є вашим вузьким місцем

GPU стали зіркою інфраструктури ШІ. Вони дорогі, їх важко отримати, і їх легко порівняти, що робить їх у центрі безлічі розмов про інфраструктуру. Однак GPU може не бути тим, що стримує розвиток, коли ШІ‑додаток досягає виробництва.

«Скільки GPU нам потрібно?» – це не те питання, яке ми маємо ставити; правильніше запитати: «Що сповільнить цей додаток через шість місяців?»

Відповідь може бути десь ще в архітектурі.

Сховище – хороший приклад. Величезні обсяги даних споживаються навантаженнями ШІ, і ці набори даних зростають з часом. Навіть надзвичайно потужний GPU може витрачати цінний час у очікуванні, якщо сховище не може швидко доставляти інформацію. Ці дані також потрібно захищати, резервно копіювати, зберігати, забезпечувати їх безпеку та керувати протягом усього життєвого циклу.

Не менш важливим є мережа. Пропускна здатність, затримка, східно‑західний трафік і взаємодія між кластерами ШІ впливають на продуктивність додатка. Добре спроектоване обчислювальне середовище не може безкінечно компенсувати погано спроектовану мережу.

Також безпека має бути частиною архітектури з самого початку. Питання, які потрібно вирішити до виробництва, включають: де зберігаються конфіденційні дані, як сегментуються мережі, чи спілкуються навантаження через приватне чи публічне підключення, і як враховуються вимоги щодо відповідності та суверенітету.

Іншим легко пропущеним фактором є підключення. Хоча вони не генерують гучних заголовків, різноманітність волокна, різноманітність маршрутів, пірингові відносини та географічна близькість критично впливають на досвід користувача – не кажучи вже про стійкість платформи.

Кінцеві користувачі не знають і не цікавляться, який саме GPU знаходиться в стійці. Їх цікавить, чи відповідає додаток миттєво, чи залишає їх у очікуванні.

Фізична інфраструктура теж заслуговує уваги. Доступність електроенергії, охолоджувальна потужність, щільність стійок та можливості розширення визначають, чи може сьогоднішнє успішне розгортання вмістити майбутнє зростання.

Потім є гравітація даних. У міру розширення наборів даних переміщення петабайтів інформації між локаціями лише тому, що обчислення розташовані десь інде, стає все менш ефективним. У багатьох випадках наближення обчислень до даних може бути практичнішим і дешевшим.

Ось чому архітектура має значення.

Подумайте про гоночний автомобіль – лише тому, що у нього найкращий двигун, ще не означає, що він виграє. Трансмісія, шини, підвіска, траса і, особливо, водій – теж мають значення. Інфраструктура ШІ працює подібно.

Організації, які отримують найбільшу цінність від ШІ, не обов’язково будуть тими, у кого найбільші кластери GPU. Вони будуть тими, хто розуміє, як усі шари інфраструктури працюють разом.

Ось різниця між купівлею інфраструктури та її проєктуванням.

Рамкова модель планування, орієнтована на робоче навантаження

У MSP є можливість змінити розмову про інфраструктуру.

Замість того, щоб починати з:

• Який GPU?
• Яка хмара?
• Який постачальник?

Починайте з навантаження:

• Яку бізнес‑проблему ми вирішуємо?
• Чи це тренувальне чи інференційне навантаження?
• Яка затримка прийнятна для додатка?
• Де зберігаються дані і як швидко вони будуть рости?
• Які вимоги щодо безпеки, відповідності та суверенітету застосовуються?
• Як навантаження буде масштабуватись?
• Який рівень доступності потрібен бізнесу?
• Який рівень операційного ризику прийнятний?
• Скільки буде коштувати експлуатація цього середовища зі зростанням навантаження?

Відповіді мають визначати архітектуру. Не навпаки.

Можливість для MSP

Цей зсув змінює роль MSP.

Клієнтам не потрібен ще один партнер, здатний продавати їм інфраструктуру. Потрібен партнер, який допоможе їм приймати кращі інфраструктурні рішення.

Підхід, орієнтований на навантаження, є обов’язковим, оскільки він дає MSP можливість оцінювати обчислення, сховище, мережу, підключення, безпеку, розташування даних, доступність та вартість як частини єдиної архітектури – а не окремих закупівельних рішень.

Таким чином ви можете контролювати витрати, підвищувати продуктивність і виявляти операційні та безпекові ризики ще до того, як додатки потраплять у виробництво.

Для MSP також створюється краща бізнес‑модель.

MSP можуть будувати більш цінні повторювані сервіси навколо архітектури, розгортання, оптимізації, безпеки, управління життєвим циклом, планування місткості та безперервного вдосконалення – замість того, щоб конкурувати переважно за рахунок стискання маржинальності обладнання.

Цінність полягає не в рекомендації найновішого GPU чи нової хмарної платформи. Вона полягає у знанні, коли клієнту це потрібно, коли ні, і що ще треба проєктувати навколо цього.

Інфраструктура ШІ в кінцевому підсумку не є рішенням щодо обладнання. Це архітектурне рішення, що визначається навантаженням, даними та бізнес‑результатом, який клієнт прагне досягти.

MSP, які розуміють це розрізнення, будуть у позиції стати набагато ціннішими, ніж постачальники інфраструктури.

Вони стануть людьми, яким клієнти довіряють, допомагаючи вирішити, яку інфраструктуру вони насправді потребують.