基准测试脚本的设计原则

在着手编写具体的测试脚本之前，需要明确几条贯穿始终的设计原则。第一条原则是可复现性——测试脚本必须具备确定性的输入参数与环境配置，确保在不同时间、不同操作者手中执行时能得到一致的结果。这意味着脚本中不能依赖任何未经版本锁定的依赖包，不能假设特定的目录结构或环境变量，且每次执行前都应执行环境预检以排除软硬件配置漂移的干扰。

第二条原则是模块化与渐进式诊断。智算一体机的性能瓶颈可能出现在计算、存储、网络或框架层，一个笼统的“跑分”结果无法告诉运维人员问题出在哪里。因此，测试脚本应按硬件层次拆分为独立的测试模块，每个模块的输出不仅包含最终的吞吐数据，还应包含中间过程的诊断信息——例如显存带宽测试不仅要报告带宽值，还要报告在何种访问模式下达到该值，以及是否存在ECC纠错导致的性能降级。

第三条原则是面向交付场景的实用性。基准测试不是为了刷出漂亮的峰值数据，而是为了摸清系统在实际负载下的稳定性能边界。脚本应包含长时间的压力测试模式，观察性能是否随时间推移出现衰减，以及在高负载下是否有温度节流或显存溢出等异常事件发生。交付场景中，客户更关心的是“这台机器在我的模型上能跑多快”，而非“这台机器的理论浮点算力是多少”。

计算子系统的性能基线

智算一体机的核心价值在于加速卡提供的计算能力，因此计算子系统的基准测试是整个脚本体系的首要模块。测试脚本应覆盖不同精度格式的计算吞吐，包括单精度浮点、半精度浮点以及整数运算，因为不同的AI模型对这些精度格式的依赖程度差异很大——计算机视觉模型可能更依赖半精度卷积，而大语言模型则对半精度矩阵乘法与张量核心的利用率更为敏感。

在测试用例的设计上，脚本不应只运行一次就给出结论，而应采用多轮次测试并结合统计分析方法剔除异常值。对于加速卡而言，第一次运算可能因为冷启动、缓存未预热或电源管理策略而偏低，后续运算则可能因为温度升高而出现节流。脚本应记录每一轮次的性能数据，并在最终报告中呈现平均值、最大值、最小值以及标准差，让验收方能够清晰了解性能的波动范围。此外，脚本还应监测测试过程中加速卡的温度曲线和功耗曲线，如果温度超过硬件规格书中的安全阈值，或功耗长时间低于额定热设计功耗，则说明散热或供电可能存在隐患，需要进一步排查。

显存带宽与容量验证

显存带宽是影响大模型训练与推理性能的关键瓶颈之一。在许多实际场景中，计算单元并未达到理论峰值，而是因为数据从显存搬运到计算核心的速度跟不上计算速度，导致流多处理器处于等待状态。基准测试脚本应包含显存带宽的专项测试，覆盖顺序访问、随机访问以及跨NUMA节点的远程显存访问等多种模式。

顺序访问带宽反映了显存控制器在理想情况下的吞吐能力，通常最接近硬件规格书中标称的数值。随机访问带宽则更贴近实际模型运行时参数读取的特征——模型权重在显存中的分布并非连续的线性数组，而是由多个张量块组成，计算核心在遍历这些张量块时会触发大量的随机寻址。脚本应分别测试这两种模式，并计算随机访问带宽与顺序访问带宽的比例，该比值越低，说明显存控制器的随机寻址效率越差，在运行稀疏模型或动态形状模型时可能遇到性能瓶颈。

显存容量的验证同样不可忽视。脚本应通过逐块分配显存的方式，验证实际可用的显存总量是否与硬件规格一致，并测试在显存接近满载时是否存在分配失败或性能骤降的情况。某些智算一体机方案可能启用了显存纠错码或预留了一部分显存用于虚拟化管理，导致用户实际可用的显存量低于芯片标称值，脚本应如实报告这一差异，避免用户在后续部署模型时因显存预估不足而遇到问题。

互联网络带宽与延迟测试

在多卡并行训练的场景中，加速卡之间的数据交换效率直接决定了扩展比的上限。如果两张卡之间的通信带宽不足或延迟过高，即使每张卡的单卡算力再强，也无法通过增加卡数来线性提升训练吞吐。基准测试脚本应覆盖节点内卡间互联和跨节点网络通信两个层面的性能验证。

对于节点内卡间互联，测试脚本应测量不同拓扑距离下的通信带宽与延迟。在典型的八卡服务器中，相邻卡之间的NVLink带宽通常最高，而跨CPU Socket的卡间通信可能需要经过PCIe交换机或CPU内部的总线，带宽会显著下降。脚本应生成一张卡间通信矩阵，清晰展示每一对卡之间的实测带宽，帮助运维人员验证硬件拓扑是否正确配置——例如是否所有卡都连接到了预期的NVLink Switch，是否存在因线缆松动或固件配置错误导致的链路降级。

