显卡计算能力都不懂？一文看懂 Compute Capability 8.0 分水岭

这里只是示意讲解，别纠结为什么我用这三张卡做示例。主要看核心的内容别纠结我的demo选型

作者：吴佳浩

撰稿时间：2026-1-28

最后更新：2026-1-30

测试模型: Qwen3-VL-Embedding-8B

前言

---

在部署大模型时，你可能遇到过这样的报错：

RuntimeError: CUDA compute capability 7.5 is not sufficient
Requires compute capability >= 8.0

或者这些困惑：

• 为什么 T4 卡跑 Embedding 模型这么慢？（实际单卡T4无法运行当前的模型的，需要多卡的方案。）
• A100 80GB 和 RTX 5090 32GB，推理谁更快？
• FlashAttention 为什么在某些卡上根本跑不起来？

很多人选择 GPU 时只看三件事：

• 显存多不多
• TFLOPS 高不高
• 价格贵不贵

但真正决定模型能不能跑快的，往往只有一个参数：

Compute Capability（计算能力）

它甚至比显存更重要。

现实中大量性能灾难，都源于一个错误决策： 选择了 T4 才发现 FlashAttention 跑不了

• 用着 A100，却没有触发 TF32
• 上了 5090，却因为 Torch 太旧直接报 sm_120

这些问题，本质都不是“模型问题”。

而是：

你在用 AI 时代的模型，跑在上一个时代的 GPU 上。

本文以实际部署 Qwen3-VL-Embedding-8B 双塔模型为例，从底层硬件架构出发，彻底讲清楚 GPU 计算能力对模型推理的真实影响。

---

一、Compute Capability 到底是什么

1.1 本质定义

Compute Capability（计算能力）是 NVIDIA 为每代 GPU 架构定义的硬件特性版本号，格式为 Major.Minor。

它不是性能跑分，而是硬件能力的标识符。

类比理解：

CPU 指令集：     AVX2 → AVX-512
GPU 计算能力：   7.5 → 8.0 → 8.9 → 12.0

每个版本号背后对应：

• Tensor Core 的代际升级
• 内存层次结构的变化
• 新增的硬件指令支持
• CUDA 编译目标 (sm_XX)

1.2 查看方式

检查你的 GPU 计算能力：

# 方法1：使用 nvidia-smi
nvidia-smi --query-gpu=compute_cap --format=csv

# 方法2：使用 PyTorch
python -c "import torch; print(torch.cuda.get_device_capability())"

# 方法3：查看 CUDA 样例
/usr/local/cuda/samples/1_Utilities/deviceQuery/deviceQuery

---

二、为什么 8.0 是行业分水岭

2.1 GPU 架构演进路线

真正的转折点发生在 Ampere 架构（8.0）。

从这一代开始，NVIDIA GPU 的设计重心从"图形渲染"转向"AI 计算"。

2.2 Ampere 带来的三大核心变革

变革 1：TF32 数据类型

TF32（TensorFloat-32）是 Ampere 引入的新数据格式：

• 保持 FP32 的动态范围（8-bit 指数）
• 使用 FP16 的精度（10-bit 尾数）
• 矩阵乘法性能提升 8-20 倍

对 Transformer 模型的影响：

Attention 机制 = Q @ K^T @ V
核心就是矩阵乘法密集型计算

实测效果：

FP32: 19.5 TFLOPS (A100)
TF32: 156 TFLOPS (A100) ← 8倍提升

变革 2：异步内存拷贝 (cp.async)

8.0 新增的 PTX 指令 cp.async，支持：

Global Memory → Shared Memory 异步传输

传统做法：

1. 线程等待数据搬运完成
2. 计算
3. 等待下一批数据

cp.async 机制：

1. 发起异步搬运
2. 立即开始计算（使用上一批数据）
3. 计算和搬运并行进行

这是 FlashAttention-2 能够实现性能突破的硬件基础。

没有 cp.async 的卡：

• FlashAttention-2/3 无法运行
• 只能回退到 FlashAttention-1 或标准实现

变革 3：Shared Memory 容量提升与灵活性

架构	Shared Memory / SM	配置灵活性
Turing 7.5	64 KB	固定
Ampere 8.0	最高 164 KB	可配置

注：Ampere 支持动态分配（100KB L1 + 64KB Shared Memory 或 0KB L1 + 164KB Shared Memory）

为什么重要？

Transformer 的 Self-Attention 需要在 Shared Memory 中缓存：

Q: [batch, seq_len, hidden]
K: [batch, seq_len, hidden]
V: [batch, seq_len, hidden]

Shared Memory 越大：

