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.
🎯 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.
- 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
| Scale | 100M | 1B | 7B | 70B | 400B |
|---|---|---|---|---|---|
| Chinchilla D (tokens) | 2 B | 20 B | 140 B | 1.4 T | 8 T |
| Compute C (FLOPs) | 1.2 × 10¹⁸ | 1.2 × 10²⁰ | 6 × 10²¹ | 6 × 10²³ | 2 × 10²⁵ |
| Steady-state mem (16 B/p) | 1.6 GB | 16 GB | 112 GB | 1.1 TB | 6.4 TB |
| Fits on… | 1× 4090 | 1× A100 40 | 3× A100 80 | 16× 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 size | 1 | 1–2 | 2–5 | 5–20 | 50+ |
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² secondsOr in A100-days:
A100-days = 9.6e-13 × N² / 86400 = 1.1e-17 × N² daysPlug in:
| N | A100-days | On 1 GPU | On 8 GPUs (DDP+scaling loss) |
|---|---|---|---|
| 100M | 0.11 | 3 h | ~25 min |
| 300M | 1.0 | 24 h | ~3.5 h |
| 1B | 11 | 11 d | ~1.7 d |
| 3B | 100 | ~3 mo | 12 d |
| 7B | 540 | ~1.5 y | 2.5 mo |
| 70B | 54000 | infeasible | ~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:
| Model | Params (16B/p) | Activations (roughly) | Total per-GPU (single) |
|---|---|---|---|
| 100M | 1.6 GB | 1 GB | 2.6 GB |
| 1B | 16 GB | 4 GB | 20 GB |
| 7B | 112 GB | 10 GB | 122 GB |
| 70B | 1120 GB | 30 GB | 1150 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.
4 · Comms scaling — why NVLink stops being enough at 70B
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 sper 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
Read this every time you're planning a new run. It tells you what to expect to spend engineering time on.
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 ≈ 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.
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 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:
| Month | Target | Cost | Skills unlocked |
|---|---|---|---|
| 1 | 100M base (S053 recap) | $10 | Full training loop, eval |
| 2 | 300M base + SFT (S058) | $50 | Instruction tuning, first useful model |
| 3 | 1B base + LoRA fine-tunes | $200 | Real distributed training, dataset engineering |
| 4 | 3B base | $1500 | Multi-GPU comfort, longer runs |
| 5 | 7B fine-tunes (of Llama base) | $500 | Efficient fine-tuning, deployment |
| 6 | 7B from scratch (personal-project ceiling) | $15,000 | Multi-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 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
I priced a personal 7B run at 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.
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.
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: 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 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:
| Year | Solo budget ($1k) | Small team budget ($100k) |
|---|---|---|
| 2022 | 100M dense on V100 | 1B dense on 8×A100 for a month |
| 2023 | 350M dense on A100 spot | 3B dense on 8×A100 for a month |
| 2024 | 1B dense on A100 spot | 7B dense on 8×H100 for 2 weeks, or 20B MoE |
| 2025 | 1B–2B dense on H100 spot | 13B 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)
- DeepSeek-V3 Tech Report — arxiv:2412.19437
- Llama-3 herd of models paper — arxiv:2407.21783
- Muennighoff data-constrained scaling — arxiv:2305.16264
- Sardana & Frankle inference-adjusted scaling — arxiv:2401.00448
- Porian et al. Chinchilla replication — arxiv:2406.19146
- Switch Transformer scaling (Fedus) — arxiv:2101.03961
- DualPipe (DeepSeek-V3 pipeline parallel) — tech report §2.3
- Transformer Engine (fp8) — github.com/NVIDIA/TransformerEngine
"Scaling laws tell me how good a model will be. Plug in parameters and tokens, read off the capability."
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.
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.
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.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?
- 1Training 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
- 2Under 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
- 3So 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
- 4But 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
- 5Those 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 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.
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.
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.
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?
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
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?