Google Cloud published a benchmark comparing classification and generation workloads on TPU v6e at 15:36 UTC on 4 September. Its lead finding: "For decode-heavy generation tasks, the Gemma 3 27B model hits a strict performance wall past 64 concurrent users, plateauing at a 4.12x normalized throughput multiplier at 128 users. In contrast, the 12B model scales up to an 8.19x multiplier."

The caveat further down

"At extreme concurrency levels (e.g., 128 users), you may notice mathematically anomalous spikes in average throughput. … Under severe resource constraints, misconfigured --max-num-seqs or --max-model-len can lead to silent request dropouts, client connection timeouts, or GKE worker node OOMs. When these failed requests terminate immediately, they falsely shorten the session duration and artificially inflate the throughput metrics. The 128-user data points in these benchmarks represent the absolute limit of cluster stability and should be treated as a ceiling rather than a sustainable production metric."

What the vouched-for rows say

The generation table across 16, 32, 64 and 128 users reads 1.00x / 1.98x / 2.96x / 8.19x for Gemma 3 12B, and 1.05x / 1.97x / 4.00x / 4.12x for 27B. At 64 concurrent users — the last row the post does not disown — the larger model is the faster one, which is the opposite of the headline. The whole "performance wall" narrative is a comparison of two numbers from the disavowed row.

Nothing here is an absolute measurement

Every cell is a multiple of Gemma 3 12B at 16 users, in a table whose column header reads "Throughput (req/s)". There is no absolute requests-per-second figure anywhere, and no cost figure — in a post whose opening line is about unit economics. The setup is a single-host TPU v6e node pool in a 2x2 chip topology on GKE Autopilot, served by vLLM via tpu-inference, at max-model-len=128000, max-num-batched-tokens=8192, max-num-seqs=512.

What the received framing gets wrong

This will be quoted as "TPU v6e delivers 8x". It is a normalised multiple, on one node, on one serving stack, at a concurrency level the publisher labels unstable and possibly corrupted by dropped requests. The post is unusually honest — the disclaimer is right there, unhedged — and the honesty is in the paragraph nobody reaches. The classification table, whose 6.04x-6.37x peaks come from the same 128-user row, carries the same problem.