Google Cloud 于 9 月 4 日 15:36 UTC 发布了一项比较 TPU v6e 上分类和生成工作负载的基准测试。其最显眼的结论是：“对于以解码为主的生成任务，Gemma 3 27B 模型在并发用户数超过 64 后会遇到严格的性能墙，在 128 个用户时，其归一化吞吐量倍数停留在 4.12x；相比之下，12B 模型可扩展至 8.19x 倍数。”
下方还有一个保留意见
“在极高并发水平下（例如，128 个用户），你可能会注意到平均吞吐量出现数学上异常的峰值。……在严重资源受限的情况下，错误配置的 --max-num-seqs 或 --max-model-len 可能导致请求静默丢失、客户端连接超时或 GKE 工作节点 OOM。当天终止这些失败请求时，它们会错误地缩短会话时长，并人为抬高吞吐量指标。这些基准测试中的 128 用户数据点代表集群稳定性的绝对极限，应被视为上限，而不是可持续的生产指标。”
经证实的行说明了什么
覆盖 16、32、64 和 128 个用户的生成表中，Gemma 3 12B 的数值分别为 1.00x / 1.98x / 2.96x / 8.19x，27B 的数值分别为 1.05x / 1.97x / 4.00x / 4.12x。在 64 个并发用户时——也就是文章没有否认的最后一行——更大的模型反而更快，这与标题所述相反。整套“性能墙”叙事，比较的只是被否认那一行中的两个数字。
这里没有任何绝对测量值
表格中的每个单元格，都是以 16 个用户时的 Gemma 3 12B 为基准的倍数，表头写的是“Throughput (req/s)”。全文没有任何绝对的每秒请求数，也没有成本数字——而文章开头谈的正是单价经济性。该设置是在 GKE Autopilot 上、采用 2x2 芯片拓扑的单主机 TPU v6e 节点池，通过 vLLM 和 tpu-inference 提供服务，参数为 max-model-len=128000、max-num-batched-tokens=8192、max-num-seqs=512。
收到的叙述哪里错了
这段内容会被概括成“TPU v6e 提供 8x”。但这只是一个归一化倍数，来自单节点、单套服务栈、一个发布方标注为不稳定、且可能因丢弃请求而失真的并发水平。该文章出人意料地坦诚——免责声明就在那里，毫不含糊——而这种坦诚藏在没人会读到的那一段里。分类表也一样，其 6.04x-6.37x 的峰值来自同样的 128 用户行，因此有同样的问题。