Search Tech Journey

Find topics, journeys and posts

back to blog
mladvanced 120m read

DL S057 · Scaling from 100M to 1B — A Mental Model

Estimate cost + wall-clock for a 1B model. Part of the 'Deep Learning & LLMs From Scratch' 80-session self-study series.

🧠SoftwareM09 · Pretraining your own foundation model· Session 057 of 130 120 min

🎯 Build a back-of-envelope mental model for scaling from 100M to 1B, 7B, 70B, and beyond — so you can price any run in your head.

Series: Deep Learning & LLMs From Scratch — 80 sessions · Session 57 / 80 · Module M09 · ~2 hours

The story we're starting with

Your 100M model cost $3 and 3 hours. You are now, technically, "someone who has pretrained a foundation model." The next question everyone asks is: what does it take to scale?

The honest answer has three axes: compute (mostly a function of N × D, from Chinchilla), memory (which architecture and infrastructure you can use, from the 16-bytes-per-param rule), and throughput (which depends on interconnect and MFU). Each axis scales differently as you go up model sizes, and understanding which becomes the bottleneck at what scale is the difference between "I could reproduce Llama 2" and "I would run out of memory on step 1."

This session builds a spreadsheet-in-your-head for the full range: 100M → 1B → 7B → 70B → 400B. At each scale we ask: what does the config look like? How much compute? How much memory per GPU? How many GPUs? How long? How much money? And what infrastructure do you actually need? By the end you'll close any tab about the "next big model release" and know exactly what it took.

We also close Module 09 — you've now covered the entire "train your own foundation model" pipeline end to end. Module 10 (fine-tuning + alignment) starts turning that base model into an instruction-follower.

Scaling is like moving from a hatchback to a container ship
🌍 Real world
💻 Code world
You will be able to
  • Estimate compute (in A100-days) for any N-param model at Chinchilla-optimal D.
  • Estimate the memory footprint per GPU for training a given N with FSDP on k GPUs.
  • Explain why 7B is the 'personal-project ceiling' and 70B is the 'team ceiling'.
  • Estimate wall-clock for a 7B run on 8×A100 to within 30%.
  • Rank the seven infrastructure knobs (compute, memory, comms, storage, monitoring, resume, debugging) by which becomes the binding constraint at each scale.

Prerequisites

  • S047 (Chinchilla) — the compute formula.
  • S051 (DDP/FSDP) — the memory + comms formulas.
  • S052 (renting GPU) — the dollar prices.
  • S053, S054, S055, S056 — you've now trained, evaluated, checkpointed, and debugged a real model.


1 · The scaling table — the whole picture on one page

Scale100M1B7B70B400B
Chinchilla D (tokens)2 B20 B140 B1.4 T8 T
Compute C (FLOPs)1.2 × 10¹⁸1.2 × 10²⁰6 × 10²¹6 × 10²³2 × 10²⁵
Steady-state mem (16 B/p)1.6 GB16 GB112 GB1.1 TB6.4 TB
Fits on…1× 40901× A100 403× A100 8016× A100 80~80× H100
Wall clock @ MFU 40%3 h (1 A100)4 d (1 A100)15 d (8 A100)30 d (128 A100)~90 d (2048 H100)
Cost @ spot pricing$3$150$1,500$150k$10M+
Team size11–22–55–2050+

Read down the table. Every column changes by roughly 10× as N grows 10×, and each pair of columns changes at different rates — so the binding constraint shifts:

  • 100M → 1B: compute becomes the pain. Wall clock jumps 30×.
  • 1B → 7B: memory becomes the pain. Doesn't fit on one GPU.
  • 7B → 70B: interconnect becomes the pain. Need multi-node with InfiniBand.
  • 70B → 400B: operations become the pain. Node failures, cost management, human coordination.

2 · The N → wall clock formula, from scratch

Chinchilla: D = 20N and C = 6ND = 120 N².

At MFU=40%, an A100 sustains 312e12 × 0.4 = 1.25e14 FLOPs/s.

Wall clock on 1 A100:

seconds = 120 N² / 1.25e14
        = 9.6e-13 × N² seconds

Or in A100-days:

A100-days = 9.6e-13 × N² / 86400 = 1.1e-17 × N² days

Plug in:

