TPU v5e 与 v6e 实测：Gemma 4 推理吞吐量对比与量化收益

核心洞察

这篇文章最有意思的地方在于，它把 TPU 选型从“看参数表”拉回到了“看实际能不能跑起来”。作者用同一套 vLLM一个高性能的LLM推理和服务库，为DeepSeek-OCR提供优化的推理能力，支持流式输出和批量处理。 配置在 v5e、v6e、L4 上跑了 Gemma 4Gemma 4，Google的轻量级开源模型系列，边缘变体（E2B/E4B）可在1.5GB RAM以下运行。，数据很实在，尤其是那个“配额不等于有货”的坑，踩过的人都懂。不过要注意，文中的 v5p 和 TPU7x 数据只是官方规格，没有实测，看的时候别把它们和实测数字混为一谈。

这篇文章是“Inference on Google Cloud”演讲的配套文字版。内容覆盖了在 Cloud TPUGoogle Cloud提供的张量处理单元（TPU）服务，专为机器学习工作负载设计，支持多种代际（如v5e、v6e等）。 v5e 和 v6e 上通过 vLLM 部署 Gemma 4，测试环境是 gemma4-dev 的 Cloud TPU 测试集群，时间跨度从 2026 年 7 月到 10 月。文章还会拿这些结果和 Google Cloud 上的 NVIDIA L4、Blackwell 的标价、AMD MI300X 以及 AWS Inferentia 做对比。四个核心概念能解释大部分结果：芯片原生计算的数字格式、喂给它的内存带宽、切片形状，以及决定一块 TPU 到底能不能租到的那些规则。

https://github.com/xbill9/gemma4-dev

动手步骤在另一个仓库里，一条命令就能启动一块 TPU 并在上面跑 Gemma 4：

https://github.com/xbill9/gcp-inference

幻灯片：https://docs.google.com/presentation/d/1hT8UXOEBueZfoFdIH0ZyhYhQ3WZJ_0xbCsvNDDs8H4A/edit

---

核心结论

1. 在 Cloud TPU v5e 上运行 Gemma 4 E2B，bf16 精度下每秒服务 144 个 token，int8 W8A8 加 4 位嵌入表可提升至 243 tok/s，而准确率仅从 0.683 降至 0.677（3,880 条记录测试集）。

2. 一块 TPU v6e-1 在 26B 4 位检查点上服务 1,283.3 tok/s，是 NVIDIA L4（393.7 tok/s）的 3.3 倍，KV cache 容量为 53,888 token 对 17,990 token，但每小时标价 $2.70 也高于 L4 的 $0.71。

3. 精度收益取决于芯片是否原生支持该格式：v5e 和 v6e 上 fp8 与 int4 均为"仅存储"，权重每次矩阵乘法前需扩成 bf16；只有 int8 在 v5e/v6e 上是原生 2 倍 bf16 速率，这是 int8 吞吐高于 fp8 的直接原因。

4. 配额不等于可用：37 个可用区报告有 v6e 配额，仅 18 个有 v6e-1 硬件；五个持有 1,536 块芯片配额的可用区中有三个返回缺货，us-central1-b 有硬件、有配额、有 flex-startTPU 的一种预付费使用模式，价格约为按需的一半，但可能会有容量限制。 价格却拒绝 flex-start 请求。

5. 单块 v5e 芯片的 16 GB HBM 中，bf16 权重占 8.97 GiB，KV cache 分配 5.52 GiB（321,280 token），支持 131,072 token 满长度上下文时并发降至 2.45 倍；将 --max-model-len 从 8,192 提到 131,072 不改变缓存大小，只改变并发数。

问题是什么？

这篇文章对比了四代 TPU、旁边的 L4 和 Blackwell GPU，以及 Google Cloud 给 TPU 芯片小时定价的每一种方式。同一个 Gemma 4 E2B，在同一块 v5e 上，bf16 下每秒服务 144 个 token，int8 加 4 位嵌入表能到 243。一块 v6e-1 在同样的 26B 检查点上，服务的 token 数是 L4 的 3.3 倍。而一个报告有 1,536 块芯片配额的可用区，照样可能返回缺货。

---

哪几代？

Google 的第一块 TPU 从 2015 年就在其数据中心里跑，是一块 8 位推理芯片，峰值 92 TOPS。Google 在 2025 年 4 月 9 日发布 Ironwood，称其为“Google 首款为推理时代打造的 TPU”。gemma4-dev 测试集群实测了 v5e 和 v6e。v5p 和 TPU7x 那两行只来自 Google 的文档。

