Почему GPU быстрее CPU для нейросетей: объяснение на пальцах

MAATRIX

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

Что вообще делает нейросеть внутри

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

Важное свойство этой операции: все умножения внутри одного слоя не зависят друг от друга. Чтобы посчитать элемент результата в строке 5, столбце 12, не нужно ждать, пока посчитается элемент в строке 1, столбце 1 — это независимые вычисления, которые в принципе можно делать одновременно. С точки зрения железа это подарок: если у вас есть тысяча исполнителей, способных умножать числа параллельно, вы отдаёте им тысячу независимых кусков работы разом, а не по очереди.

Именно это свойство — масса одинаковых, независимых, простых арифметических операций — и определяет, какая архитектура процессора выигрывает. Не «мощность» в абстрактном смысле, а соответствие формы задачи форме железа.

Архитектура CPU: немного ядер, каждое — универсальный цех

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

Под эту задачу ядро CPU — это сложное универсальное устройство. У него глубокий конвейер, предсказатель ветвлений (пытается угадать, куда пойдёт код после if, чтобы не простаивать), внеочередное исполнение (умеет переставлять инструкции местами, если это ускорит результат), большой объём кэша L1/L2/L3 на ядро, поддержка десятков разных типов инструкций. Всё это стоит транзисторов и площади кристалла.

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

Проверить это можно на любом сервере:

lscpu | grep -E "^CPU\(s\)|Model name"

Типичный вывод для арендованного выделенного сервера — что-то вроде «CPU(s): 32», и это уже хороший серверный CPU. Для сравнения — счёт ядер GPU идёт на тысячи, о чём ниже.

Архитектура GPU: тысячи простых калькуляторов в один такт

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

Под эту задачу GPU устроен принципиально иначе, чем CPU. Вместо небольшого числа сложных универсальных ядер — тысячи простых вычислительных блоков (у NVIDIA они называются CUDA-ядрами), сгруппированных в потоковые мультипроцессоры. Каждый такой блок гораздо проще ядра CPU: у него нет предсказателя ветвлений такой сложности, нет внеочередного исполнения в том же объёме, зато GPU умеет выполнять одну и ту же инструкцию сразу на множестве блоков за один такт — модель вычислений, которую называют SIMT (single instruction, multiple threads).

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

nvidia-smi --query-gpu=name,memory.total --format=csv
nvidia-smi -q | grep -i "CUDA Cores"

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

Почему это идеально ложится на матричное умножение

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

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

Обучающий фреймворк (PyTorch, TensorFlow) не считает это вручную — операция умножения матриц делегируется библиотеке, оптимизированной под конкретное железо: на GPU это cuBLAS/cuDNN от NVIDIA, на CPU — MKL или OpenBLAS. Разница в скорости между CPU- и GPU-версией одной и той же операции — не следствие плохой оптимизации CPU-библиотек, а прямое следствие того, что железу GPU физически есть куда девать тысячи параллельных потоков, а железу CPU — нет.

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

Почему CPU-инференс вообще работает

Раз GPU настолько лучше подходит под форму задачи, разумный вопрос — почему инференс на CPU вообще существует и почему многие держат модели без видеокарты. Ответ простой: CPU не умеет делать эту работу параллельно в таком же масштабе, но он умеет делать её вообще. Матричное умножение — это просто арифметика, а любой процессор, способный складывать и умножать числа, способен её выполнить, просто медленнее — примерно пропорционально тому, во сколько раз меньше независимых вычислений он может вести одновременно.

Отсюда практическое следствие: CPU-инференс не «сломан» и не «неправильный» способ запустить модель — это тот же самый расчёт, только идущий по более узкому «руслу» параллелизма. Для маленьких моделей или редких запросов это узкое русло не успевает стать узким местом на практике — а для тяжёлых моделей под нагрузкой становится им очень быстро.

Смягчить разрыв частично помогает квантование — снижение точности весов модели (с FP16 до INT8 или ещё ниже), которое уменьшает объём данных, которые нужно перемещать и обрабатывать за один проход. Это не убирает архитектурную разницу CPU и GPU, но снижает абсолютную величину работы на каждом шаге. Подробнее о выборе уровня квантования и компромиссах — в статье Квантование моделей: Q4, Q5, Q8 — что выбрать.

Где CPU всё ещё конкурентен

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

• Маленькие модели. Модель на 1–3 млрд параметров в квантованном виде создаёт заметно меньше работы на каждый токен, чем модель на 70 млрд — и на современном серверном CPU может выдавать вполне рабочую скорость для единичного пользователя, без ожидания видеокарты и без её стоимости в счёте.
• Единичные запросы без батчинга. Параллелизм GPU раскрывается сильнее всего, когда есть много независимой работы одновременно — либо большая матрица, либо много запросов, посчитанных пачкой (батчем). Один пользователь, который присылает по одному запросу и ждёт ответа, использует GPU не на полную — хотя всё равно быстрее CPU на той же модели, разрыв в таком сценарии меньше, чем под нагрузкой с батчингом.
• Эмбеддинги и лёгкие модели классификации. Задачи, где сеть маленькая, а вызовов много, но каждый недорогой — иногда экономически выгоднее считать на CPU-инстансе, чем держать GPU ради операции, которая не успевает загрузить его полностью. Отдельно разбираем этот случай в статье Как считать эмбеддинги на CPU без GPU.
• Экономика редкого использования. Если модель нужна не постоянно, а от случая к случаю, содержать простаивающую видеокарту может быть дороже, чем смириться с более медленным, но рабочим CPU-инференсом.

Таблица ориентиров — не точные цифры, а направление выбора:

Как соотнести это с конкретным железом сервера под Ollama на CPU — отдельная практическая инструкция: Ollama на CPU: какой сервер выбрать.

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