NA100-daysOn 1 GPUOn 8 GPUs (DDP+scaling loss)
100M0.113 h~25 min
300M1.024 h~3.5 h
1B1111 d~1.7 d
3B100~3 mo12 d
7B540~1.5 y2.5 mo
70B54000infeasible~17 y (need 128+)

Beyond ~3B, single-GPU training is impractical. Beyond ~30B, single-node (8-GPU) training is impractical.

Cost formula: $ ≈ A100-days × 24 × $1.10 (spot) ≈ 30 × A100-days.

So a 1B model costs 11 × 30 = $330 on spot. A 7B costs 540 × 30 ≈ $16000. That matches published estimates for training a Llama 2-class 7B from scratch on rented hardware (~$10k-20k depending on efficiency).


3 · Memory scaling — what fits where

Recall from S051: 16 bytes/param for bf16 Adam training steady state.

Add activations on top. Rough activation formula per layer (with checkpointing): ~2 × batch × seq × d_model bytes. Sum over layers, multiply by ~2 for backward.

Concrete numbers with batch=8, seq=2048:

ModelParams (16B/p)Activations (roughly)Total per-GPU (single)
100M1.6 GB1 GB2.6 GB
1B16 GB4 GB20 GB
7B112 GB10 GB122 GB
70B1120 GB30 GB1150 GB

7B doesn't fit on any single GPU. Even H100 80GB is ~120 GB short. You must shard.

Under FSDP on 8 GPUs:

  • 7B: 122/8 ≈ 15 GB per GPU. Fits nicely on A100 40GB.
  • 70B: 1150/8 ≈ 143 GB per GPU. Still doesn't fit on H100 80. Need 16+ GPUs, or add activation checkpointing (cut activations 4×).
  • 400B: needs 32+ H100 80s with FSDP + activation checkpointing.

Recall FSDP comms: ~6N bytes per step (all-gathers + reduce-scatters).

Step compute time: C_per_step / TFLOP/s = 6ND_micro_batch / (MFU × 312e12).

For a 7B model, 8× A100, batch=8, seq=4096:

  • Step compute: 6 × 7e9 × 8 × 4096 / (0.4 × 312e12) ≈ 11 s
  • Comms: 6 × 7e9 × 2 / 600e9 (NVLink3) ≈ 0.14 s
  • Overlap ratio: 1.3% — comms is basically free.

For 70B on 8× A100 (assuming it fit):

  • Step compute: 6 × 70e9 × 8 × 4096 / (0.4 × 312e12) ≈ 110 s
  • Comms: 6 × 70e9 × 2 / 600e9 ≈ 1.4 s
  • Overlap ratio: 1.3% — still fine.

But inter-node (across nodes) doesn't have NVLink. It has InfiniBand at 25-50 GB/s (200-400 Gbps). At 70B on 16× GPUs across 2 nodes:

  • Inter-node comms: 6 × 70e9 × 2 / 25e9 = 33.6 s per step
  • Step compute (halved by 2× GPUs): 55 s
  • Comms is now 60% of compute — that's a real slowdown.

Fix: hybrid parallelism. Use tensor parallelism within a node (fast NVLink), FSDP across nodes (fewer comms). Megatron-LM's key insight; every serious multi-node run uses it.

For a 400B run on 8 nodes × 8 GPUs, you need TP + PP + FSDP simultaneously — three axes of parallelism. This is where hobby-scale ends and industry-scale begins.


5 · The seven infrastructure knobs, ranked by scale

