How do I convert TFLOPS to PFLOPS?

1,000 TFLOPS = 1 PFLOPS. The calculator scales single-node compute to rack and datacenter level in both directions, with a reference table of datacenter-scale systems so your fleet sizing uses the right unit before the architecture review.

Why does the TFLOPS vs PFLOPS unit matter for fleet planning?

A single GPU is measured in TFLOPS; a datacenter is measured in PFLOPS. Confusing the two makes a 500-GPU cluster look 1,000× bigger or smaller than it is. The calculator converts your node count and per-node TFLOPS into the aggregate PFLOPS number used in capacity reviews.

How do I benchmark my fleet against TOP500-class systems?

Convert your aggregate compute to PFLOPS and compare it against the reference table's datacenter-scale figures. The calculator handles the unit conversions and keeps the decimal/binary consistency that manual math usually gets wrong.

TFLOPS → PFLOPS Scale Converter

Bidirectional Compute Scaler

Single-node TFLOPS → rack-scale PFLOPS. The conversion is trivial. The framing is not. Top-tier clusters break the PFLOPS barrier — quantify where your fleet lands.

Cluster Compute (TFLOPS)

Aggregated Compute (PFLOPS)

Datacenter Compute Reference

Real-world cluster scale benchmarks for context.

Configuration	TFLOPS	PFLOPS
8× H100 Node (FP8)	15,840	15.84
DGX H100 (8-GPU)	3,168	3.17
32× H100 Rack	63,360	63.36
1,000× H100 Cluster	1,980,000	1,980
Top 10 HPC (Avg.)	—	~200 PF
Frontier (ORNL)	—	~1,200 PF

Navigating the FLOP Scale: From Chip to Datacenter

A single H100 GPU delivers approximately 1,980 TFLOPS in FP8 dense matmul. A single 8-GPU DGX node pushes ~15.8 PFLOPS. Scale to 1,000 GPUs and you're contending with 1.98 exaflops of theoretical throughput — provided your interconnect fabric (NVLink + InfiniBand) doesn't bottleneck the bisection bandwidth.

This converter helps infrastructure engineers translate between the node-level TFLOPS spec sheets and the aggregated PFLOPS numbers that procurement and capacity-planning teams actually budget against. Always derate theoretical peaks by 30–40% for real-world sustained throughput once you account for memory-bound kernels, network contention, and checkpointing overhead.

The precision ladder: one GPU, six different TFLOPS numbers

Vendor spec sheets quote the highest number the silicon can produce under the most favourable precision, and that number is almost never the one your workload achieves. The H100 SXM illustrates the spread across a single part:

FP64: 34 TFLOPS · FP64 tensor core: 67 TFLOPS · FP32: 67 TFLOPS · TF32 tensor core: 495 TFLOPS dense · BF16 / FP16 tensor core: 990 TFLOPS dense · FP8 tensor core: 1,979 TFLOPS dense

The headline figure is the FP8 dense number, and the sparse variant doubles it to 3,958. Between the top and bottom of that ladder sits a factor of 58. A TFLOPS figure quoted without a precision label carries no information, and comparing one generation's number against a differently-labelled number from another is how capacity plans end up wrong by an order of magnitude.

Worked example: the DGX node that benches at 3 PFLOPS

An 8-GPU DGX H100 node advertises 8 × 1,979 = 15.8 PFLOPS. Walk it down to what a real training run sees:

Precision. Pretraining runs in BF16 with FP32 master weights, so the applicable dense rate is 990 TFLOPS per GPU rather than 1,979 — the node is really 7.9 PFLOPS.
Sparsity. The doubled figures require 2:4 structured sparsity in the model. Essentially no frontier model is trained sparse, so the sparse rate is unusable.
Model FLOPs utilisation. Real training runs reach 35–45% MFU once attention softmax, layer norms, gradient synchronisation and pipeline bubbles are counted. At 40%, the 7.9 PFLOPS node delivers about 3.2 PFLOPS of useful work.

A node marketed at 15.8 PFLOPS benches at roughly 3.2. The gap is not marketing dishonesty — every step is a documented property of the hardware — but it is the difference between a training estimate that holds and one that slips by a factor of five.

Turning PFLOPS into a delivery date

Training compute for a dense transformer is approximately 6 × N_params × N_tokens FLOPs. For a 7B model over 2 trillion tokens that is 6 × 7 × 10⁹ × 2 × 10¹² = 8.4 × 10²² FLOPs. Divide by the effective 3.2 × 10¹⁵ FLOPS of the node above and you get 2.6 × 10⁷ seconds —

roughly 300 days on a single DGX node.

Run the same job on 128 nodes with reasonable scaling efficiency and it lands near three days. This is the arithmetic that makes multi-node training mandatory rather than aspirational, and it also shows why interconnect matters more than the per-chip number: at 128 nodes the bisection bandwidth of the fabric, not the FLOP rating of the GPUs, decides whether the aggregate is 128× or something considerably less. Derate theoretical peaks by 30–40% before committing to a schedule, and treat any estimate built on the dense FP8 figure as fiction.