Как устроена видеокарта и куда уходит время

Зачем это нужно

В уроке 3.3.1 вы узнали, что GPU — это «тысячи простых ядер», и научились честно замерять время с torch.cuda.synchronize(). В уроке 5.1.1 посчитали бюджет обучения через паспортные 97.5 TFLOPS RTX 4080 и MFUутилизация FLOPs модели (MFU)EN model FLOPs utilization (MFU)Доля пиковой производительности железа, которая уходит на полезные вычисления модели. Для больших распределённых обучений типичны 30–50 %.. Если вы запускали «baby GPT» из урока 4.6.2 на видеокарте, то, скорее всего, MFU вышел заметно ниже 50%. Куда делась остальная мощность?

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

Что посмотреть параллельно

Андрей Карпатый в видео Let’s reproduce GPT-2 (124M) с отметки 1:22:18 до 2:06:54 ускоряет обучение GPT-2 с 1000 до 93 мс на шаг: тензорные ядра и TF32 (1:28:14), BF16 (1:39:38), torch.compile и слияние ядер (1:48:15), FlashAttention (2:00:18). Это ровно темы урока, показанные вживую. Русских субтитров нет, но автоперевод YouTube справляется.

Из чего состоит видеокарта

Процессор вашей машины — 48 мощных ядер, каждое умеет всё: ветвления, предсказания переходов, сложные инструкции. GPU устроен наоборот. В RTX 4080 76 одинаковых «цехов» — потоковых мультипроцессоровпотоковый мультипроцессор (SM)EN streaming multiprocessor (SM)Основной «цех» GPU NVIDIA: свои CUDA-ядра, тензорные ядра, регистры и shared memory. У RTX 4080 их 76, у H100 и H800 — 132. Блок потоков целиком выполняется на одном SM. (SM). В каждом SM 128 простых арифметических блоков для FP32 (NVIDIA называет их CUDA-ядрами), 4 тензорных ядра, свой файл регистров и своя быстрая память. Итого $76 \cdot 128 = 9728$ CUDA-ядер и $76 \cdot 4 = 304$ тензорных ядра — так в whitepaper NVIDIA по архитектуре Ada.

Отсюда паспортный пик FP32. Каждое CUDA-ядро за такт делает одно умножение-сложение (FMA, $a \cdot b + c$) — это 2 операции. При частоте 2.505 ГГц (boost по паспорту):

$$9728 \cdot 2 \cdot 2.505 \cdot 10^9 \approx 48.7 \cdot 10^{12}\ \text{FLOP/с}.$$

Читаем: «число ядер × 2 операции за такт × тактов в секунду». Это те самые 48.7 TFLOPS из урока 3.3.1.

Как GPU выполняет программу. Программа для GPU называется ядромядро GPU (kernel)EN GPU kernelФункция, которая запускается на GPU сразу во множестве потоков. Каждая операция PyTorch на видеокарте — запуск одного или нескольких ядер. Не путать с ядрами процессора и с CUDA-ядрами (арифметическими блоками). (kernel) — не путайте с ядрами процессора. Каждая операция PyTorch на GPU — это запуск одного или нескольких ядер: a + b — одно ядро, a @ b — другое. Ядро запускается на сетке (grid) из множества блоков потоковблок потоковEN thread block (CTA)До 1024 потоков, которые выполняются на одном SM и делят его shared memory. Ядро запускается сеткой (grid) из многих блоков.. Каждый блок целиком попадает на один SM и делится на варпыварпEN warpГруппа из 32 потоков GPU NVIDIA, которые выполняют одну и ту же инструкцию одновременно, каждый над своими данными. Если потоки варпа расходятся по разным веткам if, ветки выполняются по очереди. — группы по 32 потока, которые выполняют одну и ту же инструкцию одновременно, каждый над своими числами. Если внутри варпа потоки пошли по разным веткам if, ветки выполняются по очереди, и половина варпа простаивает.

Уровень программы	Что это	На каком «железе»
сетка (grid)	все блоки одного запуска ядра	весь GPU
блок потоков	до 1024 потоков, общая shared memory	один SM
варп	32 потока, одна инструкция на всех	планировщик внутри SM
поток	одно «скалярное» вычисление	одно CUDA-ядро

На одном SM одновременно «живут» до 48 варпов (1536 потоков) — так в Ada Tuning Guide для compute capability 8.9. Зачем так много, если CUDA-ядер 128? Чтобы прятать ожидание памяти: пока один варп ждёт данные из видеопамяти (сотни тактов), планировщик переключается на другой, у которого данные уже пришли. GPU не ускоряет доступ к памяти — он прячет его за огромным числом параллельных задач.

Иерархия памяти

Самое важное в этом уроке — память. Вот что есть у RTX 4080 (по whitepaper и Ada Tuning Guide):

