企业官网建设流程全解析

简介：这份 NVIDIA H100 Tensor Core GPU 官方 Datasheet 面向数据中心架构师、AI 算法工程师与高性能计算方向的学习者，用精简的规格资料说明 Hopper 架构强在哪里，以及该如何选型与部署。压缩包中仅包含 1 个 PDF 文件，共 402KB，轻量易读，可直接在本地或移动端翻阅。内容围绕 Hopper 架构展开：第四代 Tensor Core 与支持 FP8 精度的 Transformer Engine，让 GPT-3 175B 训练比上代快 4 倍、大模型推理最高提升 30 倍；双精度 Tensor Core 提供 60 TFLOPS 的 FP64 算力，DPX 指令带来最高 7 倍加速；还涵盖第二代 MIG、机密计算与 NVLink Switch 系统，以及 H100 NVL 的 188GB HBM3 内存，和 Llama 2 70B 相较 A100 约 5 倍的性能表现。文中的对比曲线与官方参数表可直接用于方案汇报、硬件选型比价与教学讲义引用，目前已有 627 人学习下载。

1. 数据手册不是宣传页：先弄清 H100 的两条产品线

H100 datasheet 我前后翻过很多遍。第一遍只记住了几个数：FP8 3958 TFLOPS、80GB HBM3、700W。真正拿着它去和 A100 的报价单、机柜配电表对照时才发现，这份文档最该读的不是那张算力表，而是它把 GPU 拆成了 SXM 和 NVL 两条完全不同的产品线——同样是 H100，显存、带宽、互联、功耗、能插进什么机器，全都不一样。

这篇就从这份数据手册出发，讲清楚三件事：SXM 和 NVL 该怎么选，A100 换 H100 的收益边界在哪里，以及纸面参数落到机房时会翻车的几个地方。做过一次 GPU 选型评审、或者正准备给推理集群加卡的人，可以照着往下看。

2. H100 SXM 与 H100 NVL 怎么选：四个硬指标拆开看

同一个型号名下面藏着两种物理形态，这是选型时最容易含糊过去的地方。数据手册把两者的规格并列摆出来，看着像同一个东西的两种配置，实际用起来是两条路：一条通往 8 卡整机、液冷或高风冷机柜、700W 级别的功率密度；另一条通往标准 PCIe 双槽、350 到 400W、可以直接塞进已有服务器。选错不是性能差一点的问题，是整机方案推倒重来。

2.1 显存与带宽：80GB 对 94GB 背后的账

手册上 H100 SXM 是 80GB HBM3、3.35TB/s，H100 NVL 是 94GB、3.9TB/s。单看这两个数，很容易得出“NVL 显存更大所以更划算”的结论，但真正的关键数字是另一个：NVL 双卡通过 NVLink 桥接，合计 188GB HBM3。

这两件事的区别在于，188GB 不是一张卡能用的显存。你在单卡上分配张量，能用的上限仍然是 94GB；只有当你把模型按张量并行切开、让两张卡通过桥接高速交换时，才用得上那 188GB 的合并容量。规划的时候我一般按下面这个顺序算账：

按这张表，70B 的 FP16 权重就要 140GB，单卡 80GB 或 94GB 都放不下，必须多卡切分。这时候 NVL 双卡 188GB 的意义才显出来：两张卡合起来刚好能装下权重，还留出 KV Cache 的空间，不用再往上堆第三、第四张卡。

这里有个常见误判：把 188GB 当成“单卡显存”，于是按 188GB 去规划单卡能装的模型规模。跑起来才发现框架只认 94GB，一切照旧。我一般会先问一句：这个模型是打算单卡装，还是两张卡张量并行装？答案不同，选型结论直接反过来。

带宽这 3.9TB/s 对 3.35TB/s 的差距，在 decode 阶段比在 prefill 阶段更明显。推理的瓶颈往往不在算力，而在每生成一个 token 都要把权重从显存搬一遍，这时候带宽就是主要限制。如果负载是长上下文、低并发的对话服务，带宽的权重可以往上调；如果是大批量离线训练，算力和互联的权重更高。

2.2 算力与精度：从 FP64 到 FP8 的完整梯队

数据手册给的算力是一整条梯度，从 FP64 一直排到 INT8，中间还有 TF32、BFLOAT16、FP16、FP8。把 SXM 和 NVL 两列并排看，NVL 的每一项都比 SXM 低一档，大概在 84% 到 90% 之间。这个比例关系比绝对值更有用，因为它告诉你：同一份模型代码，换成 NVL 形态，算力侧的成本大致怎么变。

