上海客服团队上线前：给 API 密钥配一份延迟与错误账本
假设你在上海的一支开发团队工作，周五要上线客服助手。测试时，有人说回答很快，有人却等了十几秒，还有人只看到“请求失败”。如果大家共用一把 API 密钥，又没有留下请求记录，你很难判断问题出在哪里。监控延迟与错误，就是给每次调用记一笔账，让“感觉不稳定”变成可以排查的事实。
按用途分配密钥，才能找到受影响的服务
API 密钥用于验证调用身份，也可以成为整理运行数据的线索。条件允许时，为正式客服、内部测试和夜间批处理分别配置密钥，并在自己的系统里标记用途。这样，批处理突然出现大量失败时，你能先确认正式客服是否也受影响。
记录中使用“客服正式环境”这样的别名，不要保存完整密钥，更不要把它放进浏览器页面或截图。密钥之间是否共享额度、限流或账户余额，要以服务规则为准；分开密钥不代表资源天然隔离。
首字延迟和总耗时回答两个不同的问题
对于流式回答，用户通常先关心“多久开始出字”，再关心“多久全部答完”。首字延迟衡量从发出请求到收到首个有效内容片段的时间；总耗时则一直计到响应结束。只收到连接信息或空事件，不代表已经开始回答。
例如，一次回答在一秒后开始显示，十二秒后完成；另一次等了八秒才开始显示，九秒后完成。后者总耗时更短，等待体验却可能更差。非流式请求可以先记录总耗时，不必强行套用首字指标。
用 P95 找到平均值掩盖的等待
平均耗时适合看整体变化，但少数特别慢的请求容易被大量快速请求掩盖。P95 可以理解为：把一批请求按耗时排序，约百分之九十五的请求不超过这个数值。它有助于观察较慢的一部分用户经历了什么。
比较时应尽量保持模型、任务和输出长度相近。生成一句欢迎语与整理一份长报告，不能直接放在一起判断速度。每次查看 P95 时也要看请求数量，十次请求得出的结果很容易波动。
错误率要包含超时和流式中断
错误率最基本的算法是失败次数除以请求总次数，但先要约定什么算失败。除了返回错误状态的请求，还应记录连接失败、客户端超时，以及已经开始输出却意外中断的流式回答。否则，日志可能显示请求成功，用户却只收到半句话。
- 认证或权限错误：先检查密钥、配置与访问权限。
- 限流错误：检查并发、发送频率和适用额度，避免立即密集重试。
- 服务端错误：结合时间、请求标识和服务状态排查。
- 超时或连接错误：同时检查客户端超时设置、网络和请求耗时。
HTTP 状态码提供排查方向，具体原因仍要结合错误信息。自动重试时，把原始请求和后续尝试关联起来，同时统计尝试失败率与最终任务失败率，避免重试掩盖问题。
先记录一行数据，再设置一条告警
无需一开始就建设复杂平台。可以先在调用代码中记录时间、密钥别名、模型、任务类型、首字延迟、总耗时、结果类型和请求标识。成功请求再记录可获得的输入与输出用量，方便解释长回答带来的耗时。默认不记录用户原文和完整回答，减少敏感信息进入日志。
先观察正常业务的表现，再设告警。例如，客服服务在五分钟内至少有一百次请求，失败率超过百分之三时提醒值班人员。这只是起点，需要按流量和业务容忍度调整；持续出现认证失败则可以单独提醒，不必等待凑够样本。
上线检查从一次真实调用开始
对于需要按量付费接入 AI 模型的团队，可以考虑 RelayVano，并注册账号完成一次小规模调用验证。其 API 基础地址为 https://api.relayvano.com，可用于兼容 OpenAI 的 SDK。把监控放在自己的调用层，再核对所用接口的路径与参数，就能按业务需要保留记录。
上线前，分别验证正常回答、认证失败和客户端超时是否留下正确记录。下一次同事说“今天回答很慢”时，你就能沿着时间、密钥别名和请求标识，找到对应调用。