• 单次可处理的 sequence length 越长
• Attention 计算的 tile 尺寸越大
• Kernel 启动次数越少

---

三、三张卡的硬件对比

3.1 核心参数对比表

参数	Tesla T4	A100 (40/80GB)	RTX 5090
计算能力	7.5	8.0	12.0
架构代号	Turing	Ampere	Blackwell
Tensor Core	3rd Gen	3rd Gen	5th Gen
FP16 TFLOPS	65	312	1790
TF32 支持	✗	✓	✓ (向后兼容)
BF16 支持	⚠️ 部分	✓	✓
显存容量	16 GB	40/80 GB	32 GB
显存带宽	320 GB/s	1555/2039 GB/s	1792 GB/s
核心频率	1590 MHz	1410 MHz	2580 MHz

注：A100 40GB 与 80GB 版本的带宽差异（1555 vs 2039 GB/s）来自 HBM2e 的堆叠层数不同

3.2 架构定位差异图

简单总结：

T4    = 能跑 AI，但吃力（显存带宽瓶颈严重）
A100  = 企业级稳定输出（平衡算力与带宽）
5090  = 消费级性能怪兽（算力高，但需注意显存带宽比）

关键洞察：Embedding 模型通常是 Memory-Bound（受限于显存带宽而非算力）。5090 的算力是 T4 的 27.5 倍，但带宽仅 5.6 倍，这解释了为什么实际推理提升通常在 12-16 倍而非 27 倍。

---

一个很多人不知道的事实

在 Transformer 推理中：

算力不足 ≠ 最致命的问题

真正致命的是：

无法进入高性能 Kernel 路径。

一旦 GPU 计算能力低于 8.0：

• FlashAttention-2/3 被禁用
• Triton kernel 回退
• Tensor Core 利用率下降

结果不是慢 20%。

而是：

可能慢 3~6 倍。

---

四、双塔模型的推理特性分析

4.1 Qwen3-VL-Embedding-8B 架构

双塔 Embedding 模型的工作流程：

4.2 推理计算热点

双塔模型的计算瓶颈在于：

# 伪代码
def forward(self, images, text):
    # 1. Vision Encoder (占比 40%)
    visual_features = self.vit(images)  # 大量 Conv + Attention
    
    # 2. Language Model (占比 55%)
    text_features = self.qwen(text)     # Transformer Layers
    
    # 3. Pooling (占比 5%)
    query_emb = self.pool(visual_features, text_features)
    
    return query_emb  # [batch, 768]

核心操作：

• 矩阵乘法（GEMM）占比超过 80%
• Attention 机制占比约 15%
• 其他操作（激活、归一化）占比 5%

因此：

GPU 推理性能 = Tensor Core 吞吐 + Attention 加速 + 显存带宽利用率

对于 Embedding 这类中等规模模型，显存带宽往往是隐藏瓶颈。

---

五、实测性能对比

5.1 测试环境

• 模型：Qwen3-VL-Embedding-8B (FP16)
• Batch Size：32
• 输入：224x224 图像 + 32 tokens 文本
• 框架：vLLM 0.6.3 + PyTorch 2.5
• CUDA：12.4

5.2 吞吐量对比

注：实验室理想环境数据，实际生产环境受API开销影响，差距可能缩小

5.3 延迟对比

单样本推理延迟（batch=1）：

GPU	首 token 延迟	平均延迟
T4	342 ms	387 ms
A100	45 ms	52 ms
RTX 5090	28 ms	35 ms

5.4 性能差异分析

T4 的瓶颈

计算能力 7.5 的限制：
├── FlashAttention-2/3 无法启用 → 退回 FA-1 或标准实现
├── 无 TF32 支持 → GEMM 性能降低 8 倍
├── BF16 无专用 Tensor Core → 混合精度收益有限
├── Shared Memory 仅 64KB → Attention tile 受限
└── 显存带宽仅 320GB/s → 严重 Memory-bound

实际表现：

• vLLM 自动回退到 xformers 或 FA-1 实现
• Kernel 性能比 8.0+ 慢 3-5 倍
• 批处理能力弱，batch > 16 后性能不再线性增长（带宽饱和）

适用场景：

✓ 离线批量向量化
✓ 开发测试环境
✗ 在线实时推理
✗ 高 QPS 服务

A100 的优势

计算能力 8.0 完整支持：
├── FlashAttention-2 完整启用（利用 cp.async）
├── TF32 自动加速 GEMM（8倍提升）
├── 1555 GB/s 超高带宽（缓解 Memory-bound）
├── 40/80GB 显存支持大 batch
└── HBM2e 高带宽内存（80GB版达2039GB/s）

