英伟达推理平台概览：GPU架构与推理专用硬件
核心原理：从图形渲染到并行计算的架构演进
英伟达GPU的架构设计始终围绕一个核心矛盾：如何在有限功耗与面积内，最大化并行吞吐量。早期GPU为图形渲染设计，其大规模并行结构天然适合矩阵运算。随着深度学习兴起，英伟达将GPU从“图形加速器”改造为“通用并行计算设备”，并逐步引入针对神经网络推理的专用单元。
理解推理延迟，首先需要理解GPU的硬件分层。以Ampere架构（A100/A10）与Hopper架构（H100）为例，其关键差异体现在以下层面：
- SM（流式多处理器）：GPU的基本计算单元，包含CUDA核心、Tensor Core、共享内存与调度器。推理时，模型层被切分为多个block分配到不同SM上并行执行。
- Tensor Core：专为矩阵乘加运算设计的硬件单元，支持混合精度（FP16/FP32累加）。在Ampere上支持稀疏化计算（2:4结构化稀疏），在Hopper上新增FP8支持与Transformer引擎，直接加速注意力机制中的矩阵运算。
- 显存层次：寄存器→共享内存→L1/L2缓存→HBM显存。推理延迟的很大一部分来自数据搬运，而非计算本身。Hopper引入的TMA（张量内存加速器）可异步完成显存与共享内存的数据拷贝，减少SM等待时间。
- NVLink与PCIe：多卡通信带宽。对于单卡可容纳的模型，PCIe Gen4/Gen5足够；对于超大模型或张量并行推理，NVLink的带宽直接决定跨卡通信延迟。
关键认知：推理延迟 = 计算时间 + 数据搬运时间 + 同步开销。在Ampere/Hopper上，Tensor Core的算力往往远超显存带宽能供给的数据速率，因此访存优化（算子融合、减少中间张量落显存）比单纯堆算力更能降低端到端延迟。
推理专用硬件矩阵：T4、A10、A100、H100的定位差异
不同推理场景对延迟、吞吐、功耗和显存容量的要求截然不同。英伟达通过产品线分层来覆盖这些需求。下表对比了当前主流的推理GPU型号，重点关注与延迟相关的硬件参数：
| GPU型号 | 架构 | Tensor Core算力(FP16) | 显存容量/带宽 | NVLink | 典型推理场景 |
|---|---|---|---|---|---|
| T4 | Turing | 65 TFLOPS | 16GB / 320GB/s | 无 | 轻量级在线推理、边缘视频分析、低功耗批量服务 |
| A10 | Ampere | 125 TFLOPS | 24GB / 600GB/s | 无 | 中型视觉模型、多实例GPU(MIG)隔离推理 |
| A100 | Ampere | 312 TFLOPS | 40/80GB / 2TB/s | 600GB/s | 大规模Transformer、多卡张量并行、高并发在线推理 |
| H100 | Hopper | 990 TFLOPS(FP8) | 80GB / 3.35TB/s | 900GB/s | 超大模型推理、FP8量化部署、专家并行(MoE) |
选择推理硬件时，不能只看峰值算力。T4的FP16算力仅为A100的1/5，但其功耗仅为70W，对于延迟不敏感、批量较小的场景，T4的性价比更高。A10则填补了T4与A100之间的空白，支持MIG（多实例GPU）可将物理GPU切分为最多7个独立实例，每个实例拥有专属显存和计算资源，避免相互干扰导致的延迟抖动。
方法流程：如何根据延迟目标选择GPU并估算性能
在实际部署中，我们通常采用“反向推导”的方法来确定硬件选型。核心流程如下：
- 确定延迟预算：例如在线推荐系统要求P99延迟小于20ms，而离线批处理任务可接受2秒。
- 测量单次推理的计算量：使用Profiler工具（如Nsight Systems）获取模型前向传播的FLOPs和显存访问量。
- 估算理论下限：
延迟下限 = max(计算量 / 算力, 数据量 / 带宽)。若模型为计算密集型（如大卷积），则受算力限制；若为访存密集型（如逐元素操作、小矩阵），则受带宽限制。 - 加入实际开销系数：由于kernel启动、同步、非理想调度等因素，实际延迟通常为理论下限的2~5倍。通过小规模压测校准系数。
- 选择GPU并验证：根据估算结果选择候选型号，在真实负载下用
trtexec或Triton Inference Server进行压测，观察P99延迟和吞吐。
实操提示：使用TensorRT进行推理时，可以通过trtexec --shapes=input:1x3x224x224 --fp16快速测量单张图片的延迟。注意--fp16与--int8的延迟差异可能高达3倍，但精度损失需通过校准数据集验证。
案例场景：BERT-base在线意图识别服务的硬件选型
假设我们需要部署一个BERT-base模型（约110M参数），输入序列长度128，要求P99延迟小于10ms，并发请求量约200 QPS。我们对比三种方案：
- 方案A：T4。实测FP16 TensorRT引擎延迟约8ms（batch=1），但并发超过50时延迟急剧上升至25ms，因为T4的共享内存较小，且无NVLink，多实例间通信走PCIe，导致吞吐瓶颈。
- 方案B：A10。单卡batch=1延迟约4ms，通过MIG切分为2个实例后，每个实例延迟稳定在6ms，可支撑150 QPS。但若需支撑200 QPS，仍需两张卡。
- 方案C：A100。单卡batch=1延迟约2.5ms，且支持更大的batch（如batch=8）而不显著增加延迟，单卡即可支撑300 QPS以上。虽然单卡成本高，但减少了服务器数量和运维复杂度。
最终选择A100，原因并非其峰值算力，而是其更大的L2缓存（40MB）能容纳BERT-base的中间激活值，减少对HBM的重复访问，从而在batch增大时保持低延迟。这个案例说明，延迟优化不仅是选更快的卡，更要匹配模型的内存访问模式。
误区与复盘：常见硬件选型与延迟分析错误
误区一：只看TFLOPS，忽略显存带宽。对于Transformer推理，自注意力中的QK^T矩阵乘法是计算密集的，但随后的Softmax与残差连接是访存密集的。若GPU带宽不足，Softmax会成为延迟瓶颈。例如在T4上运行BERT-large，Softmax操作耗时占比可达30%以上。
误区二：忽略MIG的隔离开销。MIG虽然提供硬件级隔离，但每个实例的L2缓存和显存带宽被分区，若模型频繁访问跨分区数据，性能可能下降20%以上。使用MIG前应测试实际工作负载，而非仅看规格表。
误区三：将batch=1的延迟直接乘以batch数来估算吞吐。GPU在batch增大时，Tensor Core利用率提升，单样本延迟可能下降（因为计算重叠），但显存带宽成为新瓶颈。正确做法是测量不同batch下的延迟-吞吐曲线，找到拐点。
复盘总结：在英伟达推理平台选型中，应遵循“先分析模型访存特征，再匹配硬件参数”的原则。对于延迟敏感型服务，优先考虑L2缓存大小、显存带宽和Tensor Core对混合精度的支持；对于吞吐优先型服务，则需关注NVLink带宽和多卡扩展效率。Ampere与Hopper架构的差异提醒我们，新一代硬件不仅提升算力，更通过Transformer引擎、TMA等机制降低数据搬运开销——这往往是延迟优化的真正突破口。