vLLM 通过 tpu-inference 这个 JAX 后端访问 TPU。XLA 会为每种输入形状编译一个程序，所以编译成了冷启动里最大的一块。

---

到这一步，你应该有……

• 装好 alpha 和 beta 组件的 gcloud CLI，用 gcloud auth login 和 gcloud auth application-default login 登录
• 一个在 us-west4-a 有单块 v5e 芯片 Cloud TPU 配额的项目
• python3，以及 pip install 'google-adk[extensions]' google-genai mcp
• 克隆好的 xbill9/gcp-inference

---

第一步 — 一块 TPU，一条命令

demo.sh 会在 us-west4-a 申请一块 v5e-1 的 flex-start 请求，等节点就绪，开一条 SSH 隧道连到 TPU 上 vLLM 的 8000 端口，等模型加载和编译完成，然后跑一个 Google ADK agent 去调用它。flex-start 会在 4 小时后自动停掉节点。如果 TPU 已经起来了，./demo.sh again 会跳过前两步：

./demo.sh again

== [0m01s] 3/5  通过 SSH 连接（demo 通过隧道访问 TPU 8000 端口上的 vLLM）
   [0m05s] SSH 正常
   [0m11s] 隧道已开：localhost:8005 -> TPU 8000 端口
== [0m11s] 4/5  在 vLLM 上启动 Gemma（首次启动要下载和编译：好几分钟）
   [0m30s] vLLM 有响应了
  20:21:25Z  PASS  tpu        chat 0.198s; tool run filters=['id >= 10'] quoted=8 3.71s
READY
== [0m37s] 5/5  demo：TPU 上的 Gemma 用 MCP server 的 count_ids 工具数 id
问题：有多少个 id 大于等于 10？用数字回答。
Ids: [0, 2, 3, 20, 21, 22, 23, 10, 11, 12, 13]
正确答案：8  工具：mcp
  tpu        run 1/3  ok   quoted=8  filters=['id >= 10']  3.87s
  tpu        run 2/3  ok   quoted=8  filters=['id >= 10']  0.51s
  tpu        run 3/3  ok   quoted=8  filters=['id >= 10']  0.49s
backend     runs  correct  right-filter  errors  median s  filters sent
tpu            3    3/3             3/3       0      0.51  id >= 10

这个 agent 是一个 ADK 的 LlmAgent，模型是 LiteLlm，指向 vLLM 的 OpenAI 兼容 API。一个 ADK 的 McpToolset 通过 stdio 启动 mcp_server.py，给它提供一个工具。模型自己从不计数。它调用那个 MCP server 上的 count_ids，拿到精确的计数，每次运行都会根据它发出的过滤条件和报出的数字一起打分。v5e 上的 Gemma 4 E2B 三次运行都发出了 id >= 10。

节点用 vllm/vllm-tpu:v0.30.0 以 bf16 服务 google/gemma-4-E2B-it，单芯片，不做分片。

---

第二步 — 16 GB 的芯片装了什么

vLLM 启动时会打印芯片内存。按顺序：

Init worker | ... | hbm=[(0.0, 15.75)]GiB
Init model | hbm=[(8.97, 15.75)]GiB
Memory statistics | total_hbm_limit_gb=15.75GiB | total_hbm_limit_cap_gb=14.49GiB | total_hbm_used_gb=8.97GiB | total_hbm_avail_gb=5.52GiB
TPU KV cache size: 321,280 tokens, Maximum concurrency for 8,192 tokens per request: 39.22x
Init kv-cache | num_total_layers=15 | num_blocks=[1255, ...] | regular_attn_shape=(num_blocks, (256, 1, 2, 256)) | regular_attn_dtype=bfloat16 | hbm=[(14.51, 15.75)]Gb

15 个缓存层每层有 1,255 个 256 token 的块，一个维度 256 的 KV head，bf16 格式。也就是每层每 token 1,024 字节，15 层合计每 token 15,360 字节，总共 321,280 个 token 槽位。模型的 config 列了 35 层，带 num_kv_shared_layers: 20：20 层复用另一层的 key 和 value，所以缓存只存 15 层。

---

第三步 — 完整的 131,072 token 上下文

Gemma 4 E2B 的 config 允许 131,072 个位置。vLLM 根据权重之外剩下的内存来定 KV cache 大小，所以把 --max-model-len 从 8,192 提到 131,072 只改变并发数，缓存大小不变。要在运行中的 TPU 上改参数，得替换容器：

