EP04 | 测压与Benchmark:试驾比看参数重要

EP04 | 测压与Benchmark:试驾比看参数重要

16分钟 ·
播放数6
·
评论数0

节目简介
机器点亮不等于能卖。压测是把"能开机"变成"能交付"的关键环节。用"买车试驾"类比讲透压测的三层目标和完整流程。

本期要点

  • 🎯 测压三层目标:硬件稳定性验证 → 性能验证 → 商业可交付验证

  • 📋 完整压测流程:验机 → 单项基线测试 → 多卡通信测试 → 业务场景测试 → 长稳测试

  • 🧰 工具速览:gpu-burn 测 GPU、fio 测磁盘、iperf3 测网络、NCCL Tests 测多卡通信

  • 📊 训练 vs 推理 benchmark 看什么:samples/s、tokens/s、QPS、p95 延迟

  • ⏱️ 长稳测试为什么至少 4-12 小时:短时间能跑不代表长时间稳定

  • 💬 怎么把技术测试结果翻译成客户听得懂的销售材料

  • 📝 测试报告的基本结构

推荐收听场景 要验收服务器或准备交付材料时

这一页要解决什么问题

把“服务器能亮机”升级为“服务器能稳定交付、能拿来卖、能支撑客户业务”。


一、测压的三层目标

1. 硬件稳定性验证

  • 是否掉卡

  • 是否过热

  • 是否降频

  • 是否存在 ECC 错误

2. 性能验证

  • 单卡性能

  • 多卡性能

  • 多机通信性能

  • 推理吞吐和时延

3. 商业可交付验证

  • 是否能形成客户看得懂的测试报告

  • 是否能证明“值这个价”


二、压测前先做的准备

1. 记录机器基础信息

至少记录:

  • 服务器型号

  • CPU 型号

  • 内存容量与频率

  • GPU 型号、数量、显存

  • 主板 / BMC 版本

  • 网卡型号与速率

  • 系统版本

  • 驱动版本

  • CUDA 版本

  • Docker / 容器环境版本

建议保留:

  • nvidia-smi

  • lscpu

  • lsblk

  • free -h

  • ip a

  • ethtool

这些输出作为测试报告附件。

2. 明确测试目标

先分清楚这台机器要服务什么场景:

  • 验收新采购机器

  • 卖整机前做稳定性验证

  • 做 GPU 算力租赁上架前测试

  • 面向训练客户做训练性能验证

  • 面向推理客户做吞吐与时延测试

不同目标,测试项不同。

3. 明确验收判定标准

在测试前就先写清楚:

  • 连续跑多久算通过

  • 温度上限多少

  • 是否允许单次波动

  • 是否允许 ECC 报错

  • 是否要求多卡性能接近

  • 是否要求网络吞吐达到某个阈值


三、测压分类

A. 基础硬件测压

  • GPU burn

  • CPU stress

  • 内存压力

  • 磁盘 IO

  • 网络吞吐

B. AI 场景测压

  • 训练 benchmark

  • 推理 benchmark

  • 多并发测试

  • tokens/s

  • latency / p95 / p99

C. 长稳测试

  • 长时间运行

  • 温度与功耗观察

  • 异常日志记录


四、实操版测试项清单

1. 基础验机

目标:确认硬件识别正常、配置与采购单一致。

检查项:

  • GPU 是否全部识别

  • GPU 显存是否一致

  • GPU PCIe 速率 / lane 是否正常

  • CPU / 内存是否识别完整

  • NVMe / 磁盘是否识别完整

  • 网卡速率是否符合预期

  • 驱动与 CUDA 是否正常

常用工具:

  • nvidia-smi

  • lspci

  • lscpu

  • dmidecode

  • lsblk

  • ethtool

重点看:

  • 有无少卡

  • 有无掉速

  • 有无异常告警


2. GPU 稳定性测压

目标:确认 GPU 能持续高负载运行,不掉卡、不异常降频。

建议测试:

  • 单卡满载

  • 多卡满载

  • 连续运行 30 分钟 / 1 小时 / 4 小时

常用工具:

  • gpu-burn

  • nvidia-smi dmon

  • dcgmi / DCGM

重点指标:

  • GPU utilization

  • 温度

  • 功耗

  • 时钟频率

  • ECC 错误

  • Xid 错误

通过标准示例:

  • 全部 GPU 都能稳定满载

  • 无掉卡

  • 无 Xid 错误

  • 无持续异常降频

  • 温度处于可接受范围


3. CPU / 内存稳定性测压

目标:确认 CPU 和内存没有明显硬件隐患。

常用工具:

  • stress-ng

  • sysbench

  • memtester

重点指标:

  • CPU 满载稳定性

  • 内存压力下是否报错

  • 温度是否异常

  • 系统是否死机 / 卡死


4. 磁盘 / NVMe IO 测试

目标:确认本地盘满足训练缓存、数据加载、日志写入等需求。

常用工具:

  • fio

重点测试:

  • 顺序读写

  • 随机读写

  • 不同 block size

  • 不同 queue depth

重点指标:

  • 带宽

  • IOPS

  • latency

  • p95 / p99 latency


5. 网络测试

目标:确认服务器网络没有成为训练/集群瓶颈。

常用工具:

  • iperf3

  • ib_write_bw

  • ib_read_bw

  • ib_send_bw

  • ethtool

适用场景:

  • 单机上架前网络验收

  • 多机训练前的网络基线测试

  • RoCE / InfiniBand 性能验证

