成本、计费与运维2026年10月26日Cxj

Nvidia H200 GPU：架构、性能与云部署指南

一份实用指南，帮助您为云端 AI 和 HPC 工作负载规划容量、部署、验证并运营 Nvidia H200 GPU。

Nvidia H200 GPU：架构、性能与云部署指南

Nvidia H200 GPU 是一款基于 Hopper 架构的加速器，面向 AI 和 HPC 工作负载；在这些工作负载中，内存容量、内存带宽和多 GPU 拓扑会实质性影响结果。NVIDIA 记录的每块 H200 配备 141 GB HBM3e 内存和 4.8 TB/s 内存带宽。这些是重要的起点——但它们本身并不能说明 H200 部署是否能够满足延迟目标、容纳模型及 KV 缓存，或在云节点内高效扩展。NVIDIA 的 H200 规格是硬件参考；本指南将其转化为部署流程。

对于 AI 开发者和 ML 基础设施团队而言，实际决策通常是：模型、其峰值活跃上下文和运行时开销能否在单块 GPU 上容纳，同时保留足够余量？如果不能，工作负载能否在必须跨越网络之前保持在高带宽 H200 节点内？答案应决定外形规格、并行化方案和验收测试——而非峰值 TFLOPS 的宣传标题。

这是一份架构和部署指南，而非价格表。如果您正在比较报价或云端小时费率，请先参阅我们的H200 GPU 价格指南。如果决策具体涉及 H200 与 H100 的比较，请参阅H200 与 H100 对比。

快速结论：何时 Nvidia H200 GPU 是合适之选

当以下大部分或全部情况都成立时，选择 Nvidia H200 GPU：

您的工作负载受模型内存、KV 缓存增长或内存带宽限制，而不只是受算术吞吐量限制。
您需要为长上下文推理或并发请求提供更多空间，而无需立即将模型拆分到多个节点。
您可以验证实际云拓扑——SXM 或 PCIe/NVL 外形规格、每节点 GPU 数量及可用互连——而不是将“H200”视为完整的部署规格。
您准备好以生产环境预期的相同请求形态，测量首个令牌时间、输出令牌吞吐量、尾延迟、GPU 内存和排队情况。
您需要对服务软件、模型权重、批处理或数据本地性拥有足够控制权，以证明直接运营 GPU 容量是合理的。

H200 并非每个生成式 AI 应用的自动最佳答案。如果较小的加速器能够轻松容纳模型及其活跃上下文，或者您的产品需要在无需维护 GPU 运维的情况下在许多托管模型之间切换，那么托管模型 API 可能是更简单的运营基线。重要的比较是按照您自身流量形态计算的完整工作负载成本和可靠性，而不是原始硬件指标。

Nvidia H200 GPU 架构：影响部署选择的规格

H200 使用 NVIDIA 的 Hopper 架构。Hopper 包含 Transformer Engine 和第四代 NVLink；NVIDIA 将这些功能定位于混合精度 Transformer 工作负载和多 GPU 通信。其 Hopper 架构概述也说明了为何当工作负载扩展到单个加速器之外时，服务器拓扑至关重要。

与部署相关的属性	H200 参考规格	云部署中需要验证的内容
架构	NVIDIA Hopper	您的 CUDA、框架、驱动程序和容器兼容性矩阵
GPU 内存	每块 GPU 配备 141 GB HBM3e	模型权重、峰值 KV 缓存、运行时工作区、碎片化余量以及任何同置服务
内存带宽	每块 GPU 4.8 TB/s	在您的输入长度、输出长度和并发组合下的预填充/解码行为
外形规格	H200 SXM 和 H200 NVL	提供商所提供的确切加速器外形规格，而不只是实例系列名称
节点内连接	NVIDIA 记录 H200 SXM 的 NVLink 为 900 GB/s；H200 NVL 提供 2 路或 4 路 NVLink Bridge 选项	`nvidia-smi topo -m`、点对点连接性以及实测 GPU 间带宽
多实例选项	最多七个 MIG 实例，切片大小因外形规格而异	隔离是否比整卡 GPU 服务方案更有利于您的服务组合
散热设计范围	SXM 最高可配置为 700 W；NVL 最高可配置为 600 W	提供商的供电和散热政策，因为这会影响可用的外形规格

