Почему перегнать данные в видеопамять часто дороже, чем их посчитать

MAATRIX

Вы добавили .to('cuda') в код, ожидая ускорения, — а получили результат медленнее, чем на CPU. Первая мысль — «GPU слабый» или «драйвер кривой». На деле почти всегда виновата не видеокарта и не процессор, а путь, которым данные должны проехать между ними: узкая шина PCIe, через которую каждый байт из оперативной памяти хоста попадает в видеопамять. Разберём, почему это узкое место существует физически, когда оно съедает весь выигрыш от параллельных вычислений и как заранее понять, стоит ли овчинка выделки.

Путь данных: от оперативной памяти хоста до видеопамяти GPU

Видеокарта — это отдельное устройство со своей памятью (VRAM), физически не совпадающей с оперативной памятью хоста (RAM). Прежде чем ядра GPU смогут что-то посчитать, нужные данные должны оказаться в VRAM. Путь выглядит так:

1. Данные лежат в оперативной памяти хоста — их туда положил CPU, прочитав из файла, сети или посчитав сам.
2. Приложение вызывает функцию переноса — cudaMemcpy в CUDA, .to('cuda') в PyTorch, cl::Buffer в OpenCL. Под капотом это DMA-передача через шину PCIe.
3. Данные физически едут по дорожкам PCIe от контроллера хоста к видеокарте.
4. Только после того как копирование завершилось, GPU может начать вычисления над этими данными.
5. Результат нужно скопировать обратно тем же путём — иначе он останется бесполезным набором байт в VRAM, недоступным остальной программе.

Каждый из этих пяти шагов, кроме собственно вычисления на шаге 4, — это накладные расходы, которых при вычислении на одном CPU просто не существует: данные уже лежат там, где их будет использовать процессор, кэши и шины памяти хоста работают на них напрямую, без промежуточной пересадки на другое устройство.

Важно понимать: видеопамять сама по себе — быстрая. GDDR6/GDDR6X или HBM в современных GPU спроектированы под огромную внутреннюю пропускную способность, потому что тысячи вычислительных ядер одновременно требуют данные. Проблема не в видеопамяти как таковой, а в шине, которая её соединяет с внешним миром.

Почему шина PCIe — это узкое место, а не видеопамять

PCIe — это последовательная шина общего назначения. Через неё же подключены сетевые карты, NVMe-накопители, звук, USB-контроллеры — то есть это универсальный интерфейс "устройство — материнская плата", а не выделенная магистраль, спроектированная специально под задачу "залить терабайты данных в видеопамять максимально быстро".

Внутренняя шина памяти GPU, соединяющая вычислительные ядра с собственной VRAM, устроена принципиально иначе: она короткая (буквально сантиметры внутри платы видеокарты), широкая (сотни бит параллельно) и не делится с другими устройствами. PCIe, наоборот, — это несколько последовательных линий (lane), каждая из которых передаёт данные бит за битом, и суммарная пропускная способность растёт линейно с числом линий и версией стандарта, но всё равно остаётся на порядок меньше внутренней пропускной способности VRAM.

Добавьте к этому:

• Латентность инициации передачи. Каждый вызов cudaMemcpy — это не мгновенное «данные телепортировались», а последовательность операций: подготовка дескриптора DMA, ожидание готовности шины, сама передача, подтверждение завершения. На маленьких объёмах данных эта накладная латентность может занимать сравнимое время с самой передачей полезной нагрузки.
• Синхронизацию host-device. По умолчанию многие операции переноса — блокирующие: CPU ждёт, пока копирование завершится, прежде чем отправить GPU команду на вычисление. Это время простоя, которое не занято ни передачей, ни вычислением.
• Разделение шины между устройствами. Если на сервере несколько GPU или активно используется NVMe через ту же шину, полосы PCIe в моменте могут быть заняты не только вашей передачей.

Итог простой: для GPU-вычислений данные должны физически пересечь сравнительно медленное узкое место — шину PCIe, — прежде чем попасть туда, где они действительно быстро обрабатываются.

Когда перенос данных съедает весь выигрыш от параллельных вычислений

Возьмём предельно простой пример: вам нужно применить функцию к массиву чисел — например, сложить два вектора или посчитать сумму значений. На GPU это делают тысячи потоков параллельно, каждый — над своим элементом. Звучит как идеальная задача для видеокарты.

Но если массив маленький — скажем, несколько тысяч элементов, а операция над каждым элементом простая (одно сложение, одно умножение), то реальная последовательность действий такая:

1. Скопировать массив A из RAM в VRAM      → идёт по шине PCIe
2. Скопировать массив B из RAM в VRAM      → идёт по шине PCIe
3. Запустить ядро (kernel) на GPU          → само вычисление, доли микросекунды
4. Скопировать результат из VRAM в RAM     → снова по шине PCIe

Шаг 3 — единственный шаг, ради которого всё затевалось, — оказывается самым дешёвым по времени. Шаги 1, 2 и 4 — три пересечения узкого места — доминируют над общим временем выполнения. При этом на CPU эта же задача решалась бы одним проходом по памяти, без единого пересечения внешней шины: данные уже там, где их обрабатывает исполняющее устройство.

Это не гипотетическая ситуация «в теории может быть». Это ровно тот случай, когда разработчик добавляет GPU-ускорение в код, ожидая линейного выигрыша от параллелизма, а получает замедление — потому что забыл посчитать стоимость доставки данных к месту вычисления. Разница между «GPU быстрее CPU для нейросетей» и «GPU медленнее CPU для этой конкретной операции» — это разница между большой матричной операцией, где вычислений на единицу данных много, и маленькой поэлементной операцией, где их мало. Подробнее о том, почему в первом случае выигрыш реален, я разбирал в статье почему GPU быстрее CPU для нейросетей.

