What changes when matrix inputs use fewer bits?

Idea 1 of 3

Inspect what reaches the multiplication

FP16 distinguishes fewer nearby values than FP32. BF16 has fewer fraction bits than FP16, but a much wider range, similar to FP32. The two small formats therefore make different trade-offs. In this first experiment, keep the near-one inputs fixed and inspect the value before and after conversion.

Indices begin at zero: positions 0–7 contain the near-one input and 8–15 contain −1. Stepping selects an input position. B’s corresponding input is exactly one in every supported format.

Model assumptions: conversion rounds to the nearest representable value, with ties to an even last bit, including tiny values near zero. The trace is a CPU teaching calculation, with no hardware execution, performance or tensor-core mapping.

import torch

row = torch.tensor([1.0003 if k < 8 else -1.0 for k in range(16)],
                   dtype=torch.float32, device="cuda")
a = row.repeat(16, 1).to(torch.float16)
b = torch.ones((16, 16), dtype=torch.float16, device="cuda")
c = a @ b
print(c[0, 0].float().item())

The input conversion happens before accumulation. Once a converted input has become exactly 1, no later addition can recover its original small excess.

Idea 2 of 3

Add products into an FP32 running sum

Each product here is the converted A input times one. Compare two FP32 running sums: one receives converted inputs; the reference receives original FP32 inputs. In the near-one pattern, eight negative ones cancel most of the positive sum. A small discarded input difference can then dominate the final answer.

Next try the small positive inputs to test range. Finally use alternating 1 and −0.5 to test values represented exactly in all three formats. The complete PyTorch example below uses an explicit loop on the CPU to match the model’s chosen order; it is an arithmetic explanation, not a GPU matrix implementation.

Model assumptions: each addition rounds to FP32 and K advances from 0 to 15. All A rows are identical and all B entries are one, so this one trace explains every C entry. Actual matrix kernels may use a different accumulation order or numeric rules.

import torch

row = torch.tensor([1.0003 if k < 8 else -1.0 for k in range(16)],
                   dtype=torch.float32)
converted = row.to(torch.float16).float()
total = torch.zeros((), dtype=torch.float32)
reference = torch.zeros((), dtype=torch.float32)
for k in range(16):
    total = total + converted[k] * 1.0
    reference = reference + row[k] * 1.0
print("Converted-input sum:", total.item())
print("Original-input sum:", reference.item())

Agreement on the exact pattern does not establish accuracy for every input. A useful accuracy check needs the values and formats that the real workload uses, as well as an appropriate reference.

Idea 3 of 3

Connect the arithmetic to tensor cores

The previous chapter grouped outputs into tiles to reuse inputs. Tensor-core implementations also work on matrix groups: threads cooperate to supply input tiles and retain or store the output tile. On NVIDIA GPUs, the warp introduced earlier is one such cooperation group. A lane does not independently perform an entire matrix multiplication.

A 16 × 16 output tile with 16 K positions expresses 4,096 scalar multiply–accumulates. That describes arithmetic work, not hardware instructions, cycles or speed. Supported shapes, formats and cooperation rules depend on the GPU and programming interface.

The browser’s sequential additions do not execute or simulate tensor cores. For a @ b, PyTorch and its selected library implementation decide whether and how to use specialised hardware. A smaller dtype alone does not establish the implementation or its speed. The numeric exercise gives you an accuracy question to ask alongside a separate hardware measurement.