看算力服务器性能基准测试指标与结果解读，先要分清服务器在训练还是推理：训练关注单位时间完成多少工作，以及增加设备后是否仍然划算；推理则要同时看处理能力和响应速度。选指标时，应先固定模型、输入数据、精度和并发条件，再比较结果。
先统一测试条件，数字才有可比性
同一台服务器，改变批量大小、数值精度或数据加载方式，成绩就可能不同。测试前记录加速器型号与数量、显存容量、处理器、内存、软件版本、功耗限制和散热状态。不同厂商或不同型号的结果，只有在工作负载与限制条件相近时才适合直接比较。
可以用固定版本的 PyTorch 和同一组模型权重开展测试。例如训练采用固定输入尺寸的图像分类模型，推理则固定提示词、输入长度和输出长度。先预热，再进行多轮计时；剔除初始化阶段，并同时记录设备监控数据。不要把理论峰值算力当成实际业务表现。
五项指标，按训练与推理分别看
1. 训练吞吐：每秒完成多少训练工作
训练吞吐可用每秒处理的样本数或 tokens/s 表示，取决于任务类型。比较时必须注明全局批量大小、精度和是否包含数据读取时间。吞吐提升但训练结果不收敛，或测试中跳过了数据准备环节，都不能说明训练效率更好。
2. 扩展效率：增加设备后收益有多大
用单卡与多卡的训练吞吐计算扩展效率：多卡实际吞吐 ÷ 单卡吞吐 × 设备数量的倒数。也可比较弱扩展，即设备增加时同步扩大工作量。效率下降，可能与设备间通信、数据供给或任务切分有关；判断时应确保两组测试的批量设置和模型一致。
3. 加速器利用率：设备是否持续有活可做
利用率可通过驱动工具或监控面板观察，但它不是越高越好：高利用率不必然等于更快，低利用率也可能是数据加载、同步等待或任务规模不足造成。应把利用率曲线与训练吞吐、显存占用一起看，重点查找周期性空闲和频繁波动。
4. 推理吞吐：单位时间能服务多少请求
推理吞吐通常以请求数/秒或 tokens/s 衡量。测试时逐步增加并发，记录吞吐何时趋于平稳、延迟何时明显上升。大批量通常有利于提高整体推理吞吐，却可能增加单个请求的等待时间，因此适合批处理的场景，不一定适合交互式服务。
5. 推理延迟：响应速度是否符合场景要求
交互式生成可记录首 token 延迟和每 token 输出间隔；普通请求服务可记录中位数与高分位延迟。平均值容易掩盖少数慢请求。测试报告应注明输入输出长度、并发数及统计口径；同一模型在不同精度、批量策略下，延迟会有明显差异。
按这个顺序完成一次可复现测试
选定真实工作负载，固定模型、权重、数据或请求样本，并写明精度与批量。
确认驱动、框架和功耗设置；先预热，避免把加载模型和初始化时间混入稳定运行成绩。
训练测试分别记录吞吐、扩展效率和利用率；推理测试逐档增加并发，记录吞吐与延迟。
重复测试并报告中位结果，同时保存配置与监控记录。若结果波动，先排查温度、频率、数据读取和其他任务占用，再下结论。
最终选型应回到实际目标：训练任务优先看有效吞吐和扩展效率；交互推理优先看延迟，批量推理则更重视稳定吞吐。算力服务器性能基准测试指标与结果解读的重点不是寻找单一冠军数字，而是确认同一工作负载下，哪台设备更符合业务限制。
常见问题
训练和推理能用同一套测试成绩比较吗？
不能直接比较。训练强调持续计算与扩展表现；推理还要考虑并发下的响应时间。
只看加速器利用率够不够？
不够。应结合吞吐、延迟、显存占用和监控曲线，判断利用率低的原因。
不同精度的结果可以放在一起排名吗？
应分开报告。精度会影响速度、显存需求和输出质量，需同时注明测试设置与质量要求。