flowchart TB
R["Регистры<br/>256 КБ на SM · всего 19 МБ<br/>доступ за такт"]
S["L1 / shared memory (SRAM)<br/>128 КБ на SM, из них до 100 КБ shared<br/>всего 9.5 МБ"]
L2["L2-кэш<br/>64 МБ на весь чип"]
V["Видеопамять GDDR6X<br/>16 ГБ у штатной карты · 716.8 ГБ/с"]
C["Оперативная память CPU<br/>через PCIe 4.0 x16 · около 32 ГБ/с"]
R --> S --> L2 --> V --> C

Иерархия памяти RTX 4080: чем ниже, тем больше объём и тем медленнее доступ

• Регистры — личная память каждого потока, самая быстрая. 64 тысячи 32-битных регистров на SM.
• Shared memoryshared memory (SRAM)EN shared memoryБыстрая память внутри SM, общая для потоков одного блока; физически та же SRAM, что и кэш L1. На Ada — до 100 КБ на SM. В статьях о FlashAttention её называют просто SRAM. — быстрая память внутри SM, общая для потоков одного блока. Физически это та же SRAM, что и кэш L1; сколько отдать под shared, решает программа (до 100 КБ на SM). В статьях про FlashAttention её называют просто SRAM.
• L2 — общий кэш на весь чип. У Ada он огромный, 64 МБ (у предыдущей RTX 3090 Ti было 6 МБ).
• Видеопамять — те самые гигабайты из nvidia-smi. У GeForce это GDDR6X, у серверных карт — HBMHBM, видеопамятьEN HBM (high-bandwidth memory)Основная память серверных GPU (A100, H100, H800) — микросхемы в одном корпусе с чипом. У GeForce вместо неё GDDR6X с той же ролью: большой объём, но в десятки раз медленнее SRAM. В литературе «HBM» часто означает просто видеопамять. (многослойная память в одном корпусе с чипом). Роль у них одинаковая, поэтому дальше «HBM» и «видеопамять» — синонимы.

Насколько SRAM быстрее видеопамяти? Для RTX 4080 NVIDIA этого числа не публикует, но порядок даёт статья FlashAttention (рис. 1) для A100: SRAM около 19 ТБ/с при объёме 20 МБ на весь чип, HBM — 1.5 ТБ/с при 40 ГБ. Разница больше чем на порядок, а объём меньше в тысячи раз. Отсюда главный принцип быстрых ядер: загрузить кусок данных в SRAM один раз и сделать с ним как можно больше работы, прежде чем писать результат обратно.

У вас карта на 32 ГБ

По спецификации NVIDIA у RTX 4080 16 ГБ, так что ваши 32 ГБ — нештатный вариант (скорее всего, вдвое больше микросхем памяти на той же 256-битной шине). Число SM и пропускную способность своей карты проверьте командами из блока «На вашей машине» ниже: 76 SM — чип как у RTX 4080, 80 SM — полный чип AD103, как у RTX 4080 SUPER (у неё по паспорту 736 ГБ/с).

Тензорные ядра: почему BF16 быстрее FP32

Тензорное ядротензорное ядроEN Tensor CoreБлок GPU, который за одну инструкцию умножает маленькие матрицы и прибавляет результат: D = AB + C. Работает в форматах TF32, BF16, FP16, FP8, INT8. У RTX 4080 их 304 (по 4 на SM), пик в BF16 — 97.5 TFLOPS против 48.7 у FP32 на CUDA-ядрах. за одну инструкцию умножает две маленькие матрицы и прибавляет результат к третьей: $D = A B + C$. Обычное CUDA-ядро за такт делает одно умножение-сложение, тензорное — десятки сразу. Но умеет оно только матричное умножение и только в «узких» форматах. Пиковая производительность RTX 4080 по whitepaper (плотные матрицы, без «маркетинговой» разреженности 2:4, которая удваивает числа):

Формат и блоки	Пик, TFLOPS	Где используется
FP32 на CUDA-ядрах	48.7	матмул по умолчанию в PyTorch, все поэлементные операции
TF32 на тензорных ядрах	48.7	torch.set_float32_matmul_precision("high")
BF16 / FP16 на тензорных ядрах, накопление в FP32	97.5	torch.autocast(dtype=torch.bfloat16), урок 5.4.1
FP16 на тензорных ядрах, накопление в FP16	194.9	инференс-движки; точность сумматора хуже
FP8 на тензорных ядрах, накопление в FP32	194.9	torch._scaled_mm, урок 5.4.1

Две причины, почему матмул в BF16BF16 (bfloat16)EN bfloat16 (brain floating point)16-битный формат: 1 бит знака, 8 бит порядка (как у FP32), 7 бит мантиссы. Диапазон как у FP32, точность — 2–3 значащие цифры. Стандарт обучения LLM. быстрее FP32: вдвое больше пик (97.5 против 48.7) и вдвое меньше байт на каждое число, то есть вдвое меньше нагрузка на память. Любопытная деталь GeForce: TF32 здесь не даёт выигрыша в паспорте — его пик равен FP32 на CUDA-ядрах (у серверных A100 и H100 TF32 в разы быстрее FP32). Проверьте на своей карте, что получится на практике.

