为什么 AI 功能总在截止日那天崩？连接、重试和缓存该怎么测

截止日当天的故障，可能先从连接池耗尽开始，此时 CPU 看起来还很空闲。重复启动的后台任务、没有释放的 HTTP 连接、层层叠加的重试、没起作用的缓存，都会增加服务所需的连接数。

平时流量小，这些问题可能一直藏着。压测时要让流量维持得足够久，连接和队列才会积压出来。

企业系统的高峰来自共同的截止日

消费类应用的流量高峰来自新闻和营销活动，企业系统的高峰则写在日历上：月末结账、季度报告、周五下午五点截止的问卷。几百个好几周没打开过系统的人，会在同一个下午一起登录。

容量要按实测的工作负载来定。100 人读取缓存报表的测试，说明不了 100 人同时上传文件、让 AI 分析时会怎样。先记清工作组合，逐步增加负载，再维持足够长的高峰，观察连接有没有泄漏、队列是否持续增长。

拿一次 20 毫秒的数据库查询和一次假设耗时 20 秒的模型调用作比较，流式回答在生成期间一直占着连接。按这个例子算，每秒进来 100 个请求，每个占 20 秒，同一时刻就有 2,000 个请求在途。

很多过去可以放心使用的默认配置，到这里都不够用了。按快速查询设计的连接池会被抽干，只允许几百个并发请求的 Web 服务器开始排队。模型服务商按分钟限制 token 数和请求数，额度通常是整个账号共用的，一个热门功能跑得太猛，用同一个 key 的其他功能就全都拿不到额度。

扛得住的设计，都把 AI 调用当成又慢又稀缺的工作来对待。每个功能有自己的并发上限，能拆开的话再给它单独的配额。耗时长的任务进队列，并让用户看到自己排在第几位；流式回答可以在生成结束前就先显示部分内容。每次调用都设超时，用户离开页面就可以取消。

AI 系统的提效和数据库一样，第一步都是避免重复劳动。部分服务商会对符合前缀、长度和保留期限等条件的缓存输入打折，一个助手如果每轮对话都重新发送同一套长指令和参考文档，就该调整请求结构，让这些内容能被复用。结果不会变的东西，比如对上季度文档的分类，应该放进缓存，并设好明确的过期时间。

第二个办法是选对模型。给工单归类、从发票里抽字段、判断一句话有没有提到某个供应商，交给小而快的模型就够了。通读一份合同做推理、起草一份分析，才值得用大模型。算术交给经过测试的代码，同时明确单位、舍入规则和小数精度。

检查缓存要同时看命中率和结果是否正确。缓存键要包含用户权限和数据版本，权限或原始数据一变，旧结果就要失效。员工拿到过期答案或另一个租户的记录，命中率再高也没有用。

多层重试会相乘。假如上传客户端、网关、存储适配器各尝试三次，一次操作最多会触发 27 次下游请求。应只让一层负责重试，并给整次操作设一个总的尝试次数上限。

AI 系统要加倍小心这件事，因为代理重试一次工具调用，就可能把一个动作做两遍。重试要按指数退避，并加一点随机抖动，还要有总的尝试次数上限。会修改记录的调用，只要接收方支持，就带上幂等键，并由接收方负责去重。付款或邮件接口如果不支持去重，就得先核对上一次的执行状态，再决定是否重试。

平均值会把用户真正抱怨的请求藏起来。同一组负载下，要一起看 p95、p99、错误率、排队时长和每分钟完成量。取消和被拒绝的请求也要算进去，否则过载的服务反而可能显得很快。

AI 功能还要把首次有效输出的等待时间与全部完成时间分开测。排队时可以提示进度，开始生成后可以流式展示。具体目标要按任务和用户测试来定，不能假定所有人都能接受同一种等待。

下一个截止日之前，把 AI 功能打开，按预期高峰和事先约定的余量压测。除了 CPU，还要盯连接数、队列等待时间和限流响应。掘金的 AI 原生教程提供了应用架构概览，具体容量仍要用自己将要运行的工作负载来测。