AI 流式响应可以成功发送响应头，却仍可能因客户端断开、上游中断或读取超时而结束。如果请求指标在响应开始时计数，一个没有完整结束的流也会看起来像成功的 200。
AISIX 1.6.0 于 2026 年 10 月 12 日发布，并改变了受支持流量的计量时点。AISIX 现在会在流结束时、按其结束状态写入请求指标。这让生产 SLO 更接近调用方实际经历的结果；它不会改变提供商计费，也不会把最初的响应头变成完成承诺。
AISIX 在你的环境中处理网关流量。本文描述的是 AISIX 网关遥测；AISIX Cloud 在其支持的部署选项中提供控制面和控制台。
核心要点
- 正常完成的受支持流会记录为
200；中途客户端离开为499，上游中断或流内错误为502，读取超时为504。 - 受影响的请求计数器和时长指标族现在描述流的最终结果。首 token 时间仍由专门的 TTFT 指标记录。
- 现有成功率、百分位数和基于
rate()的告警在升级后可能变化。长流会让速率信号大约滞后一个流的时长。 - 这是遥测语义变化，不会推断提供商费用、改写已交付给客户端的响应，也不覆盖文档列出的流式端点之外的所有端点。
为什么响应开始不是故事的终点
设想一个向浏览器流式返回助手回答的应用：响应头到达，浏览器渲染第一个 token，随后上游连接中断。在响应开始时计数会得到 200；在结束时计数才能让请求指标保留可观察到的最终结果。
1flowchart LR
2 C[客户端开始流] --> G[AISIX 网关]
3 G --> H[响应头和 token]
4 H -->|流完整结束| S[在流结束时记录 200]
5 H -->|断开、上游错误或超时| F[在流结束时记录最终状态]1.6.0 文档列出的覆盖范围包括 /v1/chat/completions、/v1/messages、/v1/responses 的流式调用、转写和翻译事件流、/v1/audio/speech 以及流式 /a2a 调用。流内 4xx 会保留原状态。调用方若在响应头之前离开，仍属于独立的客户端取消指标场景，而不是被追溯表示为已完成的流。
这一差异很重要：200 响应头与完整结束的流是不同事件。对于在 200 响应头之后被拒绝的流，发布说明也会在适用时保留 200，同时记录 error_class: content_filter。应一起解读状态、错误分类和端点特定语义，不能把其中一个字段当作通用的完成信号。
Prometheus 中发生了什么变化
AISIX 列出的受影响指标族包括：aisix_requests_total、aisix_request_duration_seconds、aisix_proxy_requests_total、aisix_proxy_failed_requests_total、aisix_proxy_request_duration_seconds、aisix_llm_requests_total 和 aisix_llm_request_duration_seconds。对于流式流量，成功率可能下降，时长百分位数可能上升，因为请求现在按最终结果、并按完整生命周期计入。
端到端和 TTFT 指标族——aisix_request_e2e_latency_seconds 与 aisix_request_ttft_seconds——现在带有流的真实 status_class，而非固定的 200。TTFT 本身仍是首 token 测量，不可替代完整流时长。
这并不意味着可以直接比较升级前后的仪表盘。更高的错误比例可能是对流式计量的准确修正，而非即时回归。同样，更高的时长百分位数可能反映新计量的完整流，而非首 token 时间变慢。
升级的不只是网关，还有告警契约
在将生产流量升级前，应有意识地让变化可观察：
- 清点会对流式流量查询受影响指标族的仪表盘、记录规则、SLO、自动扩缩容信号和告警。
- 在非生产环境运行正常完成的流、开始交付后的客户端取消、上游中断和读取超时，并确认查询展示的最终状态。
- 将首 token 与完整流的问题分开：前者使用 TTFT 指标，后者使用请求时长指标族。
- 复核基于
rate()的自动化，包括对aisix_llm_requests_total的任何 KEDA 查询。AISIX 说明，一阵长流可能让信号滞后约一个流的时长。 - 修改解析器或告警路由前，还应审阅 1.6.0 的其他升级说明，尤其是已重命名的
error_kind与error_class值。
不要用此变更估算提供商费用。AISIX 网关指标和使用量记录是运维证据；提供商账单仍是独立的事实来源。同样，也不要假设每个端点、未列出的协议，或尚未收到响应头的流遵循相同的生命周期规则。
计量调用方真正得到的结果
AISIX 1.6.0 为流式团队提出了更有用的问题：不是网关是否开始响应，而是该流如何结束。只要团队更新基线，并将 TTFT、完整流时长、状态和错误分类信号保持区分，成功率和时长信号就会更接近调用方体验。
升级前请阅读 AISIX 1.6.0 发布说明，然后验证你实际运行的流结果和告警行为。