本文最后更新于28 天前，其中的信息可能已经过时，如有错误请发送邮件到big_fw@foxmail.com
本篇覆盖硬件全链路压测、模型服务压测、智算网络与多机通信测试三大板块，梳理核心工具、关键指标与排障思路
一、压测概述
1. 压测的核心价值
- 稳定性验证：检测高负载下硬件、驱动、软件是否出现崩溃、降频、数据错误
- 隐患提前发现：提前暴露散热、供电、显存、链路等隐性硬件问题
- 性能基准评估：获取极限性能指标，支撑不同配置的横向对比
- 容量规划依据：为业务上线、资源调度、参数优化提供数据支撑
2. 七层压测体系
从底层硬件到上层服务，从单机到集群，形成完整验证闭环：
| 压测类别 | 验证目标 | 核心关注指标 | 常用工具 |
|---|---|---|---|
| CPU 压测 | 计算能力、多核调度、散热稳定性 | 利用率、load、温度、bogo ops | stress-ng |
| 内存压测 | 容量、带宽、ECC 稳定性、高负载可靠性 | 内存占用、带宽、ECC 错误、OOM | stress-ng / memtester |
| 磁盘压测 | 顺序 / 随机读写性能、IO 稳定性 | IOPS、吞吐、时延、队列长度 | fio / iostat |
| 网络压测 | 带宽、时延、丢包、抖动 | 带宽、延迟、丢包率 | iperf3 / ping |
| GPU 压测 | 算力、显存、温度、功耗、满载稳定性 | 利用率、显存、温度、ECC/XID 错误 | gpu-burn / DCGM |
| 模型压测 | 服务并发能力、响应时延、Token 吞吐 | QPS、TPS、TTFT、P99 延迟 | vLLM benchmark / wrk |
| 多机通信压测 | 多卡 / 多机通信带宽与时延 | AllReduce 带宽、通信延迟 | nccl-tests / ib_write_bw |
核心思路：先测硬件资源，再测 GPU 与模型，最后验证多机通信。
二、基础硬件压测（熟练掌握）
1. CPU 压测
工具：stress-ng
# Ubuntu安装
apt install -y stress-ng
常用命令
# 全核心压测30秒，输出简要统计
stress-ng --cpu 0 --timeout 30s --metrics-brief
--cpu 0：自动使用所有逻辑 CPU 核心--timeout 30s：压测持续时长--metrics-brief：输出精简性能统计
结果关键项
bogo ops/s：每秒完成的计算操作数，衡量 CPU 计算性能usr time/sys time：用户态 / 内核态耗时successful run completed：无异常退出则测试通过
2. 内存压测
核心目标
不只是占满内存，重点验证高占用下的稳定性，排查 ECC 错误、OOM、异常重启、Swap 抖动。
常用命令
# 8个线程，每线程申请4G内存
stress-ng --vm 8 --vm-bytes 4G --timeout 30s
# 占用系统80%内存
stress-ng --vm 4 --vm-bytes 80% --timeout 30s
# 随机内存访问模式，更易排查稳定性问题
stress-ng --vm 4 --vm-bytes 80% --vm-method all --timeout 30s
关注重点
内存使用率、Swap 使用量、ECC 错误计数、系统日志、是否出现卡顿或崩溃。
3. 磁盘压测
工具：fio
apt install fio -y
顺序写测试示例
fio --name=seq_write \
--filename=/data/testfile \
--size=10G \
--bs=1M \
--rw=write \
--direct=1 \
--numjobs=1 \
--runtime=60 \
--time_based
核心关注指标
- IOPS：每秒读写操作次数
- BW（带宽）：每秒数据吞吐量
- lat（时延）：平均 / 最大 IO 延迟
- 百分位延迟：P95/P99 延迟，反映极端体验
实时状态查看：iostat
iostat -x 1
重点关注：
%util：磁盘繁忙程度r_await/w_await：读 / 写请求平均等待时间r/s、w/s：每秒读 / 写次数rkB/s、wkB/s：每秒读 / 写数据量
三、GPU 硬件压测
1. gpu-burn 压力测试工具
工作原理
基于 CUDA 开发的 GPU 压力测试工具，通过调用 CUDA Core 执行大量矩阵乘法与浮点运算，让 GPU 接近满负载状态，同时持续校验计算结果。若出现计算错误（errors>0），可定位显存错误、GPU 核心异常、供电不足、散热不良等硬件稳定性问题。
安装编译
# 解压源码包
unzip gpu-burn-master.zip
# 安装编译依赖
apt install make
# 编译（指定GPU算力架构，V100对应compute_70）
make clean && make COMPUTE=70
常用用法
# 列出系统所有GPU设备
./gpu_burn -l
# 全卡双精度测试1小时
./gpu_burn -d 3600
# 指定GPU 0，使用80%显存，测试300秒
./gpu_burn -i 0 -d -m 80% 300
结果分析
生产验收通常压测 4~6 小时，重点关注：
- errors：必须为 0；出现错误说明显存、核心或供电存在硬件问题
- Gflop/s：每秒浮点运算速度，需稳定无大幅波动
- temps：GPU 核心温度，观察是否过热触发降频
- 显存占用、功耗、风扇状态是否正常
2. CUDA Samples 验证工具
NVIDIA 官方提供的 CUDA 示例程序集，用于环境验证、基础功能与带宽测试。
2.1 deviceQuery
- 作用：枚举并显示 GPU 硬件属性，验证驱动与 CUDA 环境是否正常
- 关键输出：GPU 型号、CUDA 算力版本、SM 数量、显存容量、Warp 大小、ECC 支持、PCIe 信息
- 场景：驱动 / CUDA 安装后的第一项验证，GPU 版 “硬件自检工具”
2.2 bandwidthTest【重点】
- 作用：测试三级数据传输带宽
- Host→Device：主机内存→GPU 显存（PCIe 带宽）
- Device→Host：GPU 显存→主机内存
- Device→Device：GPU 显存内部拷贝（显存带宽）
- 典型参考（Tesla V100）：
- Host↔Device：约 12~25 GB/s（PCIe Gen3 x16）
- Device→Device：约 700~900 GB/s（HBM2 显存）
2.3 p2pBandwidthLatencyTest
- 作用：测试多张 GPU 之间 P2P（Peer-to-Peer）通信的带宽与延迟
- 核心判断：
- NVLink 直连：带宽最高、延迟最低
- 同 PCIe Switch：可 P2P，性能次之
- 跨 CPU/PHB：带宽低、延迟高
- 场景：多卡服务器必测，验证 NVLink/PCIe 拓扑互联质量
3. GPU 服务器验收标准流程【面试常问】
硬件与BMC检查
↓
nvidia-smi识别检查
↓
PCIe链路与拓扑检查
↓
CUDA Samples基础验证
↓
NV带宽测试
↓
P2P与NVLink检查
↓
NCCL集合通信测试
↓
DCGM健康诊断
↓
GPU长时间压力测试
↓
模型或业务压测
四、大模型服务压测
1. 为什么做模型压测
验证模型服务在真实请求下的并发承载能力、响应时延、Token 吞吐与稳定性，提前发现排队、超时、OOM、吞吐瓶颈，为上线容量规划与参数优化提供依据。
2. 工具：vLLM benchmark
压测命令示例
vllm bench serve \
--backend openai-chat \
--host 127.0.0.1 \
--port 8000 \
--endpoint /v1/chat/completions \
--model Qwen/Qwen2-1.5B-Instruct \
--dataset-name random \
--num-prompts 500 \
--random-input-len 512 \
--random-output-len 128 \
--max-concurrency 1 \
--temperature 0
核心参数
| 参数 | 说明 |
|---|---|
--backend | 接口类型，如 openai-chat |
--num-prompts | 总测试请求数量 |
--random-input-len | 输入 Prompt 长度（Token） |
--random-output-len | 输出 Token 长度 |
--max-concurrency | 最大并发请求数 |
3. 核心指标【面试常问】
| 指标 | 全称 | 含义 |
|---|---|---|
| Request Throughput (QPS) | 每秒请求数 | 每秒处理的用户请求数量 |
| Output Token Throughput (TPS) | 每秒 Token 数 | 每秒生成的输出 Token 数量 |
| Mean TTFT | Time To First Token | 首 Token 延迟，从请求发起到第一个 Token 返回的时间 |
| Mean TPOT / ITL | Time Per Output Token | 每生成一个 Token 的平均间隔时间 |
| Failed Requests | 失败请求数 | 正常必须为 0 |
五、AI 智算网络与多机通信
1. RDMA 基础
定义
RDMA（Remote Direct Memory Access）：让一台服务器的网卡直接访问另一台服务器的内存，绕过操作系统内核与 CPU，实现低延迟、高带宽、低 CPU 占用的数据传输。
与传统 TCP/IP 对比
| 维度 | 传统 TCP/IP | RDMA |
|---|---|---|
| 数据路径 | 经内核协议栈、多次内存拷贝、CPU 参与搬运 | 内核旁路、零拷贝、网卡硬件直接搬运 |
| 延迟 | 较高 | 极低（微秒级） |
| CPU 占用 | 高 | 极低 |
| 适用场景 | 通用业务网络 | 高性能计算、AI 分布式训练 |
GPU Direct RDMA
配合 GPU Direct 技术，网卡可直接访问 GPU 显存，数据在网卡与 GPU 显存间直接传输，尽量绕过 CPU 和系统内存，大幅提升多机 GPU 通信效率。
2. RDMA 主流实现方式对比
| 对比项 | InfiniBand (IB) | RoCE v2 |
|---|---|---|
| 底层网络 | IB 专用网络 | 标准以太网 |
| 是否基于 IP | 否 | 是（UDP/IP 封装） |
| 延迟 | 极低 | 较低（略高于 IB） |
| 吞吐量 | 极高 | 高 |
| 无损保证 | 原生无损 | 需要 PFC+ECN 等网络配置保障 |
| 成本 | 高（专用网卡 + 交换机） | 低（复用现有以太网设备） |
| 适用场景 | 超大规模 AI 集群、HPC、极致性能 | 大多数 AI 训练集群、云环境、成本敏感 |
3. InfiniBand 关键组件与运维
核心组件
- HCA 卡：主机侧 IB 适配器（如 NVIDIA ConnectX 系列），负责 RDMA 通信
- IB 交换机：专用 IB 交换设备
- Subnet Manager (SM)：子网管理器，负责 IB 网络的路径计算、LID 分配与拓扑管理
常用命令
# 安装工具包
apt install infiniband-diags opensm
# 加载驱动模块
modprobe mlx4_ib
modprobe ib_umad
# 查看IB网卡状态
ibstat
ibstatus
# 查看RDMA设备信息
ibv_devices
ibv_devinfo
【常见排障】IB 物理链路 LinkUp 但状态 Initializing：通常是缺少 Subnet Manager，启动 opensm 服务即可。
4. 多机 RDMA 带宽测试：ib_write_bw
# 服务端执行
ib_write_bw -d mlx4_0 -i 1 -D 60 -s 65536 --report_gbits
# 客户端执行
ib_write_bw -d mlx4_0 -i 1 -D 60 -s 65536 --report_gbits 服务端IP
- 核心指标：
BW average，即平均写入带宽（Gb/s）
5. 多机多卡集合通信测试：NCCL
集合通信核心操作
| 操作 | 说明 | 典型场景 |
|---|---|---|
| AllReduce | 所有 GPU 数据汇总计算，结果同步回所有 GPU | 分布式训练梯度同步（最核心） |
| AllGather | 每张卡贡献部分数据，最终每张卡都得到完整数据 | 张量并行结果拼接 |
| Reduce | 所有卡数据汇总到单张卡 | 结果收集 |
| Broadcast | 单张卡数据广播到所有卡 | 参数初始化、主节点同步 |
| ReduceScatter | 先汇总再拆分到各卡 | 大模型训练，降低显存压力 |
nccl-tests 工具使用
单机测试
# 编译
make -j$(nproc) CUDA_HOME=/usr/local/cuda NCCL_HOME=/usr
# 测试AllReduce性能
./build/all_reduce_perf -b 8M -e 1G -f 2 -g 2
多机测试
mpirun \
--allow-run-as-root \
-np 2 \
-H 192.168.32.50:1,192.168.32.72:1 \
-x CUDA_VISIBLE_DEVICES=0 \
/opt/nccl-tests/build/all_reduce_perf \
-b 8M -e 1G -f 2 -g 1
结果核心指标
- algbw：算法带宽，反映 AllReduce 实际业务性能
- busbw：总线带宽，折算后的物理通信带宽，用于横向对比
- #wrong：数据校验错误数，必须为 0
6. PCIe 降速排查
常见原因
- BIOS PCIe 配置错误，速率 / 宽度设置降级
- GPU / 网卡接触不良，金手指氧化
- Riser / 转接板故障或设计降速
- 主板 PCIe Lane 分配不足，CPU 插槽通道问题
- PCIe Switch 故障
- 节能机制导致空闲时降速（负载后恢复则正常）
- GPU 本身 PCIe 接口硬件故障
排查命令
lspci -s 04:00.0 -vv | grep -E 'LnkCap|LnkSta'
LnkCap：端口支持的最大速率 / 宽度LnkSta：当前实际运行的速率 / 宽度- 若当前宽度 / 速率低于支持的最大值，即为降速；再通过交叉换槽、换卡定位故障点。
六、汇总
- GPU 服务器上线前的完整压测验收流程是什么？ 答：先做基础硬件检查（BMC、nvidia-smi 识别、PCIe 拓扑）；再用 CUDA Samples 做环境与带宽验证；然后做 NCCL 集合通信测试；接着用 DCGM 做全量健康诊断；再用 gpu-burn 做 4~6 小时长时间满载压力测试；最后部署模型做业务压测，验证并发与时延。
- gpu-burn 的工作原理是什么？压测关注什么指标？ 答：gpu-burn 基于 CUDA，通过大量矩阵乘法和浮点运算让 GPU 满负载，同时校验计算结果。压测重点关注：计算错误数 errors（必须为 0）、Gflops 算力稳定性、GPU 温度与功耗、显存占用。
- AllReduce 是什么？和 Reduce 有什么区别？ 答：Reduce 是将所有 GPU 的数据汇总计算，结果只保存在一张 GPU 上；AllReduce 是先做 Reduce 汇总，再把结果广播回所有 GPU，最终每张卡都有完整结果。AllReduce 是分布式训练梯度同步最核心的操作。
- RDMA 相比传统 TCP 有什么优势？ 答：RDMA 绕过操作系统内核协议栈，实现零拷贝数据传输，CPU 占用极低、延迟微秒级、带宽更高。适合 AI 分布式训练、高性能计算等通信密集型场景。
- PCIe 降速常见原因有哪些，怎么排查？ 答：常见原因包括 BIOS 配置错误、硬件接触不良、转接板故障、通道分配不足、交换机问题、节能机制等。用
lspci -vv对比 LnkCap（能力）和 LnkSta（当前）判断是否降速，再通过交叉换槽、换卡定位故障点。