H200 GPU：架构、性能与云端部署指南
NVIDIA H200 GPU 是一款 Hopper 代数据中心加速器，其决定部署方式的核心特性是内存：每块 GPU 配备 141 GB HBM3e 和 4.8 TB/s 内存带宽。这会改变您规划长上下文推理、大批量处理和受内存限制的 HPC 作业的方式，但并不意味着容量规划或云端验证可以省略。
本指南说明 H200 GPU 是什么、H200 SXM 与 H200 NVL 有何区别、它适合哪些工作负载，以及如何在部署更大规模集群之前验证云端部署。本文刻意避免采用易变的云服务商价格快照。请根据您可用的确切区域、机器类型、拓扑和合同，使用下方清单。
简要结论
当您的工作负载受 GPU 内存容量或带宽限制，并且您能够验证周边系统而非仅验证加速器时，请选择 H200 GPU。对于单 GPU 模型服务器，这意味着要证明模型权重、运行时工作空间和 KV 缓存能够在预留余量的情况下容纳。对于多 GPU 训练或推理服务，这意味着要证明 GPU 间互连；在适用情况下，还要证明节点间网络。
H200 GPU 并非通用升级方案。如果请求较短、批量较小，或工作负载受 CPU、存储或网络限制，其额外内存可能无法改变真正重要的结果。请先编写工作负载简介，然后测试具有代表性的追踪数据。
H200 GPU 规格：哪些因素会改变您的部署计划
NVIDIA 将 H200 列为采用 Hopper 架构的 GPU，配备 141 GB HBM3e 内存和 4.8 TB/s 内存带宽。它提供 H200 SXM 和 H200 NVL 两种型号，二者具有相同的主要内存规格，但外形规格、功耗范围和扩展选项不同。NVIDIA 公布的 Tensor Core 峰值数据可用于比较产品配置，但并不承诺应用吞吐量：这些数据包含所述测试条件和稀疏性假设。在选择 SKU 前，请查看最新的 H200 产品规格。
| 与部署相关的规格 | H200 SXM | H200 NVL | 重要性 |
|---|---|---|---|
| 架构 | Hopper | Hopper | 软件兼容性和受支持功能始于平台，而不是型号名称。 |
| GPU 内存 | 141 GB HBM3e | 141 GB HBM3e | 为权重、KV 缓存、激活值和运行时余量提供更多空间。 |
| 内存带宽 | 4.8 TB/s | 4.8 TB/s | 对于反复通过内存移动大型工作集的工作负载非常重要。 |
| 外形规格 | SXM | 双槽、风冷 PCIe | 决定可用的服务器设计和互连方案。 |
| 列出的最高 TDP | 最高 700 W，可配置 | 最高 600 W，可配置 | 影响主机供电、散热、机架和云实例选择。 |
| GPU 互连 | NVLink，标称 900 GB/s | 2 路或 4 路 NVLink 桥接，标称每块 GPU 900 GB/s；PCIe Gen5 | 在假定多 GPU 集体通信性能之前，必须检查拓扑。 |
| 分区 | 最多七个 MIG，每个 18 GB | 最多七个 MIG，每个 16.5 GB | 支持受控共享，但会改变资源和可观测性模型。 |
这些是厂商公布的数据，NVIDIA 在其产品页面中将其标注为初步数据。请将其视为配置基准，然后在实际运行环境中验证确切的云端 SKU 及其拓扑。
为什么 HBM3e 对 LLM 推理很重要
对于 LLM 服务，GPU 内存消耗的不只是模型权重。一个有用的初步容量估算公式是：
required GPU memory = weights + runtime workspace + KV cache at p95 context and concurrency + operational headroom
当 KV 缓存成为限制项时，H200 GPU 可能很有吸引力：更长的提示词、更多的并发序列或更大的批量都会增加其占用。额外的 HBM 并不能消除内存不足风险，因为缓存策略、分配器行为、量化、模型并行和流量形态仍然很重要。对于长上下文部署，请将此决策与KV 缓存卸载和分层计划结合起来，而不要假定更多本地内存就是全部答案。
H200 SXM 还是 H200 NVL：选择拓扑，而不只是显卡
外形规格是一项部署选择。
- H200 SXM适用于配备四块或八块 GPU 的 HGX H200 和 NVIDIA 认证系统设计。当单个工作负载需要紧密耦合的多 GPU 系统，且应用程序将频繁在 GPU 之间交换数据时，它通常是合适的起点。
- H200 NVL是一种双槽、风冷 PCIe 设计。NVIDIA 列出了 2 路或 4 路 NVLink 桥接配置，而合作伙伴和认证系统最多可包含八块 GPU。不要推断每台八 GPU 服务器都提供相同的直接 GPU 间路径；请检查实际拓扑，并对运行时使用的集体通信进行基准测试。
- 独立副本不一定需要耦合最紧密的互连。如果每个副本处理各自的请求，请在为工作负载不会使用的拓扑付费之前，优先考虑容量、可用性、主机资源和清晰的调度边界。
| 工作负载模式 | H200 设计初始问题 | 首先要验证的内容 |
|---|---|---|
| 一个加速器上的一个模型服务器 | p95 内存预算是否在保留安全余量后仍能满足要求？ | 分配稳定性、TTFT、令牌间延迟和内存水位。 |
| 一个模型跨多个 GPU 拆分 | 模型并行策略是否与实际的 NVLink/NVSwitch 拓扑相匹配？ | nvidia-smi topo -m、集合通信行为和端到端延迟。 |
| 多个服务副本 | 副本是相互独立，还是共享存在瓶颈的主机或网络？ | 每个副本的吞吐量、排队、嘈杂邻居行为和主机 I/O。 |
| 分布式训练或微调 | 互连结构和节点间网络是否与集合通信模式相匹配？ | NCCL 启动、集合通信带宽、检查点 I/O 和慢节点比例。 |
| 多租户推理 | 完整 GPU、MIG 实例还是时间切片资源，哪一种才是正确的隔离级别？ | 内存隔离、故障隔离、成本分摊和每租户可观测性。 |
NVIDIA 对 H200 MIG 容量有所说明，但不要将各种 GPU 共享模式视为可互换的。在 Kubernetes 中，MIG 会创建硬件隔离的 GPU 实例，而时间切片会交错执行工作，无法在副本之间提供内存或故障隔离。GPU Operator 共享指南说明了其中的权衡及其监控限制。
如需更深入的采购比较，请参阅 H200 vs. H100。该比较有助于做出决策；而一旦确定 H200 是候选方案，本页面就是部署操作手册。
H200 GPU 适用的场景
当生产环境中确实存在以下某项约束时，通常值得测试 H200 GPU：
- 受内存限制的 LLM 推理。在计算资源尚未被充分利用之前，您的 p95 上下文长度或并发量已耗尽实际可用的内存预算。
- 对带宽敏感的 AI 或 HPC。性能分析显示，作业有相当一部分时间在等待内存传输，而不只是使 Tensor Core 计算饱和。
- 更大的内存驻留工作集。您需要为模型、检索上下文、批次、缓存或科学数据结构留出更多空间，同时又不想立即增加另一块 GPU。
- 紧密耦合的多 GPU 工作负载。您可以使用 H200 SXM/HGX 类系统，并且有证据表明应用程序可从其互连结构中受益。
- 受控的分区需求。您有明确理由使用所列的 MIG 配置，并且拥有与之匹配的调度器和成本分摊模型。
不要仅根据模型参数量来选择 H200 GPU。参数量几乎无法说明精度、运行时工作空间、KV 缓存策略、最大上下文、批次形状和可用性余量。它也无法反映可能主导云工作负载性能的主机 CPU、RAM、存储或网络瓶颈。
租用云 GPU 前制定 H200 容量计划
在创建实例或请求集群节点池之前，使用这份一页简报。
| 输入项 | 记录内容 | 其影响结果的原因 |
|---|---|---|
| 模型和精度 | 确切的模型修订版本、权重格式、量化方式和运行时 | 决定基础内存下限和兼容的软件栈。 |
| 请求分布 | p50/p95 提示词令牌数、输出令牌数、到达速率和并发量 | 平均值会掩盖导致延迟 SLO 失效的缓存和排队状况。 |
| 服务目标 | p95 首令牌时间、p95 令牌间延迟、错误预算和恢复目标 | 定义您是否需要副本、预热容量或更快的互连结构。 |
| 并行化计划 | 单 GPU、张量并行、流水线并行、数据并行或独立副本 | 决定本地内存、NVLink 还是网络是关键路径。 |
| 部署环境 | 单个 VM、托管节点池或 Kubernetes 集群 | 改变驱动程序所有权、调度、可观测性和升级责任。 |
| 数据路径 | 模型制品来源、检查点存储、向量索引、出站路径和网络策略 | 避免高速加速器等待存储或网络。 |
| 财务单位 | 已接受请求、已完成批次、作业 epoch 或每百万个已接受令牌 | 避免每小时 GPU 报价成为唯一的成本指标。 |
这份简报的价值在于，它能尽早暴露不适配之处。例如，即使合成的短提示词测试表现出色，单 GPU 配置仍可能因 p95 上下文和缓存压力而失败。相反，如果多 GPU 配置被拆分到运行时无法高效利用的互连结构上，也可能性能不佳。
云端部署：分阶段 H200 GPU 操作手册
1. 确认确切的云端配置
向提供商或平台团队询问确切的加速器外形规格、GPU 数量、CPU/RAM 分配、本地和持久存储、网络特性以及 GPU 拓扑。请将答复记录在部署工单中。对于多 GPU 性能预期而言，仅有“H200”这一信息还远远不够。
在预留容量之前，请在短期试点中验证以下细节：
- H200 SXM 或 H200 NVL
- GPU 数量以及
nvidia-smi topo -m的输出 - 实例是独占、分区还是分时共享
- 驱动程序、CUDA、容器运行时和框架版本
- 可用的主机 RAM、CPU 核心数、存储吞吐量和网络路径
- 镜像拉取、模型下载、检查点和重启耗时
2. 安装受支持的软件路径
对于 Kubernetes 部署，NVIDIA 的 GPU Operator 可以管理 NVIDIA 驱动程序、容器工具包、设备插件、GPU Feature Discovery、基于 DCGM 的监控以及相关组件。官方安装指南指出，当 Operator 管理驱动程序时，需要保持节点操作系统一致性，同时还需满足容器运行时和命名空间安全性前提条件。请遵循当前的 GPU Operator 安装指南，而不要复制过时的 chart 版本。
初始安装遵循以下模式；请将版本替换为已根据集群和驱动程序策略验证过的版本：
helm install --wait gpu-operator \
-n gpu-operator --create-namespace \
oci://nvcr.io/nvidia/cloud-native-charts/gpu-operator \
--version=<validated-operator-version>
安装后，在提交第一个工作负载之前，验证 Operator Pod 和 ClusterPolicy 状态。Operator 指南还说明了如何确认节点报告可分配的 nvidia.com/gpu 资源。
3. 明确指定调度
除非您已专门为共享模式进行了设计，否则应从独占的完整 GPU 请求开始：
resources:
limits:
nvidia.com/gpu: 1
使用平台自有的节点池标签或云选择器来定位已验证的 H200 节点；不要硬编码示例集群中的产品标签。Kubernetes 文档介绍了如何通过设备插件和扩展资源进行 GPU 调度，包括上述资源限制模式。请参阅 Kubernetes GPU 调度文档以了解当前约定。
如果启用 MIG，请先清空或隔离相关节点。NVIDIA 指出，更改 MIG 模式或布局要求用户工作负载从 GPU 上移除，并且在某些云环境中可能需要重启。在将分区更改视为在线操作之前，请先查看 GPU Operator 的 MIG 操作流程。
4. 先验证简单工作负载，再验证实际工作负载
按顺序执行三个关卡：
- 平台关卡：驱动程序和 CUDA 可加载；调度器识别到预期数量的 GPU；容器可以创建 CUDA 上下文。
- 互连关卡：拓扑与既定设计相符；多 GPU 运行时能够初始化并完成具有代表性的集合通信测试。
- 应用关卡：使用具有代表性的提示词、批量大小、上下文长度、检查点模式或仿真输入进行回放，达到所需的延迟、吞吐量和错误目标。
第三个关卡是决策关卡。通用基准测试可以告诉您 GPU 是否正常工作；但它无法告诉您流量分布、模型服务器和缓存策略是否正常工作。
扩缩容前验证性能
围绕预期瓶颈构建验收测试，然后检查能够推翻该假设的结果。
| 假设 | 测试 | 成功信号 | 需要调查的失败情况 |
|---|---|---|---|
| 模型能够容纳 | 使用内存水位线运行 p95 上下文/并发跟踪 | 分配稳定且具有明确余量 | 随着缓存增长出现 OOM、驱逐抖动或延迟尖峰。 |
| 互连足够 | 运行精确的并行模式和相关的集合通信测试 | 无卡死；集合通信和端到端耗时稳定 | NCCL 初始化错误、rank 不均衡或对等节点缓慢。 |
| 服务满足其 SLO | 测量 p50/p95 TTFT、token 间延迟、端到端延迟和已完成请求数 | 在具有代表性的负载下满足目标 | 排队、长尾延迟或重试增加。 |
| 节点健康 | 在维护窗口内检查被动遥测和主动诊断 | 没有需要处理的硬件、互连或部署发现 | ECC/Xid 事件、温度/功耗限制、PCIe/NVLink 发现。 |
| 经济性成立 | 将完全加载的时间除以完成的有效工作量 | 成本处于启动阈值以内 | 闲置容量、失败的工作，或未计价的存储/网络开销。 |
NVIDIA DCGM 将被动健康监控与主动诊断分开。其诊断工作流可以测试部署、内存、PCIe、NVLink、计算、功耗、温度和通信路径，但会消耗资源并可能与生产工作发生冲突。在执行侵入式诊断前，请清空节点或安排维护窗口。请使用 DCGM 当前的诊断指南来选择合适的测试级别。
对于 LLM 服务，同时跟踪应用和基础设施信号：
- p50/p95 首个令牌时间和令牌间延迟
- 每秒接受的输出令牌数和每秒完成的请求数
- 队列深度、取消、重试和错误率
- 已分配与已预留的 GPU 内存、GPU 利用率、功耗和温度
- 缓存命中/卸载行为以及与缓存相关的故障
- 主机 CPU 饱和度、RAM 压力、模型/检查点 I/O 和网络延迟
如果一个指标变好而另一个变差，暂时不要扩容。令牌速率提高但 p95 延迟或重试次数上升，可能会导致面向客户的服务出现退化。
按完成的工作量优化成本，而非按每小时 GPU 时间
云端 H200 GPU 费率因地区、预留期限、主机配置和供应情况而异，因此静态价格表很快就会过时。相反，应使用能够反映空闲时间和失败工作量的工作负载单位：
fully loaded hourly cost = accelerator + attached CPU/RAM + storage + network + licenses + operating overhead
cost per completed request = fully loaded hourly cost / completed requests per hour
cost per million accepted output tokens = fully loaded hourly cost / accepted output tokens per hour × 1,000,000
应按预计上线时的流量组合进行计算，而不是按最大吞吐量演示进行计算。将为故障转移、模型加载、检查点和维护预留的容量纳入其中。如需更详细的模型，请参阅 自托管 LLM 每百万令牌成本。
还有一个边界问题：您需要运营运行时，还是需要可靠地访问模型输出？如果您需要自定义内核、特定运行时、专用数据本地性或受控硬件实验，那么云端 H200 GPU 试点可能是合理的。如果您主要需要模型 API，请在投入基础设施之前，将运营负担与 API 路径进行比较。GPU 服务器部署指南和Kubernetes GPU 集群指南可帮助明确这一边界。
H200 GPU 部署检查清单
在认定 H200 部署已准备就绪之前，请验证以下各项：
- [ ] 已记录确切的 H200 外形规格、GPU 数量和拓扑
- [ ] 已在 p95 上下文长度和预期并发量下测试内存预算
- [ ] 已验证驱动程序、CUDA、框架和容器镜像的兼容性
- [ ] 使用 Kubernetes 时，已确认 GPU Operator/设备插件健康状态
- [ ] 调度器暴露了预期的
nvidia.com/gpu容量 - [ ] 多 GPU 集体通信测试已在生产拓扑上通过
- [ ] 代表性负载测试达到 TTFT、延迟、吞吐量和错误目标
- [ ] DCGM 健康检查和适用于维护窗口的诊断已纳入运行手册
- [ ] 已测量存储、网络、模型加载、检查点和重启路径
- [ ] 已按完成的有效工作单位计算成本，并包含空闲及恢复容量
常见问题
H200 GPU 有多少内存？
NVIDIA 列出的 H200 SXM 和 H200 NVL 均配备 141 GB HBM3e 内存和 4.8 TB/s 内存带宽。请向提供商确认确切的 SKU 和系统配置，因为卡的外形规格和互连方式不同。NVIDIA 的 H200 规格是本指南中相关数据的来源。
对于 LLM 推理，H200 GPU 是否优于 H100？
有可能，尤其是在内存容量或内存带宽限制工作负载时。实际答案取决于模型精度、上下文长度、KV 缓存行为、并发量、服务运行时和系统拓扑。请使用代表性追踪数据比较工作负载；不要将供应商基准测试视为服务 SLO 的替代品。有关硬件决策框架，请参阅 H200 与 H100 对比。
我应该选择 H200 SXM 还是 H200 NVL？
应从拓扑出发进行选择。H200 SXM 适合紧密耦合的 HGX 风格多 GPU 配置。H200 NVL 是采用 PCIe、风冷的选项，支持 2 路或 4 路 NVLink 桥接配置。请验证拓扑、主机和工作负载的通信模式，而不要仅根据内存进行选择。
H200 GPU 支持 MIG 吗？
NVIDIA 列出 H200 SXM 和 H200 NVL 最多可提供七个 MIG 实例，每个实例列出的内存大小不同。当您需要硬件支持的内存隔离和故障隔离时，请使用 MIG。需要这些隔离属性时，请不要以时间切片替代它。
我需要多少块 H200 GPU？
从能够通过代表性内存、延迟、吞吐量和恢复测试的最小配置开始。仅当内存预算、副本数量或已验证的并行化方案需要时再增加 GPU。没有考虑互连架构的工作负载，即使增加更多 GPU，也可能只会增加成本和运维复杂度，而无法改善面向客户的结果。
从经过验证的 H200 GPU 试点开始
合适的 H200 GPU 部署是一个经过度量的系统：加速器内存、拓扑、调度器、运行时、数据路径、可观测性和工作负载经济性都需要保持一致。先从具备监测能力的试点开始，重放真实流量，记录故障模式，并且仅在证据支持下一步容量扩展后再进行扩容。