来源：NVIDIA H200 规格。NVIDIA 指出，部分已发布的性能数据使用了稀疏性；请将这些数据作为能力参考，而非生产吞吐量承诺。

内存容量是部署变量，而不是营销数字

对于 LLM 服务，请围绕完整工作集规划 HBM：

所需 GPU 内存 ≈ 模型权重
                    + 峰值活跃 KV 缓存
                    + 运行时工作区
                    + 碎片化和安全余量

模型检查点只是第一项。即使某个配置能够成功加载，留给您计划服务的活跃上下文窗口和并发序列的空间仍可能不足。这正是 H200 的 141 GB HBM3e 即使在模型从技术上讲可装入 H100 级配置时仍然有用的原因：它为部署提供了更多空间，可在批处理大小、上下文长度和并发性之间权衡延迟。

在预留容量之前，请写下以下工作负载输入：

模型、权重格式，以及任何量化或精度模式。
实际请求的最大输入 token 数和最大生成 token 数。
预期的并发活跃序列数——而不仅仅是每秒请求数。
延迟 SLO，包括首个 token 时间和尾延迟。
应用需要单个完整 GPU、隔离切片，还是多 GPU 模型副本。

请使用刻意设计的高难度提示词进行首次容量测算。看似健康的短提示词测试，可能会掩盖在生产上下文长度下出现的 KV 缓存压力。

带宽和拓扑是需要分别检查的事项

对于自回归解码和内存密集型工作负载，内存带宽的重要性至少可与计算能力相当。模型分片后，GPU 间带宽便会变得重要。不要假设八块 H200 GPU 共享一个统一的 1,128 GB 内存池：分布式服务软件必须在实际可用的连接之间放置张量并交换激活值。

NVIDIA 表示，在 DGX 和 HGX 系统中，第四代 NVLink 可提供每块 GPU 900 GB/s 的双向带宽，而 NVSwitch 支持八 GPU 域。这就是为什么单节点拓扑值得与多节点集群分开评估。NVIDIA 的 Hopper 架构参考资料是互连能力的来源；云服务提供商的实例文档则是您实际获得的拓扑的来源。

H200 SXM 与 H200 NVL：先选择部署形态，再选择实例

“H200”并不代表单一的服务器设计。两种常见的部署形态具有不同的运营影响。

选项	优化目标	需要向提供商询问的内容	典型部署影响
HGX 风格节点中的 H200 SXM	采用高带宽 NVLink/NVSwitch 互连的高密度 4 GPU 或 8 GPU 系统	GPU 数量、NVLink/NVSwitch 拓扑、主机 CPU/RAM、网络架构、本地存储和租户隔离	对于需要多块 GPU 但可保留在单个节点内的模型，是很好的默认选择
MGX 或认证系统中的 H200 NVL	采用 PCIe、双插槽、风冷部署，以及已文档化的 2 路或 4 路 NVLink 桥接选项	桥接拓扑、具有对等访问权限的 GPU 数量、PCIe 布局，以及云 VM 是否暴露预期拓扑	适用于节点设计和租户模型与您的工作负载相匹配的场景；不要仅根据 H200 名称推断其具备类似 SXM 的行为

在 NVIDIA 的规格表中，两种形态均列出 141 GB HBM3e 和 4.8 TB/s 内存带宽。对于多 GPU 工作负载，差异化因素通常是围绕该内存的服务器和连接拓扑。应将提供商的拓扑图以及实例内拓扑检查视为必需的采购依据。

工作负载到拓扑的决策矩阵

使用此矩阵确定首次部署实验。它是一个起始假设，而不是基准测试的替代品。