Арифметическая интенсивность и roofline

У любой операции есть две цены: сколько операций $F$ (FLOP) она делает и сколько байт $M$ читает и пишет в видеопамять. У GPU — два предела: пик $P$ (FLOP/с) и пропускная способность памятипропускная способность памятиEN memory bandwidthСколько байт в секунду память отдаёт вычислителю. RTX 4080 — около 717 ГБ/с, H100 — 3.35 ТБ/с, двухканальная DDR5 — около 90 ГБ/с. Главное число для скорости decode. $W$ (байт/с). Операция не может закончиться быстрее $F / P$ (не хватит вычислителя) и быстрее $M / W$ (не хватит памяти):

$$t \ge \max\left(\frac{F}{P},\ \frac{M}{W}\right).$$

Что больше, то и узкое место. Отношение $I = F / M$ называют арифметической интенсивностьюарифметическая интенсивностьEN arithmetic intensityСколько операций приходится на один прочитанный из памяти байт (FLOP/байт). Decode с батчем 1 в BF16 — около 1, prefill на 1000 токенов — около 1000. — «сколько операций приходится на каждый байт из памяти». Сравните её с точкой перегиба $P / W$. У RTX 4080 в BF16:

$$\frac{P}{W} = \frac{97.5 \cdot 10^{12}}{716.8 \cdot 10^9} \approx 136\ \text{FLOP/байт}.$$

Операция с $I < 136$ — ограничено памятьюограничено памятью (memory-bound)EN memory-boundОперация, которая дольше ждёт данные из памяти, чем считает. Ускоряется, если читать меньше байт (квантование, GQA, MLA) или делать больше работы на каждый прочитанный байт (батчинг).: тензорные ядра простаивают, ожидая данных. С $I > 136$ — ограничено вычислениямиограничено вычислениями (compute-bound)EN compute-boundОперация, в которой вычислитель загружен полностью, а память успевает подвозить данные. Ускоряется только более быстрым железом или меньшим числом операций.: память успевает, вычислитель загружен. Достижимая скорость равна $\min(P,\ I \cdot W)$; график этой функции похож на крышу (наклонный скат и ровный конёк), отсюда название модель rooflineмодель roofline («крыша»)EN roofline modelДостижимая производительность = min(пик FLOP/с, интенсивность × пропускная способность памяти). Точка перегиба (ridge point) = пик / пропускная способность; у H100 около 295 FLOP/байт..

Пример 1: сложение двух тензоров BF16 по $N$ чисел. Операций $N$ (одно сложение на число). Байт: прочитать два тензора и записать один, $3 \cdot 2N = 6N$. Интенсивность $1/6 \approx 0.17$ — в 800 раз ниже точки перегиба. Для $N = 64 \cdot 2^{20}$ (67 млн чисел) память займёт $6 \cdot 67.1 \cdot 10^6 / 716.8 \cdot 10^9 \approx 0.56$ мс, а вычисления — около 0.001 мс (поэлементное сложение идёт на CUDA-ядрах, а не на тензорных: $67.1 \cdot 10^6 / 48.7 \cdot 10^{12} \approx 0.0014$ мс).

Пример 2: матмул $(M \times K) \cdot (K \times N)$ в BF16. Операций $2MKN$, байт $2(MK + KN + MN)$, если каждая матрица читается и пишется один раз. Для $M = K = N = 4096$: $I = 4096 / 3 \approx 1365$ — далеко правее точки перегиба.

Пример 3: слои вашей «baby GPT» (батч 64 × 256 токенов = 16 384 строки, $d = 384$):

Операция	Форма	Интенсивность, FLOP/байт	Упор
c_attn (Q, K, V одной матрицей)	$16384 \times 384 \cdot 384 \times 1152$	283	вычисления, с небольшим запасом
c_fc в MLP	$16384 \times 384 \cdot 384 \times 1536$	302	вычисления
lm_head, словарь 137 символов	$16384 \times 384 \cdot 384 \times 137$	100	память
LayerNorm, GELU, остаточное сложение	поэлементно	около 1 и меньше	память, всегда

Проверим таблицу кодом — тем же, что вы напишете в практике:

def matmul_intensity(M, K, N, b=2):          # b — байт на число (BF16 = 2)
    return 2 * M * K * N / (b * (M * K + K * N + M * N))

ridge = 97.5e12 / 716.8e9                    # точка перегиба RTX 4080, BF16
for name, shape in [("c_attn", (16384, 384, 1152)), ("c_fc", (16384, 384, 1536)), ("lm_head", (16384, 384, 137))]:
    I = matmul_intensity(*shape)
    print(f"{name:8s} I = {I:5.0f}  {'вычисления' if I > ridge else 'память'}")