看这张表有两个必须注意的地方。

第一个是脚注。表里 TF32 往下的几行，数字后面跟着“With sparsity”——这些是稀疏算力。稠密算力要把数字砍一半，FP8 的 3958 对应稠密大约 1979。这是最容易翻车的一处：拿稀疏峰值去估训练时间，估出来的结果乐观得离谱，真跑起来发现差了一倍，还以为是框架没调好。我一般估时间会先用稠密数字，跑完基准再决定要不要赌稀疏加速。

第二个是 FP64 这条线为什么单独列了两行。FP64 34 TFLOPS 是通用向量单元的数字，FP64 Tensor Core 67 TFLOPS 是张量核心跑双精度的数字。HPC 代码如果没走 Tensor Core 路径，吃到的就是前者。所以在科学计算场景里，光看“FP64 提升三倍”这句话是不够的，得确认自己的算子能不能落到 Tensor Core 上。

精度梯队还决定了一件事：你的训练框架能不能用上 FP8。用不上，就只能看 BF16 那 1979 这一行；用上了，才有机会碰 3958。这中间的差距不是调参能补的，是代码路径问题。

2.3 互联与形态：900GB/s 的 NVLink 和 PCIe 双槽

互联这块，SXM 给的是 900GB/s 的 NVLink，NVL 是 600GB/s。两者都支持 PCIe Gen5 的 128GB/s。单看数字，900 对 600 是 1.5 倍，但真正拉开差距的是 NVLink Switch System：跨服务器、跨节点，每 GPU 双向 900GB/s，手册里写的是 PCIe Gen5 带宽的 7 倍以上，比上一代集群网络方案的带宽高 9 倍。

这句话对训练任务的意义在于，张量并行和数据并行都要跨卡通信，通信一旦成为瓶颈，加卡就是加等待。175B 级别的模型训练，通信占比本来就高，互联带宽不够，GPU 利用率会一直卡在低位。手册里那张相对性能图上标的“集群网络 HDR 对 NDR”的注释，说的就是这件事——性能数字不是单卡跑出来的，是整个集群网络配置跑出来的。

形态上的差别更硬：

• SXM是板载模块，必须装在 4 卡或 8 卡的模组化整机里，8 卡整机形态是标配。它不能单独买一张插进已有服务器。
• NVL是 PCIe 双槽、风冷，通过合作认证的服务器出货，可以是 4 卡或 8 卡的配置。

这意味着选型的第一步不是比参数，而是问一句：机房现有的服务器能不能插？能插，NVL 这条路省掉了整机采购和上架周期；不能插，就得走整机方案，选型范围直接从“加几张卡”变成“换一批机器”。

我见过一种情况：预算按单卡批下来，实施时才发现要配套整机、交换机、机柜改造，总价翻了一截。所以选型评审的时候，互联和形态这两栏我一般放在算力前面看，先把物理可行性钉死，再谈性能。

2.4 功耗与 MIG：700W 与 350-400W 的机房代价

功耗这栏是很多人扫一眼就跳过的，但它往往决定项目能不能按时上线。SXM 的 TDP 是可配置的，最高 700W；NVL 是 350 到 400W 可配置。

单卡差 300W 听起来不多，8 卡就是 2.4kW 的差距，再算上 CPU、网卡、风扇和电源转换损耗，一个机柜的功率密度规划要重做。更现实的问题是散热：700W 级别的模块基本要走高风冷或者液冷，机房如果还是老的风冷架构，加卡之前得先改基础设施。这不是玄学，是排期表上实打实的几个月。

MIG 这块，两者都支持第二代多实例 GPU，最多切 7 个实例。SXM 是每个实例 10GB，NVL 是每个实例 12GB。7 乘 10 是 70GB，7 乘 12 是 84GB，都不等于整卡显存，剩下的部分留给系统和运行时开销。

MIG 的价值在隔离：把一张卡切成多个独立实例，分给不同租户或不同任务，彼此不干扰，QoS 可控。如果场景是多用户共享的开发平台、或者需要按租户售卖算力的环境，MIG 是必选项；如果是单一大模型独占训练，MIG 基本用不上，切了反而损失整体吞吐。

这里有个容易忽略的点：切了 MIG 之后，各实例共享的是同一份显存带宽和同一块缓存。7 个实例跑满的时候，单个实例的感受带宽不是整卡的七分之一，而是更复杂的一个值。压测的时候我一般会把 7 个实例同时打满，看最慢那个的延迟，而不是看平均值。

