Core ML/DL Frameworks
The tools that turn the theory from Deep Learning into code you can actually run and train.
PyTorch
The dominant deep learning framework in both research and production today. Three ideas make it what it is:
- Tensors: PyTorch's core data structure — multi-dimensional arrays (see Linear Algebra) that can live on CPU or GPU, with the same operations (matrix multiply, elementwise ops) either way.
- Autograd: PyTorch automatically builds a computation graph as you run the forward pass, and calling
.backward()computes every gradient via the chain rule (see Calculus & Optimization) — you write the forward pass, PyTorch derives backpropagation for you. This is exactly the real forward-then-backward computation.backward()automates — step through it by hand once, and every.backward()call afterward is legible instead of magic:
nn.Module: the base class for defining a layer or a whole model — you define__init__(the layers/parameters you need) andforward(how data flows through them), and PyTorch handles tracking parameters, moving them to GPU, and saving/loading.
A typical training loop: forward pass → compute loss → loss.backward() → optimizer step → zero gradients → repeat. Once you've written this loop once by hand, every framework built on top of PyTorch (Hugging Face Trainer, PyTorch Lightning) is just automating that same loop with more features.
Hugging Face transformers and datasets
transformers provides ready-to-use implementations of essentially every popular model architecture (BERT, GPT-family, LLaMA, ViT, and hundreds more) along with pretrained weights — instead of implementing a Transformer from scratch (worth doing once for learning, see Attention & Transformers), you load a pretrained model in a few lines and fine-tune it for your task.
datasets provides a standard interface for loading, processing, and streaming datasets (including many large public ones) without manually writing data-loading boilerplate for each one — important because efficient data loading is often the actual bottleneck in training, not the model itself.
Experiment Tracking
Training runs involve many hyperparameters, and comparing dozens of runs by memory doesn't scale. Tools like Weights & Biases (W&B) and MLflow log metrics, hyperparameters, and artifacts (model checkpoints) for every run automatically, and provide dashboards to compare runs side by side — the difference between "I think this run was better" and being able to actually prove it.
A real 5-run learning-rate sweep on the same task, shown the way a tracking dashboard would actually show it — sortable by final loss, click any run to see its full curve:
Sorted by final loss rather than eyeballed, the ranking isn't obvious in advance: run-4 (lr=0.4) converges fastest, run-1 (lr=0.01) is still barely moving after 25 steps despite being a perfectly reasonable-looking learning rate, and run-5 (lr=1.1) doesn't just fail to converge — it diverges, ending up worse than never training at all. Without a tracked, sortable comparison, run-5's divergence is obvious from a single glance, but distinguishing run-3 from run-4 — both looking "converged" by eye on a live loss curve — genuinely isn't, without the actual final numbers side by side.
W&B, in code, logs each run under a project with its hyperparameters as config and metrics logged per step:
MLflow takes the same shape with an open-source, self-hostable backend instead of a managed SaaS dashboard:
Running an actual sweep (a grid or Bayesian search over hyperparameters, exactly the 5-run comparison above but automated instead of launched by hand) is what both tools are built to orchestrate directly — W&B Sweeps and MLflow's integration with Optuna/Ray Tune both launch, track, and rank many runs like this one automatically, rather than requiring a human to remember to compare them after the fact.
Next: LLM / Agent Frameworks — the tooling layer built on top of these for building RAG pipelines and agents specifically.