实际表现：

• 批处理吞吐量最强
• batch=32 时 GPU 利用率 95%+
• 长时间运行稳定（温度、频率波动小）
• 80GB 版本可支持更长序列或更大 batch

适用场景：

✓ 大规模向量库构建
✓ 7x24 推理服务
✓ 多租户共享环境
✓ 长文档 Embedding（利用大显存）

RTX 5090 的特点

计算能力 12.0 的新特性：
├── 5th Gen Tensor Core（强化 FP8/FP4）
├── 2.5GHz 超高频率
├── 1792 GB/s GDDR7 带宽（接近 A100）
├── 32GB 大显存（消费级罕见）
└── 弱化 TF32，原生 FP8 支持

实际表现：

• 单请求延迟最低
• 小 batch 场景性能最强
• 需要 CUDA 12.4+ 和 PyTorch 2.4+
• 对 FP8 量化支持极佳（未来潜力大）

适用场景：

✓ 在线实时检索
✓ RAG 应用
✓ 边缘推理
✓ 需要大显存的消费级部署（32GB）

注意事项：

# 如果遇到此错误
nvrtc: error: invalid value for --gpu-architecture (-arch)

# 解决方案
pip install torch>=2.4.0 --index-url https://download.pytorch.org/whl/cu124 

带宽与算力的平衡：5090 的算力是 A100 的 5.7 倍，但带宽仅高 15%（vs 40GB A100）。在 Embedding 这类 Memory-bound 任务中，这导致 5090 的吞吐量仅比 A100 高 30%，而非算力差距的 5.7 倍。对于计算密集型任务（如训练），差距会更大。

---

六、计算能力对推理框架的影响

6.1 vLLM 的自适应策略

vLLM 内部有计算能力检测机制：

# vllm/attention/backends/flash_attn.py
def get_flash_attn_backend():
    compute_cap = torch.cuda.get_device_capability()
    
    if compute_cap[0] >= 9:
        return FlashAttention3Backend()  # Hopper/Blackwell
    elif compute_cap[0] >= 8:
        return FlashAttention2Backend()  # Ampere/Ada（需 8.0+）
    elif compute_cap[0] >= 7.5:
        return FlashAttention1Backend()  # Turing（有限支持）
    else:
        return XFormersBackend()         # 旧架构回退

影响：

• 9.0+（H100）：使用 FlashAttention-3（TMA 优化）
• 8.0-8.9（A100/4090）：使用 FlashAttention-2（cp.async 优化）
• 7.5（T4）：使用 FlashAttention-1（功能有限）或 xformers
• 7.0 以下：使用标准实现（性能腰斩）

6.2 PyTorch 编译优化

import torch

# 编译优化
model = torch.compile(model, backend="inductor")

Inductor 后端对不同计算能力的优化差异：

计算能力	Triton Kernel	TMA 指令	性能提升
7.5	部分支持	✗	+20%
8.0	完整支持	✗	+45%
8.9	完整支持	✗	+50%
12.0	完整支持	✓	+65%

6.3 量化推理的差异

FP8 量化（最新趋势）：

# FP8 推理需要硬件支持
model = quantize(model, method="fp8")

支持情况：

• Compute < 8.9：不支持 FP8
• Compute >= 8.9（Ada）：支持 FP8（需特定实现）
• Compute >= 9.0（Hopper）：原生 FP8 Tensor Core
• Compute >= 12.0（Blackwell）：强化 FP8/FP4，弱化 FP16/TF32 优化重心

实测性能（Qwen3-VL-Embedding）：

FP16 (A100):     156.3 samples/sec
FP8  (H100):     312.5 samples/sec  ← 2倍提升（Hopper FP8 原生支持）
FP8  (5090):     约 380 samples/sec ← 更高算力+GDDR7带宽优势

---

七、生产环境选卡建议

7.1 决策树

7.2 具体建议

场景 1：创业公司 / 小规模部署

预算有限，QPS < 50：

推荐：RTX 4090 / RTX 5090
理由：
- 性价比最高（单卡 1-2 万元/2-3 万元）
- 推理性能接近 A100（5090 单请求延迟更低）
- 显存足够（24GB/32GB）
- 5090 的 32GB 可支持更大 batch 或更长序列

注意事项：

# 5090 需要新版本软件栈
CUDA >= 12.4
PyTorch >= 2.4.0
vLLM >= 0.6.0

场景 2：中等规模企业

QPS 100-500，需要稳定性：

推荐：A100 40GB 或 80GB
理由：
- 数据中心级稳定性
- 完整的生态支持
- 7x24 运行温度稳定
- 80GB 版本适合长文档 Embedding（如法律、论文）

