Преди около две години се прибрах от Мюнхен, изтощен. Екипът, само около 20 души по това време, беше изтощен. Подобно на сцената след надписите в Отмъстителите, нашата маса със супергерои се хранеха мълчаливо и размишляваха върху битката. Спечелихме. Имахме първата голяма победа в спасяването на мултивселената на науката за данни от неземните сили на еднонишковостта, сложността на кода и чакането. Бяхме пуснали RAPIDS.

Има чувството, че оттогава са били 16 различни филма; всички различни, всички свързани. Но ние не сме близо до края на играта. Това беше изложено изцяло на NVIDIA Fall GTC 2020. Имахме 23 разговора за различни аспекти на RAPIDS. RAPIDS може да стане голям, което беше демонстрирано в разговори като как RAPIDS и BlazingSQL захранват откриването на лекарства срещу COVID-19 на суперкомпютъра Summit в Националната лаборатория Оукридж (нов блог от ORNL тук). RAPIDS може да стане малък, работещ на вградени устройства на ръба. RAPIDS има поток, както показват нашите „двама“ „разговори“ за стрийминг. Ние сме в „облака“, ние сме на „земята“ и обработваме „звук“.

Всеки нов родител е бил предупреждаван за „ужасните двойки“, но с RAPIDS просто не виждам това да се случва. Влизаме в страхотните двойки. След последното ни издание свършихме хитова работа. Имаме някои от най-модерните НЛП техники, „работещи в мащаб“ и по-бързи от всякога. Нашият екип спечели предизвикателството RecSys за 2020 г. с GPU-ускорен конвейер, който работи от край до край за две минути и осемнадесет секунди, дори хората в Twitter бяха впечатлени. Ние учим хората как да изградят оптимизация на хиперпараметри в AWS със страхотен нов видео урок. За всички наши фенове на графиките написахме как можете да получите ускоряване до 328x чрез промяна на ред код. Графиките на NetworkX и обектите DiGraph вече се поддържат обекти в cuGraph.

Позволете ми да обобщя накратко някои от основните актуализации в тази версия.

РАПИДС cuDF

Както винаги, cuDF беше много зает. Закрихме 71 грешки и направихме 97 подобрения в кода. По отношение на новите функции, развълнуван съм, че внедрихме DataFrame.pivot() и DataFrame.unstack(), методи, на които разчитах по-рано в кариерата си. За да направим инженеринга на функции още по-лесен, сега имаме dayofweek като част от нашите функции DateTime. Преди трябваше да разработите свой собствен метод, „не най-простото нещо“. Също така добавихме първоначалната поддръжка за структурни колони за още по-голяма поддръжка на вложен тип. Освен това започнахме усилие за рефакторинг на IO читатели и писатели, за да ни позволи да изградим повече функции и да коригираме грешки по-бързо напред.

RAPIDS cuML и XGBoost

cuML направи голям тласък за разширяване на поддръжката за нови методи за предварителна обработка с добавянето на Dask LabelEncoder, разпределен tf-IDF, Porter stemming за NLP и нов, експериментален модул за предварителна обработка. Модулът за предварителна обработка включва поддръжка за голяма част от (големия) API за предварителна обработка на Scikit-learn. Въпреки че все още е в процес на работа, ние се надяваме, че потребителите могат да се възползват от предварителния преглед, за да започнат да преместват по-сложни ML тръбопроводи изцяло върху GPU.

RAPIDS 0.16 също така включва моментна снимка на DMLC XGBoost, която включва новата библиотека GPUTreeSHAP за ускоряване на SHAP-базирани обяснения на модела. SHAP включва идеи от теорията на игрите, за да изчисли добре обосновани, адитивни анализи за това как всяка характеристика допринася за дадена прогноза и може да бъде разширена, за да изчисли и въздействието на взаимодействащи характеристики. В много случаи учените по данни са избягвали SHAP, тъй като може да е скъпо от изчислителна гледна точка. Сега, с GPUTreeSHAP, един GPU може да изчислява обяснения 20 пъти по-бързо от 40-ядрен CPU възел, а ускоренията стават още по-големи при анализиране на взаимодействията. Вижте тази проста демонстрация, за да започнете, или се потопете по-дълбоко с тази чернова изследователска статия.