c_attn   I =   283  вычисления
c_fc     I =   302  вычисления
lm_head  I =   100  память

Модель маленькая, поэтому даже её матмулы стоят недалеко от точки перегиба. У GPT-2 small ($d = 768$) или Qwen-0.5B ($d = 896$) интенсивность матмулов выше, и MFU растёт сам собой.

Roofline ещё вернётся

В уроке 7.1.1 та же модель объяснит, почему генерация токенов (decode) упирается в память при $I \approx 1$, а обработка промпта (prefill) — в вычисления. Здесь мы смотрим на обучение, где почти все матмулы большие и главный враг — поэлементные операции.

Куда уходит время шага: поэлементные операции

Посчитаем бюджет одного блока baby GPT в прямом проходе, если бы каждая операция шла на пределе своего ресурса.

• Матмулы и внимание: $58$ GFLOP в четырёх линейных слоях плюс $3.2$ GFLOP во внимании (с причинной маской считается половина матрицы). На пике 97.5 TFLOPS — 0.63 мс.
• Поэлементные операции: два LayerNorm, два остаточных сложения, GELU на тензоре $16384 \times 1536$, dropout. Каждая читает вход и пишет выход: всего около 258 МБ. На 716.8 ГБ/с — 0.36 мс.

Поэлементные операции делают 0.6% всех FLOPs, а занимают около трети времени — и это оценка снизу. Под torch.autocast LayerNorm и остаточный поток считаются в FP32 (4 байта на число), а между форматами вставляются ядра-преобразования. Добавьте накладные расходы на запуск каждого ядра (единицы микросекунд, урок 3.3.1), и станет понятно, почему MFU маленьких моделей редко поднимается выше 30–40%.

Слияние операций и torch.compile

Лекарство — слияние операцийслияние операций (kernel fusion)EN kernel fusionВыполнение нескольких операций одним ядром: промежуточные результаты остаются в регистрах или SRAM, в видеопамять пишется только итог. Главный способ ускорить memory-bound операции. Автоматически это делает torch.compile. (kernel fusion): несколько поэлементных шагов делаются одним ядром, промежуточные результаты остаются в регистрах, а в видеопамять уходит только финальный ответ.

Классический пример из видео Карпатого — GELU в приближении через тангенс, записанная формулой:

import math
import torch

def gelu_manual(x):
    return 0.5 * x * (1.0 + torch.tanh(math.sqrt(2.0 / math.pi) * (x + 0.044715 * torch.pow(x, 3.0))))

В обычном (eager) режиме PyTorch выполняет эту строку как 8 отдельных ядер: pow, умножение на 0.044715, сложение с x, умножение на константу, tanh, прибавление 1, 0.5 * x и итоговое умножение. Каждое читает свои входы из видеопамяти и пишет выход обратно: всего 10 чтений и 8 записей на каждое число. Слитое ядро читает x один раз и пишет ответ один раз — в 9 раз меньше байт. Для тензора $16384 \times 1536$ в BF16 это 1.26 мс против 0.14 мс по roofline. Для сравнения: матмул c_fc, который этот тензор породил, на пике занимает 0.20 мс. Без слияния «мелкая» GELU была бы в шесть раз дольше самого тяжёлого умножения в блоке.

(В нашей model.py стоит F.gelu — это одно готовое ядро PyTorch, так что эта конкретная беда нам не грозит. Но LayerNorm, остаточные сложения, dropout и преобразования форматов по-прежнему идут отдельными ядрами.)

torch.compiletorch.compileEN torch.compileКомпилятор PyTorch 2: TorchDynamo перехватывает граф операций модели, TorchInductor генерирует слитые ядра (на GPU — на Triton). Ускоряет обучение и инференс без изменения кода модели; первый вызов долгий из-за компиляции. делает слияние автоматически. Он перехватывает граф операций вашей модели (компонент TorchDynamo), а генератор кода TorchInductor пишет для GPU новые ядра на Triton:

• сливает цепочки поэлементных операций и редукций (LayerNorm, softmax, сложения, GELU, dropout) в одно ядро;
• оставляет большие матмулы библиотеке cuBLAS (в режиме mode="max-autotune" перебирает и свои Triton-шаблоны);
• убирает накладные расходы Python между операциями, а в режиме mode="reduce-overhead" записывает весь шаг в CUDA Graph — один запуск вместо сотен.

Посмотреть, какие ядра он сгенерировал, можно переменной окружения TORCH_LOGS=output_code: в консоль выведется код на Triton с именами вроде triton_poi_fused_add_mul_tanh_... (poi — pointwise, поэлементное) или triton_red_fused_native_layer_norm_... (red — reduction). В уроке 5.7.3 вы будете писать такие ядра сами.

Профилирование: как увидеть, куда ушло время

Модель выше — это гипотеза. Проверяют её инструментами.