gcloud compute tpus tpu-vm ssh gcp-inference-tpu-node --project <tpu-project> --zone us-west4-a --command \
  'sudo docker rm -f vllm && sudo docker run -d --name vllm --restart unless-stopped --privileged --net=host \
   -v /dev/shm:/dev/shm --shm-size 10gb -e HF_HOME=/dev/shm vllm/vllm-tpu:v0.30.0 \
   vllm serve google/gemma-4-E2B-it --served-model-name gemma --max-model-len 131072 --port 8000 \
   --max-num-batched-tokens 4096 --enable-auto-tool-choice --tool-call-parser gemma4'

Memory statistics | total_hbm_limit_gb=15.75GiB | total_hbm_limit_cap_gb=14.49GiB | total_hbm_used_gb=8.97GiB | total_hbm_avail_gb=5.52GiB
TPU KV cache size: 321,280 tokens, Maximum concurrency for 131,072 tokens per request: 2.45x
init engine (profile, create kv cache, warmup model) took 503.54 s (compilation: 413.41 s)
Application startup complete.

一个满长度请求需要 1.875 GiB 的 KV cache。tpu-survey 里的 scripts/longctx.py 会把一句口令埋在最多 124,949 个 token 的填充内容里的指定深度，每个 prompt 开头都放一行唯一内容，让 vLLM 的前缀缓存没法复用之前的运行，然后问口令是什么：

$ python3 scripts/longctx.py $TPU_URL 8000 0.5
{"prompt_tokens": 7949, "completion_tokens": 10, "depth": 0.5, "seconds": 0.61, "prompt_tokens_per_second": 13110.4, "answer": "violet-harbor-7341", "found": true}
$ python3 scripts/longctx.py $TPU_URL 120000 0.1
{"prompt_tokens": 124949, "completion_tokens": 10, "depth": 0.1, "seconds": 9.53, "prompt_tokens_per_second": 13116.9, "answer": "violet-harbor-7341", "found": true}
$ python3 scripts/longctx.py $TPU_URL 120000 0.5
{"prompt_tokens": 124949, "completion_tokens": 10, "depth": 0.5, "seconds": 9.54, "prompt_tokens_per_second": 13102.3, "answer": "violet-harbor-7341", "found": true}
$ python3 scripts/longctx.py $TPU_URL 120000 0.9
{"prompt_tokens": 124949, "completion_tokens": 10, "depth": 0.9, "seconds": 9.41, "prompt_tokens_per_second": 13274.6, "answer": "violet-harbor-7341", "found": true}
$ python3 scripts/longctx.py $TPU_URL 140000 0.5
HTTP 400: {"error":{"message":"This model's maximum context length is 131072 tokens. However, you requested 16 output tokens and your prompt contains at least 131057 input tokens, for a total of at least 131073 tokens. ..."}}

口令在 124,949 token 的 prompt 的 10%、50% 和 90% 深度都能找回来，每次 9.4 到 9.5 秒，按客户端计时大约每秒 13,100 个 prompt token。vLLM 自己的日志显示每秒 12,495 token，前缀缓存命中率 0.0%，请求运行时 KV cache 用了 38% 到 39%。超过限制的 prompt 在到达芯片之前就被拒了。

---

提示：在现有芯片上提高上下文

flex-start 容量是按请求分配的。替换容器能保住节点和它的 4 小时计时，代价是一次引擎启动，在这块 v5e 上是 503.54 秒。删掉节点重新启动意味着新的 flex-start 请求，以及新的等容量。

---

第四步 — 精度：芯片实际算什么

更小的格式在每块芯片上都能省内存和带宽。只有在矩阵单元原生乘这种格式的地方，才省算力。

“仅存储”意思是权重在每次矩阵乘法前都要扩成 bf16。在 v5e 上，这个顺序直接体现在单流的 E2B 吞吐上：

准确率也稳：在一个 3,880 条记录的测试集上，bf16 是 0.683，int8 加 4 位嵌入是 0.677。12B 上，fp8 在 16 流下服务 518 tok/s，同样文件大小的 int8 是 624。

在 v6e 上，4 位路径靠一个融合 kernel 才划算。Gemma 4 26B-A4B 用 4 位 QAT W4A16，16 流下服务 1,283 tok/s，fp8 是 668，权重占 17.43 GiB 对 27.99 GiB，KV cache 能放 53,888 个 token 对 3,456 个。准确率 75.3% 对 76.0%。W4A16 需要在原版镜像上打 tpu-inference 的 PR #3299、#3653 和 #3660。

---

第五步 — 内存和带宽

每生成一个 token 都要把所有权重读一遍，所以带宽决定了单个请求的上限。