TPOT вече се ускорява с cuML и XGBoost. Потребителите на TPOT могат да ускорят своите конвейери на AutoML с новата, естествено поддържана конфигурация „TPOT cuML“, като променят само един параметър в кода си — предадете „TPOT cuML“ на аргумента config_dict на вашия TPOTClassifier или TPORegressor, вместо да го оставяте като None. Ускореният TPOT откри тръбопроводи с 2% по-висока точност на набора от данни за Хигс бозона и 1,3% по-висока точност на набора от данни на Airlines за същия времеви бюджет. И за двете проби от набори от данни конфигурацията на cuML постигна по-висока точност за един час от постигнатата по подразбиране за осем часа. Потърсете блог, който ще ви разкаже повече в следващите дни.

РАПИДС КУГРАФ

Във версия 0.16 cuGraph постави началото на три основни дългосрочни теми. Първата е да да станеш голям. Преминахме към нов 2D модел на данни, който премахва ограничението от 2 милиарда върха и предлага по-добра производителност и мащабиране в диапазона на графиката от 100TB+. Първите мулти-нодови мулти-GPU (MNMG) алгоритми, актуализирани, за да използват новия модел на данни, са PageRank, SSSP, BFS и Louvain.

Втората тема е разширяване,чрез разширяване на поддържаните от нас модели на входни данни. В 0.16 сме щастливи да обявим, че графичните обекти на NetworkX вече са валидни типове данни в нашите алгоритми. Все още разширяваме оперативната съвместимост между cuGraph и NetworkX и преминаваме към поддръжка на CuPy и други типове данни. Последната тема е да минете малко и да разработите колекция от графични примитиви. Примитивите поддържат работни потоци както с един GPU, така и с много GPU и ни позволяват да имаме единна кодова база и за двете.

RAPIDS Memory Manager (RMM)

RMM 0.16 се фокусира върху намалена фрагментация за многонишково използване и подобрения на CMake. Тази версия включва множество подобрения на CMake от сътрудника Kai Germaschewski, които улесняват използването на RMM в други базирани на CMake проекти (и предстоят още подобрения!). Той също така включва нов ресурс на паметта на арената, който намалява фрагментацията, когато много нишки споделят един GPU, както и подобрения на ресурса на паметта на пула, за да се намали въздействието на фрагментацията. Друг нов ресурс на паметта е `limiting_resource_adaptor`, който ви позволява да наложите максимално използване на паметта на всеки `device_memory_resource`. Подобрихме диагностиката с регистриране на грешки и проследяване, което в момента се поддържа в pool_memory_resource. Нов симулиран ресурс на памет позволява стартиране на бенчмарка на RMM log replayer със симулирана по-голяма памет, което може да помогне при диагностицирането на грешки при липса на памет и проблеми с фрагментацията. И последно, но определено не на последно място, чрез премахване на отхвърлената преди това функционалност, librmm вече е библиотека само за заглавки.

RAPIDS Dask-cuDF

За изданието 0.16 Dask-cuDF добави оптимизиран групиран път за агрегиране при прилагане на много агрегации. Преди това за всяка операция за агрегиране dask-cudf се изпълняваше последователно срещу обекта groupby. Сега Dask-cuDF ще извиква операциите за агрегиране паралелно на GPU. Това е голяма крачка напред за производителността.

RAPIDS cuSignal

cuSignal 0.16 се фокусира върху бенчмаркинг, тестване и производителност. Вече имаме 100% API покритие в нашия пакет PyTest — гарантирайки, че внедрените функции са числено сравними със SciPy Signal. Освен това, чрез нашите проучвания за производителност, ние открихме множество функции, които са по-подходящи за ElementWise CuPy CUDA ядра в сравнение със стандартните функции CuPy — което води до 2–4 пъти подобрения в производителността спрямо cuSignal 0,15.

BlazingSQL

Сега е по-лесно от всякога да започнете с RAPIDS и BlazingSQL. Вече можете да намерите BlazingSQL контейнери в RAPIDS Getting Started Selector и ние разширихме Blazing Notebooks, за да включим повече RAPIDS пакети (CLX и cuXfilter) с частна бета версия с няколко графични процесора, планирана за публично пускане в началото ноември.

