OpenAI又宕机了！从这次事故看AI服务的性能测试怎么做上周三下午，我正在写代码，突然收到一堆消息。群里炸了：Ope

上周三下午，我正在写代码，突然收到一堆消息。

群里炸了：OpenAI又挂了。

有人发截图，ChatGPT页面一片空白；有人说API返回5xx；还有人幸灾乐祸：“让你们天天吹AI，关键时候掉链子。”

我刷着消息，突然想起上个月我们自己的AI服务也出过类似的事。那天也是周三，也是下午，也是突然就崩了。当时我正在开会，运维的电话打过来：“服务挂了，用户全连不上，怎么办？”

怎么办？我能怎么办，我又不能现场写代码把服务拉起来。

那之后，我们花了两周时间复盘，把AI服务的性能测试从头到尾捋了一遍。今天借着OpenAI这次事故，把这些经验整理出来，希望能帮到正在被类似问题折磨的同行。

一、先说说这次OpenAI宕机，到底是怎么回事

根据官方事后发的报告，这次事故的根源是监控系统的告警风暴把基础设施压垮了。

听起来有点绕，我用人话解释一下：

OpenAI内部有一个监控系统，专门盯着各个服务的健康状况。当天某个底层服务出了点小问题，触发了告警。按理说告警发出来就完了，但不知道什么原因，这个告警被无限循环触发——就像你手机收到一条短信，然后同一秒又收到一万条。

告警量暴增，监控系统自己扛不住了，开始卡顿。它一卡，其他依赖它的服务也开始出问题。连锁反应，最后整个ChatGPT都瘫了。

这事有意思的地方在于：出问题的不是AI模型本身，而是围着AI的那些基础设施。

这恰恰是很多做AI服务的人容易忽略的地方——我们把太多精力放在测模型效果上，却很少去想：当几百万用户同时涌进来的时候，那些“边角料”系统扛得住吗？

二、我们踩过的坑：第一次压测，服务直接挂了

上个月我们自己的事故，和OpenAI这次有点像，但起因更蠢。

我们上线了一个AI客服功能，模型调通了，响应时间也OK，领导说上吧。结果上线第一天，下午三点，服务挂了。

查日志发现，高峰期并发从平时的几十涨到了几百，然后数据库连接被打满了。为什么？因为每个请求都要去数据库查用户历史，但连接池只配置了50个。

几百个请求一来，连接不够，后面的全排队。排队一长，请求超时，用户端看到的就是“服务不可用”。

更蠢的是，我们之前压测过，但压测用的是简单的脚本，只测了AI接口本身，没测依赖的数据库、缓存、第三方API。结果就是：AI接口没崩，但数据库崩了；数据库崩了，AI也就跟着崩了。

那次事故之后，我们重新梳理了AI服务的性能测试，发现要测的东西比想象的多得多。

三、AI服务性能测试，到底要测什么？

传统接口的性能测试，套路很成熟：起压、看TPS、看响应时间、找拐点。但AI服务不一样，它有几个独有的特点：

特点一：计算密集，吃GPU

传统接口是CPU和内存密集型，AI接口是GPU密集型。压测的时候，GPU利用率、显存占用比CPU重要得多。

特点二：流式输出，指标不同

传统接口是一次性返回整个响应，AI接口很多是流式输出，一个字一个字往外蹦。这时候关注的不只是“总响应时间”，还有“首字返回时间”（TTFT）和“生成速度”（TPS）。

特点三：依赖复杂，容易崩在别处

就像我们那次事故，AI模型本身没崩，崩的是数据库。所以压测不能只压AI服务，得把整个调用链都带上。

特点四：成本高，不能随便压

跑AI服务是要花真金白银的——GPU实例贵，token也贵。压测一小时，可能几千块钱就没了。所以不能像传统压测那样随便跑，得精打细算。

基于这些特点，我们重新设计了性能测试方案，分成几个维度：

四、维度一：单用户性能测试

先别急着上并发，先看一个用户的时候体验怎么样。

我们主要盯两个指标：

TTFT（Time To First Token） ：用户发完请求到收到第一个字的时间。这个指标很影响感知——如果问完问题等两三秒才看到第一个字，用户就会觉得“卡”。

生成速度：每秒生成多少个字（token）。太慢了用户等得着急，太快了可能影响质量。

这两个指标和模型大小、硬件配置直接相关。我们测下来，7B的模型在小显存卡上TTFT能到2秒以上，130B的模型即使在高配卡上也要1秒左右。

给个参考值：我们内部定的标准是TTFT < 1秒，生成速度 > 20 token/秒。达不到就优化模型或者升级硬件。

五、维度二：并发性能测试

单用户没问题了，才开始上并发。

这里有个和传统压测很不一样的地方：并发数和显存的关系。

传统接口，并发主要吃CPU和内存。AI接口，并发主要吃显存。一个模型加载到GPU上，会占用固定的显存（比如10G），剩下的显存才用来处理并发请求。

假设一张卡有24G显存，模型占10G，还剩14G。每个请求需要额外的显存（比如1G），那这张卡最多同时处理14个请求。超过这个数，显存溢出，服务就崩了。