工作负载信号	首先测试的 H200 配置	原因	验收证据
模型和峰值缓存可在一块 GPU 上装入，并留有余量	一块 H200 GPU，一个副本	简化服务、隔离故障，并避免分片通信	在长上下文负载测试期间，内存始终低于配置的保护阈值；延迟 SLO 达标
一个模型需要多块 GPU，但可装入一台 8 GPU 服务器	采用张量并行的一台 H200 节点	将高频模型通信保留在节点内部	拓扑显示预期的对等路径；集合通信带宽和端到端吞吐量可接受地扩展
模型或目标并发性超出单个节点容量	具有已文档化网络架构的多节点集群	增加聚合容量，但使网络和集合通信行为成为服务设计的一部分	跨节点集合通信、恢复行为和尾延迟满足生产测试计划
许多较小且相互隔离的工作负载	仅在验证切片内存和软件支持后再评估 MIG	可改善隔离性或利用率，但无法让一个大型模型装入	已了解每切片内存、调度、遥测归因和影响范围
突发流量，且几乎不需要硬件控制	比较托管模型 API 基线	在控制优势明确之前，避免承诺使用底层容量	在相同工作负载形态下比较成本、延迟、可靠性和模型灵活性

对于分布式推理，vLLM 的文档给出了相同的基本演进路径：当模型可容纳在一张 GPU 上时使用单 GPU；当模型可在一个节点内跨多张 GPU 容纳时使用张量并行；当必须跨节点时再加入流水线并行。具体标志和支持的策略取决于 vLLM 版本及模型架构，因此请根据已安装的版本进行验证。请参阅 vLLM 分布式推理文档。

Nvidia H200 GPU 工作负载的云部署指南

最稳妥的上线方式是分阶段进行。每个阶段在引入另一项变动来源之前，先回答一个问题。

1. 编写工作负载契约

在预配资源之前定义测试流量。应包括模型版本、精度、输入和输出令牌分布、并发量、服务级别目标、地理位置、数据要求以及成本基线。保留一组小型固定回归集，以及一组真实的回放集。

这可以避免一个常见错误：在合成吞吐量测试中比较硬件，随后才发现所选配置无法满足对应用至关重要的长提示词或尾延迟条件。

2. 在部署模型服务器之前验证节点

实例启动后，应识别其物理布局，而不是依赖其产品名称：

nvidia-smi topo -m
nvidia-smi topo -p2p n

NVIDIA 建议在诊断拓扑和 NVLink 行为时执行这些检查。其NCCL 性能与调优指南还建议使用 nvbandwidth 或 nvloom，检查实测的 GPU 到 GPU 带宽是否与预期硬件路径相符。

在部署运行手册中记录拓扑输出。这使后续的性能回归可以被审计：您可以区分应用程序变更与不同 PCIe、NVLink 或网络部署位置所导致的差异。

3. 安装受支持的 GPU 软件栈

对于 Kubernetes，集群需要 NVIDIA 驱动程序、容器运行时路径以及供应商设备插件，工作负载才能请求 GPU。安装设备插件后，Kubernetes 会将 GPU 作为自定义可调度资源公开。Kubernetes 的 GPU 调度指南说明了资源模型，以及如何对混合加速器集群使用标签或亲和性。

NVIDIA 的 GPU Operator 可以在 GPU 工作节点上，以协调的软件栈形式管理驱动程序、NVIDIA Container Toolkit、设备插件、DCGM Exporter 和 MIG Manager。请使用最新的 GPU Operator 安装文档，并在引入模型服务器之前确认其验证器和 Operator Pod 均处于健康状态。

一个最小资源请求在概念上很简单：

resources:
  limits:
    nvidia.com/gpu: 4

在 Kubernetes 中，GPU 通常在 limits 中指定；如果也指定 GPU 请求，其值必须等于限制值。添加节点标签、亲和性、污点和工作负载类别标签，以避免将对延迟敏感的 H200 服务调度到非预期的加速器池中。

