Google has added cycle-level kernel profiling to XProf, giving developers a live view of how custom TPU code uses compute and memory. Kernels written through Pallas, Mosaic or Triton previously appeared as opaque blocks, leaving optimization dependent on static cost models that can miss real stalls.
The new suite shows lowered compiler instructions, time-aligned tracks for matrix, scalar and vector units, and counters read from TPU hardware during execution. An externally triggered mode can capture sub-microsecond regions at custom-call boundaries, while periodic sampling has a one-microsecond timing floor. Teams can record as many as 28 selected counters on each of four SparseCores.
In Google’s tiled matrix-multiplication example, the counters revealed the compute unit waiting on high-bandwidth memory. Triple-buffering loads alongside calculation reduced kernel time from 125.5 microseconds to 88 microseconds, about 30%. That is one company-authored demonstration, not a general performance promise.
Google advises treating register-level hardware values as more reliable than XLA’s estimated efficiency for custom compilation paths. Counter sampling is documented for TPU v7, also called Ironwood, and XProf does not specify an equivalent capability for earlier chips. Developers must also choose counters carefully because the collection budget cannot capture every available metric at once.