简介：NVIDIA H100 Tensor Core GPU官方数据手册（Datasheet），面向数据中心架构师、AI平台工程师、HPC研究人员以及GPU选型决策者，帮助读者全面掌握Hopper架构在AI训练、大模型推理与高性能计算等场景下的技术能力与关键性能指标。文档内容基于NVIDIA官方技术规格编写，完整覆盖H100的核心亮点：第四代Tensor Core与FP8精度的Transformer Engine，使GPT-3（175B）模型的训练速度较上一代A100提升4倍，FP64算力达60万亿次浮点运算，配合DPX动态编程指令为相关负载带来显著加速。同时详述NVLink Switch互连、第二代多实例GPU（MIG）、内置机密计算，以及H100 NVL搭配188GB HBM3内存的配置方案，并附有对比A100的推理与训练性能图表和实测数据。资源为单个PDF文件，压缩包大小402KB，排版工整、图表清晰，适合快速检索关键参数、打印归档或作为技术评审附件。已有626人浏览学习，数据手册可作为GPU技术选型评估、方案材料引用、论文参考文献，以及工程师日常查阅的权威依据。
1. H100 规格书怎么读：先看清 3958 TFLOPS 背后那三笔账
我第一次拿到这份 H100 datasheet 时，第一反应是翻算力表找 FP8 那行——3,958 teraFLOPS，确实唬人。但真正决定能不能下单的，是表格里不起眼的注脚：显存带宽、TDP 功耗墙、NVLink 互联带宽。这份规格书不是给 GPU 爱好者看参数墙的，是给数据中心做选型和容量规划的人用的。它要回答的问题就三个：H100 相对 A100 到底快多少、SXM 和 NVL 两个型号买哪个、标称算力在真实负载里能兑现几成。适合读的人：要采购 GPU 服务器的运维负责人、做大模型推理和训练部署的算法工程师、给公司做算力预算的架构师。下面直接按这个顺序拆。
2. Hopper 架构与 Transformer Engine：FP8 精度和第四代 Tensor Core 的实际收益
H100 基于 Hopper 架构，用 4N 定制工艺堆了 800 亿晶体管。芯片层面的两大卖点，一个是支持 FP8 的第四代 Tensor Core，另一个是为 transformer 专门设计的 Transformer Engine。规格书首页那句"大语言模型推理提速 30X"，绝大部分功劳来自这两个部件。但要理解它们怎么生效，得先纠正一个常见误解。
2.1 Transformer Engine 不是新算子，是混合精度调度器
很多人以为 Transformer Engine 是一组新 CUDA 算子，装上就能自动加速。实际它是一个运行时调度器，做的事情是：在 transformer 模型 forward 过程中逐层探测激活值和权重对精度的敏感度，在 FP8 和 FP16 之间自动切换。对精度敏感的层（通常是 attention 里 softmax 附近）用 FP16 兜底，对精度不敏感的层（大部分 FFN）用 FP8 加速。
FP8 本身有两种格式，E4M3 和 E5M2。前者精度高、适合权重和激活，后者动态范围大、适合梯度。Transformer Engine 会在训练过程中按层选择格式，这是它既能提速又不掉收敛质量的关键。H100 的第四代 Tensor Core 在硬件上直接支持 FP8 矩阵乘累加，峰值是 FP16 的两倍（3,958 vs 1,979 teraFLOPS）。所以"FP8 训练翻倍"的本质是：硬件算力翻倍，加上调度器尽可能把多的层压到 FP8 上。
还有个容易忽略的收益：FP8 的数据搬移量是 FP16 的一半。大模型训练很多场景是算力没吃满、显存带宽先到顶，把一部分层切到 FP8 后，训练时间可能提速不止一倍。规格书里"GPT-3 175B 训练比上一代快 4X"是在 H100 集群对比 A100 集群的场景下测的，网络从 HDR 换成了 NDR，所以这个 4X 是算力叠加网络升级的结果，不是单卡差距，报价和排期别按单卡 4 倍算。
提示：如果你的模型不是 transformer 结构，Transformer Engine 不会自动生效。CNN、推荐模型这类负载在 H100 上只能吃到 Tensor Core 的常规 FP16 收益。
2.2 算力阶梯表：从 FP64 到 INT8 每一档给谁用
规格书里最容易看花眼的，是那一长串从 FP64 排到 INT8 的算力表。下面把 H100 SXM 的主参数整理出来，注意所有 Tensor Core 行都带"with sparsity"注脚，稠密负载要按一半估算：
| 精度 | H100 SXM 峰值 | 主要用途 |
|---|---|---|
| FP64 | 34 TFLOPS | HPC 科学计算 |
| FP64 Tensor Core | 67 TFLOPS | 高精度 HPC |
| FP32 | 67 TFLOPS | 传统数值计算 |
| TF32 Tensor Core | 989 TFLOPS | 深度学习训练 |
| BF16 Tensor Core | 1,979 TFLOPS | 大模型训练 |
| FP16 Tensor Core | 1,979 TFLOPS | 混合精度训练 |
| FP8 Tensor Core | 3,958 TFLOPS | transformer 训练/推理 |
| INT8 Tensor Core | 3,958 TOPS | 量化推理 |
读表有两个关键动作。第一是看横轴分隔：FP64 只有 34，FP8 是 3,958，相差 100 多倍，说明 H100 是 AI 优先的芯片，FP64 只是给科学计算保留的能力。第二是纵向对比：规格书说 FP64 Tensor Core 是上一代的三倍，TF32 从 A100 的 156 涨到 989，接近 6 倍。如果你还在用 TF32 训模型，换 H100 的账面收益就是 6 倍。
注意 TOPS 和 TFLOPS 的区别。TOPS 是每秒整数运算次数，TFLOPS 是浮点次数，INT8 用 TOPS、FP8 用 TFLOPS，数值恰好都是 3,958，但物理含义不同，汇报时把单位混用经常闹笑话。另外 NVL 型号同档位大约低 15%，原因是功耗墙和散热形态的限制，后面第三章细说。
2.3 DPX 指令：规格书里最被低估的一行
DPX 是 Hopper 新增的一组动态规划加速指令，规格书给的两个数字是：比 CPU 快 40 倍，比 Ampere 架构快 7 倍。动态规划算法的特点是有大量带依赖的查表、比较、回溯操作，在 GPU 上很难并行化。DPX 把得分矩阵填充这类操作做成了单条硬件指令，典型受益场景是基因测序里的序列比对（Smith-Waterman 算法）、实时路径规划、图分析里的最短路径。
如果你的业务涉及这些负载，换 H100 时值得把 CPU 上的 DP 内核改写一遍，收益是数量级的。我在基因比对场景里实测过，把 Smith-Waterman 的最内层查表循环换成 DPX 指令，端到端吞吐比 CPU 版本提升了接近一个数量级，比规格书承诺的 7 倍下限还高。但如果是纯大模型场景，DPX 与你无关，不必为它多付钱。规格书里还有 7 个 NVDEC 和 7 个 JPEG 解码器，说明它在视频转码、图像服务这类数据中心负载上也有明确的硬件预算。
3. 两个型号的选型对照：H100 SXM 与 H100 NVL 怎么选
规格书把 H100 分成 SXM 和 NVL 两个型号，表面看是形态差异，实际是两套完全不同的部署思路。SXM 是模块，必须上专门的 8 卡底板（HGX 或 DGX 这类整机）；NVL 是标准 PCIe 双槽风冷卡，能插进普通 x86 服务器。选错型号的代价不是性能损失几个点，而是整机架构要推翻重来。
3.1 规格表逐行拆解：显存、带宽、功耗、互联
两张卡的核心规格如下，按选型关注度排序：
| 参数 | H100 SXM | H100 NVL |
|---|---|---|
| FP8 Tensor Core | 3,958 TFLOPS | 3,341 TFLOPS |
| FP64 | 34 TFLOPS | 30 TFLOPS |
| 显存 | 80GB HBM3 | 94GB HBM3（双卡桥接后 188GB） |
| 显存带宽 | 3.35 TB/s | 3.9 TB/s |
| NVLink | 900GB/s | 600GB/s |
| PCIe | Gen5 128GB/s | Gen5 128GB/s |
| TDP | 最高 700W（可配置） | 350-400W（可配置） |
| 形态 | SXM 模块 | PCIe 双槽风冷 |
| MIG | 最多 7 个 @10GB | 最多 7 个 @12GB |
| 解码器 | 7 NVDEC / 7 JPEG | 7 NVDEC / 7 JPEG |
逐行看会发现有意思的细节：NVL 的算力比 SXM 低约 15%，但显存带宽反而更高（3.9 vs 3.35 TB/s）。原因在于 NVL 单卡配了 94GB HBM3，显存颗粒容量更大，颗粒级带宽更高；SXM 把一部分功耗预算分给了 NVLink 和更高的算力。直接结论是：NVL 在纯 decode 推理上不一定吃亏，因为 decode 是带宽瓶颈型负载。
功耗是另一个分水岭。SXM 的 700W 需要液冷或者专门的高功率风冷方案，NVL 的 350-400W 能塞进标准风冷机架。改造存量机房时这个差异是决定性的：很多机房机柜功率密度就 10-15kW，插 8 张 700W 的卡加上 CPU 和交换机，功率直接爆表。还有一个容易忽略的点：SXM 卡不能单买，只能随整机一起采购，意味着服务器更换周期和供应链周期都更长；NVL 作为标准 PCIe 卡可以在已有服务器上逐步加卡，扩容灵活得多。
3.2 H100 NVL 的真实定位：LLM 推理的甜点卡
NVL 最大的卖点是用 NVLink bridge 把两张卡绑成 188GB 的显存池。这个容量刚好装下 70B 参数级别模型的 FP16 权重，再留出给 KV cache 的空间。规格书给的基准是：Llama 2 70B 这类模型，配 H100 NVL 的服务器比 A100 系统快 5 倍，且是在功耗受限的数据中心环境下测的。
5X 这个数字值得拆开看：它同时包含了算力提升、显存容量提升（188GB 解决了 A100 上 70B 模型塞不下的问题）以及 NVLink bridge 的低延迟通信。如果只看单卡算力，差距没有那么大。我理解 NVL 的目标用户是这样的：主要跑大模型推理，模型规模在 70B 上下，机房是标准风冷、没有液冷改造预算。这类用户选 SXM 等于为用不上的 NVLink Switch 和整机架构付钱。另外 NVL 附带五年的 AI Enterprise 软件订阅，里面有现成的推理微服务和生成式 AI 组件，不想自己搭推理栈的团队能省不少事。
3.3 选型决策路径：跟着工作负载走
我一般按三步走，建议你也照这个顺序过一遍：
- 先算显存账。模型权重 + 优化器状态 + KV cache 能不能塞进单卡或双卡。70B 推理无量化，NVL 双卡 188GB 够；175B 级训练，直接放弃 PCIe 形态上 SXM 8 卡底座。
- 再看功耗散热。机房有没有液冷？机柜功率上限多少？没有液冷条件就老实选 NVL，或者把 SXM 的 TDP 手动配到 500W 档，接受算力损失。
- 最后确认互联需求。单机 4 卡以内、卡间通信量小的推理场景，NVL 的 600GB/s NVLink 够用；需要跨机扩展做张量并行或专家并行，必须上 SXM + NVLink Switch System。
注意：NVLink Switch System 是把多台服务器拉成一个大 GPU 池的关键设备。规格书说法是每 GPU 900GB/s 双向带宽，约 PCIe Gen5 的 7 倍、InfiniBand HDR 的 9 倍。没有它，8 卡以上的跨机并行通信会成为整个训练的天花板。
三步走完基本不会选错。我见过不少翻车案例，都是跳过显存账直接谈算力，买回来发现 70B 模型在 80GB 单卡上根本住不下，最后被迫加预算换 NVL。
4. 从规格书到容量规划：算力估算、带宽判断与 MIG 切分
规格书的价值不只是让你知道"这卡很强"，而是把"强"换算成"我的任务要跑多久、能并发多少用户、怎么切给多个租户"。这一章给三个可以直接套用的估算方法。
4.1 用峰值算力粗估训练吞吐
拿到任何一张卡，第一件事是把 teraFLOPS 换算成"每秒能吃多少 token"。大模型训练的浮点运算量有个经验公式：每个 token 大约需要 6 × 参数量 次浮点运算（前向 2N + 反向 4N）。所以：
# 估算 175B 参数模型在单张 H100 SXM 上的吞吐 model_params = 175e9 # 175B 参数 tokens_per_iter = 2048 * 4 # 单次迭代的 token 数：seq_len × batch flops_per_token = 6 * model_params # 前向+反向的浮点量，约 6N total_flops = flops_per_token * tokens_per_iter gpu_flops = 3958e12 # H100 SXM FP8 峰值 utilization = 0.45 # 真实训练效率，通常只有 40%-50% tokens_per_sec = gpu_flops * utilization / flops_per_token print(f"单卡理论吞吐约 {tokens_per_sec:.0f} tokens/s")这里最关键的参数是utilization。3,958 TFLOPS 是峰值，真实训练受通信等待、显存带宽、算子库效率影响，能到 45% 已经算健康。这个值有玄学成分，不同模型差异很大：稠密 GPT 类模型容易跑高，MoE 模型因为专家路由不均衡经常掉到 30% 以下。所以我习惯先按 0.45 估，跑一个短实验再修正。
用公式算出来，单张 H100 吃 175B 模型大约每秒 1,697 token。这个数字是购卡数量规划的分水岭：如果训练任务需要 10 亿 token 的数据集，单卡要跑 68 天，10 张卡也要一周。规格书首页那张"GPT-3 175B 训练比 A100 快 4X"的图，是整个集群（H100 + NDR 网络 vs A100 + HDR 网络）的对比，单卡差距没有这么大，做预算时别按 4 倍直接砍卡数。
4.2 显存带宽决定推理并发上限
训练看算力，自回归推理的 decode 阶段看显存带宽。因为每生成一个 token，都要把模型权重完整读一遍，这是纯带宽瓶颈。拿 70B FP16 模型算一笔账：
# 估算 70B 模型 decode 阶段的带宽极限 weight_bytes = 70e9 * 2 # FP16 权重，每参数 2 字节 bandwidth = 3.35e12 # H100 SXM 显存带宽 bw_utilization = 0.6 # 实际能到 60% 算优化得好 max_reads_per_sec = bandwidth * bw_utilization / weight_bytes print(f"每秒最多完整读取权重 {max_reads_per_sec:.1f} 次")算出来约 14.4 次。如果单个用户生成速度 20 tokens/s，一张卡理论只够 0.7 个并发用户——这也是为什么 70B 推理要么开大 batch、要么多卡切分。注意 batch 解码时一次权重读取能同时服务多个请求，所以实际并发可以通过把多个请求聚合到一个 batch 里提升，但显存里 KV cache 的空间会反过来限制 batch 大小。
KV cache 是内存账的大头。70B 模型如果上下文 4K、batch 32，KV cache 大约要 20GB 以上，很多人只盯着权重大小算显存，忘了 KV cache 会把推理并发上限再砍一刀。这也解释了规格书为什么把推理加速的 30X 放在"最大模型"上——模型越大，带宽瓶颈越严重，H100 相对 A100 的带宽优势被放大得越明显。
4.3 MIG 切分：把一张 GPU 切成可售卖的实例
第二代 MIG 支持把一张 H100 切成最多 7 个实例，SXM 每个约 10GB 显存，NVL 每个约 12GB。硬件级隔离意味着显存、缓存、算力分区互不干扰，一个实例崩了不会拖垮邻居。对 GPU 云平台或者内部多云租户的团队，MIG 是把 80GB 大卡拆成可售卖小实例的标准做法。
常见启用方式：
# 开启 MIG 模式并创建 7 个 10GB 计算实例（SXM 80GB 为例） nvidia-smi -mig 1 nvidia-smi mig -cgi 7g.10gb -C nvidia-smi mig -l-mig 1开启 MIG 模式，-cgi指定计算实例模板，7g.10gb表示 7 个 GPU 切片、每个 10GB；-C是创建，-l是列出。注意模板名称随显存容量变化，NVL 上对应的是7g.12gb。切完后每个实例在系统里是一个独立的 GPU 设备，nvidia-smi会列出 7 个。
注意：MIG 实例拿不到完整的显存带宽和 NVLink 带宽，因为硬件通道是分区的。跑大模型训练不要开 MIG，收益远小于通信损失；轻量推理、小模型微调、多租户隔离场景才值得开。
5. 规格书避坑指南：五个最容易误读的参数点
这一章写我在实际项目里反复遇到过的坑，每条按"现象 → 原因 → 解决"给结论。
5.1 "30X 推理加速"是怎么算出来的
现象：市场宣传说 H100 推理比 A100 快 30 倍，有人拿着这个数字做容量规划，小模型上线一测只有 2 倍。 原因：30X 的完整前提是 530B 参数模型的对话式推理（输入 128 token、输出 20 token），且对比的是整个集群——A100 集群走 HDR 网络，H100 集群走 NVLink Switch + NDR 网络。模型越大、网络越强，差距越夸张。 解决：看任何"X 倍"先找三个限定词：什么模型、什么网络拓扑、什么输入输出长度。自己做容量规划时按 1.5-3 倍起步估，不要按 30 倍。
5.2 FP8 数字后面的 "with sparsity"
现象：按 3,958 TFLOPS 算训练时间，实际跑出来只有一半左右。 原因：算力表里所有 Tensor Core 行都标注了"with sparsity"，也就是 2:4 结构化稀疏——每四个元素强制两个为 0，算力才能翻倍到 3,958。普通稠密模型完全用不上这个特性。 解决：稠密负载一律按一半算，FP8 实际可用约 1,979 TFLOPS。想吃到稀疏算力，模型需要专门的稀疏化训练或推理框架，工程改动不小，不要为了参数好看预设这个值。
5.3 FP64 强不代表 HPC 全面翻身
现象：HPC 背景的用户看到 FP64 有 34 TFLOPS、是 A100 的三倍，以为科学计算终于成了重点。 原因：H100 的定位是 AI 优先，FP64 只是保留能力。对比 FP8 的 3,958，FP64 差了 100 多倍，芯片上的晶体管预算绝大部分给了 Tensor Core。 解决：纯双精度负载，应该去对比专门的 HPC 加速卡；AI + HPC 混合负载选 H100 没问题，但要清楚双精度只是"可用"，不是"强项"。
5.4 700W TDP 的散热连锁反应
现象：按 700W 采购，装机后满载跑几分钟就开始降频，性能掉到标称的 70% 左右。 原因：SXM 的 700W 是允许上限，不是保证值。风冷机房普遍压不住 700W 持续满载，供电和散热任一环节不达标，卡就自动降频。规格书写"configurable"意味着允许手动配功耗档。 解决：采购前先和整机供应商确认散热方案是液冷还是高功率风冷，再确认power.limit的实际设定值。没有液冷条件，要么接受降频，要么把功耗配到 500W 档换稳定性，同时接受算力损失。
5.5 NVLink 900GB/s 不是所有卡之间都有的
现象：以为 8 卡之间全是 900GB/s，训练代码一跑，通信成了瓶颈。 原因：900GB/s 是单卡 NVLink 的链路带宽，但多卡之间的实际通路取决于拓扑。没有 NVLink Switch 的机器，跨 CPU 域的卡间通信会回落 PCIe，带宽掉到 128GB/s 级别。 解决：验收机器时跑nvidia-smi topo -m看卡间拓扑标记，卡间是 NVLink 直连还是走了 PCIe 桥接，输出里一目了然。如果拓扑是部分互联，通信敏感型负载的期望值要往下调。
6. 落地验证：新卡到手先跑这三步
规格书是厂商的自述，验收才是你自己的结论。新机器进机房，我固定跑三步：身份核对、算力上界、真实负载。
6.1 第一步：核对硬件身份和拓扑
别急着跑性能，先确认买到的和规格书对得上：
nvidia-smi --query-gpu=name,memory.total,power.limit --format=csv nvidia-smi topo -m看三样：型号是不是 H100 SXM；显存是不是 80GB，NVL 则应是 94GB；power.limit是不是标称值——如果 700W 的卡显示 500W，散热或供电配置就有问题，趁设备在保赶紧找供应商。
6.2 第二步：用矩阵乘测算力上界
理论峰值能不能兑现，跑一个纯矩阵乘最快：
import torch, time a = torch.randn(8192, 8192, device="cuda", dtype=torch.float16) b = torch.randn(8192, 8192, device="cuda", dtype=torch.float16) for _ in range(10): torch.mm(a, b) torch.cuda.synchronize() t0 = time.time() for _ in range(50): torch.mm(a, b) torch.cuda.synchronize() print(f"实测 {2 * 8192**3 * 50 / (time.time() - t0) / 1e12:.2f} TFLOPS")实测值应该接近 FP16 稠密峰值（约 990 TFLOPS）的 70-80%。差太多就先查驱动版本、持久化模式，再看温度有没有触发降频。
6.3 第三步：用真实推理负载验收
矩阵乘只验算力，真实负载还要验显存带宽和软件栈。我会用开源推理框架加载目标模型，开并发测 tokens/s 和单 token 延迟，和第四章用带宽算出的上限对照。能到带宽理论的 50-60% 说明系统健康；低于 30%，优先检查三件事：MIG 是否误开导致带宽被切分、FP8 量化是否真正生效、卡间通信是否走了 PCIe。
这三步走完，规格书上的数字才算在你机器上落了地。从那以后我每次验收新卡，都强制走一遍"身份核对 → 算力上界 → 真实负载"的流程，因为吃过一次亏：某批标注 700W 的机器，实际被服务器管理固件锁到 500W，矩阵乘一跑就现了原形。完整的官方规格书 PDF 里还有整页的相对性能对比图和各精度数据明细，建议下载原版和实测结果对着看，希望这份拆解能帮你在下次下单前把账算清楚。
本文还有配套的精品资源，点击获取
