Serving Gemma 4 E2B on a TPU v6e-1 A Cloud TPU v6e-1 (Trillium) costs 2.25× a v5e-1 and returns 1.62–1.68× the throughput on workloads that fit in a v5e, and 2.32–2.77× on workloads that do not.
Per output token that makes v6e 34–39% dearer in the first regime and 3–19% cheaper in the second — so the case for the bigger chip is narrower than the memory ratio suggests, and break-even sits at roughly 270,000 KV tokens. v6e is not a general upgrade over v5e.
It is a memory upgrade sold at a compute price: 32 GB against 16, a KV pool of 1,151,744 tokens against 321,376 (3.6×), for 1.907× the bandwidth.
Where the extra memory does nothing, the workload pays 2.25× for 1.6×.
Two findings drive the rest: There is no capacity knee at any occupancy tested. , R² = 0.999996, across 56% to 157% of the KV pool, with in every cell.
A line fitted entirely below 100% occupancy predicts 157% to within 0.13%.
Spot is more expensive than flex-start on this chip — $1.4033 against $1.35/chip-hr in us-east5, reversing the v5e ordering.
The cheaper option is also the preemption-free one that stops billing by itself.
Configuration: (, one Trillium chip), , vLLM , tpu-inference JAX backend, at bf16, TP=1, 32768, 4096, , prefix caching on. 128 throughout. v5e-1 comparison figures are from the same model and engine family on and are not a controlled A/B — read them as shape, not delta.
Part 1 — Getting a v6e-1 at all 1.1 The gcloud spelling table On v5e, is spelled to gcloud.
On v6e the marketing name and the CLI value coincide — which teaches a habit that breaks on the next chip.
Context v5e single chip v6e single chip Prose, directory names / / Flex-start runtime version / / / TPU API quota id Spot quota id Nothing in that table survives a retarget by analogy.
The v6e quota ids drop the the v5e ids carry, and a stale quota id fails quietly — it matches no rows rather than erroring, producing a confident "no quota anywhere" that is a typo. , the directory spelling without the hyphen, is still not a valid gcloud value even though is. 1.2 Provisioning clears three independent gates A creation must pass three separate checks.
They fail differently, and the one that is easiest to query carries the least information.
Gate 1 — does the zone have hardware?
Of 37 zones reporting quota, only 18 offer the accelerator type: Google's regions-and-zones page names 8, a strict subset of what the API accepts.
Read the API.
This gate is provisioning-model-independent.
Gate 2 — does that zone offer that provisioning model for that accelerator type?
Independent of both quota and hardware, and where a published price stops meaning anything. us-central1-b and us-south1-a have v6e-1 hardware, quota, and a published rate for their region, and both reject flex-start at the API: Confirmed accepting flex-start: us-east5-a, us-east5-b, europe-west4-a.
This is the v6e analogue of the v5e result, where flex-start was accepted in exactly one zone out of
44.
Note that europe-west4 inverts across generations: it rejected while quoting a rate for it, and accepts .
Gate 3 — is there free capacity right now?
Reachable only after the first two pass, and the one gate that is not a property of the zone.
Requests in accepting zones sit at for tens of minutes to hours before capacity is granted.
That state is not a failure — it should not be recorded as one, and the request should not be torn down, because flex-start capacity can take up to two hours to come back once dropped.
A published rate is not an offer of capacity, and not even an offer of the provisioning model.
Quota is the first thing most people check and the last thing that should reassure them. 1.3 Provision is flex-start-only. bounds the request, not the run, so it is shared by all three models.
Spot and on-demand nodes bill until preempted or deleted.
The Hugging Face token belongs in Secret Manager, not in the startup script — the rendered script is uploaded as instance metadata, and anything baked into it is readable from the