Master Notebook:
ML Systems

Tasks & Targets

An ML system exists to predict a target from a feature vector. The interviewer's very first clarifying question — "what are we predicting?" — is not rhetorical; the answer determines the loss, the metric, and whether you can even collect labels. There are four shapes of prediction problem that cover 95% of interview scenarios.

• Binary classification — the label is 0/1. Examples: click, spam, churn, fraud. Output layer is a single sigmoid; loss is binary cross-entropy.
• Multi-class — the label is exactly one of K classes. Examples: MNIST, language ID, intent routing. Softmax head; categorical cross-entropy.
• Regression — the label is a real number. Examples: ETA, price, ad CPC, latency. Linear output; MSE / MAE / Huber.
• Ranking / retrieval — there is no single "answer"; you return an ordered list. Examples: search, recommendation, ads. Loss acts on pairs or lists of items; metric is NDCG / MRR / recall@k.

Each of these maps to a different system shape. A click predictor looks like "feature store → DLRM → logistic head → calibration → bidder." A ranker looks like "candidate generator → scorer → re-ranker." If you do not name the task shape in the first two minutes of the interview, the rest of your design will drift.

Losses You Must Know

Losses are the contract between the task and the gradient. Memorize these six; almost every production system is a composition of them.

Minimal PyTorch reference

import torch
import torch.nn.functional as F

# 1) Binary cross-entropy (logit form is numerically stable)
logits = model(x)                        # shape [B]
loss = F.binary_cross_entropy_with_logits(logits, y.float())

# 2) Categorical (softmax over K)
logits = model(x)                        # shape [B, K]
loss = F.cross_entropy(logits, y.long())

# 3) Contrastive InfoNCE (batch negatives, temperature 0.07)
q = F.normalize(query_tower(x_q), dim=-1)    # [B, D]
k = F.normalize(item_tower(x_k),  dim=-1)    # [B, D]
logits = q @ k.T / 0.07                      # [B, B]
labels = torch.arange(q.size(0), device=q.device)
loss   = F.cross_entropy(logits, labels)     # diagonals are positives

Gradient-Based Training

Every model in this notebook — from two-tower to 70B transformer — is trained by the same five-line loop: sample a batch, forward, compute loss, backward, step the optimizer. What varies is the optimizer, the batch size, and the parallelism. The core loop is non-negotiable.

optimizer = torch.optim.AdamW(model.parameters(), lr=1e-3, weight_decay=1e-2)
scheduler = torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, T_max=epochs)

for epoch in range(epochs):
    for x, y in loader:
        x, y = x.to(device), y.to(device)
        optimizer.zero_grad(set_to_none=True)
        logits = model(x)
        loss   = loss_fn(logits, y)
        loss.backward()
        torch.nn.utils.clip_grad_norm_(model.parameters(), 1.0)  # stability
        optimizer.step()
    scheduler.step()

Optimizer picks, by era

• SGD + momentum — still the academic default for ResNets on ImageNet; cheap memory.
• Adam / AdamW — default for transformers and anything with sparse features. Costs 2× weights in state (first/second moment).
• Adafactor / 8-bit Adam — when optimizer state memory is the bottleneck on 10B+ params.
• Lion / Sophia — newer, faster convergence claims; not yet standard in interview answers.

Learning rate: the one hyperparameter that matters

If you have one hour to tune a model, spend it on the learning rate. Rule of thumb: Adam likes 1e-4 to 1e-3 for transformers; SGD likes 0.1 with momentum 0.9 for conv nets. A cosine schedule with 1–5% warmup is the modern default. Gradient clipping at norm 1.0 makes transformer training not blow up on the first few steps.

Overfitting & Regularization

Overfitting is when the model memorizes the training set and generalizes poorly. Every regularization technique in production ML is one of three ideas: shrink the hypothesis space, add noise, or stop early.

