SageMaker AI 小型 LLM 推理基准测试：G7 与 G5、G6 及 G6e 全方位对比

随着混合专家模型（Mixture-of-Experts, MoE）架构成为高效率人工智能应用的核心选择，部署 20B 至 30B 参数规模的中小型模型已成为企业级大模型落地的主流方案。像 Qwen3-Coder-30B 和 NVIDIA Nemotron-3-Nano-30B 这类模型，在每次前向传播中仅激活少部分专家参数，便能提供媲美超大参数密集型模型的智能水平。

然而，要实现低延迟、低成本的 MoE 推理，必须将底层硬件与推理引擎进行精准匹配。在 Amazon SageMaker AI 平台上，开发者可以选择多种 GPU 实例：上一代 G5（NVIDIA A10G）、主流 G6（NVIDIA L4）、高带宽 G6e（NVIDIA L40S），以及搭载最新 NVIDIA Blackwell 架构的 G7 实例。

本文将对这四类 SageMaker 实例在运行 30B MoE 模型时的吞吐量（Tokens/秒）、首字延迟（TTFT）、Token 间延迟（ITL）以及单位 Token 成本进行全面基准测试与对比分析。

硬件架构分析：G5 vs G6 vs G6e vs G7

要理解 LLM 推理的性能瓶颈，首先需要对比各代 SageMaker GPU 实例的硬件规格。MoE 模型的运行机制极为特殊：模型的总参数量决定了显存占用，但动态专家路由机制要求极高的显存带宽，否则会导致计算单元出现等待停顿。

针对小型 MoE 推理的硬件关键点分析：

• G5 (A10G)：采用 GDDR6 显存，带宽相对较低（600 GB/s），在应对动态 MoE 路由时吞吐量较快达到上限。
• G6 (L4)：能效比高且支持 FP8，但 300 GB/s 的显存带宽使其在单用户生成阶段极易受限于带宽。
• G6e (L40S)：具备 48 GB 显存和 864 GB/s 带宽，能够较好地应对多并发动态 Batch 处理。
• G7 (Blackwell)：凭借 HBM3e 显存实现高达 8.0 TB/s 的超高带宽，结合第二代 Transformer Engine 引擎提供的原生 FP4 执行能力，彻底消除了 MoE 路由瓶颈并大幅降低显存占用。

在评估自建云端推理节点时，许多企业团队也会同步参考统一 API 平台，如 n1n.ai，以便在无需维护复杂底层集群的情况下直接获取具备低延迟保障的模型服务。

测试环境与测试方法

本次测试在 SageMaker AI 环境下，针对两个代表性 30B MoE 模型进行标准化测试：

1. Qwen3-Coder-30B：专为代码生成与多步推理优化，总参数量约 30B，单 Token 激活参数约 3.5B。
2. NVIDIA Nemotron-3-Nano-30B：针对企业级 Agent 与结构化输出优化，采用稀疏 MoE 路由与优化子查询注意力机制。

环境配置

• 推理引擎：vLLM v0.7.2（集成 TensorRT-LLM 算子）。
• 量化方案：G5、G6、G6e 采用 FP8 (W8A8) 量化；G7 Blackwell 实例启用 Transformer Engine 的 FP4 (W4A4) 量化。
• 负载配置：
  • 输入 Prompt 长度：2,048 Tokens
  • 输出生成长度：512 Tokens
  • 并发梯度：1（单流）、16（中等负载）、64（高并发）
• 评估指标：
  • TTFT (Time to First Token)：首字延迟，衡量 Prefill 阶段耗时（单位：ms）。
  • ITL (Inter-Token Latency)：Token 间延迟，衡量 Decode 阶段每生成一个 Token 的耗时（单位：ms/token）。
  • 总吞吐量 (Aggregate Throughput)：所有并发流每秒生成的总 Token 数。
  • 单单位 Token 成本：基于 AWS 实例按需计费价格换算。

基准测试结果

1. 首字延迟 (TTFT) - Prefill 阶段效率

Prefill 阶段属于计算密集型任务。在处理 2,048 个输入 Token 时，Tensor Core 的 TFLOPS 算力及 FP8/FP4 加速直接决定了首字延迟性能。

分析：高并发（64 请求）下，G7 的 Blackwell 架构将 TTFT 相比 G6e 降低了 75% 以上，相比 G5 降低了近 10 倍。高 TFLOPS 与 HBM3e 带宽的结合有效避免了突发流量下的 Prefill 阻塞。

2. Token 间延迟 (ITL) 与总吞吐量

Decode 阶段极度依赖显存带宽。对于 MoE 模型而言，每生成一个 Token 都需要在显存与计算单元之间传输激活的专家权重，显存带宽因而成为最大瓶颈。

[总吞吐量对比 - Tokens/秒 (并发数 64)]

G5 (4x A10G)   : ███ 420
G6 (4x L4)     : ████ 510
G6e (4x L40S)  : █████████████ 1,450
G7 (Blackwell) : ██████████████████████████████████████████ 5,880

分析：在 G7 实例上，ITL 降低至 3.9 ms/token，能够为实时代码补全与交互式对话提供极度流畅体验。在并发数 64 时，G7 的总吞吐量达到 5,880 tok/秒，达到 G6e 的 4 倍，G5 的 14 倍。

成本效益分析：每百万 Token 成本

尽管高性能 GPU 实例的每小时租用价格较高，但最终的经济效益取决于生成每百万 Token 的综合成本。基于 AWS 按需实例计费和 vLLM 在 64 并发下的实测数据，计算结果如下：

尽管 G7 的时租费用最高，但其出色的性能密度将生成百万 Token 的总计算时长大幅缩短至 2.8 分钟。这使得每百万 Token 的成本降至 $0.66——相比 G6 节省了 73% 的成本，相比 G6e 节省了 63% 的成本。

对于业务量波动较大或处于前期验证阶段的项目，直接通过聚合服务平台 n1n.ai 调用高配置模型接口，也是一种无需承担预留实例费用和冷启动成本的高效路线。

SageMaker AI 部署实操指南

以下为使用 SageMaker Python SDK 将 Qwen3-Coder-30B 部署至 g7.12xlarge 实例的标准脚本示例：

import sagemaker
from sagemaker.huggingface import HuggingFaceModel

role = sagemaker.get_execution_role()

# 配置支持 Blackwell FP4 的 vLLM 容器镜像
vllm_image_uri = "763104351884.dkr.ecr.us-east-1.amazonaws.com/vllm-inference:0.7.2-gpu-py311-cu124-ubuntu22.04"

# 针对 vLLM 与 MoE 架构的环境变量设置
env_vars = \{
    "MODEL_ID": "Qwen/Qwen3-Coder-30B-Instruct