Сеть повторяет одно и то же движение

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

Внутри строки — умножения, сложения, активации, свёртки, механизм внимания (attention) и нормализация. Числа лежат в многомерных массивах, тензорах, а не в отдельных переменных. До формулы слой легко принять за список разных имён. Строка ниже оставляет одно движение, которое ряд конфорок может повторять вместе:

Y = XW + b

После неё всё, что ниже по стеку, существует ради повтора этой строки, а не ради новых названий. X — вход, W — веса, b — смещение, Y — выход.

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

Tensor → операции → огромный поток чисел → вычислительное железо

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

Пока процессор готовит батч, карта ждёт

Вернитесь к плите из начала. Картинки ещё на диске: CPU открывает файлы, декодирует их и складывает батч. Это повар у доски. GPU в этот момент не умножает матрицы — считать нечего. Узкое место — подготовка данных.

Разница в том, как устроены чипы. У CPU несколько мощных ядер и сложное управление: удобно вести ветвления, загрузку и всё, где шаг зависит от предыдущего. У GPU сетка более простых блоков: одна и та же работа на многих числах сразу, то есть матрицы и тензоры. Схема меняет масштаб: четыре крупных ядра против поля мелких конфорок.

CPU:  [Core] [Core] [Core] [Core]

GPU:  [ ][ ][ ][ ][ ][ ][ ][ ]
      [ ][ ][ ][ ][ ][ ][ ][ ]
      [ ][ ][ ][ ][ ][ ][ ][ ]

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

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

CPU → data loading, preprocessing, orchestration, control
         ↓
GPU → tensor ops, matmul, слои, training / heavy inference

Подписи на схеме по-английски. Смысл прямой: пока верхняя строка не отдала батч, нижняя ждёт. Даже сильный ускоритель простаивает, если картинки всё ещё декодируются на CPU.

Что вы покупаете вместе с картой

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

Фреймворк не зажигает огонь сам. Типичный путь на NVIDIA выглядит так: шаг записан в PyTorch или TensorFlow, дальше его подхватывает CUDA, и только потом команда доходит до GPU. Схема вставляет кухню между бланком заказа и конфоркой:

PyTorch / TensorFlow → CUDA → NVIDIA GPU

Если на этом пути нет драйвера или библиотеки, которую фреймворк умеет вызвать, быстрый чип остаётся тёмным. Вокруг NVIDIA поэтому выросли ядра CUDA, cuDNN, TensorRT и NCCL. Практический выигрыш — зрелый набор программ, не только кремний.

Большие матрицы на этом чипе считают отдельные блоки смешанной точности. Их называют Tensor Cores (и у других вендоров есть аналоги). Форматы — FP32, FP16, BF16, TF32, INT8 и другие. Большая сеть даёт большие матрицы; спецблоки проходят их быстрее, если формат выбран аккуратно и качество от этого не разваливается. Это тот же ряд конфорок, собранный под одно крупное движение.

Сначала память, потом скорость обмена

Модель спокойно отвечает на 8 ГБ и падает, как только на той же карте включают обучение. На выводе на столешнице в основном веса: тарелку отдают как есть. На обучении рядом живут активации, градиенты, состояния оптимизатора и служебные буферы. Adam этот список заметно раздувает.

Смотрите, что занимает VRAM, а не одну строку «веса модели». Схема раздвигает столешницу: на ней не одна тарелка, а весь рабочий набор.

VRAM → weights · activations · gradients · optimizer states · buffers

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

Memory ≈ weights + gradients + activations + optimizer + overhead

Слагаемые те же, плюс накладные расходы. Формат чисел (FP32, FP16, BF16, INT8) и приёмы вроде LoRA и QLoRA сильно меняют итог: меньше бит на число — и та же карта вдруг вмещает шаг. Столешница не выросла. На каждое число приходится меньше места.

Объёма VRAM мало, чтобы выбрать карту. Одна и та же модель может упираться в скорость счёта или в то, как быстро тензоры едут через память. В обзорах эти три величины стоят рядом, и их легко спутать. Схема разводит три разных предела: сколько движений успевают конфорки, как быстро заготовки едут по столешнице и сколько на ней места.

FLOPS  vs  Memory Bandwidth  vs  VRAM Capacity

Слева — сколько операций чип успевает: упор в счёт (compute-bound). Справа — сколько памяти есть. Посередине — скорость обмена с памятью (memory-bound): карта сильная, а тензоры не успевают доехать. Пиковые FLOPS эти три случая не различают.

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

Storage (SSD) → RAM → CPU → PCIe → GPU VRAM

