TPU v6e 跑 Gemma 4 决策推理：比 L4 快一倍，成本却贵 3.7 倍

核心洞察

这篇文章最有意思的点是：TPU v6eCloud TPU v6e (Trillium)，第六代 TPU 芯片，单芯片 32GB HBM、1638 GB/s 带宽、峰值 BF16 918 TFLOPs，性能更强但价格更高。 跑 Gemma 4Gemma 4，Google的轻量级开源模型系列，边缘变体（E2B/E4B）可在1.5GB RAM以下运行。 做决策推理，速度确实比 L4 快一倍，但按需价格贵了将近一倍。作者把预注册、逐条输出、失败记录全公开了，连 31B 加载失败的错误信息都贴出来了。如果你正在纠结推理硬件选型，这篇的实测数据比大多数 benchmark 都实在。

---

这篇文章是一份分步指南，讲怎么在单颗 Google Cloud TPU v6e 芯片上用 Gemma 4 和 vLLM一个高性能的LLM推理和服务库，为DeepSeek-OCR提供优化的推理能力，支持流式输出和批量处理。 跑一个 Jev 风格的决策模型，并和单张 NVIDIA L4 GPUNVIDIA 的推理优化型数据中心 GPU，本教程中作为 Cloud Run 服务的加速硬件，用于承载 Gemma 4 E2B 的 vLLM 推理。 上的同样读取做对比。测量是预注册的，每一条输出都已提交。

一颗 v6e 芯片能以 bf16 服务 Gemma 4 E2B、E4B 和 12B，以及一个 26B-A4B 的 fp8 构建；31B 检查点加载不了。同样的检查点在 TPU 和 L4 上给出同样的答案，26B 在 TPU 上决策耗时 27 到 33 毫秒，L4 上是 61 毫秒。按需计费的话，TPU 每次决策的成本比 L4 或 Jev 都高；12B 是最值得选的尺寸。

代码仓库地址：https://github.com/xbill9/gemma4-dev/tree/main/jev-tpu

---

核心结论

1. 单颗 TPU v6e 芯片可服务 Gemma 4 E2B、E4B、12B（bf16）及 26B-A4B（fp8），但 31B 检查点无法加载——vLLM TPU 后端的 JAX 路径不支持任何 4-bit 压缩格式，唯一可加载的 31B fp8 构建（30.98 GiB）超出芯片 28.74 GiB 可用内存。

2. TPU 与 L4 在相同检查点上给出几乎一致的答案：E2B 和 E4B 在 1,200 条决策中分别有 1,186 和 1,193 条预测标签匹配，每个任务准确率差异不超过 1.0 和 0.4 个百分点。

3. 26B-A4B 在 TPU 上的单次决策耗时为 27–33 毫秒，比 L4 的 61 毫秒快 1.8–2.2 倍，但按需价格 $2.97/小时是 L4（$0.8048/小时）的 3.7 倍。

4. 按需计费下 TPU 每次决策成本更高：12B 每百万次决策 $8.19，26B-A4B 为

这篇文章最有意思的点是：TPU v6e 跑 Gemma 4 做决策推理，速度确实比 L4 快一倍，但按需价格贵了将近一倍。作者把预注册、逐条输出、失败记录全公开了，连 31B 加载失败的错误信息都贴出来了。如果你正在纠结推理硬件选型，这篇的实测数据比大多数 benchmark 都实在。

---

这篇文章是一份分步指南，讲怎么在单颗 Google Cloud TPU v6e 芯片上用 Gemma 4 和 vLLM 跑一个 Jev 风格的决策模型，并和单张 NVIDIA L4 GPU 上的同样读取做对比。测量是预注册的，每一条输出都已提交。

一颗 v6e 芯片能以 bf16 服务 Gemma 4 E2B、E4B 和 12B，以及一个 26B-A4B 的 fp8 构建；31B 检查点加载不了。同样的检查点在 TPU 和 L4 上给出同样的答案，26B 在 TPU 上决策耗时 27 到 33 毫秒，L4 上是 61 毫秒。按需计费的话，TPU 每次决策的成本比 L4 或 Jev 都高；12B 是最值得选的尺寸。

