说实话接到这个任务的时候我心里是有准备的但真正跑完这七天还是有很多没想到的地方。国产算力集群的稳定性测试和以往在常规GPU集群上做压测完全是两种体验工具链要自己拼、监控要自己搭、驱动日志要自己啃。这篇就把我们这次7×24小时压测的完整过程写出来从指标设定、工具选型、执行编排到问题排查希望能给正在做或者准备做国产算力集群稳定性测试的朋友一些参考。1. 国产算力集群稳定性测试到底在测什么1.1 为什么“能跑通”和“扛得住”是两回事很多团队对稳定性测试有个误解觉得功能测试都过了接口也通了模型推理结果也正确那系统就是稳定的。但长期压测要暴露的恰恰是功能测试覆盖不到的那类问题性能衰减、资源泄漏、累积性故障。拿我们这次测试的大模型推理链路举例。功能测试阶段一条请求进来模型正常返回耗时200毫秒看起来一切正常。但当你用固定并发持续压测几小时后问题就开始冒头显存碎片越来越多KV Cache的分配策略开始退化算子调度出现间歇性等待最终表现就是QPS从最初的900一路跌到350响应时间的P99从300毫秒涨到3秒。这种问题是功能测试无论如何都发现不了的因为它不是“坏了”而是“慢慢变差了”。所以7×24小时长稳测试关注的核心是三件事性能是否随时间衰减、是否存在累积性资源泄漏、故障发生时系统能不能自愈或被快速拉起。1.2 国产算力集群和常规GPU集群的差异决定了方案不能照搬这句话我说得很直白如果你之前做过GPU集群的压测然后把那套方案原封不动搬到国产算力集群大概率会踩坑。第一个差异是监控体系。常规GPU集群有DCGM、nvtop这些成熟工具指标采集开箱即用。国产加速卡这边不同厂商提供的能力不一样有的有类似DCGM的exporter有的只给一个CLI工具指标得自己解析甚至有些功耗、温度、显存利用率的核心指标要自己写脚本去读系统接口。第二个差异是软件生态。驱动和运行时SDK的API命名、日志规范、错误码定义各家有各家的风格网上能搜到的资料也少。遇到一个奇怪的错误码可能就要翻厂商SDK头文件或者提工单才能确认含义。第三个差异是互联拓扑。国产集群的集合通信性能和卡间互联拓扑和NVIDIA的NVLinkInfiniBand方案差别很大。全链路压测的时候多卡并行推理的通信瓶颈会出现在意想不到的地方这直接决定你要不要调整请求分发策略。也就是说做国产算力集群压测不能只盯着业务层指标必须有一套覆盖硬件健康状态、驱动日志、通信库状态的监控方案这些在后面会详细讲。2. 压测目标与指标基线动手之前先想清楚三个问题2.1 并发数怎么确定阶梯加压才是正路我最担心看到的就是有人拍脑袋定并发数比如“线上有500个用户那就压500并发”。这个思路的问题在于并发数根本不是一个静态数值它取决于系统资源、业务复杂度、模型推理时长。拿大模型推理来说一个请求要占用显存里的KV Cache空间并发数太高直接OOM并发数太低又跑不满算力这个最优值必须在压测中找出来。我们用的是阶梯加压法这个过程也是热词里经常提到的“怎么确认系统并发数”的实操答案。具体分三步第一步从1个并发开始每5分钟增加10个并发持续观察TPS每秒事务数和响应时间的变化。最开始TPS会随并发线性增长增长到某个点之后TPS的增长幅度会明显放缓这个拐点就是系统的软极限。第二步在拐点附近做细粒度加压比如每次只加2个并发把拐点的位置确认到尽量精确。这个数值你后面定目标并发时要用。第三步继续加压到系统开始大量报错或者P99响应时间急剧恶化记下这个饱和点。这个点的价值是让你知道系统离崩溃还有多远。最后7×24小时长稳测试的目标并发建议定在拐点值的70%到80%而不是顶着饱和点跑。原因很简单长稳测试的目的是暴露隐患不是证明系统能扛住极限。你顶着极限跑7天大概率第一天就把集群跑挂了什么都验证不了还得花两天恢复环境。2.2 指标体系不能只盯QPS和CPU长稳压测的指标要分成四层来看缺一层都容易出盲区。业务层TPS、响应时间P50/P95/P99、错误率、超时率。这是最直观的也是给老板看的核心数据。系统层CPU使用率、内存占用、磁盘IO和磁盘剩余空间、网络带宽和连接数。重点是看有没有缓慢增长的趋势。硬件层芯片温度、功耗、显存占用、ECC纠错次数、风扇转速、PCIe链路错误计数。这些指标在普通压测里经常被忽略但长稳测试里恰恰是关键。芯片温度受机房空调策略影响夜间温度波动可能触发降频显存占用如果随时间单边上涨基本就能断定有显存泄漏。框架层这是大模型链路特有的包括排队请求数、实际Batch Size、首Token延迟TTFT、Token间延迟TPOT、KV Cache命中率。我们可以用京东那种削峰填谷的比喻来讲指标趋势QPS可能一直在波动但波动不能有单边下行的趋势显存占用可以有波峰波谷但谷底必须回到初始水平温度可以随负载变化但变化幅度不能超过硬件规格。3. 压测工具选型与脚本设计从JMeter到k6再到自研中间层3.1 JMeter做协议层压测的边界在哪里JMeter是绝大多数人接触压测的第一个工具它的生态确实完善HTTP、WebSocket、gRPC都有对应的Sampler而且有图形界面配置线程组加监听器就能跑。简单场景下JMeter压测的基本步骤就是创建线程组、配置并发数和循环次数、添加HTTP请求Sampler、添加聚合报告和结果树、启动并查看结果。这套流程对普通Web接口完全够用。但到了大模型推理链路JMeter的短板非常明显。首先是资源开销JMeter本身是Java写的单机模拟高并发时JVM内存和GC开销都很大跑7×24小时还要考虑JMeter自身会不会先挂掉。其次是协议支持大模型推理走的是流式响应客户端要解析SSEServer-Sent Events数据流还要处理多轮对话中动态拼接的PromptJMeter写这些逻辑非常别扭。第三是分布式压测的数据汇聚用JMeter分布式模式跑长稳Agent的角色胜率要看网络可靠性Agent挂掉一个压测数据就不连续了。所以我们的定位是JMeter可以用来做网关层的短时专项压测比如验证某个API的限流配置是否正确或者压测鉴权服务的并发上限。但全链路长时间压测我们换成了别的方案。3.2 k6在长稳场景下的优势k6是我们这次重点使用的开源工具它在长稳场景下的优点值得一说。第一k6的并发模型基于Go协程单机支撑的并发数远超JMeter而且自身资源占用很低跑7天基本不操心。第二脚本用JavaScript编写写起来比JMeter的XML配置直观得多而且支持模块化组织场景。第三内置的阈值触发机制很适合长稳测试——你可以设定“错误率连续5分钟超过5%就自动停止”这在夜间无人值守时太重要了。k6还有一个好处是结果导出方便可以一键导出到Prometheus远程写入端点或者通过StatsD协议推送到InfluxDB省去自己写采集脚本的麻烦。我们用k6做了网关层的长稳压测脚本里通过stages配置渐进式加压比如前30分钟从0升到目标并发然后维持48小时再逐步降为0整个加压曲线在Grafana里看非常清晰。3.3 大模型链路全量压测为什么必须自研中间层虽然k6很好用但覆盖不了全链路。大模型推理的请求和普通HTTP请求最大的区别是请求内容动态变化Prompt长度随机、输出长度随机、多轮会话有上下文依赖。用压测工具硬编码URL和参数根本模拟不出真实业务形态。我们的做法是自研了一个基于Python asyncio的压测客户端。这个客户端做的事情是从Kafka回放线上真实日志流量每条请求根据业务分布动态生成不同长度的Prompt随机模拟多轮对话通过流式接口读取结果并校验响应内容摘要。它本身也内置了并发控制模块可以在运行过程中动态调整并发数不需要重启任务。这里要澄清一个点不是说JMeter和k6没用而是它们属于组件级工具适合定点验证全链路压测必须要有能够模拟真实流量特征的“流量产生器”。这个中间层是压测方案里投入成本最高的部分但也是价值密度最高的部分。4. 7×24小时长稳压测的完整执行过程4.1 压测前的环境清洗与基线验证长稳压测最忌讳的就是在环境不干净的时候直接开跑。我们的准备流程是这样的第一步确认集群上没有其他任务。这一点容易忽视很多集群有自动调度系统你以为这块区域闲置了结果半夜调度器又塞了一个训练任务进来压测数据全废了。我们是在测试开始前手动检查了集群的作业列表并且在测试期间给这个队列加了作业提交白名单。第二步统一镜像和权重记录启动日志。确保每台节点上跑的推理服务镜像相同、模型权重一致、配置文件版本锁定。这个步骤看起来很基础但真出问题的时候你会庆幸自己留了基线。第三步先跑30分钟短时压测做校准。把目标并发先拉起来看当前系统的QPS、响应时间、错误率是否和之前小规模测试的结论一致。如果差距超过10%先排查环境差异不要带着问题启动长稳。第四步检查时间同步。所有节点统一的NTP时间校准这点长稳测试里特别关键。7天的日志如果时间基准都不一致问题定位时看谁先谁后都看不出来。第五步检查日志轮转和磁盘空间。7天跑下来推理服务的access log、错误日志、监控agent的采集日志加起来可能塞满几百G。我们提前配置了logrotate策略确保日志不会写满磁盘导致服务异常。这一步我在多个项目里都踩过坑建议当成SOP固定下来。4.2 分四个阶段推进的编排逻辑7×24小时不是简单地把压测工具开着跑一天而是分成四个阶段每个阶段有明确的验证目标。阶段一第1到12小时1倍目标并发观察各层指标是否平稳。这个阶段的主要任务是建立正常基线并把监控告警配置调准确。如果前期有漏配的指标前12小时还能补救。阶段二第12到48小时把并发提到目标值的1.2倍做超负荷试探。这个阶段是资源泄漏最容易暴露的时间窗。以显存为例如果存在泄漏12到48小时内曲线会呈现明显的阶梯式上升。为什么要加压到1.2倍因为有些泄漏在低负载下不明显只有在高压力下才会因为资源分配更加频繁而显现。阶段三第48到120小时回到目标并发稳定运行重点观察夜间环境变化的影响。机房的空调策略一般不会为压测单独调整夜间的温度波动、供电波动都会在这时候体现出来。我们这次就在这个阶段抓到了一个小问题某一排机柜在凌晨温度偏高导致部分芯片小幅降频虽然没影响业务但确认了冷却系统的余量不足。阶段四第120到168小时混合场景冲刺模拟业务高峰和低峰交替并在低峰时段插入突发流量脉冲。这个阶段验证的是系统应对真实业务节奏的能力而不是均匀载荷下的稳定性。4.3 七天里真实遇到的三个典型问题第一个是显存泄漏。现象从第二个阶段开始QPS从900逐步回落到350但奇怪的是芯片利用率和显存占用一直往上走。我们在国产加速卡的监控工具里看到显存占用率的曲线呈现锯齿状上升每处理一批请求释放的显存比分配的要少一点。排查思路是先定位是哪个模块泄漏用详细的性能分析工具抓算子级别的显存分配最终定位到一个自定义的归一化算子没有释放中间张量。修复验证的方法是连续观察48小时确认显存曲线恢复平稳。第二个是句柄耗尽。跑到第60小时左右新请求开始大量连接超时日志里出现了很多包含“too many open files”的报错。我们先用lsof统计了进程的文件句柄数发现它从初始的1500涨到了接近系统上限65535。根因是推理服务的HTTP客户端在长时间运行后健康检查逻辑存在缺陷每次探测都新建连接但对旧连接只做了关闭标记没有真正调用close。长稳测试最大的价值就在这里小程序在功能上完全正确但长时间运行就会让资源耗尽类问题暴露。第三个是加速卡在运行72小时后被系统自动隔离。现象是某台节点的算力单元从集群状态中消失整体QPS瞬间下降了15%但服务没有完全中断。通过厂商提供的固件日志排查确认是卡的温度过高触发了硬件保护机制保护机制主动把算力单元置为不可用状态等待冷却后重新初始化。根因是这排机柜的散热策略配置不当机柜尾部热空气回流严重。调整方案包括修改空调出风策略、增大机柜风扇转速、调低温度保护的触发阈值并在监控里新增了卡温度变化率指标温度在5分钟内上涨超过15度就提前告警。这三个问题有一个共同特点都不是“瞬间崩溃型”故障而是“缓慢劣化型”故障恰好是7×24小时长稳测试必须抓的问题。5. 监控告警与日志收集5.1 监控体系怎么搭才能覆盖全维度监控是长稳压测的生命线不是可选项。我们的监控体系包含三层。底层是数据采集。Prometheus作为核心时序数据库业务指标通过自研压测客户端的Prometheus端点暴露系统指标用node_exporter采集硬件指标用国产加速卡厂商提供的exporter采集。这里强调一句国产卡的硬件指标尽量用厂商原生的exporter不要自己写脚本去解析系统接口因为不同版本的固件输出的格式可能变化你会花大量时间在调试采集程序上。中间层是告警规则。我们建了一套分级告警规则核心指标包括芯片温度、显存占用率、QPS趋势、P99响应时间、错误率。所有告警都配置了持续时间条件比如错误率必须连续5分钟超过5%才触发避免瞬时抖动导致的告警风暴。上层是可视化看板。Grafana看板拆成两页第一页是业务总览包含QPS、错误率、响应时间分布适合给团队和管理层看第二页是硬件健康矩阵把每台节点的温度、功耗、显存、ECC错误用热力图方式展示一眼能看出哪台机器有异常趋势。5.2 夜间告警分级与无人值守策略长稳测试大概率会跨多个夜晚如果每个告警都要打电话叫醒人团队撑不过第二天。我们把告警分成了三个等级P0级服务完全不可用、加速卡批量掉线、整节点宕机。这类必须立刻电话通知因为如果不及时处理后续几十个小时的压测数据都会失效。P1级性能指标大幅劣化比如QPS下跌超过50%、显存占用持续增长接近阈值、节点温度连续多次超过警告线。这类要求1小时内确认值班人员需要起来看一眼监控。P2级单次抖动、指标小幅波动、单卡温度短暂偏高。这类只记一条日志第二天复核不通知任何人。想要做到夜间安心额外有两个小工具很值得做。一个是自动巡检脚本每15分钟检查一次核心指标并生成摘要日志异常时自动抓取相关日志片段保存到临时目录。另一个是看门狗脚本监控压测客户端本身是否存活如果压测进程挂了自动重启任务并记录中断时间。长稳测试里最有挫败感的事就是压测工具在凌晨4点挂了早上9点才发现7个小时的数据全白费。5.3 日志收集的三个注意点日志在长稳测试中的价值比一般测试更大。我们在日志收集上犯了几个错误花了代价才修过来这里直接说结论第一所有节点和组件的日志时间戳必须统一格式统一时区毫秒级精度。第二集中式日志系统比如ELK或Loki必须在压测前就部署好并验证可用不要压测到一半发现日志采集进程内存溢出挂了。第三关键问题段落的原始日志要保留原始文件路径方便回溯压测结束后再压缩归档到冷存储。6. 压测报告怎么写才真正有参考价值6.1 报告结构的安排一份压测报告如果只堆数据那和没做测试差不多。我们的报告分成四个部分。第一部分是结论。结论必须是经过逻辑校验后的“输出决策”比如“系统当前适合承接目标负载但存在某某风险需要在一个月内完成某某优化后再次验证”或“系统未通过稳定性验证主要卡点在某某指标”。这部分放在最前面因为评审人最关心的就是结论。第二部分是关键数据。用表格列出7天每天的QPS平均值、P95/P99响应时间、错误率、资源利用率范围以及对比第一天的性能衰减程度。表格一定要有趋势列注明某一天是上升、下降还是平稳。第三部分是问题清单。这是整份报告最有价值的部分。每个问题需要包含现象描述、排查过程、根因分析、修复方案、验证结果五个要素。我们这次处理了三个P1级问题每个问题的排查过程都写成了可复现的步骤这样后续如果出现类似问题新同学也能快速上手排查。第四部分是原始数据和监控截图归档。Prometheus的历史数据、Grafana的看板截图、压测客户端的请求日志全部打包归档到对象存储保留至少一个月。这看起来不起眼但真到了有的问题在测试结束后才被业务指标暴露出来的时候你会发现原始数据是唯一可以回溯的线索。6.2 复盘会上那些不好回答的问题压测报告写完接下来就是评审会。根据我的经验技术负责人大概率会追问三个问题需要提前准备。第一个问题“你这个压测覆盖了真实业务场景吗”回答这个问题的底气来自测试前的流量分析。我们当时从生产环境收集了3天的日志分析了Prompt长度的分布、请求到达的时序特征、多轮对话的比例然后把这些特征完整复现到压测脚本里。第二个问题“切到国产算力集群之后性能比原来差多少”这个问题前面如果没做基线对比就答不上来。我们在压测前特意用同一个模型、同一份数据、同量级并发在旧集群上跑了一套对标测试结论就是要给出两张表的对比数据。第三个问题“压测通过了容量规划和扩容策略是什么”这要求你在报告里不仅写测试结果还要写业务建议。比如根据7天压测的数据建议目标并发控制在当前规模的70%当平均资源利用率连续30分钟超过85%时触发扩容扩容建议按线性扩展估算。这种问题提前想清楚评审会你就能掌握主动权。这段压测经历实际上比预期更值得记下来——不光是输出的数据有什么更重要的是把长期运行环境下那些探测的做法沉淀了下来。集群稳定性的问题从来没有“没问题”这个选项只有“还没被发现”的状态。这套方案里的指标分层、分段压测、告警分级和问题排查链路已经被我固定成内部的项目模板。下次再遇到国产算力集群的稳定性测试直接套用这套流程至少能少走一半弯路。