大模型流式输出如何做首字延迟监控：TTFT、分段耗时与客户端断线

流式回答“开始得快不快”，不能只看整段响应的总耗时。用户真正感受到的是请求发出后多久看到第一个可展示片段，也就是 TTFT（Time to First Token）；首字出现后，如果片段间隔忽长忽短，体验仍然会卡。线上排查时，还要把客户端主动断开、代理超时和服务端自然结束区分开，否则平均耗时会掩盖真正的问题。

先把一次流式请求拆成四段时间

一个请求从网关入口到用户看到文字，至少存在四段容易混淆的时间：进入服务后的排队时间、模型开始产出前的等待时间、首片写入响应的时间，以及首片之后的片段传输时间。把它们全部压成一个 duration_ms，只能回答“这次慢不慢”，回答不了“慢在哪里”。

我更建议每个请求保留一条短时间线：accepted_at、upstream_started_at、first_chunk_at、last_chunk_at。其中 TTFT 可以定义为 first_chunk_at - accepted_at；如果网关已经记录排队结束时间，再额外计算模型等待段，排查会更准确。

规模上来后，原来的总耗时指标为什么失真

假设一批请求总耗时都在 8 秒左右，其中一半在 300 毫秒内已经看到首片，另一半排队 4 秒后才开始输出。平均值看起来稳定，用户却会明显分成“很快”和“像没响应”两组。更麻烦的是，某些代理会缓存少量字节，服务端记录的首片时间和浏览器真正收到首片时间并不相同。

因此指标至少要按成功完成、客户端断开、上游失败三类终态拆开，并同时看 p50、p90、p99。片段间隔不要只记平均值，保留最大间隔和最后五片的间隔，才能发现“前面顺畅、结尾卡住”的情况。

在 Go 服务端记录首片和分段间隔

计时要使用单调时钟差值，不要把多个墙上时钟的格式化字符串拿来相减。下面的示例只演示观测骨架：收到第一个非空片段时设置 TTFT，之后为每个片段递增序号，并在客户端取消时立即记录终态。

type StreamStats struct {
    AcceptedAt time.Time
    FirstChunk time.Time
    LastChunk  time.Time
    Chunks     int
    Bytes      int
    MaxGap     time.Duration
    EndReason  string
}

func (s *StreamStats) ObserveChunk(now time.Time, n int) {
    if n == 0 {
        return
    }
    if s.Chunks == 0 {
        s.FirstChunk = now
    } else if gap := now.Sub(s.LastChunk); gap > s.MaxGap {
        s.MaxGap = gap
    }
    s.Chunks++
    s.Bytes += n
    s.LastChunk = now
}

真实服务里还要把请求 ID、模型别名、区域、协议类型和代理节点写入同一条日志。不要把用户原文或完整回答塞进指标标签；它们会造成高基数，也可能把敏感内容带进长期存储。

首片必须是“可展示片段”

有些上游事件只包含角色、元数据或空增量。它们到达得再早，也不能算用户看见了文字。建议把“事件到达”和“可展示片段”分成两个计时点，并在服务端明确过滤空增量，否则 TTFT 会被虚假地压低。

如何判断是模型慢、代理缓冲还是客户端网络抖动

排查时把同一个请求 ID 串起三处时间：服务端读到上游片段的时间、服务端写入下游的时间、客户端收到片段的时间。第一段就慢，优先看排队和模型；服务端读得快、写出慢，检查下游缓冲和 flush；服务端写出快、客户端收到慢，则要看网络、浏览器连接和移动端切网。

不要看到片段间隔变大就立刻调小超时。先拿一条慢请求的时间线对齐日志，再确认它是否只发生在长上下文、特定模型或特定区域。没有分组的总量指标，很容易把容量问题误判成模型问题。

客户端断线后，成功与失败要怎样收口

客户端取消上下文后，服务端通常会先收到写入错误或取消信号。此时应停止读取后续片段，记录已经确认的最后序号，并把 end_reason 设为 client_cancelled。不要继续等待上游自然结束，也不要把这次请求混入“完整成功”的 TTFT 分布。

如果业务允许恢复，恢复请求要带上原请求 ID 和最后确认序号；服务端再决定是从缓存片段继续，还是重新生成并在客户端去重。恢复不是简单重发，尤其是带工具调用或有副作用的流程，必须先确认重复动作不会再次发生。

用一条可复现的回放样本做上线验收

上线前准备三组固定样本：短输入、长上下文、主动取消。每组至少记录首片时间、片段数、最大间隔、终态和最后序号。验收不追求一个永远不变的毫秒数，而是确认字段齐全、终态互斥、断线后没有继续计入成功流，并能从请求 ID 找回同一条时间线。

request_id=chat_20260825_001
status=client_cancelled
first_chunk_ms=612
chunk_count=7
max_gap_ms=934
last_confirmed_seq=6
end_reason=client_cancelled

这条样本里，序号从零开始还是从一开始并不重要，重要的是协议和日志保持一致。监控面板则建议同时展示 TTFT 分位数、最大片段间隔、断线率和各终态占比；四者缺一时，结论都可能偏。

常见问题：流式体验指标怎么避免误读

TTFT 越低，整段回答就一定越快吗？

不一定。TTFT 只描述首片之前的等待，后续生成速度和网络传输仍由片段间隔、总字节数与收口时间决定。

空事件能不能算首片？

不建议。只有真正能被客户端展示的非空片段才应写入 TTFT，否则不同协议的首片口径无法比较。

客户端断线要不要继续统计上游耗时？

可以作为资源回收指标单独统计，但不要把它与完整成功请求的总耗时混在一起，并明确标注断线终态。

为什么服务端 TTFT 很低，用户仍然觉得卡？

常见原因是下游缓冲、网络抖动或片段间隔过大。对齐服务端写出时间和客户端收到时间，通常比继续调模型参数更快找到方向。

把“快不快”变成能定位的时间线

流式输出的观测重点不是再增加一个漂亮的平均数，而是把首片、片段、断线和终态放进同一条可回放的时间线。先建立稳定口径，再按模型、区域、上下文长度和终态拆分分位数；遇到慢请求时，沿着请求 ID 对齐服务端、代理和客户端三个时间点，优化才不会靠猜。