三块实测芯片落在每 TB/s 122 到 154 token 之间。Google 标 v5e 带宽是 800 GiBps，也就是 859 GB/s。L4 的数字是在 AWS g6.2xlarge 上测的，和 Google Cloud 的 g2 是同一块芯片。

---

第六步 — 拓扑和切片

权重大小决定切片。每个 Gemma 4 尺寸都能在单主机上跑：

小模型靠横向扩展。在一块 v5e-4 上，四个单芯片 E2B 引擎在 16 流下输出是一个 TP=4 引擎的 1.39 倍，64 流下 2.52 倍，256 流下 3.36 倍。E2B 只有一个 KV head，所以张量并行会保留四份 KV cache。12B 从 TP=4 受益：单流下是 v5e-1 输出的 2.25 倍，KV token 122,624 对 9,728。

---

提示：配额让你能开口，可用性决定给不给

配额是申请 TPU 的许可。可用性决定请求能不能拿到硬件，要过三道检查：可用区里有硬件、那里提供这种计费模式、那一刻有容量。37 个可用区报告有 v6e 配额，18 个有 v6e-1 硬件。五个持有 1,536 块芯片配额的可用区里，有三个返回缺货。us-central1-b 有硬件、有配额、有 flex-start 价格，但拒绝 flex-start。用 spot 请求查容量：它会快速失败并返回“reason: stockout”，而没配额的 flex-start 请求会排队成 PENDING，看起来和缺货一模一样。

少要几块芯片。在 europe-west4-a，一个 v6e-8 的 flex-start 请求 26 分钟后过期，不到一小时后一个 v6e-4 立刻就批了。

---

第七步 — 和其他加速器比

同样的 26B 4 位检查点，同样的参数和客户端：

Cloud Run 把 L4 当托管服务提供：每个实例一块 L4，权重从 Cloud Storage 挂到 /mnt/models，启动检查第一次探测前等 180 秒，默认在零到一个实例之间伸缩，所以闲置的服务意味着冷启动 GPU。

Google Cloud 上的 Blackwell 每加速器小时标价高于 v6e：g4-standard-48 上的 RTX PRO 6000 按需 $4.50，flex-start $2.25；B200 每 GPU flex-start $8.06（8 卡 a4-highgpu-8g 的 $64.44 除以 8）。两个都只是标价，本文没有实测。

按美元算，E2B bf16 用 vllm bench serve，1,024 prompt 和 128 输出 token，v5e 按 $0.58 的 spot 价格领先到 16 流，MI300X 按 $1.99 在 64 流领先。v6e-1 按 europe-west4 的 $2.97 按需价格算：

每套软件栈各有各的翻车方式：

---

提示：缓存编译结果

对 E2B 来说，XLA 编译占 vLLM 引擎启动的 81% 到 91%：v6e-1 上 404 秒里的 329 秒，v5e-1 上 814 秒里的 738 秒，包含在容器启动到健康的 510 和 986 秒里。今天这块 v5e-1 用 vllm/vllm-tpu:v0.30.0，引擎启动是 503.54 秒，其中 413.41 秒是编译。挂载编译缓存把 v5e 重启从 857 秒降到 497 秒，省了 42%。31B 权重从同区域 Cloud Storage 加载要 5.6 分钟，从 Hugging Face 要 60 到 90 分钟。

GPU 上能用的服务参数在 TPU 上会晚失败，在编译之后。--gpu-memory-utilization 0.95 在 v5e 上编译 691 秒后失败，两次；0.92 能跑。--kv-cache-dtype fp8 在 v6e 上日志写 fp8，实际分配 bf16。vllm/vllm-tpu:nightly 标签在 2026-10-02 弄坏了两个 4 位构建，所以固定镜像 digest。

---

第八步 — 每块芯片多少钱

flex-start 在每一代上都把按需价格砍半，还能低于 spot：us-east5 的 v6e flex-start 标 $1.35，spot 是 $1.40。flex-start 跑 10 分钟到 7 天，计费到删除为止。

利用率决定每 token 价格。一块 v6e-1 按 europe-west4 的 $2.97 每小时，E2B 单流每百万输出 token $4.14，八流 $0.70，32 流 $0.55，按 1,024 token prompt 算。一块 v5e 按 $0.60 的 flex-start 价格，从单流每百万 $1.31 降到 64 流的 $0.09，按 128 token prompt 算。

---

对比与对照

---

那到底选哪个？