代码仓库地址：https://github.com/xbill9/gemma4-dev/tree/main/jev-tpu

---

0.37，均高于 Jev 的 $5.54 和 L4 上 26B 的最多 $5.43；按 flex-start 价格

这篇文章最有意思的点是：TPU v6e 跑 Gemma 4 做决策推理，速度确实比 L4 快一倍，但按需价格贵了将近一倍。作者把预注册、逐条输出、失败记录全公开了，连 31B 加载失败的错误信息都贴出来了。如果你正在纠结推理硬件选型，这篇的实测数据比大多数 benchmark 都实在。

---

这篇文章是一份分步指南，讲怎么在单颗 Google Cloud TPU v6e 芯片上用 Gemma 4 和 vLLM 跑一个 Jev 风格的决策模型，并和单张 NVIDIA L4 GPU 上的同样读取做对比。测量是预注册的，每一条输出都已提交。

一颗 v6e 芯片能以 bf16 服务 Gemma 4 E2B、E4B 和 12B，以及一个 26B-A4B 的 fp8 构建；31B 检查点加载不了。同样的检查点在 TPU 和 L4 上给出同样的答案，26B 在 TPU 上决策耗时 27 到 33 毫秒，L4 上是 61 毫秒。按需计费的话，TPU 每次决策的成本比 L4 或 Jev 都高；12B 是最值得选的尺寸。

代码仓库地址：https://github.com/xbill9/gemma4-dev/tree/main/jev-tpu

---

.35/小时则降至 $3.72 和 $4.71。

5. 推荐选型：TPU 上做 Jev 风格决策服务应选 Gemma 4 12B bf16（套件得分 76.2%，拟合后中位 ECE 0.070，决策耗时 26–27 毫秒）；当每次决策时间关键或技术栈已在 Google Cloud 上时选 TPU，当每次决策成本关键时选 L4 或 Jev。

为什么要测这个

Jev 风格的决策模型回答一个带类型的问题时，会为每个允许的选项给出一个概率：在答案开始的位置截断提示，读取允许标签 token 的分数，然后对这些分数做 softmax。TypeSafe 的 Jev 把这做成了托管服务，任何开源模型都可以用同样的方式读取。

一篇姊妹文章在单张 NVIDIA L4 上测过这种读取，并和 Jev 的公开结果做了对比。这篇要问的是：换到 TPU 上会有什么变化？哪些 Gemma 4 尺寸能塞进一颗 v6e 芯片？读取方式还一样吗？这颗芯片在速度和成本上换来了什么？

---

开始之前你需要准备

• 一个 Google Cloud 项目，在提供 ct6e-standard-1t 的区域有 v6e 配额，并且 gcloud CLI 已登录
• 一个 Hugging Face token，存为 Secret Manager 的 hf-token 密钥，Compute Engine 默认服务账号可读
• 一个 Cloud Storage 桶用来存结果，在 tpu/run.sh 和 tpu/startup.sh 里设为 BUCKET
• 克隆仓库：git clone https://github.com/xbill9/gemma4-dev，然后 cd gemma4-dev/jev-tpu

---

第一步 — 预注册测量方案

模型、镜像、服务参数、数据、指标以及量化尝试的顺序，在任何模型调用之前就写进 PREREGISTRATION.md 并提交；每一处偏离都会在受影响的结果评分之前记录日期。

git show -s --oneline e0cce69 4937fb8

e0cce69 jev-tpu: sibling of jev for one TPU v6e chip — copied read, data, suite and scoring code (proxy byte-identical); pre-registration for E2B/E4B/12B bf16 and exploratory quantized 26B-A4B/31B probes
4937fb8 jev-tpu: VM boot, serve and run drivers; pre-registration amended before any model call — suite built locally at 0e67403 (13/13 checksums) and re-checked on the VM

---

第二步 — 挑选能塞进一颗芯片的检查点

一颗 v6e 芯片有 31.24 GiB 内存，其中 vLLM 最多用 28.74 GiB：

Memory statistics | total_hbm_limit_gb=31.24GiB | total_hbm_limit_cap_gb=28.74GiB | total_hbm_used_gb=24.56GiB | total_hbm_avail_gb=4.19GiB

