інтерв'ю Минулого тижня завершилася конференція Nvidia GPU Technology Conference, на якій було обговорено чіпи компанії Blackwell і галасливі чудеса штучного інтелекту з усіма дорого придбаними графічними процесорами.
Навколо компанії такий галас, що ціна її акцій заграє з рекордно високими рівнями, базуючись на уявленні про те, що багато творчих починань можна зробити швидше, якщо не краще, завдяки автоматизації, яка підтримується моделями машинного навчання.
Це все ще тестується на ринку.
Одного разу Джордж Сантаяна пише: «Ті, хто не може згадати минуле, приречені повторювати його». Це фраза, яку часто повторюють. Проте спогади про минуле насправді не відрізняють моделі ШІ. Вони можуть пам'ятати минуле, але вони все одно приречені повторювати його на вимогу, іноді неправильно.
Незважаючи на це, багато хто клянеться всемогутнім штучним інтелектом, особливо ті, хто продає апаратне забезпечення ШІ або хмарні сервіси. Nvidia, серед іншого, робить на це велику ставку. Так Реєстр коротко завітав на конференцію ГПУ, щоб побачити, до чого тут галас. Йшлося, звичайно, не про батончики з лимоном, які подавали у виставковому залі в четвер, багато з яких завершили свою первинну публічну пропозицію незавершеними в контейнерах на виставковому майданчику.
Набагато привабливішою була розмова Реєстр провів з Карі Бріскі, віце-президентом із управління продуктами для комплектів розробки програмного забезпечення AI та HPC у Nvidia. Вона очолює керування програмними продуктами для базових моделей компанії, бібліотек, SDK, а тепер і мікросервісів, які займаються навчанням і висновками, як-от нещодавно анонсований NIM мікросервіси та краще встановлені немо структура розгортання.
Реєстр: Як компанії збираються використовувати ці мікросервіси – у хмарі, на місці?
Брискі: Насправді в цьому полягає вся принадність того, чому ми створили NIM. Це трохи смішно говорити «НІМ». Але ми почали цю подорож давно. Ми працюємо над висновками з тих пір, як я почав – я думаю, що це був TensorRT 1.0, коли я почав 2016 рік.
Протягом багатьох років ми нарощували наш стек логічних висновків, дізнаючись більше про різні типи робочого навантаження, починаючи з комп’ютерного зору та глибоких рекомендаційних систем і мовлення, автоматичного розпізнавання мовлення та синтезу мовлення, а тепер і великих мовних моделей. Це був справді орієнтований на розробника стек. І тепер, коли підприємства [побачили] OpenAI і ChatGPT, вони розуміють необхідність мати ці великі мовні моделі, що працюють поруч із їхніми корпоративними даними або в корпоративних програмах.
Звичайний постачальник хмарних послуг має сотні інженерів, які працюють над методами оптимізації для своїх керованих послуг. Підприємства не можуть цього зробити. Їм потрібно негайно розрахувати час і цінність. Ось чому ми інкапсулювали все, чого навчилися за ці роки, за допомогою TensorRT, великих мовних моделей, нашого Triton Inference Server, стандартного API та перевірок працездатності. [Ідея полягає в тому, щоб] мати можливість інкапсулювати все це, щоб ви могли перейти від нуля до великої кінцевої точки моделі мови менш ніж за п’ять хвилин.
[Щодо локального та хмарного центру обробки даних], багато наших клієнтів є гібридними хмарами. Вони віддають перевагу обчисленню. Тож замість того, щоб надсилати дані до керованої служби, вони можуть запускати мікросервіс поблизу своїх даних і запускати його, де завгодно.
Реєстр: Як виглядає програмний стек Nvidia для ШІ з точки зору мов програмування? Це все ще переважно CUDA, Python, C і C++? Ви шукаєте в іншому місці більшу швидкість і ефективність?
Брискі: Ми завжди досліджуємо, де розробники використовують. Це завжди було нашим ключем. Тож відколи я почав працювати в Nvidia, я працював над прискореними математичними бібліотеками. По-перше, вам потрібно було запрограмувати в CUDA, щоб отримати паралелізм. А потім у нас були C API. І у нас був Python API. Отже, мова йде про те, щоб розмістити платформу там, де є розробники. Наразі розробники просто хочуть досягти дуже простої кінцевої точки API, наприклад, за допомогою команди curl або команди Python чи щось подібне. Тож це має бути дуже просто, тому що саме тут ми сьогодні зустрічаємося з розробниками.
Реєстр: CUDA, очевидно, відіграє величезну роль у забезпеченні ефективності обчислень GPU. Що робить Nvidia для просування CUDA?
Брискі: CUDA є основою для всіх наших графічних процесорів. Це графічний процесор із підтримкою CUDA, який можна програмувати за допомогою CUDA. Кілька років тому ми назвали це CUDA-X, тому що у вас були ці предметно-орієнтовані мови. Отже, якщо у вас є [додаток] для медичного зображення, у вас є cuCIM. Якщо у вас є автоматичне розпізнавання мовлення, у вас є декодер прискореного пошуку променя CUDA. І тому є всі ці специфічні речі для кожного різного типу робочого навантаження, які були прискорені CUDA. Протягом багатьох років ми створювали всі ці спеціалізовані бібліотеки cuDF та cuML, і cu-це-і-те. Усі ці бібліотеки CUDA є основою того, що ми створювали роками, і тепер ми начебто надбудовуємо це.
Реєстр: Як Nvidia дивиться на міркування вартості з точки зору способу розробки програмного та апаратного забезпечення? З чимось на кшталт Nvidia AI Enterprise це 4,500 доларів США за графічний процесор щороку, що є чималим показником.
Брискі: По-перше, для невеликих компаній у нас завжди є Початок програма. Ми постійно працюємо з клієнтами – безкоштовна 90-денна пробна версія, це дійсно цінно для вас? Чи справді воно того варте? Потім, щоб зменшити ваші витрати, коли ви купуєте це, ми постійно оптимізуємо наше програмне забезпечення. Отже, якщо ви купували 4,500 доларів США за графічний процесор на рік за ліцензію, і ви працюєте на A100, а завтра ви працюєте на H100, це та сама ціна – ваша вартість знизилася [відносно вашої пропускної здатності]. Тому ми завжди повертаємо ці оптимізації та загальну вартість володіння та продуктивність у програмне забезпечення.
Коли ми думаємо як про навчання, так і про логічний висновок, навчання вимагає трохи більше часу, але ми маємо ці автоматичні конфігуратори, щоб ми могли сказати: «Скільки у вас даних? Скільки обчислень вам потрібно? Скільки часу ти хочеш, щоб це зайняло?» Таким чином, у вас може бути менший обчислювальний відбиток, але навчання вашої моделі може зайняти більше часу… Чи хочете ви навчити її за тиждень? Або ви хочете потренувати його за день? І тому ви можете зробити ці компроміси.
Реєстр: Що стосується поточних проблем, чи є щось конкретне, що ви хотіли б вирішити, чи є технічна проблема, яку ви хотіли б подолати?
Брискі: Зараз це керується подіями ганчір'я [що є способом доповнення моделей ШІ даними, отриманими із зовнішнього джерела]. Багато підприємств просто думають про класичну підказку для створення відповіді. Але насправді ми хочемо [з’єднати] всі ці генеративні системи з доповненим пошуком разом. Бо якщо ви подумаєте про себе та про завдання, яке ви, можливо, захочете виконати: «О, я мушу піти поговорити з командою бази даних. І команда бази даних має поговорити з командою Tableau. Вони повинні зробити мені інформаційну панель», і все це має відбутися, перш ніж ви зможете виконати завдання. І тому це щось на зразок RAG, керованого подіями. Я б не сказав, що КРГ розмовляють з КРГ, але по суті це так: агенти йдуть, виконують багато роботи та повертаються. І ми на порозі цього. Тож я думаю, що я дуже радий побачити це у 2024 році.
Реєстр: Nvidia тестує власний ШІ? Чи знайшли ви ШІ корисним внутрішньо?
Брискі: Насправді ми пішли, і минулого року, оскільки 2023 рік був роком досліджень, я знайшов 150 команд у Nvidia – їх могло бути більше – і ми намагалися сказати, як ви використовуєте наші інструменти, які випадків використання, і ми почали об’єднувати всі знання, начебто від розквіту тисячі квітів, і ми ніби об’єднали всі їхні знання в найкращі практики в одному репо. Це фактично те, що ми випустили як те, що ми називаємо Приклади генеративного ШІ на GitHub, тому що ми просто хотіли мати всі найкращі практики в одному місці.
Це те, що ми зробили структурно. Але як явний приклад, я думаю, що ми написали цю справді чудову статтю під назвою ЧіпНеМо, і це насправді все про нашу команду дизайнерів EDA, VLSI і про те, як вони взяли базову модель і навчили її на наших власних даних. У нас є власні мови кодування для VLSI. Тож вони створювали копілоти [моделі генерації коду з відкритим вихідним кодом], щоб мати можливість генерувати нашу власну мову та підвищити продуктивність нових інженерів, які не зовсім знають наш код написання мікросхем VLSI.
І це викликало відгук у кожного клієнта. Отже, якщо ви спілкуєтеся з SAP, вони мають ABAP (розширене програмування бізнес-додатків), який є як пропрієтарний SQL для їх бази даних. І я спілкувався з трьома іншими клієнтами, які мали різні власні мови – навіть SQL має сотні діалектів. Таким чином, можливість генерувати код не є випадком використання, який можна негайно вирішити за допомогою RAG. Так, RAG допомагає отримувати документацію та деякі фрагменти коду, але якщо він не навчений генерувати маркери цією мовою, він не може просто створювати код.
Реєстр: Коли ви дивитесь на великі мовні моделі та те, як вони пов’язані з програмами, чи думаєте ви про затримку, яка може виникнути, і як із нею боротися? Чи бувають випадки, коли просто жорстке кодування дерева рішень здається більш доцільним?
Брискі: Ви маєте рацію, коли ви задаєте конкретне запитання або запитуєте, навіть для одного запитання може бути п’ять або сім моделей, які вже запущено, щоб ви могли швидко переписати, захистити, відновити та змінити рейтинг а потім генератор. Ось чому NIM такий важливий, оскільки ми оптимізували затримку.
Ось чому ми також пропонуємо різні версії базових моделей, тому що у вас може бути SLM, маленька мовна модель, яка начебто краща для певного набору завдань, і тоді вам потрібна більша модель для більшої точності в кінці. Але потім зв’язати все це так, щоб воно відповідало вашому вікну затримки, — це проблема, яку ми вирішували роками для багатьох гіпермасштабованих або керованих служб. У них є такі вікна затримки, і багато разів, коли ви задаєте запитання чи виконуєте пошук, вони фактично вимикаються та видають питання кілька разів. Таким чином, у них є багато умов перегонів «яке моє вікно затримки для кожної маленької частини загальної відповіді?» Тож так, ми завжди дивимось на це.
Щодо вашої думки про жорстке кодування, я щойно розмовляв із клієнтом про це сьогодні. Ми вийшли за межі жорсткого кодування... Ви можете використовувати менеджер діалогів і мати якщо-тоді-інше. [Але] керувати тисячами правил справді неможливо. І тому нам подобаються такі речі, як огорожі, тому що огорожі є своєрідною заміною класичного менеджера діалогів. Замість того, щоб сказати: «Не говоріть про бейсбол, не говоріть про софтбол, не говоріть про футбол» і перераховувати їх, ви можете просто сказати: «Не говоріть про спорт». І потім LLM знає, що таке спорт. Економія часу та можливість керувати цим кодом пізніше набагато кращі. ®
- Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
- PlatoData.Network Vertical Generative Ai. Додайте собі сили. Доступ тут.
- PlatoAiStream. Web3 Intelligence. Розширення знань. Доступ тут.
- ПлатонЕСГ. вуглець, CleanTech, Енергія, Навколишнє середовище, Сонячна, Поводження з відходами. Доступ тут.
- PlatoHealth. Розвідка про біотехнології та клінічні випробування. Доступ тут.
- джерело: https://go.theregister.com/feed/www.theregister.com/2024/03/26/nvdiai_kari_briski_interview/