3. A100 换 H100 的收益边界：哪些工作负载真能吃到那 30 倍

数据手册上最显眼的几个数字是 30X、4X、9X、7X。这些数字都有明确的前提条件，写在图注的小字里。跳过小字直接拿去写立项报告，后面验收时对不上账，是要担责任的。这一章把几个主要场景的收益来源拆开，讲清楚什么条件下能吃满，什么条件下只能吃到一部分。

3.1 GPT-3 175B 训练：4 倍的来源是 FP8 而不是魔法

手册给的结论是：第四代 Tensor Core 加上带 FP8 精度的 Transformer Engine，相比上一代，GPT-3 175B 模型的训练速度最高提升 4 倍。

这 4 倍的构成，拆开看主要是两块。一块是 FP8 带来的算力密度提升，从 BF16 的 1979 到 FP8 的 3958，纸面上是两倍；另一块是 Transformer Engine 的调度能力，它会在每一层动态选择用 FP8 还是 FP16，把精度敏感的部分留在高精度上，其余部分压到低精度。

也就是说，这 4 倍不是“换卡就自动到账”的。前提是你的训练代码路径能走到 Transformer Engine 上。如果框架版本、算子实现或者自定义层不支持，实际跑的还是 BF16，那能拿到的就只是第四代 Tensor Core 相对上一代的那部分提升，和 4 倍差得很远。

我的判断方法是：先在目标框架上跑一个小规模的基线，把 loss 曲线和 A100 上的结果对齐，确认收敛行为没有异常，再逐步放大模型规模。跳过这一步直接上全量，一旦 loss 出现抖动，排查成本会高得多——你分不清是精度问题、并行策略问题还是数据问题。

还有一个前提条件藏在图注里：这些相对性能是在特定集群网络配置下测出来的。175B 训练是跨节点任务，网络配置不同，结果会差不少。评审时我一般会要求供应商把测试环境的网络配置写清楚，不然这个 4 倍没法复现。

3.2 推理与 MoE：30 倍、9 倍这些数字的适用条件

推理侧的 30X 是手册里最大的数字，对应的是“最大模型上的 AI 推理性能”。同一个图里还有 Megatron 530B 参数模型对话机器人的推理数据，图注写明：输入序列长度 128，输出序列长度 20。

这两个数字很关键。128 进、20 出，是典型的短输入、短输出场景，prefill 阶段很轻，大头在 decode。这种负载下，显存带宽和单 token 的生成效率是主要因素，正好是 H100 加 NVLink Switch System 组合最擅长的部分。

如果你的实际负载是长上下文——比如几万 token 的文档问答、代码补全——那么 prefill 阶段的算力占比会大幅上升，收益结构和这个 30X 对不上。这不是说 H100 不行，而是说你不能拿 30X 去估你的长上下文场景，估出来一定是错的。

MoE 那边，Switch-XXL 395B 参数、1T token 数据集，相对 A100 集群是 9 倍（带 NVLink Switch System）。MoE 的特点是专家并行，通信模式比稠密模型复杂得多，对互联的敏感度更高。这也解释了为什么这个数字要标注“带 NVLink Switch System”——不带的话，通信会成为明显的瓶颈。

我在做容量规划时的习惯是：把手里的负载按输入输出长度分成两三类，每一类单独估，而不是用一个笼统的倍数乘上去。短输入短输出的对话服务，可以往手册的高倍数靠；长上下文和批量离线任务，得打个折重新算。这样出来的预算虽然不好看，但上线后不会被打脸。

3.3 HPC 场景：FP64 三倍与 DPX 的 7 倍

科学计算这条线，手册给的是：双精度 Tensor Core 的 FLOPS 提升到上一代的三倍，提供 60 TFLOPS 的 FP64 计算能力；同时 DPX 指令让动态规划类算法相对上一代 GPU 提升最高 7 倍，相对 CPU 提升 40 倍。

这两句话对应的是两类完全不同的代码。前一句说的是传统的稠密线性代数——矩阵乘、分解、求解，只要算子能落到 Tensor Core 上，就能吃到三倍。后一句说的是动态规划类算法，比如序列比对里的 Smith-Waterman、路径规划、图分析，这类算法分支多、数据依赖强，本来就难并行，DPX 指令是专门为这类模式做的加速。

手册里提到的两个例子很说明问题：3D FFT（4K³）和基因组测序。这两个都是典型的 HPC 负载，一个吃浮点吞吐和互联，一个吃动态规划指令。如果你的 HPC 应用是分子动力学或者流体仿真，重点看 FP64 和互联；如果是生物信息、路径优化，重点看 DPX。

