H100与H200推理性能对比：差距在带宽不在算力

当你把 70B 模型部署到推理服务，却发现单卡显存装不下、双卡通信又拖慢延迟时，你真正需要对比的并不是 H100 与 H200 的算力数字，而是两者存储子系统的差距。H100与H200推理性能对比的核心结论是：两者算力完全相同，差距集中在显存容量与带宽——H200 的 141GB HBM3e 和 4.8TB/s 带宽，决定了它在大模型、长上下文、高并发场景下的吞吐优势，而在小模型短上下文中几乎没有差别。

同核心同算力：3,958 TFLOPS FP8 完全一致意味着什么

先说一个反直觉的事实：NVIDIA H200 与 H100 SXM 采用完全相同的 Hopper 架构 GH100 核心与第 4 代 Tensor Core，两者的 FP8 峰值算力完全一致，均为 3,958 TFLOPS，NVLink 带宽同为 900 GB/s。这直接回答了“H100和H200算力一样吗”——是的，算力完全一样，H200 并不是算力升级版。这意味着在 Prefill 阶段，H200 不会有任何优势。

参数	H100 SXM	H200 SXM
架构核心	GH100（Hopper）	GH100（Hopper）
FP8 峰值算力	3,958 TFLOPS	3,958 TFLOPS
显存容量	80GB HBM3	141GB HBM3e
显存带宽	3.35 TB/s	4.8 TB/s
NVLink 带宽	900 GB/s	900 GB/s

H100与H200显存参数对比

真正的变量：141GB vs 80GB、4.8 TB/s vs 3.35 TB/s 改写了哪一段负载

既然算力相同，性能差异就完全来自存储子系统：显存容量提升 76%（80GB→141GB），带宽提升 43%（3.35 TB/s→4.8 TB/s）。这两个数字分别改写不同的负载环节：

容量决定能否把模型权重与 KV Cache 完整放进单卡。70B FP16 权重约需 140GB，H100 80GB 必须多卡并行，而 H200 141GB 可以单卡承载。
带宽决定 Decode 阶段逐 Token 生成时把全量权重与 KV Cache 搬运进核心的速度。

所以，“H200显存带宽4.8TB/s有什么用”的答案在于：它直接压缩了 Decode 阶段的内存搬运阻塞，提升逐 Token 生成速度（TPOT）。

Memory-bound 与 Compute-bound：怎么判断自己的推理属于哪一类

要判断“推理是算力瓶颈还是带宽瓶颈怎么判断”，需要先理解 LLM 推理的两个阶段：

Prefill（输入处理）：并行计算矩阵乘法，算术强度高，属于 Compute-bound（算力受限），此时 H100 与 H200 首字延迟（TTFT）基本一致。
Decode（逐 Token 生成）：每生成一个 Token 都要把全量权重和 KV Cache 载入核心，算术强度极低，属于 Memory-bound（带宽受限），此时 H200 的优势开始显现。

实际业务中，负载通常混合两种情况。你可以按以下顺序自查：

统计平均输入长度与输出长度：若输出长度远大于输入，Decode 占比高，大概率是带宽瓶颈。
观察并发 Batch 大小：大 Batch 会放大带宽需求，更容易进入 Memory-bound。
监控 KV Cache 峰值占用：接近显存上限时，容量优势变得关键。
测量 TTFT 与 TPOT：TTFT 慢而 TPOT 快，说明是算力受限；反之则是带宽受限。

H200比H100快多少：30%~90%提升出现在什么条件下

回到H100与H200推理性能对比的量化问题：网上流传的H200比H100快30%~90%的说法，必须在特定条件下才成立。在 70B+ 大模型、大并发请求、长上下文输出（KV Cache 占用高）等 Memory-bound 场景下，H200 实测吞吐可提升 30%~90%（MLPerf 吞吐可达 1.4x~1.9x）。

但在小模型（如 7B/8B）、小并发 Batch 或以超长 Prompt 输入为主的 Prefill 受限场景下，H200 的吞吐提升趋近于零，甚至因为时租更高而显得不划算。

负载特征	预期提升幅度	瓶颈类型
70B+ 模型、大 Batch、长上下文	30%~90%	Memory-bound（带宽）
7B/8B 模型、小 Batch、短上下文	接近 0%	Compute-bound（算力）
超长 Prompt、短输出	接近 0%	Compute-bound（Prefill）

拓扑简化的隐性收益：单卡承载 70B FP16 省掉的 TP 通信开销

