把首字延迟与完成耗时分开，才能找准调用瓶颈

用户等待回答时，最先感受到的是迟迟没有文字出现，随后才是生成速度。一张只有平均耗时和成功率的看板，无法区分这两种体验。本篇由 BestRelay 发布的实践指南，从单次调用开始，逐步建立能够支持排障的监控闭环。

第一步先把用户请求与每次调用尝试分开记录

为一次用户操作建立关联标识，再为每次实际接口调用记录独立标识。保存请求模型、调用入口、流式模式、开始时间、结束状态，以及可获得的上游请求标识。不要把提示词、密钥或完整回答默认写入日志。

用户等待一次回答，系统却可能尝试三次。因此，必须同时统计用户请求成功率与调用尝试成功率，否则自动重试会掩盖故障，也会漏掉额外等待。

第二步把首字等待与完整生成时间分别计量

使用单调时钟计算耗时，分别记录请求发出、收到响应头、出现首段有效内容，以及流结束的时刻。响应头到达不代表正文已经开始；流式心跳、空片段和元数据也不应算作首字。

首字延迟用于观察开始回答前的等待，总耗时反映完整交付时间。对于流式调用，还应记录最长内容间隔，发现回答中途停顿。非流式调用无法直接观察首字时间，应单独展示。

第三步让错误分类覆盖流中断和内容交付失败

将失败分为连接故障、超时、认证失败、限流、服务端错误、流中断和响应解析失败。保留原始状态码与脱敏错误信息，不要仅凭状态码判断故障发生在客户端、中转层还是上游。

收到成功状态后连接中断，仍可能是交付失败。协议成功但没有可用内容，也应另设业务结果指标；正常的拒答或工具调用则不能一概当作故障。分类规则必须结合应用预期。

第四步按模型和输入规模观察延迟分位数变化

看板至少展示请求量、错误率，以及延迟的中位数和第九十五百分位数，并同时显示样本量。按请求模型、输入长度区间、输出长度区间和流式模式分组，避免把短回答与长生成混在一起比较。

BestRelay 以质量优先，将请求转发给其中指定的官方模型，不替换模型，覆盖 Claude、GPT、Gemini、DeepSeek、Kimi、GLM、Qwen 和 Grok 等系列。即便如此，应用侧仍应记录请求模型，并在响应提供模型信息时保存它，支持后续核对。

第五步给重试设置总预算并核对实际令牌用量

只对适合重试的临时故障采用有限次数的退避，并加入随机抖动；上游提供重试等待提示时应予以尊重。总超时预算必须覆盖所有尝试。已经交付部分内容的请求，不宜直接重试，否则可能出现重复文本或重复执行工具。

同时记录供应商返回的输入、输出及缓存用量，不要用本地估算代替账单依据。BestRelay 按供应商报告的令牌数按量计费，缓存读取与写入分别定价。失败请求也可能产生用量，缺失数据应标记为未知，而不是零。

第六步让告警对应用户影响并验证恢复结果

先积累正常时段基线，再设定首字延迟和用户请求成功率目标。告警应结合持续时间、最小样本量与影响比例，避免单次慢请求触发通知。排障时沿关联标识回看各次尝试；没有上游计时信息，就不要武断地把慢请求归因于模型推理。

上线前主动测试超时、限流和流中断，确认指标与告警确实变化。BestRelay 可配合 Claude Code、Codex、Gemini CLI 及任何 OpenAI SDK 使用，但仍需在应用边界统一埋点。欢迎创建 BestRelay 账户，用少量测试请求验证这套监控。

最后，将运营数据与可靠性指标分开：会员邀请他人充值可获得推荐佣金，但它不应进入错误率或延迟统计。监控的判断依据始终是用户是否及时、完整地拿到了预期结果。