Двигатель из болтов собрать можно — для поездки нужен автомобиль

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

Фреймворк не «является» нейросетью. Он снимает рутину, чтобы вы думали о модели и данных, а не о том, как в очередной раз переложить активации в память перед обратным проходом.

Под капотом: тензор, граф и autograd

В дорожном автомобиле вы смотрите на панель, а под капотом крутятся узлы, без которых поездки не будет. У ML-фреймворка та же раскладка: сверху понятный API, внутри — массив с устройством, запись операций и автоматический расчёт производных.

Типичная архитектура:

                 ML Framework
                      │
        ┌─────────────┼─────────────┐
        ↓             ↓             ↓
     Tensor        Autograd       Models
        │             │             │
        ↓             ↓             ↓
   CPU / GPU       Gradients      Layers
        │             │             │
        └─────────────┼─────────────┘
                      ↓
                  Optimizer → Training

Тензор — многомерный массив с типом, формой и устройством. Изображение часто [C, H, W], батч — [B, C, H, W]. Нейросети живут тензорами, потому что почти все операции — массовые линейные алгебраические преобразования. Граф вычислений — запись того, какие операции породили тензор (для обратного прохода). Автоматическое дифференцирование (autograd) — автоматический расчёт градиентов по этому графу.

Дальше навешиваются привычные детали кузова: функция потерь, оптимизатор (SGD, Adam, …), слои (Linear, Conv2d), модель как композиция слоёв, Dataset/DataLoader, абстракция устройства (cpu / cuda / …), сериализация весов. Цикл обучения — маршрут, по которому автомобиль ездит снова и снова:

данные → модель → prediction → loss → backpropagation → gradients → optimizer → новые weights

На верстаке и на голом шасси: micrograd и tinygrad

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

micrograd (идея Andrej Karpathy) — крошечная реализация скалярного autograd. Цель не скорость, а ясность: узел хранит значение и локальный градиент, backward идёт по рёбрам назад. После раздела читатель видит: autograd — не магия, а аккуратный обход графа. tinygrad — маленький фреймворк с собственной философией минимализма и прозрачности стека (не «урезанный PyTorch»). Полезен, когда хочется увидеть, как операция доходит до ускорителя, без километров индустриальных абстракций. Для прод-CV его обычно не выбирают первым; для учёбы устройства ML-стека — да.

Как выглядит идея на пальцах. Узел хранит значение и локальный вклад в производную. Если c = a * b, то при обратном проходе вклад в a пропорционален b, вклад в b — пропорционален a. Цепочка a → b → c раскрывается как последовательное применение правила цепочки. Именно это и делает loss.backward() в большом каркасе — только на тензорах и с оптимизациями памяти.

PyTorch — дорожный автомобиль для большинства маршрутов

PyTorch стал де-факто стандартом deep learning в исследованиях и большей части прикладного CV/LLM-стека. Это не учебный макет: за рулём вы получаете torch.Tensor, torch.nn, torch.optim, Dataset/DataLoader, autograd, CUDA, сохранение (state_dict, .pt) — полный набор для повседневных поездок.

Минимальный цикл:

for x, y in dataloader:
    optimizer.zero_grad()
    prediction = model(x)
    loss = criterion(prediction, y)
    loss.backward()
    optimizer.step()

zero_grad очищает прошлые градиенты; forward считает предсказание; criterion — ошибку; backward наполняет .grad; step обновляет веса. Одна строка loss.backward() снаружи — внутри обход графа, производные, память и запуск ядер на выбранном устройстве. Ту же цепочку вы уже видели на верстаке micrograd; здесь она спрятана за панелью.

Для OCR, CRNN, YOLO-экосистемы и большинства vision-пилотов PyTorch — разумный старт. Дальше веса часто уходят в ONNX для сервера или браузера. Сохранение модели — отдельный навык. Обычно сохраняют state_dict (веса), а не весь Python-объект целиком: так проще версионировать код модели и подгружать чекпоинт на другой машине. Формат .pt / .pth — соглашение экосистемы torch, а не универсальный «формат любой нейросети».

TensorFlow, Keras и JAX — другие дороги, другие машины

Не все маршруты ведут по одной и той же трассе. Где-то уже проложена инфраструктура обслуживания, где-то нужен другой стиль вождения, где-то дорога идёт через облачные ускорители Google.

TensorFlow долго был главным индустриальным каркасом. Сегодня важен связкой с Keras, tf.data, обслуживанием моделей и сценариями, где уже сложилась TF-инфраструктура. TensorFlow 2.x сделал упор на немедленное исполнение (eager) — ближе к привычному императивному стилю. Keras — высокоуровневый API моделей. Исторически сросся с TF как tf.keras; отдельно существует развитие Keras как удобного слоя над разными бэкендами. Упрощённо:

Keras → высокоуровневый API модели
TensorFlow → вычисления и экосистема (часто как backend)

JAX — другой взгляд: «NumPy + дифференцирование + JIT + ускорители» в функциональном стиле. jax.numpy, grad, jit, vmap — трансформации функций, а не «объект nn.Module с состоянием» как в классическом API PyTorch. Силён в исследованиях и на TPU; кривая входа выше, если вы пришли из объектного nn.Module. Простой каркас мысли для JAX: пишете функцию потерь как чистую функцию от параметров и батча, затем grad(loss_fn) даёт градиент, jit ускоряет компиляцией, vmap — векторизацией по оси батча. Состояние модели обычно явные массивы/деревья, а не скрытые буферы внутри объекта слоя. Это удобно для исследований и сложных трансформаций, но требует дисциплины, если вы привыкли к «слою с .parameters() внутри».