这里有个选型上的实操建议：先把自己的热点函数做一次 profile，看看时间花在哪种模式上。花在矩阵乘上的部分，换卡收益直接；花在分支密集的循环上的部分，得看能不能改写成 DPX 友好的形式，改不动的话，那 7 倍跟你没关系。这一步做完，再谈买几张卡才靠谱。

4. 把纸面参数落到机房：三个容易被忽略的工程约束

参数表看懂了，不代表方案就能跑起来。从数据手册到实际部署，中间隔着精度校准、显存规划、多租户隔离这几道关。这几件事在手册里都只有一两句话，但在工程上各占一块时间。下面三节按我实际踩过的顺序讲。

4.1 Transformer Engine 与 FP8：精度损失的判断方法

Transformer Engine 的做法是混合 FP8 和 FP16，由软件决定每一层用哪个精度。手册里这句话写得很轻，落地时它意味着：你需要一套机制来判断“这一层压到 FP8 会不会出问题”。

比较稳的做法是三步。第一步，用 BF16 或 FP16 跑一个短程基线，记录 loss 曲线和几个关键中间层的数值分布。第二步，打开 FP8 再跑一遍同样的步数，把两条 loss 曲线叠在一起看。如果前几百步偏差在噪声范围内，基本可以放心；如果出现系统性偏移或者抖动，就要往回找是哪一层的问题。第三步，针对出问题的层做局部回退，而不是整体退回 FP16——整体回退等于放弃了 FP8 的收益。

常见的错误是直接上全量 FP8 训练，看到 loss 不对就判定“FP8 不能用”。实际上多数情况是个别层对精度敏感，或者是缩放因子的更新策略不匹配，而不是整个方案不可行。

还有一点：FP8 的收益在训练和推理上不一样。训练侧主要是算力密度，推理侧还要看权重能不能量化到 FP8、KV Cache 是否保持高精度。推理场景做 FP8 之前，我一般会先拿一批真实请求做 A/B，对比输出质量，而不是只看吞吐。

4.2 70B 模型的单机方案：188GB HBM3 意味着什么

手册对 NVL 给了一个很具体的场景：70B 参数以内的模型（举的例子是 Llama 2 70B），PCIe 形态加 NVLink 桥接、Transformer Engine、188GB HBM3，能在任何数据中心里提供不错的性能和扩展性。配了 NVL 的服务器，相对 A100 系统在 70B 模型上性能最高 5 倍，同时在功率受限的环境里保持低延迟。

这段话里有三个关键信息。第一，188GB 是双卡合计，70B 模型 FP16 权重约 140GB，双卡装得下，这是它能“单机跑 70B”的物理基础。第二，5 倍是相对 A100 系统，不是相对单卡，比的时候要看清分母。第三，功率受限环境是个明确限定——这正好对应 NVL 350 到 400W 的功耗设计。

所以这个方案真正适合的场景是：机房功率密度上不去、又需要在本地跑 70B 级别模型的推理服务。如果是训练，70B 全参训练双卡肯定不够，得看更大的集群方案。

另外，NVL 附带五年的企业级 AI 软件订阅，里面包含一套微服务组件，用来加速生成式 AI 的部署，覆盖计算机视觉、语音、检索增强生成这些场景。这块在选型时容易被当成赠品忽略，但如果团队本来就要自己搭推理服务框架，这套东西能省不少工程时间；如果已经有成熟的自研栈，它的价值就要重新评估。我一般会问：这套软件里的组件，和我们现有的推理框架重叠多少？重叠高的部分，订阅的边际价值就低。

4.3 机密计算与第二代 MIG：多租户下的隔离账

机密计算这块，手册的说法是给工作负载提供机密性和完整性，用硬件级保护覆盖“使用中”的数据和应用。这句话的技术含义是：数据在内存里解密使用的时候，也在保护范围内，而不只是传输和存储时加密。

对什么场景有用？多租户环境、受监管行业、跨机构联合建模。比如几个机构一起训一个模型，谁都不想把自己的原始数据暴露给基础设施方，机密计算就是为这种需求准备的。反过来说，如果是单一团队独占的集群，这个特性基本用不上，选型时不必为它付溢价。

第二代 MIG 和机密计算经常一起出现，因为它们解决的是同一类问题：隔离。MIG 把一张卡切成多个独立实例，每个实例有自己的显存分区，QoS 可控；机密计算保证即使基础设施层也看不到实例里的数据。两者叠加，才构成完整的“可信多租户”。