nvidia-smi показывает память и GPU-Util. Осторожно: GPU-Util — это доля времени, когда на карте выполнялось хотя бы одно ядро. Одно крошечное ядро на одном SM из 76 даёт те же 100%. Если GPU-Util низкий (меньше 90%), карта ждёт процессор — данные, Python, запуск ядер. Если высокий, это ещё ничего не говорит об эффективности.

torch.profilerпрофайлерEN profilerИнструмент, который записывает, сколько времени заняла каждая операция и каждое ядро. Для PyTorch — torch.profiler (таблица и трасса для Perfetto), для всей программы — NVIDIA Nsight Systems (nsys). записывает каждую операцию PyTorch и каждое ядро GPU с их временем. Минимальный пример — профиль шага обучения из полного скрипта ниже:

from torch.profiler import ProfilerActivity, profile, record_function, schedule

acts = [ProfilerActivity.CPU, ProfilerActivity.CUDA]            # на CPU — только ProfilerActivity.CPU
with profile(activities=acts, schedule=schedule(wait=1, warmup=1, active=3)) as prof:
    for _ in range(5):                    # 1 шаг пропустить, 1 — прогрев профайлера, 3 — записать
        with record_function("train_step"):                     # своя метка на трассе
            train_step()
        prof.step()                       # сообщить профайлеру, что шаг закончился
print(prof.key_averages().table(sort_by="self_cuda_time_total", row_limit=10))
prof.export_chrome_trace("trace.json")    # открыть в https://ui.perfetto.dev

Таблица — это «кто сколько съел». На CPU (маленькая модель, 4 слоя, $d = 128$) у нас она выглядит так (сокращено, числа на вашей машине будут другими):

                                    Name    Self CPU %      Self CPU   ...   # of Calls
                                aten::mm        29.10%      99.049ms   ...          105
                             aten::addmm        14.69%      50.016ms   ...           48
aten::_scaled_dot_product_flash_atten...         7.22%      24.565ms   ...           12
                               aten::sum         3.79%      12.918ms   ...           51
                               aten::add         3.39%      11.524ms   ...           30
                     aten::gelu_backward         3.33%      11.353ms   ...           12

На GPU в таблице появятся колонки Self CUDA и строки с именами ядер: матмулы — что-то вроде sm80_xmma_gemm_bf16... или cutlass_..., внимание — flash_fwd_kernel, поэлементные — vectorized_elementwise_kernel, LayerNorm — layer_norm_kernel. Имена зависят от версий CUDA и PyTorch; узнавать их надо по смыслу.

Трасса (trace.json в Perfetto) — это время по горизонтали. Сверху строка потока CPU: Python ставит операции в очередь. Ниже строка «stream 7» (номер может отличаться): ядра на GPU. Читайте её так:

• ядра идут плотно, без щелей — GPU занят; дальше смотрите, какие ядра длинные;
• между ядрами щели — GPU ждёт CPU. Лечится крупным батчем, torch.compile, CUDA Graphs;
• много коротких ядер подряд (по 5–20 мкс) между длинными матмулами — поэлементные операции, кандидаты на слияние.

Nsight Systems (nsys) — профайлер от NVIDIA для всей программы сразу: CPU, GPU, копирования по PCIe, NCCL. Он нужен, когда торч-профайлер не видит проблему (например, задержки загрузки данных или обмен между картами): nsys profile -t cuda,nvtx,osrt -o gpt python train.py, затем nsys stats gpt.nsys-rep или графический Nsight Systems.

Практика

Напишите тайловый матмул со счётчиком обращений к медленной памяти и roofline-калькулятор. Вы увидите, во сколько раз тайлы сокращают трафик, какой тайл помещается в 100 КБ shared memory и почему одной shared memory не хватает, чтобы матмул стал compute-bound.

Тайловый матмул и roofline RTX 4080numpy · нужен интернет6 тестов

import numpy as np

# Характеристики RTX 4080 (whitepaper NVIDIA по архитектуре Ada, плотные операции без разреженности)
PEAK_BF16 = 97.5e12      # FLOP/с: тензорные ядра, BF16 с накоплением в FP32
PEAK_FP32 = 48.7e12      # FLOP/с: обычные ядра CUDA, FP32
BANDWIDTH = 716.8e9      # байт/с: видеопамять GDDR6X
SMEM_BYTES = 100 * 1024  # байт: максимум shared memory на один SM (Ada, compute capability 8.9)


# ── Готовый помощник: наивный матмул со счётчиком ─────────────────────────────
def naive_matmul(A, B):
    """C = A @ B «в лоб». Каждое C[i, j] читает строку A и столбец B из медленной памяти.

    Возвращает (C, loads), где loads — сколько чисел прочитано из медленной памяти.
    Кэша нет: одно и то же число читается заново каждый раз, когда нужно.
    """
    n = A.shape[0]
    C = np.zeros((n, n))
    loads = 0
    for i in range(n):
        for j in range(n):
            C[i, j] = A[i, :] @ B[:, j]   # строка A (n чисел) и столбец B (n чисел)
            loads += 2 * n
    return C, loads