• L2 (weight decay) — penalize ||w||². Shrinks weights toward zero; built into AdamW. Default 1e-2 for transformers.
• L1 — penalize ||w||₁. Produces sparse weights; useful when you want feature selection.
• Dropout — randomly zero p fraction of activations during training. p=0.1 is default for transformers; p=0.5 for older FC nets.
• Label smoothing — replace one-hot targets with (1-ε, ε/(K-1)...). Prevents overconfident logits; hurts calibration slightly.
• Data augmentation — random crops/flips for images, token masking for text. Free regularization via more effective samples.
• Early stopping — watch the val loss; stop when it starts climbing. Free, always works.

Bias-Variance

Every interview eventually asks "what's bias-variance?" The short answer is: bias is how wrong your model's best guess is on average; variance is how much that guess wobbles when you resample the training set. Total error ≈ bias² + variance + irreducible noise.

Feature Types

Before encoding, classify every field. The classification dictates storage, memory, and which encoder to reach for.

• Numeric continuous — price, age, latency. Needs normalization (z-score, min-max, or quantile).
• Numeric discrete / count — num_clicks_7d, session_length. Log1p transform is the default.
• Categorical low-card — country, device type. Cardinality < 10k → one-hot or learned embedding table.
• Categorical high-card — user_id, item_id, url. Cardinality 10⁶+ → hashing trick or embedding table with row-eviction.
• Text — titles, descriptions. Tokenize (BPE/WordPiece) → token ids → embedding.
• Embedding / dense — already a vector (e.g., pretrained image CLIP features). Pass through as-is.
• Sequence — last-N clicks, last-N searches. Feed through attention, mean-pool, or GRU.

Encoding

Every category must become a number before a model can consume it. The four canonical encoders, in order of when to reach for them:

• One-hot — cardinality ≤ ~500. Simple, but size grows with cardinality.
• Label encoding + embedding table — assign each category an integer id, look up a D-dim vector. Standard for anything 1k–100M cardinality. D typically 16–256.
• Hashing trick — h(category) mod B. Collisions, but constant memory. Used by Vowpal Wabbit, ads click models. B = 2²⁰ is common.
• Target encoding — replace each category with the mean of the target for that category. Powerful but leaks labels — must be computed per-fold with smoothing.

# Hashing trick in 6 lines — O(1) memory per feature
import numpy as np
HASH_BUCKETS = 1 << 20          # 1,048,576 buckets

def encode(category: str) -> int:
    return hash(category) % HASH_BUCKETS

# Embedding lookup for this id
import torch.nn as nn
emb = nn.Embedding(HASH_BUCKETS, 32)      # 32-dim embedding, ~128 MB
vec = emb(torch.tensor([encode("us-west-2")]))

Normalization

Numeric features must live on comparable scales or gradient descent will follow the dominant feature and ignore the rest. Three canonical choices:

• Z-score: (x - μ) / σ. Default. Assumes roughly Gaussian distribution.
• Min-max: (x - min) / (max - min). Bounded to [0, 1]; fragile to outliers.
• Quantile / rank: replace x with its empirical percentile. Robust; destroys scale info.
• Log1p: log(1 + x) for heavy-tailed counts (session time, clicks).

Rule: always fit normalizer stats on train only, persist them, and reuse at serve time. Computing μ,σ from the live request stream will silently leak future data.

Train/Serve Skew

Train/serve skew is the #1 silent killer of real ML systems. The model was trained on features computed one way, but production computes them slightly differently — so the live numbers are out-of-distribution and the model silently degrades.

The four causes, in order of frequency

• Code duplication — offline feature code in Spark, online in Python. The two implementations drift. Fix: share one codebase, or use a feature store that runs both.
• Time travel — offline feature uses "last 7 days of clicks as of now" during training, but "as of now" means the label time, not the prediction time. Fix: point-in-time joins.
• Missing data handling — offline imputes missing with 0; online passes raw null. Fix: one imputation policy.
• Normalizer drift — stats recomputed on new data without retraining the model. Fix: bind normalizer version to model version.

Feature Store Architecture

A feature store is a versioned database of ML features that serves both training and serving from the same code path. The canonical architecture (Feast, Tecton, Michelangelo) has four components.

Offline vs online stores

Online serve SLO

The online store must return a batch of features (for one user + N candidates) in under 10 ms p99, because the feature fetch is one hop in a request that must finish in ~200 ms total. Redis / ScyllaDB with multi-get pipelining is the standard answer.