E2B 或 E4B 要最低成本，用 v5e-1 跑 int8，每芯片一个引擎，走 spot 或 flex-start。12B 到 31B 单芯片，用 v6e-1 跑 4 位 QAT。bf16 的 26B 或 31B 加长上下文，用 v6e-4 加 TP=4。要原版软件和最快启动，用 L4，在 Compute Engine 或 Cloud Run 上。TPU7x 带来 fp8 算力和每芯片 192 GiB，但在白名单后面。不管选哪个：用 spot 请求查容量，要能放下的最小切片，固定镜像 digest，挂载编译缓存。

---

总结

这篇文章的目标是在 Cloud TPU 上一条命令跑起 Gemma 4，然后通过原生精度、内存带宽、切片形状和容量来解释跨代 TPU 的结果。方案的关键是在真实硬件上验证每个说法，每个比例和价格都用代码算。结果如下：

• 🟢 一块 v5e 芯片装得下 Gemma 4 E2B 完整的 131,072 token 上下文：321,280 token 的 KV cache 旁边是 8.97 GiB 的 bf16 权重，口令在 124,949 token prompt 的 10%、50% 和 90% 深度都能在 9.4 到 9.5 秒内找回来。
• 🟢 agent 发出了正确的过滤条件：v5e 上 3 次运行都调用 count_ids 并传 id >= 10，报出 8。
• 🟢 int8 是 v5e 上的快格式：加 4 位嵌入表后 E2B 是 bf16 的 1.7 倍，准确率差不到一个点。
• 🟢 v6e-1 服务的 token 数是 L4 的 3.3 倍，同样的 26B 4 位检查点，KV cache 是 3 倍。
• 🟢 flex-start 在每一代上都把按需价格砍半，还能低于 spot。
• ⚠️ 冷启动要 8.5 到 16.4 分钟，大部分是 XLA 编译；缓存它。
• 🟢 单流解码跟着带宽走：v5e、v6e 和 L4 上每 TB/s 122 到 154 tok/s。
• ❌ 配额是申请许可，可用性决定批不批：37 个可用区报告有 v6e 配额，18 个有 v6e-1 硬件，持有满配额的可用区照样返回缺货。

范围：动手步骤在 2026-10-25 于 us-west4-a 的一块 flex-start v5e-1 上跑，google/gemma-4-E2B-it 用 bf16，vllm/vllm-tpu:v0.30.0，三次 demo 运行，每个深度一次长上下文请求。其余覆盖 Cloud TPU v5e 和 v6e 上 Gemma 4 E2B 到 31B，用 vLLM 和 tpu-inference 在 gemma4-dev 测试集群上于 2026 年 7 月到 10 月测的；L4 在 Google Cloud g2 和 AWS g6 上；MI300X 在 DigitalOcean 上；Inferentia2 和 Trainium 在 AWS 上。跨厂商的每美元 token 表混了不同 vLLM 构建、主机和重复次数，所以只显示方向。v5p、TPU7x 和 Blackwell 的数字是 Google 公布的规格和标价，2026-10-12 读取，2026-10-25 重读数值相同；spot 价格来自 Cloud Billing Catalog 的记录日期。

在 Google Cloud 上从 v5e 到 Ironwood 服务 Gemma 4 的策略，是用增量的一步步方法验证的。

---

参考

• gemma4-dev | GitHub
• gcp-inference | GitHub
• tpu-survey，长上下文测试和证据 | GitHub
• Gemma 4 E2B-it | Hugging Face
• Inference on Google Cloud 幻灯片 | Google Slides
• Inference on AWS 幻灯片 | Google Slides
• tpu-inference | GitHub
• Cloud TPU 文档 | Google Cloud
• TPU7x (Ironwood) | Google Cloud
• Cloud TPU 定价 | Google Cloud
• 加速器优化机型定价 | Google Cloud
• In-Datacenter Performance Analysis of a Tensor Processing Unit | arXiv

常见问题（FAQ）

在TPU v5e上部署Gemma 4，int8量化加4位嵌入表能提升多少吞吐量？

同一块v5e上，bf16下每秒服务144个token，int8加4位嵌入表能到243个token，提升约69%。这得益于芯片原生int8计算和内存带宽优化。

TPU配额显示有货但实际租不到芯片是怎么回事？

文章提到“配额不等于有货”的坑：一个报告有1,536块芯片配额的可用区，照样可能返回缺货。配额只是允许申请，实际可用性取决于集群资源。

v6e-1和NVIDIA L4在服务Gemma 4 26B模型时性能差多少？

在同样的26B检查点上，一块v6e-1服务的token数是L4的3.3倍。v6e Trillium峰值bf16为918 TFLOPs，远高于L4，且支持int8原生低精度。