1. 推理GPU性能对决的背景与核心价值
大模型推理这件事，真正落到生产环境里，绕不开一个最现实的问题：同样的模型、同样的并发量，换一张卡，成本和延迟可能差出一倍。过去两年大家习惯性把目光锁在训练侧，觉得推理不过是“跑起来就行”，但实际做过线上服务的人都知道，推理才是长期烧钱的那一端。一个日请求量百万级的对话服务，GPU选型差一档，一年电费和租用成本能差出六位数。
InferenceX v2 这个项目，本质上就是一套面向推理场景的GPU横向评测框架。它不测训练吞吐，不测理论算力峰值，只盯着一件事：在真实推理负载下，不同架构的GPU到底谁更划算、谁更稳、谁更适合放进你的机柜。这次横评覆盖了 NVIDIA Blackwell、AMD 以及上一代 Hopper 三条产品线，基本代表了当前推理市场的三个主流选择方向。
为什么这个对比值得单独拿出来讲？因为推理和训练的硬件需求根本不是一回事。训练吃的是大规模矩阵乘的持续吞吐和显存带宽，而推理吃的是低延迟、高并发下的能效比和显存容量。一张训练猛卡放到推理场景里，很可能因为功耗墙和调度策略，表现还不如一张定位更低的推理专用卡。InferenceX v2 的价值就在于，它把这层“错配”问题用数据摊开了。
这篇文章适合三类人看：一是正在做推理服务选型、纠结买哪张卡的工程负责人；二是自己搭本地推理环境、想搞清楚性价比的开发者；三是做GPU资源调度、需要理解不同架构差异的运维同学。我会把评测框架的设计逻辑、关键指标的测法、三家架构的实际表现，以及我踩过的坑，全部拆开讲清楚。你不需要有硬件背景，只要跑过推理服务，就能看懂。
2. InferenceX v2 评测框架的整体设计思路
2.1 为什么不用理论算力做对比
刚接触GPU选型的人，最容易犯的错就是看TFLOPS。厂商发布会上一张卡标称几百TFLOPS，另一张标称一半，直觉上就觉得前者强。但推理场景里，这个数字的参考价值极低。原因有三层。
第一层，标称算力通常是特定精度下的峰值，比如FP8或者INT4，而你的模型实际跑在什么精度，取决于量化策略和框架支持。一张卡FP8很强，但你用的是FP16权重，那它的优势根本发挥不出来。第二层，推理是访存密集型任务，尤其是自回归生成阶段，每一步只算一个token，计算量小但要把整个KV Cache和权重读一遍，瓶颈在显存带宽而不是算力。第三层，功耗和散热会直接限制持续性能，标称峰值只能维持几毫秒，真实推理是长时间稳定负载。
InferenceX v2 的设计思路就是绕开这些干扰项，直接用端到端指标说话。它测的是：在固定模型、固定输入输出长度、固定并发数下，每秒能处理多少token，首token延迟是多少，以及整机功耗是多少。这三个数字组合起来，才能算出真正的“每token成本”。
2.2 评测负载的构造逻辑
框架里最核心的设计是负载模型。InferenceX v2 没有用单一的固定输入，而是构造了一个混合负载分布，模拟真实线上流量。具体来说，输入长度按对数正态分布采样，大部分请求在128到512 token之间，少量长尾请求到2048甚至4096。输出长度同样如此，多数在64到256之间。
这么设计的原因很实际：真实用户的提问长度差异极大，如果只测固定长度，得到的吞吐数字会严重偏乐观。长输入会显著拉高首token延迟，因为prefill阶段要处理整个上下文；长输出则考验decode阶段的持续吞吐和KV Cache管理。混合负载能同时压到这两个环节。
提示：如果你自己搭评测环境，千万别只用“你好，请介绍一下你自己”这种短输入跑benchmark，得到的数字放到生产里会打对折。
框架还区分了两种测试模式：离线吞吐模式和在线服务模式。离线模式一次性灌入大量请求，测极限吞吐，用来评估批处理能力；在线模式按泊松过程到达请求，测P50和P99延迟，用来评估服务质量。这两种模式的结果经常互相矛盾——某张卡离线吞吐最高，但在线P99延迟最差，因为它调度策略激进，长尾请求被饿死。InferenceX v2 把两种模式都保留，就是为了暴露这种trade-off。
2.3 三家架构的定位差异
在进入具体数据之前，有必要先把三条产品线的定位理清楚，否则看数字会失去参照系。
NVIDIA Blackwell 是这一代的新架构，主打的是FP4原生支持和更大的显存带宽。它的目标场景很明确：超大规模推理集群，尤其是MoE模型和超长上下文。Blackwell在片间互联上做了大幅升级，多卡推理时的通信开销被压得很低，这是它相对上一代最实质的进步。
AMD 这边的参评产品线走的是另一条路。它的优势在于显存容量和单位算力成本，同样的预算能买到更大的显存池。对于显存瓶颈明显的场景，比如长上下文或者大batch，AMD的卡往往能塞下更多并发。但它的软件栈成熟度是绕不开的话题，后面会专门讲。
Hopper 作为上一代产品，现在最大的价值是性价比。新卡溢价高，而Hopper经过市场沉淀，二手和租赁价格都下来了。对于预算有限、又不需要最新特性的团队，Hopper仍然是很多场景下的理性选择。InferenceX v2 把它纳入对比，不是凑数，而是给出一条“够用就好”的基准线。
3. 核心性能指标的测法与数据解读
3.1 吞吐量：token/s 背后的三个陷阱
吞吐量是最直观的指标，但也是最容易被误读的。InferenceX v2 报告的吞吐量分三个维度：单请求吞吐、批量吞吐、以及每瓦吞吐。单请求吞吐就是batch size为1时的生成速度，反映交互式场景的响应能力；批量吞吐是塞满显存后的总吞吐，反映离线处理能力；每瓦吞吐则是总吞吐除以整机功耗，反映能效。
实测下来，Blackwell在批量吞吐上领先明显，尤其是在FP4量化下，同样显存能塞下的batch更大，总吞吐自然更高。但单请求吞吐的差距没有批量那么大，因为单请求时算力根本吃不满，瓶颈在显存延迟。AMD在单请求场景下表现意外地稳，原因是它的显存控制器调度策略偏向低延迟，牺牲了一部分峰值带宽换取了更稳定的响应。
这里有个陷阱要提醒：很多评测只报批量吞吐，然后拿这个数字去推算单请求性能，这是错的。批量吞吐高不代表单请求快，两者甚至可能负相关。如果你的服务是交互式的，一定要看单请求延迟，别被总吞吐忽悠。
| 指标 | 测试条件 | 反映场景 | 常见误读 |
|---|---|---|---|
| 单请求吞吐 | batch=1 | 交互式对话 | 误当成整体性能 |
| 批量吞吐 | 显存打满 | 离线批处理 | 误用于在线服务估算 |
| 每瓦吞吐 | 整机功耗 | 长期运营成本 | 忽略散热和电源损耗 |
3.2 首token延迟：prefill阶段的真实较量
首token延迟（TTFT）是用户体验的生死线。用户发完消息，等第一个字出来，超过一秒就会觉得卡。这个指标主要考验prefill阶段，也就是模型处理整个输入上下文、生成第一个token的过程。
InferenceX v2 测TTFT时，特意区分了短上下文和长上下文。短上下文（512以内）下，三家差距不大，都在几十毫秒量级，因为计算量小，主要开销在调度和启动。但上下文拉到4096以上，差距就拉开了。Blackwell凭借更大的显存带宽和更高效的attention实现，长上下文TTFT明显占优。AMD在这个环节的表现取决于软件栈版本，新版本驱动下改善很大，但老版本会有明显的性能塌陷。
注意：TTFT对输入长度极其敏感，报TTFT数据时必须标注上下文长度，否则数字没有意义。我见过有人拿128上下文的TTFT去宣传长文本能力，这是耍流氓。
3.3 显存占用与KV Cache管理
显存是推理服务的硬约束。模型权重占一部分，KV Cache占一部分，剩下的才能给batch。KV Cache的大小和上下文长度、batch size、层数、注意力头数都相关，计算公式大致是：2 × 层数 × 头数 × 头维度 × 序列长度 × batch × 精度字节数。
这个公式解释了为什么长上下文场景下显存这么紧张。序列长度翻倍，KV Cache就翻倍。Blackwell和AMD在显存容量上的策略不同：Blackwell单卡容量相对保守，但靠互联把多卡拼成一个大显存池；AMD单卡容量给得大方，单卡就能扛更长的上下文。
InferenceX v2 专门测了“最大可服务上下文长度”这个指标，也就是在给定batch下，不OOM的前提下能支持多长的序列。这个数字对做长文档问答、代码仓库理解的团队特别关键。实测中，AMD在单卡长上下文上确实有优势，但多卡扩展时通信开销比Blackwell大，超过一定规模后反而不划算。
3.4 功耗与能效：被低估的运营成本
功耗这件事，采购时容易被忽略，运营时天天肉疼。一张卡标称功耗350W，实际跑推理可能稳定在300W左右，加上CPU、内存、风扇、电源转换损耗，整机功耗要乘一个1.3到1.5的系数。一个8卡节点，整机功耗轻松上3kW，机房电费和散热成本一年下来是笔大钱。
InferenceX v2 用功率计实测整机功耗，而不是读显卡报告的功耗。这个区别很重要，显卡报告的只是芯片功耗，不包括显存、供电模块和风扇。实测数据显示，Blackwell在同等吞吐下能效比最好，但绝对功耗也最高；AMD的能效比居中，但待机功耗控制得不错；Hopper能效比最差，但考虑到它的采购成本低，综合TCO未必输。
| 架构 | 典型整机功耗 | 每瓦吞吐（相对值） | 适合场景 |
|---|---|---|---|
| Blackwell | 高 | 1.0 | 大规模集群、能效敏感 |
| AMD | 中 | 0.75 | 显存敏感、预算有限 |
| Hopper | 中高 | 0.6 | 性价比优先、成熟稳定 |
4. 实操过程与关键环节实现
4.1 评测环境搭建的完整步骤
复现InferenceX v2的评测，环境搭建是最容易翻车的地方。我把自己搭环境的流程完整走一遍，你可以直接抄。
第一步是确定软件栈版本。这一步比选硬件还重要。NVIDIA这边，CUDA版本、驱动版本、推理框架版本三者必须匹配，错一个就可能性能腰斩。AMD这边更敏感，ROCm版本和框架的兼容性要严格对照官方矩阵，别想着用最新版碰运气。我的建议是：先用官方推荐的稳定组合跑通，再考虑升级。
第二步是准备模型。InferenceX v2用的是几个主流开源模型，覆盖不同规模。你需要提前把权重下载好，转成框架需要的格式。这里有个坑：不同框架对量化格式的支持不一样，同一个模型在A框架能跑FP8，在B框架可能只支持FP16。评测前要统一精度，否则对比没有意义。
第三步是配置推理服务。关键参数包括batch size上限、KV Cache分配策略、调度策略。这些参数对性能影响巨大，必须针对每张卡单独调优，不能一套配置跑到底。我的做法是先用默认配置跑一遍，找到瓶颈后再针对性调参。
# 以某推理框架为例，启动服务的基本命令结构 python -m inference_server \ --model /path/to/model \ --dtype fp16 \ --max-batch-size 32 \ --max-seq-len 4096 \ --gpu-memory-utilization 0.9 \ --port 8000第四步是压测。用框架自带的benchmark工具或者自己写脚本，按混合负载分布发请求。记录吞吐、延迟、功耗三组数据。压测时间要足够长，至少跑十分钟，让功耗和温度进入稳态，短时间跑出来的数字不可信。
4.2 参数调优的核心逻辑
调参这件事，核心是找到显存、算力、延迟三者的平衡点。我总结了几条实操原则。
batch size不是越大越好。增大batch能提升吞吐，但会拉高单请求延迟，因为每个请求要等更久才能轮到。在线服务场景下，batch size要控制在延迟可接受的范围内。我的经验值是：交互式服务batch控制在8到16，离线批处理可以拉到显存上限。
KV Cache的分配策略直接影响能支持的最大并发。有些框架默认预留一大块显存给KV Cache，导致可用batch变小。可以手动调整预留比例，但别调太满，留10%余量防止碎片化导致的OOM。
量化精度的选择要权衡。FP8比FP16省一半显存，吞吐也更高，但精度损失在部分任务上肉眼可见。我的建议是：对话类任务可以上FP8，代码生成和数学推理建议FP16，除非你验证过FP8的精度可接受。
提示：调参时一次只改一个变量，改完记录数据。同时改多个参数，出了问题根本不知道是哪个引起的。
4.3 多卡推理的配置要点
单卡跑不动的大模型，就得上多卡。多卡推理有两种模式：张量并行和流水线并行。张量并行把每一层的计算切到多张卡上，通信频繁但延迟低；流水线并行把不同层分到不同卡上，通信少但有气泡。
InferenceX v2 主要测的是张量并行，因为推理场景对延迟敏感，流水线的气泡不可接受。张量并行的关键是卡间互联带宽。Blackwell的互联带宽最高，多卡扩展效率最好，8卡能跑到接近单卡8倍的吞吐。AMD的互联带宽相对低，4卡以内效率不错，超过4卡衰减明显。Hopper介于两者之间。
配置多卡时，要注意显存均衡。张量并行下每张卡存的权重是一样的，但KV Cache可能分布不均。要确保每张卡的显存占用接近，否则一张卡OOM，整个服务就挂了。
5. 常见问题与排查技巧实录
5.1 性能不达预期的排查路径
跑出来数字比预期低，是最常见的问题。我整理了一条排查路径，按顺序走，基本能定位到原因。
先看GPU利用率。如果利用率上不去，说明瓶颈不在GPU，可能在数据加载、请求调度或者CPU预处理。用监控工具看GPU利用率的实时曲线，如果忽高忽低，说明请求供给不足；如果一直很低，说明有别的环节卡住了。
再看显存占用。如果显存快满了，框架会频繁触发显存回收，性能断崖式下跌。这时候要降低batch size或者缩短上下文长度。如果显存占用很低但性能也低，可能是框架没有正确识别到GPU，跑在CPU上了。
然后看功耗。如果功耗远低于标称值，说明GPU没吃满，可能是驱动限制了功耗墙，或者散热不足导致降频。检查驱动设置里的功耗上限，以及机箱风道是否合理。
最后看软件版本。很多性能问题升级驱动或框架就解决了。尤其是AMD平台，ROCm版本更新带来的性能提升经常是两位数百分比。
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| GPU利用率低 | 请求供给不足 | 增加并发或检查调度 |
| 显存频繁回收 | batch或上下文过大 | 降低负载参数 |
| 功耗远低于标称 | 功耗墙或降频 | 检查驱动和散热 |
| 性能突然下降 | 软件版本问题 | 回滚或升级版本 |
5.2 精度与性能的取舍问题
量化能带来显著的性能提升，但精度损失是绕不开的。我的做法是：先确定任务能接受的精度下限，再选量化方案。
具体操作上，准备一个验证集，覆盖你的真实任务类型。用FP16跑一遍作为基准，再用FP8或INT8跑一遍，对比输出差异。如果差异在可接受范围内，就用量化版本；如果差异明显，就老老实实用FP16。
有个经验：量化的精度损失不是均匀分布的。简单任务几乎无损，复杂推理任务损失明显。所以别拿简单问答的测试结果去推断复杂任务的表现。
5.3 散热与稳定性的隐藏坑
散热问题在短时间评测里看不出来，长时间跑才会暴露。我遇到过跑benchmark前五分钟性能很好，十分钟后吞吐掉了20%，一查是GPU温度到了阈值开始降频。
机箱风道要保证前进后出，GPU之间留够间距。如果是高密度部署，考虑用液冷或者加强风扇。另外，电源要留足余量，瞬态功耗可能远超标称值，电源不够会导致重启。
注意：评测环境一定要和 production 环境一致，包括机箱、风扇、电源。在开放平台上测出来的数字，放进机柜里可能完全不一样。
5.4 常见问题速查表
| 问题 | 排查方向 | 解决思路 |
|---|---|---|
| 首token延迟高 | prefill计算或调度 | 检查上下文长度和调度策略 |
| 吞吐上不去 | batch或显存瓶颈 | 调大batch或优化显存 |
| 多卡扩展效率低 | 互联带宽或通信 | 减少并行度或换互联方案 |
| 长时间跑性能衰减 | 散热降频 | 改善散热或限制功耗 |
| 精度不达标 | 量化损失 | 回退精度或换量化方案 |
6. 选型建议与个人实操体会
选型这件事，没有绝对的最优解，只有最适合你场景的解。我把几个典型场景的推荐理一下。
如果你做的是超大规模在线服务，日请求量千万级，对能效和延迟都敏感，Blackwell是当前最稳的选择。它的多卡扩展效率和高能效比，在大规模下摊薄成本的优势明显。代价是采购成本高，适合预算充足的团队。
如果你做的是长上下文场景，比如长文档分析、代码仓库理解，显存是硬瓶颈，AMD的大显存卡更合适。单卡能扛更长的序列，省去了多卡通信的麻烦。前提是你能接受软件栈的折腾成本，建议选成熟稳定的ROCm版本。
如果你是中小团队或者个人开发者，预算有限，Hopper仍然是理性选择。它的性能足够覆盖大多数推理场景，生态成熟，踩坑资料多，遇到问题好查。二手和租赁市场价格友好，试错成本低。
我个人在实际操作中的体会是：别迷信参数表，一定要自己跑一遍。厂商给的数字都是在理想条件下测的，你的模型、你的负载、你的环境，都可能让结果完全不同。我见过太多次“纸面最强”的卡在实际场景里翻车。花两天时间搭个评测环境，跑一遍自己的真实负载，比看一百篇评测都有用。
最后分享一个小技巧：评测时把功耗和温度也记录下来，画成时间曲线。性能数字只是结果，曲线才能告诉你稳定性。一张卡如果性能高但曲线抖动大，生产环境里就是定时炸弹。稳，比快更重要。
