AI辅助整理：本文基于下方列出的公开原始来源改写，不代替原文。
核心摘要： AWS 官方博客用两个 30B 级混合专家模型，在 SageMaker AI 上对比 G5、G6、G6e 与 G7 四代 GPU 实例。编码助手场景中，ml.g7.12xlarge 输出吞吐约 391.3 令牌/秒，比 G6 高约 60.8%、比 G5 高约 13.0%，平均延迟分别降低约 37.6% 与 10.8%。企业助手场景中，g7.48xlarge 在短上下文负载下吞吐约 2397 令牌/秒，g7.2xlarge 每百万输出令牌成本约 0.90 美元。文章强调结果仅适用于所测模型、配置与负载。
业务背景：推理选型成为企业 AI 成本的主要变量
当企业把大模型接入客服、销售助手或经营分析后，账单里增长最快的往往不是训练，而是持续不断的推理调用。同一代模型，换一代 GPU 实例，延迟、吞吐和单位成本都可能出现明显差异。
AWS 官方博客因此用两个 30B 级混合专家模型做了一组对照实验，目标是回答一个具体问题：新一代实例在真实负载下到底能带来多少改善。
问题：参数表看不出真实差距，负载形态决定结论
文章指出，实例代际带来的收益大小取决于模型架构、量化格式和负载形态。混合专家模型在生成阶段受显存带宽约束，因为每个令牌只激活少量专家，带宽直接决定令牌间延迟与吞吐。
此外，只有 G7 实例原生支持 FP4 张量核心，其他代际运行 NVFP4 权重时缺少硬件加速，这构成结构性差异。
AI 怎么落地：两条路径，先测已有端点，再让系统推荐配置
第一条路径是基准测试：把模型部署到不同 GPU 实例的端点上，用同一服务框架和同一负载做对比。文章用 Qwen3-Coder-30B 在 G5、G6、G7 的 12xlarge 规格上测试，负载为 100 个请求、并发 4、平均输入输出各 128 令牌。
第二条路径是推荐：定义模型、候选实例、负载与优化目标，由 SageMaker AI 评估候选配置并返回按指标排序的建议。文章用 NVIDIA Nemotron-3-Nano-30B 测试了对话型与长上下文 RAG 型两种负载。
结果证据：吞吐、延迟与单位成本的具体数字
编码助手场景中，ml.g7.12xlarge 输出吞吐约 391.3 令牌/秒，比 G6 高约 60.8%、比 G5 高约 13.0%；平均请求延迟约 1315.8 毫秒，比 G6 低约 37.6%、比 G5 低约 10.8%；P99 延迟降幅更大，分别约为 54.7% 与 20.2%。值得注意的是，G7 用的是两块 GPU、64GB 聚合显存，而 G5 与 G6 配置为四块 GPU、96GB。
企业助手场景中，短上下文负载下 g7.48xlarge 吞吐约 2397 令牌/秒，g7.2xlarge 每百万输出令牌成本约 0.90 美元；长上下文 RAG 负载下吞吐降至约 816 令牌/秒，单位成本升至约 2.29 美元。流式测试中，G7 中位首令牌延迟约 118 毫秒，平均令牌间隔约 8.9 毫秒。
结果边界：数字只对特定条件成立
文章反复强调，结果仅适用于所测模型、服务配置、令牌分布、并发与负载，并建议企业在生产部署前用自身应用的流量特征做基准测试。
同时，G7 目前仅在美国东部（俄亥俄）与美国西部（俄勒冈）可用，区域可用性会直接影响选型。来源未披露客户案例或长期运行成本数据。
可复制动作：把选型变成可重复的测量流程
企业可以把这套方法固化为流程：先明确优化目标（吞吐、延迟或单位成本），再用代表性负载跑基准，最后按结果选择规格，而不是按代际或参数直觉决策。
对长上下文场景，建议单独建立测试集，因为输入长度增加会同时影响吞吐与单位成本，混在同一个基准里容易得出误导性结论。
证据与边界
- 来源为 AWS 官方博客，含完整基准配置与结果表
- 测试模型为 Qwen3-Coder-30B 与 NVIDIA Nemotron-3-Nano-30B
- G7 目前仅在美国东部（俄亥俄）与美国西部（俄勒冈）可用
- 文章明确结果仅适用于所测模型、配置、负载与区域
企业今天可以做什么
建议企业先做三件事：第一，用自身真实流量特征（输入输出长度、并发、是否流式）构造基准负载，而不是照搬公开数字；第二，把优化目标写清楚，是追求最高吞吐还是最低单位成本，两者对应的实例规格不同；第三，把长上下文场景单独测一遍，因为输入变长会同时压低吞吐、抬高单位成本。