AWS SageMaker AI 推理基准测试：G7 对比 G5 和 G6
AWS 发布了 SageMaker AI 推理基准测试，对两款 300 亿参数模型在四个 GPU 实例系列上的表现进行了比较，其中 G7 在性价比方面领先。测试结果在统一的实时推理工作流下，将 NVIDIA Blackwell 硬件与较早的 G5、G6 和 G6e 选项进行了对照。
这一比较之所以重要，是因为购买最新 GPU 并不必然是最佳部署决策。模型架构、请求并发量、响应长度、内存容量和延迟目标，都会改变哪种实例能带来最低的有效单 token 成本。
这项 AWS 基准测试 测试了四个实例系列上的 Qwen3-Coder-30B 和 NVIDIA Nemotron-3-Nano-30B。两者都是混合专家模型，即通常所说的 MoE 模型：它们会针对每个 token 激活选定的参数组，而非使用全部参数。
AWS 表示，G7 配置在实时推理的吞吐量和性价比上实现了可衡量的提升。但值得关注的不只是 Blackwell 更快，而是这些提升如何改变旧有算力与新一代加速器之间的取舍。
对于工程团队而言，决策取决于两类选择：一类是拥有成熟运行经验的熟悉实例，另一类是承诺让每个已配置端点完成更多工作的 G7 部署。该基准测试为这一决策提供了共同框架，但最终胜出的仍将是实际生产工作负载。
AWS SageMaker AI 推理基准测试实际改变了什么
AWS 将一项硬件代际对比，转化为围绕 token、延迟和端点成本的部署决策。
这项研究评估了两款标称参数规模相同的模型。Qwen3-Coder-30B 面向编程和智能体软件任务，而 Nemotron-3-Nano-30B 覆盖更广泛的推理与语言工作负载。
相同的 300 亿参数标签使这组对比颇具参考价值，但并不代表两款模型的计算负载完全相同。它们的内部路由、注意力模式、活跃参数数量、精度选择和服务实现，都可能带来不同的硬件表现。
AWS 将模型部署到运行 G5、G6、G6e 和 G7 实例的 SageMaker AI 端点。团队随后在受控的基准测试工作流下测量了延迟、吞吐量和性价比。
延迟描述一次请求或生成一个 token 所需的完成时间。吞吐量衡量端点在给定时间内处理的工作量，通常会涵盖并发请求。
性价比则将这些工作量与运行成本联系起来。它关注的是端点在相同支出水平下能够服务多少有效 token，而不是哪块 GPU 最先完成任务。
这一差异对持续运行的端点尤为重要。当利用率持续偏低时，速度更快的实例可能并不更经济；而当流量足以让其保持繁忙时，昂贵的加速器也可能变得高效。
该基准测试还聚焦实时推理，即应用将请求发送至持久化端点，并期待立即获得响应。这与离线批处理不同，后者可以容忍排队和更长的完成窗口。
实时工作负载包括编程助手、客服智能体、检索系统、文档分析和交互式推理工具。每种使用场景都会在首 token 延迟与持续生成速度之间形成不同的平衡。
AWS 将评估置于 SageMaker AI 环境中，而不是呈现一项孤立的 GPU 测试。这使周边服务环境、部署配置、软件栈和端点行为也成为比较的一部分。
因此，结果比原始加速器规格更贴近托管部署场景。但这也意味着，读者不应将每项发现原封不动地套用到其他云平台、框架或自管集群上。
AWS 报告称，在测试配置中，G7 带来了可衡量的性价比提升。该公司将这一优势归因于 NVIDIA Blackwell GPU 及这一代产品面向推理的能力。
这一发现改变了已在使用 G5 或 G6 的团队默认会问的问题。重点不再是 G7 是否采用了更新的芯片，而是迁移能否减少实现既定服务目标所需的资源。
服务目标可能要求最长首 token 延迟、最低生成速率，或支持固定数量的并发会话。硬件只有在改善其中某项结果时才有价值。
因此，这项基准测试为团队提供的是一个初步候选清单，而不是通用答案。它将调查重点缩小到 G7，同时保留了针对具体工作负载进行验证的必要性。
Blackwell 不仅在速度上，也在成本上给旧 GPU 端点带来压力
当更高吞吐量让单个 G7 部署能够承载原本需要更多容量的工作时，它会对旧端点形成最大的压力。
G5 系列属于较早一代的 AWS GPU 基础设施。许多团队已经熟悉其运行特征、兼容容器、扩缩容行为和容量供给模式。
这种熟悉度本身具有价值。一个流量可预测、运行稳定的部署，并不会仅仅因为新一代加速器取得了更好的基准测试成绩就立刻过时。
G6 通过更新的 NVIDIA GPU 推进了这一对比，并着重面向图形和推理工作负载。G6e 则提供了更大的配置，定位于高要求的生成式 AI 和空间计算任务。
G7 将 Blackwell 纳入这一序列。NVIDIA 为 Blackwell 设计了更新的张量处理能力、内存特性和低精度计算能力，旨在提升 AI 工作负载效率。
真正的压力来自端点经济性。如果 G7 能在相同时间内完成更多 token 生成，团队便可用更少的已配置容量满足吞吐量目标。
不过，这种关系取决于利用率。为大流量峰值配置的端点，可能长时间处于闲置状态，从而削弱其理论吞吐优势的价值。
自动扩缩容可以改善利用率，但实时系统并不总能即时扩缩。模型加载、容器启动和流量突发，都对缩容至零策略构成实际限制。
当需求适中、区域容量更易获得，或应用依赖已经验证的软件配置时，旧实例仍然具有吸引力。迁移同样会产生工程和测试成本。
当流量密集且稳定时，G7 的说服力更强。高并发能够为加速器提供足够的并行工作，使其吞吐优势得以显现。
较长输出也可能带来类似效果，因为生成过程会更长时间地占用端点。编程助手和研究智能体通常生成的响应会比简短分类服务更长。
研究中的两款模型有助于说明这一点。一款编程模型可能用于处理代码库问题、代码生成，或输出较长的迭代式调试会话。
Nemotron 则可能服务于推理、综合分析或企业问答请求。即使按当前标准该模型相对较小，此类工作负载也可能涉及大量上下文和持续生成。
因此，“小”是一个相对概念。300 亿参数 MoE 模型虽然小于许多旗舰系统，但仍需要强大的加速器内存和服务基础设施。
MoE 路由改变了计算公式，因为每次 token 计算只有部分模型参与。但完整权重仍会影响存储、加载和内存规划。
这一差距对云服务采购者很重要，因为加速器是以租赁容量的形式购买，而非抽象芯片。实例规格、内存、网络、可用性和软件支持都会影响最终服务成本。
对 AWS 而言，积极的 G7 测试结果强化了将推理工作负载迁移至新基础设施的理由。对 NVIDIA 而言，这些结果支持 Blackwell 在训练最大前沿模型之外的市场定位。
最直接的压力落在那些维护旧端点、却没有最新测量数据的团队身上。按照早期流量或模型假设选定的部署，即使仍满足服务协议，也可能已变得低效。
这并不意味着需要紧急迁移。但在延续长期容量假设前，确实有必要让工作负载与更新的候选方案重新进行测试。
G7 优势为何会在端点层面显现
只有当服务栈能把硬件能力转化为更多已完成请求，同时不突破延迟限制时，Blackwell 的优势才会真正有用。
加速器无法独自为应用提供服务。模型服务器必须调度请求、管理内存、对 token 进行批处理、维护键值缓存，并返回流式输出。
连续批处理尤为重要。这种技术会在生成过程中合并活跃请求，使 GPU 能够处理多位用户的工作，而不是等待单一序列。
更高并发可以提升利用率和吞吐量。但如果服务器接纳的工作超过硬件能在目标时间窗口内处理的范围，延迟也可能随之上升。
正确的配置需要平衡这些影响。团队通常需要测试多个并发级别，因为一次只处理一个请求的结果，几乎无法说明繁忙生产端点的表现。
提示词处理和 token 生成对硬件施加的压力也不同。读取输入提示词会使用并行计算，而后续 token 的生成则遵循顺序依赖关系。
首 token 时间衡量输出开始前的等待时间。token 间延迟衡量流式输出开始后的节奏，而端到端延迟涵盖完整响应。
用户可以接受这些指标的不同组合。编程助手应当迅速确认请求，而后台文档工作流则可以接受较慢的初始响应。
吞吐量不能替代延迟成为唯一指标。一个端点可能产出大量聚合 token，但单个用户等待服务的时间仍可能过长。
同样，较低的单请求延迟并不保证规模化部署的经济性。围绕单一请求优化的配置，可能会在真实流量下让大部分加速器资源闲置。
Blackwell 的价值取决于它能否改善这条运行曲线。最理想的配置是在应用仍可接受的延迟水平下提供更高吞吐量。
精度同样会影响这条曲线。低精度格式可减少内存使用并提高计算效率，但部署团队必须在转换或量化后验证模型质量。
量化会将模型权重压缩为更少的位数。它可以让更大的模型或缓存装入内存，但激进的设置可能改变输出质量。
基准测试中的两款 MoE 模型又增加了一层复杂性。专家路由可以减少每个 token 的计算量，但也可能带来不规则的内存移动，或需要框架特定的优化。
因此，Qwen3-Coder-30B 和 Nemotron-3-Nano-30B 测试的不只是原始矩阵乘法。它们还测试了模型架构、运行时软件和 GPU 能力如何在托管端点内相互作用。
阿里巴巴官方的 Qwen model collection 记录了其不断扩展的语言与代码模型家族。不同版本在上下文长度、精度和服务要求方面各不相同。
NVIDIA 的 Nemotron model card 同样介绍了一个 300 亿参数级别的 MoE 系统，其每个 token 的实际激活规模更小。这些特征使其适合用于高吞吐推理测试。
即使是同一个模型，提示词长度也可能改变结果。简短的聊天轮次、大规模代码上下文和检索得到的文档包，对计算和内存提出的要求各不相同。
响应长度同样重要。短回答更突出提示词处理和首 token 延迟，而长回答则会体现持续解码性能。
因此，每 token 成本需要结合上下文理解。单一的综合数字可能掩盖工作负载究竟使用了短提示词、长提示词、高并发，还是有利的输出结构。
AWS 的发现最有价值之处，在于它证明 G7 值得测试。它不应被视为每个端点都能获得固定百分比提升的保证。
团队应复现自己实际预期的请求分布，包括输入长度、输出长度、并发量、流式传输、错误率和低负载时段。
还应区分成功生成的 token 与被放弃或失败请求所产生的 token。一个启动很快、却难以应对流量峰值的系统，可能会浪费容量，同时无法提供可接受的服务。
因此，G7 领先背后的机制并不只是“新 GPU 等于更高速度”。关键在于，它将更新的硬件转化为更优的延迟—吞吐量边界。
当这一边界向外扩展时，团队可以在相同延迟下服务更多用户。或者，也可以在保持吞吐量不变的情况下降低延迟。
只要端点保持足够高的利用率，两种结果都能改善性价比。硬件优势只有在工作负载达到这一运行点后，才能转化为商业优势。
G7 与 G5、G6 的比较并非普遍结论
AWS 的基准测试支持 G7 适用于所测试的工作负载，但并未确立一个适用于所有模型和流量模式的永久赢家。
第一个限制来自来源视角。AWS 运营 SageMaker AI，并销售比较中每个实例系列的访问权限。
这并不会使测量结果失效。但这意味着买方应将该研究视为供应商提供的证据，并使用自己的工作负载复现其方法。
第二个限制是模型选择。两个 300 亿参数级别的 MoE 模型提供了有意义的覆盖范围，但无法代表稠密模型、视觉语言系统、嵌入模型或规模更大的部署。
稠密模型会在推理过程中激活完整的参数集。其计算和内存行为可能与激活路径较小的 MoE 模型存在显著差异。
多模态模型引入了图像或视频处理。嵌入端点通常更强调请求量和批处理，而非长篇自回归生成。
第三个限制是软件成熟度。新硬件可能会在每个推理框架、内核、容器和监控集成都达到同等稳定性之前推出。
后续的软件版本无需改变硬件就能提升实例性能。反过来，不成熟的运行时也可能阻碍新加速器达到预期性能。
因此，基准结果应包含容器版本、服务框架、模型版本、精度设置和编译器选项。缺少这些信息，复现将变得困难。
容量可用性带来了另一项不确定性。如果团队无法在所需区域获取最快配置，或无法在需求高峰期间对其扩容，那么它的价值就十分有限。
区域支持还会影响数据驻留和延迟。组织不能仅为了使用偏好的加速器，就自由迁移敏感工作负载。
可靠性同样值得重视。团队应将启动失败、内存不足事件、尾延迟、限流和恢复行为与平均吞吐量一并比较。
尾延迟衡量请求中最慢的部分，通常以高百分位结果表示。这些请求往往决定了流量突发期间的真实用户体验。
平均延迟可能看起来健康，但仍有相当一部分用户会经历长时间等待。生产决策应同时涵盖典型表现和高百分位表现。
成本分析也不止于运行 token。空闲端点、部署副本、日志记录、网络传输、存储、工程时间和迁移测试都会影响总运营支出。
文章的价格限制使其无法列出按小时计费的数据，但决策原则依然明确：基准测试中较低的 token 成本，并不保证更低的系统总成本。
团队还应评估每项优化下的输出质量。如果量化或配置调整增加了重试、修正或人工审核，解码更快的价值就会下降。
对于代码工作负载，有价值的测试应衡量被接受的建议或完成的任务，而不只是生成的 token。更多 token 可能只是意味着更冗长，而非更高效的工作。
对于推理系统，准确性和一致性很重要。一个回答很快却需要反复提示的端点，可能会消耗更多总容量。
安全性和治理也会影响实例选择。经过验证的镜像、获批准的依赖链或成熟的监控流程，可能会放缓向新系列迁移的速度。
运营熟悉度可以为暂时的低效率提供理由。不过，这应是由证据支持的明确选择，而非无限期保留的假设。
这正是 Inference Recommender 能够发挥作用的地方。该 SageMaker AI 功能会在团队部署偏好选项之前，根据工作负载和优化目标评估模型服务配置。
建议仍需要判断。排名可以识别有前景的配置，但无法界定可接受的用户体验或应用质量。
正确的结论比全面支持某种硬件更为具体：G7 在接受测试的 AWS SageMaker AI 推理基准中领先，而生产验证仍是最终关卡。
这种谨慎解读保留了研究的价值，也能避免基准图表在缺乏足够上下文的情况下直接变成架构决策。
团队应如何理解吞吐量、延迟和每 token 成本
胜出的实例，是在最低总运营负担下满足既定服务目标的实例。
有效的评估应从应用开始，而不是从 GPU 开始。团队应定义请求模式、预期响应长度、并发范围和可接受的延迟。
交互式服务通常需要严格的首 token 时间目标。即便后续生成速度很快，用户仍会将长时间的初始停顿视为失败。
随后，生成速度决定了响应是否流畅。这对于代码、长篇分析和多步骤 Agent 输出尤为重要。
吞吐量定义了系统可支持的同时在线用户数量。但只有当延迟仍处于产品限制内时，峰值吞吐量数据才有意义。
团队应在多个流量水平下测试。轻负载可揭示基础响应能力，常规负载代表日常经济性，压力负载则会暴露排队或内存故障。
成本计算也应使用相同的流量水平。若将端点费用除以人为饱和测试产生的 token，可能得到一个看似诱人的数字，但日常流量永远无法达到该利用率。
公平的 G7 与 G5、G6 比较，应保持模型、提示词集、响应策略和质量设置不变。仅改变正在审查的部署变量。
预热行为也必须保持一致。初始请求可能触发编译、缓存分配或模型加载效应，从而扭曲短期测试。
更长时间的运行可揭示热稳定性、内存碎片和持续调度器行为，也能降低启动噪声对平均测量值的影响。
请求轨迹应接近生产环境。合成提示词对可重复性仍有价值，但应复现输入和输出长度的实际分布。
仅看平均值并不足够。团队需要在每个并发级别记录中位数结果、高百分位延迟、错误数量、完成请求数和吞吐量。
评估还应记录延迟开始比吞吐量上升更快的临界点。曲线中的这一拐点通常标志着实际容量上限。
当 G7 的拐点出现在更高请求速率时，其优势才会体现价值。端点可以在用户体验恶化前吸收更多流量。
G5 或 G6 在较低利用率下仍可能胜出。如果端点大部分时间都低于新实例的高效运行区间，迁移节省可能无法实现。
流量形态与流量规模同样重要。稳定的内部自动化可以让 GPU 保持忙碌，而面向公众的助手则可能在低负载时段与不可预测的流量峰值之间剧烈波动。
多模型部署带来了另一种选择。将多个模型整合到一块加速器上可以提高利用率，但也可能引入相互干扰和复杂的扩缩容行为。
团队不应将生成的 token 视为唯一价值单位。代码模型应根据已解决任务、被接受代码或缩短的完成时间来评估。
文档分析模型则可通过已完成记录和经过验证的答案来衡量。这些应用指标将基础设施效率与有价值的结果联系起来。
该基准对服务开放权重模型的团队尤其相关。他们可以控制运行时，并调整批处理、精度、上下文限制和模型部署位置。
这种控制也带来责任。每项优化都需要进行质量回归测试，因为基础设施变化可能改变输出行为或数值稳定性。
部署评审还应保留实验记录。基准测试结束后，负责比较配置的工程师仍需访问提示词、容器版本、图表和决策记录。
可搜索的工程知识库可以让这些材料与后续事件和迁移保持关联。当软件更新改变此前结论时，这一点尤为重要。
实际流程是迭代进行的：对当前端点进行基准测试，将 G7 作为候选方案测试，识别延迟—吞吐量边界，并将结果转化为应用结果。
如果 G7 改善了目标指标，团队可以开展受控的生产试点。如果没有，旧部署在工作负载或软件栈发生变化前仍然是合理选择。
这种方法既避免条件反射式迁移，也避免条件反射式谨慎。它将 AWS 的结果视为一项可信信号，但该信号必须经受本地证据检验。
什么将验证 Blackwell 的真实推理优势
三个信号将决定 G7 的基准领先能否成为持久的生产优势，而非一项有利的早期结果。
第一个信号是针对更多模型类型的独立复现。稠密语言模型、视觉语言系统、嵌入服务和更大规模的 MoE 部署，将检验这种领先是否具有普遍性。
不同架构中反复出现的提升，将强化 Blackwell 广泛改变性价比曲线的主张。若结果不一，则模型特定测试的重要性会进一步上升。
第二个信号是在生产并发条件下保持稳定的延迟。早期基准测试通常强调峰值吞吐量，而真实服务必须面对流量突发、变化的上下文和不均匀的输出长度。
G7需要在承载更多并发请求的同时，保持可接受的首 token 延迟和高分位延迟。这样的表现才能把原始算力转化为清晰的用户体验优势。
第三个信号是软件栈逐步成熟后的运行稳定性。框架更新、优化内核、容器支持、自动扩缩容行为以及区域容量，都将影响长期结果。
随着时间推移而持续改善，将进一步强化采用G7的理由，因为较新的运行时能够释放更多Blackwell硬件能力。若部署摩擦持续存在，则会削弱短期迁移的说服力。
采购方应将这三个信号结合起来观察。模型测试更快、但服务不稳定，并不能决定部署选择；而成熟的工具链也无法弥补疲弱的工作负载经济性。
AWS已经提供了一个有价值的起点。其对比涵盖两款30B MoE模型、四个GPU系列，以及实时推理规划中最关键的三项指标。
报告结果倾向于G7，尤其是在吞吐量和每token成本比沿用现有端点的熟悉度更重要时。它也促使团队重新审视过去的容量假设。
这种挑战是积极的。为昨日的模型、流量和运行时作出的GPU选择，可能会在其原始依据早已不再适用后依然延续。
不过，下一步应是测量，而非自动替换。使用接近生产环境的请求进行一次简短基准测试，往往比宽泛的硬件规格更能说明问题。
先定义服务目标。然后比较已完成请求数、首 token 延迟、高分位延迟、持续吞吐量、失败情况和有效利用率。
最后，将基础设施结果与产品成果联系起来。只有当用户能以同等质量更快完成编码、研究、支持或分析工作时，更快的生成才真正有意义。
AWS SageMaker AI的推理基准测试使G7成为这两款模型中需要超越的候选方案。现在，你的工作负载必须决定Blackwell是否也能在你的应用中胜出。
