云GPU实例选型：根据模型大小、延迟、吞吐量选择合适实例
选云GPU，说白了就是一场「算力与预算的拉锯战」。我见过不少团队，上来就抢A100，结果模型才7B，跑起来显卡都快打瞌睡了。也见过为了省钱选了T4，结果用户等回复等得直接关页面。这一章，咱们就把这事儿拆开揉碎了讲。
模型大小：算力需求的敲门砖
模型大小直接决定了显存门槛。你想想看，一个7B模型就是70亿参数，FP16下光是权重就要占多少显存？
以FP16推理为例：
- 权重部分：7B × 2字节 = 14GB
- KV Cache：根据输入长度和批处理大小动态变化
- 额外开销：约20-30%用于中间激活和框架缓冲
我个人习惯先跑一个显存预留测试：
import torch
from transformers import AutoModelForCausalLM
model = AutoModelForCausalLM.from_pretrained(
"model-path",
torch_dtype=torch.float16,
device_map="auto"
)
# 模拟推理压力
input_ids = torch.randint(0, 32000, (4, 1024)).cuda()
with torch.no_grad():
outputs = model.generate(
input_ids,
max_new_tokens=512,
do_sample=True
)
print(f"峰值显存: {torch.cuda.max_memory_allocated() / 1e9:.2f} GB")不同规模模型的显存需求参考：
| 模型规模 | FP16权重 (GB) | 推理总显存 (GB) | 推荐实例类型 |
|---|---|---|---|
| 1-3B | 2-6 | 4-12 | T4 / L4 / A10 |
| 7-13B | 14-26 | 20-40 | A10G / A100 40G |
| 30-70B | 60-140 | 80-180 | A100 80G × 2 / H100 |
| > 70B | > 140 | > 200 | 多卡H100集群 |
这里要注意一个细节：很多模型实际跑起来会用到flash attention或vLLM这种显存优化技术，实际占用会比估算值低。但保守点总没错。
延迟：用户体验的生命线
延迟这东西，说白了就是「用户按下回车，到看到第一个token的时间」。一般分两种场景：
- 流式场景：聊天机器人、实时翻译。需要TIPS（每秒token数）高，首token延迟低。
- 非流式场景：批量数据分析、离线任务。更在意P99延迟稳定性。
为什么会这样？因为用户对等待的容忍度是线性的。你想想看，3秒出首token和5秒出首token，体验差距不是一点点。我建议用P99而不是平均延迟来评估：
# 模拟延迟测试
import time
import numpy as np
latencies = []
for _ in range(100):
start = time.time()
# 这里执行推理
gen_output = model.generate(input_ids, max_new_tokens=128)
end = time.time()
latencies.append(end - start)
latencies = np.array(latencies)
print(f"P50 延迟: {np.percentile(latencies, 50):.2f}s")
print(f"P99 延迟: {np.percentile(latencies, 99):.2f}s")不同实例的延迟表现差异巨大。我做过一个对比测试：
| 实例类型 | 首token延迟 (7B模型) | 每token生成速度 | 适用场景 |
|---|---|---|---|
| T4 | 800-1200ms | 15-25 TPS | 非实时、低预算 |
| A10G | 300-500ms | 30-50 TPS | 中等延迟要求 |
| A100 80G | 150-300ms | 60-100 TPS | 实时交互场景 |
| H100 | 80-150ms | 100-180 TPS | 高吞吐低延迟 |
吞吐量：成本效益的试金石
吞吐量讲究的是「单位时间内能处理多少请求」。计算公式很简单：
但实际操作没那么简单。我个人习惯先确定目标：
- 低成本优先：比如T4配大批次，用时间换吞吐。
- 高吞吐优先：比如A100配VLLM的连续批处理，最大化利用率。
- 平衡方案：比如L4或A10G，在成本和性能之间取中值。
这里有个关键点：批次大小和吞吐量不是线性关系。我测过一组数据：
批次大小 | A100吞吐(TPS) | T4吞吐(TPS) | 显存使用率
1 | 120 | 25 | 30%
2 | 210 | 45 | 45%
4 | 360 | 75 | 75%
8 | 420 | 100 | 95%
16 | 440 | 105 | 99%看到没？批次从8到16，A100只涨了5%，但显存快用爆了。这就是边际收益递减。
选型决策流程
好了，综合上面三点，我把自己的选型逻辑画成一张图，方便你照着走：
照着这张图走下来，基本上就能锁定2-3款候选实例。我建议再到云厂商的现有实例列表里找最接近的配置。
实战对比：A100 vs H100 vs L4
我拿一个实际项目举例。当时我们要部署一个13B的聊天模型，要求首token延迟在500ms以内，峰值吞吐要撑住300个并发用户。下面是我当时做的对比：
| 指标 | A100 80G | H100 80G | L4 24G |
|---|---|---|---|
| 单卡推理延迟 | 320ms | 180ms | 650ms |
| 最大并发数 | 8 | 12 | 4 |
| 总吞吐量 | 480 TPS | 720 TPS | 120 TPS |
| 成本(美元/时) | $3.2 | $4.8 | $1.1 |
| 成本效益 | 150 TPS/$ | 150 TPS/$ | 109 TPS/$ |
你猜我最后选了哪个？答案是A100。原因很简单：H100虽然性能猛，但成本效益和A100持平，而且当时H100资源不稳定。L4嘛，延迟都650ms了，直接超标。