# ── Ваша часть ───────────────────────────────────────────────────────────────
def tiled_matmul(A, B, t):
    """Тайловый матмул: C = A @ B блоками t×t.

    Для каждого тайла C[bi, bj] (t×t) идём по k-тайлам: загружаем в «быструю память»
    тайл A[bi, bk] и тайл B[bk, bj] (каждый — t·t чисел), перемножаем и прибавляем к C.
    Возвращает (C, loads), loads — сколько чисел прочитано из медленной памяти.
    n делится на t.
    """
    n = A.shape[0]
    assert n % t == 0, "n должно делиться на t"
    C = np.zeros((n, n))
    loads = 0
    # TODO: три вложенных цикла по i, j, k с шагом t; срезы A[i:i+t, k:k+t] и B[k:k+t, j:j+t]
    ...
    return C, loads


def tiled_loads(n, t):
    """Формула: сколько чисел читает тайловый матмул n×n с тайлом t. Тайлов C: (n/t)²,
    у каждого n/t шагов по k, на шаге — 2t² чисел."""
    # TODO
    ...


def max_tile(smem_bytes, bytes_per_elem):
    """Самый большой тайл t — степень двойки, — при котором три тайла t×t
    (A, B и накопитель C) помещаются в smem_bytes: 3·t²·bytes_per_elem ≤ smem_bytes."""
    # TODO: начните с t = 1 и удваивайте, пока следующий размер помещается
    ...


def matmul_intensity(M, K, N, bytes_per_elem):
    """Арифметическая интенсивность (FLOP на байт) умножения (M×K)·(K×N), если каждая
    матрица читается/пишется ровно один раз: 2MKN / (bytes·(MK + KN + MN))."""
    # TODO
    ...


def roofline(intensity, peak, bandwidth):
    """Модель roofline. Возвращает (достижимые FLOP/с, "memory" или "compute").

    Достижимая производительность = min(peak, intensity · bandwidth).
    Если intensity меньше точки перегиба peak / bandwidth — упор в память ("memory").
    """
    # TODO
    ...


if __name__ == "__main__":
    rng = np.random.default_rng(0)
    A, B = rng.standard_normal((32, 32)), rng.standard_normal((32, 32))
    _, naive = naive_matmul(A, B)
    print("наивный матмул 32×32 читает", naive, "чисел")
    C, loads = tiled_matmul(A, B, 8)
    print("тайловый, t = 8:", loads)

ЗапуститьПроверитьПодсказкаСбросить

После решения посмотрите на вывод solution: тайл BF16, который помещается в shared memory, — 128, и он даёт интенсивность $t / 2 = 64$ FLOP/байт относительно видеопамяти. Это ниже точки перегиба 136. Как же cuBLAS выжимает из карты почти пик? Помогает следующий уровень иерархии: тайлы A и B, которые одновременно нужны десяткам блоков на разных SM, приходят из L2 (64 МБ), а не из видеопамяти. Поэтому хорошие ядра заботятся о порядке обхода тайлов. В уроке 5.7.3 вы увидите это в матмуле на Triton как параметр GROUP_SIZE_M.

🖥 На вашей машине (4×GPU)

1. Паспорт своей карты. Узнайте, что у вас за чип:

import torch
p = torch.cuda.get_device_properties(0)
print(p.name, f"{p.total_memory / 2**30:.1f} ГиБ", "SM:", p.multi_processor_count, "CC:", f"{p.major}.{p.minor}")

nvidia-smi --query-gpu=name,memory.total,clocks.max.sm,clocks.max.mem,power.limit --format=csv

Ожидаем compute capability 8.9 и 76 SM (или 80, см. примечание выше). Запишите числа в журнал.

2. Пропускная способность памяти. Копирование большого тензора — чистая работа с памятью:

import time, torch
x = torch.empty(2**28, dtype=torch.bfloat16, device="cuda")   # 512 МиБ
y = torch.empty_like(x)
for _ in range(3): y.copy_(x)                                  # прогрев
torch.cuda.synchronize(); t0 = time.perf_counter()
for _ in range(20): y.copy_(x)
torch.cuda.synchronize(); dt = (time.perf_counter() - t0) / 20
print(f"{2 * x.numel() * 2 / dt / 1e9:.0f} ГБ/с")              # прочитали и записали по 512 МиБ

Паспорт — 716.8 ГБ/с; ждите заметно меньше (оценка: 80–90% паспорта).

3. FP32, TF32 и BF16. Возьмите bench из урока 3.3.1 с $n = 8192$ и замерьте три режима: FP32 по умолчанию, FP32 после torch.set_float32_matmul_precision("high") (TF32) и тензоры dtype=torch.bfloat16. Сравните с паспортными 48.7, 48.7 и 97.5 TFLOPS. Помогает ли TF32 на GeForce?