Which constraint bites at which scale

    Read this every time you're planning a new run. It tells you what to expect to spend engineering time on.

    Try itPrice a Llama-2-7B-from-scratch run in your head, before opening any calculator

    Work it out top-down using only the formulas from §2. (1) Chinchilla D for 7B = 20 × 7e9 = 140B tokens. (2) Compute C = 6ND = 6 × 7e9 × 140e9 ≈ 5.9e21 FLOPs. (3) On 1 A100 at 40% MFU: 5.9e21 / (1.25e14) ≈ 4.7e7 s ≈ 545 A100-days. (4) At 1.10/hrspot:545×24×1.10/hr spot: 545 × 24 × 1.10 ≈ 14,400.Nowcheckthetableabove:540A100daysand 14,400. Now check the table above: `540 A100-days` and `~16k`. Close enough. Now redo it for a 3B model at Chinchilla-optimal, then a 7B model undertrained to 40B tokens (Llama 1). Both should be doable in under a minute with no calculator.

    💡 Hint · You should land within 30% of published numbers ($10–20k).

    6 · Real numbers from Llama 3 8B

    From the Llama 3 paper (§3):

    • Params: 8B
    • Tokens: 15T (over-trained ~10× past Chinchilla)
    • Compute: ~7.4 × 10²³ FLOPs (12× more than Chinchilla-optimal for 8B)
    • Wall clock: ~1.3M H100-hours on a 16000-H100 cluster
    • Wall clock in days: ~3.4 days
    • **Cost (if rented at 2.50/hrH100spot): 2.50/hr H100 spot):** ~3.25M
    • Cost (Meta internal): perhaps $500k in electricity + amortized hardware

    That's your "what does frontier open-source look like" reference. 100× our 7B baseline in compute (from over-training + more careful data) and 3.4 days on 16000 H100s.


    7 · A realistic 6-month "personal frontier" ladder

    If you wanted to spend a year seriously moving up from 100M, here's a sane ramp:

    MonthTargetCostSkills unlocked
    1100M base (S053 recap)$10Full training loop, eval
    2300M base + SFT (S058)$50Instruction tuning, first useful model
    31B base + LoRA fine-tunes$200Real distributed training, dataset engineering
    43B base$1500Multi-GPU comfort, longer runs
    57B fine-tunes (of Llama base)$500Efficient fine-tuning, deployment
    67B from scratch (personal-project ceiling)$15,000Multi-node, real ops

    Total budget: ~$17k over 6 months. Compare to a Master's degree in ML. Similar cost, ridiculously more capability.

    Almost nobody does this — most stop at 1B or move to fine-tuning bigger open models — but the ladder is real. The gate isn't skill; it's dollars and time.


    8 · Where the mental model breaks

    Things this scaling model doesn't capture:

    • Data quality wins. A well-curated 1T tokens might beat a poorly-curated 5T. This session assumes fixed quality.
    • Architecture innovations. MoE, MLA, and various attention variants can shift the effective compute curve. Sometimes 30% improvements.
    • Fine-tuning is much cheaper than pretraining. A 7B LoRA fine-tune is 10,not10, not 10k. Most practical LLM work happens here, not at pretraining.
    • Distillation. A 100M student trained on outputs of a 7B teacher can beat a 100M peer trained from scratch by 5-10 points. We cover it in S068.
    • Emergent scaling. Some capabilities don't appear until N ≥ some threshold. You can't buy them incrementally at smaller scales.

    9 · Closing Module 09

    You have now covered:

    • S046-S049: how to build a pretraining corpus.
    • S050: how to design a modern LLM architecture.
    • S051-S052: how to make it run on real hardware.
    • S053-S055: how to train, eval, and checkpoint it.
    • S056-S057: how to debug it and scale it.

    You could — literally — kick off a personal 1B pretraining run tomorrow. You know what it costs, what to watch for, what will break, and how to recover.

    That was the "make your own foundation model" module. The rest of the series (M10 onward) turns your model, or someone else's open weights, into something that does things: follows instructions, gets aligned to preferences, runs efficiently at inference, and eventually powers a real product.


    10 · War stories

    War story The 7B I couldn't finish

    I priced a personal 7B run at 10k.Startediton8A100spotinstances.Nodereclaimed4daysincheckpointingsavedmostoftheloss,resumedonafresh8GPUcluster.Repeated3moretimes.Byday15Idspent10k. Started it on 8 A100 spot instances. Node reclaimed 4 days in — checkpointing saved most of the loss, resumed on a fresh 8-GPU cluster. Repeated 3 more times. By day 15 I'd spent 8k, was 60% through training, and lost the appetite. Final cost: $8k for a partial-run checkpoint that never made it to production.

    Lesson: scale up gradually. Don't jump from 300M to 7B — do 1B first, learn the operational muscle memory, then 3B, then 7B. The engineering skill required at each step is not linear in compute.

    War story The MFU that wasn't 40%

    Estimated a 3B run at 4 A100-days assuming MFU=40%. Real MFU turned out to be 22% (a python-side dataloader bottleneck I hadn't spotted). Wall clock: 7.5 days. Cost: 2× my budget.

    Lesson: measure MFU on your specific stack before you extrapolate. Don't trust industry numbers as a floor. tok/sec × 6 × N / (312e12 × world_size) is your real MFU; run it at step 500 and reprice from there.

    War story DeepSeek-V3 receipts — what $5.6M actually buys in 2024

    The DeepSeek-V3 tech report (arxiv 2412.19437, §5) is the most detailed public accounting of a modern frontier pretrain. Reading §5 changes your mental model of what 'expensive' means. Numbers:

    • 671B total params (37B active), MoE with 256 routed + 1 shared expert.
    • 14.8T high-quality tokens, mostly English + code, then multilingual tail.
    • 2,048 H800 GPUs (H100 export-restricted variant; ~15% less compute per GPU, comparable bandwidth).
    • Total training: 2.788M H800-GPU-hours (~2 months wall-clock on the full cluster).
    • **Reported cost: 5.576Mattheirassumed5.576M** at their assumed 2/H800-hr rental rate.
    • MFU claimed: ~40% with FP8 mixed precision and DualPipe pipeline parallelism.
    • Parallelism: 16-way pipeline × 64-way expert × ZeRO-1 data.

    Compare Llama-3-405B: Meta reports ~30.8M H100-hours, using ~24k H100s. At market H100 spot of 1.80/hrthats 1.80/hr that's ~55M compute-only. DeepSeek-V3 achieved comparable quality for ~1/10 the cost primarily through: (a) MoE (5× param efficiency), (b) FP8 (~1.5–2× throughput), (c) MLA (much smaller KV cache = larger batches), (d) fine-grained auxiliary-loss-free MoE.

    Lesson for the mental model: the 'cost per token' of frontier training is dropping ~10× every 18 months right now. Anchor your extrapolations to the most recent public receipt, not the 'well, Llama-2 cost X so...' from 2023.


    12 · The 2025 scaling landscape — what the frontier learned this year

    Six things changed the scaling calculus in 2024–2025. If your mental model is stuck at Chinchilla-2022, update.

    12.1 · Overtraining beats Chinchilla for inference-heavy models

    Muennighoff et al. (2023, arxiv 2305.16264, 'Scaling Data-Constrained LMs') and follow-ups showed: Chinchilla-optimal minimizes training compute for a target loss, but not total (train + inference) compute over a model's lifetime. If you're going to serve N tokens of inference per parameter, the optimal training tokens-per-parameter grows from Chinchilla's ~20 toward 100–300 for popular inference-heavy models. Llama-3-8B was trained on 15T tokens (~1875 tokens/param, ~90× Chinchilla). Phi-3 mini went ~1000 tokens/param. Under-training is the new over-training.

    For your 100M model: at 2B tokens (20 tokens/param), you're Chinchilla-optimal for training cost. Push to 10–20B tokens if you plan to use the model.

    12.2 · MoE changed the param-to-compute-to-quality frontier

    The old rule 'quality scales with N and D' silently assumed dense. For MoE:

    • Active params (Nactive) determine per-token compute (≈ 6 · Nactive · D).
    • Total params (Ntotal) determine model 'capacity' and disk footprint.
    • Quality lies somewhere between the two, closer to sqrt(Nactive · Ntotal) per Fedus et al. Switch Transformer scaling laws and DeepSeek's own scaling analysis.

    Rule of thumb 2025: a well-tuned MoE with 4–10× total:active ratio matches a dense model with active_params · 1.5–2 params at the same training compute. Mixtral 8×7B (12.9B active, 46.7B total) matches Llama-2-34B. DeepSeek-V3 (37B active, 671B total) matches Llama-3-405B dense-equivalent quality.

    12.3 · FP8 and BF16 are your leverage

    H100 bf16 = 989 TFLOPS. H100 fp8 = 1979 TFLOPS. If your training loop is compute-bound and your framework supports Transformer Engine, fp8 doubles your throughput (in practice ~1.5–1.8× after all-reduce overhead). This alone is why 2024–2025 pretrains got so much cheaper. Every serious training framework now supports fp8 (torchao, TransformerEngine, MosaicML Composer). Use it on H100+.

    12.4 · Interconnect is the new ceiling

    At 8B, one 8×H100 node with NVLink is enough. At 70B dense, you need 2D parallelism (TP inside node, FSDP across). At 405B, you need 3D (TP + PP + FSDP) plus InfiniBand NDR (or better, XDR). At MoE 600B+, you need expert-parallel with careful all-to-all optimization. Each order of magnitude in params adds a new dimension of parallelism.

    See §4; add: 2025 Blackwell (B200) doubles NVLink5 to ~1.8 TB/s per GPU, pushing the single-node ceiling from ~70B to ~150B dense. If you rent 8×B200 (available on CoreWeave/Nebius mid-2025), you can train a Llama-3-70B-class model on a single node without TP. That's a big deal.

    12.5 · The 'personal frontier' has moved up

    What a solo dev/small team could pretrain in 2022 vs 2025:

    YearSolo budget ($1k)Small team budget ($100k)
    2022100M dense on V1001B dense on 8×A100 for a month
    2023350M dense on A100 spot3B dense on 8×A100 for a month
    20241B dense on A100 spot7B dense on 8×H100 for 2 weeks, or 20B MoE
    20251B–2B dense on H100 spot13B dense on 8×H100 for a month, or 40B MoE

    Roughly a 5–10× improvement in 'what you can afford' every 18 months, driven by hardware (H100 → B200), formats (bf16 → fp8), and architecture (dense → MoE). Your 100M/2B run in 2025 is what a 10M/200M run was in 2020.

    12.6 · Where scaling laws stop predicting — the frontier's dirty secret

    Hoffmann's Chinchilla laws were fit on <100B-param dense models. Extrapolating to 1T dense or 10T MoE, the laws stop being predictive. Frontier labs have their own internal scaling laws refit yearly on their own architectures + data recipes; those laws are proprietary. What's public:

    • DeepMind's revised Chinchilla (Porian et al. 2024, arxiv 2406.19146) reanalyzed the original data and found the exponents differ from Hoffmann's estimates. The 'optimal tokens/param = 20' is closer to 18–25 depending on how you fit.
    • Sardana & Frankle (2024, arxiv 2401.00448) 'Beyond Chinchilla-Optimal': derives the inference-adjusted optimum. Shows for models with >100M inference tokens per param served, optimal training tokens is 100–300× params, not 20×.
    • Kaplan-style vs Chinchilla-style laws: still an active fight. See Muennighoff for the definitive 2024 synthesis.

    Practical takeaway: for your 100M–1B "personal frontier", the classical formulas are close enough. Don't extrapolate them to 100B+.

    Further reading (12.x)


    Common misconception
    ✗ What most people think

    "Scaling laws tell me how good a model will be. Plug in parameters and tokens, read off the capability."

    ✓ What is actually true

    Scaling laws predict loss, and loss is a smooth aggregate over the next-token distribution. Downstream capability is not smooth in loss — many evaluated abilities sit near chance for a long stretch and then move, because the metric is a thresholded, discrete score rather than a continuous one. So the laws are genuinely predictive of the thing they model and genuinely unreliable as a capability forecast, and the gap is a property of the metric, not a failure of the law.

    Why the myth is so sticky

    Because loss and capability really are tightly coupled in the regime where you validate the intuition. Compare a 100M model and a 1B model on anything and both loss and benchmark scores move together, so "lower loss ⇒ better model" is confirmed. The coupling is monotone but not linear, and the non-linearity lives at the point where a capability crosses from unusable to usable — exactly the point you care about predicting, and the only point where the smooth extrapolation gives no guidance.

    Prove it to yourself

    Put both curves on the same axis for your own checkpoints and look at their shapes:

    # for each saved checkpoint, record val loss AND a downstream score
    for step, ckpt in checkpoints:
        L = eval_loss(ckpt)
        acc = benchmark_accuracy(ckpt)      # multiple-choice, chance = 0.25
        print(f"{step:>7}  loss={L:.3f}  acc={acc:.3f}")
    
    # loss should fall smoothly and near-log-linearly in compute.
    # acc will sit at chance and then move. Same model, same axis,
    # two completely different curve shapes.
    From first principles
    Start with the question

    Why does communication become the binding constraint as models grow, when compute grows too? Both scale with model size — so why does one overtake the other?

    1. 1
      Training compute per step scales as roughly 6 × params × tokens_per_step, so at fixed batch size it is linear in parameter count N.
      forced by · every parameter participates in a fixed number of multiply-accumulates per token
    2. 2
      Under data parallelism the communication per step is a gradient all-reduce whose volume is also linear in N — one gradient value per parameter, regardless of batch size.
      forced by · gradients are accumulated over the batch before the reduction, so batch size does not change the message size
    3. 3
      So the compute-to-communication ratio per step is proportional to tokens_per_step — it improves with larger batches and is independent of model size.
      forced by · the N in the numerator and the N in the denominator cancel
    4. 4
      But once a model no longer fits on one device you must shard it, and sharded execution adds collectives inside the forward and backward pass — parameter all-gathers per layer, or activation exchanges across a tensor-parallel group — which the single per-step all-reduce did not have.
      forced by · you cannot compute a layer whose weights or activations live on another device without moving them first
    5. 5
      Those intra-step collectives scale with layer count and hidden dimension, and crucially they sit on the critical path between dependent computations, so they overlap far less well than a gradient all-reduce that can start as soon as each bucket is ready.
      forced by · layer k+1 cannot begin until layer k's exchange completes — the dependency is sequential by construction
    ⇒ Therefore

    Therefore the crossover is not caused by model size per se but by the point at which the model stops fitting on one device and you are forced into sharded parallelism. That is why interconnect bandwidth becomes a headline specification exactly at the scale where single-device training ends.

    And note the prediction: because the compute-to-comms ratio improves with tokens per step, raising the per-device batch size or the sequence length should push a communication-bound run back toward compute-bound. Verify it — measure model-FLOPs-utilisation at several per-device batch sizes on a fixed model and world size. MFU should climb with batch size and then flatten once you are compute-bound again, and the batch size at which it flattens is the smallest one you should ever run on that hardware.

    Mental modelFour budgets, one run

    Any training run at any scale is constrained by exactly four budgets, and only one of them binds at a time: compute (total FLOPs, which sets wall clock), memory (what fits on a device, which sets whether it runs at all), bandwidth (interconnect, which sets how much of your compute you actually get), and data (tokens available, which sets how far you can train before repeating).

    Scaling from 100M to 1B to 70B is the story of which budget binds. At 100M nothing binds — it fits and it finishes. At 1B memory starts to bind. At 70B bandwidth binds. At frontier scale data begins to bind. Every technique in this module exists to relieve one specific budget, and applying a technique to a budget that is not binding buys nothing.

    • Wall clock ≈ 6ND / (peak FLOP/s × MFU). Memorise this; it prices any run in ten seconds and is the only formula you need for planning.
    • Memory splits into state (params + grads + optimizer, relieved by sharding) and activations (relieved by checkpointing or sequence parallelism). Different budgets, different fixes.
    • MFU is the honest efficiency number. Comparing runs by tokens/sec across different hardware is meaningless; comparing by MFU is not.
    • Inference cost is paid per request for the model's whole life. That is why production models are trained far past the compute-optimal token count for their size.
    🔔 Fires when you see

    Fire this model the moment you see: someone quoting a training cost without a token count · a proposal to add GPUs to fix an OOM · a plan to scale up a model that has not been profiled · an MFU number below roughly a third of peak · any claim that a capability will "emerge" at some parameter count.

    The tradeoff

    You have a compute budget and you want the best model you can serve. Train compute-optimally, overtrain a smaller model, or use a sparse (mixture-of-experts) architecture?

    Train at the compute-optimal point
    + you gain the lowest loss achievable for your training budget, which is exactly what the scaling laws optimise for; the cleanest comparison against published results at the same compute
    − you pay optimises the wrong objective if you intend to serve the model — the compute-optimal point ignores inference entirely, and gives you a larger model than you would have chosen knowing you must run it millions of times
    pick when the model is a research artifact, or the number of inference calls it will serve is small relative to the training cost
    Overtrain a smaller model
    + you gain a permanently cheaper artifact to serve: less memory, a smaller KV cache, higher throughput per device, and often the ability to run on hardware a compute-optimal model could not fit on
    − you pay strictly worse loss than the compute-optimal model on the same training budget, and you need enough distinct tokens to keep feeding it — past a point you are re-reading the corpus with diminishing returns
    pick when projected lifetime inference cost exceeds training cost, which you can estimate directly from expected requests per day times model size — for anything user-facing this is nearly always true
    Sparse / mixture-of-experts
    + you gain decouples parameter count from per-token compute: you get the capacity of a large model at the activated-FLOPs cost of a much smaller one, which is a genuinely different point on the frontier
    − you pay total memory is still governed by all parameters, so serving needs the whole model resident; routing adds load-balancing failure modes and makes throughput dependent on token distribution; and the training and inference stacks are meaningfully more complex
    pick when you are memory-rich but compute-poor at inference — many devices with aggregate capacity to hold the full parameter set, and a latency target that a dense model of equivalent quality would miss
    What a senior engineer actually does

    Price the whole lifetime, not the training run. The single most useful calculation in this session is comparing projected inference cost against training cost, because it decides the size question — and the size question decides everything else, since memory, bandwidth, and serving hardware all follow from it.

    The estimation discipline worth building: before any run, write down predicted wall clock from 6ND and an assumed MFU, then compare against actual. Being consistently wrong in the same direction tells you something real about your stack — usually that MFU is lower than you assumed, which is a fixable systems problem rather than a scaling one.


    13 · 🧠 Retention scaffold

    Quick recall · click to reveal
    ★ = stretch question

    One-line summary (write it in your own words): _______________________________

    Spaced review: re-read §1 (the scaling table) and §12 (2025 landscape) in 24 hours. Revisit the full session on day 7. This session and §1 combined ARE your working mental model of pretraining scale.

    Next session (S058, Module M10): Supervised Fine-Tuning — how to turn your base model (gibberish completer) into something that follows instructions.

    Sticky note (keep on your desk): "FLOPs = 6ND. Chinchilla D=20N (or 100–300N if inference-heavy). MoE quality ≈ sqrt(Nactive · Ntotal). +1 dimension of parallelism per 10× in N."

    Legacy recall drills (kept for spaced-review continuity)

    1. Chinchilla-optimal tokens for a 1B model?

    D = 20 × N = 20 × 1e9 = 20 billion tokens.

    2. Wall clock for training a 1B model on 1 A100 at MFU 40%?

    ~11 A100-days. About $330 at spot.

    3. At what N does a model stop fitting on a single A100 40GB (bf16 Adam)?

    Around 2-3B params. Steady-state (16 B/param) plus activations exceeds 40 GB.

    4. Why does 70B pretraining require multi-node?

    70B needs ~1150 GB of memory (16 B/param). Even 8× H100 80GB (640 GB total) can't hold it — you need at least 16 GPUs across ≥ 2 nodes.

    5. What's the "personal-project ceiling" for LLM pretraining, and why?

    Roughly 7B. Below that: single-node, tractable time and money for one person. Above that: multi-node infra, dedicated engineering time, six-figure budgets — becomes a team activity.

    Stretch

    Build a scaling calculator. Function plan(N, tokens_per_param=20, gpus=1, gpu="A100_40", mfu=0.4) returns \{compute, wall_clock, per_gpu_mem, cost\}. Test on the 5 sizes in §1's table and confirm the numbers match. Extend to handle gpu="H100" and mfu=0.5 for a realistic H100 sanity check. Post the code as a gist.

    In your own words

    "The four scale-dependent bottlenecks are ______, ______, ______, ______ — and each becomes binding at roughly the ______, ______, ______, ______ scale."

    Spaced-review pointer

    • S047 (Chinchilla) — you're applying it at every row of the table.
    • S051 (DDP/FSDP) — memory formulas.
    • S053 (real training) — the 100M baseline is your only data point that isn't extrapolation.

    Next-session teaser

    Module 10 opens with Supervised Fine-Tuning (SFT) — how to take your (or Llama's) base model and teach it to follow instructions. Suddenly your gibberish-completer becomes something you can chat with. Session 058 turns "language model" into "assistant."

    Bring back tomorrow

    • Table: the 5-row scaling table (100M/1B/7B/70B/400B) — memorize the compute + memory + cost row.
    • Rule: 24 GB VRAM = ~1.5B params ceiling for single-GPU training.
    • Question: at your target scale, which of the seven infrastructure knobs is the binding constraint?

    Previous: ← DL S056 · Next: DL S058 →