所以我们压测的时候，第一件事不是看TPS，而是找显存拐点：并发到多少的时候，显存开始接近上限。这个数就是理论上的最大并发。

然后在这个基础上，再测响应时间的变化、错误率、CPU/内存使用率。

血的教训：我们有一次没注意显存，直接压到50并发，结果服务挂了。后来发现，那张卡最多只能扛15个并发。

人工智能技术学习交流群

伙伴们，对AI测试、大模型评测、质量保障感兴趣吗？我们建了一个 「人工智能测试开发交流群」，专门用来探讨相关技术、分享资料、互通有无。无论你是正在实践还是好奇探索，都欢迎扫码加入，一起抱团成长！期待与你交流！👇

六、维度三：全链路压测

这是我们上次事故后加上的。

AI服务很少是孤立的，它通常要查数据库、调缓存、访问第三方API。这些依赖任何一个出问题，AI服务都会跟着崩。

所以我们现在的压测是“全链路”的：

压测工具模拟用户请求打到网关
网关转发给AI服务
AI服务去查数据库、调缓存、可能还调别的API
所有这些依赖都要带上，不能mock

有一次全链路压测，我们才发现Redis的连接池也配小了。单压AI服务的时候看不出来，全链路一跑，Redis先扛不住了。

建议：全链路压测最好在生产环境的镜像环境做，配置和数据都和真实环境一致。不然测出来不靠谱。

七、维度四：降级和容错测试

这是OpenAI这次事故给我们最大的教训。

他们的监控系统崩了，然后整个ChatGPT都崩了。这其实是架构设计的问题——监控系统应该是旁路的，不应该和主服务强耦合。

所以我们专门加了“降级测试”：

如果数据库挂了，AI服务还能不能用？（至少应该返回友好的错误提示）
如果缓存挂了，是直接报错还是可以降级到查数据库？
如果第三方API超时，是等着还是快速失败？

我们甚至故意把一些依赖搞挂，看AI服务的反应。

有一次测试，我们把Redis停了，结果AI服务直接抛了500错误。后来优化了代码，加了缓存不可用时的降级方案，至少能返回“服务繁忙，请稍后再试”，而不是一坨乱码。

另一个要测的是“优雅降级” ：当并发超限时，是直接拒绝，还是排队，还是返回简化版的结果？这些都得提前想好、测好。

八、维度五：长稳测试

很多问题不是压测那一会儿能发现的。

我们有个模型，跑了一周之后，响应时间越来越慢。查了半天，发现是日志打印太多，把磁盘打满了。还有一次，某个缓存没设置过期时间，越积越多，最后把内存撑爆了。

这些都得靠长期稳定性测试来发现。

我们的做法：用中低并发（比如最大并发的30%）连续跑24-48小时，盯着这几个指标：

响应时间有没有缓慢上升（可能内存泄漏）
错误率有没有突然增加（可能某个资源耗尽）
磁盘、内存、GPU使用率有没有异常增长

跑过一次48小时长稳，发现显存占用从10G慢慢涨到了14G，最后服务崩了。后来排查是某个模块有内存泄漏，修了之后才稳定下来。

九、维度六：容量规划测试

最后一个是给运维和老板看的。

“我们的服务到底能扛多少用户？”这个问题必须用数据回答。

我们做的容量规划测试分几步：

单用户资源消耗：跑一个请求，看消耗多少GPU时间、多少数据库连接
并发拐点：找到性能开始下降的并发数
资源瓶颈分析：是GPU不够？数据库连接不够？还是网络带宽？
模型推演：根据DAU预估峰值并发，看看当前配置够不够

比如我们算出来，一个请求平均消耗0.5秒的GPU时间，一张卡每秒最多处理2个请求（不算排队）。如果峰值并发是100，那就需要至少50张卡。

这个数字给老板，他才知道要买多少机器、花多少钱。

十、写在最后：性能测试的本质，是准备承受多少失败

OpenAI这次宕机，持续了好几个小时。网上很多人嘲讽，但做过AI服务的都知道，这太正常了——越是复杂的系统，越容易在想不到的地方出问题。

我们那次事故之后，组里有个同学问：“那我们能保证以后再也不出类似问题吗？”

我想了想说：“不能。”

他愣了一下。

我接着说：“但我们可以保证，出了问题的时候，我们知道是哪里出的、为什么出的、多久能修好。还可以保证，不会因为一个小问题，把整个服务都拖垮。”

这大概就是性能测试的本质——不是追求“永远不会崩”，而是追求“崩的时候不会太惨”。

那次事故之后，我们每个月做一次全链路压测，每季度做一次容灾演练，每次上线前做一次容量评估。麻烦是麻烦了点，但至少再出问题的时候，我不会在会议室里被领导盯着说不出话了。

OpenAI这次，估计以后也会补上这些流程吧。

毕竟，有些坑，早晚都得踩。踩过了，记住了，下次就知道了。

OpenAI又宕机了！从这次事故看AI服务的性能测试怎么做