E2B、E4B 和 12B 以 bf16 能放下。26B-A4B 和 31B 放不下，所以预注册里列出了按顺序尝试的量化构建：

31B 的 fp8 构建是 30.98 GiB，超过了芯片的可用内存，没有尝试。

---

第三步 — 启动一颗 v6e 芯片

VM 从启动脚本跑完整个测量，从 Cloud Storage 拉取代码和测试套件，运行结束后自删除。

gcloud compute instances create jev-tpu-v6e1 --zone europe-west4-a \
  --machine-type ct6e-standard-1t \
  --image-family ubuntu-accel-2204-amd64-tpu-v5e-v5p-v6e --image-project ubuntu-os-accelerator-images \
  --boot-disk-size 200GB --scopes cloud-platform --maintenance-policy TERMINATE \
  --provisioning-model STANDARD --max-run-duration 6h --instance-termination-action DELETE \
  --metadata jev-code=<code-tarball>,jev-run=2026-09-24-v6e1 --metadata-from-file startup-script=tpu/startup.sh

NAME          ZONE            MACHINE_TYPE      PREEMPTIBLE  INTERNAL_IP    EXTERNAL_IP    STATUS
jev-tpu-v6e1  europe-west4-a  ct6e-standard-1t               10.164.15.207  34.32.155.166  RUNNING

--scopes cloud-platform 让 VM 在启动时能从 Secret Manager 读取 Hugging Face token，这样 token 就不会进入实例元数据。

---

第四步 — 服务每个模型

tpu/serve.sh 一次启动一个模型，每个 arm 用同样的参数，然后等 /v1/models 就绪。以下是删减版，省略了 token 和 volume 选项：

docker run -d --name vllm --privileged --net=host --shm-size 10gb vllm/vllm-tpu:nightly \
  vllm serve google/gemma-4-12B-it --tensor-parallel-size 1 --max-model-len 2048 --max-num-seqs 16 \
  --max-logprobs 32 --generation-config vllm --limit-mm-per-prompt '{"image":0,"audio":0}' --enable-prefix-caching

[jev-run 2026-09-24T14:42:48Z] READY google/gemma-4-E2B-it after 346s
[jev-run 2026-09-24T14:51:34Z] READY google/gemma-4-E4B-it after 421s
[jev-run 2026-09-24T15:02:01Z] READY google/gemma-4-12B-it after 512s
[jev-run 2026-09-24T15:14:59Z] READY RedHatAI/gemma-4-26B-A4B-it-FP8-dynamic after 616s

镜像是 vllm/vllm-tpu@sha256:19a1a0526476f902eb83e1057f3d8938f35b457dd7716a30e9ab4f7bee90d507，vLLM 版本 0.29.1rc1.dev468+g0b7f11a1e。在 v6e 上，它对每个模型默认把 KV 缓存存为 fp8：

INFO 09-24 14:53:37 [tpu_platform.py:232] Automatically using fp8_e5m2 for FP8 KV cache on TPU v6e.

所以下面说的“bf16”指的是权重。L4 那次运行保持默认的 16 位 KV 缓存。

---

第五步 — 从 top 32 里读标签

在 GPU 上，读取时向 vLLM 请求标签 token 按 id 的 log-probabilities。vLLM 的 TPU 后端只返回 top-k log-probabilities，请求特定 token id 会失败。每个模型读取之前会发四种请求形态，答案都保留下来：