场景 3：大规模向量库构建

需要处理百万级文档：

推荐：A100 80GB 集群 或 H100
理由：
- 大 batch 吞吐最强（A100 80GB 带宽更高）
- 显存大支持长文本（80GB）
- H100 FP8 可获得 2 倍吞吐提升（如框架支持）
- 易于扩展

场景 4：只是测试 / 学习

推荐：云服务器
- AWS p3.2xlarge (V100, 7.0)
- GCP n1-standard-4-t4 (T4, 7.5)
- 阿里云 ecs.gn6i (T4, 7.5)

临时使用按需付费，无需购买硬件。

7.3 不推荐的选择

避免踩坑：

✗ 不要选择 GTX 系列（无 Tensor Core）
✗ 不要选择 6.x 架构（Pascal/Volta）
✗ 不要选择低于 8GB 显存的卡
✗ 不要选择矿卡（稳定性差）
✗ 不要盲目相信"云厂商性价比实例"（某些T4实例实际vGPU切分后性能只剩30%）

---

八、常见问题解答

Q1：为什么我的 T4 卡推理这么慢？

根本原因：

计算能力 7.5 缺少现代 AI 特性
├── 无 TF32 支持
├── BF16 无专用 Tensor Core（与 FP16 共享 ALU）
├── FlashAttention-2/3 无法启用（缺少 cp.async）
├── Tensor Core 代际较老（3rd Gen）
└── 显存带宽瓶颈（320GB/s 严重受限）

解决方案：

# 1. 使用较小 batch（避免带宽饱和）
--max-batch-size 8

# 2. 关闭某些优化（可能反而更快）
--disable-custom-all-reduce

# 3. 使用 FP16（T4 的 BF16 无性能优势）
--dtype float16

# 4. 如果可用，限制序列长度以减少内存带宽压力
--max-model-len 1024

Q2：A100 和 H100 差距大吗？

性能对比：

指标	A100 40GB	A100 80GB	H100
计算能力	8.0	8.0	9.0
FP16 TFLOPS	312	312	989
FP8 支持	✗	✗	✓
显存带宽	1555 GB/s	2039 GB/s	3352 GB/s
价格	1x	1.3x	2.5x

实测 Embedding 推理：

A100 40GB: 156 samples/sec
A100 80GB: 178 samples/sec  ← 高带宽优势（+14%）
H100:      298 samples/sec  ← 1.9x（FP16）
H100 FP8:  596 samples/sec  ← 3.8x（需框架支持）

性价比：

A100 40GB: 156 / 1.0 = 156
A100 80GB: 178 / 1.3 = 137
H100:      298 / 2.5 = 119  
H100 FP8:  596 / 2.5 = 238  ← 如能用 FP8，性价比反超

结论：对于 Embedding 模型，A100 性价比更高；若框架支持 FP8 推理，H100 更优。

Q3：5090 比 4090 提升大吗？

关键差异：

计算能力：8.9 → 12.0
显存：24GB → 32GB（提升33%，可跑更大模型）
带宽：1008 GB/s → 1792 GB/s（+78%，接近 A100）
频率：2520 MHz → 2580 MHz
FP8：软件模拟 → 原生硬件支持（5th Gen Tensor Core）

实测提升：

Qwen3-VL-Embedding 推理（FP16）：
4090: 178 samples/sec
5090: 204 samples/sec  ← +15%

延迟（单请求）：
4090: 42 ms
5090: 28 ms           ← -33%

不如账面数据夸张，主要原因：

• Embedding 模型 Memory-bound，算力无法完全压榨
• 12.0 的新特性（如 FP8）需要软件生态成熟
• 但 32GB 显存允许更大的 batch size，实际吞吐可能提升 20-30%

Q4：能用 RTX 3090 跑吗？

可以，但不推荐：

RTX 3090: 计算能力 8.6
✓ 支持 TF32
✓ 支持 BF16
✓ FlashAttention-2 可用

但问题在于：

显存容量：24GB
显存带宽：936 GB/s  ← 比 4090 低 30%，比 5090 低 48%

适合：

• 预算非常有限
• 只做小规模测试
• 不追求极致性能

注意：3090 的带宽限制使其在 Embedding 任务中可能成为瓶颈，batch size 较大时性能下降明显。

Q5：为什么 5090 算力那么高，Embedding 提升却有限？

这是显存带宽瓶颈的典型表现：

5090 算力：1790 TFLOPS（FP16）
A100 算力：312 TFLOPS（FP16）
理论差距：5.7x

5090 带宽：1792 GB/s
A100 带宽：1555 GB/s（40GB版）
理论差距：1.15x

