You need to train a dense decoder-only transformer on 300 billion tokens. It has 80 layers, width 8,192, gated feed-forward width 28,672, 64 query heads, 8 key/value heads, head size 128, and a tied vocabulary of 128,000 tokens. You have 512 GPUs in 64 eight-GPU nodes. Each GPU has 80 GB of memory, about 1 PFLOP/s peak BF16 compute, a fast switched link inside its node, and 45 GB/s effective per-rank transfer bandwidth for large cross-node collectives under load. Plan the run.
This question tests whether a candidate can turn dimensions into a measured systems plan. There is no single correct parallel layout. Assumptions and checks matter more than naming a framework.
Try it before reading the answer
Estimate:
- total parameters;
- model-state memory;
- total training FLOPs;
- wall time at 50% model FLOPs utilization;
- accelerator-hours;
- a first parallel layout;
- global batch construction for about four million tokens per optimizer step;
- the first experiments and failure checks.
Assume BF16 weights and gradients, FP32 Adam moments, and no separate FP32 master weights.
Count the parameters
For each layer, gated feed-forward parameters are:
Attention parameters with grouped-query attention are:
Across 80 layers:
The tied token embedding adds:
Norms and small terms bring the estimate close to 70 billion parameters.
Count the model state
Per parameter:
- BF16 weight: 2 bytes;
- BF16 gradient: 2 bytes;
- two FP32 Adam moments: 8 bytes.
Total model state is about:
This excludes activations, temporary kernel buffers, communication buffers, and allocator margin.
Count the compute
Start with the parameter-matrix estimate:
This estimate should be refined for long-context attention and the final architecture. It is sufficient for an early capacity plan.
At sequence length 8,192, the attention score and weighted-value operations are large enough to include. Their forward and backward cost is approximately:
The refined total is about FLOPs, before smaller operations.
The cluster peak is:
At 50% MFU, useful model throughput is FLOP/s. Using the refined compute estimate, the run time is:
The run uses about:
accelerator-hours, before failed runs, evaluation, checkpoints, and recovery time.
Choose a first layout
Start with eight-way tensor parallelism inside each node. This keeps frequent per-layer activation communication on the fast local links.
That leaves 64 data-parallel groups across nodes.
Before selecting full parameter sharding, check whether a lighter option fits. With eight-way tensor parallelism:
- weights per GPU: GB;
- gradients per GPU: another 17.5 GB;
- Adam moments sharded over the 64 data-parallel ranks: GB.
This ZeRO-1 style estimate uses about 36.1 GB per GPU for model state. It leaves about 44 GB for activations, temporary buffers, communication, and safety margin.
This may fit with activation checkpointing. If measured peak memory is safe, it avoids the parameter all-gathers required by full parameter sharding.
If activations still do not fit:
- reduce the local micro-batch;
- checkpoint activations;
- use sequence or context parallelism for long sequences;
- then consider parameter sharding or pipeline parallelism if the earlier steps are not enough.
Do not start with every parallelism dimension.
Build the global batch
At sequence length 8,192, use one sequence per data-parallel replica per micro-batch and accumulate eight micro-batches.
The 300-billion-token run needs about:
optimizer steps.
Tensor-parallel ranks work on the same sequences, so they do not multiply the global batch.
The target batch must also make sense for optimization. If it changes from the validated training recipe, retune learning rate, warmup, and possibly the token schedule.
Check communication
Each tensor-parallel rank owns about 17.5 GB of gradients. Gradient synchronization may use an all-reduce or an equivalent reduce-scatter plus parameter all-gather for optimizer-state sharding. The ring traffic has this large-message lower bound:
The real value depends on bucketing, topology, contention, and overlap with backpropagation.
Trace the last gradient buckets. A long reduction tail after backward compute ends is exposed communication and directly increases step time.
Validate the plan in stages
Stage 1: one-node correctness
- confirm loss and gradient behavior;
- verify parameter count and FLOP estimate;
- record peak memory by component;
- measure kernel shapes and numerical stability.
Stage 2: multi-node scaling
Test a small grid, such as 8, 64, 128, and 512 GPUs when practical. Keep the global batch or report any change.
Record:
- tokens per second;
- MFU;
- median and tail step time;
- exposed collective time;
- per-rank imbalance;
- peak memory.
Stage 3: reliability
- checkpoint model, optimizer, data position, and random state;
- test restart before the full run;
- validate checkpoint write time and storage load;
- define health checks for loss spikes, NaNs, stalled ranks, and slow nodes;
- keep a known-good checkpoint for rollback.
Stage 4: convergence
Run enough tokens to test the learning curve, not only systems throughput. Compare with smaller-scale predictions and monitor held-out loss by data source.
What an L4 answer sounds like
“Use 512 GPUs, mixed precision, tensor parallelism, FSDP, activation checkpointing, and a distributed training framework.”
This names tools without calculating fit, time, batch, or communication.
What an L5 answer adds
An L5 candidate estimates 70 billion parameters, about 840 GB of unsharded model state, and the parameter-matrix FLOP baseline. A stronger estimate adds about FLOPs for long-context attention, giving about 6.6 days at 50% MFU. They place tensor parallelism inside each node and build the global batch correctly.
What an L6 answer adds
An L6 candidate starts with the least expensive layout that fits. They notice that tensor parallelism plus optimizer-state sharding may fit without full parameter sharding. They reserve memory margin, estimate exposed gradient communication, preserve optimization behavior, and define a staged scaling, restart, and convergence plan.
They also report uncertainty. The 50% MFU and communication estimates are planning assumptions that traces must replace.
Strong-hire signals
- Arithmetic comes before framework choice.
- Tensor-parallel ranks are not counted as extra data replicas.
- Model state and activations are budgeted separately.
- The topology determines group placement.
- Wall time and accelerator-hours are both reported.
- The candidate tests a simpler sharding stage before full parameter sharding.
- Communication overlap is measured, not assumed.
- Restart and convergence tests happen before the full run.
Common follow-up
“Why not use full parameter sharding immediately?”
Full parameter sharding saves more memory. It also adds parameter all-gathers during forward and backward work. If a lighter sharding stage already leaves enough activation and buffer memory, the extra communication may not help. Measure both if the answer is close.
Related: Transformer compute and memory accounting, strong scaling and parallelism selection, accelerator network topology, and train a 100B parameter model.