4. Профиль GPT до и после torch.compile. Скрипт profile_gpt.py ниже кладите рядом с model.py из урока 4.6.2. Он замеряет шаг обучения baby GPT в BF16, печатает MFU и таблицу профайлера, сохраняет трассу:

"""profile_gpt.py — куда уходит время в шаге обучения GPT из урока 4.6.2.

python profile_gpt.py              # обычный (eager) режим
COMPILE=1 python profile_gpt.py    # то же через torch.compile
"""
import os
import time

import torch
from torch.profiler import ProfilerActivity, profile, record_function, schedule

from model import GPT, GPTConfig

dev = "cuda" if torch.cuda.is_available() else "cpu"
compiled = os.environ.get("COMPILE") == "1"
torch.manual_seed(0)
if dev == "cuda":   # «baby GPT» из урока 4.6.2: 10.8M параметров
    cfg, B = GPTConfig(vocab_size=137, block_size=256, n_layer=6, n_head=6, n_embd=384, dropout=0.2), 64
else:               # на CPU — маленькая модель, чтобы скрипт отработал быстро
    cfg, B = GPTConfig(vocab_size=137, block_size=128, n_layer=4, n_head=4, n_embd=128), 16

model = GPT(cfg).to(dev)
opt = torch.optim.AdamW(model.parameters(), lr=1e-3)
if compiled:
    model = torch.compile(model)          # первый вызов будет долгим: идёт компиляция
x = torch.randint(cfg.vocab_size, (B, cfg.block_size), device=dev)   # случайные «токены»:
y = torch.randint(cfg.vocab_size, (B, cfg.block_size), device=dev)   # для замера скорости текст не нужен


def train_step():
    with torch.autocast(device_type=dev, dtype=torch.bfloat16, enabled=(dev == "cuda")):
        _, loss = model(x, y)             # прямой проход в BF16 на тензорных ядрах
    opt.zero_grad(set_to_none=True)
    loss.backward()
    opt.step()


def sync():
    if dev == "cuda":
        torch.cuda.synchronize()          # ждём, пока GPU реально досчитает (урок 3.3.1)


for _ in range(5):                        # прогрев: выбор алгоритмов, компиляция
    train_step()
sync()
n = 20
t0 = time.perf_counter()
for _ in range(n):
    train_step()
sync()
dt = (time.perf_counter() - t0) / n
tokens = B * cfg.block_size
n_params = sum(p.numel() for p in model.parameters())
print(f"{dev}, compile={compiled}: шаг {dt * 1000:.1f} мс, {tokens / dt:,.0f} токенов/с".replace(",", " "))
if dev == "cuda":
    mfu = 6 * n_params * tokens / dt / 97.5e12        # 6N FLOPs на токен (урок 5.1.1), пик BF16 RTX 4080
    print(f"MFU ≈ {mfu:.0%}, пик памяти {torch.cuda.max_memory_allocated() / 2**30:.2f} ГиБ")

acts = [ProfilerActivity.CPU] + ([ProfilerActivity.CUDA] if dev == "cuda" else [])
with profile(activities=acts, schedule=schedule(wait=1, warmup=1, active=3)) as prof:
    for _ in range(5):
        with record_function("train_step"):
            train_step()
        prof.step()
sort = "self_cuda_time_total" if dev == "cuda" else "self_cpu_time_total"
print(prof.key_averages().table(sort_by=sort, row_limit=10, max_name_column_width=40))
prof.export_chrome_trace(f"trace_{dev}_compile{int(compiled)}.json")   # открыть в ui.perfetto.dev

CUDA_VISIBLE_DEVICES=0 python profile_gpt.py
CUDA_VISIBLE_DEVICES=0 COMPILE=1 python profile_gpt.py
CUDA_VISIBLE_DEVICES=0 COMPILE=1 TORCH_LOGS=output_code python profile_gpt.py 2>&1 | grep -m 20 "def triton_"

Чего ждать (оценки, а не замеры: под рукой у автора урока не было RTX 4080). Шаг eager — порядка десятков миллисекунд, MFU baby GPT — 10–30%. С torch.compile первый запуск компилирует модель от десятков секунд до пары минут, а дальше шаг обычно короче на 20–50%. Самое интересное — сравнить две таблицы: в compiled-версии короткие поэлементные ядра исчезают, вместо них появляются несколько ядер triton_..., а доля матмулов и внимания в общем времени растёт. Откройте обе трассы в Perfetto рядом и найдите щели между ядрами.

Модель крупнее (n_layer=12, n_head=12, n_embd=768, как GPT-2 small, около 85M параметров с нашим словарём) поднимет MFU: матмулы станут интенсивнее. Проверьте это — и посчитайте, сколько займёт претрейн из урока 5.6.2 при вашем реальном MFU.

5. Nsight Systems (ставится вместе с CUDA Toolkit или отдельным пакетом nsight-systems):

