TL;DR: Time = FLOPs ÷ (GPUs × peak × MFU) = 6.35e24 ÷ (16,384 × 989e12 × 0.4) ≈ 9.8e5 s ≈ 11.3 days. At 30% MFU it is 15 days, at 50% it is 9; state the MFU with the answer, because it is the only input that is a guess.
How to approach it
Take the FLOPs figure from the previous step, or recompute it in one line, and ask whether the peak to use is dense bf16 (989 TFLOPS on the H100) or the sparsity-inflated marketing figure, and say you are using dense. Compute the fleet's effective FLOPs per second first, since it is the divisor everything else follows from, and write the units. Then divide, convert seconds to days, and give the range across the plausible MFU band before the interviewer asks.
A strong answer
A typical situation: a schedule is committed with a single number of days and no MFU stated, so nobody can tell later whether the run is behind or the estimate was. Naming the assumption out loud is most of the answer.
Time to train is the compute budget divided by the rate the fleet actually sustains, which is peak per GPU, times GPUs, times model FLOPs utilization. MFU is the fraction of peak that goes into the model's own matmuls after communication, data loading, stragglers, and non-matmul work; 35 to 45% is a good large-scale bf16 run.
inputs: C = 6.35e24 FLOPs (6 × 70.6e9 × 15e12)
GPUs = 16,384
peak = 989 TFLOPS dense bf16 = 989e12 FLOP/s per H100
MFU = 0.40
effective rate = GPUs × peak × MFU
= 16,384 × 989e12 × 0.40
= 6.48e18 FLOP/s
time = C ÷ rate
= 6.35e24 ÷ 6.48e18
= 9.80e5 s
= 9.80e5 ÷ 86,400 ≈ 11.3 days
sanity: 16,384 GPUs × 11.3 days × 24 h ≈ 4.4 million GPU-hours, which is the same 4.5M figure
the 6ND ÷ per-GPU rate gives directly, so the two routes agree.
Now the sensitivity, which is the point of the question. Time scales as 1 ÷ MFU, so the range is:
| MFU | rate (FLOP/s) | days |
|---|---|---|
| 30% | 4.86e18 | 15.1 |
| 40% | 6.48e18 | 11.3 |
| 50% | 8.10e18 | 9.1 |
A ten-point drop in MFU adds four days to an eleven-day run, and on 16k GPUs that is 1.5 million GPU-hours, several million dollars of rental. That is why training teams report MFU as a first-class metric and why "what MFU did you assume" is the reply to any time-to-train claim.
Two things this estimate leaves out, both of which push the wall clock up. Restarts: a run at this scale loses time to hardware failures and to reloading the last checkpoint, and the recoverable-time fraction is usually 5 to 10% of the schedule. Warm-up and evaluation: learning-rate warm-up, periodic evaluation passes and any mid-run data changes take real time that 6ND does not model. A calendar answer is "eleven days of compute, plan for two to three weeks."
The reversal condition: precision. In fp8 the H100 peak doubles to 1,979 TFLOPS dense, and if the run holds the same MFU the time halves; in practice fp8 MFU is lower than bf16 MFU because more of the step is scaling and conversion, so the gain is closer to 1.3 to 1.6x than 2x, and the honest sentence is "fp8 would bring it to roughly a week if the numerics hold." The GPU-hours and time to train page carries the same fleet equation with the GPU-count form. GPU-Hours and Time to Train is the same equation in different units, and DCGM_FI_PROF_PIPE_TENSOR_ACTIVE is the field that tells you the assumed MFU on a running job. Training FLOPs: 6ND supplies the numerator this divides.
What interviewers probe next
- "What MFU should I assume for a run like this?" 35 to 45% in bf16 on H100s for a dense model with good overlap; below 30% is a sign of a communication or data bottleneck worth diagnosing.
- "Why dense and not the 1,979 TFLOPS on the datasheet?" 1,979 is the fp8 dense figure; the bf16 headline "with sparsity" is 1,979 too but assumes 2:1 structured sparsity that training does not use. GEMMs reach the dense number.
- "How would you measure MFU on the running job?" Tokens per second × 6N gives model FLOPs per second; divide by GPUs × peak. If a step on 16k GPUs processes 16M tokens in 1.0 s, that is 6 × 70.6e9 × 16e6 = 6.8e18 ÷ 1.62e19 = 42%.
- "What if I have 8,192 GPUs instead?" Time doubles to 22.6 days at the same MFU, and MFU is usually slightly higher with fewer ranks, so a little under.
Common mistakes
- Forgetting to convert TFLOPS to FLOP/s and getting an answer in the wrong unit by 1e12.
- Using peak with no MFU and reporting 4.5 days, a number no run has achieved.
- Giving a single day count with no MFU stated, which the interviewer cannot check.
- Treating the compute time as the calendar time, with no allowance for restarts and evaluation.
Key takeaways
- Time = C ÷ (GPUs × peak × MFU); 6.35e24 on 16,384 H100s at 40% is 11.3 days.
- Time scales as 1 ÷ MFU: 30% gives 15 days, 50% gives 9. Say the MFU.
- Use dense peak (989 TFLOPS bf16 on H100), never the sparsity figure.
- Add 5 to 10% for restarts and evaluation before promising a date.