Что считает нейросеть

Типичный слой:

Y = XW + b

Внутри — умножения матриц, сложения, активации, свёртки, attention, нормализация. Всё это живёт в тензорах — многомерных массивах чисел:

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

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

CPU vs GPU: разная архитектура

CPU — немного мощных ядер, сложная логика, отличная универсальность и последовательные задачи.

GPU — огромное число более простых блоков, массовый параллелизм, силён в матрицах и тензорах.

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

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

Миф «для нейросетей нужен только GPU» ломается о реальность:

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

Без быстрой подготовки батчей даже топовый ускоритель простаивает.

GPU изнутри, CUDA и Tensor Cores

Современная AI-видеокарта — не «игрушка с подсветкой», а вычислительный узел: исполнительные блоки, ускорение матриц, VRAM, контроллер памяти, кэш, interconnect (связь между чипами).

Программный мост (типичный путь):

PyTorch / TensorFlow → CUDA → NVIDIA GPU

Вокруг NVIDIA выросли CUDA-ядра, библиотеки, cuDNN, TensorRT, NCCL. Преимущество — не только кремний, но и зрелая экосистема ПО.

Tensor Cores (и аналогичные матричные блоки) заточены под смешанную точность: FP32, FP16, BF16, TF32, INT8 и др. Большая сеть → матрицы → спецблоки → быстрее вычисления при аккуратном выборе формата чисел.

VRAM, bandwidth и путь данных

Во время обучения в памяти живут не только веса:

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

Поэтому модель, которая выводится на 8 ГБ, может не обучаться на той же карте: градиенты и Adam «раздувают» бюджет.

Грубая оценка:

Memory ≈ weights + gradients + activations + optimizer + overhead

Формат чисел (FP32 / FP16 / BF16 / INT8) и приёмы вроде LoRA/QLoRA сильно меняют цифру.

Объём VRAM ≠ вся история. Смотрите ещё:

FLOPS  vs  Memory Bandwidth  vs  VRAM Capacity

Задача может быть ограничена счётом (compute-bound) (упирается в счёт) или ограничена памятью (memory-bound) (упирается в скорость подкачки тензоров).

Путь данных:

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

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

Multi-GPU, TPU, NPU, Apple и другие

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

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

Больше GPU ≠ линейное ускорение: растёт цена синхронизации.

TPU — специализированное железо Google под тензоры (часто TensorFlow/JAX). Не «ещё один GPU», а другая точка в спектре: CPU универсален, GPU — массовый параллелизм, TPU — узко заточенный тензорный счёт.

NPU — AI-ускоритель в ноутбуках и телефонах, чаще под inference: речь, камера, размытие фона, локальные эмбеддинги, лёгкие LLM. Энергоэффективность важнее пиковых FLOPS.

Apple Silicon объединяет CPU, GPU и Neural Engine через unified memory — нет классического «отдельного VRAM-острова». Удобно для локального AI; стек — Metal/MPS, MLX и родственные инструменты.

Рядом: AMD (compute + ROCm), Intel (CPU/GPU/NPU), Google (TPU). Рынок шире NVIDIA, но практический выбор часто диктует поддержка фреймворка.

Накопители, классы машин и энергия

Полный контур обучения:

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

Карта приоритетов:

Большая модель / обучение?     → 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); quantization.
• Серьёзное обучение: multi-GPU, быстрый interconnect, большой RAM, питание и охлаждение.

Как найти узкое место:

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

Смотрите utilization GPU/CPU, VRAM/RAM, throughput диска и PCIe, примеров/сек.

Типичные ошибки выбора: смотреть только FLOPS; игнорировать VRAM и bandwidth; слабый CPU при сильной GPU; недооценить БП и охлаждение; ждать линейного ускорения от N карт; путать железо обучения и вывода; считать NPU заменой датацентровой GPU.

Алгоритм выбора: модель → training или inference → память → throughput → precision → framework → поддерживаемые бэкенды → бюджет / питание / охлаждение.

Классы владения (без прайс-листа — цены плывут):

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

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

Training vs inference, quantization и почему «не влезает»

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

Quantization:

FP32 → FP16/BF16 → INT8 → INT4

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

Стек: от приложения до чипа

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

Фреймворк не живёт в вакууме: его возможности упираются в аппаратным стеком. YOLO, CRNN и Transformers — разные нагрузки поверх одного принципа «тензоры → ускоритель».

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

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

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

Заключение

AI-железо — это система: CPU готовит и оркестрирует, GPU/TPU/NPU считают тензоры, память и bandwidth решают, «влезет ли», storage кормит пайплайн, а питание с охлаждением позволяют машине жить часами. Обучение и вывод требуют разных бюджетов; quantization и экспорт снимают часть ограничений. Выбирайте связку «задача → фреймворк → runtime → ускоритель», а не отдельную «самую мощную карту».

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