Зачем нужен ML-фреймворк

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

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

Что внутри: тензор, граф, autograd

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

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

Тензор — многомерный массив с типом, формой и устройством. Изображение часто [C, H, W], батч — [B, C, H, W]. Нейросети живут тензорами, потому что почти все операции — массовые линейные алгебраические преобразования.

Граф вычислений (computational graph) — запись того, какие операции породили тензор (для обратного прохода).

Автоматическое дифференцирование (autograd) — автоматический расчёт градиентов по этому графу.

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

Цикл обучения:

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

micrograd и tinygrad: понять, а не только вызывать API

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() снаружи — внутри обход графа, производные, память и запуск ядер на выбранном устройстве.

Для OCR, CRNN, YOLO-экосистемы и большинства vision-пилотов PyTorch — разумный старт. Дальше веса часто уходят в ONNX для сервера или браузера.

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

TensorFlow, Keras и JAX

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 vs inference и путь до железа

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.

Сравнение и путь новичка

Маршрут изучения:

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 наугад без проверки драйверов.

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

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

• 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)