# Feast-style point-in-time join (pseudocode)
#   label_df  has columns: user_id, ts, clicked
#   feature_view 'user_activity' has rows (user_id, ts, n_clicks_7d, ...)
#
# The join returns the latest feature row where feature_ts <= label_ts.
from feast import FeatureStore
store = FeatureStore(repo_path=".")

training = store.get_historical_features(
    entity_df=label_df,
    features=[
        "user_activity:n_clicks_7d",
        "user_activity:avg_session_min",
        "item_stats:ctr_30d",
    ],
).to_df()

What Is An Embedding

An embedding is a D-dimensional vector that represents a discrete object (word, user, item, image, document) such that similar objects are close in vector space. D is typically 32 for small-scale recs, 128 for items, 384–768 for sentence embeddings, and 1024–4096 for state-of-the-art text retrieval.

• Two objects being "similar" means their cosine similarity is high (or their L2 distance is small).
• The embedding table is just an nn.Embedding(V, D) — a V×D matrix. Row i is the embedding for token i.
• Embeddings are learned: start random, train under some loss that pulls similar objects together and pushes dissimilar ones apart.

How Embeddings Are Trained

There are four training regimes you will be asked about.

Word2Vec / skip-gram (2013)

Predict context words from a center word. Use negative sampling: for each (center, context) positive, sample K=5–20 random words as negatives. Loss is binary cross-entropy. Trains in minutes on CPU for 10⁹ tokens. Still the baseline for cheap text embeddings.

Matrix factorization (2007)

Given a user-item rating matrix R (sparse), factor it as R ≈ U · Vᵀ. User embeddings are rows of U, item embeddings are rows of V. Loss: MSE over observed entries + L2 regularization. Solve with alternating least squares or SGD. Still the right baseline for a recommendation system interview question.

Two-tower contrastive (2019+)

Two neural networks — a query tower and an item tower — each produce a D-dim embedding. Pull (query, positive-item) pairs close, push (query, negative-item) apart with InfoNCE loss. Negatives are sampled from the batch (each row's items are positives for that row and negatives for every other row). This is the modern retrieval training recipe.

SimCLR / contrastive for images (2020)

Take an image, apply two random augmentations → x, x'. Train a network so that f(x) and f(x') are close, while f(x) and f(y) (another image) are far. InfoNCE loss with a large batch (4k–32k). Produces image embeddings without labels.

# Two-tower training loop — the retrieval-system interview special
import torch, torch.nn as nn, torch.nn.functional as F

class Tower(nn.Module):
    def __init__(self, vocab, d_in=64, d_out=128):
        super().__init__()
        self.emb = nn.Embedding(vocab, d_in)
        self.mlp = nn.Sequential(nn.Linear(d_in, 256), nn.ReLU(),
                                 nn.Linear(256, d_out))
    def forward(self, x):
        return F.normalize(self.mlp(self.emb(x).mean(1)), dim=-1)

query_tower, item_tower = Tower(10_000), Tower(1_000_000)
opt = torch.optim.AdamW(list(query_tower.parameters()) +
                        list(item_tower.parameters()), lr=1e-3)

for q_batch, pos_item_batch in loader:           # both shape [B, seq]
    q = query_tower(q_batch)                     # [B, 128]
    k = item_tower(pos_item_batch)               # [B, 128]
    logits = q @ k.T / 0.07                      # [B, B]
    labels = torch.arange(q.size(0))
    loss = F.cross_entropy(logits, labels)
    opt.zero_grad(); loss.backward(); opt.step()

ANN Indexes

Given a query vector q and N item vectors, finding the exact nearest neighbors is O(N·D) — unacceptable at N = 10⁸. Approximate Nearest Neighbor (ANN) indexes buy ~100× speedup for 1–5% recall loss. The three you must know:

HNSW — Hierarchical Navigable Small World

A layered graph: top layer is sparse with long edges, bottom layer is dense. Search greedily descends from top. Build cost high, query cost O(log N). Recall@10 > 0.95 with default params. The current production default (used by Weaviate, Milvus, Qdrant, pgvector).