nsys profile -t cuda,nvtx,osrt -o gpt_eager python profile_gpt.py
nsys stats --report cuda_gpu_kern_sum gpt_eager.nsys-rep | head -20   # самые долгие ядра

Настройка карт и драйверов — на странице «Ваша лаборатория (4×GPU)».

Китайский угол: DeepSeek думает в терминах SM

Теперь вы можете перечитать знакомые места из техотчёта DeepSeek-V3 другими глазами. В уроке 5.4.3 было: «из 132 SM H800 на коммуникации выделено около 20». Теперь понятно, что это значит: 20 «цехов» из 132 отдано ядрам пересылки, остальные 112 считают. Это прямой торг вычислителем ради того, чтобы пересылки шли параллельно со счётом. А перенос частичных сумм FP8 в FP32 каждые 128 элементов (урок 5.4.1) — это работа на стыке тензорных ядер (быстро, но неточный сумматор) и CUDA-ядер (медленнее, зато FP32).

Открытая библиотека DeepSeek DeepGEMM (MIT) — матмулы FP8 с поблочным масштабированием. В её README сказано, что ядра достигают до 1550 TFLOPS на H800 и что основных функций-ядер намеренно немного: библиотеку задумывали и как учебный материал по оптимизации GPU-ядер. Запустить её на RTX 4080 не получится (нужна архитектура SM90 или SM100, то есть Hopper или Blackwell), но читать код после этого модуля полезно.

Где учиться по-китайски. Курс ZOMI AISystem, раздел 02Hardware: подраздел 03GPUBase объясняет устройство GPU и эволюцию архитектур NVIDIA, 04NVIDIA — тензорные ядра и NVLink.

Термины. Потоковый мультипроцессор (SM), разделяемая память, тензорное ядро и арифметическая интенсивность по-китайски называются дословно. Варп — «пучок потоков»: образ тот же, что у английского warp, который пришёл из ткачества (нити основы). Видеопамять — буквально «память отображения», наследие времён, когда видеокарта только рисовала картинку. Слияние операций называют «слиянием операторов».

Проверь себя

Проверь себя6 вопросов·

1 Пик RTX 4080 в BF16 — 97.5 TFLOPS, пропускная способность памяти — 716.8 ГБ/с. Чему равна точка перегиба roofline (FLOP на байт)? Округлите до целого.

2 Какие операции шага обучения baby GPT упираются в пропускную способность памяти? Выберите все.Можно выбрать несколько ответов

LayerNormОстаточное сложение x + attn(x)GELU в MLPМатмул $4096 \times 4096 \cdot 4096 \times 4096$ в BF16

3 Сложение двух BF16-тензоров по $64 \cdot 2^{20}$ чисел на RTX 4080. Сколько миллисекунд займёт оно по roofline? Округлите до двух знаков.

4 Ручная GELU из 8 операций в eager делает 10 чтений и 8 записей на каждое число, слитое ядро — 1 чтение и 1 запись. Во сколько раз слияние уменьшает трафик памяти?

5 nvidia-smi показывает GPU-Util 100%. Что это гарантирует?

Все 76 SM загружены полностьюКарта выдаёт близко к паспортным TFLOPSВ каждый момент замера на карте выполнялось хотя бы одно ядроУзкое место — память, а не вычисления

6 Почему матмул в BF16 на RTX 4080 быстрее, чем в FP32? Выберите все верные причины.Можно выбрать несколько ответов

BF16 идёт на тензорных ядрах с пиком 97.5 TFLOPS, FP32 по умолчанию — на CUDA-ядрах с пиком 48.7Число в BF16 занимает 2 байта вместо 4, и памяти нужно читать вдвое меньшеBF16 точнее FP32В BF16 матмул делает вдвое меньше умножений

Проверить ответы

Итоги

• GPU — это 76 SM (у RTX 4080), в каждом 128 CUDA-ядер и 4 тензорных ядра. Программа-ядро запускается сеткой блоков; блок живёт на одном SM и выполняется варпами по 32 потока. Десятки варпов на SM нужны, чтобы прятать ожидание памяти.
• Память — иерархия: регистры → shared memory/SRAM (до 100 КБ на SM) → L2 (64 МБ) → видеопамять (716.8 ГБ/с). Быстрое ядро загружает данные в SRAM один раз и делает с ними как можно больше работы.
• Roofline: время ≥ $\max(F/P, M/W)$; точка перегиба RTX 4080 в BF16 — 136 FLOP/байт. Большие матмулы упираются в вычисления, поэлементные операции — всегда в память.
• Поэлементные операции — доли процента FLOPs, но треть времени и больше. Слияние операций (вручную или через torch.compile) убирает лишние чтения и записи. Проверяйте гипотезы профайлером: таблица — кто сколько съел, трасса — где GPU простаивает.

Дальше: FlashAttention: внимание без матрицы n×n — самый знаменитый пример того, как тайлы в SRAM и слияние операций превращают memory-bound внимание в быстрое и точное.