将大语言模型从实验原型推向企业生产环境时，基础设施往往决定了性能上限和单位成本。标准硬件基准测试通常忽略了一个现实：不同类型的 LLM 请求对芯片的压力方式并不相同。
据 Google Cloud 发布的技术文章，该团队在 TPU v6e 上对 Gemma 3 12B 和 Gemma 3 27B 两款开源权重模型进行了系统基准测试，以评估不同结构特征的负载在规模化时的实际表现。
测试架构与负载设计
测试部署基于 Google Kubernetes Engine（GKE）Autopilot 集群，连接配置为 2x2 芯片拓扑的单主机 TPU v6e 节点池。推理框架使用通过 vllm-project/tpu-inference 提供的 vLLM，全局服务配置统一设定为 max-model-len=128000、max-num-batched-tokens=8192 和 max-num-seqs=512。
测试覆盖 16、32、64 和 128 个并发用户，针对两类典型场景：
- 分类任务（高输入、低输出）：模拟电商合规审核，提示词包含大量产品规则、商品描述和 OCR 提取文本，输出仅为“允许”或“禁止”。输入序列长度（ISL）约 4,000 token，输出序列长度（OSL）约 10 token。
- 生成任务（中低输入、高输出）：模拟长文本生成，要求模型撰写关于 AI 与劳动力市场的政策分析简报，主要计算集中在解码阶段。ISL 约 500 token，OSL 约 1,000 token。
生成任务的扩展瓶颈
在解码密集的生成任务中，两款模型在 64 个并发用户以内表现相近。但当并发升至 128 时，Gemma 3 12B 的归一化吞吐量乘数达到 8.19 倍（以 12B 在 16 用户时的吞吐量为基线），而 27B 模型在 4.12 倍处即触及性能天花板。
| 并发用户数 | Gemma 3 12B 吞吐量倍数 | Gemma 3 27B 吞吐量倍数 | |---|---|---| | 16 | 1.00x | 1.05x | | 32 | 1.98x | 1.97x | | 64 | 2.96x | 4.00x | | 128 | 8.19x | 4.12x |
这表明在生成负载下，参数量更大的 27B 模型更早触及内存或算力限制。对于需要高并发生成的场景，文章建议改用 12B 模型，或将 27B 模型的每个副本并发请求严格限制在 64 以内。
值得注意的是，128 用户级别的数据点代表集群稳定性的绝对极限。在资源严重受限时，若 --max-num-seqs 或 --max-model-len 配置不当，可能出现静默请求丢弃、客户端超时或 GKE 工作节点内存溢出。失败请求提前终止会缩短会话时长，从而人为拉高平均吞吐量指标，因此该数据应视为理论上限而非可持续的生产指标。
分类任务中的参数规模无关性
在预填充密集的分类任务中，模型参数规模的差异几乎不体现于扩展行为。两款模型均能在硬件容量内高效运行，128 并发用户时归一化吞吐量分别达到 6.37 倍（12B）和 6.04 倍（27B），TPU 未出现饱和。
| 并发用户数 | Gemma 3 12B 吞吐量倍数 | Gemma 3 27B 吞吐量倍数 | |---|---|---| | 16 | 1.00x | 0.76x | | 32 | 1.18x | 1.53x | | 64 | 2.04x | 3.15x | | 128 | 6.37x | 6.04x |
这意味着在摘要或分类等工作流中，可以部署能力更强的 27B 模型而不必承受明显的吞吐量代价。
延迟变化与调优建议
端到端（E2E）延迟随模型规模和任务类型呈现不同的缩放特征。使用相同的 --max-num-seqs=512 超参数时，12B 模型在分类任务中的延迟从 32 用户到 64 用户约翻一倍，显示资源竞争开始显现；而 27B 模型在 32 至 64 用户间延迟相对平稳，直到 128 用户时才翻倍。
| 模型 | 任务 | 16 用户 | 32 用户 | 64 用户 | 128 用户 | |---|---|---|---|---|---| | Gemma 3 12B | 生成 | 1.00x | 1.13x | 1.40x | 1.70x | | Gemma 3 12B | 分类 | 1.00x | 0.99x | 1.79x | 2.90x | | Gemma 3 27B | 生成 | 1.20x | 1.68x | 2.93x | 3.33x | | Gemma 3 27B | 分类 | 1.20x | 1.95x | 1.95x | 3.88x |
文章指出，硬件饱和会表现为严重的延迟尖峰和静默请求丢失。为缓解这一问题，不应依赖标准的 CPU 或内存扩缩容触发条件，而应基于 E2E 延迟指标进行扩缩。同时建议配置 VLLM_TPU_BUCKET_PADDING_GAP，使序列桶按线性而非几何级数扩展，避免长提示词因零填充造成算力浪费。此外，--max-num-seqs 和 --max-model-len 需根据平均用户负载和每次请求的平均 token 数谨慎设定，否则可能导致请求丢弃。
此次测试表明，原始参数数量并非推理性能的唯一预测因素，服务框架、硬件拓扑与负载 token 比例之间的交互共同决定了效率。映射出的具体硬件饱和阈值——例如分类任务在 64 用户时延迟翻倍、生成任务在 128 用户时触及极限——可为自动扩缩容提供数据驱动的依据，替代过度配置。