IVF — Inverted File Index

K-means cluster all vectors into n_list centroids (typically √N, so ~10k for 100M vectors). At query, compute distance to every centroid, visit the n_probe closest (e.g. 16), and exhaustively scan their cluster. Recall tunable by n_probe. Memory-efficient; the default in Faiss.

PQ — Product Quantization

Split each D-dim vector into M chunks of D/M dims. K-means each chunk independently with 256 centroids → each chunk becomes 1 byte. A 768-dim float32 vector (3 KB) compresses to M=96 bytes. 32× compression. Usually combined with IVF → IVF-PQ.

Vector DB Choice

Collaborative Filtering

Collaborative filtering assumes "users who liked similar things will like similar new things." The signal is the user-item interaction matrix, no content features. Two flavors:

• User-based: for user u, find the top-K most similar users (cosine over rating vectors), recommend their top items.
• Item-based: for each item i, precompute the top-K most similar items. At serve time, aggregate the similar items of u's recent interactions. This is what Amazon famously used in the 2000s ("people who bought this also bought").

Item-based wins in practice because you precompute item-item similarities offline (expensive but batched), and online lookup is just a hash join. User-based requires recomputing per user at query time.

Matrix Factorization

Assume each user u has a latent vector p_u ∈ ℝᴰ, each item i has q_i ∈ ℝᴰ, and rating r_ui ≈ p_u · q_i. Solve min Σ (r_ui - p_u · q_i)² + λ(||p||² + ||q||²). ALS and SGD both work; ALS parallelizes better (Spark MLlib).

# Matrix factorization with SGD — the Netflix Prize recipe
import numpy as np
U, I, D = 100_000, 500_000, 64
P = np.random.randn(U, D) * 0.01
Q = np.random.randn(I, D) * 0.01
lr, reg = 0.01, 0.02

for u, i, r in interactions:             # (user, item, rating)
    pred = P[u] @ Q[i]
    err  = r - pred
    P[u] += lr * (err * Q[i] - reg * P[u])
    Q[i] += lr * (err * P[u] - reg * Q[i])

Two-Tower Retrieval

The modern drop-in for MF: one neural net per side. Query tower consumes user features + recent context and emits a D-dim vector. Item tower consumes item features and emits a D-dim vector. Train with InfoNCE. Serve by indexing every item's tower output in an ANN index and doing one ANN lookup per query.

• Input to query tower: user_id embedding, recent N clicks (sequence), country, device, time-of-day.
• Input to item tower: item_id embedding, category id, creator id, title text embedding, image embedding.
• Output: L2-normalized 128-dim vector on both sides. Similarity = dot product.
• Item tower output is precomputed offline for the full catalog and pushed to the ANN index nightly.
• Query tower runs at request time per user.

Two-tower trades some accuracy for enormous serving efficiency: a single ANN lookup replaces scoring millions of items.

Deep Retrieval & DCN

Once candidates are retrieved, you rank them with a much richer model that can consume the full cross-product of features. This is where Deep & Cross Networks (DCN v2), DLRM, and Wide & Deep live.

• Wide & Deep (Google, 2016): Wide arm is a linear model over crossed features (memorization); deep arm is a 3-layer MLP over embeddings (generalization). Sum the logits, apply sigmoid.
• DCN / DCN-v2: Explicitly learn feature crosses to arbitrary order via a cross layer: x_{l+1} = x_0 · (W·x_l + b) + x_l. Replaces hand-crafted crosses.
• DLRM (Meta, 2019): Dense features through bottom MLP, sparse features through embedding tables, all pairwise dot products, concat, top MLP. Standard for ads.

3-Stage Pipeline

Why three stages, not one

A single model that scores all 10⁹ items per request would need 10⁹ × feature_fetch × 10⁶ QPS = impossible. The three-stage funnel trades accuracy for throughput by using progressively more expensive models on progressively smaller candidate sets.

Common candidate-gen sources (union them)

• Two-tower ANN — personalized 500 items.
• Item-to-item co-visitation — 200 items similar to what user just watched.
• Popularity in user's country/language — 100 items, combats cold start.
• Recent items from subscribed channels — explicit follow signal.
• Fresh items (uploaded last 24h) — exploration slot.