== probe 3: {"prompt":[2,106,1645,108],"max_tokens":1,"temperature":0,"logprobs":32,"return_tokens_as_token_ids":true}
{"id":"cmpl-9ee6dc5f0461280b","object":"text_completion", ...
== probe 4: {"prompt":[2,106,1645,108],"max_tokens":1,"temperature":0,"logprobs":5,"logprob_token_ids":[236776,236799,236780],"return_tokens_as_token_ids":true}
{"error":{"message":"list index out of range","type":"InternalServerError","param":null,"code":500}}

所以读取时请求 top 32 个 log-probabilities（JEV_TOPK=32），从中取标签 token。落在 32 以内的标签拿到精确的 log-probability；落在 32 以外的标签拿到代理的回退值，即返回的最低 log-probability 减 5，每条四任务记录都保留了多少标签回来了。

---

第六步 — 运行和评分

每个模型先跑一个五样本的冒烟读取，然后跑四个任务（sst2、AG News、DAIR Emotion 和 tweet_eval irony 各 300 条），三个选项任务及其选项反转版本，一次一个请求的延迟测试，以及 Bespoke Labs 的 3,880 条公开套件，用 Nimble 的转换器重建并在 VM 上对照全部 13 个公开校验和检查。

[jev-run 2026-09-24T14:36:51Z] suite: 13 of 13 subsets match
[jev-run 2026-09-24T15:02:42Z] 12b four tasks: 23s for 1200 decisions at concurrency 8
[jev-run 2026-09-24T15:04:25Z] 12b suite: 60s for 3880 records

python3 sweep_score.py --prefix 2026-09-24-v6e1 --arms e2b e4b 12b 26b-fp8
python3 nimble_suite/suite_sweep.py --prefix 2026-09-24-v6e1 --arms e2b e4b 12b 26b-fp8

两者都把表格写入 results/，下面每个数字都来自那些文件和 article_figures.py。

---

一颗 v6e 芯片上什么能放下、什么能加载

两个 31B 构建都以同样的错误停止：

NotImplementedError: compressed-tensors scheme for layer 'model.language_model.layers.0.self_attn.q_proj' is not yet supported in the JAX path.

Gemma 4 只能在 vLLM TPU 后端的 JAX 路径上运行，它能加载 fp8，但对稠密模型不支持任何 4-bit 格式。它能加载的唯一 31B 格式是 30.98 GiB，超过了一颗芯片的可用内存。

---

TPU 会改变答案吗

不会。E2B 和 E4B 也在 L4 上读取过，用同样的检查点和提示。预测标签在 1,200 条中分别有 1,186 和 1,193 条匹配，每个任务的准确率最多差 1.0 和 0.4 个百分点。这里的 26B-A4B fp8 构建和 L4 上的 4-bit AWQ 构建是同一模型的不同量化，每个任务最多差 1.3 个百分点，套件上差 0.7 个百分点。

每个任务的校准、选项顺序变化和第 90 百分位耗时都在 results/2026-09-24-v6e1-SWEEP.md 里。

---

各尺寸和 Jev 比怎么样

Jev 对比是 L4 那篇文章的主题，其注意事项在那里完整列出。在同样的 3,880 条公开记录上：

Jev 总体领先 12B 1.1 个百分点（95% 区间 −0.8 到 +3.0），领先 26B-A4B 1.3 个百分点（−0.6 到 +3.2），在多选上领先 4.7 和 3.2 个百分点。L4 上的 4-bit 26B 得分 75.3%，落后 2.1 个百分点，区间 0.2 到 4.0，所以可以把 26B 理解为在任一平台上落后 Jev 一到两个百分点。Jev 的逐条答案未公开，所以这些区间比较的是两个独立比例，共享同一段文本的记录会加宽区间。Gemma 是用 PR 代理的提示格式读取的，没有调优；不同的提示可能让多选差距朝任一方向移动。

---

top-32 读取丢了什么吗

准确率上没丢。每条四任务读取至少有一个标签回来了，所以预测标签是精确的；只有 32 以外的标签概率是近似的。

在四个任务上，把所有缺失标签从回退值移到 top-32 上界（它可能有的最大概率），原始 ECE 变化不到 0.001，50 标签后的 ECE 最多变化 0.005。这个检查是运行后加的。套件记录不保留多少标签回来了，所以套件校准数字没有这个检查；按下界计数，12B 的套件记录中至少 10.2%、26B-A4B 的至少 17.8% 用了回退值。

允许标签上的概率占比也各不相同。在 irony 上，12B 最可能的 token 在 300 次读取中有 5 次是标签，两个标签上的概率中位数为 3.1%；26B-A4B 在 300 次 AG News 读取中有 161 次最可能的 token 是标签，中位数为 55.2%。读取会把标签重新缩放使其和为 1，所以答案读起来总是很自信，每条记录里的 label_mass 会显示这一点。

---

TPU v6e 对比 L4

这张表里 🥇 标记更好的值。26B 在 TPU 上决策快 1.8 到 2.2 倍。芯片按需每小时贵 3.7 倍，按 flex-start 价格 $1.35 则贵 1.7 倍，不过这次运行期间该模式没有容量。L4 的成本来自它第一次运行的吞吐，客户端在家庭网络上，所以是上界；TPU 的来自八个并发时的请求耗时。

---

提示：先在两个平台上服务同一个检查点

比较硬件之前，先在两个平台上用同样的提示服务同一个检查点，逐条比较预测标签。这会检查整个读取链路，从聊天模板到标签 token；这里 TPU 的 top-32 读取和 L4 的精确读取在 1,200 条答案中分别有 1,186 和 1,193 条一致。

---

那到底选哪个

如果要在 TPU 上做 Jev 风格的决策服务，选 Gemma 4 12B bf16 加一个在约 50 个标签上拟合的温度。它在套件上和 26B 持平，76.2% 对 76.0%，虽然 26B 在 irony 上高 6.3 个百分点；它拟合后中位 ECE 达到 0.070，决策耗时 26 到 27 毫秒，不需要第三方量化检查点。先在自己的任务上检查 label_mass：在 irony 上，12B 把中位数 3.1% 的概率放在了标签上。

当每次决策的时间重要，或者技术栈其余部分已经在 Google Cloud 上时，选 TPU：它把 26B 的每次决策时间相对 L4 减半。当每次决策的成本重要时，选 L4 或 Jev 本身：按需计费下，一颗 v6e 芯片上的 12B 每百万次决策 $8.19，而 Jev 是 $5.54，L4 上的 26B 最多 $5.43。

---

成本是多少

从八个并发时的请求耗时测量，一颗 v6e 芯片用 E2B 每秒回答约 274 次决策，E4B 206 次，12B 101 次，26B-A4B 80 次。按 europe-west4 按需价格 $2.97 每小时算，分别是每百万次决策 $3.01、$4.00、$8.19 和 $10.37；按 flex-start 价格 $1.35 算，是 $1.37、$1.82、$3.72 和 $4.71。TypeSafe 对 Jev 的定价是每百万次决策 $5.54，基于 L4 运行的中位提示 132 token。芯片不管忙闲都按小时计费，八个并发请求低于服务器允许的 16，所以这些数字只在芯片至少保持这个繁忙度时成立。

实测运行花了 48 分钟按需时间，$2.39，整个测量用到的实例时间最多 $3.25。

---

清理

VM 在 tpu/run.sh 结束后自删除，--max-run-duration 6h 加 --instance-termination-action DELETE 是兜底。确认它没了：

gcloud compute instances describe jev-tpu-v6e1 --zone europe-west4-a

ERROR: (gcloud.compute.instances.describe) Could not fetch resource:
 - The resource 'projects/aisprint-491218/zones/europe-west4-a/instances/jev-tpu-v6e1' was not found

---

总结

这篇文章的目标是在一颗 TPU v6e 芯片上用 Gemma 4 跑一个 Jev 风格的决策模型，找出和 GPU 相比有什么变化。解决方案的关键是和 L4 运行用同样的提示、标签和评分，预注册的设计，以及从 top 32 log-probabilities 读取标签。结果如下：

• 🟢 一颗 v6e 芯片能服务 Gemma 4 E2B、E4B 和 12B bf16，以及一个 26B-A4B fp8 构建
• ❌ 没有 31B 检查点能加载：w4a16 和 4-bit 构建在 JAX 路径上失败，fp8 构建是 30.98 GiB
• 🟢 同样的检查点在 TPU 和 L4 上给出同样的答案：1,200 条中 1,186 和 1,193 条
• 🟢 26B 在 TPU 上决策耗时 27 到 33 毫秒，L4 上是 61 毫秒
• ⚠️ 按需计费下，26B 在 TPU 上每百万次决策 $10.37，L4 上最多 $5.43，Jev 是 $5.54
• ⚠️ vLLM 在 TPU 上只返回 top-k log-probabilities；从 top 32 读标签不改变任何答案，四任务校准变化最多 0.005
• 🟢 12B 和 26B 持平：3,880 条套件上 76.2% 对 76.0%，Jev 是 77.3%
• 🟢 50 标签后，12B 和 26B-A4B 达到中位 ECE 0.070，Jev 出厂是 0.071
• 🟢 整个测量最多花了 $3.25 的实例时间

范围：一颗 TPU v6e 芯片（ct6e-standard-1t，按需）在 europe-west4-a，vLLM 0.29.1rc1.dev468+g0b7f11a1e，镜像 digest 如上，E2B、E4B 和 12B 用 bf16 权重，26B-A4B 用 RedHatAI 的 fp8 构建，每个模型在 v6e 上用 vLLM 默认的 fp8 KV 缓存，--max-model-len 2048，每个模型一次运行，每任务 300 条加 3,880 条公开套件，客户端在 VM 上。top-32 读取和按需容量是带日期的预注册偏离，top-32 上界检查是运行后加的，只覆盖四个任务。L4 数字来自姊妹运行，用 us-east-1 的 g6.xlarge 和 g6.4xlarge，两个平台的计时用了不同的客户端。每个源数据集都在 Gemma 4 之前发布，可能在其训练数据中。没有调用 Jev：Jev 数字是 Bespoke Labs 在同一批记录上的公开结果，来自一家销售竞争模型的公司的 Jev 1.13.0 一次运行，无效 Jev 响应计为错误，Jev 的概率被其 API 四舍五入到两位小数。部分分析和写作用了 AI 辅助（Claude）；每个数字都来自已提交的输出文件。

在 TPU 上用 Gemma 4 跑 Jev 风格决策模型一种通过读取模型对每个允许选项标签 token 的 log-probability，并应用 softmax 来输出每个选项概率的决策方法。的策略，是通过增量式分步方法验证的。

---

参考

• 代码、预注册和逐条结果：https://github.com/xbill9/gemma4-dev/tree/main/jev-tpu
• 姊妹 L4 测量：https://dev.to/gde/plain-gemma-4-26b-vs-jev-on-one-ec2-l4-21-points-behind-overall-level-on-yesno-45-behind-on-15k6
• 姊妹文章对 Jev 独立证据的审查：https://dev.to/gde/jev-after-eight-days-of-independent-tests-level-with-mid-price-llms-behind-the-frontier-1kln
• vLLM TPU 文档：https://docs.vllm.ai/projects/tpu/en/latest/
• tpu-inference：https://github.com/vllm-project/tpu-inference
• 26B-A4B fp8 检查点：https://huggingface.co/RedHatAI/gemma-4-26B-A4B-it-FP8-dynamic
• Gemma 4 12B：https://huggingface.co/google/gemma-4-12B-it
• Bespoke Labs，Jev 1.13.0 公开套件结果：https://github.com/bespokelabsai/nimble/blob/0e67403/docs/PUBLIC_BENCHMARKS.md
• Cloud TPU v6e：https://cloud.google.com/tpu/docs/v6e
• Guo et al., On Calibration of Modern Neural Networks：https://arxiv.org/abs/1706.04599

常见问题（FAQ）

TPU v6e 跑 Gemma 4 做决策推理，比 NVIDIA L4 快多少？

26B-A4B 模型在单颗 TPU v6e 上决策延迟为 27 到 33 毫秒，而单张 NVIDIA L4 上是 61 毫秒，速度约快一倍。同样的检查点在两种硬件上给出相同答案，读取方式也一致。

Gemma 4 哪些尺寸能塞进一颗 TPU v6e 芯片？

一颗 v6e 芯片有 31.24 GiB 内存，vLLM 最多用 28.74 GiB。E2B、E4B、12B 以 bf16 能放下，26B-A4B 的 fp8 构建也能跑；31B 检查点加载不了，其 fp8 构建 30.98 GiB 超出可用内存。

TPU v6e 和 L4 相比，成本上该怎么选？

按需计费时，TPU 每次决策的成本比 L4 或 Jev 都高，虽然速度更快但价格贵了将近一倍。综合速度与成本，12B 是最值得选的尺寸，适合正在纠结推理硬件选型的场景。