AI API 延迟解析：TTFT、流式与为什么「首字」最重要

AI API Latency: TTFT, Streaming and Why First Token Matters

延迟的解剖学

一次流式请求的时间线：DNS 解析 → TCP 握手 → TLS 握手 → 闸道验证与路由 → 上游连线 → 模型排队与首字 → 逐 token 输出。前三段是网络常数（台湾到香港 RTT 19ms，3×RTT ≈ 57ms 属正常），后三段才是服务商能优化的。

所以别把 60ms 的 TTFT 当故障——那是物理极限附近；该追的是 P95 突然变长（代表某上游排队或故障转移在发生）。

流式的正确打开方式

①闸道必须关闭 SSE 缓冲（flush_interval -1），逐 chunk 转发；②HTTP/3（QUIC）在部分网络会卡到逾时，服务端应只开 h1/h2；③上游长连接复用省掉每次请求的握手（实测可省 25ms+）；④客户端 SDK 也要关缓冲（部分代理层的 gzip 会把 SSE 攒成一坨）。

延迟问题的排查流程

①在控制台看 TTFT P50/P95 分布，定位是全面变慢还是长尾；②若是长尾——大概率是某上游故障正在触发换家（每次失败尝试吃掉一个逾时周期）；③检查该时段是否正好有上游故障，服务商有没有自动切走；④自己网络层：换备援端点（例如香港↔日本通道）对比。

模型等级与延迟的关系

推理型模型（带 thinking）首字必然较慢——模型要先生成内部推理。旗舰模型在尖峰时段也可能排队。对延迟敏感的场景：选 flash／mini 等快速档位＋稳定分组；OlithmRouter 的用量日志同时记录 first_token_ms 与总延迟，模型间可直接对比。

常见问题

TTFT 多少算正常？

中转站场景，非推理模型 P50 在 1-3 秒属正常（含网络与上游排队）；推理模型看思考长度，数十秒也可能合理。看分位数比看单次准。

为什么有时候卡很久才开始吐字？

大概率是故障转移正在发生：第一上游秒错、第二上游等到逾时才换家。上游逾时设 300 秒的服务商会让你等满 5 分钟——这是设定问题，可要求调整或换服务商。

流式到一半断了怎么办？

闸道只能在「还没吐出任何位元组」前换家；已开始输出的断流需要客户端重试。好的服务商会在 SSE 结尾补齐协定要求的事件序列。

香港和日本端点差别？

延迟差别（香港离内地与台湾更近）与线路差别（CN2/普通线路）。OlithmRouter 提供主端点与香港、日本备援端点，控制台会标示建议。

相关文章