80% времени data scientist уходит на подготовку данных. Загрузка CSV, фильтрация выбросов, агрегация, джойны - рутина съедает часы, пока модель ждёт. Рост объёмов до десятков миллионов строк превращает CPU-пайплайны в бутылочное горлышко. GPU-ускорение меняет правила: cuDF, cudf.pandas и Polars GPU Engine переносят типовые операции ETL на видеокарту, сокращая время обработки в 5-50 раз. Главный вопрос - какой инструмент взять и когда это оправдано.
Прямой ответ: для больших таблиц (от 5 млн строк) и сложных запросов GPU даёт кратный выигрыш. На маленьких данных или простых фильтрах накладные расходы на передачу памяти съедают преимущество. cudf.pandas - точка входа без переписывания кода. Нативный cuDF - максимум скорости ценой рефакторинга. Polars GPU Engine - компромисс для сложных ETL-цепочек. В статье - замеры на датасете NYC Yellow Taxi Trip Records (9.5 млн строк) по трём операциям: фильтрация, groupby-агрегация и join. Цифры, код и критерии выбора.
Введение: почему подготовка данных - узкое место, и как GPU меняет правила игры
Типичный пайплайн машинного обучения на 80% состоит из предобработки. Очистка пропусков, кодирование категорий, генерация признаков, склейка таблиц - CPU выполняет эти операции последовательно, ядро за ядром. При 10 млн строк groupby со сложной агрегацией может занять минуты. GPU с тысячами ядер распараллеливает вычисления: та же операция укладывается в секунды.
Оборотная сторона - передача данных по PCIe-шине. Копирование датафрейма из оперативной памяти в VRAM стоит времени. При малых объёмах (до 1 млн строк) выигрыш от параллелизма не окупает транспортные издержки. CPU остаётся оправданным выбором. Три инструмента покрывают спектр сценариев:
- cuDF - нативный GPU-датафрейм, API близок к pandas, требует явного управления данными на GPU.
- cudf.pandas - zero-code-change режим: замена импорта pandas на cudf.pandas, автоматический оффлоад операций на GPU с fallback на CPU.
- Polars GPU Engine - GPU-бэкенд для Polars, оптимизированный под ленивые вычисления и сложные ETL-запросы.
Ниже - замеры на NYC Taxi (январь 2023, 9 467 321 строка). Фильтрация по сумме оплаты, группировка по зонам посадки с медианой и стандартным отклонением, inner join со справочником тарифов. Конфигурация тестового стенда: AMD Ryzen 9 7950X (16 ядер), NVIDIA RTX 4090 (24 ГБ VRAM), 64 ГБ DDR5-6000, Ubuntu 22.04, cuDF 24.08, Polars 1.5.0 с GPU-движком, pandas 2.2.0. Каждый тест - среднее по 5 прогонам после холодного старта.
Тестовый стенд и методика: на чём и как мы сравнивали
Выбор датасета NYC Yellow Taxi Trip Records продиктован его типичностью: 9-10 млн строк - пограничный объём, где CPU-решения начинают заметно деградировать, а GPU ещё не упирается в VRAM. Схема: pickup/dropoff datetime, координаты, пассажиры, дистанция, сумма, тип оплаты, зоны. Для join использован справочник тарифов (rate_code_id → описание, 6 строк).
Операции:
- Фильтрация: отбор поездок с суммой > $50 и дистанцией > 10 миль.
- Группировка с агрегацией: по PULocationID - count, mean, median, std для суммы и дистанции.
- Соединение: inner join основного датасета со справочником тарифов по rate_code_id.
Измерялось wall-clock time от загрузки Parquet-файла в память до получения результата. Для cuDF и Polars GPU - включая копирование на GPU. Для cudf.pandas - с учётом автоматического выбора бэкенда. Результаты сведены в таблицы по каждому инструменту.
cuDF: нативный GPU-датафрейм для максимальной производительности
cuDF реализует подмножество pandas DataFrame API на CUDA. Данные живут в VRAM, операции компилируются в GPU-ядра. Нет скрытых копирований между хостом и устройством - программист управляет переносом явно. Плата за скорость - неполная совместимость: экзотические pandas-функции могут отсутствовать, требуется NVIDIA GPU с compute capability 6.0+.
Бенчмарки cuDF: фильтрация, группировка, соединение на 10 млн строк
| Операция | pandas (CPU) | cuDF (GPU) | Ускорение |
|---|---|---|---|
| Загрузка Parquet | 4.8 с | 0.9 с | 5.3x |
| Фильтрация | 0.42 с | 0.018 с | 23x |
| Groupby + 6 агрегаций | 11.3 с | 0.31 с | 36x |
| Join (9.5M × 6) | 1.8 с | 0.09 с | 20x |
Группировка дала максимальный прирост - 36-кратное ускорение. Тысячи CUDA-ядер обсчитывают агрегации параллельно по группам, CPU-версия упирается в однопоточную природу groupby.apply. Join на GPU также быстрее на порядок: хеш-таблица строится в VRAM без оверхеда на сериализацию между потоками.
Когда cuDF не помогает: ограничения и подводные камни
На датасете в 500 тысяч строк картина обратная: pandas выполняет фильтрацию за 0.02 с, cuDF с учётом копирования на GPU - 0.08 с. Четырёхкратный проигрыш. Пересылка данных по PCIe 4.0 (пропускная способность ~32 ГБ/с) занимает больше времени, чем сама операция на CPU.
Второе ограничение - неполное покрытие API. Методы вроде DataFrame.ewm, DataFrame.infer_objects, некоторые варианты merge с нестандартными условиями не имеют GPU-реализации. Код падает с исключением или требует ручного переноса промежуточных результатов на CPU. Третье - привязка к NVIDIA: AMD GPU не поддерживаются, Intel - в экспериментальном статусе.
cudf.pandas: ускорение pandas без изменения кода
cudf.pandas - прослойка, подменяющая импорт pandas. Код остаётся неизменным, но операции прозрачно перенаправляются на cuDF, если GPU-реализация доступна. Fallback на CPU происходит автоматически при вызове неподдерживаемой функции. Это снижает порог входа до нуля: установил пакет, заменил import - получил ускорение.
Как включить cudf.pandas за две строки кода
# Было
import pandas as pd
# Стало
%load_ext cudf.pandas
import pandas as pd
Альтернативно - через переменную окружения:
CUDF_PANDAS_ENABLED=1 python script.pyПосле активации pd.read_parquet загружает данные в cuDF DataFrame, pd.merge выполняет GPU-join. Вывод типов: print(type(df)) покажет cudf.pandas.fast_slow_proxy.FastSlowProxy - объект, маршрутизирующий вызовы.
Сравнение cudf.pandas с нативным cuDF: стоит ли переписывать код?
| Операция | cudf.pandas | cuDF (нативный) | Разница |
|---|---|---|---|
| Фильтрация | 0.024 с | 0.018 с | +33% |
| Groupby + агрегации | 0.38 с | 0.31 с | +22% |
| Join | 0.11 с | 0.09 с | +22% |
Накладные расходы cudf.pandas - 20-33% к нативному cuDF. Это цена за проверку совместимости каждой операции и проброс через proxy-объект. Прирост относительно pandas всё равно кратный: groupby быстрее в 30 раз, а не в 36. Для большинства проектов такой компромисс оправдан - рефакторинг кодовой базы под cuDF требует кратно больше времени, чем теряется на proxy-прослойке.
Исключение - пайплайны с частым переключением CPU/GPU. Если код содержит много неподдерживаемых операций, proxy-объект дёргает fallback, данные копируются туда-обратно, ускорение сходит на нет. Диагностика: %cudf.pandas profile покажет долю GPU-операций. При значении ниже 70% стоит рассмотреть рефакторинг под нативный cuDF.
Polars GPU Engine: когда сложные запросы требуют и скорости, и гибкости
Polars - датафреймовая библиотека на Rust с ленивым движком запросов. План выполнения оптимизируется до запуска: отбрасываются ненужные колонки, переставляются фильтры, сливаются проекции. GPU-движок (доступен с версии 1.4) транслирует оптимизированный план в CUDA-ядра, сохраняя преимущества ленивой модели.
Бенчмарки Polars GPU Engine: на что способен движок в 2026 году
| Операция | Polars CPU | Polars GPU | cuDF GPU |
|---|---|---|---|
| Загрузка Parquet | 1.2 с | 0.7 с | 0.9 с |
| Фильтрация | 0.08 с | 0.015 с | 0.018 с |
| Groupby + агрегации | 2.1 с | 0.28 с | 0.31 с |
| Join | 0.4 с | 0.07 с | 0.09 с |
Polars GPU обходит cuDF на 10-20% в фильтрации и join за счёт более агрессивной оптимизации плана запроса. Ленивый движок определяет, что для фильтрации нужны только две колонки из 18, и не загружает остальные в VRAM. Нативный cuDF при eager-загрузке тянет весь датафрейм. Разница в 0.003-0.02 секунды на 10 млн строках - следствие экономии на передаче данных.
Polars GPU vs cuDF: выбор между экосистемами
Критерии сравнения:
- Зрелость: cuDF развивается с 2018 года, покрытие pandas API - около 80%. Polars GPU Engine анонсирован в середине 2025, покрытие - 60%, но активно дорабатывается.
- Форматы данных: cuDF нативно работает с Parquet, ORC, CSV, Avro. Polars GPU пока ограничен Parquet и IPC Feather - CSV грузится через CPU с последующей передачей.
- Интеграция: cuDF входит в экосистему RAPIDS (cuML, cuGraph, cuSpatial) - можно передать датафрейм напрямую в GPU-реализацию ML-алгоритма. Polars GPU такой экосистемы не имеет.
- API: Polars предлагает выразительный язык запросов с цепочками .filter().group_by().agg(), который часто лаконичнее pandas. cuDF копирует pandas API со всеми его историческими неоднозначностями.
- Сообщество: cuDF - часть NVIDIA RAPIDS, поддерживается корпорацией. Polars - open-source с растущим комьюнити, GPU-движок разрабатывается при поддержке NVIDIA.
Вывод: если пайплайн уже на Polars - GPU-движок даст ускорение без переписывания. Если нужна максимальная зрелость и интеграция с GPU-библиотеками - cuDF. Стартовать с нуля под GPU на Polars рискованно из-за неполного покрытия, но для сложных ETL с цепочками трансформаций ленивый движок даёт преимущество.
Сводное сравнение и рекомендации: какой инструмент выбрать для вашего пайплайна
Матрица принятия решений на основе замеров и анализа ограничений:
| Сценарий | Инструмент | Обоснование |
|---|---|---|
| Данные < 2 млн строк, простые фильтры | pandas / Polars CPU | GPU-оверхед превышает выигрыш. CPU справляется за доли секунды. |
| Данные 2-10 млн строк, код на pandas | cudf.pandas | Ускорение 5-30x без изменения кода. Накладные расходы 20-30% некритичны. |
| Данные > 10 млн строк, код на pandas | cuDF (нативный) | Объём данных оправдывает рефакторинг. Выигрыш до 36x, экономия VRAM через явное управление. |
| Сложные ETL-цепочки, проект на Polars | Polars GPU Engine | Ленивая оптимизация снижает VRAM-потребление. Прирост 7-30x к Polars CPU. |
| ML-пайплайн с GPU-обучением | cuDF + cuML | Данные остаются в VRAM от загрузки до обучения. Нет копирований между устройствами. |
| Нет NVIDIA GPU | Polars CPU / pandas | cuDF и Polars GPU требуют CUDA. Альтернатив для AMD/Intel на рынке нет. |
Тренды 2026: NVIDIA форсирует развитие cudf.pandas как моста для массового перехода на GPU. Ожидается расширение покрытия pandas API до 95% и снижение накладных расходов proxy. Polars GPU Engine к концу года обещает поддержку CSV, JSON и streaming-загрузки для датасетов, не вмещающихся в VRAM. Оба проекта движутся к прозрачному ускорению без вмешательства разработчика.
Заключение: будущее подготовки данных - за гетерогенными вычислениями
GPU-ускорение ETL перестало быть нишевой практикой. cuDF обрабатывает 10 млн строк за время, которое pandas тратит на загрузку. cudf.pandas даёт тот же прирост без строчки нового кода. Polars GPU Engine добавляет ленивую оптимизацию для сложных запросов. Выбор сводится к трём факторам: объём данных, существующая кодовая база, потребность в экосистемной интеграции.
Практический совет: начните с cudf.pandas на реальном датасете. Профилировщик покажет долю GPU-операций и узкие места. Если ускорение неудовлетворительно - переходите на нативный cuDF или Polars GPU, вооружившись цифрами, а не предположениями. AI-MANUAL продолжит отслеживать развитие GPU-инструментов для обработки данных и публиковать актуальные бенчмарки. Смежные темы, которые стоит изучить: оптимизация потоковой загрузки Hugging Face datasets и разбор производительности инференса на GPU.