Проєктування довговічної інфраструктури для обслуговування ШІ

Наступна конкурентна перевага у сфері корпоративного ШІ пов’язана не стільки з тим, яку модель ви обираєте, скільки з тим, що ви навколо неї створюєте.

Це важливий зсув. Протягом останніх кількох років значна частина розмов про ШІ була зосереджена на можливостях моделей: більші моделі, краще міркування, більші контекстні вікна, вищі результати тестів. Ці досягнення були надзвичайними. Але в міру переходу ШІ від експериментів до промислового використання питання, що стоїть перед керівниками підприємств, змінилося — тепер уже не «що може зробити модель?», а «чи можемо ми забезпечити надійну, економічно ефективну та масштабовану роботу цього інтелекту?»

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

Для технічних керівників це змінює напрям інвестицій у ШІ — і вимоги до архітектури, що його підтримує.

Починайте з робочого навантаження, а не з моделі

Не існує універсально «найкращої» моделі чи архітектури ШІ. Існує лише правильне рішення для конкретної бізнес-проблеми.

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

Робоче навантаження визначає обмеження. Обмеження мають визначати архітектуру.

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

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

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

Проєктуйте систему, а не модель

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

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

Пам’ять GPU — хороший приклад. Під час інференсу ваги моделі залишаються незмінними, але кеш ключів-значень (KV) зростає разом із кількістю активних запитів і довжиною контексту. У міру збільшення одночасності система може вичерпати доступну пам’ять GPU, навіть якщо обчислювальні потужності ще є. Додавання обчислювальних ресурсів без розуміння цього вузького місця може лише зробити неефективну систему дорожчою.

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

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

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

Створюйте з урахуванням змін, а не сьогоднішніх тестів

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

Це робить адаптивність дедалі важливішим результатом стратегії у сфері ШІ.

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

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

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

Модель надає інтелект. Контур визначає, чи може підприємство надійно, економічно та масштабовано забезпечувати результати.

Цей матеріал підготовлено компанією EXL. Його написали не редактори MIT Technology Review.