4. 从单变量服务测试开始

使用能够容纳该工作负载的最小拓扑启动一个模型副本。对于单节点多 GPU vLLM 部署，张量并行规模应与分配给该副本的 GPU 数量相匹配。例如：

vllm serve <model-identifier> \
  --tensor-parallel-size 4

这有意作为拓扑示例，而非可直接复制运行的生产命令。在您自己的部署清单中固定容器镜像、驱动程序/CUDA 兼容性、模型修订版本、分词器和服务引擎版本。然后一次只更改一个变量：张量并行规模、最大活动序列数、缓存分配策略或副本数量。

5. 分别测试预填充和解码

令牌吞吐量可能掩盖用户实际经历的延迟路径。至少应测量：

短输入提示词和长输入提示词的首个令牌时间。
首个令牌后的输出令牌吞吐量。
P50、P95 和 P99 端到端延迟。
GPU 内存使用量、缓存压力和内存不足事件。
排队时间、请求取消、重试和错误率。

Nvidia H200 GPU 的更大、更快内存可能会改善受约束的部署，因为它创造了更多调度空间；但只有经过测量的请求组合才能表明，这些空间是否会转化为对用户有用的实际容量。

6. 在可能的情况下，先增加副本再增加节点

如果一个 H200 节点可以容纳模型并满足延迟目标，增加副本在运维上可能比引入第二个节点更简单。一旦跨节点部署，首先测试网络和集合通信路径。对于多节点推理，请保持各节点的环境和模型工件一致；容器、驱动程序、模型修订版本或分词器不匹配，可能看起来像是硬件问题。

在收集拓扑基线之前，不要强制设置 NCCL 算法。NVIDIA 的 NCCL 文档指出，默认选择具有拓扑感知能力；手动设置是针对已测量行为的响应，而不是对测量的替代。

7. 在流量面临风险之前监控容量

DCGM Exporter 可以将 GPU 遥测数据暴露给 Kubernetes 监控栈。NVIDIA 将其记录为由 GPU Operator 管理的栈的一部分，并在其 DCGM Exporter 文档中提供了适用于 Prometheus 环境的安装指南。

构建将基础设施健康状况与服务结果关联起来的仪表板：

信号	重要原因	告警问题
GPU 内存和利用率	揭示余量是否正在转化为有效工作，还是变成缓存压力	长上下文工作负载是否正在接近内存保护阈值？
GPU 温度和功耗表现	有助于定位主机或提供商层面的不稳定性	限频是否与延迟或吞吐量下降同时发生？
首个令牌时间和尾延迟	比峰值吞吐量评分更能反映应用体验	排队、缓存压力或拓扑变更是否损害了 SLO？
队列深度和活跃序列数	显示容量问题是副本数量问题，还是每个副本的配置问题	我们是否需要增加一个副本、收紧准入控制，或采用不同的批处理策略？
已完成工作负载成本	使硬件选择始终与业务结果挂钩	在所需 SLO 下，已完成请求是否足以证明容量承诺合理？

8. 规划故障和维护行为

只有具备恢复方案，H200 部署才算生产就绪。测试副本重启、节点排空、模型重新加载、缓存冷启动和上游网络中断。定义容量暂时不可用时的处理方式：排队、削减请求、路由到更小的模型，或使用托管 API 作为回退。最佳选项取决于产品对正确性和延迟的要求。

性能：基准测试工作负载，而不是宣传资料

NVIDIA 发布了有关 H200 的能力和基准测试资料，其中包括在特定比较中具有更高 LLM 推理性能的声明。这些结果有助于理解该加速器能够实现什么，但并不承诺特定模型、上下文长度、量化方式、服务栈或云拓扑会取得相同效果。应结合其测试条件和脚注阅读 H200 数据表。

要进行可操作的 H200 比较，请保持以下变量不变：

