1. 为什么国产算力集群必须做7×24小时稳定性压测1.1 算力规模上来之后稳定性才是真正的门槛这两年国产算力集群的交付规模肉眼可见地上来了单集群几百卡、上千卡已经不算新鲜事。但跟成熟的商用加速卡方案相比国产芯片在硬件成熟度、驱动稳定性、通信库优化、框架适配这些层面仍然有大量需要在实际场景中验证的短板。很多团队在采购阶段跑个把小时的训练任务觉得性能还行就放心上线了结果真正跑起大模型训练或者推理服务之后各种玄学问题接踵而至显存ECC错误悄悄累积、网卡链路闪断、驱动偶发重置、某个节点的算力掉到标称值的一半、训练Loss莫名其妙发散。这些问题有一个共同点——单次短时测试根本复现不出来只有长时间、满负荷运转才会暴露。所以我一直坚持一个观点国产算力集群的验收绝不能只看benchmark跑分必须把稳定性测试当作一票否决项。所谓稳定性测试就是在满负荷或接近满负荷的状态下持续运行足够长的时间观察系统各项指标是否保持平稳、是否出现错误累积、是否发生故障。而这个“足够长的时间”在业内基本形成了共识——至少7×24小时也就是连续168小时不关机、不降负载、全程监控。7×24这个数字不是拍脑袋定的。服务器硬件的早期故障率曲线浴盆曲线告诉我们新设备在投入使用的最初一段时间内故障率是相对较高的。大部分隐性硬件缺陷比如内存颗粒的虚焊、电容的批次问题、散热模组的装配不良往往需要连续运行几天才会暴露。短测几天就能蒙混过关长测一周以上出问题的概率就大大提高了。此外很多软件栈层面的问题比如内存泄漏、句柄泄漏、缓存污染、未释放的锁、通信库的拥塞控制缺陷通常也是按小时甚至按天级别累积的测试时间不够长根本看不到症状。这篇文章主要面向负责算力集群交付验收、AI基础设施运维、大模型训练平台建设的同学。如果你正在用国产加速卡搭建训练集群或推理服务或者正在为采购的算力集群做验收测试这篇文章里提到的思路、方法和踩坑记录应该能帮你省下不少时间。1.2 7×24小时这个时间窗口是怎么定出来的很多刚接触稳定性测试的同事会问为什么不是12小时不是72小时偏偏是7×24小时这里有几个实际的考量。第一覆盖完整的“天级”业务周期。大模型训练任务一旦跑起来往往是以天为单位的。一个7B参数模型的预训练动辄跑几十天即便是一个微调任务也常常要跑一两天。如果只测12小时你只覆盖了白天的机房温度、电力负载、网络流量情况晚上机房温度更低、空调波动更大、ups切换测试也可能在这时候发生这些环境变量的变化对硬件稳定性的影响只有跨天测试才能捕捉到。第二覆盖“故障周期性复现”的时间窗口。我实测过不少国产加速卡有些问题表现出明显的周期性比如某个节点的通信模块每隔6到8小时会出现一次延迟尖峰或者某个驱动的内存占用每12小时涨一轮。这些问题如果没有跨越多天观察几乎不可能定位到规律。第三7天是一个便于排班的自然周期。周一开始下周一结束正好一个完整的工作循环。白班夜班交接、每日巡检记录、周末无人值守时的异常响应都能在这一轮测试中被验证。这也解释了为什么业界普遍以7×24小时作为稳定性测试的默认时长。1.3 测试分层硬件、驱动、框架、业务链路一个都不能少我在设计压测方案时习惯把稳定性测试拆成四个层次每一层都有自己的关注点和工具组合不能混为一谈。最底层是硬件稳定性。关注的是电源、散热、内存、存储、板卡加速卡/网卡在连续满负荷运转下是否出现物理层面的故障。典型表现就是ECC错误、PCIE链路降速、风扇故障、电源过温等。第二层是驱动与运行时稳定性。国产加速卡的驱动栈目前还在快速迭代中常见问题包括驱动内存泄漏、内核模块异常、用户态运行时库崩溃、任务提交接口偶发超时等。这一层的测试通常用高密度的算子调用、多进程并发提交任务来压。第三层是框架适配稳定性。PyTorch、TensorFlow等训练框架跑在国产芯片上往往需要经过厂商的适配层才能调用底层算力。框架与芯片之间的适配程度直接决定了长时间训练是否会出现显存泄漏、梯度同步超时、数据加载瓶颈等问题。这一层建议直接用真实模型训练来压用resnet这种小模型不太够看最好上大模型的训练链路。第四层是业务链路稳定性。这才回到用户真正关心的东西模型能不能稳定收敛推理服务的P99延迟能不能扛住波动多机多卡集合通信在整个训练周期内是否平滑。这一层也是最终验收最看重的结果层。四个层次的测试不是串行做的而是可以并行嵌套在一个7×24小时的窗口中。硬件和驱动的底层测试可以先用小规模跑框架和业务链路测试则用全量规模跑。这样一轮压测下来能得到一张从底层到上层的完整“体检报告”。2. 压测前的完整准备环境基线、监控体系与工具选型2.1 环境基线与健康检查清单很多团队拿到新集群就急着上负载跑压测这是大忌。压测前必须做一轮彻底的健康检查把初始状态记录下来否则压测中出了问题你根本分不清是“压出来的”还是“本来就有病”。我习惯在环境基线阶段做这么几件事硬件信息采集把每台服务器的CPU型号、内存容量、BIOS版本、加速卡型号与数量、网卡固件版本、硬盘型号、电源模块信息全部记录下来做成一个集群资产清单。这一步看似琐碎但在后续排查故障节点时能帮你快速判断是不是某一批次硬件的共性问题。固件与驱动版本核对国产加速卡的驱动和固件更新频率很高厂商经常会修复一些“只在特定场景下出现”的bug。压测前一定要统一到厂商推荐的稳定版本不要混用不同版本。特别注意检查加速卡的固件版本是否一致——同一个集群里如果存在不同固件版本的卡跑集合通信时经常会出现莫名奇妙的性能波动。基础健康检查用厂商自带的诊断工具类似nvidia-smi、rocm-smi的对应工具跑一遍完整的硬件自检确认所有加速卡都能正常识别、驱动加载无报错、设备温度在正常范围内。同时用ipmitool检查服务器整体健康状态电压、风扇转速、温度、电源状态。网络连通性测试算力集群的节点间通信主要走RoCE或IB网络。压测前需要确认所有节点之间的网络连通性正常检查是否有丢包、链路协商速率是否达标、是否有CRC错误计数增长。存储性能抽测数据集的读取和checkpoint的写入都依赖存储系统。用fio对共享存储做一轮基础抽测确认读写带宽和IOPS能满足训练任务的需求避免压测中途因为存储瓶颈导致训练中断。这几项做完之后输出一份《环境基线报告》作为后续所有稳定性判断的对照基准。后续压测中如果某个指标明显偏离基线那就是需要重点关注的对象。2.2 监控体系怎么搭硬件指标、系统指标、业务指标三级联动7×24小时压测能不能发挥价值一半取决于监控体系的完备程度。没有监控的压测等于盲跑——任务崩了只知道崩了不知道在崩溃之前系统经历了什么。我习惯搭建三级监控体系第一级是硬件监控。针对加速卡要采集核心温度、显存温度、显存利用率、算力利用率、功耗、风扇转速、ECC错误计数、PCIE带宽利用率、电源模块状态。针对服务器要采集CPU利用率、内存使用率、磁盘IO、网卡流量与错误计数。采集频率建议5秒一次太粗了看不到瞬态问题太细了存储开销大。第二级是系统监控。包括操作系统层面的一切异常内核日志dmesg、系统消息日志/var/log/messages、加速卡驱动日志、分布式训练框架日志、调度系统日志。这一级监控的核心目标是“留痕”——出了问题之后能回放日志定位根因。第三级是业务监控。对大模型训练任务要记录每一步的迭代耗时、吞吐量tokens/s或samples/s、Loss值、梯度范数、通信耗时占比。对推理服务要记录QPS、P50/P99延迟、超时率、错误率。三级监控的数据要统一汇总到一个时序数据库中比如Prometheus VictoriaMetrics再通过Grafana做可视化面板。同时要配置告警规则温度超过阈值、ECC错误计数增长、吞吐量下降超过20%、Loss连续N步不下降、通信耗时占比异常升高等都要触发告警。告警的接收人一定要包含当天的值班人员否则半夜出了问题没人响应7×24就名存实亡了。2.3 工具选型解析HPL、通信压测、LLM全量链路、服务接口压测怎么选稳定性压测的工具选择我总结下来就一句话按测试目标选工具不要一个工具打天下。峰值算力测试用HPLHigh Performance Linpack。HPL是超算领域经典的线性代数基准测试能充分压满CPU和加速卡的浮点算力同时也能暴露出散热和供电的短板。不过HPL的局限性也很明显——它是一个单机或小规模集群基准测试无法覆盖多机通信和大模型训练的真实负载特征所以只能作为压测的一个环节不能代表全部。集合通信压力测试用NCCL相关工具all_reduce_perf、all_gather_perf等或者厂商自带的通信测试工具。在多机多卡场景下集合通信往往是性能瓶颈和故障高发点。我会设计一组从2卡到全集群规模的通信压测矩阵用不同消息大小从64KB到64MB覆盖小包延迟敏感和大包带宽敏感两类场景连续跑多轮并记录P50/P99延迟和带宽的波动情况。大模型链路全量压测用真实的训练框架跑真实模型。这一步是整轮压测的重头戏。我的建议是至少跑一个LLaMA类模型比如7B或13B参数量使用和真实业务一致的并行策略数据并行、张量并行或ZeRO配上真实规模的数据集让模型真正做前向反向传播和参数更新。这样测出来的不仅仅是算力还包括框架适配性、通信稳定性、显存管理、数据加载、checkpoint保存等全链路的能力。服务接口压测用JMeter或k6。这里的场景主要是针对推理服务或者训练平台对外提供的API接口。JMeter在接口层压测中非常成熟适合做HTTP/gRPC接口的并发压力测试可以比较方便地设置线程组、观察吞吐量、响应时间和错误率。k6则胜在脚本化能力强适合做更复杂的场景编排并且资源占用远低于JMeter能起大量实例模拟高并发。我在实际使用中的体会是如果只是给推理服务做常规的接口稳定性验证用JMeter就够了如果要模拟真实用户流量模型、做阶梯加压、持续数小时的复杂场景k6更顺手。顺带提一句行业里还有monkey稳定性测试这样的概念最初来源于安卓平台的Monkey测试——随机生成大量操作事件来测试系统的健壮性。在算力集群的场景下这种思路可以借鉴比如随机地对集群中的节点做故障注入、随机地启停任务、随机地调整并发数看系统能否在“混乱”中保持稳定。不过这种测试更适合在7×24常规压测通过之后作为进阶项来做。3. 大模型链路全量压测的执行要点与参数设置3.1 全量压测的任务设计从单机单卡到多机多卡的推进节奏大模型链路全量压测是整个7×24小时测试中最核心的部分。我的建议不要一上来就全集群跑大任务而是分阶段推进每一步都确认稳定后再往前。阶段一单机单卡冒烟测试。跑15到30分钟的小规模训练任务确认环境本身没有明显问题驱动加载正常显存分配无误。阶段二单机多卡压力测试。用上单机内的全部加速卡跑数据并行或张量并行的训练任务持续2到4小时。这一步主要验证单机内的通信NVLink或PCIE Switch是否稳定显存分配是否合理。阶段三多机多卡全链路测试。扩展到整个集群使用与真实业务一致的模型规模和并行策略长时间运行。这一阶段才是真正进入7×24小时倒计时的部分。这里要特别提醒训练任务本身要设置合理的心跳和保护机制。训练进程要定期上报日志和心跳调度系统要能感知训练状态是否健康。如果训练崩溃但没有被及时感知压测的有效时长就会被浪费掉。3.2 关键参数设置与数据采集吞吐、显存、通信时延、Loss收敛在大模型全量压测中我重点关注以下几组参数吞吐量Throughput记录每秒钟处理的tokens数量或样本数量。吞吐量曲线应该是平稳的如果出现周期性下跌或持续下滑说明系统存在问题。观测周期建议每分钟记录一次聚合值既不过度占用存储又能捕捉到分钟级的波动。显存占用记录每张加速卡的显存使用率HBM utilization、显存温度、显存ECC错误计数。持续增长的显存占用是内存泄漏的典型信号ECC错误计数的持续增长则是硬件退化的信号。国产加速卡在显存ECC方面的表现参差不齐有的卡在长时间高负载后ECC错误会暴露出来这是稳定性验收中非常关键的观测点。通信时延与带宽记录每次集合通信的平均时延、P99时延和带宽。通信时延的剧烈抖动会直接导致训练吞吐下降也会加剧梯度同步的等待时间。建议在训练过程中通过NCCL或厂商提供的profiling工具定期抓取通信性能数据。Loss收敛Loss值应该按照预期趋势下降。虽然不是每一次step的Loss波动都代表问题但Loss长期不下降或者突然发散说明训练链路的某个环节出了问题需要及时排查。这里我要分享一个经验执行全量压测时建议把一次训练任务切分成多个较小的checkpoint周期每隔固定步数保存一次checkpoint。一旦训练崩溃可以从最近的checkpoint恢复不至于让前面几十个小时的算力白费。数据集也需要注意。全量压测用的数据集不要用那种已经被反复清洗过、体积小巧的玩具数据集太容易跑完然后又需要重启任务。建议准备一个规模足够大、与真实业务分布接近的数据集确保整个7×24小时周期内训练不会因为数据耗尽而停止。3.3 7×24小时执行实录我习惯的巡检节奏与记录习惯执行7×24小时全量压测时我一般会安排至少两名工程师轮流值班白班/夜班换班每2小时做一次定时巡检同时随时响应告警。巡检内容包括一次完整的巡检清单包括检查Grafana面板上的各项指标曲线是否正常查看是否有告警触发登录1到2个关键节点查看日志尾部是否有报错确认训练任务还在正常运行Loss在正常下降检查存储系统的剩余容量和IO延迟记录当前集群总功耗和机房温度。很多人觉得7×24小时压测就是“挂着跑就行”其实值班记录非常重要。我会让值班人员在每轮巡检时填写一份值班记录表表格内容包括巡检时间、训练step数、当前Loss、平均吞吐量、告警事件、异常现象描述、处理动作。这套记录在最终写压测报告时非常有价值——你可以清楚地说出系统在第几个小时内出现了什么波动而不是只知道“整体还算稳定”。另外我强烈建议把整个压测过程的核心日志保存下来。训练日志按天切分系统日志按节点归档监控数据全量保留。这些数据在压测结束后用于分析问题、生成报告、与厂商沟通问题都是最有说服力的证据。关于故障注入有些严格要求的客户会要求在7×24压测中主动做故障演练比如随机拔掉一个节点的电源、断掉一条网线、重启一台服务器观察系统能否从故障中自动恢复、训练任务能否借助checkpoint自动续跑。这种故障注入测试很有价值但建议放在压测周期中间且在业务方知情的情况下进行。4. 从压测报告到稳定性整改常见问题与排查技巧4.1 ECC错误与硬件亚健康最常见也最隐蔽的问题在我测过的国产算力集群中最常遇到的问题就是显存ECC错误。这个问题非常隐蔽因为轻微的ECC错误不会直接导致任务失败错误计数会一直增长但系统看起来还在正常运行。等到错误累计到一定程度就会出现随机性的计算错误、训练Loss发散、甚至驱动崩溃。排查思路很简单压测期间持续监控每张加速卡的ECC错误计数一旦发现某个节点持续增长立即标记为可疑节点。很多厂商提供了比nvidia-smi更详细的诊断工具可以查看更精细的错误分类。对于确认有问题的卡要么联系厂商做固件升级要么直接更换硬件。千万不要带着疑似有错的卡继续跑长训任务不然你会得到一整套无法解释的训练异常。另一个容易被忽视的硬件亚健康状态是PCIE链路降速。国产加速卡如果PCIE金手指接触不良、或者主板PCIE插槽供电不稳长时间满负荷运行后链路可能自动降速到低代际比如从PCIe 5.0降到4.0甚至3.0导致数据传输性能大幅下降。这类问题通常需要通过日志或者诊断工具查看PCIE链路状态变化来发现——在压测前后各抓一次链路状态做一次对比即可。4.2 通信抖动导致训练吞吐周期性下降多机训练中最让人头疼的问题是通信抖动。现象是训练吞吐量每隔一段时间就会出现一次明显下跌持续几十秒到几分钟然后自动恢复。这种抖动在短时测试中很难发现往往要到压测的后半段才开始显现。我的排查步骤通常是这样的先用通信压测工具比如all_reduce_perf对疑似节点之间的网络做专项测试观察是否出现延迟尖峰或带宽下降接着检查对应网卡的错误计数看是否有CRC错误、重传次数在增长再检查交换机端口的错误计数最后查看是否有其他业务流量在共享网络带宽导致拥塞。网络层面的问题需要协调网络团队一起排查。常见的原因包括RoCE网络的PFC流控配置不当、交换机缓存不足导致丢包、光纤模块光信号衰减过大、多租户共享网络导致流量干扰。通信问题往往是整个压测中最耗时的一环因为牵涉的链路很长需要多方配合。4.3 驱动重置与节点NotReady调度层面的连锁反应国产加速卡的驱动稳定性是当前整个国产算力生态中最普遍的短板之一。症状表现为驱动突然崩掉应用报错系统日志中出现驱动reset或Xid错误类似NVIDIA卡的错误事件ID然后该卡的算力消失了训练任务异常退出。严重时甚至会导致整个节点变得不可用被调度系统标记为NotReady该节点上的任务被重新调度或直接失败。这类问题的处理难度在于驱动崩溃的触发条件往往因场景而异可能是某个特定算子组合、某个显存分配模式、甚至是某个并发提交任务的时序问题。我踩过几次坑之后形成了这么一套打法压测开始前务必确认驱动版本与训练框架、通信库的兼容性。很多驱动崩溃在厂商最新版本中已经被修复所以压测前一定要咨询厂商技术支持拿到当前最优的版本组合。压测期间出现驱动reset事件后第一时间导出完整的驱动日志和系统日志不要马上重启服务。这些日志是定位根因的唯一线索。对于频繁出现reset的节点果断从压测集群中剔除先换上备用节点继续跑不要为了一个故障节点把整个压测周期拖垮。这听起来像废话但实际执行中总有人因为“再观察观察”而浪费更多时间。从调度层面也要做一些冗余设计。比如训练任务支持自动重启、自动从最近checkpoint恢复、节点故障时自动替换。这样才能保证单个节点出问题时不至于导致整个压测任务失败。4.4 压测结果怎么转化为稳定性整改清单7×24小时压测跑完后下一步是把原始数据整理成一份各方都能看懂的压测报告并且生成一份明确的整改清单。压测报告至少包含测试环境描述集群规模、软硬件版本、网络拓扑测试负载描述模型、数据集、并行策略、超参配置核心指标统计平均吞吐、峰值吞吐、稳定吞吐、训练总时长、checkpoint成功率异常事件汇总按严重程度分级列出所有压测期间发生的异常故障节点清单涉及硬件更换的、涉及驱动调整的、涉及配置修改的分类列出性能波动分析哪些时间段的性能出现了下滑下滑幅度有多大原因是什么整改建议每一项问题对应的处理方案和负责人。报告中最重要的不是过程记录而是结论。我的做法是把所有发现的问题按严重程度分级P0表示必须解决才能验收通常是硬件故障、数据错误、驱动崩溃级别的P1表示影响稳定性但不能阻止验收需要在后续持续跟踪的比如偶发的通信抖动、轻微的ECC错误增长P2表示优化建议类比如某些节点散热效率偏低建议改善机房风流组织等。把压测报告和整改清单发给厂商和硬件供应商之后一定要约定明确的整改截止时间并安排复测。稳定性问题不像性能问题修完之后复查一次就完了——很多问题在第一次整改后会以另一种形态复发。我的建议是整改完成后至少再安排一轮48小时到72小时的短周期回归测试确认问题确实解决且没有引入新的问题。最后分享一个我个人的体会国产算力集群的稳定性是一个动态演进的状态。驱动在迭代、固件在更新、框架适配在完善今天稳定的集群下个月升级一个组件后可能又出现新问题。7×24小时压测不是一锤子买卖而应该成为算力集群生命周期管理中的一个标准动作。每次硬件更换、驱动升级、大规模扩容之后都应该安排一轮或多轮稳定性回归用数据去说话。这一步做到位了后续的模型训练和推理服务才能真正跑得安心。