对于跨节点网络通信，测试脚本应关注集体通信原语的性能，包括AllReduce、AllGather和ReduceScatter等在大模型分布式训练中频繁使用的操作。这些原语的性能不仅取决于网络硬件（如RDMA网卡和交换机的带宽与缓存），还取决于通信库的实现效率和参数配置。脚本应在不同消息大小下测试这些原语的吞吐，并记录其随着节点数增加而变化的缩放曲线。如果随着节点数增加，通信吞吐的增长远低于线性，说明网络或通信库存在瓶颈，需要进一步调优。

AI框架与模型级吞吐测试

硬件层面的基准测试只能证明“这台机器在理论负载下能达到什么水平”，但客户真正关心的是“这台机器跑我的模型时能有多快”。因此，基准测试脚本还应包含基于主流AI框架和典型模型架构的端到端吞吐测试。

在模型选择上，脚本应覆盖计算机视觉领域的ResNet和ViT，自然语言处理领域的BERT和GPT类架构，以及多模态领域的CLIP类模型。这些模型代表了不同类型的计算模式——ResNet以卷积为主，计算密集且显存访问模式规整；BERT以Transformer编码器为主，涉及大量的矩阵乘法和注意力计算；GPT类模型则涉及自回归解码，对显存带宽和KV缓存的管理有特殊要求。通过在多种模型上运行测试，可以全面评估智算一体机在不同负载类型下的表现。

脚本应记录每个模型在训练模式下的每秒样本吞吐量、在推理模式下的首令牌延迟和每秒输出令牌数，以及在显存占用方面的表现。这些数据应与同配置的参考系统进行对比，如果差距超过一定比例（如百分之十），则需要排查是否存在框架版本不兼容、算子库未启用或环境变量配置不当等问题。脚本还应支持自定义模型导入功能，允许客户将自己的模型放入测试流程中运行，以获得最贴近实际业务场景的性能数据。

长时间压力测试与稳定性验证

基准测试不能止步于短时间内的峰值性能，因为智算一体机在实际生产环境中需要持续运行数天甚至数月。脚本应包含长时间压力测试模式，通常持续数小时到数天，以验证系统在持续高负载下的稳定性。

在长时间测试过程中，脚本应持续采集加速卡的温度、功耗、时钟频率和风扇转速等硬件健康指标，并以时间序列的形式呈现在最终报告中。如果温度在测试后期持续上升并触发节流，导致时钟频率下降和性能衰减，说明散热系统设计存在不足或机房环境温度超标。如果功耗在测试过程中出现异常波动，可能指向电源供应不稳定或电压调节模块故障。

脚本还应在长时间测试中注入一些异常场景，例如模拟显存溢出、网络闪断或文件系统写入失败等情况，观察系统是否能够优雅地处理这些异常并恢复到正常工作状态。对于训练任务，脚本应验证断点续训功能是否正常——在测试中途强制终止任务，然后从最近的一个检查点恢复训练，对比恢复后的loss曲线和吞吐是否与中断前保持一致。这些稳定性验证虽然在日常测试中容易被忽略，但在交付验收和后续运维中往往是最具价值的测试项目。

测试报告的结构化输出

基准测试的最终交付物是一份结构化的测试报告。息壤平台的基准测试脚本在每次执行完毕后，会自动生成一份包含摘要、详细数据和诊断信息的综合报告。摘要部分以简洁的表格形式呈现各项关键指标的测试结果与合格判定，便于交付经理和客户快速了解整体情况。详细数据部分则包含了每一轮测试的原始数据、统计分析结果以及性能波动曲线，供技术专家深入分析。诊断信息部分汇总了测试过程中发现的异常事件、告警信息和配置建议，为后续的调优工作提供方向。

报告的输出格式应兼顾人类可读与机器可解析。HTML格式便于在浏览器中查看和分享，JSON格式则便于导入到自动化运维系统或数据分析平台中进行横向对比。每份报告都应附带一个唯一的版本号和时间戳，以及测试环境的完整快照——包括操作系统版本、驱动版本、固件版本、AI框架版本和依赖库的锁定文件。这些元数据确保了报告的可追溯性，即使在数月之后，也能准确还原当时的测试条件和结果。

结语

智算一体机解决方案的性能基线基准测试脚本，是将硬件算力转化为可量化、可对比、可追溯的工程证据的关键工具。息壤平台通过模块化的脚本设计，覆盖了计算吞吐、显存带宽、互联通信、框架性能和长时间稳定性等多个维度，为交付验收提供了客观的评判标准。在脚本的开发与迭代过程中，始终秉持可复现性、渐进式诊断和面向交付场景的实用性原则，确保每一次测试都能产出有价值的信息，而非空洞的数字。随着智算一体机方案的硬件架构不断演进——新型加速卡、更高速的互联网络以及更复杂的存储拓扑——基准测试脚本也需要持续更新以覆盖新的性能特征。息壤平台将继续在这一领域深耕，为智算基础设施的标准化评测贡献工程实践。