流式响应健康监控：逐步测量首字、停顿与断流
§1 第一步：明确首字、停顿与断流的边界
监控流式回答，不能只看请求是否返回成功状态。流式接口会持续发送增量事件，文本、完成和错误需要分别处理，因此应把监控单位设为一次完整生成，而不是一次连接建立。([developers.openai.com](https://developers.openai.com/api/docs/guides/streaming-responses))
先约定三个业务指标：首字延迟表示请求发出到首段可展示文本到达的时间；生成停顿表示回答尚未结束时，连续没有新增内容；异常断流表示尚未确认完成，连接就结束或读取失败。这里的首字是用户体验指标，不宣称测到了模型内部生成首个词元的时刻。
§2 第二步：给每次生成记录关键时间点
为每次生成分配请求标识，并建议使用单调时钟计算耗时。建立以下埋点，把接收进度与展示进度分开记录，方便后续定位。
- – 请求发出时记录起点，同时保存模型、接口路径和重试次数。
- – 收到首个完整事件时记录事件时间，收到首段可展示文本时单独记录首字时间。
- – 每次收到有效增量时更新进度时间，文本实际展示时更新界面时间。
- – 确认完成、发生错误或用户取消时，记录唯一终态及对应原因。
解析时不要把一次网络读取直接当成一个完整事件。服务器发送事件使用空行分隔消息，需要先完成事件组装，再更新业务指标。([html.spec.whatwg.org](https://html.spec.whatwg.org/multipage/server-sent-events.html))
§3 第三步：计算真正可见的首字延迟
用首段可展示文本时间减去请求起点，得到首字延迟。不要在收到响应头或任意事件后立即停止计时，因为流中存在不同类型的事件，并非每个事件都是可展示文本。([developers.openai.com](https://developers.openai.com/api/docs/guides/streaming-responses))
建议同时记录接收首字和界面首字。若前者正常、后者偏慢，优先检查应用内部队列、批量刷新和渲染路径。仪表盘分别展示中位数、第九十五百分位及超时比例，不要让平均值掩盖长时间等待的请求。
§4 第四步：用双计时器识别生成停顿
分别维护传输活动计时器和内容进度计时器。前者观察数据是否继续到达，后者观察文本或工具参数等有效增量是否继续增长。事件流中的注释可用于保持连接，但不会作为普通消息交给应用，因此不能把心跳当成回答进展。([html.spec.whatwg.org](https://html.spec.whatwg.org/multipage/server-sent-events.html))
建议将“连续五秒没有内容”设为压测起点，而不是通用服务承诺。按照文本生成、工具执行等阶段分别调整阈值，并设置独立的总时长上限。告警应记录停顿开始和恢复时间，避免同一次停顿重复通知。
§5 第五步：用明确终态判断异常断流
为每个请求维护等待首字、持续生成、疑似停顿、完成、失败和取消状态。只有收到所用接口定义的完成信号，才标记正常完成；遇到错误事件则保留错误信息。流式接口具有专门的完成与错误事件，不能仅凭连接关闭判定成功。([developers.openai.com](https://developers.openai.com/api/docs/guides/streaming-responses))
建议将用户主动取消与异常断流分开统计，并把达到输出限制单列。发生断流时保留已展示内容、最后进度时间和失败阶段；重试创建新的尝试标识，不直接拼接两次生成的文本，也不默认服务支持从断点继续。
§6 第六步：验证告警并接入统一流式入口
上线前建议注入五类测试：首字前延迟、生成中暂停、完成前断开、正常完成和主动取消。逐项核对状态、计时和告警，确保监控不仅能发现失败，也不会把正常结束误报为断流。
需要统一接入多个模型时，可以考虑题设中的 Fluxio：它定位为流式优先、按词元付费的人工智能接口中转服务，适合在应用侧复用同一套埋点。仍应按具体模型、请求长度和执行阶段拆分指标，不把统一入口等同于统一延迟表现，也不假定中转服务自动提供上述监控。
注册 Fluxio，开始验证你的流式监控。