За версия 0.16 работихме усилено, за да разрешим десетки проблеми, изпратени от потребители. В същото време ние работим върху основен ремонт на комуникационния слой в BlazingSQL. SQL заявките са тежки операции за разбъркване; този нов комуникационен слой (скоро ще бъде обединен в 0.17 nightlies) повишава производителността при 95% от работните натоварвания, като същевременно ни настройва да използваме UCX, позволявайки технологиите на NVIDIA NVLink, Mellanox Infiniband и т.н. за още по-голяма производителност.

NVTabular

NVTabular осигурява бързо инженерство и предварителна обработка на функциите на GPU и по-бързо зареждане на данни, базирани на GPU към PyTorch, Tensorflow, HugeCTR и Fast.ai, ускорявайки работните потоци на таблично дълбоко обучение с 5–20 пъти, когато се използва във връзка с NVIDIA AMP. От самото си създаване, той разчита на RAPIDS cuDF, за да осигури основна функционалност на IO и dataframe.

Със скорошната версия 0.2, NVTabular вече е още по-интегриран с екосистемата RAPIDS, преминавайки от персонализирана итерационна задна част към такава, изградена изцяло на Dask-cuDF. Това означава, че потребителите вече могат да предават кадри с данни Dask-cuDF или cuDF като вход в допълнение към многото файлови формати, които вече се поддържат от cuIO, и могат да смесват и съчетават безпроблемно NVTabular и Dask-cuDF, като пишат персонализирани операции за NVTabular директно в Dask -cuDF. Той също така позволява лесно мащабиране в множество GPU или дори множество възли; В скорошен бенчмарк успяхме да обработим предварително 1,2TB — 4 милиарда реда набор от данни на Criteo Ads за по-малко от 2 минути на DGX A100.

RAPIDS версия 0.16 въвежда поддръжка на списъци в cuDF, което позволява добавянето на най-търсената функция на NVTabular, Multi-hot категорични колони, и екипът работи усилено върху това за NVTabular версия 0.3.

CLX

Въпреки че имаше множество подобрения и настройки на производителността на примерните преносими компютри в CLX, което ги направи по-производителни и по-лесни за използване, големите подобрения идват в cyBERT. В допълнение към групирания режим при поискване, поддържан по-рано, cyBERT вече може да използва конвейер за поточно предаване за непрекъснато, вградено анализиране на журнали. Освен това cyBERT е модифициран, за да поддържа модели ELECTRA в допълнение към поддържаните преди това модели BERT. Въпреки че BERT все още е предпочитан за типовете регистрационни файлове, които сме наблюдавали досега (осигурявайки по-висока точност на анализиране, макар и с малко по-ниска скорост), поддръжката на ELECTRA ще позволи на другите, използващи cyBERT, по-голяма гъвкавост при избора на модел, който работи за тях в техните мрежови среди. cyBERT също получи още няколко ощипвания и подобрения, включително нов инструмент за зареждане на данни, който помага да бъде в крак с по-големите поточни конвейери.

Общност на RAPIDS

Започваме подкаст, наречен RAPIDS Fire. Първият епизод излиза в началото на ноември, така че внимавайте за обявяването. Ще се радваме да получим вашите отзиви по темите и да поканим общността да се присъедини към диалога. Форматът ще бъде уникален, както е уникален RAPIDS. Ще има водещ, „Пол Малер“, и ротационни съдомакини. Аз ставам първи. Двамата домакини ще интервюират гост за всичко, свързано с науката за ускорени данни и Общността на RAPIDS. Наистина сме развълнувани от това, така че очаквайте блог, който да обяви първия епизод. Очакваме подкастът да бъде достъпен навсякъде, където се намират подкасти.

Увийте

RAPIDS постигна толкова голям напредък за две години, че почти не мога да повярвам. Имаме много вълнуващи нови неща във версия 0.17, още подобрения на SHAP, повече MNMG алгоритми в cuGraph и поддръжката на вложен тип в cuDF ще продължи да се подобрява. Както винаги, намерете ни в GitHub, последвайте ни в Twitter и разгледайте нашата документация и ресурси за първи стъпки. Радваме се да се присъедините към нас и очакваме с нетърпение още една страхотна година на RAPIDS.

И гласувайте!