Pointwise / Pairwise / Listwise

Three ways to supervise a ranker, in increasing sophistication.

• Pointwise — treat each (query, item) as an independent classification problem. Predict P(click | q, i). Loss is binary cross-entropy. Simple, fast to train, but the model does not know about ranking structure.
• Pairwise — sample pairs (q, i⁺, i⁻) where i⁺ is clicked and i⁻ is not. Train the model so score(q, i⁺) > score(q, i⁻). Losses: RankNet (logistic over score difference), pairwise hinge. Matches ranking intuition better.
• Listwise — loss operates on an entire ranked list. LambdaRank / LambdaMART weights each pair by the Δ-NDCG it would cause. ListNet applies softmax over the list. Highest accuracy but expensive to train.

# Pairwise RankNet loss — four lines
# s1 = score of item1, s2 = score of item2, y = 1 if item1 preferred else 0
import torch.nn.functional as F
def ranknet(s1, s2, y):
    # probability that 1 > 2 under the model
    p = torch.sigmoid(s1 - s2)
    return F.binary_cross_entropy(p, y)

Feature Crosses

A feature cross is a synthetic feature made by combining two raw features (e.g., user_country × item_language). Cross features model interactions that a linear model or simple MLP cannot learn at reasonable width.

• Wide models (logistic regression, FTRL) rely entirely on hand-crafted crosses. Production ads systems have crossed 10⁴–10⁶ features.
• DCN / DCN-v2 learn cross interactions up to arbitrary order with a stack of cross layers. No manual crossing.
• DLRM: pairwise dot products between all embedding-table outputs implicitly produce second-order crosses.

Second-order cross has |A| × |B| cells; above 10⁶ you need the hashing trick.

LambdaMART, DLRM, MMoE

LambdaMART

A GBDT (LightGBM, XGBoost) trained with pairwise gradients weighted by Δ-NDCG. For years the dominant search ranker (Bing, Yandex). Fast at training time, interpretable feature importances. Weakness: can't ingest raw sequences or embeddings directly.

DLRM

Facebook's open-source click-through ranker. Two-part architecture:

• Bottom MLP over dense features (age, CTR history, prices).
• Embedding tables for sparse features (user_id, ad_id, page_id). Tables are enormous (100s of GB) and embedding-parallel across GPUs.
• All embeddings + dense_bottom are pairwise-dotted, concatenated, fed through top MLP → sigmoid.

MMoE — Multi-gate Mixture-of-Experts

A multi-task architecture used by YouTube & Google Ads to jointly predict multiple outcomes (click, watch time, like, share). Shared experts produce N representations; each task has a gate that weights them. Lets correlated tasks benefit each other while avoiding negative transfer on uncorrelated ones.

Position Bias & Exploration

Position bias: the higher an item appears, the more likely the user is to click it, independent of relevance. A naive click model trained on logged clicks learns "ranked first → high CTR," which collapses to a self-fulfilling feedback loop.

Three remedies

• Position feature at train, zeroed at serve — include the position as an input at training time so the model attributes some CTR to position; at serve, set position = 0 (or a reference value) so the model doesn't use it for ranking.
• Inverse Propensity Scoring — reweight each training sample by 1/P(observed | position).
• Counterfactual / bandit approaches — log probabilities at serve time, use doubly robust estimators.

Exploration

An always-greedy ranker never collects data on items it ranks low. Three exploration strategies:

• ε-greedy — with probability ε=1–5%, serve a random candidate in the top slot. Simple.
• Thompson sampling — score = model prediction + noise from posterior uncertainty. Decays as confidence grows.
• Dedicated exploration slots — reserve 1-of-10 result slots for fresh/cold-start items.

KV Cache & Paged Attention

Decoder-only transformers generate one token at a time. At each step, the model computes attention over all previous tokens. Naively, that means re-running the full attention every step — O(L³) for a sequence of length L.

The KV cache is the standard fix. During the prefill pass you compute the Key and Value tensors for every input token and store them. During decoding, each new token only computes its own Q and attends against the cached K,V. Decoding drops to O(L) per step.

