训练卡的选型逻辑相对简单：算力越强越好，显存越大越好，反正预算都花在刀刃上。但推理卡的选型完全是另一套逻辑——推理服务的成本是按"每一次请求"摊薄的，选错了要么性能不够被投诉，要么性能过剩白烧钱。
更关键的是，推理和训练对硬件的需求曲线并不重合。训练看算力峰值和互联带宽，推理看显存容量和显存带宽。一张算力很强的卡用在推理上，可能还不如一张便宜的卡划算。本文把推理服务器的 GPU 选型拆成四个维度来讲：显存容量、显存带宽、算力匹配、以及单位成本核算。
一、先确立推理场景的三个关键特征
理解这三个特征，选型逻辑就清楚了。
1.1 推理是访存受限，不是算力受限
大语言模型生成文本是自回归过程：一个 token 一个 token 地往外吐。每生成一个 token，都要把模型全部权重从显存读一遍到计算单元。这意味着：
- Prefill 阶段（处理输入的 prompt）：大矩阵乘法，是计算受限，看算力。
- Decode 阶段（逐 token 生成）：batch 较小时矩阵退化成矩阵-向量乘，是访存受限，看显存带宽。
在线服务中，单个用户的体感延迟主要由 Decode 阶段决定，所以单用户交互场景下，显存带宽几乎直接等于生成速度。而当并发很高、batch 很大时，计算量重新占主导，这时算力才变得重要。结论：低延迟场景看带宽，高吞吐场景看带宽+算力。
1.2 显存容量决定"能不能跑"和"能跑多少并发"
按下面这个公式算：
推理显存 ≈ 参数量 × 每参数字节数
+ 单token KV 占用 × 上下文长度 × 并发数
+ 激活值（约 0.5~2 GB）
+ 框架开销（约 1~2 GB）
以 Llama 架构为例，单 token 的 KV 占用（FP16）大致为：7B 约 0.5 MB/token，13B 约 0.8 MB/token，70B（GQA，8 个 KV 头）约 0.31 MB/token。也就是说，7B 模型在 8K 上下文、16 并发下，光 KV Cache 就要约 64GB——远超它 14GB 的权重占用。
1.3 成本要按"每千次请求"算，不是按"每张卡多少钱"算
这是采购时最容易犯的错误。一张贵的卡如果吞吐是便宜卡的 3 倍，那么它的单位请求成本反而更低。正确的算法是：
单位请求成本 ≈ (卡的采购/租用成本 + 配套功耗与机房成本) / (该卡在目标场景下的吞吐 × 运行时长)
因此选型前必须做实测吞吐，用真实模型、真实并发、真实上下文长度压一遍，而不是看厂商标称的 TFLOPS。
二、主流推理卡的规格对比
| 型号 | 显存 | 显存类型 | 带宽 | 精度支持 | 相对采购成本量级 | 典型推理定位 |
|---|---|---|---|---|---|---|
| L4 | 24 GB | GDDR6 | 约 300 GB/s | FP8/INT8 | 低 | 视频、小模型、高并发低延迟 |
| RTX 4090 | 24 GB | GDDR6X | 约 1008 GB/s | FP16/INT8 | 低 | 单机 demo、小团队自用 |
| A10 | 24 GB | GDDR6 | 约 600 GB/s | FP16/INT8 | 中低 | 通用推理、虚拟化切分 |
| L40S | 48 GB | GDDR6 | 约 864 GB/s | FP8/FP16 | 中 | 大模型推理、多模态、图形混合 |
| A100 40G | 40 GB | HBM2e | 1555 GB/s | TF32/BF16/FP16/INT8 | 中高 | 训练+推理通用，生态最好 |
| A100 80G | 80 GB | HBM2e | 2039 GB/s | 同上 | 高 | 大模型推理主力 |
| H100 SXM | 80 GB | HBM3 | 约 3.35 TB/s | FP8/FP16/BF16 | 很高 | 高吞吐推理、训练一体 |
| H200 SXM | 141 GB | HBM3e | 约 4.8 TB/s | 同上 | 最高 | 超长上下文、超大 batch |
读这张表时注意一个反直觉现象：L40S 的算力规格不弱，但 864 GB/s 的带宽明显低于 A100 80G 的 2039 GB/s。L40S 用的是 GDDR6 而非 HBM。它在多模态、图形渲染、以及 batch 较大的推理场景表现不错，但在低延迟单条生成场景上不如 A100/H100。所以不能只看"48GB 比 40GB 大"就下结论。
三、按场景给出选型判断
3.1 场景一：内部工具，并发个位数
典型如内部知识库问答、代码辅助。特征：QPS 低、延迟容忍度高、预算敏感。
建议：单张 RTX 4090（24GB）跑 7B INT4，或单张 4090 跑 13B INT4/Q4_K_M。成本量级在所有方案中最低，普通机房即可部署。要注意消费级卡没有 ECC 显存，长时间运行的数据可靠性不如数据中心卡，因此不适合承载关键业务，但内部工具完全够用。
3.2 场景二：对外服务，中等并发
典型如客服助手、内容生成 API。特征：QPS 几十到几百、要求 P99 延迟稳定、需要 7×24 运行。
建议：优先 A100 80G 或 L40S 48G。前者带宽高、延迟低、生态成熟；后者显存大，适合需要装更大模型或更长上下文的情况。这个级别要用 vLLM 之类的推理框架做连续批处理，把吞吐提上去。数据中心卡的 ECC、长期供货和驱动支持也是对外服务的必要保障。
3.3 场景三：大模型 API，高并发多租户
特征：QPS 高、批量请求多、追求单位成本最优。
建议：H100 SXM 或 H200。理由是高吞吐场景下算力重新成为瓶颈，而 H100 的 FP8 能力和 3.35 TB/s 带宽能同时覆盖计算和访存两端。如果业务以超长上下文（32K 以上）为主，H200 的 141GB 显存可以显著减少张量并行的卡数，反而降低了总体复杂度和成本。
3.4 场景四：边缘 / 多实例切分
特征：需要一张卡服务多个互不干扰的租户或模型。
建议：A100/H100 支持 MIG（多实例 GPU），可以把一张 80G 卡硬切成最多 7 个独立实例（每个实例有独立的显存、缓存和计算资源，硬件级隔离）。这是多租户场景下的最优解之一。L4、A10 这类卡也常用于虚拟化环境下的 vGPU 切分。
# 查看 MIG 是否支持与当前状态 nvidia-smi --query-gpu=mig.mode.current,mig.mode.pending --format=csv # 开启 MIG 模式（需 root，且卡上无运行进程） sudo nvidia-smi -mig 1 # 查看可用的 MIG 实例配置 nvidia-smi mig -lgip # 创建 MIG 实例（示例：按 3g.40gb 规格切分） sudo nvidia-smi mig -cgi 3g.40gb -C # 列出已创建的实例与计算实例 nvidia-smi mig -lgi nvidia-smi mig -lci
四、推理性能的关键优化点（选卡时必须一起考虑）
同样的卡，用不用这些技术，吞吐差距可以到数倍。评估卡的时候要连同软件栈一起评估。
| 优化技术 | 作用 | 对硬件的要求 |
|---|---|---|
| 连续批处理（Continuous Batching） | 请求到达即加入批次，不阻塞等待 | 无特殊要求，框架支持即可 |
| PagedAttention | KV Cache 分页管理，减少碎片 | 无，但显存越大收益越明显 |
| INT8 / INT4 量化 | 权重显存减半到 1/4，带宽压力同降 | 需 Turing 及以后架构 |
| FP8 | 权重和激活都降到 1 字节 | 需 Ada Lovelace / Hopper 架构 |
| Speculative Decoding | 小模型草稿+大模型验证 | 需要额外显存放草稿模型 |
| 张量并行 | 多卡分担单层计算 | 强烈依赖 NVLink 带宽 |
| CUDA Graph | 减少 kernel 启动开销 | 无特殊要求 |
4.1 量化对推理的双重收益
量化不只是省显存，它同时降低了访存带宽压力。7B 模型从 FP16 到 INT4，每生成一个 token 要读的数据从 14GB 降到 3.5GB，在带宽固定的情况下理论生成速度就能提升约 4 倍。这就是为什么在推理场景，量化的收益比在训练场景大得多。
| 精度 | 7B 权重显存 | 相对 FP16 显存 | 相对 FP16 理论生成速度 | 效果损失 |
|---|---|---|---|---|
| FP16 / BF16 | 14 GB | 100% | 1x | 基准 |
| INT8 | 7 GB | 50% | 约 2x | 很小 |
| INT4（AWQ/GPTQ） | 3.5 GB | 25% | 约 3~4x | 小到中等 |
注意最后一列的"约"字：量化后算力可能成为新瓶颈，实际加速比会低于理论值。而且量化 kernel 本身有额外开销，batch 很小时收益会被抵消。
五、成本对比的正确做法
5.1 只讲量级关系，不讲具体报价
GPU 的市场价格受供需影响波动很大，任何具体数字都会很快过时。这里只给出相对量级关系，实际报价请以供应商当期报价为准：
- 消费级卡（RTX 4090 等）远低于数据中心卡的采购成本，但缺少 ECC、缺少长期供货保障、且厂商授权条款通常不允许用于数据中心。
- 同代数据中心卡中，显存越大、带宽越高的型号价格越高，且通常不是线性关系——80GB 版本的价格高于 40GB 版本的两倍是常见情况。
- 新一代（H 系列）相对上一代（A 系列）价格更高，但如果按单位吞吐计算，在高并发场景下反而可能更划算。
- 租用场景中，包月/包年通常显著低于按小时计费的累计值，长期稳定负载适合包月，峰谷明显的负载适合按量。
5.2 成本要算全，不只是卡的购置费
总拥有成本 ≈ GPU 采购或租用费
+ 服务器（CPU/内存/硬盘/主板）分摊
+ 机房机柜费（按 U 或按功率）
+ 电费（GPU 功耗 × 24h × 365 × 电价 / PUE）
+ 运维人力
+ 软件与许可（如使用商业推理引擎）
常被漏掉的是电费和机柜费。一张 700W 的 H100 满载跑一年，按 1 元/度、PUE 1.5 计算，仅电费就是：0.7 kW × 24 × 365 × 1.5 × 1 ≈ 9200 元/年。8 卡机器一年的电费就是 7 万元以上，这个数字在长期运营中不容忽视。反过来，如果 GPU 利用率只有 20%，说明大部分电费是白烧的——此时应该优先考虑提高利用率，而不是加卡。
六、选型决策步骤清单
- 明确 SLA：目标 P99 延迟是多少毫秒？峰值 QPS 多少？平均和最大上下文长度多少？
- 定模型与精度：参数量、架构（决定 KV 头数）、业务能接受的精度下限。
- 算显存：按公式算出权重 + KV Cache + 开销，乘 1.2 安全系数。
- 初筛卡型：显存能装下的型号进入候选，装不下的直接排除。
- 区分延迟型还是吞吐型：延迟型优先看带宽，吞吐型带宽和算力都要看。
- 实测吞吐：用真实模型和数据，在候选卡上各压一遍，记录 tokens/s 和 P99 延迟。
- 算单位成本：把卡的采购/租用成本 + 电费 + 机柜费，除以实测吞吐，得出每百万 token 的成本。
- 考虑运维复杂度：单卡能装下就别上多卡；需要张量并行时确保卡间有 NVLink。
- 评估长期因素：供货周期、驱动与框架生态支持、是否需要 ECC、是否要 MIG 切分。
- 小步验证：先租或先买一台跑一个月，用真实业务数据验证后再批量部署。
# 用 vLLM 自带基准测试测吞吐（替换模型路径与并发数）
python -m vllm.entrypoints.openai.api_server \
--model /data/models/llama-2-7b \
--max-num-seqs 32 \
--max-model-len 4096 \
--gpu-memory-utilization 0.92
# 另开终端跑压测
python benchmarks/benchmark_serving.py \
--backend vllm \
--model /data/models/llama-2-7b \
--num-prompts 500 \
--request-rate 20
# 压测同时采集 GPU 真实状态
nvidia-smi dmon -s pucvmet -d 2 -c 180
七、常见选型误区
- 只看显存容量，不看带宽：48GB 的 L40S 和 40GB 的 A100，在单条低延迟生成场景下后者更快，因为带宽差了将近一倍。
- 只看卡的单价，不算单位吞吐成本：贵的卡可能因为吞吐高而更省。
- 忽略功耗与机房条件：买到卡却发现机柜供电不够、散热压不住，是常见的返工原因。
- 用消费级卡承载关键对外业务：没有 ECC、无长期供货、授权条款有风险，一旦出问题代价远超省下的钱。
- 不做实测就下单：厂商标称的 TFLOPS 和实际业务吞吐之间没有简单的换算关系，必须压测。
- 显存按"刚好够"配：业务侧随时可能把上下文从 2K 提到 8K，KV Cache 会翻四倍。
小结
AI 推理服务器的 GPU 选型，核心是三句话：显存容量决定能不能跑和能撑多少并发，显存带宽决定单条请求的快慢，单位吞吐成本决定长期划不划算。
流程上，先把显存算清楚做初筛，再按"延迟型 vs 吞吐型"区分看带宽还是看算力，然后用真实业务数据实测吞吐，最后把硬件成本、电费、机柜费一起摊到单位吞吐上做最终决策。
最后给一条最实用的建议：先租后买，先小后大。用短期租用跑一轮真实业务压测，拿到自己场景的实测吞吐数据，再决定采购什么型号、采购多少张。这比任何纸面参数对比都可靠，也能避免一次性投错方向造成的浪费。
本文所列显卡规格为公开规格中的常见值，实际参数以厂商官方文档为准；成本部分仅讨论影响因素与相对量级关系，不涉及任何具体报价。
企业QQ咨询
