Как использовать мощность вашего графического процессора для регулярного анализа данных и машинного обучения, даже если вы не занимаетесь глубоким обучением.
Вы ищете «науку о данных на GPU»?
Представьте себя специалистом по обработке данных, бизнес-аналитиком или академическим исследователем в области физики / экономики / нейробиологии ...
Вы регулярно занимаетесь обработкой данных, очисткой, статистическими тестами и визуализацией. Вы также возитесь с множеством подгоночных данных линейных моделей и иногда заходите в RandomForest. Вы также занимаетесь кластеризацией больших наборов данных. Звучит достаточно знакомо?
Однако, учитывая характер наборов данных, с которыми вы работаете (в основном табличные и структурированные), вы не особо рискуете глубоким обучением. Вы бы предпочли вложить все имеющиеся у вас аппаратные ресурсы в повседневные дела, чем на какую-нибудь причудливую модель глубокого обучения. Опять знакомо?
Вы слышали об удивительной мощности и молниеносной вычислительной мощности систем с графическими процессорами, подобных тем, что у NVidia, для всех видов промышленных и научных приложений.
И все время думаешь: «Что для меня? Как я могу использовать преимущества этих мощных полупроводников в моем конкретном рабочем процессе? »
Вы ищете науку о данных на базе графических процессоров.
Один из лучших (и самых быстрых) вариантов оценки этого подхода - использовать комбинацию Облако Сатурна + БЫСТРЫЕ. Позвольте мне объяснить подробнее ...
Графические процессоры в фольклоре AI / ML в первую очередь предназначены для глубокого обучения.
Хотя использование графических процессоров и распределенных вычислений широко обсуждается в академических и деловых кругах для решения основных задач AI / ML (например, запуск 1000-слойной глубокой нейронной сети для классификации изображений или модели синтеза речи BERT с миллиардами параметров), они нашли меньшее покрытие, когда дело доходит до их полезности для обычных задач науки о данных и инженерии данных.
Тем не менее задачи, связанные с данными, являются важным предшественником любой рабочей нагрузки машинного обучения в конвейере ИИ, и они часто составляют большую часть времени и интеллектуальных усилий, затрачиваемых специалистом по данным или даже инженером машинного обучения. . Недавно известный пионер ИИ Эндрю Нг рассказал о переходе от подхода, ориентированного на модели, к подходу, ориентированному на данные. Это означает, что нужно тратить гораздо больше времени на необработанные данные и их предварительную обработку, прежде чем реальная рабочая нагрузка ИИ выполнится в вашем конвейере.
Итак, важный вопрос: Можем ли мы использовать мощность графического процессора и распределенных вычислений для регулярной обработки данных?
Хотя использование графических процессоров и распределенных вычислений широко обсуждается в академических и деловых кругах для решения основных задач ИИ / машинного обучения, они нашли меньшее покрытие в своей полезности для обычных задач обработки и анализа данных.
Фантастическая экосистема RAPIDS
Набор программных библиотек и API RAPIDS дает вам - обычному специалисту по данным (и не обязательно специалисту по глубокому обучению) - возможность и гибкость для выполнения сквозных конвейеров обработки и анализа данных полностью на графических процессорах.
Этот проект с открытым исходным кодом был создан Nvidia путем создания инструментов для использования примитивов CUDA. Особое внимание в нем уделяется раскрытию возможностей параллелизма графического процессора и скорости памяти с высокой пропускной способностью с помощью удобного для анализа данных языка Python.
Общие задачи по подготовке данных и согласованию высоко ценятся в экосистеме RAPIDS. Он также предоставляет значительный объем поддержки многоузлового развертывания, развертывания с несколькими графическими процессорами и распределенной обработки. Везде, где это возможно, он интегрируется с другими библиотеками, что упрощает обработку данных при нехватке памяти (т. Е. Размер набора данных превышает ОЗУ отдельного компьютера) и становится доступным для отдельных специалистов по данным.
Три наиболее важных (и питонических) компонента, которые представляют особый интерес для специалистов по обычным данным, - это:
- CuPy: библиотека массивов на основе CUDA, которая выглядит и работает так же, как Numpy, при использовании различных библиотек CUDA, например cuBLAS, cuDNN, cuRand, cuSolver, cuSPARSE, cuFFT и NCCL, чтобы в полной мере использовать преимущества. архитектуры графического процессора внизу.
- CuDF: это библиотека графического процессора DataFrame для загрузки, агрегирования, объединения, фильтрации и управления данными с помощью API-интерфейса, подобного пандам. Инженеры и специалисты по обработке данных могут использовать его, чтобы легко ускорить потоки задач с помощью мощных графических процессоров, даже не изучая основы программирования CUDA.
- CuML: эта библиотека позволяет специалистам по данным, аналитикам и исследователям запускать традиционные / классические алгоритмы машинного обучения и связанные с ними задачи обработки, полностью используя возможности графического процессора. Естественно, это используется в основном с табличными наборами данных. Подумайте о Scikit-learn и о том, что он может сделать со всеми этими сотнями ядер Cuda и тензорных ядер на вашей видеокарте! По этой причине в большинстве случаев API Python cuML совпадает с API Scikit-learn. Кроме того, он пытается предложить поддержку нескольких графических процессоров и многоузловых графических процессоров, изящно интегрируясь с Dask, где это возможно, для использование преимуществ истинно распределенной обработки / кластерных вычислений.
Можем ли мы использовать возможности графического процессора и распределенных вычислений для регулярных задач обработки данных и машинного обучения со структурированными данными?
Это отличается от использования Apache Spark?
Вы можете спросить, чем отличается обработка данных на GPU от Apache Spark. На самом деле есть некоторые тонкие различия, и только недавно, с появлением Spark 3.0, графические процессоры стали основным ресурсом для рабочих нагрузок Spark.
У нас нет времени или места для обсуждения уникальных отличий этого подхода к анализу данных с использованием графического процессора от задач Big Data, которые особенно подходят для Apache Spark. Но задайте себе эти вопросы, и вы, вероятно, поймете тонкую разницу,
Как специалист по данным, моделирующий экономические операции и управление портфелем, я хочу решить« линейную систему уравнений со 100 000 переменных. Я использую чистую библиотеку линейной алгебры или Apache Spark? »
Как часть конвейера сжатия изображений, я хочу использовать« Разложение по сингулярным значениям на большой матрице из миллионов записей. Подходит ли для этого Apache Spark? »
Большой размер проблемы не всегда означает экосистему Apache Spark или Hadoop. Большие вычисления не эквивалентны большим данным. Как разностороннему специалисту по данным, вам нужно знать и то, и другое, чтобы решать всевозможные проблемы.
RAPIDS уделяет особое внимание раскрытию возможностей параллелизма графического процессора и скорости памяти с высокой пропускной способностью с помощью API-интерфейсов Python.
Что мы показываем в этой статье?
Только четкие примеры CuPy и CuML
Итак, в этой статье мы просто продемонстрируем четкие примеры CuPy и CuML,
- как они сравниваются (по скорости) с соответствующими функциями / оценками Numpy и Scikit-learn
- какое значение имеет размер данных / проблемы в этом сравнении скорости.
Примеры CuDF в следующей статье
Хотя примеры инженерии данных, похожие на обработку данных Pandas, представляют большой интерес для многих специалистов по данным, мы рассмотрим примеры CuDF в следующей статье.
Какая у меня аппаратная платформа на базе графического процессора?
Я использую экземпляр Saturn Cloud Tesla T4 GPU, так как буквально за 5 минут работы нужно развернуть полнофункциональный и загруженный (с библиотеками DS и AI) вычислительный ресурс в облаке для все мои данные работают с их сервисом. Пока я использую Jupyter Notebook не более 10 часов в месяц, это бесплатно! Если вы хотите узнать больше об их услугах,
Помимо Tesla T4 GPU, это 4-ядерный процессор Intel (R) Xeon (R) Platinum 8259CL с тактовой частотой 2,50 ГГц с 16 ГБ оперативной памяти и постоянным диском на 10 ГБ. Итак, это вполне нормальная установка с точки зрения конфигурации оборудования (ограниченный жесткий диск из-за бесплатного уровня), т.е. любой специалист по данным может иметь такое оборудование в своем распоряжении. Единственным отличительным фактором является наличие графического процессора и правильная настройка всех библиотек CUDA и Python, чтобы пакет RAPIDS работал без сбоев.
Большой размер проблемы не всегда означает экосистему Apache Spark или Hadoop. Большие вычисления не эквивалентны большим данным. Как разносторонний специалист по обработке данных, вам необходимо знать и то, и другое, чтобы решать всевозможные проблемы.
Решение линейной системы уравнений
Мы создаем линейные системы уравнений различного размера и используем Numpy (и CuPy) linalg.solveroutine для решения этого с помощью следующего кода:
И код изменяется на одну букву (при нескольких вызовах) для реализации CuPy!
Также обратите внимание, как мы можем создавать массивы CuPy из массивов Numpy в качестве аргументов.
Однако результат впечатляет. CuPy запускается медленно или с той же скоростью, что и Numpy, но опережает его для задач большого размера (количества уравнений).
Разложение по сингулярным числам
Затем мы решаем проблему разложения по сингулярным числам, используя случайно сгенерированную квадратную матрицу (полученную из нормального распределения) различных размеров. Мы не повторяем здесь блок кода, а просто для краткости показываем результат.
Важно отметить, что алгоритм CuPy не показывает заметно более высокую производительность по сравнению с алгоритмом Numpy в этом классе проблем. Возможно, разработчикам CuPy стоит над этим взяться, чтобы улучшить.
Возвращаясь к основам: инверсия матриц
Наконец, мы вернемся к основам и рассмотрим фундаментальную проблему обращения матриц (используется почти во всех алгоритмах машинного обучения). Результат снова показывает очень хороший прирост производительности алгоритма CuPy по сравнению с пакетом Numpy.
Решение проблемы кластеризации K-средних
Затем мы рассмотрим проблему неконтролируемого обучения кластеризации с использованием хорошо знакомого алгоритма k-средних. Здесь мы сравниваем функцию CuML с эквивалентной оценкой из пакета Scikit-learn.
Для справки, вот сравнение API между этими двумя оценщиками.
Вот результат для набора данных с 10 функциями / размерами.
И вот результат другого эксперимента с набором данных из 100 объектов.
Очевидно, что и размер выборки (количество строк), и размерность (количество столбцов) имели значение в том, как ускорение на основе графического процессора работает лучше.
Всем известная проблема линейной регрессии
Кто может игнорировать проблему линейной регрессии для сравнения скорости при работе с табличными наборами данных? Следуя ритму, как и раньше, мы меняем размер проблемы - на этот раз одновременно количество выборок и размерностей - и сравниваем производительность CuML LinearRegression оценщика с производительностью, полученной из Scikit-learn стабильной.
Ось X на следующем рисунке представляет размер проблемы - от 1000 выборок / 50 функций до 20 000 выборок / 1000 функций.
Опять же, оценщик CuML работает намного лучше по мере роста сложности проблемы (размера выборки и размерности).
Резюме
Мы сосредоточились на двух наиболее фундаментальных компонентах структуры RAPIDS, которая направлена на то, чтобы использовать возможности графического процессора для повседневных задач анализа данных и машинного обучения, даже когда специалист по данным не выполняет никаких задач глубокого обучения.
Мы использовали экземпляр на базе Tesla T4 Saturn Cloud для простой, бесплатной и быстрой настройки и продемонстрировали некоторые особенности библиотек CuPy и CuML и сравнения производительности широко используемых алгоритмов.
- Не все алгоритмы из библиотек RAPIDS намного лучше, но большинство из них.
- Как правило, прирост производительности быстро увеличивается по мере роста сложности задачи (размера выборки и размерности).
- Если у вас есть графический процессор, всегда пробуйте RAPIDS, сравнивайте и проверяйте, получаете ли вы какую-либо производительность, и сделайте его надежной рабочей лошадкой в своем конвейере обработки данных.
- Смена кода минимальна, при переключении практически не существует.
Позвольте мощности графического процессора ускорить ваш рабочий процесс аналитики и обработки данных.
Вы можете проверить в репозиториях GitHub автора код, идеи и ресурсы по машинному обучению и науке о данных. Если вы, как и я, увлечены искусственным интеллектом / машинным обучением / наукой о данных, пожалуйста, не стесняйтесь добавить меня в LinkedIn или подписаться на меня в Twitter.
