Figure: a bar chart of each read stream as a share of the 236.5 GB per second a DGX Spark GB10 actually achieves on a streaming copy kernel, which is itself 87 per cent of the 273 GB per second spec figure. The bars are: streaming copy 236.5 GB/s, 100 per cent, the reference; weight read under vLLM with FlashAttention-2, 205.7 GB/s, 87 per cent; weight read under HuggingFace with SDPA, 151.5 GB/s, 64 per cent; KV read under HuggingFace with SDPA, 65.7 GB/s, 28 per cent; and KV read under vLLM with FlashAttention-2, 61.1 GB/s, 26 per cent. Weights are read at roughly two thirds to seven eighths of achievable bandwidth and KV at roughly a quarter of it, whichever framework is used. Dividing the best weight read by the worst KV read, 205.7 over 61.1, gives 3.4: on this hardware a KV byte costs 3.4 times a weight byte.

Figure 2.7 · Measured

Weights are read near peak. KV is read at a quarter of it.

A streaming copy kernel on this machine reaches 236.5 GB/s, 87% of the 273 GB/s spec figure — which retires the undefended ~50% "effective bandwidth" haircut earlier drafts applied. Measured against that achieved figure rather than against spec, the weight stream and the KV stream are not the same stream.

Both frameworks read KV at 26–28% of achievable bandwidth. Swapping SDPA with contiguous KV for FlashAttention-2 with paged KV lifts the weight read from 64% to 87% — a 34% improvement — and leaves the KV read at a quarter. That is the same result the fitted slopes give in the previous figure, read off the bandwidths instead of the fits. The fitted model shows a large difference between effective KV-path and fixed-path byte costs on this GB10 configuration. Reducing KV traffic is therefore a first-order opportunity. Compression, sparse selection and placement act on different terms; the measurement does not establish that one universally dominates the others.

Measured — DGX Spark GB10, 19 Aug 2026, scripts/bw_wall.py