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 提供主端點與香港、日本備援端點，控制台會標示建議。

相關文章