将 LLM 从实验原型推向生产，一个关键事实浮出水面：基础设施决定了性能上限和单位经济学。标准硬件基准测试忽略了一个根本差异——不是所有 LLM 请求对硅片的压力方式相同。

本文在 Google Cloud TPU v6e（2×2 芯片拓扑，单主机）上对 Gemma 3 12B 和 27B 进行了分类和生成两类负载的基准测试，使用 vllm (vllm-project/tpu-inference) 作为推理框架，部署在 GKE Autopilot 集群。

基准测试设定了两个典型场景：
– 分类任务（高输入低输出）：模拟电商合规检查，输入约 4000 token，输出仅 10 token 左右。
– 生成任务（低/中输入高输出）：模拟长文本生成，输入 500 token，输出约 1000 token。

所有测试使用统一服务配置：max-model-len=128000, max-num-batched-tokens=8192, max-num-seqs=512。

关键发现：
1. 生成任务的性能墙：在 16、32、64、128 并发用户下，两个模型在 64 用户之前表现相近。但到 128 用户时，Gemma 3 12B 的归一化吞吐量达到 8.19x（以 12B 在 16 用户为基线），而 Gemma 3 27B 仅为 4.12x，表明大模型在高并发生成时很快触及内存或计算极限。
2. 分类任务的性能对等：在分类任务中，两个模型的缩放行为几乎没有差异。12B 和 27B 在 128 用户时分别达到 6.37x 和 6.04x 的归一化吞吐量。模型参数量在预填充密集型任务中对吞吐量影响很小。
3. 延迟阈值：端到端延迟数据显示，12B 分类延迟从 32 用户到 64 用户翻倍（1.00x → 1.79x），而 27B 在 32-64 用户时平稳（1.95x），在 128 用户时跳至 3.88x。生成任务中，27B 在 128 用户时延迟升至 3.33x，而 12B 仅为 1.70x。

建议与边界： 对于高并发生成工作负载，应降级到 12B 模型或为 27B 设置严格的副本自动缩放限制（例如将并发请求上限设为 64）。对于分类/摘要等预填充密集型任务，可以安全部署更大模型而不损失吞吐量。硬件饱和会表现为严重的延迟尖峰和静默请求丢包，建议基于端到端延迟指标而非 CPU/内存指标进行缩放，并积极调整 vLLM 的 TPU bucket padding 参数（如 VLLM_TPU_BUCKET_PADDING_GAP）以节省内存。

最终结论：参数数量不是推理性能的唯一预测指标，推理框架、硬件拓扑和工作负载 token 比率的交互决定效率。通过精确映射硬件饱和阈值，可以实现数据驱动的自动缩放，避免过度配置。