共计 1816 个字符，预计需要花费 5 分钟才能阅读完成。
为什么算力预估总是翻车？
每次部署新模型时，总会遇到两种尴尬情况：要么申请的云服务器性能过剩造成浪费，要么推理速度不达标被业务方投诉。上周同事在 AWS 上开了台 p3.2xlarge 跑文本分类，结果发现 GPU 利用率还不到 15%——这类问题本质都是缺乏系统的算力预估方法。
算力预估三维度
1. FLOPS：从理论计算开始
模型的理论计算量可以用 FLOPS（每秒浮点运算次数）来衡量。不同网络结构的计算公式差异很大：
-
CNN 类模型 的 FLOPS 主要来自卷积层，计算公式为：
$$\text{FLOPS} = \sum_{l=1}^{L} 2 \times C_l \times K_h \times K_w \times H_{out} \times W_{out} \times C_{l+1}$$
其中 $K_h$ 和 $K_w$ 是卷积核尺寸，$C$ 是通道数 -
Transformer 模型 的计算量集中在注意力机制：
$$\text{FLOPS} ≈ 4 \times d_{model} \times L \times n_{heads} \times (d_{head} \times seq_len)^2$$
实际使用时建议用thop库直接统计（示例代码见后文）
2. 内存占用：显存的隐形杀手
模型运行时内存分为两部分：
- 权重内存：容易计算，例如 FP32 的 ResNet50 约需要(2500 万参数×4 字节)=100MB
- 激活内存：常被忽略但更致命，BERT-large 在序列长度 512 时激活内存可达 3GB
推荐用这个 PyTorch 代码片段实时监控：
def get_gpu_memory():
import torch
return torch.cuda.memory_allocated() / 1024**2 # 转换为 MB
# 在 forward 前后调用
mem_before = get_gpu_memory()
output = model(input)
mem_used = get_gpu_memory() - mem_before3. 推理延迟：别被理论值欺骗
实验室测得的理论 FLOPS 和实际延迟可能差 10 倍，因为：
- 框架开销（如 TensorFlow 的 session 初始化）
- 数据传输成本（CPU-GPU 通信）
- 并行度利用不足
测试时务必用真实输入尺寸，并运行 100 次取平均值：
import time
times = []
for _ in range(100):
start = time.time()
model(input_tensor)
torch.cuda.synchronize() # 确保 GPU 计算完成
times.append(time.time() - start)
print(f"平均延迟：{sum(times[10:])/90*1000:.1f}ms") # 跳过前 10 次预热生产环境避坑清单
这些坑我基本都踩过：
- 忽略批处理效应：batch_size= 1 时 GPU 利用率可能只有 30%，但增大 batch 又可能增加延迟
- 未量化模型：FP32 模型比 INT8 版本多占 4 倍内存，但精度可能只差 0.5%
- 框架选择失误：某些模型在 ONNX Runtime 上的速度比原生 PyTorch 快 3 倍
- 冷启动问题：AWS Lambda 等无服务器方案第一次调用可能有秒级延迟
云服务商选型秘籍
主流云平台的 vCPU-GPU 换算经验值（以 resnet50 推理为基准）：
| 云厂商 | GPU 类型 | 等效 vCPU | 适合场景 |
|---|---|---|---|
| AWS | T4 | 8 核 | 低成本推理 |
| P100 | 16 核 | 中等负载训练 | |
| Azure | V100-32GB | 32 核 | 大模型微调 |
动手实验
现在用你的模型运行这个测试脚本：
# 综合测试脚本
model.eval()
input = torch.randn(1, 3, 224, 224).cuda() # 替换为你的输入尺寸
# 计算 FLOPs
from thop import profile
flops, params = profile(model, inputs=(input,))
print(f"FLOPs: {flops/1e9:.1f}G Params: {params/1e6:.1f}M")
# 内存测试
torch.cuda.reset_peak_memory_stats()
_ = model(input)
print(f"峰值显存: {torch.cuda.max_memory_allocated()/1024**2:.1f}MB")
# 延迟测试
...（接上文延迟测试代码）建议对比不同 batch_size 下的显存和延迟变化，找到性价比最高的配置点。实际部署时记得预留 20% 余量应对流量峰值。
