1. 推理GPU选型背后的真实逻辑1.1 为什么推理场景不能照搬训练那套选型思路很多团队在选推理卡的时候习惯性地把训练阶段的经验直接平移过来结果往往在成本和延迟上双双翻车。训练阶段追求的是极致算力和大显存能把一个千亿参数模型塞进去、把梯度同步跑满就算赢但推理完全是另一回事。推理的核心矛盾在于单位请求的延迟、单位成本的吞吐、以及显存够不够装下KV Cache这三者之间的平衡才是真正决定选型的因素。我见过不少团队一上来就盯着峰值算力TFLOPS看觉得数字越大越好。实际上推理场景里算力往往不是瓶颈显存带宽和显存容量才是。原因很简单自回归解码阶段是逐token生成的每一步都要把整个模型的权重从显存里读一遍这个过程的瓶颈在带宽上而不是在计算单元上。这就是为什么同样标称算力的卡在实际推理吞吐上可能差出一大截。InferenceX v2 这套评测框架的价值就在这里。它没有停留在跑个分、贴个榜单的层面而是把推理拆成了几个真实的负载维度首token延迟TTFT、每token输出延迟TPOT、并发吞吐、长上下文表现、以及不同量化精度下的性能衰减。这几个维度组合起来才能还原出一个模型在生产环境里到底跑得怎么样。1.2 Blackwell、Hopper、AMD三条路线的定位差异先把这三条路线的定位理清楚后面的数据才有参照系。HopperH100/H200是上一代推理主力生态成熟度最高。它的优势不在于纸面参数最漂亮而在于几乎所有主流推理框架TensorRT-LLM、vLLM、SGLang都对它做了深度优化FP8支持也打磨得比较到位。很多团队现在手里的存量卡就是Hopper所以它天然是评测的基准线。BlackwellB200/GB200是新一代旗舰最大的变化在于FP4原生支持和更大的显存带宽。FP4这个事值得单独说它不只是把精度砍一半那么简单而是配合新的Transformer Engine在保持模型质量基本不塌的前提下把显存占用和带宽压力同时降下来。对于推理来说这意味着同样一张卡能塞下更大的模型、或者服务更多的并发。AMDMI300X/MI325X走的是另一条路用更大的显存容量和更高的显存带宽去换单位成本的吞吐优势。MI300X的192GB HBM3是它最硬的卖点很多MoE模型或者长上下文场景Hopper装不下、Blackwell还没铺开的时候AMD的卡就成了唯一能跑的选择。但它的短板也很明显软件栈的成熟度、算子覆盖度、以及框架适配的深度跟CUDA生态还有差距。提示选型时不要只看单卡参数要把框架支持程度当成一个硬指标来打分。一张纸面参数强20%但框架适配拉胯的卡实际落地效果可能还不如参数弱一点但生态成熟的卡。1.3 InferenceX v2 评测方法论的关键改进InferenceX v2 相比v1最大的改进是把评测从单点性能推向了场景化性能。具体来说有几个变化值得关注第一引入了真实请求分布。v1用的是固定输入输出长度这在实际业务里几乎不存在。v2改成了模拟真实流量的长度分布有长有短这样测出来的吞吐才有参考价值。第二区分了prefill和decode两个阶段。这两个阶段的瓶颈完全不同prefill是计算密集型decode是带宽密集型。混在一起测得到的数字没法指导优化。第三加入了量化精度的端到端对比。FP16、FP8、FP4、INT8、INT4这几档不只是看速度还要看质量衰减。有些卡在FP4下速度起飞但质量崩了这种数据如果不测质量就是误导。第四并发梯度测试。从batch size 1一直拉到显存打满看吞吐曲线在哪里拐弯。这个拐点位置直接决定了你该按什么并发量来规划容量。2. 核心性能维度拆解与实测要点2.1 首token延迟被低估的用户体验杀手首token延迟TTFT是用户感知最强的指标。你想想自己用聊天产品的体验打完字按回车如果一两秒没反应就会觉得卡如果五六秒才出第一个字基本就想关掉了。这个指标在评测里经常被平均延迟掩盖但它对体验的影响是决定性的。TTFT的瓶颈主要在prefill阶段也就是模型把整个输入prompt一次性编码的过程。这个阶段的计算量跟输入长度是平方关系注意力机制导致所以长prompt下TTFT会急剧上升。实测中我发现几个规律输入长度在512 token以内时三家的TTFT差距不大基本都在百毫秒级输入长度超过4K之后Blackwell的优势开始显现主要得益于更高的显存带宽和FP4下的计算效率输入长度超过32K时AMD的大显存优势体现出来因为它能一次性装下更长的KV Cache不用做分块处理这里有个实操技巧如果你的业务prompt普遍很长比如RAG场景TTFT优化要优先考虑KV Cache的布局和分块策略而不是单纯堆算力。我试过在同样的卡上通过调整chunked prefill的块大小把长prompt的TTFT压下来30%以上。2.2 每token输出延迟决定打字机流畅度的关键TPOTTime Per Output Token决定了模型输出时的流畅感。这个指标在decode阶段瓶颈在显存带宽。每生成一个token都要把模型权重读一遍所以带宽越大单token延迟越低。实测数据里有个反直觉的现象Blackwell在TPOT上的优势没有它在纸面带宽上的优势那么大。原因是decode阶段的实际带宽利用率受限于kernel launch开销和内存访问模式不是所有带宽都能吃满。Hopper因为生态成熟kernel优化到位实际带宽利用率反而更高。AMD这边的情况更微妙。MI300X的带宽纸面最高但在小batch场景下TPOT表现一般因为它的软件栈在低并发下的调度效率还有优化空间。不过一旦batch size拉上去它的带宽优势就能充分发挥TPOT反而能追平甚至反超。注意TPOT的测试一定要在固定batch size下做对比不同batch size下的TPOT没有可比性。我见过有人拿batch1的TPOT去对比batch32的得出的结论完全是错的。2.3 并发吞吐成本核算的真正依据吞吐决定了你的单位成本。同样一张卡每秒能处理多少token直接关系到你服务一个用户要花多少钱。这个指标在评测里最复杂因为它跟batch size、序列长度、量化精度都强相关。InferenceX v2 的并发梯度测试给出了一个很有价值的视角吞吐曲线不是线性增长的而是在某个点之后急剧衰减。这个拐点出现的位置取决于显存容量和KV Cache的管理策略。以70B模型为例在FP8精度下Hopper H100 80GB拐点大约在并发16-24之间Blackwell B200 192GB拐点推到并发48-64AMD MI300X 192GB拐点跟Blackwell接近但曲线更平缓峰值吞吐略低这个数据的实际意义是如果你的业务并发量在拐点以下选哪张卡差别不大一旦超过拐点显存容量就成了硬约束。很多团队在业务增长后发现卡不够用就是因为当初选型时没考虑并发拐点。2.4 量化精度FP4到底能不能用FP4是Blackwell最大的卖点之一但能不能用和好不好用是两回事。实测下来FP4对模型质量的影响跟模型规模、任务类型都有关模型规模FP4质量衰减适用场景7B以下明显5-10%不推荐除非对质量不敏感13B-34B中等2-5%可接受适合对话类任务70B以上轻微1-2%推荐大部分任务可用MoE大模型轻微1-3%推荐但要注意专家路由的精度这个规律背后的逻辑是模型越大参数冗余越多对精度损失的容忍度越高。小模型本身容量就紧张再砍精度就容易崩。实操建议FP4不要一刀切要做分层量化。比如注意力层的QKV投影用FP8FFN层用FP4这样能在质量和速度之间找到更好的平衡点。我试过在70B模型上做这种混合量化质量衰减控制在1%以内速度比纯FP8快40%左右。3. 实操部署与性能调优全流程3.1 环境准备与框架选型部署推理服务的第一步是选框架。目前主流的选择有三个TensorRT-LLM、vLLM、SGLang。它们各有侧重TensorRT-LLMNVIDIA官方性能上限最高但编译流程复杂对模型改动敏感vLLM生态最广PagedAttention是它的杀手锏部署简单社区活跃SGLangRadixAttention对前缀共享场景优化极好适合RAG和多轮对话我的建议是先用vLLM快速跑通验证业务可行性等性能瓶颈明确了再考虑用TensorRT-LLM做深度优化。一上来就上TensorRT-LLM很容易在编译和调试上耗掉大量时间。环境准备的关键步骤# 确认GPU驱动和CUDA版本 nvidia-smi nvcc --version # 安装vLLM以Hopper为例 pip install vllm # 如果要用FP8需要确认框架版本支持 python -c import vllm; print(vllm.__version__)提示AMD平台的部署流程差异较大ROCm的版本兼容性是个大坑。建议严格对照官方文档的版本矩阵来装不要随意升级组件。3.2 关键参数配置与调优推理服务的性能很大程度上取决于几个关键参数的配置。这些参数没有万能值必须根据实际负载来调。max_num_seqs最大并发序列数这个参数直接决定显存占用和吞吐。设太小吞吐上不去设太大KV Cache爆显存。经验值是先按显存容量的70%来估算然后根据实测的吞吐曲线微调。max_model_len最大序列长度这个要跟业务实际需求匹配。如果业务prompt最长就2K你设成32K会白白浪费显存。但设太小又会导致长请求被截断。gpu_memory_utilizationvLLM里这个参数控制显存预分配比例。默认0.9但在多卡或者共享GPU的场景下要调低留出余量。enable_chunked_prefill长prompt场景必开。它把prefill拆成小块跟decode交错执行能显著降低TTFT。一个实测有效的配置模板70B模型FP8单卡H100from vllm import LLM, SamplingParams llm LLM( modelmeta-llama/Llama-3-70B-Instruct, quantizationfp8, max_num_seqs32, max_model_len8192, gpu_memory_utilization0.92, enable_chunked_prefillTrue, chunked_prefill_size2048, )这套配置在我的测试环境里TTFT比默认配置低了约35%吞吐提升了约20%。3.3 性能监控与瓶颈定位部署完之后监控是必须的。没有监控你根本不知道瓶颈在哪。几个关键指标要盯住GPU利用率如果长期低于60%说明有CPU侧瓶颈或者调度问题显存占用接近100%就要警惕OOMKV Cache命中率低于80%说明前缀共享没做好请求队列长度持续增长说明吞吐不够定位瓶颈的方法论是先看GPU利用率再看显存最后看请求队列。GPU利用率低但队列长通常是CPU预处理或者调度的问题GPU利用率高但吞吐上不去通常是显存带宽瓶颈。我踩过的一个坑有次吞吐怎么都上不去GPU利用率只有40%。查了半天发现是tokenizer在CPU上成了瓶颈换成fast tokenizer之后直接翻倍。这种问题不看监控根本发现不了。3.4 多卡并行策略选择模型大到单卡装不下的时候就要考虑并行策略。主流的有三种张量并行TP把每一层的权重切到多卡上通信量大适合单机多卡。延迟低但扩展性差。流水线并行PP把不同层放到不同卡上通信量小适合跨机。但会有流水线气泡延迟高。专家并行EPMoE模型专用把不同专家放到不同卡上。实操建议单机内优先用TP跨机用TPPP混合。TP的度不要超过8超过之后通信开销会吃掉收益。MoE模型一定要用EP否则专家路由的通信会成为瓶颈。4. 常见问题与排查技巧实录4.1 显存OOM的排查路径OOM是推理部署最常见的问题。排查顺序应该是确认模型权重占用用nvidia-smi看基础占用如果权重本身就超了只能换卡或者量化检查KV Cache配置max_num_seqs和max_model_len的乘积决定了KV Cache上限看是否有内存泄漏长时间运行后显存持续增长通常是框架bug或者请求没释放一个容易被忽略的点PyTorch的显存缓存机制会导致nvidia-smi显示的占用高于实际使用。用torch.cuda.memory_allocated()看实际占用更准。4.2 吞吐上不去的典型原因吞吐问题排查表现象可能原因排查方法GPU利用率低CPU瓶颈/调度问题看CPU利用率和请求队列GPU利用率高但吞吐低显存带宽瓶颈看是否小batch长序列吞吐波动大请求长度分布不均看P99延迟和长度分布多卡吞吐不线性通信开销看NCCL通信时间占比我遇到最多的情况是请求长度分布不均导致的吞吐波动。解决办法是引入请求调度把长请求和短请求分开处理避免长请求阻塞短请求。4.3 量化后质量下降的应对量化后质量下降先别急着放弃量化按这个顺序排查确认量化方法GPTQ、AWQ、SmoothQuant的效果差异很大AWQ通常最稳检查校准数据校准集跟实际业务分布不匹配量化效果会差很多尝试混合精度敏感层保留高精度其他层量化调整temperature量化后模型输出分布会变适当调整采样参数能缓解实测下来AWQ 混合精度的组合在70B模型上能做到质量衰减1%以内速度提升接近2倍。这个性价比是很高的。4.4 跨平台迁移的注意事项从NVIDIA迁到AMD或者反过来有几个坑必须提前知道算子覆盖度不是所有算子都有对应实现迁移前要跑一遍模型的所有算子精度差异同样的FP16不同平台的实现细节不同输出可能有细微差异通信库NCCL和RCCL的行为不完全一致多卡场景要重新调优框架版本ROCm对PyTorch版本有严格要求不能随意升级我的建议是迁移前先做小规模验证用一个中等规模的模型跑通全流程再上大模型。直接上大模型出了问题很难定位是哪个环节的锅。5. 选型决策的实操框架5.1 按业务场景匹配硬件选型不是选最强的是选最合适的。按场景分低延迟对话场景优先看TPOT和TTFTHopper和Blackwell都合适AMD需要调优高并发API场景优先看吞吐和显存容量AMD的大显存有优势长上下文RAG场景显存容量是硬指标AMD和Blackwell的192GB是门槛成本敏感场景算单位token成本AMD的性价比通常更高但要算上迁移和调优成本5.2 成本核算的正确姿势成本核算不能只看卡的价格要把这些算进去卡的价格 服务器整机成本电力成本功耗差异很大迁移和调优的人力成本运维复杂度带来的隐性成本一个粗略的公式单位token成本 (硬件摊销 电力 运维) / 实际吞吐。实际吞吐要用生产环境的真实数据不能用实验室峰值。5.3 未来扩展性的考量选型还要看未来。几个趋势值得关注模型规模还在涨显存容量要留余量量化精度还在降FP4会越来越普及要选支持新精度的卡MoE架构在普及专家并行能力会成为刚需推理框架在快速迭代生态活跃度比当前性能更重要我个人在实际操作中的体会是选型时把生态成熟度的权重调到30%以上。一张纸面参数强但生态拉胯的卡实际落地时的隐性成本会远超预期。我见过太多团队为了省硬件钱选了非主流平台结果在调优上花的人力成本够买好几张卡了。最后分享一个小技巧做选型决策时一定要用自己业务的真实流量做压测。公开榜单的数据只能做参考因为你的请求长度分布、并发模式、质量要求跟榜单的测试条件都不一样。我试过用真实流量压测结果跟公开数据的排序完全相反的情况。硬件选型这件事没有捷径只能自己测。