重点指标:

  • 吞吐带宽

  • 延迟

  • 丢包

  • 多流并发时表现


6. GPU 通信测试

目标:确认多卡、多机训练时 GPU 间通信正常。

常用工具:

  • NCCL Tests

    • all_reduce_perf

    • all_gather_perf

    • reduce_scatter_perf

重点指标:

  • bus bandwidth

  • alg bandwidth

  • 多卡一致性

  • 是否存在明显异常卡

适合:

  • 8 卡整机验收

  • 训练型服务器性能确认


7. 训练场景 Benchmark

目标:确认在真实训练场景下的吞吐和扩展效率。

常见方式:

  • PyTorch DDP 训练 demo

  • Megatron / DeepSpeed / vLLM 相关测试

  • 选一个小型公开模型做固定训练任务

重点指标:

  • samples/s

  • tokens/s

  • step time

  • scaling efficiency

  • GPU 利用率

适合回答:

  • 这台机器训练值不值这个价?

  • 多卡扩展效率是否正常?


8. 推理场景 Benchmark

目标:确认这台机器适不适合拿来卖推理算力。

常见方式:

  • vLLM benchmark

  • TensorRT-LLM benchmark

  • Triton Inference Server 压测

  • 自建 API 并发压测

重点指标:

  • QPS

  • tokens/s

  • 首 token 延迟

  • 平均延迟

  • p95 / p99 延迟

  • 并发下吞吐变化

  • 单卡/多卡成本效率

适合回答:

  • 这台机器更适合训练还是推理?

  • 在目标模型下,商业价值如何?


9. 长稳测试

目标:确认机器不是“短时间能跑”,而是“能稳定交付”。

建议时长:

  • 最低:4 小时

  • 推荐:12 小时

  • 更严谨:24 小时或更长

重点观察:

  • 有无掉卡

  • 有无驱动异常

  • 有无过热降频

  • 有无系统重启

  • 有无网络异常


五、建议工具清单

基础信息采集

  • nvidia-smi

  • lspci

  • lscpu

  • lsblk

  • dmidecode

  • free -h

  • uname -a

GPU / 系统监控

  • nvidia-smi dmon

  • DCGM / dcgmi

  • Prometheus + Grafana

  • dmesg

  • journalctl

压测工具

  • gpu-burn

  • stress-ng

  • sysbench

  • memtester

  • fio

  • iperf3

  • NCCL Tests

AI 场景工具

  • PyTorch

  • vLLM benchmark

  • TensorRT-LLM benchmark

  • Triton Inference Server


六、推荐测试顺序

第 1 步:验机

  • 看配置是否与采购一致

  • 看驱动与环境是否正常

第 2 步:单项基线测试

  • GPU

  • CPU / 内存

  • 磁盘

  • 网络

第 3 步:多卡 / 通信测试

  • NCCL

  • 多卡满载

第 4 步:业务场景测试

  • 训练 benchmark

  • 推理 benchmark

第 5 步:长稳测试

  • 观察异常与波动


七、结果怎么判定

1. 看是否“能跑”

最低标准:

  • 不报错

  • 不掉卡

  • 不死机

2. 看是否“稳定”

进阶标准:

  • 长时间负载下没有明显异常

  • 多卡表现没有明显短板卡

  • 温度和功耗曲线可控

3. 看是否“有商业价值”

最终标准:

  • 指标能转化成客户价值

  • 能与同类 GPU / 同类整机比较

  • 能支撑报价逻辑


八、怎么出测试报告

报告结构模板

1. 测试目的

  • 新机验收 / 上架前验证 / 客户报价支持 / 故障排查

2. 测试环境

  • 服务器型号

  • CPU / 内存 / GPU / 存储 / 网卡

  • OS / Driver / CUDA / 框架版本

3. 测试方法

  • 使用工具

  • 使用参数

  • 每项测试时长

  • 并发设置

4. 测试结果

  • GPU 稳定性

  • CPU / 内存

  • 磁盘

  • 网络

  • 多卡通信

  • 训练/推理业务结果

5. 异常记录

  • 掉卡

  • Xid

  • ECC

  • 降频

  • 网络异常

6. 结论

  • 是否通过验收

  • 是否适合训练

  • 是否适合推理

  • 是否需要整改

7. 附录

  • nvidia-smi

  • dmesg

  • benchmark 原始日志


九、一个简版报告示例骨架

  1. 测试环境

  2. 机器配置

  3. 驱动 / CUDA / 框架版本

  4. 测试工具与参数

  5. 核心结果

  6. 异常情况

  7. 结论与建议


十、如何把测试结果变成销售材料

不要只写“跑分多少”,而要写成客户听得懂的话:

技术表达

  • 8 卡满载稳定运行 12 小时

  • NCCL 多卡通信正常

  • 单机推理吞吐达到 XX

销售表达

  • 可稳定支持 XX 规模模型推理

  • 适合企业私有化部署

  • 可用于高并发推理业务

  • 已完成长稳压测,适合上架交付


十一、我后续要重点补充

  • 常用工具清单

  • 训练场景指标体系

  • 推理场景指标体系

  • 典型故障与排查路径

  • 测试报告模板


十二、学习时重点关注

  1. 什么样的测试结果对客户有说服力?

  2. 跑分高不等于客户场景表现好,为什么?

  3. 如何把技术测试转化成销售材料?