Paged Attention (vLLM, 2023)

Classical KV cache allocates one contiguous buffer per request, sized to max context length. That wastes memory: a request producing 100 tokens reserves space for 4096. Paged Attention splits KV cache into fixed-size blocks (typically 16 tokens) and keeps a per-request page table. Requests grab blocks on demand; fragmentation drops from ~60% to ~4%. This is what let vLLM run 2–4× more concurrent requests than early contiguous-cache servers.

Continuous (In-Flight) Batching

Static batching stalls because sequences finish at different times. If you batch 8 requests and one wants 4000 tokens while seven want 100, the GPU idles for those seven after step 100. Continuous batching (also called in-flight batching) evicts finished sequences from the batch and admits waiting requests every iteration.

Continuous batching typically raises throughput 3–5× vs static batching at identical latency, especially under mixed prompt lengths.

Speculative Decoding

Autoregressive decoding is serial: you must generate token N before N+1. Speculative decoding uses a small cheap draft model to guess K tokens, then runs the big model once to verify all K in parallel. If the draft model agrees with the big model on k tokens, you get k tokens in one big-model forward pass.

• Draft model: a 1B or 7B variant of the big model family.
• Target model: 70B or larger.
• Speedup: 2–3× on average; zero quality loss (the big model rejects any incorrect draft token).

# Speculative decoding outline
def spec_decode(target, draft, prompt, K=4):
    x = prompt
    while not finished(x):
        # Draft produces K tokens cheaply
        draft_tokens = draft.generate(x, K)
        # Target verifies all K in ONE forward pass
        target_logits = target(x + draft_tokens)
        # Accept longest prefix where target agrees with draft
        k = longest_accept(draft_tokens, target_logits)
        x = x + draft_tokens[:k]
        # Always append one extra sample from the target's own distribution
        x = x + sample(target_logits[k])
    return x

Quantization

Weights are stored in fp16 or bf16 during training (16 bits each). At serve time, you can drop precision without much accuracy loss — moving less memory per token is the fastest way to speed up a bandwidth-bound GPU.

Serving Stacks

• vLLM — open-source; paged attention; continuous batching; prefix/prompt caching; tensor-parallel multi-GPU. The default starting point for self-hosting, with the broadest hardware support and largest community.
• SGLang — open-source; RadixAttention for automatic KV-prefix reuse (big wins on RAG and multi-turn chat); structured/constrained decoding; continuous batching. A top-tier engine alongside vLLM and TensorRT-LLM.
• NVIDIA Triton + TensorRT-LLM — maximum throughput on NVIDIA hardware; proprietary kernels; in-flight batching; can edge out vLLM 30–50% under high concurrency, but complex to configure.
• TGI (Hugging Face) — similar features; tighter integration with the HF model hub; Rust router.
• Ray Serve + vLLM/SGLang backend — when you also need complex routing and scaling.

Across all of these, automatic prefix/prompt caching and disaggregated prefill/decode (running the compute-bound prefill and the bandwidth-bound decode on separate GPU pools) are now table-stakes — name them when asked how to push throughput further.

Lake → Registry

• Data lake: S3/GCS Parquet, partitioned by date. Append-only, immutable; the source of truth.
• Processing: Spark, Beam, or Flink jobs; compute features + labels; write tfrecords or parquet for trainer consumption.
• Training: orchestrated by Airflow / Kubeflow / Flyte; runs on GPU cluster; writes to object store.
• Eval: offline metrics on held-out data; slice metrics (new users vs tenured users, each locale, etc.).
• Model registry: MLflow / SageMaker / Vertex. Stores weights + metadata + lineage (data version, code sha).
• Canary: deploy to 1% traffic; automated guardrails on error rate, latency, online metric delta.
• Promotion: if guardrails clean for 24–72h, ramp to 100%. Otherwise rollback.

Hardware

DDP / FSDP / ZeRO

Data-parallel (DDP)

Replicate the whole model on every GPU. Each GPU sees a different batch slice. After backward, AllReduce the gradients. Works until the model fits in one GPU's memory.

FSDP / ZeRO