Диск, оперативная память, процессор, шина PCIe, видеопамять. Медленный диск, узкий PCIe или загрузчик, который не успевает готовить батчи (DataLoader), оставляют GPU в том же простое, что в начале статьи. Когда карт несколько, добавляется связь между рядами: быстрый interconnect (NVLink и аналоги), NCCL и коллективные операции. Иначе распределённое обучение упирается в обмен, а не в терафлопсы. Второй ряд конфорок стоит, если между рядами узкий проход.

Когда одной карты мало

Одного ряда конфорок перестаёт хватать в двух разных местах. Либо шаг не влезает на столешницу, либо влезает, но идёт слишком долго. Вторая карта сама по себе скорость не удваивает: сначала решают, что именно режут.

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

• параллелизм по данным — разные батчи на копиях модели;
• параллелизм модели / тензоров / конвейера — части модели на разных GPU.

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

Дальше по спектру уже не ещё один GPU. TPU — специализированные чипы Google под тензоры, чаще в связке с TensorFlow или JAX. CPU остаётся универсальным, GPU даёт массовый параллелизм, TPU считает узко тензорную работу. Это другая точка спектра: конфорка под одно движение, а не замена всей плите.

NPU стоит в ноутбуках и телефонах и почти всегда занят выводом, не обучением: речь, камера, размытие фона, локальные эмбеддинги, небольшие LLM. Здесь важнее энергия на один ответ, чем пиковые FLOPS. Маленькая конфорка отдаёт одну тарелку и не держит на столешнице черновик обучения.

Apple Silicon собирает CPU, GPU и Neural Engine в одной памяти — unified memory. Отдельного острова VRAM, куда тензор надо копировать по PCIe, нет: повар и конфорки делят одну столешницу. Для локальных экспериментов это удобно. Программы ходят через Metal и MPS, MLX и родственные инструменты.

Рядом живут AMD (счёт и ROCm), Intel (CPU, GPU и NPU) и Google (TPU). Рынок шире NVIDIA. Практический выбор почти всегда упирается в то, видит ли фреймворк этот runtime: CUDA, ROCm, Metal или TPU.

Где машина реально тормозит

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

Dataset → SSD → RAM → CPU preprocess → PCIe → GPU VRAM
        → forward → loss → backprop → optimizer → new weights → repeat

Левая половина — подача данных, правая — сам шаг. Если GPU в этом круге простаивает, усиливать карту рано: сначала чинят диск, память и подготовку батча на CPU. Более мощный ряд конфорок не начнёт работу, пока кладовая не отдаёт продукты.

Куда смотреть первым, зависит от симптома. Большая модель на обучении — это VRAM и GPU. Карта простаивает — конвейер данных, CPU, SSD и RAM. Маленькая локальная модель часто живёт на CPU, NPU или в общей памяти. Огромный набор данных упирается в SSD, RAM и предзагрузку следующего батча. Четыре строки ниже меняют вопрос с «какой чип быстрее» на «куда смотреть первым»:

Большая модель / обучение?     → VRAM / GPU
GPU простаивает?               → конвейер данных / CPU / SSD / RAM
Маленькая локальная модель?    → CPU / NPU / unified memory
Огромный датасет?              → SSD + RAM + prefetch

Стрелка показывает первое место, куда смотреть, а не какой чип «вообще быстрее». По задачам ориентиры такие. Таблица не добавляет машин: она раскладывает тот же выбор по знакомым работам.

Классы машин ниже — без артикулов и цен. Цены плывут, развилка одна и та же. Для учёбы хватает CPU, 16–32 ГБ RAM, умеренного GPU и SSD. Для компьютерного зрения берут сильнее GPU и больше VRAM, быстрый SSD и достаточный CPU. Для локальной LLM главное — доступная память, VRAM или общая память (unified memory), и квантование. Серьёзное обучение — это multi-GPU, быстрый interconnect, большой объём RAM, питание и охлаждение.

• Учёба / старт: CPU, 16–32 ГБ RAM, умеренный GPU, SSD.
• Компьютерное зрение: сильнее GPU и VRAM, быстрый SSD, достаточный CPU.
• Локальная LLM: главное — доступная память (VRAM или общая память); квантование.
• Серьёзное обучение: multi-GPU, быстрый interconnect, большой RAM, питание и охлаждение.

Симптом читается с загрузки, не с названия карты. Четыре вопроса переводят стрелку прибора в первое место поломки:

GPU ~100%?  → compute-bound
GPU ~20%?   → конвейер данных / CPU / I/O
VRAM 100%?  → batch / модель / precision
Диск busy?  → storage

Около ста процентов на GPU — упор в счёт: конфорки заняты. Около двадцати — простаивает подача: CPU, диск, ввод-вывод. Память забита — столешница кончилась, уменьшайте батч, модель или точность чисел. Диск занят — узкое место в кладовой. Рядом смотрят загрузку GPU и CPU, занятость VRAM и RAM, скорость диска и PCIe и сколько примеров в секунду проходит.