模型版本、分词器、精度和量化方式。
提示词和输出令牌分布。
并发量和准入控制策略。
张量/流水线并行布局及实际硬件拓扑。
服务引擎以及 CUDA/NCCL 版本。
SLA 测量方法，包括预热和缓存状态。
云定价单位以及存储、出站流量、CPU 和运维等非 GPU 成本。

该测试计划比通用的“每秒令牌数”比较更有价值，因为它能告诉您 Nvidia H200 GPU 是否改变了面向客户的 SLO 或每个已完成请求的成本。

H200 部署清单

将此清单作为发布新 H200 工作负载的准入门槛。

[ ] 记录模型、精度、峰值上下文长度、输出长度和目标并发量。
[ ] 为权重、KV 缓存、运行时工作区和安全余量计算内存预算。
[ ] 确认分配的 H200 是 SXM 还是 NVL，并记录 nvidia-smi topo -m。
[ ] 验证驱动程序、CUDA、容器、框架和服务引擎的兼容性。
[ ] 在编排器中请求所需的 GPU 数量及放置约束。
[ ] 在加载模型之前运行 CUDA/算子健康测试。
[ ] 在接受多 GPU 结果之前，运行拓扑和集合通信带宽验证。
[ ] 分别测量短上下文和长上下文流量。
[ ] 跟踪 TTFT、输出令牌吞吐量、P95/P99 延迟、排队时间、错误和 GPU 内存。
[ ] 测试重启、节点排空和容量缩减场景。
[ ] 在相同工作负载和 SLO 下，将结果与托管模型 API 基准进行比较。
[ ] 将拓扑、基准测试配置和成本假设与部署决策一同保存。

何时模型 API 是更好的云部署选择

直接运行 Nvidia H200 GPU 可让您控制模型权重、服务配置、数据放置和容量。它也增加了容量规划、拓扑验证、可观测性和恢复方面的工作。如果这些控制并不能带来显著的产品优势，请如实进行比较：基于相同的质量、延迟、可用性和已完成工作负载指标评估托管模型 API。

对于需要在官方模型 API 之间进行测试或路由、但不想维护单独提供商集成的团队，Flatkey 可以作为这样的基准之一。其产品概览介绍了可跨模型和工具使用的一个 API 密钥和余额；正确的选择是以最少的不必要运维复杂度满足工作负载要求的方案。当路由 API 比专用 GPU 容量更适合该工作负载时，您可以探索 Flatkey 的模型目录或获取 API 密钥。

常见问题

Nvidia H200 GPU 的内存容量是多少？

NVIDIA 标明每块 H200 GPU 配备 141 GB HBM3e 内存，内存带宽为 4.8 TB/s。这是单个加速器的规格，因此，如果模型和活动缓存超过单块 GPU 的可用余量，您仍需要分布式服务方案。

H200 主要用于推理还是训练？

H200 面向 AI 和 HPC 工作负载。对于部署规划，应根据工作负载而非标签进行区分：长上下文 LLM 服务、微调、分布式训练和科学计算对内存、通信和调度的压力各不相同。请针对您实际运行的框架和拓扑进行基准测试。

H200 SXM 与 H200 NVL 有什么区别？

它们是不同的 H200 外形规格和服务器集成路径。NVIDIA 列出的 SXM 系统在 HGX 风格的 4 或 8 GPU 配置中具备 NVLink 连接，而 H200 NVL 是一种双槽 PCIe 外形规格，并提供了文档化的桥接选项。在假设多 GPU 行为等效之前，请确认云服务提供商的实际拓扑。

我可以在 Kubernetes 上运行 H200 工作负载吗？

可以，前提是集群具备兼容的 NVIDIA 驱动程序、容器运行时路径和设备插件。Kubernetes 将 GPU 作为扩展资源进行调度，NVIDIA GPU Operator 可以管理 GPU 软件栈和遥测组件。在发送生产流量之前，请验证节点标签、GPU 资源请求、Operator 健康状态以及应用程序级 SLO。