Рядом с автомобилем — кузова, запчасти и отдельный мотор для поездки

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

Кратко по периферии: MXNet — исторически важен, сейчас реже на слуху; PaddlePaddle — своя экосистема; OneFlow — нишевые сценарии; MLX — интересен на Apple Silicon (единая память, GPU Apple). ONNX Runtime — в первую очередь движок вывода, не полноценный фреймворк обучения в стиле PyTorch:

Training (PyTorch / TF / …) → ONNX → ONNX Runtime → Inference

Отдельно: фреймворк обучения ≠ библиотека готовых моделей.

PyTorch          → инструмент создать и обучить
Ultralytics YOLO → готовый контур детекции поверх экосистемы
HF Transformers  → модели и пайплайны поверх каркасов
timm / Diffusers → зоопарки моделей и утилит

Путать «поставим YOLO» с «выбрали фреймворк» — как путать готовый кузов с самим автомобилем. Частая ошибка новичка.

Какая дорога — какая машина

Таблица ниже — не рейтинг «кто лучше», а соответствие маршруту. Сначала задача и железо, потом логотип.

Какой моторный отсек: CPU, GPU и TPU

Автомобиль едет только если моторный отсек согласован с дорогой. Устройство в фреймворке — такой же контракт: не название на шильдике, а драйверы, сборка и бэкенд.

Framework → CPU | GPU (CUDA / Apple / …) | TPU

• CPU — всегда доступен; для учебных моделей и отладки часто достаточно.
• NVIDIA CUDA — основной ускоритель для PyTorch/TensorFlow в проде и исследованиях.
• Apple GPU — Metal / MPS в PyTorch, плюс отдельный интерес к MLX на единой памяти.
• AMD — зависит от стека (ROCm и сборки); проверяйте поддержку конкретной версии каркаса.
• TPU — сильная сторона JAX/TensorFlow в облачных сценариях Google.

device = "cuda" — контракт с окружением, не заклинание. Перенос тензора и модели на устройство (to(device)) должен быть согласован: иначе получите ошибку или тихий проигрыш скорости.

Собрать автомобиль и сесть за руль — не одно и то же

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

TRAINING:  данные → модель → loss → backprop → weights
INFERENCE: данные → модель → результат

От Python до GPU путь длиннее, чем кажется с панели:

Python → Framework API → тензорные операции → backend → CUDA/Metal/TPU runtime → hardware

Строка x @ weights может развернуться в огромный объём работы на видеокарте — поэтому «простой API» не значит «простая реализация». Связка с браузером — когда собранный автомобиль отдают в другой гараж только для поездки:

PyTorch (обучение) → ONNX → Transformers.js / ORT Web + WebGPU (вывод во вкладке)

Подробности клиентского пути — в WebGPU + Transformers.js, экспорта — в ONNX: от PyTorch до Runtime.

Карта маршрутов: сравнение и путь новичка

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

Маршрут изучения — сначала верстак и основы, потом дорожный автомобиль:

Python → NumPy → основы сетей → micrograd → PyTorch → CNN → CRNN → Transformers → LLM

Ветка зрения: PyTorch → YOLO / детекция → OCR.

Первый выезд: мини-проект на рукописных цифрах

Теория без руля быстро забывается. Возьмите рукописные цифры (MNIST или свой набор) и один раз пройдите контур «руками» — от загрузки данных до отдельного скрипта вывода.

1. Загрузить данные и собрать DataLoader с батчами.
2. Описать маленький CNN (Conv → активация → пулинг → линейный слой).
3. Написать цикл обучения: zero_grad → forward → loss → backward → step.
4. Оценить точность на отложенной выборке.
5. Сохранить state_dict в .pt.
6. В отдельном скрипте загрузить веса и сделать inference без обучения.
7. Мысленно сопоставить те же шаги с идеями micrograd/tinygrad: где граф, где градиент, где «магия» API.

Практика рукописных цифр на сайте: CNN → TrOCR.

Типичные ошибки на старте

Большинство ранних сюрпризов — не «сломанный автомобиль», а путаница, что в нём двигатель, что кузов, а что только поездка.

• Считать PyTorch «нейросетью», а не каркасом.
• Путать фреймворк и готовый зоопарк моделей (YOLO/Transformers).
• Не понимать форму тензора и размерность батча.
• Копировать backward() без картины графа.
• Думать, что GPU обязателен для любой учебной задачи.
• Путать training и inference; ждать, что .pt универсален для любого рантайма.
• Выбирать device наугад без проверки драйверов.

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

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

• Железо для AI
• PyTorch vs TensorFlow
• ONNX: от PyTorch до Runtime
• WebGPU + Transformers.js
• Инженерия YOLO
• Компактная CRNN
• Рукописные цифры
• Три слоя стека LLM

Заключение

Нейросеть — математическая модель. Фреймворк — автомобиль вокруг тензоров, градиентов и устройств: двигатель из болтов собрать можно, для поездки нужна панель и кузов. micrograd и tinygrad учат разбирать мотор и смотреть на шасси; PyTorch закрывает большую часть прикладных маршрутов; TensorFlow/Keras и JAX остаются важными ветками под экосистему и ускорители; вывод часто живёт отдельно — в ONNX Runtime или даже в браузере. Выбор инструмента — ответ на вопрос «какая дорога, какое железо, кто будет сопровождать», а не охота за модным логотипом на капоте.

Concepts (tensor, grad) → Frameworks → Models (YOLO, CRNN, LLM)
                              ↓
                           Training → GPU/TPU/CPU
                              ↓
                           Inference → Server | Browser (WebGPU)