共计 1503 个字符，预计需要花费 4 分钟才能阅读完成。
背景痛点：为什么需要标准化测试？
当前大模型测试领域存在两大核心问题：
- 指标定义混乱 ：常见如将 FLOPS（理论计算量）与实际吞吐量（Throughput）混为一谈。FLOPS 是硬件理论峰值，而吞吐量受内存带宽、调度效率等多因素影响
- 环境不可复现 ：同一模型在不同机器上测试结果差异可达 300%，原因包括：
- CUDA 版本不一致
- 未隔离后台进程导致 CPU 资源竞争
- 显存碎片化未被清理
核心指标对照表
| 指标名称 | 测量方法 | 适用场景 | 典型单位 |
|---|---|---|---|
| Latency | 计算 end-to-end 推理时间取 p99 值 | 实时交互场景 | 毫秒 (ms) |
| Throughput | 单位时间处理的 token 数 | 批量处理场景 | tokens/sec |
| Memory Usage | 监控显存峰值占用（nvidia-smi） | 部署容量规划 | GB |
| Accuracy | 在标准测试集（如 MMLU）上的表现 | 模型能力评估 | 百分比 (%) |
实战测试方案
1. 环境隔离（Dockerfile 示例）
FROM nvidia/cuda:12.1-base
# 固定关键库版本
RUN pip install torch==2.1.0 transformers==4.33.0 vllm==0.2.0
# 禁用后台服务
RUN systemctl disable cron2. vLLM 测试代码片段
from vllm import LLM, SamplingParams
import time
# 关键参数说明：# - tensor_parallel_size: 对应 GPU 数量
# - max_model_len: 影响显存预分配策略
llm = LLM(model="meta-llama/Llama-2-7b-chat",
tensor_parallel_size=2,
max_model_len=2048)
# 预热（避免首次推理延迟偏高）llm.generate("warmup")
# 正式测试
start = time.time()
outputs = llm.generate(["巴黎是"]*8, # batch_size=8
SamplingParams(temperature=0))
latency = (time.time() - start)*1000 # 转毫秒 3. 监控配置（prometheus.yml 片段）
scrape_configs:
- job_name: 'gpu_metrics'
static_configs:
- targets: ['localhost:9400'] # nvidia-docker-exporter 端口 三大典型避坑案例
- 显存不足导致 OOM
- 现象：测试中途崩溃，nvidia-smi 显示显存耗尽
-
解决方案：
- 减小 max_model_len
- 启用 PagedAttention（vLLM 默认开启）
-
BatchSize 与吞吐量的非线性关系
- 当 batch_size 从 1 增加到 8 时，吞吐量可能提升 5 倍
-
但当 batch_size 超过 GPU 并行处理能力时，延迟会急剧上升
-
温度参数对延迟的影响
- temperature= 0 时（确定性输出），推理速度最快
- temperature>1 时，采样计算开销增加 20%-50%
分布式测试进阶技巧
当进行多机测试时：
- 网络带宽验证方法：
# 节点间 iperf 测试 iperf3 -c 192.168.1.2 -t 60 - 优化策略：
- 使用梯度累积减少通信频次
- 采用 3D 并行（Tensor/Pipeline/Data Parallelism）
开放讨论
当测试结果与论文数据差异 >15% 时，建议按此顺序排查：
1. 硬件配置一致性（特别是 NVLink 是否启用）
2. 软件版本差异（PyTorch/CUDA/cuDNN）
3. 测试数据是否经过相同预处理
4. 随机种子是否固定
最后留个思考题：在 8bit 量化模式下，为什么有时吞吐量反而比 FP16 更低？
正文完