Shard the model parameters, gradients, and optimizer state across GPUs. During forward, AllGather the needed weights; during backward, ReduceScatter the gradients. Memory drops linearly with world size. ZeRO has three stages:

• ZeRO-1: shard optimizer state only (Adam state is 12 B/param vs weights at 2 B/param fp16).
• ZeRO-2: shard gradients too.
• ZeRO-3 (= FSDP): shard parameters too. Equivalent to fully-sharded data-parallel.

Tensor / Pipeline parallel

Very large models (70B+) don't fit even under FSDP. Tensor parallel splits matmuls across GPUs (Megatron-LM). Pipeline parallel splits layers across GPUs, introducing bubble overhead. Combine with DP as 3D parallelism.

# FSDP in PyTorch — the one-line upgrade from DDP
from torch.distributed.fsdp import FullyShardedDataParallel as FSDP
from torch.distributed.fsdp.wrap import transformer_auto_wrap_policy

model = FSDP(
    model,
    auto_wrap_policy=transformer_auto_wrap_policy,
    mixed_precision=MixedPrecision(
        param_dtype=torch.bfloat16,
        reduce_dtype=torch.float32,     # keep reductions in fp32 for stability
        buffer_dtype=torch.bfloat16,
    ),
)

Mixed Precision & Checkpointing

• Mixed precision (bf16 / fp16): keep a master copy of weights in fp32, cast to bf16 for forward/backward. Throughput doubles; bf16 has the same exponent range as fp32 so it rarely overflows (fp16 needs loss scaling).
• Gradient accumulation: effective batch size = micro_batch × accumulation_steps × world_size. Lets you match a target batch size on small hardware.
• Gradient / activation checkpointing: recompute forward activations during backward instead of storing them. Trades ~30% extra compute for ~50% less activation memory. Mandatory past ~7B params.

Offline Metrics

Online Metrics

• CTR (click-through rate) — short-term signal; easy to game via clickbait.
• Watch time / session length — medium-term engagement; the canonical YouTube metric.
• Retention / DAU / WAU — long-term; slow and noisy; the ultimate product metric.
• Revenue per mille (RPM) — ads; directly ties model quality to dollars.
• Guardrail metrics — latency p99, error rate, complaint rate, blocked-content rate. Must not regress.

A/B Design

A well-formed A/B test has six pieces:

• Unit of randomization — user_id for most ML (session_id for logged-out). Never per-request; within-user spillover contaminates both arms.
• Hypothesis — "new ranker increases watch-time by ≥ 0.5% with p < 0.01, no guardrail regression."
• Primary metric — one pre-registered metric. Adjust for multiple comparisons if you're tracking more.
• Sample size / power — computed from MDE (minimum detectable effect) and baseline variance. Typical FAANG A/B: 7–14 days, millions of users.
• Traffic split — 50/50 if no risk; 95/5 with 1% canary first if guardrails unknown.
• Stopping rule — fixed horizon or sequential (always-valid p-values, mSPRT).

Sample size, back-of-envelope

# For a continuous metric, two-sided test, α=0.05, power=0.80:
# n per arm ≈ 16 × σ² / Δ²
# σ = stdev of metric per user
# Δ = minimum detectable effect (absolute)
#
# For watch time: σ ≈ 30 min, Δ = 0.6 min → n ≈ 16 × 900 / 0.36 = 40,000/arm

CUPED & Interference

CUPED (Controlled-experiment Using Pre-Existing Data)

Variance reduction via pre-experiment covariates. Compute ŷ = y - θ · (x_pre - E[x_pre]) where x_pre is each user's metric value before the experiment. Lowers variance 30–50%, which cuts required sample size 30–50%. Standard at Microsoft, Netflix, Booking.

Interference

Classical A/B assumes units are independent. ML violates this in three ways:

• Two-sided marketplaces (Uber, Airbnb): treating some riders affects driver availability for control. Fix: cluster randomization (by city / day).
• Social spillover (Facebook feed): treated user's post seen by control user. Fix: ego-network randomization.
• Learning loops: both arms write to the same candidate-gen training data → pollution. Fix: separate log streams.