这里有个成本账要算清楚。切 MIG 之后，每个实例的算力和带宽都是整卡的一部分，整体吞吐通常低于整卡跑单个任务。如果你的业务是多租户、需要按租户隔离和计费，这个损失是必要成本；如果是单一业务独占，切 MIG 纯属自找麻烦。我在评审时会把“是否需要按租户隔离”作为一个独立的决策项，而不是当成默认配置。

5. 采购和上线阶段最常见的六个坑：逐条排查

前面讲的是怎么比、怎么算。这一章讲的是比完之后依然会出问题的地方，都是我或者身边人真实踩过的。每条按现象、原因、解决三段写，看到相似现象可以直接对号。

5.1 选型阶段的三条

第一条：拿稀疏算力估训练时间，结果差一倍。

现象是方案里写的训练周期很乐观，实际跑起来慢一倍，团队开始怀疑框架和并行策略。原因是数据手册表格里从 TF32 往下的几行都带“With sparsity”脚注，那是稀疏算力，稠密负载要减半。解决办法很简单：估时间一律先用稠密数字，跑完基准测试确认稀疏加速真的生效了，再考虑要不要按稀疏值算。

第二条：把双卡合计显存当成单卡显存规划。

现象是按 188GB 规划了一个模型，部署时框架报显存不足，实际可用只有 94GB。原因是 188GB 是 NVL 双卡通过 NVLink 桥接的合计容量，单卡上限还是 94GB。解决办法是在规划表里把“单卡可用显存”和“多卡合计显存”分成两列写，模型能不能装下，先看单卡那一列。

第三条：只看单卡 TDP，没算整机功率。

现象是机器上架后频繁降频，或者配电告警。原因是 700W 只是 GPU 模块的 TDP，整机还有 CPU、内存、网卡、风扇，8 卡整机的峰值功耗远高于 8 乘 700。解决办法是按整机峰值功率加冗余来规划机柜，同时确认散热方案——高风冷还是液冷，这个决定要提前几个月做，不是上架前一天能改的。

5.2 部署阶段的三条

第四条：以为 SXM 能插进已有服务器。

现象是卡到了，机箱装不进去。原因是 SXM 是板载模块，必须配 4 卡或 8 卡的模组化整机，不是标准 PCIe 插卡。解决办法是在选型第一轮就把形态确认下来：现有服务器能插 PCIe 双槽的，走 NVL；要走 SXM，就得连整机一起规划。

第五条：直接开 FP8 不做精度校验。

现象是训练 loss 抖或者收敛变慢，团队判定 FP8 不可用。原因是个别层对精度敏感，或者缩放因子策略没匹配上，不是整个方案不能用。解决办法是先跑 BF16 基线，再跑 FP8 对比 loss 曲线，定位到具体层做局部回退，而不是一刀切退回高精度。

第六条：切了 MIG 之后按线性比例估性能。

现象是切了 7 个实例，以为每个能拿到七分之一性能，实测下来对不上。原因是各实例共享同一份显存带宽和缓存资源，负载打满时互相影响。解决办法是按 QoS 目标做压测——7 个实例同时满载，看最慢那个的 P99 延迟，用这个数去定 SLA，而不是用理论切分值。

6. 一张表收口：不同场景该配哪种 H100，以及我的验收习惯

把前面几章压成一张决策表，选型会上可以直接对着走：

这张表能解决“买哪种”的问题，解决不了“买回来能不能兑现”的问题。后者靠验收。我现在做 GPU 选型，会强制走一遍自己的验收清单：先拿真实负载的一小段跑基准，不看厂商给的倍数，看自己测出来的吞吐和延迟；再对比稠密和稀疏两种模式的实际差距，确认稀疏加速真的生效；最后把 7 个 MIG 实例同时打满，看最慢实例的延迟曲线。

这套习惯是被坑出来的。早些年做一次集群扩容，方案是照着峰值算力写的，验收时只跑了单卡的基准，结果上生产后多租户一挤，延迟指标全线超标，回头查才发现问题是共享带宽被吃满，而不是算力不够。从那以后我每次做容量规划，都强制把“多租户同时打满”这一项单独跑一遍，谁也不许跳过。

数据手册是一份很好的起点，但它写的是上限和条件，不是你的场景。把条件读出来，把上限打个折，再用自己的负载验证一遍，这三步走完，选型才算落地。这份 H100 数据手册值得留在本地，每次做 GPU 相关的评估前翻一翻，尤其是那些图注里的小字——真正的信息往往在那儿。希望帮到你。

本文还有配套的精品资源，点击获取