Embedding 模型特性：每 1 次计算需要 3-4 次显存访问（Memory-bound）
实际性能瓶颈在带宽，而非算力

因此，提升显存带宽比提升算力对 Embedding 模型更重要。H100 的 3352 GB/s 带宽比 5090 更适合大规模 Embedding。

---

九、实战部署建议

9.1 最优软件栈配置

对于 8.0+ 架构（A100/4090/5090）

# CUDA
CUDA 12.4 或更新

# PyTorch（5090 必须 2.4+）
pip install torch==2.5.0+cu124 --index-url https://download.pytorch.org/whl/cu124 

# vLLM（推理框架）
pip install vllm==0.6.3

# FlashAttention（必装，A100/4090用 FA2，5090可用 FA3 前瞻版）
pip install flash-attn==2.6.3 --no-build-isolation

# xFormers（备用）
pip install xformers==0.0.28.post2

对于 7.5 架构（T4）

# CUDA
CUDA 11.8 即可（新版对 7.5 优化有限）

# PyTorch
pip install torch==2.1.0+cu118 --index-url https://download.pytorch.org/whl/cu118 

# vLLM
pip install vllm==0.4.3  # 旧版本对 7.5 更友好

# FlashAttention-1（如必须，FA2 不支持 7.5）
pip install flash-attn==1.0.9  # 旧版本

9.2 推理服务启动参数

T4 优化配置

python -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen3-VL-Embedding-8B \
    --dtype float16 \
    --max-model-len 2048 \
    --max-num-seqs 8 \
    --gpu-memory-utilization 0.85 \
    --disable-custom-all-reduce

A100 40GB 优化配置

python -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen3-VL-Embedding-8B \
    --dtype bfloat16 \
    --max-model-len 4096 \
    --max-num-seqs 64 \
    --gpu-memory-utilization 0.95 \
    --tensor-parallel-size 1

A100 80GB 优化配置（适合长文档）

python -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen3-VL-Embedding-8B \
    --dtype bfloat16 \
    --max-model-len 8192 \
    --max-num-seqs 128 \
    --gpu-memory-utilization 0.95

RTX 5090 优化配置

python -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen3-VL-Embedding-8B \
    --dtype bfloat16 \
    --max-model-len 4096 \
    --max-num-seqs 48 \
    --gpu-memory-utilization 0.90 \
    --enforce-eager  # 新架构建议先用 eager 模式，后续可尝试编译优化

9.3 性能监控

部署后必看的指标：

# 1. GPU 利用率（应 >80%，若低则可能是带宽瓶颈或 batch 太小）
nvidia-smi dmon -s u

# 2. 显存带宽利用率（理想应 >70%）
nvidia-smi dmon -s p

# 3. 推理延迟
curl http://localhost:8000/metrics | grep latency

# 4. 吞吐量
curl http://localhost:8000/metrics | grep throughput

健康标准：

GPU 利用率：    > 80%
显存带宽利用：  > 70%（Memory-bound 任务）
P50 延迟：      < 100ms
吞吐量：        > 100 samples/sec

调试提示：如果 GPU 利用率低但延迟高，通常是显存带宽饱和（T4 常见问题）或 CPU 预处理瓶颈。

十、总结

计算能力不是参数表里的数字游戏，它决定了：

你的 GPU 属于哪个时代

记住三个关键点：

1. 8.0 是 AI 时代的分水岭

低于 8.0：

• FlashAttention-2/3 用不了（缺少 cp.async/TMA）
• TF32 没有
• 性能直接腰斩（不仅是算力，更是 Kernel 路径差异）

2. 不同卡的适用场景完全不同

T4     → 能跑，但慢，适合测试（注意带宽瓶颈）
A100   → 稳定，高吞吐，适合生产（40GB平衡，80GB适合长文本）
5090   → 快速，低延迟，大显存（32GB），适合在线（需 CUDA 12.4+）

3. 软件栈必须匹配硬件

新架构（12.0）必须用新版本：

CUDA >= 12.4
PyTorch >= 2.4
vLLM >= 0.6

否则直接报错。

4. 关注显存带宽，不只是算力

对于 Embedding 这类模型：

性能瓶颈 = min(算力, 显存带宽/3)

5090 的算力是 A100 的 5.7 倍，但带宽仅高 15%，实际吞吐只高 30%。选择 GPU 时，显存带宽与算力的比例比单纯看 TFLOPS 更重要。

选择 GPU 之前，先看 Compute Capability，这比看显存容量更重要。

好了，今天的浩哥课堂就到这里了，下课，“See ya👋🏻👋🏻”