Арифметическая интенсивность: сколько вычислений нужно на единицу данных

В основе решения «выносить на GPU или нет» лежит понятие, которое в литературе по производительности называют арифметической интенсивностью (arithmetic intensity) — отношение числа выполненных операций к объёму данных, которые пришлось переместить, чтобы эти операции выполнить.

Грубо говоря:

• Низкая интенсивность — на каждый байт, доехавший до GPU, приходится одна-две простых операции. Пример: поэлементное сложение векторов, копирование, простая фильтрация. Время выполнения такой задачи определяется не вычислениями, а тем, сколько данных нужно перегнать через шину — задача «упирается в память» (memory-bound), причём в первую очередь в пропускную способность именно шины передачи, а не самой VRAM.
• Высокая интенсивность — на каждый байт данных приходится много операций. Пример: перемножение больших матриц, свёртки в нейросетях, где один и тот же блок данных многократно переиспользуется вычислительными ядрами после однократной загрузки в VRAM. Такая задача «упирается в вычисления» (compute-bound) — и вот здесь тысячи параллельных ядер GPU дают реальный выигрыш, потому что накладные расходы на перенос размазываются на огромное число операций.

Практическое следствие: GPU выгоден не потому, что «видеокарта быстрая», а потому что для конкретной задачи объём вычислений на единицу перемещённых данных достаточно велик, чтобы компенсировать стоимость пересечения PCIe. Перенос вычислений на видеокарту — это не универсальный ускоритель, который выгодно применять к любому коду; это инструмент, который окупается только при определённом соотношении «вычисления / передача».

Если вы прикидываете, где проходит эта граница для вашей задачи, полезно сравнить оба варианта на практике — иногда решение считать эмбеддинги на CPU без GPU оказывается не компромиссом, а осознанно более эффективным выбором именно из-за низкой арифметической интенсивности операции.

Практические примеры: где перенос на GPU не окупается

Ниже — типичные ситуации, где стоит остановиться и посчитать, а не переносить вычисления на GPU по умолчанию.

Частая ошибка — обрабатывать запросы к модели по одному, без батчинга: каждый вызов тянет за собой полный цикл «скопировать вход → посчитать → скопировать результат», и стоимость переноса платится заново на каждый маленький запрос вместо того, чтобы размазаться на группу запросов. Это тесно связано с темой пропускной способности памяти как потолка производительности — я подробнее писал об этом в статье пропускная способность памяти — потолок локальной LLM.

Ещё один практический нюанс: если данные уже один раз загружены в VRAM (например, веса модели), а меняется только маленький вход (промпт, один батч изображений), то стоимость шины платится один раз за веса и многократно — но по мелочи — за входы. Здесь важно не путать «однократную загрузку большого объёма данных» с «повторяющимся переносом маленьких порций»: первое почти всегда окупается, второе — предмет отдельного расчёта.

Как заранее понять, стоит ли овчинка выделки

Прежде чем переносить вычисление на GPU, полезно ответить себе на несколько вопросов — без бенчмарков, чисто на уровне архитектуры задачи:

• Сколько байт нужно переместить и сколько операций выполнить над ними? Если операций на байт мало (одно-два действия) — сигнал в пользу CPU или как минимум повод для батчинга перед переносом.
• Можно ли объединить много маленьких передач в одну большую? Одна передача 10 МБ почти всегда эффективнее, чем тысяча передач по 10 КБ — из-за латентности инициации каждой отдельной операции копирования.
• Данные загружаются один раз или на каждой итерации? Если один раз (веса модели, статичный датасет, единожды посчитанные константы), то стоимость переноса амортизируется на все последующие вычисления и перестаёт быть проблемой.
• Используется ли pinned (page-locked) память на стороне хоста? Обычная память может быть переставлена операционной системой, из-за чего DMA-контроллеру приходится работать медленнее или через дополнительный буфер. Закреплённая (pinned) память ускоряет именно передачу — но сама по себе не решает проблему низкой арифметической интенсивности задачи.
• Можно ли перекрыть передачу вычислениями? CUDA-streams и подобные механизмы в других фреймворках позволяют пока одна порция данных считается на GPU, параллельно грузить следующую по шине. Это не убирает стоимость передачи, но прячет её за уже идущими вычислениями — работает только если вычислений на GPU достаточно много, чтобы было что перекрывать.
• Что покажет реальный профилировщик? Прежде чем принимать архитектурное решение, стоит один раз замерить долю времени, которая уходит на host-to-device и device-to-host копирование, отдельно от времени самого вычисления — инструменты вроде nsys/nvprof показывают это разделение прямо в таймлайне.

Если после такого разбора соотношение выходит не в пользу GPU — это нормальный, вполне легитимный результат, а не повод считать, что вы «неправильно готовите» видеокарту. Не любая задача автоматически ускоряется переносом на GPU: часть кода в реальных системах либо остаётся на CPU осознанно, либо требует предварительной агрегации данных, чтобы разовая стоимость пересечения шины окупилась объёмом последующих вычислений. Если вы выбираете между локальным железом и арендой сервера под конкретный профиль нагрузки, сравнение вариантов CPU и GPU стоит делать именно в этих терминах — я разбирал подход подробнее в статье CPU или GPU для локальной LLM: что выгоднее.

Частые вопросы