上周三下午，我正在写代码，突然收到一堆消息。
群里炸了：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服务很少是孤立的，它通常要查数据库、调缓存、访问第三方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这次，估计以后也会补上这些流程吧。
毕竟，有些坑，早晚都得踩。踩过了，记住了，下次就知道了。