70B FP16 模型权重约需 140GB 显存，H100 80GB 无法单卡加载，必须通过双卡或多卡张量并行（TP=2/4）部署；而 H200 凭借 141GB HBM3e 可实现单卡承载，彻底省去跨卡通信（All-Reduce）带来的网络开销与拓扑复杂性。关于多卡场景下的调优细节，可参考多卡推理优化。这意味着“H100双卡还是H200单卡跑70B划算”的答案很明确：只要能单卡放下，单卡方案通常更优，因为省去了通信延迟和运维复杂度。

H200值得比H100多花钱吗：每百万Token成本的回本条件

判断“H200值得比H100多花钱吗”，不能只看单价，而要看单位 Token 成本。具体方法：在相同负载下测出 H200 相对 H100 的吞吐倍数，再除以 H200 的时租倍数——如果商大于 1，说明 H200 能摊薄每百万 Token 成本；如果接近 1 或小于 1，则 H200 的溢价难以回本。具体时租需以各云厂商公开价格页为准，本文不引用任何报价数字；但吞吐倍数÷时租倍数这一判据是通用的。

什么时候留在 H100，什么时候换 H200，什么时候两者都不必

根据负载画像，可以把决策分成三类：

留在 H100：如果你主要跑 7B/8B 小模型、小并发、短上下文，H100 完全够用，换 H200 几乎无感。
换 H200：如果你要部署 70B+ 模型，且业务有高并发、长上下文（如问答、摘要、Agent 等），H200 的容量和带宽优势能显著优化 TPOT 和吞吐。
两者都不必：如果业务是纯离线批处理或 Prefill 密集，算力才是瓶颈，此时应该关注单位算力价格，而非卡型代际。

这三类判断都建立在实测之上，可在NexGPU等支持按量计费、多卡型自由切换的平台上先跑小时级验证。

用按量资源做一次同负载对照实测：该记录哪些指标

纸上推演终归不如实测。在锁定长期规格前，建议用按量计费的云 GPU 资源做一轮对照测试。比如在 NexGPU 上分别租用 H100 和 H200，用相同的模型、相同的请求分布、相同的推理框架（如 vLLM）跑一遍，记录以下指标：

TTFT（首字延迟）
TPOT（逐 Token 生成时间）
并发吞吐（每秒处理请求数或 Token 数）
KV Cache 峰值占用
显存带宽利用率

通过对比这些数据，你能清楚看到 H200 的提升是否真实存在。如果需要多卡方案，还可以参考 vLLM多卡张量并行配置指南来确保配置正确。如果想进一步了解选型细节，GPU显存怎么选也提供了实用的判断标准。

选型检查清单与三个常见误判

做H100与H200推理性能对比的最终决策前，对照下面这份清单检查你的负载：

模型参数量是否超过 70B？
平均输出长度是否远大于输入？
并发请求量是否高于当前卡型的承载能力？
KV Cache 是否接近显存上限？
是否已经实测过 TTFT 和 TPOT？

同时，要避开三个常见误判：

把 H200 当作算力升级：两者算力完全相同，H200 提升的是带宽与容量，不是峰值算力。
用小 Batch 短上下文测试就断言 H200 无价值：测试负载如果不在带宽瓶颈区间，自然看不到差异。
忽略多卡 TP 通信开销：双卡 H100 的纸面算力虽高，但通信开销可能抵消优势，单卡 H200 往往更优。

常见问题

H100和H200算力一样吗？

是的，H200 和 H100 SXM 采用完全相同的 GH100 核心，FP8 峰值算力都是 3,958 TFLOPS，NVLink 带宽也都是 900 GB/s。算力没有差别，差别完全在显存容量和带宽上。

H200 比 H100 快多少？

在 Memory-bound 场景（如 70B 模型、长上下文、高并发）下，H200 吞吐可提升 30%~90%，MLPerf 可达 1.4x~1.9x。但在 Compute-bound 场景（小模型、短上下文）下，提升几乎为零。

H200 的 141GB 显存能单卡跑 70B 模型吗？

可以。70B FP16 权重约需 140GB，H200 的 141GB 显存正好能放下，单卡即可部署，省去多卡张量并行的通信开销。H100 的 80GB 则必须双卡或四卡。

如何判断自己的推理是算力瓶颈还是带宽瓶颈？

看平均输出长度是否远大于输入，以及 Batch 大小和 KV Cache 占用。输出长、Batch 大、KV Cache 高，通常就是带宽瓶颈；反之则可能是算力瓶颈。更可靠的是实测 TTFT 和 TPOT。

H200 比 H100 多花钱值得吗？

只有当你的负载能进入 Memory-bound 区间，H200 的吞吐提升才能摊薄每百万 Token 成本。如果负载偏 Prefill 或小模型，H200 的溢价可能无法回本。建议先实测再决定。