显卡计算能力都不懂？一文看懂 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 架构演进路线
graph LR
A[Pascal 6.x<br/>2016] --> B[Volta 7.0<br/>2017]
B --> C[Turing 7.5<br/>2018]
C --> D[Ampere 8.0<br/>2020]
D --> E[Ada 8.9<br/>2022]
E --> F[Blackwell 12.0<br/>2024]
style D fill:#90EE90,stroke:#333,stroke-width:3px
style E fill:#FFD700,stroke:#333,stroke-width:2px
style F fill:#FF6347,stroke:#333,stroke-width:2px
真正的转折点发生在 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 架构定位差异图
flowchart TB
subgraph T4["Tesla T4 (7.5)"]
t1[推理入门卡]
t2[16GB GDDR6]
t3[低功耗 70W]
t4[缺少现代特性]
end
subgraph A100["A100 (8.0)"]
a1[数据中心主力]
a2[40/80GB HBM2e]
a3[高带宽 1555GB/s]
a4[7x24 稳定运行]
end
subgraph RTX5090["RTX 5090 (12.0)"]
r1[消费级旗舰]
r2[32GB GDDR7]
r3[超高频率 2.5GHz]
r4[最新 Tensor Core]
end
style T4 fill:#f9f9f9,stroke:#999,stroke-width:2px
style A100 fill:#e8f5e9,stroke:#4caf50,stroke-width:3px
style RTX5090 fill:#fff3e0,stroke:#ff9800,stroke-width:3px
简单总结：
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 模型的工作流程：
flowchart LR
A[Query Input] --> B[Query Encoder<br/>ViT + QwenLM]
C[Document Input] --> D[Document Encoder<br/>ViT + QwenLM]
B --> E[Query Vector<br/>768-dim]
D --> F[Doc Vector<br/>768-dim]
E --> G[Cosine Similarity]
F --> G
G --> H[Relevance Score]
style B fill:#bbdefb
style D fill:#bbdefb
style G fill:#fff9c4
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 吞吐量对比
graph TB
subgraph Performance["推理吞吐量 (samples/sec)"]
T4_Result["T4<br/>12.5 samples/sec"]
A100_Result["A100<br/>156.3 samples/sec"]
RTX5090_Result["RTX 5090<br/>203.7 samples/sec"]
end
T4_Result -.->|12.5x| A100_Result
A100_Result -.->|1.3x| RTX5090_Result
style T4_Result fill:#ffebee,stroke:#f44336
style A100_Result fill:#e8f5e9,stroke:#4caf50
style RTX5090_Result fill:#fff3e0,stroke:#ff9800
注：实验室理想环境数据，实际生产环境受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 决策树
flowchart TD
A[选择 GPU] --> B{使用场景?}
B -->|在线推理| C{QPS 要求?}
B -->|离线批处理| D{预算?}
C -->|< 100 QPS| E[RTX 4090/5090]
C -->|> 100 QPS| F[A100/H100]
D -->|有限| G{能接受慢速?}
D -->|充足| H[A100 集群]
G -->|Yes| I[T4 多卡]
G -->|No| F
style E fill:#fff3e0,stroke:#ff9800,stroke-width:2px
style F fill:#e8f5e9,stroke:#4caf50,stroke-width:2px
style I fill:#ffebee,stroke:#f44336,stroke-width:2px
style H fill:#e3f2fd,stroke:#2196f3,stroke-width:2px
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👋🏻👋🏻”