Типичная ошибка покупки — смотреть только на FLOPS. Рядом забывают VRAM и скорость обмена, ставят слабый CPU к сильной карте, недооценивают блок питания и охлаждение, ждут линейного ускорения от N карт, путают железо обучения и вывода и считают NPU заменой датацентровой GPU.

Порядок выбора короткий. Сначала модель, затем обучение или вывод, память, пропускная способность, точность чисел, фреймворк и поддерживаемые им бэкенды, и только потом бюджет, питание и охлаждение.

Классы владения растут в ту же сторону. Прайс-листа нет: цены плывут. Лестница ниже меняет не скорость одного чипа, а масштаб кухни: от одной плиты до зала, где питание и охлаждение уже часть работы.

Ноутбук → рабочая станция → 1 мощная GPU → `multi-GPU` → AI-сервер → кластер

Вместе с классом растут задачи, память, энергопотребление и стоимость владения. GPU нужно питать и охлаждать: TDP, блок питания, поток воздуха, шум. Дата-центр на конце шкалы — это стойки, сеть, питание и охлаждение на масштабе, а не игровой ПК с RGB.

Запустить чат и обучить с нуля — разные бюджеты

Чат на этой машине отвечает, а обучение той же модели не стартует. На выводе на столешнице нет градиентов и состояния оптимизатора: тарелку отдают, черновик рецепта на столе не держат. На обучении они обязательны и занимают память. Задержка на обучении терпит долгий шаг. На выводе часто решает, ответит ли сервис сразу. Энергия важна в обоих случаях и особенно на выводе: там NPU как раз уместен, а на обучении встречается реже. По памяти эти два бюджета расходятся на порядок.

Таблица собирает эти два бюджета рядом. Колонки расходятся там, где на обучении ещё живут градиенты и оптимизатор, а на выводе важнее задержка и энергия.

«Мощный ПК не тянет» обычно значит одно из знакомого списка: мало VRAM или RAM, слишком большая модель или длина контекста, тяжёлые активации, большой батч, фрагментация памяти. Лекарства из того же списка: квантование, модель меньше, LoRA, разрезание по картам (sharding), выгрузка части весов с карты (offloading), меньший батч и отдельная настройка вывода (ONNX). Разрезание уносит кусок модели на соседний ряд конфорок. Выгрузка снимает часть весов со столешницы карты.

Квантование сжимает тот же ряд форматов, который уже встречался у матричных блоков. Стрелка ниже меняет плотность нарезки: меньше бит на число, меньше след на той же столешнице.

FP32 → FP16/BF16 → INT8 → INT4

Меньше бит — меньше размер и след в памяти, иногда выше скорость, и остаётся риск по качеству. Для локальных LLM это часто единственный способ вообще уместить модель.

Заказ доходит до конфорок только через кухню

Вы вызываете фреймворк. Он вызывает библиотеки. Библиотеки вызывают runtime — CUDA, ROCm, Metal или TPU. Runtime говорит с GPU, TPU, NPU или CPU. Чип всё равно ждёт память, шину, диск и сеть. YOLO, CRNN и трансформеры грузят эту цепочку по-разному, но принцип один: тензоры едут на ускоритель. Бланк заказа не прыгает сразу на огонь.

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

Application
   ↓
PyTorch / TensorFlow / JAX
   ↓
ML libraries
   ↓
CUDA / ROCm / Metal / TPU runtime
   ↓
GPU / TPU / NPU / CPU
   ↓
Memory · PCIe / fabric · Storage / Network

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

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

Дальше по теме

• PyTorch vs TensorFlow
• ML-фреймворки
• ONNX: от PyTorch до Runtime
• WebGPU + Transformers.js
• Инженерия YOLO
• Компактная CRNN

Заключение

Следующий простой GPU начинается с цепочки, а не с покупки карты помощнее. Пока повар ещё режет, более мощный ряд конфорок остаётся холодным.

На следующую задачу порядок такой:

1. Проверьте, не декодирует ли CPU ещё батч.
2. Проверьте, влезает ли шаг в память.
3. Дальше идут математика сети, фреймворк, runtime, ускоритель, память и ввод-вывод.

CPU готовит данные и ведёт цикл. GPU, TPU или NPU считают тензоры. Память и скорость обмена решают, влезет ли шаг. Диск кормит конвейер. Питание и охлаждение позволяют машине жить часами. Обучение и вывод требуют разных бюджетов. Квантование и экспорт снимают часть ограничений.

Схема повторяет этот порядок и ставит ускоритель после фреймворка, который его вызовет:

Математика сети → Framework → Runtime (CUDA/…) → Accelerator → Memory/IO

Ускоритель имеет смысл после того, как ясно, какой фреймворк его вызовет и влезет ли шаг в память. Пока батч не доехал до столешницы и не поместился на ней, более мощный ряд конфорок остаётся холодным.